Frameworks and Standards

DORA

EU regulation that sets uniform rules for ICT risk management, incident reporting, resilience testing, and third party oversight in the financial sector.

Where you will see it: Used in governance, risk, and compliance work: control selection, audits, reporting, and security roadmaps.

What it is

A binding EU regulation that standardizes how financial entities manage ICT risk, handle incidents, test resilience, and control third party ICT dependencies.

Key points
  • Applies to many EU financial entities and introduces EU level oversight for critical ICT third party service providers.
  • Requires an ICT risk management framework covering prevention, detection, response, recovery, and communication.
  • Mandates reporting of major ICT related incidents to competent authorities and encourages structured post incident learning.
  • Requires digital operational resilience testing, with advanced threat led penetration testing for certain entities.
  • Strengthens ICT third party risk management through due diligence, contract requirements, monitoring, and exit planning.

How it works in broad strokes

  1. Scope critical services and ICT assets, then set governance and accountability at management level.
  2. Build an ICT risk management framework: policies, controls, monitoring, and documented resilience objectives for critical services.
  3. Define incident classification and reporting workflows, including playbooks, communications, and lessons learned.
  4. Run a resilience testing program that fits your risk, from basic control testing up to threat led penetration testing where required.
  5. Manage ICT third party risk with structured due diligence, contract clauses, ongoing monitoring, and realistic exit plans.

Concrete example

A payment firm migrates key workloads to a cloud provider. Under DORA, it must assess concentration risk, harden identity and logging, ensure incident support is contractually defined, test recovery with realistic exercises, and maintain an exit path if the provider becomes a critical dependency.

Why it matters

Financial services are interconnected. A single ICT outage or supplier failure can cascade across firms. DORA aligns expectations across the EU and pushes organizations to prove resilience, not only document security.

Security angle

  • Treat operational resilience as a lifecycle: design for failure, detect quickly, respond decisively, recover reliably, then improve.
  • Use the same criticality lens for vendors as for internal systems: service mapping, concentration risk, and shared dependencies.
  • Make testing evidence driven: test results should feed risk decisions, investments, and board reporting.

Common pitfalls

  • Treating DORA as documentation only, while leaving monitoring, testing, and recovery maturity unchanged.
  • Weak service mapping, which hides critical dependencies and makes exit plans unrealistic.
  • Over relying on a cloud or MSP contract without verifying observability, incident support, and recovery capabilities.
  • Incident reporting that focuses on paperwork, not on improving detection, containment, and recovery time.
  • Running generic annual tests that do not reflect real attack paths or operational failure modes.

DEEP DIVE

▾

Resilience evidence, not paperwork

DORA pushes financial entities to prove that critical services can survive real ICT disruption, not just that policies exist. A good DORA program treats outages, cyber incidents, and supplier failures as normal operating conditions that must be engineered for.

In practice, the question becomes simple: when something breaks, can you detect it quickly, make correct decisions under pressure, and recover within stated objectives. That evidence comes from monitoring coverage, rehearsed runbooks, tested backups, and clear escalation paths, not from a one time compliance sprint.

Because the regulation applies across the EU financial sector, the expectation is consistency and comparability. If two firms claim the same resilience objective, regulators will expect similar quality of evidence behind it.

The five pillars translated into day to day work

DORA groups requirements into ICT risk management, incident management and reporting, resilience testing, third party ICT risk management, and information sharing. Teams usually implement this by anchoring governance at management level, then building a cycle of map, protect, monitor, test, and improve.

The most visible change is service centric thinking. Instead of starting with tools or systems, you start with critical services, their recovery objectives, and the ICT components and suppliers that enable them. This becomes the backbone for risk decisions, reporting, and testing plans.

A mature program connects these pillars. Vendor clauses influence logging access, logging influences incident detection, detection quality influences reporting, and reporting lessons influence the next testing cycle.

Incident reporting as an operational learning loop

Incident reporting under DORA is easy to misunderstand as a paperwork exercise. The real intent is to force strong classification, timely internal decision making, and reliable external communication when an incident is material.

High performing teams design reporting from the inside out. They define what evidence is needed during response, how to preserve it, who decides severity, and how to update regulators and customers without guessing. This reduces panic and prevents inconsistent messages.

The fastest maturity gains come after the incident. Each major event becomes a short improvement cycle that tightens detection, response, and recovery, and then feeds back into testing scenarios.

Third party ICT risk, concentration, and exit reality

DORA is explicit that outsourcing does not outsource accountability. A cloud provider, managed service, or SaaS platform can become a single point of failure, so vendor management must become technical and operational, not only contractual.

The practical focus is on observability, incident support, and recoverability. Contracts are useful only if you can actually get logs, trigger escalations, and execute a realistic exit path under time pressure. If an exit plan cannot be tested, it is usually not real.

Concentration risk is the quiet challenge. Even if each vendor looks acceptable alone, shared dependencies can create systemic risk across services, regions, or an entire portfolio.

How to start so it survives audits and outages

Start by mapping a small number of critical services end to end, including systems, data flows, identities, and suppliers. Add clear recovery objectives and verify that they can be met with current backups and runbooks.

Next, build an evidence pack for each service. Include monitoring signals, response playbooks, recovery test results, and third party clauses that enable access and support. This makes gaps visible and turns compliance into engineering tasks.

Then iterate with realistic exercises. Pick scenarios that mirror real failure modes, measure detection and recovery time, fix what breaks, and expand the approach to the next set of services.