DORA — the Digital Operational Resilience Act — went live across the EU in January 2025. If you work at a bank, insurance company, investment firm, payment processor, or any of the other financial entities it covers, you are now legally required to comply.
The problem is that DORA is a regulation written by lawyers, for lawyers. The actual text runs to dozens of articles, each referencing others, with definitions that require their own definitions. Reading it and knowing what you need to do to your infrastructure are two very different things.
This post cuts through it. Here’s what DORA actually requires from your IT infrastructure — organized by what you need to have, what you need to document, and what you need to prove.
First: who does DORA apply to?
DORA covers ‘financial entities’ as defined in Article 2. The list is long but the main categories are:
- Credit institutions (banks)
- Payment institutions
- Electronic money institutions
- Investment firms
- Crypto-asset service providers
- Insurance and reinsurance undertakings
- Occupational pension funds
- Credit rating agencies
- Data reporting service providers
The regulation also applies to ICT third-party service providers that serve these entities — cloud providers, software vendors, managed service providers — though their obligations differ.
If you’re unsure whether your organization is covered, assume it is and verify with legal counsel. The fines for non-compliance reach €10 million or 2% of total annual worldwide turnover, whichever is higher.
What DORA requires — broken down by infrastructure topic.
1. ICT risk management framework (Articles 5–16)
You need a documented ICT risk management framework. This isn’t a policy document — it requires actual implementation evidence.
Specifically, your framework must include:
- An up-to-date map of all ICT systems, assets, and their interdependencies
- Classification of systems by criticality
- Identification of all dependencies on third-party ICT providers
- Documented processes for identifying, assessing, and managing ICT risks
The phrase ‘up-to-date map of all ICT systems’ is doing a lot of work here. It means a continuously maintained inventory — not a spreadsheet that someone updates before audits. DORA assessors will ask when it was last verified, how it’s kept current, and what process updates it when infrastructure changes.
2. ICT-related incident management (Articles 17–23)
You need to be able to detect, classify, and respond to ICT incidents. Infrastructure requirements here include:
- Monitoring capability across critical systems — you need to know when something goes wrong, fast
- Documented incident response procedures with clear escalation paths
- The ability to reconstruct what your infrastructure looked like at the time of an incident
- Logging that supports root-cause analysis
That last point is often missed. DORA requires you to be able to explain what happened and why. That requires a change history — a record of what your infrastructure looked like before, during, and after an incident.
3. Digital operational resilience testing (Articles 24–27)
You need to regularly test your ICT systems for resilience. For most financial entities this means:
- Basic testing: vulnerability assessments and network security testing
- Advanced testing (for significant entities): Threat-Led Penetration Testing (TLPT)
The infrastructure requirement here is documentation — evidence that tests were conducted, what was tested, what was found, and what was remediated. This evidence needs to be traceable back to specific infrastructure components.
4. Third-party ICT risk (Articles 28–44)
This is the part that catches organizations off guard. DORA requires you to manage the ICT risk of your third-party providers — not just accept their security certifications and move on.
The key requirements:
- Maintain a register of all ICT third-party service providers
- Classify providers by criticality
- Conduct due diligence before engagement and ongoing monitoring
- Include specific contractual provisions in agreements with critical providers
Article 30 is particularly important for infrastructure teams. It requires that contracts with third-party ICT providers include provisions for exit — the ability to transition services away from the provider. This applies to any tool or platform that touches your critical infrastructure, including governance and monitoring tools.
5. Information and intelligence sharing (Articles 45–49)
DORA encourages (and for significant entities, may require) participation in information sharing about cyber threats. The infrastructure implication is that you need to be able to extract and share relevant threat intelligence from your environment without exposing sensitive operational data.
The documentation DORA assessors will ask for.
When a DORA assessment happens — either internal audit or regulatory inspection — here’s the documentation that will be requested:
- ICT asset inventory — complete, current, and with a process for keeping it current
- System criticality classification — which systems are critical, how that was determined
- Change history — evidence that infrastructure changes are tracked and reviewed
- Third-party provider register — all providers, criticality classification, contractual status
- Incident records — classification, response timeline, infrastructure impact
- Testing evidence — what was tested, when, by whom, findings, and remediation
- Exit plans — documented capability to exit critical third-party arrangements
The common thread: you need to be able to produce this documentation quickly, for any point in time, and have it reflect what actually happened — not what was planned.
The most common DORA gaps in infrastructure teams.
The asset inventory is manual and out of date
Every infrastructure team has some form of asset inventory. Almost none of them are current. The moment a new service is deployed, a container is scaled, or a configuration changes, the inventory is wrong. DORA requires a process for keeping it current — not a best-effort spreadsheet.
The change history is in Git, Jira, and memory
Most teams can tell you what changed if you ask the right person. They can’t always tell you what changed across all environments, across all teams, for a specific time window, in a format that maps to specific ICT systems. DORA needs that mapping.
Third-party dependencies aren’t fully mapped
Cloud providers are obvious. But what about the IaC tools, the monitoring platforms, the compliance scanning tools? Every piece of software that touches your infrastructure is a third-party ICT provider under DORA. Most teams haven’t mapped all of them.
Exit capability is theoretical, not demonstrated
Most organizations can tell you they could exit a provider ‘in principle.’ DORA requires that exit capability be documented and demonstrated. For many tools — especially those deeply integrated with infrastructure management — exit is more complex than assumed.
What a DORA-ready infrastructure looks like.
A DORA-compliant infrastructure is one where:
- Every component is discovered, classified, and documented automatically — not manually
- Every change is tracked with a timestamp, an actor, and a before/after state
- Compliance checks run continuously, not just before assessments
- Reports can be generated for any historical state, not just the current one
- All tooling is self-hosted or has documented, exercisable exit capability
None of these are aspirational. DORA assessors will expect evidence, not intent.
The good news: if you have continuous infrastructure discovery, versioned change tracking, and automated compliance checking, most of the evidence DORA requires is already there.
What to do next.
If you’re an IT leader at an EU financial institution, the first step is understanding your current gap. Specifically:
- Do you have a current, complete ICT asset inventory? How is it maintained?
- Do you have a change history that maps changes to specific ICT components?
- Have you mapped all third-party ICT dependencies, including tooling?
- Do you have documented exit capability for critical providers?
These aren’t trick questions. They’re the questions a DORA assessor will ask. If any of them give you pause, that’s where to start.
Vernix.one was built specifically for this problem. It discovers infrastructure automatically, maintains a versioned history of every change, runs continuous compliance checks against DORA requirements, and is self-hosted — so it satisfies Article 30’s exit requirement by design. We can show you exactly what your DORA compliance status looks like today, against your real infrastructure, in a single session.