Skip to content

DORA (Digital Operational Resilience Act) — Customer Guide

Last updated: 2026-05-14 (Plan 132 v1)

What is DORA, and why does it matter to you?

DORA is the EU regulation that asks every financial firm — banks, payment institutions, e-money, investment firms, insurers, crypto-asset service providers — to prove it can keep running when its ICT systems are under stress. It has been directly applicable across the EU since 17 January 2025; there is no national transposition lag and there is no grace period. Your national competent authority can request the operational-resilience evidence pack at short notice, and the Article 19 incident- reporting clock starts ticking four hours after you classify an incident as major. Secruna's job is to keep that pack ready and that clock visible.

What DORA-specific features does Secruna ship?

End-to-end (Plan 132) — every item below is wired in the deployed system:

  • Rule book v1 — 33 IGP YAMLs at rule_book/dora/v1/ covering all five DORA pillars: ICT risk management framework (Art. 5-16), ICT-related incident management (Art. 17-23), digital operational resilience testing (Art. 24-27), ICT third-party risk including the Art. 28(3) register (Art. 28-30), and information sharing (Art. 45). Loader picks it up via KNOWN_FRAMEWORKS["dora"] in packages/rekognise-core/src/rekognise/agent/rule_book/registry.py.
  • Evidence pack export — PDF / CSV / HTML at /exports/dora-evidence-pack. Backend renderer in packages/rekognise-core/src/rekognise/cp/export/regulation_evidence_pack.py (shared with NIS2); API at GET /export/dora-evidence-pack?format={pdf,csv,html} mounted by apps/cp-api/src/cp_api/main.py.
  • Tenant subscription — platform admins enable dora per tenant via enabled_frameworks (the same Plan 103 path used for every other framework). The evidence-pack endpoint gates on require_framework_subscription(db, tenant.id, "dora").
  • Sidebar entry — /exports/dora-evidence-pack is registered in the framework feature manifest (packages/rekognise-core/src/rekognise/cp/framework_features/manifest.py) as the dora_evidence_pack feature.
  • Counsel review (Plan 97) — every rule YAML carries pending_counsel_review: true so verdicts route through the same counsel pipeline as DS 05-138 / NCSC CAF / NIS2 rules.
  • Cross-framework signal share — DORA Pillar 1 reuses the same tenant_cyber_posture artifact-metadata kind that powers DS 05-138 / NCSC CAF / NIS2. Pillar 4 Art. 28(3) register reuses the universal Secruna AI systems inventory (/inventory).
  • Verdict taxonomy — Non-Compliant / Partial / Compliant. See FRAMEWORK_CATEGORY_TAXONOMY["dora"] in packages/rekognise-core/src/rekognise/agent/rule_book/loader.py.
  • Operator surface — /admin/regulations lists DORA under shipped frameworks; /admin/tenants/{id}/framework-subscriptions accepts dora as a subscription target.
  • Audit event — successful exports emit evidence_pack.dora.exported for the audit log.

Limitations (v1)

  • Article 28 register limited to AI ICT third-party arrangements. Art. 28(3) requires a register of all ICT third-party arrangements (cloud, SaaS, managed services, telecoms, hardware, payment processors, etc.). v1 reuses the Secruna AI systems inventory as a partial register covering AI ICT third-party arrangements only. Full ICT third-party coverage is scaffolded under Plan 134 (ICT third-party register beyond AI). For non-AI ICT arrangements, customers maintain the register out-of-band and import on demand; v1 documents the gap explicitly so the supervisor sees the boundary.
  • TLPT (Art. 26) is tenant-attested. Threat-Led Penetration Testing under Article 26 requires a TIBER-EU-style engagement with accredited red-teamers. Secruna does not run pentests. The Art. 26 IGP records the entity's TLPT scope + cycle as a tenant attestation; running the test is the entity's job.
  • Concentration risk assessment (Art. 29) is tenant-attested. The Art. 29 concentration-risk assessment requires sector-wide ICT third-party usage data Secruna does not collect. The Art. 29 IGP records the assessment as a tenant attestation.
  • Major-incident auto-classification (Art. 18) is scaffolded under Plan 135. Article 18 + Commission Delegated Regulation 2024/1772 define the major-incident threshold against services affected, duration, geographic reach, clients affected, economic + reputational impact. v1 lets the tenant tag incidents manually; the auto-classifier is scaffolded as Plan 135 (DORA major-incident classifier — depends on Plan 133).
  • No live competent-authority submission integration. Art. 19 initial / intermediate / final reports flow through national channels (BaFin, KNF, FCA-equivalent, etc.). Secruna ships the evidence pack + structured 4h / 72h / 1-month timeline tracker, not the submission portal.

What DORA is

DORA (Regulation (EU) 2022/2554 of 14 December 2022) is the EU regulation establishing a single, harmonised cybersecurity + ICT operational resilience framework for every EU financial entity. DORA entered force on 16 January 2023 and applies from 17 January 2025.

Unlike NIS2 (Directive — Member-State transposition), DORA is a Regulation — directly applicable across the EU with no transposition step. The text on EUR-Lex is the authoritative obligation.

DORA applies to financial entities in scope of Article 2:

  • credit institutions (banks),
  • payment institutions, electronic money institutions, account information service providers,
  • investment firms, AIFMs, UCITS management companies,
  • insurance + reinsurance undertakings + insurance intermediaries,
  • IORPs (institutions for occupational retirement provision),
  • central counterparties + trade repositories + credit rating agencies,
  • crypto-asset service providers, central securities depositories,
  • the ICT third-party service providers serving any of the above (Pillar 4 supplemental supervision by the ESAs).

DORA is structured as five pillars across Articles 5-45:

  1. Pillar 1 — ICT risk management framework (Art. 5-16) — governance, framework, identification, protection, detection, response, recovery, communication, learning, simplified framework option for microenterprises.
  2. Pillar 2 — ICT-related incident management (Art. 17-23) — process, classification, reporting (4h initial / 72h intermediate / 1-month final to competent authority), harmonised RTS templates, payment-incident overlay.
  3. Pillar 3 — Digital operational resilience testing (Art. 24-27) — general requirements, ICT system testing, threat-led penetration testing (TLPT), third-party tester qualifications.
  4. Pillar 4 — ICT third-party risk (Art. 28-30) — general principles, Art. 28(3) register of information, due diligence, exit strategies, concentration risk, key contractual provisions, sub-outsourcing, critical-provider designation.
  5. Pillar 5 — Information sharing (Art. 45) — voluntary cyber threat intelligence sharing.

What Secruna covers

Secruna ships DORA as a live rule book — rule_book/dora/v1/. Each Article becomes one or more Secruna rules with a DORA citation, a connector signal match, and a customer_description body explaining what the obligation means and what evidence the supervisor expects.

The v1 rule book covers:

  • Pillar 1 (Art. 5-16) — 13 IGPs: governance (Art. 5), risk management framework (Art. 6), ICT systems / protocols / tools (Art. 7), identification (Art. 8), protection + prevention (Art. 9), detection (Art. 10), response + recovery (Art. 11), backup + recovery procedures (Art. 12), learning + evolving (Art. 13), communication (Art. 14), RTS harmonisation (Art. 15), simplified framework option for microenterprises (Art. 16).
  • Pillar 2 (Art. 17-23) — 5 IGPs: incident management process (Art. 17), classification taxonomy (Art. 18), 4h initial report (Art. 19(4)(a)), 72h + 1-month follow-ups (Art. 19(4)(b)©), harmonised RTS template adoption (Art. 20), payment-incident overlay (Art. 23).
  • Pillar 3 (Art. 24-27) — 4 IGPs: testing programme (Art. 24), vulnerability assessments + AI-system testing (Art. 25), TLPT scope attestation (Art. 26), third-party tester qualifications (Art. 27).
  • Pillar 4 (Art. 28-30) — 9 IGPs: general principles (Art. 28(1)-(3)), Art. 28(3) register of information, pre-contract due diligence (Art. 28(4)), exit strategies (Art. 28(8)), concentration risk (Art. 29), Art. 30 key contractual provisions, Art. 30(3) supplemental provisions for critical-function arrangements, sub-outsourcing tracking (Art. 28(5)), critical-provider designation awareness (Art. 31).
  • Pillar 5 (Art. 45) — 1 IGP: cyber threat intelligence sharing.

How verdicts map to DORA Articles

Secruna verdict DORA outcome What it means
non_compliant Article not evidenced Competent-authority finding with supervisory-rating consequence. Highest severity.
partial Article partially evidenced A weakness with tracked remediation plan due before next supervisory review (e.g. register present but Art. 28(3) field 'sub-outsourcing chain' missing).
compliant Article evidenced + operating Informational.

Severity ordering (highest first): non_compliant > partial > compliant.

DORA does NOT carry a not_applicable value. The Regulation applies to every EU financial entity in scope of Art. 2, so the residual fallback is "compliant by absence of obligation" rather than a separate taxonomy value. Where a tenant is genuinely out of scope for an Article (e.g. Art. 16 simplified framework on a standard-sized investment firm), the rule does not fire rather than producing an explicit not-applicable verdict.

Using the evidence pack at supervision time

The DORA Evidence Pack is generated from the dashboard under Exports → DORA Evidence Pack (org_admin role required). The file is a tenant-level PDF / CSV bundle:

  • Cover — tenant name, framework metadata, generation timestamp, document ID.
  • §1. Assessment summary — counts of IGPs at each verdict.
  • §2. Per-IGP evidence by Pillar → Article — one section per Pillar, sub-grouped by Article, one row per IGP with the verdict and a short evidence summary.
  • §3. Gaps surfaced for supervision — non-compliant + partial IGPs surfaced separately so the supervisor sees the remediation list at a glance.
  • §4. Audit trail — last 90 days of platform activity material to the evidence pack.

Filename: secruna-dora-evidence-{tenant_slug}-{date}.pdf (or .csv).

Submitting

The national competent authority (BaFin in Germany, KNF in Poland, ASF in Romania, MFSA in Malta, etc.) supervises DORA compliance. For designated critical ICT third-party providers, supplemental EU-level supervision by the ESAs kicks in. Hand the evidence pack to the supervisor alongside the harmonised Art. 20 RTS template for major incidents. Submission flows through national channels; Secruna ships the evidence, the entity files it.

Re-running after remediation

Verdicts re-evaluate on every discovery run. To refresh the evidence pack after closing a gap:

  1. Trigger a discovery run (Connections → Run discovery now) or wait for the scheduled run.
  2. Confirm the verdict has flipped to compliant under the IGP detail page.
  3. Generate a fresh evidence pack — the new gap count appears on the cover.

What Secruna does NOT cover

  • Article 28(3) register beyond AI ICT third-party arrangements. v1 covers AI ICT third-party arrangements via the universal AI inventory; non-AI ICT third-party coverage is scaffolded under Plan 134.
  • TLPT (Art. 26) execution. Secruna does not run penetration tests. The Art. 26 IGP records the entity's TLPT scope + cycle.
  • Art. 29 concentration risk computation. Requires cross-tenant sector-wide data Secruna does not collect.
  • Art. 18 major-incident auto-classification. v1 lets the tenant tag incidents; auto-classification scaffolded under Plan 135.
  • Live competent-authority submission integration. Secruna ships the evidence pack; the entity files via national channels.

Frequently asked

Q. We're a UK bank with EU operations. Does DORA apply? DORA applies to EU-established financial entities. UK entities providing services in the EU may fall under DORA through their EU establishments. The Secruna multi-tenant model supports a per-EU-entity DORA subscription if that's how the supervision sits.

Q. We're already shipping NIS2. Do we need DORA too? DORA is the lex specialis for EU financial entities. Where DORA covers an obligation (incident reporting timelines, ICT third-party risk, etc.), DORA wins. NIS2 still covers the regulated entity for sector-specific obligations not addressed by DORA (notably some governance + supply-chain provisions). Most banks subscribe to both, with DORA carrying the bulk of the supervisory weight.

Q. The Art. 28(3) register — what does “reuse the AI inventory” mean concretely? Every AI vendor entry in your Secruna inventory (/inventory) is rendered into the Art. 28(3) register section of the DORA evidence pack. Fields covered: provider name, service description, criticality flag, supports critical function (yes / no). Fields not covered in v1: sub-outsourcing chain, exit strategy reference, contractual reference. Non-AI ICT third-parties (e.g. your hosting provider, payment processor, ERP vendor) are out of v1 scope.

Q. Who is the management body for Art. 5 governance purposes? National transposition varies. Typically the management board (Vorstand / zarząd / conseil d'administration) or the equivalent executive committee. Art. 5(2) makes the body responsible + Art. 5(4) makes its members participate in cybersecurity training.

Q. We're a small payment institution under Art. 16. Can we use the simplified framework? DORA Art. 16 permits microenterprises and small / non-interconnected investment firms to apply a simplified ICT risk management framework that nonetheless covers governance, identification, protection, detection, response + learning, ICT business continuity. The Art. 16 IGP in Secruna records the size classification + the six required elements coverage. If you are uncertain whether your entity qualifies for the simplified framework, ask your competent authority.