dora

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):

1. Preparation: scope definition, threat intelligence, test plan, coordination with the national TIBER office.
2. Testing: red team performs an attack against production-critical functions, with limited blue-team awareness ("white team" of insiders facilitates).
3. 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

• EU Regulation 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554. Primary text.
• ESAs Joint Committee — DORA implementation — https://www.esma.europa.eu/policy-activities/digital-finance/digital-operational-resilience-act-dora. All RTS/ITS publications collected.
• DNB — DORA page — https://www.dnb.nl/. Search for "DORA" for NL-specific expectations for banks/PSP/EMI.
• AFM — DORA — https://www.afm.nl/. For investment firms, trading venues, crowdfunding.
• TIBER-EU — https://www.ecb.europa.eu/paym/cyber-resilience/tiber-eu/html/index.en.html. Framework for TLPT.
• TIBER-NL — https://www.dnb.nl/voor-de-sector/tiber/. Dutch implementation of TIBER.
• EBA — DORA — https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience. EBA-specific guidance for banks.
• EIOPA — DORA — https://www.eiopa.europa.eu/digital-operational-resilience-act-dora_en. For insurers.
• Register of Information ITS — [verify current version via the ESAs website]. Template and required fields for Art 28(3).

Categories

• grc