DORA Compliance Architecture: Mapping the 5 Pillars to Your ICT Stack (2026)

The Digital Operational Resilience Act (DORA) became mandatory across the EU in January 2025, applying to banks, insurers, investment firms, payment institutions, crypto-asset service providers, and their critical ICT suppliers. Unlike previous guidance that treated operational resilience as a risk management checkbox, DORA introduces binding technical requirements: documented ICT risk frameworks, regulated incident reporting timelines, mandatory resilience testing for significant entities, structured third-party oversight, and formal threat intelligence sharing arrangements. Non-compliance exposes firms to supervisory sanctions and, in some jurisdictions, individual liability for senior management.

For fintech engineering and compliance architecture teams, DORA means building and documenting specific ICT controls — not just asserting that they exist. Yet almost no visual architecture resources exist for this regulation: the authoritative sources are dense regulatory PDFs and regulatory technical standards (RTS) published by the European Supervisory Authorities. This post fills that gap. Below you will find each of DORA's five pillars translated into concrete ICT components, AI diagram prompt templates you can drop into ArchitectureDiagram.ai, and a comparison table showing what changes between a pre-DORA and a DORA-compliant architecture.

DORA's five pillars as architecture domains

DORA organises its requirements into five distinct pillars. Each pillar maps to a recognisable architecture domain, making it possible to draw clear boundaries between compliance areas in a diagram.

• Pillar 1 — ICT Risk Management: A documented, board-approved risk framework covering asset inventory, threat and vulnerability management, network segmentation, backup and recovery, and business continuity. Think of this as your baseline security and resilience architecture that must be formally governed.
• Pillar 2 — ICT-Related Incident Reporting: A detection-to-regulator pipeline: SIEM, endpoint detection, anomaly detection, severity classification, and automated reporting workflows that can meet DORA's strict timelines (4-hour initial report, 72-hour detailed report, 30-day final report to competent authority).
• Pillar 3 — Digital Operational Resilience Testing (TLPT): Threat-led penetration testing, red team / blue team integration, chaos engineering pipelines, disaster recovery runbooks, and an annual testing calendar. Significant financial institutions must engage approved external TLPT providers.
• Pillar 4 — Third-Party ICT Risk Management: An ICT vendor register, due diligence workflows, contractual requirements tracking, concentration risk dashboards mapping single-vendor dependencies, and documented exit strategies for critical ICT providers.
• Pillar 5 — Information and Intelligence Sharing: Participation in threat intelligence sharing arrangements (TIBER-EU, FS-ISAC), structured feeds from the European Union Agency for Cybersecurity (ENISA), and internal tooling to ingest, correlate, and act on shared indicators of compromise.

Pillar 1: ICT risk management architecture

The ICT risk management pillar is foundational — regulators will look here first. DORA Article 6 requires financial entities to implement and maintain a robust ICT risk management framework that is reviewed at least annually and approved at board level. The architecture to support this touches several systems.

Key components

• ICT asset inventory (CMDB): A configuration management database tracking all hardware, software, network devices, cloud resources, and data assets. Under DORA, the inventory must also capture dependencies between assets and link each asset to the business functions it supports. Tools like ServiceNow CMDB, Snipe-IT, or cloud-native asset inventories (AWS Config, Azure Resource Graph) are typical implementations.
• Threat and vulnerability management: Continuous CVE scanning (Tenable Nessus, Qualys, Wiz, Snyk) integrated with a ticketing system for remediation SLA tracking. DORA requires documented patch management processes with defined timelines for critical vulnerabilities.
• Network segmentation controls: Firewall rule sets, micro-segmentation policies (zero-trust network access), and network access control (NAC) documented with topology diagrams. Regulators specifically look for isolation of critical production systems from development and test environments.
• Backup and recovery (RTO/RPO targets): Automated backup pipelines (daily full, continuous incremental), immutable off-site storage, and tested recovery procedures. DORA requires RTO and RPO targets to be defined per system criticality tier and tested at least annually.
• Business continuity plan (BCP): Documented crisis management procedures, communication trees, and alternate site arrangements. The BCP must reference the ICT architecture and be exercised through tabletop tests or live drills.

The critical governance requirement here is board-level sign-off. DORA Article 5 makes the management body directly responsible for the ICT risk framework, meaning your architecture documentation must be accessible to, and approved by, non-technical senior leadership — not just the CISO.

AI prompt: ICT risk management architecture diagram

Pillar 2: Incident detection and reporting pipeline

DORA's incident reporting pillar (Articles 17–23) introduces one of the most operationally demanding requirements: regulated timelines for notifying competent authorities after a major ICT incident. Missing these deadlines is itself a compliance failure, independent of the underlying incident. Your architecture must make fast, accurate classification and escalation possible.

Reporting timeline

• Initial notification — 4 hours: Submit to the relevant competent authority (EBA for banks, ESMA for investment firms, EIOPA for insurers) within 4 hours of classifying an incident as "major." This report is high-level: impact scope, estimated cause, and initial containment steps.
• Intermediate report — 72 hours: A detailed report covering confirmed root cause, affected systems, number of clients impacted, financial impact estimate, and remediation status.
• Final report — 30 days: A comprehensive post-incident analysis including lessons learned, permanent fixes implemented, and updated risk assessment.

Architecture components

• SIEM (Splunk / Microsoft Sentinel / Elastic): Centralised log aggregation and correlation engine. Under DORA, log retention policies must be documented and the SIEM must ingest events from all critical ICT systems. Correlation rules should map directly to DORA's major incident classification criteria.
• Endpoint detection (EDR): CrowdStrike Falcon, Microsoft Defender for Endpoint, or SentinelOne deployed across all managed endpoints, feeding alerts into the SIEM.
• Anomaly detection: ML-based user and entity behaviour analytics (UEBA) — Exabeam, Darktrace, or built-in SIEM capabilities — to surface novel threats that signature-based rules miss.
• Severity classification engine: An automated or semi-automated triage workflow (typically in a SOAR platform like Palo Alto XSOAR or Splunk SOAR) that evaluates each alert against DORA's major incident criteria: number of clients affected, transaction volume impacted, geographic spread, and reputational significance.
• Regulatory reporting pipeline: A templated report generation system — often a GRC tool integration or a custom workflow — that pre-populates the EBA/ESMA/EIOPA reporting forms and tracks submission deadlines. Some firms integrate this with their incident management platform (PagerDuty, ServiceNow) so the clock starts automatically when an incident is escalated.

AI prompt: incident detection and reporting pipeline

Pillar 3: Resilience testing architecture

DORA mandates a digital operational resilience testing programme for all in-scope entities (Articles 24–27), with more stringent requirements for Significant Financial Institutions (SFIs). For SFIs, this includes Threat-Led Penetration Testing (TLPT) — an advanced form of red team exercise that simulates realistic threat actor techniques against live production systems.

TLPT requirements for significant financial entities

TLPT must be conducted at least every three years by approved external providers using the TIBER-EU framework methodology. Unlike conventional penetration tests, TLPT targets critical functions in a live environment, requires the full participation of the blue team, and must result in a formal attestation submitted to the competent authority.

• Red team / blue team integration: Your architecture should show how the red team's command-and-control (C2) infrastructure interfaces with production systems, and how the blue team's detection tooling (SIEM, EDR, network monitoring) is scoped for the exercise. Purple team review sessions should be documented as a formal step.
• Chaos engineering: Tools like Chaos Monkey (Netflix OSS), LitmusChaos (CNCF), or AWS Fault Injection Simulator inject controlled failures — instance terminations, network partitions, latency spikes — to validate that recovery automation and runbooks work as designed. Results feed back into the ICT risk framework.
• Disaster recovery runbooks: Version-controlled, step-by-step recovery procedures stored in a document management system accessible during an outage (i.e., not hosted solely on the system being recovered). Runbooks must reference specific RTO and RPO targets.
• Annual testing calendar: A governance artefact tracking all planned tests (penetration tests, DR drills, tabletop exercises, chaos experiments) with assigned owners, scheduled dates, and links to prior test results. Regulators may request this during supervisory review.

Pillar 4: Third-party ICT risk architecture

DORA's third-party risk pillar (Articles 28–44) targets a specific systemic risk: the financial sector's heavy dependence on a small number of critical ICT providers — hyperscale cloud providers, core banking vendors, and payment processors. The regulation requires firms to map, monitor, and plan exit strategies for every material ICT dependency.

Critical vs. non-critical classification

Not all vendors require the same oversight. DORA requires firms to classify each ICT third-party arrangement as supporting a critical or important function (CIF) or not. CIF arrangements require enhanced contractual provisions, more frequent audits, and documented exit strategies. The classification must be reviewed when the vendor or the function changes.

Architecture components

• ICT vendor register: A structured registry — typically maintained in a GRC platform (Archer, ServiceNow GRC, OneTrust) or a dedicated third-party risk management (TPRM) tool — capturing each ICT vendor, the functions they support, their CIF classification, contract expiry, audit schedule, and sub-contractor dependencies. DORA requires this register to be kept current and submitted to the competent authority on request.
• Due diligence workflow: A standardised onboarding process for new ICT vendors that includes security questionnaires (aligned to ISO 27001 or CSA CAIQ), contractual review against DORA's mandatory clauses (Articles 30), and a sign-off gate before live access is granted.
• Contractual requirements checker: DORA Article 30 specifies minimum contractual provisions for CIF arrangements: audit rights, incident notification obligations, SLA targets, sub-contracting disclosure, and data portability on exit. A checklist or GRC workflow ensures every CIF contract is verified against these requirements before execution and at each renewal.
• Concentration risk dashboard: A visualisation of single-vendor exposure across the ICT estate — for example, the percentage of critical functions dependent on a single cloud provider. DORA specifically requires firms to assess concentration risk, and supervisors are monitoring sector-wide concentration on hyperscale cloud. A dependency graph or heatmap updated quarterly is the typical architecture artefact.
• Exit strategy documentation: Documented transition plans for each CIF vendor: alternative providers identified, data portability verified, migration runbooks drafted, and estimated migration duration. Exit strategies must be tested — at minimum through tabletop exercises — to confirm they are executable within an acceptable timeframe.

AI prompt: full DORA compliance architecture (all five pillars)

Pillar 5: Information and intelligence sharing

Pillar 5 (Articles 45–49) encourages — and in some cases formalises — the sharing of cyber threat intelligence between financial entities and with public authorities. The key frameworks are TIBER-EU (the ECB's threat intelligence-based ethical red teaming framework), FS-ISAC (Financial Services Information Sharing and Analysis Center), and ENISA's threat landscape publications.

• Threat intelligence platform (TIP): An internal platform — MISP (open source), OpenCTI, or a commercial TIP — that ingests indicators of compromise (IoCs) from shared feeds, enriches them with internal context, and exports actionable detections to the SIEM. The TIP is the hub that connects Pillar 5 to Pillar 2.
• TIBER-EU integration: For entities conducting TLPT under the TIBER-EU framework, the Threat Intelligence Provider (TI provider) feeds a targeted threat intelligence report into the TLPT process. This requires a structured handoff between the TIP and the TLPT red team — document this as an explicit architecture interface.
• ISAC and ENISA feeds: FS-ISAC membership provides STIX/TAXII feeds of financial-sector-specific threat intelligence. ENISA publishes its Threat Landscape report annually and maintains CERT-EU advisories. These should be automated ingestion sources into the TIP rather than manual review processes.

Pre-DORA vs. DORA-compliant architecture comparison

The table below summarises the most significant architectural differences between a typical pre-DORA financial institution ICT setup and a DORA-compliant one. Use it to identify gaps in your current architecture.

Frequently asked questions

What is DORA and who does it apply to?

DORA — the Digital Operational Resilience Act (EU 2022/2554) — is an EU regulation that became mandatory in January 2025. It applies to financial entities authorised or registered in the EU, including credit institutions (banks), payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers (CASPs), central counterparties, and trade repositories. It also applies — as supervised "critical ICT third-party service providers" (CTPPs) — to cloud providers, data analytics vendors, and other ICT suppliers that are deemed critical to the financial system by the European Supervisory Authorities.

What is the difference between DORA and GDPR for architecture purposes?

GDPR is a data protection regulation focused on personal data: lawful basis for processing, data subject rights, breach notification (72 hours to the supervisory authority), and data minimisation. Your GDPR architecture centres on data flows, consent management, encryption at rest and in transit, and privacy-by-design patterns.

DORA is an operational resilience regulation focused on ICT systems: their continuity, integrity, and recoverability. Your DORA architecture centres on system availability, incident detection pipelines, vendor dependency mapping, and resilience testing. The two regulations overlap in incident reporting — a ransomware attack affecting personal data triggers both GDPR Article 33 (72-hour breach notification) and DORA Article 19 (4-hour initial incident notification) simultaneously.

How do I diagram DORA compliance architecture?

The most effective approach is to structure your diagram around DORA's five pillars as swim lanes or bounded domains, then populate each with the concrete ICT systems and data flows that implement that pillar's requirements. Use the AI prompt templates in this post as starting points — paste them into ArchitectureDiagram.ai and refine the output to match your specific stack. Keep your diagrams as living documents: version-control them alongside your infrastructure-as-code so they stay current as the architecture evolves. Regulators and auditors are sceptical of diagrams that look too polished and too static — they want evidence that the documentation reflects the real system.

What counts as a "major ICT incident" under DORA?

DORA Article 18 and the associated RTS (published by the Joint Committee of the European Supervisory Authorities) define major ICT incidents using a multi-criteria threshold. An incident is "major" if it meets at least one of the following: it affects more than a defined number of clients or counterparties; it causes the unavailability of a critical or important function for longer than a defined duration; it has a financial impact above a defined threshold; it causes reputational or geopolitical significance; or it involves a data integrity breach affecting critical data. The exact thresholds vary by entity type and are set out in the Commission Delegated Regulations supplementing DORA. Your SOAR severity classification logic should be configured to evaluate each of these criteria automatically when an alert is escalated.

Related architecture guides

• Zero Trust Architecture Diagram: A Complete Guide — the network segmentation and identity-aware access controls required by DORA Pillar 1 are most cleanly implemented using zero-trust patterns.
• SOC 2 Architecture Diagrams: What Auditors Actually Look For — SOC 2 Type II covers many of the same controls as DORA's ICT risk management pillar; a SOC 2 report can support DORA compliance evidence.
• CMMC Architecture Diagrams: Mapping Controls to Your Tech Stack — useful reference for security control mapping methodology, applicable to DORA's risk management and incident response requirements.
• EU AI Act Compliance Architecture: What Engineers Need to Know — for firms using AI in trading, credit decisioning, or fraud detection, the EU AI Act and DORA requirements interact: AI systems must meet DORA resilience requirements as well as AI Act risk management obligations.