DORA compliance checklist for IT and security teams

DORA (Digital Operational Resilience Act) applies to financial entities and critical ICT providers operating in the EU, with supervisory expectations around continuous resilience — not “compliance on paper.” Industry estimates often cite tens of thousands of in-scope entities and material ICT providers; penalties can reach up to €10M or 2% of worldwide annual turnover (whichever is higher), depending on the case and legal basis.

DORA’s five pillars (what IT must be able to prove)

1. ICT risk management — identify critical functions, map supporting assets, maintain a living risk register.
2. Incident reporting — classify major incidents and meet regulator timelines (initial notification within 4 hours; follow-ups within 72 hours where applicable).
3. Resilience testing — baseline testing for all; TLPT-style threat-led testing for systemic entities.
4. Third‑party ICT risk — contractual rights, exit plans, and concentration risk visibility.
5. Cyber threat intelligence sharing — structured collaboration where permitted, with privacy and competition safeguards.

Tools like Avanoo help teams operationalize inventory and governance: detect Shadow IT / Shadow AI and align evidence collection with NIS2 and DORA expectations.

Why it matters: DORA is not only about fines — it’s about keeping critical services available under stress and demonstrating defensible oversight to supervisors and customers.

What is DORA? (training excerpt)

ICT risk management (what “good” looks like)

DORA expects a closed-loop ICT risk framework: identify, protect, detect, respond, recover — and review after major incidents, architecture changes, or threat shifts.

Inventory critical systems and SaaS

Start by mapping critical/important business functions to the ICT assets that support them — including cloud and “non-standard” SaaS that never went through architecture review. DORA pushes organizations toward a standardized register of ICT assets and third-party arrangements.

For vendor criticality, use supervisory criteria (impact, substitutability, substitutability constraints) and define RTO/RPO targets for essential systems.

Continuous risk assessment

Anchor your program to credible baselines (ISO 27001, NIST CSF, COBIT) and run a BIA that ties downtime scenarios to euros/minutes — not vague “high/medium/low” labels.

Governance isn’t a staff-only exercise: DORA emphasizes board-level ownership of ICT risk policy and tolerance.

Automate evidence and monitoring

Use SIEM and APM where appropriate, but don’t confuse tooling with outcomes: the goal is timely detection, traceability, and audit-ready records. Automated evidence collection can dramatically reduce audit prep time — if the underlying inventory stays current.

Major incident reporting (make timelines boring — in a good way)

DORA’s incident lifecycle is designed for consistency across the EU. Practically, you need classification, communications, and forensic discipline that start immediately — not after legal spends a weekend debating definitions.

Classification criteria (simplified)

A major incident is typically evaluated using supervisory criteria (often based on thresholds like customers affected, duration, geography, data impact, economic impact, service criticality). Many frameworks also treat recurrent minor incidents with a common root cause as major when they repeat within a window.

Response plans and crisis mechanics

Your playbooks should include: crisis team roles (IT, legal, risk, comms), decision rights, forensic preservation, regulator notification templates (including identifiers like LEI where required), and customer/partner messaging discipline.

For French operations, coordinate with national authorities as applicable (ACPR, CNIL, ANSSI) alongside EU-level processes.

Operational resilience testing (baseline + TLPT)

DORA distinguishes baseline resilience testing and TLPT for systemic entities. The point is not “more pentests” — it’s a program with prioritized scope tied to critical functions, remediation tracking, and board visibility.

Maintain a living asset register for testing scope

Your register should connect assets to critical functions, include fourth-party dependencies where relevant, and survive scrutiny — poor register quality is a common supervisory finding in pilot reporting exercises.

Cadence (indicative)

Many programs run quarterly vulnerability scanning on critical systems, annual penetration testing / scenario exercises, and TLPT on the supervisory cadence for in-scope entities. Validate major releases with secure SDLC reviews.

Reporting outcomes

Each test should produce methodology, findings, remediation owners, and deadlines — stored in the ICT risk system and escalated to management with measurable closure.

Third‑party ICT risk (you can outsource work, not accountability)

Assess vendor criticality and concentration

Evaluate data volume, service criticality, failure impact, security posture evidence (SOC reports, ISO), incident history, and concentration (single points of failure across the market).

Contractual minimums (Article 30 directionally)

DORA raises the bar for contractual content on critical ICT services: SLAs, audit rights, data location, assistance during incidents, and exit/transition assistance. Many teams implement DORA addenda rather than renegotiating entire estates overnight.

Contract element	Why it matters
SLAs + RTO/RPO	Makes resilience measurable
Audit / inspection	You cannot govern what you cannot verify
Data location + transfers	GDPR + operational reality
Exit + transition	Prevents hostage renewals
Incident cooperation	Clear runbooks reduce clock risk

Ongoing monitoring

Run service monitoring, periodic reassessment, and supply-chain mapping (including nth-party dependencies). Update the register when vendors change — and at least annually even if “nothing changed” (something always changed).

Information sharing on cyber threats

Article 45 enables sharing of IOCs, TTPs, and alerts in trusted communities — with GDPR and competition-law guardrails. Operationalize TLP-style handling, validate IOCs before distribution, and use standards like STIX/TAXII where possible.

Platforms like MISP and SOAR integrations help operational teams convert intelligence into action — without turning sharing into accidental data leakage.

Tools that make DORA operational (not theoretical)

Financial IT teams need continuous inventory, automated evidence, and supplier visibility — especially where SaaS and AI adoption outpaces traditional CMDB hygiene.

Avanoo for SaaS + AI governance

Avanoo helps European organizations discover what is actually used — including Shadow IT and unauthorized AI tools — and consolidate an evidence-friendly inventory quickly (typically <15 minutes to first integrated view with standard connectors).

"We discovered 214 AI tools in use. We only knew about 7. Avanoo gave us the clarity to act." — Thomas D., IT security lead, European bank

EU hosting options support sovereignty expectations for sensitive assessments — pair technical discovery with your legal/procurement register to close the DORA “unknown ICT” gap.

Plans (illustrative)

Capability	Basic	Professional	Enterprise
Shadow IT detection	Yes	Yes	Yes
Shadow AI discovery	Limited	Full	Full
Supply-chain mapping	No	Baseline	Advanced
DORA / NIS2 modules	No	Yes	Yes
Browser nudges / surveys	No	Yes	Yes

Conclusion

DORA turns resilience into a management system: ICT risk, incidents, testing, third parties, and intelligence sharing are mutually reinforcing — not five separate projects.

"The essence of DORA is strengthening the financial sector’s digital resilience as ICT disruption and cyber threats accelerate." — Danielle Barbour, Kiteworks (paraphrased public statement)

If you start anywhere, start with truth in inventory — because every other control depends on knowing what runs in production, who owns it, and what happens when it fails.

FAQs

We don’t have a trustworthy ICT asset register yet — where do we start?

Run a gap assessment against DORA expectations, then build a minimum viable inventory (apps, infra, critical vendors, owners, RTO/RPO). Expand iteratively — perfection is not a prerequisite for progress.

How do we prove DORA compliance in an audit without manual chaos?

Automate evidence: risk assessments, incident timelines, test reports, vendor reviews, and change records. Auditors reward repeatable processes and traceability, not slide decks.

When is an ICT provider “critical” under DORA?

Supervisors look at dependency, substitutability, concentration, and impact on the financial system — not at your internal “tier 1 / tier 2” label alone.