Dashboard Academy Control templates DORA
Public Beta. Reference implementation only — not a compliance certification, attestation, or audit outcome. Read the full beta disclaimer →

Control template: DORA (Digital Operational Resilience Act)

Status: Public Beta · Version: dora/v0.1.0-beta

A bundle of CALM control snippets covering the architecturally enforceable subset of the EU's Digital Operational Resilience Act (Regulation (EU) 2022/2554). DORA became mandatory for in-scope financial entities on 17 January 2025. You copy these into your *.calm.json files on the nodes that participate in your ICT service estate.

Who DORA applies to

DORA Art. 2 in-scope entities include: - Credit institutions, payment institutions, e-money institutions - Investment firms, asset managers, UCITS/AIFMD managers, central securities depositories - Insurance and reinsurance undertakings - Crypto-asset service providers - Critical third-party providers (CTPPs) designated by the ESAs (typically major cloud providers)

If your firm is in-scope, your ICT services are too. If you're not sure, talk to your compliance team — we don't make that call.

What this template covers

DORA's 5 pillars are governance + risk + testing + third-party + information-sharing. The architecturally enforceable subset is roughly 10 controls below:

DORA Pillar Architectural surface Control alias
1 — ICT risk management ICT asset inventory dora-ict-inventory
1 — ICT risk management Critical-function identification dora-critical-function
1 — ICT risk management Encryption (in transit + at rest) dora-encryption
1 — ICT risk management Access logging and monitoring dora-access-logging
1 — ICT risk management Backup and recovery (RPO/RTO) dora-backup-recovery
2 — Incident reporting Incident notification pathway dora-incident-reporting
3 — Resilience testing Resilience testing schedule dora-resilience-testing
4 — Third-party risk ICT third-party dependency register dora-third-party-register
4 — Third-party risk Sub-outsourcing chain declared dora-sub-outsourcing
5 — Information sharing (Not architectural — process / contractual) —

DORA Pillar 5 (cyber-threat information sharing) is governance / contractual rather than architectural — out of scope for this template.

The "critical or important function" pattern

A node represents a critical or important function (CIF) if the firm has designated it as such per DORA Art. 8(7). Tag those nodes explicitly:

{
  "unique-id": "core-banking-ledger",
  "node-type": "service",
  "name": "Core Banking Ledger",
  "metadata": {
    "dora-critical-function": true,
    "dora-criticality-tier": "tier-1",
    "data-classification": "confidential"
  }
}

Then attach the relevant controls below. Stricter expectations apply to CIFs (e.g., shorter RPO/RTO, mandatory resilience testing).

Control snippets

Copy each block under the controls key of the node it applies to.

Pillar 1 — ICT asset inventory (dora-ict-inventory)

Graph-level. Declare once per repo / per CALM document. The engine checks that every node has an entry; missing entries mean ICT assets that aren't accounted for in your DORA Art. 8 inventory.

// In your top-level CALM document's metadata:
"metadata": {
  "controls": {
    "dora-ict-inventory": {
      "description": "DORA Art. 8(1) — comprehensive inventory of ICT assets.",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/dora/ict-inventory",
          "config": {
            "control-id": "dora-ict-inventory",
            "inventory-completeness": "all-nodes-in-graph",
            "review-frequency": "annual-and-on-significant-change",
            "responsible-role": "ict-asset-owner"
          }
        }
      ]
    }
  }
}

Pillar 1 — Critical function identification (dora-critical-function)

Per-node. Attach to every node that is or supports a CIF.

"dora-critical-function": {
  "description": "DORA Art. 8(7) — node is a critical or important function (CIF) per the firm's designation.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/dora/critical-function",
      "config": {
        "control-id": "dora-critical-function",
        "criticality-tier": "tier-1",
        "business-function": "payment-execution",
        "designation-document-url": "https://internal.example.com/dora/cif-register",
        "designated-by": "head-of-operational-resilience",
        "review-date": "2025-12-31"
      }
    }
  ]
}

Pillar 1 — Encryption (dora-encryption)

Per-node. Same architectural shape as PCI Req 3+4 but with DORA vocabulary. Attach to nodes that store or transmit confidential data.

"dora-encryption": {
  "description": "DORA Art. 9(2) — cryptographic protection of ICT assets at rest and in transit.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/dora/encryption",
      "config": {
        "control-id": "dora-encryption",
        "at-rest-algorithm": "AES-256-GCM",
        "in-transit-minimum-tls": ["1.2", "1.3"],
        "key-management": "hsm-or-kms",
        "key-rotation-days": 365
      }
    }
  ]
}

Pillar 1 — Access logging (dora-access-logging)

Per-node. DORA Art. 9(4)(c) requires logging of access events on critical functions.

"dora-access-logging": {
  "description": "DORA Art. 9(4)(c) — logging of access and authentication events on ICT assets supporting critical or important functions.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/dora/access-logging",
      "config": {
        "control-id": "dora-access-logging",
        "events": ["read", "write", "auth-success", "auth-failure", "privilege-elevation", "config-change"],
        "destination": "centralized-siem",
        "immutable": true,
        "retention-days": 1825
      }
    }
  ]
}

Pillar 1 — Backup and recovery (dora-backup-recovery)

Per-node. DORA Art. 12 requires backup, restoration, and recovery methods. RPO/RTO must be declared and met.

"dora-backup-recovery": {
  "description": "DORA Art. 12 — ICT backup, restoration, and recovery procedures. RPO/RTO must be documented and aligned with the function's criticality tier.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/dora/backup-recovery",
      "config": {
        "control-id": "dora-backup-recovery",
        "rpo-minutes": 15,
        "rto-minutes": 60,
        "backup-frequency": "hourly",
        "backup-storage": "geographically-separate",
        "restoration-test-frequency": "quarterly",
        "last-restoration-test-date": "2025-04-15"
      }
    }
  ]
}

Pillar 2 — Incident reporting (dora-incident-reporting)

Graph-level. DORA Art. 17 requires a major-ICT-incident notification process to the firm's NCA within strict timelines (initial, intermediate, final reports).

"metadata": {
  "controls": {
    "dora-incident-reporting": {
      "description": "DORA Art. 17 — process for classifying, escalating, and reporting major ICT-related incidents to the competent authority.",
      "requirements": [
        {
          "requirement-url": "https://archrails.io/catalog/req/dora/incident-reporting",
          "config": {
            "control-id": "dora-incident-reporting",
            "classification-criteria-url": "https://internal.example.com/dora/incident-classification",
            "competent-authority": "BaFin",
            "initial-report-deadline-hours": 4,
            "intermediate-report-deadline-hours": 72,
            "final-report-deadline-days": 30,
            "escalation-roster-url": "https://internal.example.com/dora/escalation",
            "tested-annually": true,
            "last-test-date": "2025-03-10"
          }
        }
      ]
    }
  }
}

Pillar 3 — Resilience testing (dora-resilience-testing)

Per-node OR graph-level depending on test scope. DORA Art. 24 requires an annual digital operational resilience testing program; Art. 26 requires threat-led penetration testing (TLPT) for designated firms every 3 years.

"dora-resilience-testing": {
  "description": "DORA Art. 24 — annual digital operational resilience testing covering this node. TLPT (Art. 26) applies if the firm is designated.",
  "requirements": [
    {
      "requirement-url": "https://archrails.io/catalog/req/dora/resilience-testing",
      "config": {
        "control-id": "dora-resilience-testing",
        "test-types": ["vulnerability-assessment", "scenario-based", "performance", "end-to-end"],
        "frequency": "annual",
        "tlpt-applicable": true,
        "tlpt-frequency-years": 3,
        "last-tlpt-date": "2024-09-30",
        "next-tlpt-date": "2027-09-30"
      }
    }
  ]
}

Pillar 4 — Third-party dependency register (dora-third-party-register)

Per-relationship (attach to edges representing third-party ICT dependencies). DORA Art. 28 + RTS on register of information require firms to maintain a register of all ICT third-party arrangements.

// On a relationship (NOT a node):
"controls": {
  "dora-third-party-register": {
    "description": "DORA Art. 28 — this third-party ICT dependency is recorded in the firm's Register of Information.",
    "requirements": [
      {
        "requirement-url": "https://archrails.io/catalog/req/dora/third-party-register",
        "config": {
          "control-id": "dora-third-party-register",
          "provider-leid": "549300ABCDEFGHIJKLMN",
          "provider-name": "Acme Cloud Services",
          "service-category": "iaas-compute",
          "supports-critical-function": true,
          "contract-effective-date": "2024-01-01",
          "contract-end-date": "2027-12-31",
          "exit-strategy-document-url": "https://internal.example.com/dora/exit/acme",
          "register-entry-id": "DORA-TP-2024-0042"
        }
      }
    ]
  }
}

Pillar 4 — Sub-outsourcing chain (dora-sub-outsourcing)

Per-relationship. DORA Art. 29 requires firms to identify the entire chain when a critical-function third party further subcontracts.

"controls": {
  "dora-sub-outsourcing": {
    "description": "DORA Art. 29 — sub-outsourcing chain identified for critical-function third-party arrangements.",
    "requirements": [
      {
        "requirement-url": "https://archrails.io/catalog/req/dora/sub-outsourcing",
        "config": {
          "control-id": "dora-sub-outsourcing",
          "subcontractor-chain": ["Acme Cloud Services", "Underlying DC Operator GmbH"],
          "sub-outsourcing-approved-by-firm": true,
          "sub-outsourcing-jurisdiction": ["DE", "FR"]
        }
      }
    ]
  }
}

What the engine enforces

Same constraint engine that handles your no-pii-in-logs and PCI controls handles these — no special DORA-specific code path. Per-rule behavior:

All evaluations are deterministic — pure function over your CALM JSON, replayable byte-for-byte. Same trust direction as the PCI template: ArchRails enforces what you authored.

Auto-include during bootstrap (coming)

A future release will let archrails bootstrap detect EU-FSI repos (by asking you about regulatory scope, or by detecting dora / mifid / EU-LEI strings) and offer to auto-include this template in the generated .archrails/config.yml. Until that ships, copy-paste from above.

Versioning

This is dora/v0.1.0-beta. Pre-1.0 = beta. Bumps:

When DORA RTS amendments ship, or when authoritative interpretations from EBA/ESMA/EIOPA materially refine the architectural surface, we'll publish a new template version. The constraint engine evaluates every version identically — beta versus GA is metadata, not behavior.

Specifically out of scope for this template

For those surfaces, pair this template with your firm's DORA program documentation. We provide the deterministic enforcement of authored architectural controls; your DORA framework owns the rest.