DORA ICT Risk Management with Claude — Articles 5–16, Incident Classification and RTO

DORA: The ICT Risk Framework That Changes Everything for EU Finance

The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) is the most significant ICT regulatory framework to hit EU financial services since MiFID II. Fully applicable from January 17, 2025, it creates a single, binding operational resilience framework across the EU financial sector — banks, insurance companies, investment firms, payment institutions, crypto-asset service providers, and, critically, the ICT third-party providers that serve them. The penalties are material: Article 50 allows competent authorities to impose fines up to 1% of daily worldwide turnover for ongoing breaches.

DORA's structure is five pillars: ICT risk management (Articles 5–16), ICT-related incident management and reporting (Articles 17–23), digital operational resilience testing (Articles 24–27), ICT third-party risk management (Articles 28–44), and information sharing (Articles 45–49). This guide focuses on the first two pillars — the ones most teams are racing to implement — and how Claude accelerates the documentation and analysis work.

ICT Risk Management Framework: Articles 5–16

Article 5 requires the management body to define, approve, oversee, and bear ultimate responsibility for the ICT risk management framework. This is a deliberate design choice: DORA makes operational resilience a board-level accountability, not an IT function. Article 6 requires a comprehensive, documented, and internal ICT risk management framework — a written policy covering identification, protection, detection, response, and recovery.

ICT Asset Register (Article 8)

Article 8 requires financial entities to identify, classify, and document all ICT assets — hardware, software, data, and ICT services — that support business functions. The asset register must identify which assets support critical or important functions, creating the link between ICT and business continuity risk. This is often the most labor-intensive starting point for DORA implementation.

• "Build an ICT asset register template compliant with DORA Article 8. The register should capture: (1) asset ID and name, (2) asset type (hardware / software / data asset / ICT service / network), (3) owner (department and named individual), (4) function supported (which business process does this asset enable?), (5) criticality classification (critical function / important function / non-critical), (6) location (on-premises / cloud provider + region / SaaS vendor), (7) third-party dependency (vendor name, contract reference), (8) recovery time objective (how long can this asset be unavailable before business impact is material?), (9) last reviewed date. Pre-populate the template with example entries for: (a) core banking system, (b) payment processing middleware, (c) customer CRM (SaaS), (d) internal email system, (e) regulatory reporting database."
• "We have completed our ICT asset register and need to classify assets by criticality under DORA Article 8. Apply the classification criteria: a function is 'critical or important' if its disruption would materially impair the financial performance, or the soundness or continuity of services, of the financial entity. Classify these 8 systems: (1) Core banking platform (processes all customer transactions), (2) Risk calculation engine (runs overnight batch, 4-hour RTO acceptable), (3) HR payroll system, (4) Customer-facing mobile banking app, (5) Internal BI dashboard, (6) SWIFT messaging gateway, (7) AML transaction monitoring system, (8) Document management system (stores loan files). For each: classification (critical / important / non-critical), reasoning, and the DORA obligations that apply to each criticality tier."

ICT Risk Assessment and Tolerance (Articles 6, 8, 9)

Article 9 requires financial entities to identify and document ICT risks, assess their likelihood and potential impact, and define ICT risk tolerance levels. The risk tolerance must be aligned with the overall risk appetite approved by the management body. This creates a documented chain from board-level risk appetite to operational ICT risk thresholds.

• "Conduct an ICT risk assessment for the following scenario under DORA Articles 8–9. Asset: Payment Processing Gateway (critical function — all outgoing SEPA and SWIFT payments). Risk: Ransomware attack leading to system unavailability. Current controls: EDR on all endpoints, 24x7 SOC, immutable backups with 2-hour RTO. Threat likelihood: Medium (financial sector is targeted 3× more than other sectors per ENISA 2025). Business impact if unavailable 4 hours: €2.1M in delayed payments, regulatory reporting obligation under DORA Article 19 if disruption exceeds thresholds. Risk assessment output required: (1) inherent risk score, (2) control effectiveness rating, (3) residual risk score, (4) comparison to ICT risk tolerance (assume board-approved tolerance: no disruption to payment processing exceeding 2 hours), (5) treatment plan (accept / mitigate / transfer / avoid)."

ICT Incident Management: Articles 17–23

Major Incident Classification (Article 18)

Article 18 and the associated RTS on incident classification (published by ESAs in January 2024) define the criteria for classifying an ICT-related incident as a "major incident" triggering mandatory regulatory reporting. The classification criteria include: number of clients affected, geographic spread, duration, data losses, criticality of affected services, and reputational impact. Getting the classification right is critical — over-reporting creates regulatory noise; under-reporting creates enforcement exposure.

• "Classify the following ICT incident under DORA Article 18 and the ESAs' RTS on incident classification. Incident: A misconfiguration in our API gateway caused customer authentication failures for 3 hours on a Saturday afternoon. Affected: 12,400 retail banking customers (8% of our customer base) could not access mobile banking. No data was exfiltrated or modified. Customer service received 847 calls. No financial transactions were lost (transactions were queued and processed after restoration). No regulatory reporting thresholds for payment delays were breached. Assess against each major incident criterion: (1) number of clients/transactions affected (threshold: significant portion of client base or critical transactions), (2) geographic spread, (3) duration (threshold: varies by service type), (4) data losses, (5) reputational impact, (6) criticality of service. Conclusion: major incident or significant cyber threat? If major incident: draft the initial report for competent authority within 4 hours."
• "Draft a DORA major incident initial report (Article 19, 4-hour notification) for the following scenario: Our core banking system experienced a database failure at 09:14 CET. Payments processing was suspended for 2 hours 47 minutes. 74,000 customers were affected (unable to execute payments or view balances). €18.3M in SEPA credit transfers were delayed. The root cause was a storage controller firmware update that triggered a controller failover to a degraded state. System was restored using the standby database cluster at 12:01 CET. No data loss confirmed. The report must include: (a) entity identification, (b) incident description and timeline, (c) classification basis (major incident criteria met), (d) immediate impact assessment, (e) initial containment measures taken, (f) notification to other affected parties."

RTO/RPO Requirements and Business Continuity

Article 11 requires financial entities to set and test RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for ICT systems supporting critical functions. The RTO/RPO targets must be documented, approved, achievable with current capabilities, and tested annually through exercises. For most financial entities, the challenge is not setting the targets but proving the targets are achievable.

• "Build a DORA Article 11 RTO/RPO matrix for a mid-sized investment firm. Systems to cover: (1) Order Management System (OMS, critical — trading), (2) Portfolio Accounting System (daily NAV calculation), (3) Client Reporting Platform (quarterly statements), (4) Risk Analytics Engine (overnight batch), (5) Compliance Monitoring System (real-time trade surveillance), (6) Email and collaboration tools. For each system: (a) proposed RTO (1 hour / 4 hours / 8 hours / 24 hours / 72 hours), (b) proposed RPO (zero loss / 15 min / 1 hour / 4 hours / 24 hours), (c) current recovery capability vs. target (gap analysis), (d) test method (failover test / tabletop / restore test), (e) DORA Article 11 compliance status. Justify RTO/RPO choices against the DORA requirement that targets must be appropriate for the function's criticality."

TLPT: Threat-Led Penetration Testing (Articles 24–27)

Articles 24–27 require significant financial entities (designated by competent authorities based on systemic importance) to conduct Threat-Led Penetration Testing (TLPT) — the EU's implementation of the TIBER-EU framework — at least every three years. TLPT involves an intelligence-led assessment of the entity's defenses against realistic threat actor TTPs (Tactics, Techniques, and Procedures). Claude can help scope TLPT engagements and analyze the resulting findings.

• "Help me scope a DORA TLPT engagement for a retail bank. Under DORA Article 25, the scope must cover at least the critical functions identified in the ICT asset register. Our critical functions are: (1) payment processing, (2) customer authentication and identity, (3) core banking transaction processing, (4) AML transaction monitoring. The TLPT will use the TIBER-EU framework. Describe: (1) what threat intelligence the red team will need (sector-specific TTPs from ENISA, FS-ISAC, Mandiant threat intelligence), (2) which systems should be in scope for red team testing vs. blue team awareness testing, (3) the key deliverables (threat intelligence report, red team test plan, final report with remediation roadmap), (4) how findings are reported to the competent authority under DORA Article 26."

Where to Start

For most financial entities, DORA implementation priority order is: (1) ICT asset register — you can't manage what you haven't mapped; (2) major incident classification framework — the 4-hour reporting clock starts immediately when a major incident occurs, so the classification criteria must be operationalized before an incident happens; (3) ICT risk assessment against tolerance — board sign-off required; (4) RTO/RPO targets and testing — most entities have informal targets but haven't documented or tested them to the DORA standard. The Third-Party Vendor Risk guide covers DORA Articles 28–44 (ICT third-party risk management), which is the most complex pillar for firms with large vendor ecosystems.