DORA Architecture Diagrams: Documenting ICT Resilience for EU Financial Compliance (2026)

The EU's Digital Operational Resilience Act (DORA) entered full enforcement in January 2025, placing approximately 22,000 financial entities — banks, insurers, investment firms, crypto-asset service providers, and their critical ICT third-party service providers — under binding obligations for ICT risk management, incident reporting, resilience testing, and vendor oversight. Architecture diagrams are not optional documentation under DORA; they are the primary evidence artifact that competent authorities use to assess whether an entity's ICT risk management framework (Articles 5–16) is implemented in practice. This guide explains which diagrams DORA requires, what each must show, and how to generate audit-ready diagrams quickly using AI.

DORA's five pillars and where architecture diagrams apply

• ICT risk management (Articles 5–16): Requires a comprehensive ICT reference architecture covering all systems supporting critical or important functions (CIFs), network topology, access controls, and encryption. This is the most documentation-heavy pillar.
• ICT-related incident management (Articles 17–23): Requires documented incident classification flows, escalation paths to management and competent authorities, and reporting timelines (initial report within 4 hours of major incident classification, intermediate report within 72 hours, final report within 1 month).
• Digital operational resilience testing (Articles 24–27): Basic testing annually for all entities; Threat-Led Penetration Testing (TLPT) every 3 years for significant entities. TLPT scope diagrams must delineate which production systems are in scope and how red team activities are contained.
• ICT third-party risk management (Articles 28–44): Requires a complete register of all ICT third-party service providers, with criticality classification and contractual obligations documented. Architecture diagrams must show data flows to and from each critical ICT third party (CITSP).
• Information sharing (Article 45): Voluntary; no architecture diagram required, but participation in threat intelligence sharing arrangements should be reflected in your monitoring architecture.

Core architecture diagrams DORA assessors expect

• ICT reference architecture: The foundational diagram. Shows all systems supporting critical or important functions (CIFs), grouped by business domain (payments, trading, custody, reporting). Each system must be annotated with its classification (CIF-supporting or not), hosting model (on-premise, cloud, colocation), and the ICT third-party provider responsible for it. Network segmentation between domains, internet-facing perimeters, and internal trust zones must be explicit.
• Business continuity and disaster recovery architecture: Documents RTO/RPO targets for each CIF, primary and secondary site configurations, failover mechanisms (active-active vs active-passive), backup schedules, and the geographic distribution of recovery sites. DORA Article 11 requires that recovery capabilities be tested and documented.
• TLPT scope diagram: A scoped network diagram identifying which production systems are included in the Threat-Led Penetration Test. Must show the threat intelligence boundary (what the red team knows in advance), the containment perimeter (blast radius limit), and the systems explicitly excluded from TLPT scope. Required for significant entities under Article 26.
• Incident detection and reporting flow: A process flow showing how ICT incidents are detected (SIEM alerts, anomaly detection, user reports), classified (major vs non-major per DORA RTS criteria), escalated internally (IT → CISO → Executive → Board), and reported externally (competent authority, ENISA, payment scheme operators). Timelines at each node.
• ICT third-party vendor map: A landscape diagram of all ICT third-party service providers, showing which internal systems depend on each vendor, data flows crossing vendor boundaries, criticality tier (critical vs non-critical), and contractual exit strategy indicators. DORA Article 30 requires exit plans for all critical ICT third parties.
• Three Lines Model governance diagram: Shows the ICT risk governance structure: First Line (ICT operations, business units), Second Line (risk management function, CISO), Third Line (internal audit). Maps each DORA article obligation to the responsible line and escalation path to the management body.

Prompt examples for DORA architecture diagrams

ICT reference architecture for a payment institution

Business continuity and disaster recovery architecture

Incident detection and reporting flow

ICT third-party vendor map

DORA vs other EU financial regulations: diagram scope

DORA documentation checklist for architecture artifacts

• Asset inventory alignment: Every system in your architecture diagram must correspond to an entry in your ICT asset register (Article 8). Auditors cross-reference the two artifacts — gaps indicate undocumented shadow IT.
• CIF labeling: Clearly distinguish systems supporting critical or important functions from non-CIF systems. DORA applies stricter controls to CIF-supporting systems; unlabeled diagrams create ambiguity about which controls apply.
• Network segmentation evidence: Article 9 requires that network connections from CIF systems to non-CIF systems and internet be explicitly controlled. Architecture diagrams must show firewall or security group boundaries, not just logical connections.
• Third-party data flows: Every data exchange crossing a CITSP boundary must be annotated with data classification, encryption method, and whether the CITSP has sub-processors (Article 30.2 sub-outsourcing visibility requirement).
• Version control and review dates: DORA Article 6 requires ICT risk documentation to be reviewed at least annually and after major incidents. Diagrams must carry a version number, review date, and approving officer name.
• Article cross-references: Annotate each architectural layer or control with the specific DORA article and RTS/ITS provision it evidences. This dramatically shortens supervisory examination time and demonstrates awareness of regulatory intent.

Related guides: fintech architecture diagrams, disaster recovery architecture, NIS2 architecture diagrams, and zero-trust architecture diagrams.