Fintech auditors accept vulnerability management that matches the regulations you fall under in wording and evidence. In the EU, DORA asks for documented patch and update policies, continuous identification of vulnerabilities, regular testing and tracked remediation. Show the policy, the inventory and dated records of each step.
What does DORA actually say?
Regulation (EU) 2022/2554, the Digital Operational Resilience Act, applies from 17 January 2025 to financial entities in scope, which may include fintechs depending on their licences. Check scope with counsel. Four provisions matter for vulnerability work:
- Article 8(2): financial entities shall, on a continuous basis, identify all sources of ICT risk and assess cyber threats and ICT vulnerabilities relevant to their business functions, information assets and ICT assets. Risk scenarios must be reviewed regularly and at least yearly.
- Article 9(4)(f): have appropriate and comprehensive documented policies for patches and updates. Point (e) adds documented change management for software, hardware and firmware.
- Article 24(6): other than microenterprises, ensure at least yearly that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions.
- Article 25(1): the testing programme provides for tests such as vulnerability assessments and scans, open source analyses, network security assessments, source code reviews where feasible, scenario-based tests and penetration testing.
Article 24(5) adds that entities must establish procedures to prioritise, classify and remedy all issues revealed by testing, with internal validation to confirm weaknesses are addressed.
What does the text not say?
It does not give a number of days to patch. The regulation sets duties to have policies, to test and to remediate, and leaves the timeframes to you and to supervisory expectations. Auditors accept your timeframes if they are written, risk-based and followed.
How do you order fixes in a way you can defend?
CISA's BOD 26-04 gives a useful structure, though it binds US federal agencies. Its inputs are asset exposure, whether the CVE is in the Known Exploited Vulnerabilities catalog, whether exploitation can be automated, and technical impact. Its most urgent lane is action within three days plus forensic triage, and its slowest is "fix on system upgrade". A payments API on the internet with a known exploited flaw lands in the fast lane. An internal reporting tool with a low-impact flaw lands in the slow lane.
NIST SP 800-40 Rev. 4 describes enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches. Verification is the step teams skip, and the one auditors check.
What evidence turns policy into proof?
Constructed example. A payments startup keeps a register with one row per finding: source (scan, pen test, advisory), asset and criticality, date found, priority and rule used, owner, fix date, verification date and link to the change ticket. Quarterly, the head of engineering signs a summary. Open items past target have an exception with an approver and expiry. When an auditor samples five rows, each tells a complete story.
For software dependencies, a bill of materials per release lets you answer "are we exposed" in minutes when a flaw is announced. Open source analysis appears in Article 25's list of tests, so keep results from dependency scans as testing evidence.
What to do
- Confirm which regulations apply and extract their vulnerability and testing clauses.
- Write a patch and update policy covering software, firmware and third-party components.
- Inventory ICT assets and tag criticality and exposure.
- Define a prioritization rule and target times by priority.
- Run vulnerability scans, dependency analysis and source reviews on a schedule, and test critical systems at least yearly.
- Track every finding to verified closure, with exceptions approved and expiring.
- Have independent testers, internal or external, as Article 24(4) requires.
- Report the register to management quarterly and keep the minutes.
Safeguard's SBOM and dependency scanning, reachability analysis and compliance automation can help create and organise parts of this evidence. They do not make an entity compliant with DORA.
Quick check
Does DORA set a patching deadline?
No. It requires documented patch and update policies and remediation of test findings, leaving timeframes to the entity.
How often must critical systems be tested under DORA?
Article 24(6) requires appropriate tests at least yearly on ICT systems and applications supporting critical or important functions, for entities other than microenterprises.
Sources
- Regulation (EU) 2022/2554 (DORA), EUR-Lex
- CISA BOD 26-04: Prioritizing Security Updates Based on Risk
- NIST SP 800-40 Rev. 4
Last reviewed: 18 October 2026.
