10 Things to Do for DORA Compliance

The Digital Operational Resilience Act has applied since 17 January 2025. It covers banks, payment institutions, investment firms, insurance companies, crypto asset service providers, and a wide range of other financial entities — along with the ICT providers that serve them.

DORA doesn't just require that your systems are secure. It requires that you can prove your operational resilience is managed, tested, documented, and governed. Regulators are now actively reviewing implementation. Here is what you need to do.

1. Build an ICT risk management framework

Your ICT risk management framework is the foundational document for DORA compliance. It must describe your approach to identifying, classifying, and managing ICT risk across your business. It must be approved by your management body, reviewed at least annually, and updated after significant incidents or strategic changes.

This is not an IT policy document. It is a governance-level framework signed off by senior management. If it doesn't exist, start here.

2. Map all your ICT assets

You cannot manage risk on assets you haven't identified. Your ICT asset inventory needs to cover systems, applications, data repositories, hardware, cloud services, and SaaS tools. It must be kept current — not a one-time exercise.

For each asset, identify: what it does, what data it holds or processes, who owns it, and how critical it is to your operations. Link it to the third-party arrangements where relevant.

3. Identify and classify every ICT third-party provider by criticality

DORA specifically requires that you identify which ICT providers are critical to your operations — meaning that their failure would prevent you from delivering your services. These critical providers carry heightened obligations and more intensive monitoring requirements.

Go through your vendor list and assess each one: what happens to your business if this provider has a major outage? Which ones are genuinely replaceable in a reasonable timeframe, and which ones aren't?

4. Create a register of all ICT third-party arrangements

DORA requires a register of all ICT third-party arrangements — every vendor contract, every SaaS subscription, every cloud service that touches your operations. The register must be maintained, kept current, and provided to your competent authority on request.

The register should include: provider name, type of service, whether the arrangement is considered critical or important, contract start and expiry dates, and the applicable contractual terms. This is a living document, not an annual exercise.

5. Define your incident classification criteria

When an ICT incident occurs, your team needs to be able to classify it quickly — specifically, whether it meets the threshold for a "major ICT-related incident" under DORA. Major incidents trigger mandatory regulatory reporting with tight timelines.

DORA specifies criteria for classification: number of clients affected, duration, geographic spread, data losses, criticality of disrupted services, and economic impact. Your internal classification criteria must align with these. Your team must know them before an incident occurs, not during.

6. Build an incident reporting process with regulatory timelines

For major ICT incidents, DORA requires three reports to your competent authority:

• Initial notification: within 4 hours of classifying the incident as major
• Intermediate report: within 72 hours of the initial notification
• Final report: within one month of the incident

This is faster than most organisations' existing incident response processes. Build the workflow, assign the roles, and test it. The four-hour window for initial notification in particular requires that someone is empowered to make the classification decision and trigger the notification without waiting for management approval that may take too long.

7. Conduct digital operational resilience testing

DORA requires that in-scope entities conduct regular testing of their ICT systems. For most entities, this means regular vulnerability assessments and basic testing programmes. For "significant" financial institutions (as designated by competent authorities), this extends to threat-led penetration testing (TLPT) every three years.

This is not uptime monitoring or standard IT health checks. Resilience testing specifically assesses your ability to withstand and recover from ICT disruptions. Define your testing programme, run it, and document the results and remediation actions.

8. Review every ICT vendor contract for DORA-required clauses

DORA specifies mandatory contractual provisions that must appear in all ICT third-party contracts. These include:

• Clear and complete description of services
• Service level agreements with measurable performance indicators
• Audit rights for the financial entity (and its competent authority)
• Termination rights and exit strategies
• Sub-outsourcing provisions and restrictions
• Data security and confidentiality requirements

Review your existing contracts. Missing clauses mean non-compliance at the contract level — and when these contracts come up for renewal, the required terms must be included. Start renegotiating critical contracts now if needed.

9. Establish a threat intelligence programme

DORA requires that in-scope entities monitor the threat landscape relevant to their sector and incorporate threat intelligence into their risk management. This doesn't mean building a security operations centre. It does mean having documented sources of threat intelligence — sector-specific ISACs, national CSIRT feeds, vendor threat reports — and a process for reviewing and acting on that intelligence.

Document how intelligence feeds into your risk management decisions. What sources do you use? Who reviews them? How often? What is the escalation path if a relevant threat is identified?

10. Test your business continuity and disaster recovery plans for ICT disruptions

DORA requires that business continuity and disaster recovery plans are specifically designed for ICT disruptions — and tested. Having the plans documented is the minimum. The regulation expects evidence that you've run them.

Tabletop exercises are a starting point, not the end state. Run actual recovery tests. Simulate a critical system failure or a ransomware scenario. Time the recovery. Document the gaps and the remediation actions. The test results are part of your evidence base for compliance.

DORA has applied since 17 January 2025. Competent authorities are now actively reviewing implementation across all in-scope sectors.

Knowing the 10 steps and having them documented, monitored, and auditable are two different things.

This article is for informational purposes only and does not constitute legal advice. For legal advice specific to your situation, consult a qualified attorney licensed in your jurisdiction.