SDOS Runtime Governance Framework — EU AI Act Alignment¶
SDOS Version: 1.9
Regulation: EU AI Act — Regulation (EU) 2024/1689 of the European Parliament and of the Council
Entry into Force: 1 August 2024
Application Date for Annex III High-Risk Obligations: 2 August 2026 (Article 5 prohibitions applied 2 February 2025; GPAI obligations applied 2 August 2025; certain Annex I high-risk obligations and provider penalties apply 2 August 2027)
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 high-risk AI system providers under the EU AI Act (Regulation 2024/1689). It is intended to assist CISOs, GRC auditors, EU compliance leads, and procurement reviewers in evaluating SDOS against EU AI Act provider 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 the Act.
Applicability¶
This document applies to organizations deploying agentic AI workflows — systems in which one or more AI agents invoke tools, make routing decisions, or produce outputs autonomously on behalf of an operator. It is relevant when:
- The deployment falls within the EU AI Act's definition of a high-risk AI system under Annex III, or
- The organization is a provider or deployer of AI systems subject to EU AI Act obligations, and
- The organization is evaluating whether a runtime governance layer satisfies specific technical obligations under the Act.
This document is not applicable to static LLM-chat interfaces in which no tool invocation or autonomous action occurs. It is not applicable to obligations that arise exclusively from the model development lifecycle (training, validation, testing) or from post-deployment provider documentation requirements that precede or follow runtime operation.
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¶
Each article in the Full Mapping Table is assigned a mapping strength rating. These ratings are defined as follows:
| Rating | Meaning |
|---|---|
| Strong | SDOS provides a direct, mechanism-specific technical implementation of the obligation. The control satisfies the requirement through observable runtime behavior, not policy assertion. |
| Partial — [qualifier] | SDOS addresses a defined subset of the obligation. The qualifier identifies which subset is covered and which is not. A partial mapping is not a gap — it is a scoped claim. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance with the obligation but does not itself satisfy it. The obligation requires additional provider action consuming SDOS outputs. |
| Out of Scope | The obligation falls entirely outside the operational boundary of a runtime governance framework. No SDOS control addresses it, and none is claimed. |
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 sub-clauses are covered and which are not. Do not interpret "Partial" as incomplete implementation — it reflects an honest scope boundary. A framework that claims "Strong" alignment against every article of the EU AI Act is not credible. A framework that maps precisely to what it does and names what it does not do is.
Article Reference Format¶
Articles are referenced using the format Art. number where applicable. Where a mapping applies to the article as a whole, only the article number is cited. Where a mapping applies to a specific obligation within the article, the paragraph and sub-paragraph are cited.
Glossary¶
EU AI Act Terms¶
| Term | Definition as Used in This Document |
|---|---|
| High-risk AI system | An AI system listed in Annex III of the Act, subject to the full set of provider obligations including Articles 9, 12, 13, 14, and 17 |
| Provider | The entity that develops or places a high-risk AI system on the market or puts it into service under its own name or trademark |
| Deployer | The entity that uses a high-risk AI system under its authority in a professional capacity |
| Conformity assessment | The formal process by which a provider demonstrates compliance with the Act's requirements before placing a system on the market |
| Post-market monitoring | The provider's obligation to actively collect and analyze data on system performance after deployment (Article 72) |
| Quality management system (QMS) | The documented set of procedures, controls, and responsibilities a provider must establish under Article 17 |
| Harmonized standard | A European standard adopted to provide technical specifications that, when applied, create a presumption of conformity with specific Act obligations |
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 |
| Governed egress | Outbound operations subject to pre-execution policy enforcement before results are returned to the caller |
| 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 |
| Deliberation panel | A structured multi-agent evaluation process in which each participating agent operates within a policy-defined role; composition is a governance artifact, not agent-determined |
| Convergence record | The structured output of a governed deliberation capturing participant positions, degree of convergence or divergence, and the final governance determination |
| Model-alignment-independent | Enforcement that operates through structural separation from model inference, without reliance on the model's internal safety tuning |
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 EU AI Act obligations that fall within that runtime scope.
Within scope: Runtime risk management measures, automatic logging, human oversight technical measures, quality management system technical controls, and module identity verification.
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 |
|---|---|---|
| Article 9(2)(a–c) | Pre-deployment risk identification during design and development phases | SDOS operates at runtime, not during model design or training |
| Article 10 | Training, validation, and testing data governance; bias examination in training datasets | SDOS operates exclusively at inference time — after a model has been trained, validated, and deployed — and has no visibility into, access to, or control over training datasets, validation datasets, testing datasets, or the data governance procedures applied during model development; Article 10 obligations fall entirely within the model development lifecycle and require provider processes that precede SDOS deployment |
| Article 13 | Deployer-facing documentation of system characteristics, limitations, and foreseeable risks | SDOS generates operational audit records; producing the Article 13 information package is a provider documentation obligation outside SDOS scope |
| Article 72 | Post-market monitoring analysis, behavioral drift detection, and performance degradation evaluation | SDOS audit logs provide the data collection substrate; systematic performance analysis is a separate provider obligation |
Explicitly naming out-of-scope obligations is a feature of a credible alignment document, not an admission of weakness. SDOS is designed to solve the runtime enforcement problem. Adjacent obligations require complementary provider processes.
Article 9 — Runtime Scope Boundary¶
SDOS addresses a specific and bounded subset of Article 9's risk management system requirements. Article 9(2)(d) — adoption of appropriate and targeted risk management measures — is where SDOS operates: at the point of dispatch, before tool execution, on every governed invocation. The controls that satisfy this sub-clause are SDOS-RM-01 (risk classification), SDOS-RM-02 and SDOS-RM-03 (capability floor enforcement), SDOS-GV-03 (default-deny admission), SDOS-EN-01 (pre-egress enforcement), and SDOS-EN-03 (fail-closed degradation).
The remaining sub-clauses of Article 9(2) — identification and analysis of known and foreseeable risks (9(2)(a)), estimation and evaluation of risks under intended purpose and foreseeable misuse (9(2)(b)), and evaluation of risks from post-market monitoring data (9(2)(c)) — require design-phase analysis, lifecycle risk modeling, and systematic monitoring activities. These are provider obligations that precede and surround the runtime enforcement layer; SDOS does not perform them and does not claim to. Article 9(3), which requires risk elimination or mitigation through design measures or Article 13 information, addresses system design obligations, not runtime enforcement. Article 9(6), which requires testing to identify appropriate risk management measures and confirm consistent performance, is a pre-deployment validation obligation with no runtime analog in SDOS.
The correct framing is not that SDOS partially satisfies Article 9, but that SDOS fully satisfies the runtime enforcement layer of Article 9 while leaving design-phase, lifecycle, and post-market obligations to the provider processes that surround it. A complete Article 9 implementation requires both.
Strongest Alignment: Articles 12 and 14(4)(e)¶
SDOS provides direct, mechanism-specific coverage for two EU AI Act requirements that most AI governance frameworks address only at the policy level:
Article 12 — Record-Keeping
Article 12 requires that high-risk AI systems technically allow for the automatic recording of events over the system's lifetime, capturing data relevant to risk situations, substantial modifications, and operational monitoring. SDOS satisfies this requirement through four controls operating in combination:
- SDOS-AU-01 generates a structured audit record for every tool invocation, written before the result is returned to the caller — ensuring the governance decision is captured regardless of execution outcome.
- SDOS-AU-02 maintains the audit log in an append-only structure so that unauthorized alteration or deletion of historical records is detectable through integrity verification.
- SDOS-AU-03 writes audit records simultaneously to two independently maintained repositories, ensuring audit continuity even if one repository is unavailable or compromised.
- SDOS-EN-04 writes a tamper-evident record of every governed outbound operation, including the governance decision, agent identity, and timestamp, before the operation result is returned.
Together these controls constitute a technical implementation — not a policy claim — of Article 12's automatic logging requirement.
Article 14(e) — Halt Capability
Article 14(4)(e) requires that high-risk AI systems include a stop button or equivalent procedure allowing the system to come to a halt in a safe state. SDOS-EN-03 (Fail-Closed Degradation) provides a structural implementation of this requirement: when governance infrastructure is unavailable or when baseline integrity verification fails, SDOS defaults to a restrictive posture that halts operations requiring active governance evaluation. SDOS-EN-03 provides a governance-enforced halt — a structural implementation of the safe-state requirement in Article 14(4)(e).
Full Mapping Table¶
| EU AI Act Article | Title | Relevant SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|---|
| Art. 9 | Risk Management System | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-GV-03, SDOS-EN-01, SDOS-EN-03 | Partial — Runtime Scope | SDOS addresses Art. 9(2)(d): adoption of targeted risk management measures at the point of dispatch. Risk classification (RM-01), capability floor enforcement (RM-02, RM-03), default-deny admission (GV-03), and pre-egress enforcement (EN-01) collectively constitute a runtime risk management system. Pre-deployment obligations under Art. 9(2)(a–c) are outside scope. |
| Art. 10 | Data and Data Governance | — | Out of Scope | SDOS operates at runtime inference. Training, validation, and testing data governance are outside SDOS operational boundary. |
| Art. 12 | Record-Keeping | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03, SDOS-EN-04 | Strong — Generation and Integrity / Partial — Retention and Access | SDOS implements the technical generation and integrity requirements of Art. 12: per-invocation records written before result returned (AU-01), append-only log integrity (AU-02), dual independent repository (AU-03), tamper-evident governed egress records (EN-04). Retention durations and provision of access to competent authorities (Articles 19 and 20) are operator obligations consuming SDOS audit output. |
| Art. 13 | Transparency and Provision of Information to Deployers | SDOS-AU-01 | Weak — Substrate Only | SDOS audit records provide the operational data from which Art. 13 deployer information can be derived. SDOS does not produce the Art. 13 instructions-for-use information package itself — that is a provider documentation obligation outside SDOS scope. |
| Art. 14 | Human Oversight | SDOS-EN-03, SDOS-EN-01, SDOS-IA-01, SDOS-AU-01 | Partial — Technical Measures | SDOS provides technical measures that support human oversight without substituting for organizational oversight obligations. EN-03 directly implements Art. 14(4)(e) halt capability. EN-01 (pre-egress block) supports Art. 14(4)(d) override or reverse capability. IA-01 (verified agent identity) ensures oversight personnel know which agent acted. Art. 14's organizational requirements — human training, escalation paths, oversight staffing — are outside SDOS scope. |
| Art. 17 | Quality Management System | SDOS-GV-01, SDOS-GV-04, SDOS-GV-05, SDOS-IN-01, SDOS-IN-02, SDOS-IN-03, SDOS-IA-02 | Partial — Technical QMS Controls | SDOS controls map to Art. 17's technical QMS requirements: configuration-governed module activation (GV-01) addresses design control; cross-module governance continuity (GV-04) addresses quality assurance procedures; cryptographic baseline and module integrity verification (IN-01, IN-02, IN-03, IA-02) address examination and validation procedures. Art. 17's accountability framework establishing staff responsibilities is an organizational requirement outside SDOS scope. |
| Art. 72 | Post-Market Monitoring | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03 | Weak — Data Collection Only | SDOS audit logs provide the per-invocation data collection infrastructure that feeds post-market monitoring analysis. SDOS does not perform behavioral drift analysis, performance degradation evaluation, or the systematic monitoring required under Art. 72. These are provider obligations that consume SDOS audit data as input. |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | Art. 17(1)(c): design control and verification procedures |
| SDOS-GV-02 — Governance-Tiered Model Selection | Art. 9(2)(d): targeted risk management measures at dispatch |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | Art. 9(2)(d): systematic admission control as risk measure |
| SDOS-GV-04 — Cross-Module Governance Continuity | Art. 17(1)(c)/(d): design control across module boundaries; examination and validation procedures for cross-module governance continuity |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | Art. 9(2)(d): enforcement independent of model alignment state |
Risk Management (RM)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | Art. 9(2)(d): risk evaluation and classification at point of dispatch |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | Art. 9(2)(d): risk management measure preventing under-resourced governance decisions |
| SDOS-RM-03 — Risk-Floor Model Binding | Art. 9(2)(d): hard minimum capability floor for elevated-risk categories |
Enforcement (EN)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | Art. 14(4)(d): structural support for override or reverse capability |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | Art. 17(1)(c)/(d): secondary verification at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | Art. 14(4)(e): governance-enforced halt implementing the safe-state halt requirement |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | Art. 12: tamper-evident record of governed outbound operations |
Identity and Attestation (IA)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | Art. 14: supports human oversight by ensuring agent identity in every audit record |
| SDOS-IA-02 — Attested Module Identity | Art. 17(1)(d): cryptographic verification before module activation; examination procedure |
Audit (AU)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | Art. 12: automatic event recording; written before result returned |
| SDOS-AU-02 — Append-Only Audit Log Integrity | Art. 12: log integrity ensuring records accurately reflect system history |
| SDOS-AU-03 — Dual Audit Trail | Art. 12: continuity of logging even if one repository is unavailable |
Integrity (IN)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | Art. 17(1)(c)/(d): cryptographic config verification as quality assurance procedure |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | Art. 9(2)(d): governance baseline integrity verification as risk management measure; halt prevents operation under compromised governance |
| SDOS-IN-03 — Module Manifest Integrity | Art. 17(1)(d): cryptographic signature verification before module activation |
Deliberation (DE)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-DE-01 — Governed Multi-Agent Deliberation | See Architectural Alignment Note below |
| SDOS-DE-02 — Convergence-Based Decision Record | See Architectural Alignment Note below |
Architectural Alignment Note — DE Domain and EU AI Act¶
SDOS-DE-01 and SDOS-DE-02 address the structural independence requirement implicit in Article 9(2)'s continuous iterative risk management process and Article 17's quality assurance procedures. In agentic workflows, these obligations assume a reviewer structurally independent of the system under evaluation. DE-01 enforces that independence at the governance layer (panel composition is a governance artifact, not agent-selected); DE-02 produces the durable convergence record that makes iterative review meaningful. These controls map to the architectural intent of Articles 9(2) and 17, not to a specific enumerated sub-clause.
Admission (AD)¶
| Control | EU AI Act Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | Art. 9(2)(d): default-deny posture as systematic risk management measure |
Governed Multi-Agent Deliberation: SDOS-DE-01 and SDOS-DE-02¶
Article 9(2) requires that a risk management system operate as a continuous iterative process with regular systematic review and updates. For single-model systems, the implementation pattern this implies is relatively straightforward: a human or process reviews outputs, flags risks, and updates risk parameters. For agentic AI workflows — where multiple AI agents evaluate, route, and act on tasks — the pattern breaks. The agent that produces an output may also be in a position to evaluate it, scope its own review panel, or determine which risks are worth flagging. The Act does not specify how providers should prevent this; it assumes the governance structure will be organizational. SDOS addresses it structurally.
SDOS-DE-01 — Governed Multi-Agent Deliberation enforces that the composition of any deliberation panel is defined by governance policy, not by the participating agents. An agent cannot nominate its own reviewers, exclude dissenting perspectives, or narrow the scope of its own evaluation at runtime. The panel composition is a governance artifact — defined before the task is dispatched, enforced at the SDOS layer, and not modifiable by any agent within the session. This is not a procedural control. It is a structural constraint that eliminates a class of self-serving bias that organizational governance cannot reliably prevent in automated pipelines.
SDOS-DE-02 — Convergence-Based Decision Record produces a structured output from every governed deliberation: a scored record that captures the positions of all panel participants, the degree of convergence or divergence across those positions, and the final governance determination. The record preserves minority positions — outputs with material dissent are not collapsed into a single result. A reviewer consuming a DE-02 record can distinguish between a unanimous high-confidence output and an output that cleared a threshold despite significant panel disagreement. This distinction is material to the iterative review requirement in Article 9(2).
Together, DE-01 and DE-02 map to the spirit of Article 9(2)'s continuous iterative risk management requirement in two ways. First, DE-01 ensures that iterative evaluation is structurally independent — the evaluation process cannot be self-directed by the system under evaluation. Second, DE-02 ensures that iterative evaluation produces a durable, reviewable record that captures the state of deliberation, not just its output. Both properties are necessary for the iterative process to be meaningful rather than procedural.
These controls also map to Article 17's quality assurance procedures. Article 17 requires that providers establish procedures for the examination, testing, and validation of high-risk AI systems before they are placed on the market and throughout their lifecycle. In agentic workflows, DE-01 and DE-02 extend this requirement into runtime: the governance structure governing deliberation is itself an examination procedure applied at the point of execution, and the convergence record is the validation artifact it produces.
The practical significance for organizations implementing agentic AI workflows subject to the Act: the Article 9 iterative risk management requirement and the Article 17 quality assurance requirement both assume a reviewer structurally independent of the system being reviewed. In single-model systems, a human reviewer satisfies this assumption. In multi-agent pipelines operating at machine speed, organizational independence is not sufficient — the independence must be enforced at the architecture level. DE-01 and DE-02 are that enforcement.
Important limitation. Convergence across participating agents is a deliberation signal, not a correctness guarantee — correlated errors across models with shared training distributions are a recognized failure mode. The convergence record alone does not establish the correctness of the deliberation outcome; for high-risk decisions, human review remains required. DE-01 and DE-02 support Article 14's human oversight obligation by ensuring the oversight process has a structurally independent, reviewable record to act on; they do not substitute for human oversight.
Regulatory Evolution Notice¶
The EU AI Act is supplemented by delegated acts, implementing acts (Articles 290 and 291 TFEU), harmonised technical standards, and guidance from the EU AI Office that will further specify provider obligations across the phased application schedule. This mapping reflects the Act as in force at the document date above.
SDOS governance configurations and this alignment document will require periodic review as delegated and implementing acts are adopted and as AI Office guidance is issued. AAM Cyber maintains a version history for this reference document at /sdos/reference/changelog/.
Relationship to NIST AI RMF 1.0¶
SDOS is also mapped to the NIST AI Risk Management Framework (AI RMF) 1.0 as part of a NIST OLIR submission. The NIST AI RMF 1.0 and the EU AI Act are not identical in scope or structure, but they address overlapping governance concerns. Where SDOS controls map to both frameworks, the intersection is noted below:
| SDOS Domain | AI RMF Function | EU AI Act Article |
|---|---|---|
| Audit (AU) | GOVERN, MANAGE | Art. 12 |
| Enforcement (EN) | MANAGE | Art. 9, Art. 14 |
| Integrity (IN) | MEASURE | Art. 17 |
| Risk Management (RM) | MAP, MANAGE | Art. 9 |
| Identity & Attestation (IA) | GOVERN | Art. 14, Art. 17 |
Full NIST AI RMF mapping: SDOS Control Catalog and Reference Document v1.9
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 EU AI Act requirements: [email protected]
SDOS Runtime Governance Framework — EU AI Act Alignment. Version 1.3. Published 2026-05-03.