Claude AI for DORA Compliance: ICT Risk Management, Incident Reporting, and Third-Party Oversight for EU Financial Firms (2026)

Claude for DORA Compliance

The Digital Operational Resilience Act (DORA — Regulation EU 2022/2554) has applied to all EU financial entities since January 17, 2025. That deadline passed — which means for banks, investment firms, insurers, payment institutions, and crypto-asset service providers operating in the EU, DORA compliance is not a future project. It's an ongoing operational requirement with teeth: EBA, ESMA, and ECB supervisors are now assessing compliance, and the Joint ESAs Oversight Framework for Critical ICT Third-Party Providers (CTPPs) began its first designation cycle in 2025.

Most institutions completed their initial DORA gap assessments and implementation projects. The ongoing challenge is different: maintaining the ICT risk management framework as systems evolve, classifying incidents under the DORA threshold tests correctly, managing the contractual requirements for ICT third-party providers as contracts renew, and preparing for TLPT (threat-led penetration testing) for institutions that meet the designation criteria. Claude handles the documentation layer across all five DORA pillars.

ICT Risk Management Framework Documentation

DORA Article 6 requires a comprehensive and documented ICT risk management framework. It must be reviewed annually, approved by the management body, and cover the six components: ICT risk identification and classification, protection and prevention measures, detection, response and recovery, learning and evolving, and communication. For many institutions, the framework document exists but hasn't been updated to reflect organizational changes, new systems, or lessons from operational incidents. Claude rebuilds or updates the framework documentation from current state inputs.

• "DORA ICT Risk Management Framework gap assessment: Our institution is a mid-sized EU investment firm (MiFID II regulated, ~€2B AUM). We completed our initial DORA implementation in Q4 2024 and have an ICT risk management framework document. The document was approved by the Board in December 2024. Since then: (1) we migrated our core portfolio management system from on-premise to a cloud provider (AWS) in March 2025, (2) we onboarded a new fintech data vendor for alternative data, (3) we experienced one significant ICT incident (trading system outage, 4 hours, reported to the FCA in our UK branch). Assess our DORA ICT risk management framework against Article 6 requirements: (1) which components of the framework need updating for the cloud migration? (2) does the new data vendor need to be classified as an ICT third-party provider under DORA Article 28? (3) what lessons-learned obligations apply following the trading system incident? (4) what needs to be included in the next annual Board review?"
• "DORA Article 9 ICT Security Policy documentation: Draft the ICT security policy section required under DORA Article 9(2) for an EU bank with 450 employees and 12 branch offices. The policy must cover: (a) policies for information security, (b) ICT access management and privileged access controls, (c) change management, (d) patch and update management, (e) backup and recovery (including the specific DORA requirements: multiple copies, different locations, tested recovery time), (f) cryptography and encryption, (g) ICT-related physical security. Draft the policy in the format suitable for annual Board approval, with specific reference to DORA Article 9(2) sub-clauses. Flag any areas where we would need to specify our actual technical standards (these will be placeholders for the institution to fill in)."
• "DORA business continuity and disaster recovery documentation: Our institution must document recovery time objectives (RTO) and recovery point objectives (RPO) under DORA Article 12. Critical business functions identified: (1) trading execution — RTO 1 hour, RPO 15 minutes. (2) client reporting — RTO 4 hours, RPO end of prior day. (3) settlement operations — RTO 2 hours, RPO 1 hour. (4) regulatory reporting — RTO 8 hours, RPO end of prior day. We have tested recovery for trading execution (achieved in 52 minutes in the last test). Client reporting and settlement have not been tested in 18 months. Draft the DORA-compliant BCP/DR documentation for these four functions, including: function criticality classification, RTO/RPO documentation, backup system description, recovery test schedule and last test results, and the gap analysis for untested functions."

ICT Incident Classification and Reporting

DORA Article 18-20 establish a classification framework for ICT incidents and a mandatory reporting timeline for "major ICT incidents." The classification requires testing against five criteria: clients affected, duration, geographic spread, reputational impact, and criticality of affected services. Getting the classification wrong has real consequences: under-reporting a major incident is a regulatory violation; over-reporting creates examination scrutiny. The initial notification to the competent authority must be submitted within 4 hours of classification as a major incident — which is not much time to draft a structured regulatory submission.

• "DORA major incident classification test: Our bank experienced a core banking system outage starting at 09:15 CET on a Tuesday. The outage lasted 3 hours and 47 minutes (resolved 13:02 CET). Impact: (1) retail online banking unavailable for all 285,000 customers during the outage window. (2) Branch transactions processed manually with 30-60 minute delays. (3) ATM network operational (third-party managed). (4) No data loss confirmed. (5) No financial loss to customers (no payments missed their value date). (6) Media coverage: 3 local news stories, one national financial newspaper article. (7) Social media: 1,200 complaints on Twitter/X during the outage. Apply the DORA Article 18 classification criteria: (a) number of clients affected and whether it meets the 'significant number' threshold, (b) duration — does 3h47m meet the major incident threshold for our institution type? (c) reputational impact — does national press coverage constitute significant reputational impact? (d) geographic spread — are all clients in one member state? (e) our supervisory authority: we are regulated by BaFin. Does this incident qualify as a major ICT incident requiring mandatory reporting?"
• "DORA major incident initial notification draft: The above incident has been classified as a major ICT incident. We must submit an initial notification to BaFin within 4 hours of classification (which occurred at 13:45 CET when the incident management team completed the classification assessment). Draft the DORA Article 19 initial notification, which per the EBA ITS must include: (1) incident reference number, (2) date and time of detection and classification, (3) nature of the incident — root cause if known or preliminary assessment, (4) impact assessment — services affected, clients affected, financial impact if any, (5) containment and recovery measures taken and planned, (6) estimated recovery time, (7) cross-border impact (do we have clients in other member states?), (8) contact person details. Use professional regulatory language. The notification must be fact-based and not speculative."
• "DORA incident register requirements: Under DORA Article 17, we must maintain an ICT-related incident register. Design the incident register template and classification taxonomy. The register must capture: incident reference, detection date/time, classification (minor/major/significant cyber), affected services, root cause category (from the EBA taxonomy), financial impact, number of clients affected, notification status, and lessons learned. We have 12 incidents to log this year, ranging from a 2-minute database timeout to the core banking outage. Build the register structure and show how to classify each of these 3 incidents: (A) 2-minute database timeout, no client impact, auto-recovered. (B) 6-hour outage of the mobile banking app, 45,000 clients affected, no data loss. (C) Ransomware attack attempt, blocked by perimeter controls, no breach, 0 clients affected."

ICT Third-Party Risk Management

DORA's third-party requirements (Articles 28–44) are among the most operationally complex. Every contractual arrangement with an ICT third-party provider must be assessed; those supporting critical or important functions must meet enhanced contractual requirements. The contracts must include exit strategies, audit rights, data portability clauses, SLA specifications, and security standards. The Oversight Framework for Critical ICT Third-Party Providers (CTPPs) adds a further layer for the largest cloud providers and data vendors. Claude reviews contract language against DORA requirements and drafts the missing clauses.

• "DORA ICT third-party contract gap analysis: We have a cloud infrastructure contract with a major hyperscaler (supporting our core banking application — a critical function). The current contract was signed in 2022 and has not been updated for DORA. Review the following contract excerpts against DORA Article 30 mandatory contractual requirements: [describe key contract terms — e.g., SLA uptime 99.95%, 30-day termination for convenience, annual security audit right, data return within 60 days of termination, no specific BCDR testing obligation]. For each DORA Article 30 requirement: (1) is it present in the contract? (2) is it DORA-compliant or does it need strengthening? (3) draft the replacement clause language that would satisfy DORA. Prioritize: exit strategy and termination assistance, audit rights, sub-outsourcing consent requirements, and BCDR testing obligations."
• "DORA critical or important function assessment: We use 47 ICT third-party providers. I need to identify which ones support 'critical or important functions' (CoIF) under DORA Article 3(22). Our function register shows these functions: (1) Core banking system hosted by Provider A (on-premise). (2) Payment processing by Provider B (SaaS). (3) HR system by Provider C (SaaS). (4) Customer analytics by Provider D (data processor). (5) Backup data storage by Provider E (cloud). (6) Email and collaboration tools by Provider F. (7) Market data feed by Provider G. (8) Regulatory reporting by Provider H. For each provider: (a) is the supported function critical or important? Apply the three-factor test: substitutability, scale, and systemic importance. (b) what DORA enhanced requirements apply to CoIF providers? (c) do any of these providers likely qualify as a CTPP (Critical Third-Party Provider) under the ESAs joint oversight framework?"

TLPT Scoping and Documentation

Threat-Led Penetration Testing (TLPT) under DORA Article 26 is mandatory for significant institutions designated by their competent authority. It differs from standard penetration testing in that it must be intelligence-led (based on current threat intelligence for the specific institution), cover production systems (not just test environments), and use testers meeting the TIBER-EU qualification standards. The scoping exercise — defining what is in scope, what intelligence feeds are used, and what the threat scenario covers — requires structured documentation that satisfies the framework.

• "TLPT scoping document for a medium-sized EU bank: We have been notified by ECB that we meet the TLPT designation criteria and must conduct a TLPT within 18 months. We have never conducted a TLPT under DORA/TIBER-EU. Our critical systems include: core banking (on-premise, IBM), mobile banking app (AWS-hosted), SWIFT connectivity hub (on-premise), FX trading platform (third-party, Bloomberg terminal), and regulatory reporting system (SaaS). Help me draft the TLPT scope document, which must include: (1) in-scope critical systems and rationale for each, (2) out-of-scope systems and exclusion rationale, (3) threat intelligence provider selection criteria (what qualifies as a TIBER-EU accredited TI provider?), (4) Red Team provider qualification requirements, (5) what is the 'Purple Team exercise' at the end of TLPT and what does it involve, (6) timeline from scoping to completion for an 18-month window."

Where to Start

The AML & RegTech and Compliance & Risk categories have templates designed for EU regulatory workflows. For DORA compliance officers doing the annual framework review, the ICT Risk Management Framework Assessment template gives you the gap analysis against current DORA Article 6 requirements. For institutions dealing with an active incident, the Incident Classification and Notification Drafting template produces compliant initial notifications within the 4-hour window — the most time-critical DORA compliance task. All templates work in Claude.ai Pro — paste the system prompt into a Claude Project and use it across your DORA compliance program.