A colleague forwards you the Digital Operational Resilience Act and asks the question with no short answer: are we compliant? You already run scans and patch what they find. The harder question is whether you can prove the programme behind those scans to a financial regulator who asks for evidence.
DORA compliance is the state of meeting the requirements of the Digital Operational Resilience Act (DORA), Regulation (EU) 2022/2554, the EU law that sets uniform rules for how financial entities manage information and communications technology (ICT) risk. It has applied since 17 January 2025 and binds every in-scope organisation directly, with no national transposition step (member states do not pass their own version of the law first). For the in-house IT or security lead, the practical weight of DORA sits in two places: the controls you run, and the evidence you can produce that they work.
This guide explains who DORA applies to, what each of its five pillars requires, and where continuous vulnerability management does the heaviest lifting. By the end you will know which obligations land on your team, what evidence an auditor expects, and how to tell whether your current scanning demonstrates a programme or just produces reports.
What is DORA compliance?
DORA compliance is meeting the requirements of the Digital Operational Resilience Act, Regulation (EU) 2022/2554. The regulation requires EU financial entities to manage ICT risk, report major incidents, test their operational resilience, control third-party ICT dependencies, and share threat intelligence. Compliance means running those controls and holding the evidence that proves it.
DORA replaced a patchwork of national and sector rules with one directly applicable regulation across the EU. Because it is a Regulation and not a Directive, it took effect the same way in every member state, with no local transposition law to wait for. The European Supervisory Authorities (ESAs), the joint body of the EU banking, insurance, and markets regulators, fill in the technical detail through regulatory technical standards (RTS).
The shift DORA makes is from documentation to demonstration. Earlier guidance let many firms describe their controls in a policy and move on. DORA expects a financial entity to show that its controls operate, that issues get remediated, and that someone validated the fix. For a lean IT function, that is the part worth planning around.
Why DORA exists and why it matters now
DORA exists because the financial sector's biggest operational risk shifted from balance sheets to systems. A single ICT failure or cyberattack at a bank, payment firm, or one of their technology suppliers can cascade across the market. The regulation makes digital operational resilience a supervised obligation, on the same footing as capital or liquidity.
For the team carrying compliance, the timing is the pressure. The obligations are live, not pending.
DORA has applied to in-scope financial entities since 17 January 2025. It is binding in its entirety and directly applicable in every EU member state.
The organisations that struggle are rarely the ones missing scanners. They are the ones who scan, fix, and then cannot reconstruct what happened when a supervisor asks. DORA turns that gap into a compliance finding.
Key DORA terms at a glance
DORA uses precise definitions, and they decide who has to do what. A short glossary before the pillars:
| Term | What it means under DORA |
|---|---|
| Financial entity | One of 20 regulated categories in Article 2, from credit institutions to crypto-asset service providers. |
| ICT third-party service provider | Any undertaking providing ICT services to a financial entity, including hosting, software, and managed services. |
| Critical or important function | A function whose failure would materially impair the firm's financial performance or its regulatory standing. |
| Digital operational resilience | The ability to build, assure, and review the integrity and reliability of the systems supporting financial services. |
| Threat-led penetration testing (TLPT) | An intelligence-led red-team test of live production systems, modelled on real threat actors. |
| Vulnerability | A weakness, susceptibility, or flaw in an asset, system, process, or control that can be exploited. |
These definitions carry weight. "Critical or important function" sets the scope of testing. "ICT third-party service provider" decides whether a supplier is pulled in.
Who needs to comply with DORA?
DORA applies to 20 categories of financial entity listed in Article 2, plus the ICT third-party service providers that supply them. If your organisation is a regulated financial firm in the EU, or you provide ICT services to one, DORA is likely to reach you, directly or through contract.
The financial entities DORA covers
Article 2 names the in-scope categories explicitly, and they run far wider than banks. The list includes credit institutions, payment institutions, electronic money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, insurance and reinsurance undertakings, insurance intermediaries, institutions for occupational retirement provision, credit rating agencies, and crowdfunding service providers, among others.
Two qualifiers matter for smaller firms. Microenterprises (under DORA, fewer than 10 staff and no more than EUR 2 million in annual turnover or balance sheet) get a lighter-touch version of several obligations. And some entities, such as small and non-interconnected investment firms, fall under a simplified ICT risk-management framework in Article 16 rather than the full Chapter II regime.
ICT third-party providers: in scope by proxy
This is where DORA reaches beyond finance. Article 2 of the regulation lists ICT third-party service providers as in-scope, and the law imposes detailed requirements on the contracts between financial entities and their suppliers. A software vendor, hosting provider, or managed service firm that serves a bank does not file the same reports the bank does. But it inherits obligations through its customer's compliance.
In practice, a financial-entity customer must map its ICT dependencies, set contractual terms covering security and audit rights, and may include a supplier in its resilience testing. So the supplier feels DORA through questionnaires, contract clauses, and testing requests. A recurring question from suppliers is whether merely hosting a service in the EU brings the relationship into scope. The answer turns on what the service supports, not where it runs: if it underpins a financial entity's critical or important function, expect to be in scope by proxy.
A narrower group, the ICT providers designated as "critical" by the ESAs under Article 31, face a direct EU oversight framework. Most suppliers will not be designated critical, but every supplier to a financial entity should expect their customers to push DORA obligations down the contract.
Microenterprises and the simplified framework
DORA is proportionate, not one-size-fits-all. Article 4 sets a proportionality principle, and several articles scale obligations to the size and risk profile of the entity. Microenterprises are exempt from parts of the testing regime, and the entities listed in Article 16 follow a simplified ICT risk-management framework.
That said, simplified is not absent. An entity under Article 16 still has to maintain a documented ICT risk-management framework, continuously monitor its systems, detect and handle incidents, identify third-party dependencies, and test its controls regularly. The evidence burden is lighter, not gone.
What are the five pillars of DORA?
DORA is commonly described as five pillars, each a chapter of the regulation: ICT risk management, ICT incident management and reporting, digital operational resilience testing, ICT third-party risk management, and information sharing. Together they define what a financial entity must do to be resilient and to prove it.
Pillar 1: ICT risk management
ICT risk management is the foundation. Chapter II requires the management body, your board or senior leadership, to own ICT risk, not delegate it away, and to maintain a sound, well-documented risk-management framework covering the full system lifecycle. The framework spans identification, protection, detection, response, recovery, and learning.
For an IT team, the operational core is asset identification and detection. Article 8 requires you to identify and classify the ICT assets supporting your functions. Article 10 requires mechanisms to detect anomalous activity. You cannot protect or test what you have not inventoried, which is why asset discovery and continuous monitoring underpin every other pillar.
Pillar 2: ICT incident management and reporting
Chapter III requires a process to detect, manage, and classify ICT-related incidents, and to report the major ones. Article 18 sets the classification criteria that decide whether an incident counts as major. Article 19 requires major incidents to be reported to your competent authority, the national regulator that supervises your firm, such as a central bank or financial-markets authority.
Reporting runs on a staged clock: an initial notification, an intermediate report as the situation develops, and a final report once the root cause is known. The exact deadlines are fixed by the regulation's technical standards. The clock starts when you become aware, so the firms that struggle are the ones still gathering basic facts when the first deadline lands.
Pillar 3: Digital operational resilience testing
This is the pillar where vulnerability management does the heaviest lifting. Chapter IV requires financial entities, other than microenterprises, to run a testing programme and to test all ICT systems supporting critical or important functions at least once a year.
Article 25 names the tests, and the list is explicit.
The testing programme must provide for "vulnerability assessments and scans." Article 25 lists them alongside network security assessments, gap analyses, source-code reviews, and penetration testing.
A separate, heavier obligation sits on top. Larger and more systemic entities, identified by their competent authority, must carry out threat-led penetration testing (TLPT) at least every three years, modelled on the European TIBER-EU framework (the EU's standard for intelligence-led red-team testing). TLPT is a bespoke red-team test of live production systems, and it sits above routine scanning rather than replacing it. For most lean IT teams, the load-bearing requirement is the Article 25 testing programme, run continuously and evidenced.
Article 24 also closes the loop. A financial entity must prioritise, classify, and remedy every issue the tests reveal, and validate that each weakness was fully addressed. Finding issues is not the deliverable. Closing them, with proof, is.
Pillar 4: ICT third-party risk management
Chapter V governs the suppliers behind your systems. It requires a register of your ICT third-party arrangements, a preliminary assessment of concentration risk (over-dependence on a single supplier whose failure would take down a critical function) before signing, and specific contractual provisions covering security, audit rights, and exit. The aim is that a financial entity never loses visibility or control because a function sits with a vendor.
For the IT lead, this pillar turns vendor management into a documented, ongoing discipline. You map dependencies, you assess them, and you keep the register current as services change.
Pillar 5: Information sharing
Chapter VI, a single article, encourages financial entities to share cyber threat intelligence among themselves within trusted communities. It is voluntary, not mandatory. Its inclusion signals DORA's intent: resilience is collective, and timely threat information helps the whole sector respond.
How vulnerability management satisfies DORA's resilience-testing pillar
Continuous vulnerability management is the operational engine of DORA's testing pillar and a core input to its risk-management pillar. Article 25 names vulnerability assessments and scans as required tests, and Article 24 requires you to remediate and validate what they find. A programme that scans, tracks remediation, and records the outcome produces exactly the evidence those articles demand.
The gap most explainers leave open is proof. Detecting vulnerabilities is the easy part, and most teams already do it. The hard part under DORA is showing a supervisor, months later, that a critical finding was prioritised, assigned, fixed, and verified, with a record that survives a second question. That is the difference between owning a scanner and running a vulnerability management lifecycle.
This is the work Vornin is built to remove. We scan across web apps, infrastructure, code, and cloud, then auto-map every finding to the frameworks it touches, including DORA. Each finding carries its full history, and that history is sealed in a per-tenant tamper-evident evidence chain, so the record cannot be quietly edited after the fact. When a competent authority asks, you export an auditor pack the auditor can verify, rather than reassembling screenshots the week before a deadline. Findings auto-resolve on the next clean scan, and overdue issues escalate before they become a finding of their own.
The point is not the scan. It is that the same record proves both that you tested and that you closed the loop, which is precisely what Article 24 asks for.
What DORA requires of your ICT-risk programme
DORA's requirements translate into a short set of things your ICT-risk programme must be able to do and to demonstrate. The detail varies with your size and risk profile, but the shape holds across the five pillars.
DORA compliance checklist: the five pillars
Use this as a readiness check, not a project plan. For each pillar, the question is whether you can show it, not just claim it.
- ICT risk management: a documented framework, a current inventory of ICT assets supporting critical functions, and management-body ownership of ICT risk.
- Incident reporting: a classification process for major incidents and the ability to file initial, intermediate, and final reports within the regulatory deadlines.
- Resilience testing: a testing programme that includes vulnerability assessments and scans, run at least yearly on systems supporting critical functions, with remediation and validation recorded.
- Third-party risk: a register of ICT suppliers, concentration-risk assessment before contracting, and DORA-aligned contractual terms.
- Information sharing: awareness of, and ideally participation in, trusted threat-intelligence sharing arrangements.
The evidence each item produces is the deliverable. A scan report proves you looked. A remediation record with timestamps and validation proves you acted. DORA cares about the second.
If your team also handles other EU frameworks, the work overlaps. The same vulnerability evidence that satisfies DORA's testing pillar maps closely to ISO 27001 control A.8.8 and to the NIS2 Directive's Article 21, so one record can serve several audits. For the dual-scope case, see our guides to NIS2 compliance and where NIS2 and ISO 27001 overlap.
DORA vs GDPR: what's the difference?
DORA and the General Data Protection Regulation (GDPR) are both EU regulations, but they protect different things. DORA protects the operational resilience of financial systems. GDPR protects the personal data of individuals. A financial entity is usually subject to both at once.
The practical differences:
| Dimension | DORA | GDPR |
|---|---|---|
| Protects | Operational resilience of ICT systems | Personal data and privacy rights |
| Applies to | Financial entities and their ICT providers | Any organisation processing EU personal data |
| Core obligation | Manage ICT risk, test resilience, report incidents | Lawful processing, data subject rights, breach notification |
| Incident trigger | Major ICT-related incident | Personal data breach |
| Supervisor | Financial competent authority, such as a central bank | National data protection authority |
The overlap is incident handling. A single cyberattack can be both a major ICT-related incident under DORA and a personal data breach under GDPR, with two separate reporting clocks running to two different regulators. Your incident process has to satisfy both.
Frequently asked questions
Is DORA applicable to the UK?
No. DORA is an EU regulation and does not apply to UK-based firms following Brexit. A UK company can still be affected indirectly if it provides ICT services to an EU financial entity, because that customer must impose DORA-aligned terms in the contract.
What is DORA regulation in a nutshell?
DORA is the EU's Digital Operational Resilience Act, Regulation (EU) 2022/2554. It sets uniform requirements for how financial entities manage ICT risk, report major incidents, test their resilience, and control their technology suppliers. It has applied since 17 January 2025.
What is the DORA Act Ireland?
There is no separate Irish DORA act. DORA is an EU regulation that applies directly in Ireland, the same as in every member state. In Ireland, the Central Bank of Ireland is the competent authority responsible for supervising DORA compliance.
When did DORA come into force?
DORA entered into force on 16 January 2023, twenty days after its publication in the Official Journal of the EU. It became applicable, meaning firms had to comply, on 17 January 2025, after a two-year implementation period.
Does DORA apply to a company that supplies software to a bank?
Often, by proxy. A software supplier is not a financial entity, but DORA requires its financial-entity customers to impose security, audit, and resilience terms through the contract. If the software supports a critical or important function, expect to be brought into scope through your customer's obligations, and possibly into their resilience testing.
How often does DORA require testing?
Financial entities other than microenterprises must test all ICT systems supporting critical or important functions at least once a year, using tests that include vulnerability assessments and scans. A subset of larger, more systemic entities must also perform threat-led penetration testing at least every three years.
What evidence do auditors expect under DORA?
Auditors and competent authorities look for proof that controls operate, not just that they exist. That means documented test and scan results, records showing that critical findings were remediated and by when, validation that fixes were confirmed, and justification for any issue left unaddressed. A record that holds up to follow-up questions is the goal.
Is ISO 27001 enough for DORA?
ISO 27001 is a strong foundation but not a substitute. Its controls overlap heavily with DORA's ICT risk-management and testing requirements, so a certified firm starts well ahead. But DORA adds finance-specific obligations, such as detailed third-party contractual terms, regulator incident reporting, and threat-led penetration testing, that ISO 27001 does not require.
Conclusion
DORA compliance is live and directly binding: financial entities and their ICT suppliers have had to meet it since 17 January 2025. The regulation's five pillars define both the controls you run and the evidence you produce, and the evidence is where most teams fall short. Of the five, the resilience-testing pillar is where continuous vulnerability management earns its place, because Article 25 names vulnerability assessments and scans and Article 24 demands you remediate and validate what they find. The teams that pass are the ones who can prove the programme behind the scan, not just show the scan.
Resources and further reading
Primary source:
Read-only access · Working scan data deleted after each scan · EU-hosted
