| name | dora |
| description | EU Digital Operational Resilience Act (2022/2554) compliance — scope (financial entities + critical ICT TPPs), five pillars (ICT risk management, incident reporting, resilience testing incl. TLPT, third-party risk, information sharing), and Dutch oversight via DNB/AFM. |
DORA Compliance
Disclaimer: not legal advice. This skill supports a technical gap analysis against DORA and the underlying Regulatory Technical Standards. Legal qualification (entity classification, contract clauses, sanctions risk) requires financial-law expertise, usually via a compliance department or external counsel.
When to use
The Digital Operational Resilience Act (EU regulation 2022/2554) has been in force since 17 January 2025. It harmonizes ICT risk management for financial entities in the EU and extends supervision to critical ICT third-party providers. As a regulation (not a directive), DORA applies directly in NL law without an implementation act, although with a national supervision structure (DNB + AFM + ESAs).
Triggers on:
- A question like "DORA gap analysis", "is our entity in scope of DORA", "how do we classify an incident under DORA", "what is a TLPT", "set up a DORA third-party register", "DNB reporting pipeline".
- A financial entity (bank, insurer, investment firm, pension fund, payment institution, crypto-asset service provider, crowdfunding platform, trading venue, etc.) that needs to demonstrate compliance.
- An ICT service provider serving EU financial entities and considering whether it will be designated a "critical ICT third-party provider" by the ESAs.
- A handoff from
iso27001 or nis2: DORA replaces NIS2 for financial entities (lex specialis) on most points but not all.
- A security incident where classification and reporting timing must be determined.
When NOT (handoff)
- General EU cybersecurity for non-financial →
nis2. Note: in dual-scope cases (e.g. a payment institution that also delivers digital infrastructure) both can apply.
- GDPR/AVG breach notifications →
gdpr-pia. DORA reporting is additive, not a replacement.
- Technical ICT risk-management implementation → the relevant security skills (
ir-runbook, detection-engineer, container-hardening, etc.). DORA demands that you have things; how lives there.
- Threat-Led Penetration Testing execution itself → pentest skills (
recon-agent, web-exploit-triage, c2-hygiene, pentest-reporter). This skill describes the TLPT regime, not how you run a test.
- Contract-legal review → legal expertise. This skill helps with technical clause mapping (e.g. which exit criteria must be in the contract).
Approach
Seven phases, one per pillar plus scope determination and the verification-loop.
1. Scope determination
DORA Art 2 lists financial entities explicitly: credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, central securities depositories, central counterparties, trading venues, credit rating agencies, insurers/reinsurers, intermediaries, pension funds, crowdfunding, etc. Plus critical ICT third-party service providers (CTPPs) designated by the ESAs.
Reviewer checks:
- Does the organization fall under one of the explicit categories (Art 2(1))?
- Do proportionality exceptions apply (Art 4)? Microenterprises have lighter regimes for some requirements, not all.
- Does the organization deliver ICT services to EU financial entities? Then possibly third-party scope, including possible CTPP designation under the ESA oversight framework.
- Is there overlap with NIS2? In principle DORA applies as lex specialis; see Art 1(2) for the exception. NIS2 keeps applying for the parts not covered by DORA.
2. Pillar 1 — ICT Risk Management (Art 5–14)
Governance and framework requirements. Core elements:
- Art 5 Governance: the management body is ultimately responsible, must approve the ICT risk-management framework and oversee it, and must have sufficient ICT expertise. Annual review required.
- Art 6 ICT risk-management framework: written, approved, roles/responsibilities named, budget allocated, audit trail for decisions.
- Art 7–9 Identification + protection: ICT-asset inventory, classification, periodic risk assessment plus on changes, info-security controls (access, segmentation, encryption, data integrity).
- Art 10–13 Detection + response + recovery: anomaly detection, logging, incident-response plan, business-continuity plan with RTO/RPO targets, recovery testing, backup strategies.
- Art 14 Lessons learned: post-incident review required, findings flow back into the framework.
Mapping: ISO 27001:2022 Annex A largely covers Art 6-13. NIST CSF 2.0 covers the full span. Use your existing framework as a base and map specifically to DORA articles for the gap analysis.
3. Pillar 2 — Incident Reporting (Art 17–23)
Three-stage reporting comparable to NIS2, but with its own thresholds and regime:
- Classification (Art 18): a major ICT-related incident when criteria from the RTS are exceeded (number of customers affected, duration, geographic impact, reputational impact, data impact, financial impact). The
[RTS on classification of major ICT-related incidents] (Commission Delegated Regulation that sets the thresholds): verify the current version.
- Initial notification: within 4 hours of classification as major, and at the latest 24 hours after first detection of the incident. Different from NIS2 (24h early-warning), shorter.
- Intermediate report: within 72 hours of the initial, with more detail.
- Final report: within one month, with root cause, impact, and lessons learned.
Reporting goes to the competent authority (NL: DNB for banks/payment institutions/e-money, AFM for trading venues/investment firms/crowdfunding, etc.). The ESAs receive aggregate data.
Additionally: significant cyber-threat reporting (voluntary, Art 19). Despite "voluntary" in the text, in practice this is a peer-pressure question: if your peers report, not reporting stands out.
4. Pillar 3 — Digital Operational Resilience Testing (Art 24–27)
Two levels:
- Basic testing (Art 25): required for all in-scope entities. Annually, via assessment methodologies: vulnerability assessments/scans, penetration tests, source-code reviews, network security assessments, scenario-based tests. Independent internal or external testers.
- Threat-Led Penetration Testing (TLPT, Art 26–27): required for "significant" entities (designated by the ESAs based on systemic importance + size). Three-yearly testing with red-teaming against production-critical functions. Follows the TIBER-EU framework or equivalent national counterpart (in NL: TIBER-NL under DNB). Testers must be accredited (CREST, CBEST, TIBER-certified).
TLPT process (high level):
- Preparation: scope definition, threat intelligence, test plan, coordination with the national TIBER office.
- Testing: red team performs an attack against production-critical functions, with limited blue-team awareness ("white team" of insiders facilitates).
- Closure: debrief, remediation plan, attestation to the competent authority.
See recon-agent, c2-hygiene, post-exploit, pentest-reporter for execution. This skill describes only the regime.
5. Pillar 4 — ICT Third-Party Risk Management (Art 28–30)
Probably the most operational impact for most financial entities, because it touches every contract.
- Art 28 ICT third-party strategy: a document containing criteria for selection, due diligence, contract management, exit.
- Art 28(3) Register of information: a machine-readable register of all contracts with ICT third parties, to be filed with the competent authority. Format standardized via an ITS (Implementing Technical Standard). Contains: provider identification, service description, contract key data, data processed, sub-outsourcing, concentration metrics.
- Art 29 Pre-contractual assessment: due diligence on the supplier: risk assessment, data locality, sub-outsourcing chain, concentration risk.
- Art 30 Contract clauses (mandatory elements):
- Full description of functions + service levels.
- Location where data is processed plus the provider's locality.
- Security obligations including notification on incidents.
- Assistance obligations for ICT incidents at the financial entity.
- Exit strategies with term and transition support.
- Access/audit rights for the financial entity and the competent authority.
- Termination rights under specific circumstances.
- Critical ICT Third-Party Providers (CTPPs): designated by the ESAs. Subject to a direct oversight framework (Art 31+). Both the CTPP and its financial customers have additional obligations.
Workflow for this skill: walk through the contract portfolio, check per contract whether all Art 30 elements are present, build/maintain the register of information, calculate concentration metrics (% of critical functions dependent on one provider).
6. Pillar 5 — Information Sharing (Art 45)
Voluntary exchange of cyber-threat information between financial entities, via trusted communities (ISACs). Not required, but explicitly permitted and legally protected: for organizations doubting whether sharing is legally allowed, DORA is the yes answer.
NL ISAC structure: FI-ISAC NL and sector-specific platforms. Operational coupling to threat-intel feeds (see ioc-hunter).
7. Verification-loop
Layer 1: scope (all in-scope entities included, including the group structure?), assumptions (RTS/ITS versions up to date?), gap analysis (all five pillars addressed without silent exclusions?). Layer 2: article numbers from regulation 2022/2554 correct, RTS/ITS references current (these are updated by the ESAs), NL supervisor split (DNB vs AFM) correct per activity type, TIBER-framework names correct.
Output
DORA compliance assessment — <entity>
Date: YYYY-MM-DD | DORA in force since: 2025-01-17
Scope:
Entity category (Art 2): <bank | insurer | ... | CTPP | n/a>
Proportionality: <full | lighter — rationale>
NL supervisor: <DNB | AFM | n/a>
Pillar 1 — ICT Risk Management:
Framework document: <present | gap>
Board approval + review: <date + cadence>
Asset inventory + classif: <coverage%>
Incident response plan: <present | gap>
BCP with RTO/RPO: <last tested: date | never>
Pillar 2 — Incident Reporting:
Classification procedure: <present | gap>
4h notification pipeline: <tested | never>
Authority contact: <DNB/AFM details on hand>
Pillar 3 — Resilience Testing:
Annual basic testing: <last: date, scope>
TLPT required?: <yes (significant) | no>
TIBER-NL trajectory status:<planned | executed | n/a>
Pillar 4 — Third-Party Risk:
Strategy document: <present | gap>
Register of Information: <complete | gaps: ...>
Contract clauses Art 30: <coverage% per element>
CTPP dependencies: <list of critical providers>
Concentration metrics: <% per critical function>
Pillar 5 — Info Sharing:
ISAC membership: <FI-ISAC NL | other | none>
Threat-intel pipeline: <active | passive | n/a>
Priorities:
<fix-now / fix-sprint / fix-quarter with DORA article ref>
Verification-loop: ...
References
Categories
