SDOS Runtime Governance Framework — DORA Alignment¶
SDOS Version: 1.9
Regulation: EU Digital Operational Resilience Act — Regulation (EU) 2022/2554
Enforcement Date: 17 January 2025
Document Date: 2026-05-03
Authoring Organization: AAM Cyber (aamcyber.com)
Inventor: Pharns Genece
SDOS Control Catalog: View full control definitions
Purpose¶
This document maps the controls of the SDOS Runtime Governance Framework to the obligations placed on financial sector entities under the EU Digital Operational Resilience Act (DORA, Regulation 2022/2554). It is intended to assist CISOs, CROs, GRC auditors, and ICT risk managers in financial institutions evaluating SDOS against DORA's ICT risk management, incident detection, and third-party ICT risk requirements.
This is an informative alignment document. It does not constitute a certification, a conformity assessment, or a regulatory declaration. Organizations should conduct independent assessment to determine whether SDOS controls satisfy their specific compliance obligations under DORA.
Applicability¶
This document applies to financial sector entities subject to DORA that deploy agentic AI workflows — systems in which one or more AI agents invoke tools, make routing decisions, or produce outputs autonomously as part of ICT operations. DORA applies to a broad range of entities including credit institutions, payment institutions, investment firms, crypto-asset service providers, insurance undertakings, and ICT third-party service providers designated as critical.
This document is relevant when:
- The entity deploys AI agents as part of its ICT systems subject to DORA's ICT risk management framework obligations, or
- The entity is evaluating whether a runtime governance layer satisfies specific technical obligations under DORA Chapter II (ICT risk management) or Chapter III (ICT incident management), or
- An ICT third-party service provider is demonstrating operational resilience controls to a DORA-regulated client.
This document is not applicable to obligations that arise from organizational governance structures, board-level accountability requirements, regulatory reporting chains, or threat-led penetration testing programs — these fall outside the operational boundary of a runtime governance framework.
SDOS Control Catalog Summary¶
The full control catalog with per-control descriptions, evidence types, and related control dependencies is published at /sdos/reference/v1/. The 24 SDOS controls comprising the public runtime control set are:
| Control ID | Title |
|---|---|
| SDOS-GV-01 | Configuration-Governed Module Activation |
| SDOS-GV-02 | Governance-Tiered Model Selection |
| SDOS-GV-03 | Default-Deny Pre-Admission Policy |
| SDOS-GV-04 | Cross-Module Governance Continuity |
| SDOS-GV-05 | Model-Alignment-Independent Policy Enforcement |
| SDOS-RM-01 | Dispatch-Time Risk Classification |
| SDOS-RM-02 | Complexity-Tiered Resource Allocation |
| SDOS-RM-03 | Risk-Floor Model Binding |
| SDOS-AD-01 | Default-Deny Agent Pre-Admission |
| SDOS-IA-01 | Attested Agent Identity |
| SDOS-IA-02 | Attested Module Identity |
| SDOS-IN-01 | Governance Baseline Integrity Verification |
| SDOS-IN-02 | Baseline Drift Detection and System Halt |
| SDOS-IN-03 | Module Manifest Integrity |
| SDOS-EN-01 | Pre-Egress Policy Enforcement |
| SDOS-EN-02 | Subordinate-Side Enforcement Gate |
| SDOS-EN-03 | Fail-Closed Degradation |
| SDOS-EN-04 | Governed Egress with Tamper-Evident Audit |
| SDOS-AU-01 | Per-Invocation Audit Record |
| SDOS-AU-02 | Append-Only Audit Log Integrity |
| SDOS-AU-03 | Dual Audit Trail |
| SDOS-DE-01 | Governed Multi-Agent Deliberation |
| SDOS-DE-02 | Convergence-Based Decision Record |
| SDOS-RS-01 | Governed Return on Safety Investment (ROSI) Evaluation |
How to Use This Document¶
Assessor Use Notice¶
Mapping strength reflects the framework's design coverage of the cited requirement. Operating effectiveness is a property of a specific deployment and must be tested per engagement. Assessors should treat all mappings as control-design assertions requiring implementation verification — including evidence collection, sample selection, and testing against the assessor's own audit objective. The strength rating is the starting point for an assessor's testing plan, not a substitute for it.
Mapping Strength Legend¶
| Rating | Meaning |
|---|---|
| Strong | SDOS provides a direct, mechanism-specific technical implementation of the obligation through observable runtime behavior. |
| Partial — [qualifier] | SDOS addresses a defined subset of the obligation. The qualifier identifies which subset is covered and which is not. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance but does not itself satisfy the obligation. |
| Out of Scope | The obligation falls entirely outside the operational boundary of a runtime governance framework. |
How to Read Partial Mappings¶
A "Partial" rating means SDOS covers a specific, named subset of the article's requirements. The notes column identifies exactly which aspects are covered and which require additional organizational controls. DORA obligations span organizational, contractual, and technical layers — SDOS addresses the technical runtime layer only.
Glossary¶
DORA Terms¶
| Term | Definition as Used in This Document |
|---|---|
| ICT risk | Any reasonably identifiable circumstance in relation to ICT systems that could compromise their security, continuity, capacity, or performance |
| ICT incident | An unplanned event that compromises the security, availability, continuity, or quality of ICT services |
| Digital operational resilience | The ability of a financial entity to build, assure, and review its operational integrity and reliability by ensuring ICT capabilities withstand disruptions |
| Critical ICT third-party provider (CTPP) | An ICT third-party service provider designated by supervisory authorities as critical to the financial system |
| TLPT | Threat-Led Penetration Testing — advanced red-team testing required for significant financial entities under Art. 26. The TIBER-EU framework (Threat Intelligence-Based Ethical Red Teaming) provides the methodological basis referenced in DORA's TLPT requirements. |
SDOS Terms¶
| Term | Definition |
|---|---|
| Point of dispatch | The moment a task is assigned to an agent and before any tool execution occurs; the primary SDOS enforcement boundary |
| Fail-closed degradation | SDOS-EN-03 defines three failure modes: (1) governance infrastructure unavailability — pre-authorized operations may continue under a documented degradation policy; (2) governance baseline integrity failure — all operations halt without exception; (3) partial-degradation states (e.g., one of two AU-03 repositories unavailable, single-module manifest revalidation failure) — governed by a documented degradation policy that is itself integrity-verified per IN-01. See SDOS-EN-03 in the control catalog for the full definition. |
| Governance baseline | The authorized configuration state against which SDOS verifies integrity at startup and on demand |
| Module manifest | A cryptographically signed artifact declaring a module's identity and authorized capabilities |
| Governed egress | Outbound operations subject to pre-execution policy enforcement before results are returned |
Scope Statement¶
SDOS is a runtime governance framework. Its controls operate at the point of dispatch — the moment a task is assigned to an AI agent and before any tool execution occurs. This document maps SDOS controls to DORA obligations that fall within that runtime scope.
Within scope: ICT risk identification and classification at dispatch, access control and pre-egress enforcement, automated event detection and audit logging, governance baseline integrity verification, module identity verification, and fail-closed degradation as a continuity measure.
Outside SDOS Operational Boundary (must be addressed by complementary organizational controls): The following obligations are outside the operational boundary of a runtime governance framework and are not claimed here:
| Article | Obligation | Why Out of Scope |
|---|---|---|
| Art. 5 | Board-level governance arrangements and management accountability | Organizational structure obligation — no technical runtime substitute |
| Art. 13 | Post-incident learning and ICT risk framework evolution | Requires organizational process and review cycles beyond runtime enforcement |
| Art. 14 | Internal and external incident communication protocols | Human escalation chains and regulatory notification — organizational obligation |
| Art. 19–20 | Regulatory incident reporting to competent authorities | Legal and organizational reporting obligation |
| Art. 26–27 | Threat-led penetration testing (TLPT) programs and tester qualifications | Pre-deployment and periodic testing programs — outside runtime scope |
| Art. 32–34 | Oversight framework for designated Critical Third-Party Providers | Regulatory designation and supervision — not a technical control |
Strongest Alignment: Articles 9 and 10¶
Article 9 — Protection and Prevention
Article 9 requires financial entities to have in place ICT security policies, procedures, and controls to protect against intrusions, unauthorized access, and data misuse. SDOS provides the most complete coverage of this article of any DORA obligation at the AI agent dispatch layer:
- SDOS-GV-03 (Default-Deny Pre-Admission Policy) implements a default-deny posture — no agent operates without explicit admission, directly implementing Art. 9's access restriction requirement at the dispatch boundary.
- SDOS-EN-01 (Pre-Egress Policy Enforcement) blocks unauthorized outbound operations before execution, directly implementing Art. 9's prevention requirement.
- SDOS-EN-02 (Subordinate-Side Enforcement Gate) provides a secondary enforcement boundary at the module level, creating defense-in-depth within the governed pipeline.
- SDOS-EN-03 (Fail-Closed Degradation) ensures that when governance infrastructure is unavailable, the system halts rather than permitting uncontrolled operation — a structural implementation of Art. 9's resilience posture.
Art. 9's full scope extends to network protection, endpoint security, physical ICT asset controls, and software patch management — infrastructure obligations outside SDOS operational boundary. SDOS covers the AI agent dispatch layer of Art. 9 with depth and precision; complementary infrastructure controls address the remainder.
Article 10 — Detection
Article 10 requires financial entities to have in place mechanisms to promptly detect anomalous activities and ICT-related incidents. SDOS provides the most complete detection coverage within its dispatch-layer scope of any DORA obligation:
- SDOS-AU-01 generates a structured audit record for every agent invocation, written before the result is returned — creating an uninterrupted detection substrate.
- SDOS-AU-02 maintains the audit log in an append-only structure, ensuring the detection record cannot be silently altered after the fact.
- SDOS-IN-01 and SDOS-IN-02 perform governance baseline integrity verification and halt the system when unauthorized configuration changes are detected — direct implementation of anomaly detection at the governance layer.
Article 17 — ICT Incident Management Process
Article 17 requires financial entities to define, establish, and implement an ICT incident management process for detecting, managing, and notifying ICT-related incidents. SDOS provides technical logging infrastructure that feeds this process, but does not satisfy the full process obligation:
- SDOS-AU-01, AU-02, AU-03 together create a complete, tamper-evident, dual-repository audit trail that feeds Art. 17's logging requirements at the AI dispatch layer.
- SDOS-RM-01 (Dispatch-Time Risk Classification) provides per-invocation severity tiering that feeds Art. 18's incident materiality classification requirement.
Full Art. 17 compliance requires organizational incident management — detection workflows, notification chains, classification procedures, and escalation paths — that operate above the runtime layer SDOS governs.
Full Mapping Table¶
| DORA Article | Title | Relevant SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|---|
| Art. 6 | ICT risk management framework | SDOS-GV-01, SDOS-GV-04, SDOS-GV-05, SDOS-RM-01 | Partial — AI Runtime Layer | SDOS addresses the AI agent dispatch layer of the ICT risk management framework. Configuration-governed module activation (GV-01), cross-module continuity (GV-04), and model-alignment-independent enforcement (GV-05) constitute a documented runtime governance layer. Art. 6 is a full-framework obligation spanning organizational governance, board accountability, and the complete ICT stack — SDOS addresses the AI runtime layer only. |
| Art. 8 | Identification | SDOS-RM-01, SDOS-AD-01, SDOS-IA-01, SDOS-IA-02 | Partial — AI Asset Layer | Dispatch-time risk classification (RM-01), default-deny admission (AD-01), and verified agent/module identity (IA-01, IA-02) satisfy Art. 8's requirements at the AI agent layer. Full Art. 8 compliance requires identification across the complete ICT asset inventory, including infrastructure and network assets outside SDOS scope. |
| Art. 9 | Protection and prevention | SDOS-GV-03, SDOS-EN-01, SDOS-EN-02, SDOS-EN-03 | Partial — AI Dispatch Layer | Default-deny (GV-03), pre-egress enforcement (EN-01), subordinate gate (EN-02), and fail-closed degradation (EN-03) implement Art. 9's access control and prevention requirements at the AI agent dispatch boundary. Art. 9's full scope spans network protection, endpoint security, physical ICT asset controls, and patch management — all outside SDOS operational boundary. Complementary infrastructure-layer controls are required. |
| Art. 10 | Detection | SDOS-AU-01, SDOS-AU-02, SDOS-IN-01, SDOS-IN-02 | Partial — AI Dispatch Layer | Per-invocation audit records (AU-01), append-only log integrity (AU-02), and governance baseline verification with halt (IN-01, IN-02) satisfy Art. 10's anomaly detection requirements at the AI agent dispatch layer. Full Art. 10 compliance requires anomaly detection across the complete ICT environment including network, endpoint, and infrastructure layers outside SDOS scope. |
| Art. 11 | Response and recovery | SDOS-EN-03, SDOS-GV-04 | Partial — Fail-Closed Only | EN-03 fail-closed degradation implements a safe halt response. GV-04 cross-module continuity supports recovery. Full Art. 11 response and recovery requires organizational BCP/DRP processes outside SDOS scope. |
| Art. 12 | Backup and recovery | — | Out of Scope | Article 12 governs ICT system backup and restoration of ICT systems and data. SDOS does not provide system backup or data recovery capabilities — those are infrastructure-layer obligations. AU-03 (dual audit trail) addresses audit-record continuity for Articles 10 and 17 logging, not the system-backup obligation in Article 12. |
| Art. 13 | Learning and evolving | — | Out of Scope | Post-incident learning loops and ICT risk framework evolution require organizational review processes. No runtime substitute exists. |
| Art. 15 | Further harmonisation of ICT tools, methods, and policies | SDOS-GV-01, SDOS-IN-03 | Weak — Standards Substrate | Art. 15 is a regulatory delegation provision directing the ESAs to develop harmonised technical standards — it creates obligations on supervisory authorities, not directly on financial entities. Financial entities must comply with the resulting ITS/RTS when issued. SDOS configuration governance (GV-01) and module manifest integrity (IN-03) provide a standards-ready technical substrate that can be configured to meet specific ITS/RTS requirements as they are published. No direct Art. 15 entity obligation exists for SDOS to satisfy. |
| Art. 17 | ICT incident management process | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03, SDOS-IN-01 | Partial — Logging Substrate | SDOS provides the tamper-evident dual-repository audit trail that feeds Art. 17's detection and logging requirements at the AI dispatch layer. Full Art. 17 compliance requires an organizational incident management process covering detection, management, notification, classification, assignment, and escalation — none of which are runtime substitutes. |
| Art. 18 | Classification of ICT incidents | SDOS-RM-01, SDOS-RM-02 | Partial — Classification Input | Dispatch-time risk classification (RM-01) and complexity-tiered resource allocation (RM-02) feed the materiality threshold assessment required by Art. 18. Formal incident classification is an organizational obligation. |
| Art. 19 | Reporting to authorities | — | Out of Scope | Regulatory incident reporting is a legal and organizational obligation with no runtime analog. |
| Art. 24 | General resilience testing | SDOS-IN-01, SDOS-IN-02, SDOS-IN-03 | Partial — Integrity Verification | Baseline integrity verification (IN-01, IN-02) and module manifest checks (IN-03) provide continuous automated verification. Periodic resilience testing programs are organizational obligations. |
| Art. 28 | Third-party ICT risk — general principles | SDOS-GV-01, SDOS-GV-05, SDOS-RM-01, SDOS-AD-01 | Partial — Dispatch Boundary Only | SDOS enforces third-party risk controls at the AI agent dispatch boundary: default-deny admission (AD-01) and model-alignment-independent enforcement (GV-05) govern what third-party components an agent can invoke. Art. 28's general principles span contract management, due diligence, and risk concentration assessment — all organizational obligations outside SDOS scope. |
| Art. 30 | Key contractual provisions for ICT third-party services | SDOS-IA-01, SDOS-IA-02, SDOS-EN-02, SDOS-GV-04 | Partial — Identity and Enforcement Chain | Verified agent and module identity (IA-01, IA-02) provide cryptographic verification that third-party components operate as contracted. Subordinate-side enforcement gate (EN-02) and cross-module continuity (GV-04) extend governance enforcement through third-party chains at the technical layer. Contractual terms, SLA monitoring, and audit rights are organizational obligations outside SDOS scope. |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | DORA Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | Art. 6: documented ICT risk management framework; Art. 15: technical standards alignment |
| SDOS-GV-02 — Governance-Tiered Model Selection | Art. 6: risk-proportionate resource allocation within ICT framework |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | Art. 9: access restriction and prevention controls |
| SDOS-GV-04 — Cross-Module Governance Continuity | Art. 11: continuity measures; Art. 30: third-party chain governance |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | Art. 6: enforcement independent of underlying ICT component alignment; Art. 28: third-party risk |
Risk Management (RM)¶
| Control | DORA Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | Art. 8: ICT risk identification; Art. 18: incident severity classification input |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | Art. 18: risk-proportionate response resourcing |
| SDOS-RM-03 — Risk-Floor Model Binding | Art. 9: minimum capability floor as a prevention measure |
Enforcement (EN)¶
| Control | DORA Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | Art. 9: prevention of unauthorized access and data misuse at egress |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | Art. 9: defense-in-depth; Art. 30: technical enforcement in third-party chains |
| SDOS-EN-03 — Fail-Closed Degradation | Art. 9: resilience posture; Art. 11: safe halt as a response measure |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | Art. 10: detection substrate; Art. 17: incident management logging |
Identity and Attestation (IA)¶
| Control | DORA Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | Art. 8: asset identification; Art. 30: third-party component verification |
| SDOS-IA-02 — Attested Module Identity | Art. 8: asset identification; Art. 30: cryptographic verification of third-party modules |
Audit (AU)¶
| Control | DORA Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | Art. 10: continuous monitoring; Art. 17: incident detection and logging |
| SDOS-AU-02 — Append-Only Audit Log Integrity | Art. 10: tamper-evident detection record; Art. 17: audit trail integrity |
| SDOS-AU-03 — Dual Audit Trail | Art. 17: resilient incident record substrate |
Integrity (IN)¶
| Control | DORA Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | Art. 10: anomaly detection at governance layer; Art. 24: continuous verification |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | Art. 10: automated anomaly response; Art. 24: operational resilience testing analog |
| SDOS-IN-03 — Module Manifest Integrity | Art. 15: technical standards alignment; Art. 30: third-party component integrity |
Deliberation (DE)¶
| Control | DORA Relevance |
|---|---|
| SDOS-DE-01 — Governed Multi-Agent Deliberation | Architectural alignment: structured risk evaluation independent of the system under evaluation; supports Art. 6 iterative risk management intent |
| SDOS-DE-02 — Convergence-Based Decision Record | Architectural alignment: durable record of governance deliberation for audit and review; supports Art. 6 iterative review intent |
Admission (AD)¶
| Control | DORA Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | Art. 9: default-deny as systematic access control; Art. 28: third-party risk gate |
Risk Measurement (RS)¶
| Control | DORA Relevance |
|---|---|
| SDOS-RS-01 — Governed ROSI Evaluation | Art. 6: quantified evidence that governance overhead is justified by measurable risk reduction — supports the iterative evaluation component of the ICT risk management framework; Art. 8: provides operational metrics that feed risk identification and monitoring at the AI dispatch layer |
Regulatory Context¶
DORA entered into force on 16 January 2023 and became applicable on 17 January 2025. It is directly applicable across all EU member states without transposition. The European Supervisory Authorities (ESAs) — EBA, EIOPA, and ESMA — are issuing implementing technical standards (ITS) and regulatory technical standards (RTS) that further specify obligations under the Act. This mapping reflects DORA as in force at the document date above.
Organizations subject to DORA should monitor ESA technical standards publications for additional specification of ICT risk management and incident reporting requirements that may affect the scope of runtime governance obligations.
AAM Cyber maintains a version history for this reference document at /sdos/reference/changelog/.
Relationship to NIST AI RMF 1.0 and EU AI Act¶
SDOS is also mapped to the NIST AI Risk Management Framework (AI RMF) 1.0 and the EU AI Act. For financial sector entities subject to both DORA and the EU AI Act, SDOS controls provide a unified runtime governance layer addressing obligations under both regulations simultaneously.
| SDOS Domain | NIST AI RMF Function | EU AI Act Article | DORA Article |
|---|---|---|---|
| Audit (AU) | GOVERN, MANAGE | Art. 12 | Art. 10, 17 |
| Enforcement (EN) | MANAGE | Art. 9, 14 | Art. 9, 11 |
| Integrity (IN) | MEASURE | Art. 17 | Art. 10, 24 |
| Risk Management (RM) | MAP, MANAGE | Art. 9 | Art. 8, 18 |
| Identity & Attestation (IA) | GOVERN | Art. 14, 17 | Art. 8, 30 |
Full NIST AI RMF mapping: SDOS Control Catalog and Reference Document v1.10
EU AI Act alignment: SDOS — EU AI Act Alignment
Architectural Positioning¶
SDOS operates at the dispatch-time enforcement layer — the moment immediately before an AI agent invokes a tool, makes a decision, or produces an output. The SDOS framework does not replace organizational, physical, or personnel cybersecurity controls. It provides a runtime layer that enforces governance policy at the boundary where AI agents act, adding an architectural layer of cybersecurity assurance for AI-augmented operations.
For alignment purposes, SDOS supports the operational and technical requirements addressing how AI-driven cyber operations are deployed, monitored, and audited. Requirements addressing the organizational, physical, or personnel layer fall outside the SDOS scope and require separate controls.
Maintenance¶
This document is maintained by AAM Cyber as part of the SDOS Reference Library. The library currently covers 17 framework alignments: NIST AI RMF 1.0, NIST CSF 2.0, NIST SP 800-53 Rev 5.2.0, NIST AI 600-1, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, CMMC 2.0, SOC 2, NAIC MDL-668, NERC CIP, IEEE P2863 (draft), and FAA UAS/AAM (principles-mapped). Version history for every framework alignment is published at /sdos/reference/changelog/.
Subsequent updates to this alignment page will be issued when: (1) screening feedback from a recognized standards body requires revision, (2) the focal framework releases a revision requiring mapping review, or (3) SDOS controls are added or retired affecting the alignment.
Intellectual Property¶
The SDOS Runtime Governance Framework was invented by Pharns Genece. Aspects of the framework are the subject of pending U.S. Provisional Patent Applications 64/029,300, 64/049,300, 64/067,427, 64/069,200, and 64/076,620. The scope of pending claims is defined by the as-filed specifications and is not coextensive with the descriptions in this control catalog. AAM Cyber, all rights reserved unless otherwise indicated.
Patent inquiries should be directed to AAM Cyber at aamcyber.com.
Contact¶
AAM Cyber
aamcyber.com
Questions about SDOS framework alignment with DORA requirements: [email protected]
SDOS Runtime Governance Framework — DORA Alignment. Version 1.3. Published 2026-05-03.