An ICT risk register that maps to Article 6
Not a generic risk log, the register the framework actually requires, with the classifications, dependencies and criticality the supervisor will check against.
DORA compliance
DORA, operational, not aspirational.
A working DORA programme for EU financial entities and the ICT providers they depend on: risk register live, major-incident workflow tested against the clock, third-party register in the format the ESAs ask for, and a board that can defend the programme to its supervisor.
- Scope and proportionality decision documented, not assumed.
- Major-incident reporting tested against the 4h / 72h / 1-month clocks.
- Third-party register in the ESA-defined format, not a spreadsheet rebrand.
- Regulation 2022/2554
- Live since Jan 2025
- ESAs oversight regime
- Article 30 register
When this is for you
The moments DORA becomes a board item.
-
Your supervisor asked for the ICT risk register.
A thematic review opened, the request is specific, and the artifact you have is a risk log that does not map to Article 6. What lands on the regulator's desk needs to be the artifact they ask for, in the format they ask for, this week.
-
A financial-entity customer is pushing DORA terms into the contract.
You sell software, cloud or managed services into a bank or insurer. Article 30 contractual clauses are not optional and not negotiable, exit, sub-outsourcing, audit rights, data localisation. The procurement clock is short.
-
An incident happened and the 4-hour clock surprised you.
Initial notification within 4 hours of classification, intermediate within 72, final within one month, in the ESAs' structured template. Without a tested workflow these deadlines are unreachable in practice and the supervisor will notice.
-
The management body has heard "ultimately responsible" and wants a defensible answer.
DORA makes the management body explicitly accountable for the ICT risk-management framework. We translate the obligation into something a board can approve, oversee and document, not just a slide that says "compliant".
The engagement
Five phases, scope to ongoing supervisory dialogue.
Each phase produces an artifact the supervisor recognises by name, not a deliverable we invented.
- 01
Scope, proportionality & gap 2–3 weeks
Entity classification, proportionality decision, and a gap assessment against the five pillars. Outputs: scope memo, proportionality rationale, prioritized remediation plan with named owners.
- 02
ICT risk-management framework 4–6 weeks
Governance arrangements, ICT risk register, classification of information assets and ICT functions, business-impact analysis, and the documented strategy the management body adopts. Article 6 onwards, mapped to operating controls your team can actually run.
- 03
Major-incident reporting workflow 3–4 weeks
Classification criteria, escalation paths, communication templates for the 4-hour initial, 72-hour intermediate and 1-month final notifications in the ESA's template. Tested in a tabletop with the actual people who would file them.
- 04
Third-party register & contractual cleanup 4–8 weeks
The Article 30 register populated in the ESA-defined format, criticality assessment per provider, sub-outsourcing chain mapped, exit strategies drafted, and a programme to renegotiate contracts that fail the mandatory clauses.
- 05
Resilience testing & supervisory dialogue 3–6 weeks
A proportional testing programme, regular for everyone, threat-led for the significant. The first round scoped, executed and reported. Ongoing dialogue with the supervisor handled by a named officer with the artifacts to support the conversation.
Outcomes
What the regulator examines.
A tested major-incident workflow
4-hour, 72-hour and 1-month notifications drafted, owned and rehearsed against the ESA template. The first real incident is not the rehearsal.
An Article 30 register that audits cleanly
Third parties classified, sub-outsourcing chains mapped, exit strategies drafted, and a contractual remediation plan for the providers that fail the mandatory clauses.
A management body that can sign and defend
Briefing pack, decision log and the documented oversight responsibilities. When the supervisor asks who approved what and when, the answer is in the file, not in someone's inbox.
From the practice
"DORA is the first time the EU has put a binding oversight regime on the ICT chain a financial entity depends on. The firms that treat it as another tickbox will find out, the hard way, that the supervisor reads the register line by line."
Purple Dragon Cybersecurity
Frequently asked
Common questions, direct answers.
Who is actually in scope for DORA?
EU banks, insurers, investment firms, payment institutions, crypto-asset service providers, central counterparties, trade repositories, and a long list of other financial entities. It also reaches their critical ICT third-party providers, cloud platforms, SaaS vendors, MSPs, through the oversight framework. If you operate financially in the EU or sell software to one, you are very likely in scope.
DORA went live in January 2025. What does that mean now?
Enforcement is active. ESAs and national competent authorities are running thematic reviews, asking for the ICT risk register, the third-party register, the major-incident reports and the testing programme. The grace period is over, what is missing today is a finding waiting to happen.
How is DORA different from NIS2 or ISO 27001?
NIS2 is horizontal critical-infrastructure law; DORA is the financial-sector lex specialis that overrides it for ICT risk. ISO 27001 is a voluntary certification, useful as a foundation but never a substitute. DORA adds explicit incident-reporting clocks, mandatory advanced testing (TLPT) for significant entities, and a binding third-party oversight regime that the others do not have.
Do we need to do threat-led penetration testing?
Only if you are designated as a significant financial entity by your national authority. The TLPT regime is closer to TIBER-EU than to a regular pentest, scoped, intelligence-led, conducted by certified providers, every three years. For everyone else, regular testing of critical ICT systems is required but the format is proportional.
What does the third-party register actually have to contain?
A specific format defined by the ESAs: legal entity, contractual function, criticality assessment, sub-outsourcing chain, exit strategy, data localisation, and the contractual clauses required by Article 30. It is not a procurement list with a security column bolted on, it is a regulatory artifact that gets requested by name.
Get a 30-min DORA scope check
No deck. A working session that confirms whether you are in scope, where the gaps are, and what the next 30 days should produce.
Talk to a security operator.
Tell us what you're trying to ship, what's stalled, or which buyer security review is up next. We work with companies across the EU, EEA and US, and we reply within one business day.
- info@purpledragoncyber.com
- +31 10 899 8719
- Nicolaas Beetsstraat 216, 3511 HG Utrecht