DORA readiness checklist for cloud teams

Who is in scope, and why proportionality matters

DORA applies to most regulated financial entities in the EU: credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and more (Article 2). It also reaches ICT third-party service providers - cloud providers included - through the oversight framework and, more practically for you, through the contractual requirements your regulator expects to see in your cloud agreements.

The proportionality principle (Article 4) is real: a three-person fintech is not expected to run the same programme as a systemic bank. But proportionality changes the depth of each artefact, not the list of artefacts. Every entity in scope needs a documented ICT risk framework, an incident process, a testing programme and a third-party register.

Pillar 1: ICT risk management (Articles 5-16)

The management body owns ICT risk under DORA: it cannot be delegated away to a CISO or a cloud team. What the cloud team owns is the evidence that the framework describes reality: an asset inventory that matches what actually runs, network and identity documentation, and a mapping from critical business functions to the cloud services that support them.

• ✓A current inventory of ICT assets and cloud accounts, with owners.
• ✓Documented identification of critical or important functions and the systems supporting them.
• ✓Access management evidence: SSO, least privilege, joiner-mover-leaver process, no shared long-lived credentials.
• ✓Backup and restore policy with tested restore evidence - not just backup job logs.
• ✓A business continuity and disaster recovery plan with defined RTO/RPO for critical functions.

Pillar 2: Incident management and reporting (Articles 17-23)

DORA requires a process to detect, classify and report major ICT-related incidents to your competent authority, with an initial notification, an intermediate report and a final report on fixed timelines. The classification criteria (clients affected, duration, geographic spread, data losses, criticality of services, economic impact) are set out in the regulatory technical standards.

For a cloud team this means your monitoring and on-call process needs a bridge into regulatory reporting: whoever is on call must know which severity levels trigger the compliance clock and who makes that call at 3 a.m. Write it down, run one tabletop exercise, and keep the log.

Pillar 3: Resilience testing (Articles 24-27)

All entities in scope need a proportionate digital operational resilience testing programme: vulnerability assessments, scenario-based testing, and for entities designated by their supervisor, threat-led penetration testing (TLPT) at least every three years. Most cloud teams already do parts of this. The gap is usually that nothing is documented as a programme.

Start from what you have: dependency scanning, restore tests, chaos or failover exercises. Put them on a calendar, define what evidence each run produces, and store that evidence where an auditor can find it.

Pillar 4: Third-party risk and the register (Articles 28-30)

This is the pillar that lands hardest on cloud teams. You must maintain a register of information covering all contractual arrangements with ICT third-party providers (Article 28(3)) - hyperscalers, SaaS tooling, managed service providers - and your supervisor can request it. Contracts supporting critical or important functions must contain the specific provisions of Article 30: audit and access rights, exit strategies, service levels, incident support and termination rights.

Practical order of work: inventory every provider touching production, classify which support critical functions, then gap-check those contracts against Article 30. For AWS, Azure and GCP there are financial-services contract addenda that cover most clauses, but you have to actually sign them and file them.

A realistic 90-day sequence

If you are starting late, sequence beats completeness. Weeks 1-4: asset and provider inventory, criticality mapping, register skeleton. Weeks 5-8: incident classification bridge into on-call, restore test with evidence, contract gap analysis. Weeks 9-12: close the highest-risk contract gaps, document the testing programme, brief the management body. That is a defensible position, and a far better conversation with a supervisor than a perfect plan that has not started.

FAQ