SDOS Runtime Governance Framework — HIPAA Security Rule Alignment¶
SDOS Version: 1.9
Regulation: HIPAA Security Rule — 45 CFR Part 164, Subparts A and C
Enforcing Agency: U.S. Department of Health and Human Services (HHS), Office for Civil Rights (OCR)
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 technical safeguard requirements of the HIPAA Security Rule (45 CFR Part 164, Subparts A and C). It is intended to assist CISOs, privacy officers, GRC auditors, and healthcare technology reviewers evaluating SDOS as a technical control layer for AI systems that operate in healthcare environments where electronic protected health information (ePHI) may be present.
This is an informative alignment document. It does not constitute a certification, a conformity assessment, or a legal determination of HIPAA compliance. Organizations should conduct independent assessment — including legal review — to determine whether SDOS controls satisfy their specific compliance obligations under the Security Rule.
Applicability¶
This document applies to covered entities and business associates that deploy agentic AI workflows in which AI agents may access, process, route, or produce outputs involving ePHI. It is relevant when:
- An AI agent operates within a healthcare IT environment where ePHI is present in the systems the agent can invoke, or
- The organization is evaluating whether a runtime governance layer satisfies technical safeguard requirements under §164.312, or
- A business associate is demonstrating technical controls governing AI agent operations to a covered entity.
This document is not applicable to physical safeguards (§164.310), workforce training and sanctions (§164.308(a)(5)), business associate agreement obligations (§164.314), or ePHI content-level encryption — these fall outside the operational boundary of a runtime governance framework.
Important scope clarification: SDOS governs AI agent dispatch — the decision of whether and how an agent operates. It does not access, store, encrypt, or process ePHI content directly. SDOS controls the governance layer above the data layer. This distinction is material to understanding where SDOS satisfies HIPAA technical safeguard requirements and where complementary controls are required.
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 safeguard requirement through observable runtime behavior. |
| Partial — [qualifier] | SDOS addresses a defined subset of the requirement. The qualifier identifies which subset is covered and which requires additional controls. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance but does not itself satisfy the requirement. |
| Out of Scope | The requirement falls entirely outside the operational boundary of a runtime governance framework. |
Required vs. Addressable Implementation Specifications¶
The HIPAA Security Rule distinguishes between Required and Addressable implementation specifications. Required specifications must be implemented. Addressable specifications must be implemented if reasonable and appropriate, or the covered entity must document why not and implement an equivalent alternative. This mapping notes which category each specification falls into where relevant.
Glossary¶
HIPAA Terms¶
| Term | Definition as Used in This Document |
|---|---|
| ePHI | Electronic protected health information — individually identifiable health information transmitted or maintained in electronic media |
| Covered entity | Health plans, healthcare clearinghouses, and healthcare providers that transmit health information electronically |
| Business associate | A person or entity that performs functions involving use or disclosure of ePHI on behalf of a covered entity |
| Required specification | An implementation specification that must be implemented by all covered entities and business associates |
| Addressable specification | An implementation specification that must be implemented if reasonable and appropriate, or an equivalent alternative documented |
| Minimum necessary | The principle that access to ePHI should be limited to the minimum necessary to accomplish the intended purpose |
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 |
| 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 |
| Verified agent identity | A cryptographically verifiable declaration of which agent is operating within a governed session |
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 HIPAA Security Rule requirements that fall within that runtime scope.
Within scope: Technical access control at the agent dispatch boundary, audit controls for agent invocations, integrity controls for the governance layer, agent and module authentication, and pre-egress enforcement for outbound operations.
Outside SDOS Operational Boundary (must be addressed by complementary organizational controls): The following requirements are outside the operational boundary of a runtime governance framework and are not claimed here:
| Section | Requirement | Why Out of Scope |
|---|---|---|
| §164.310 | Physical safeguards — facility access, workstation security, device controls | Physical environment controls; no runtime analog |
| §164.308(a)(5) | Workforce training and sanctions policy | Organizational and HR obligation |
| §164.312(a)(2)(iv) | Encryption and decryption of ePHI at rest | Data-layer encryption; SDOS does not store or encrypt ePHI |
| §164.312(e)(2)(ii) | Encryption of ePHI in transit | Transmission-layer encryption; outside SDOS operational boundary |
| §164.314 | Business associate contracts and group health plan provisions | Contractual obligation; not addressable by technical controls |
| §164.308(a)(1) | Risk analysis of ePHI threats across the full environment | Enterprise risk analysis scope; SDOS provides runtime classification input only |
Explicitly naming out-of-scope requirements is a feature of a credible alignment document. SDOS covers the AI agent governance layer. A complete HIPAA technical safeguard implementation requires complementary controls at the data, transmission, and organizational layers.
Strongest Alignment: §164.312(b) and §164.312(d)¶
§164.312(b) — Audit Controls (Required)
Section 164.312(b) requires covered entities to implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use ePHI. SDOS satisfies this requirement at the AI agent dispatch layer through four controls:
- SDOS-AU-01 generates a structured audit record for every agent invocation, written before the result is returned — ensuring every governance decision is captured regardless of execution outcome.
- SDOS-AU-02 maintains the audit log in an append-only structure so that unauthorized alteration 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 agent identity and timestamp, before the result is returned.
Together these controls constitute the recording mechanism component of §164.312(b) at the AI agent layer — not a policy claim. The examination obligation (review workflows, analyst triage, follow-up on flagged events) is an organizational obligation that requires a complementary program operating alongside SDOS.
§164.312(c) — Integrity (Addressable)
Section 164.312(c) requires covered entities to implement policies and procedures to protect ePHI from improper alteration or destruction. SDOS addresses the governance integrity dimension — not ePHI content integrity. Governance baseline integrity (IN-01, IN-02), module manifest integrity (IN-03), and tamper-evident egress records (EN-04) ensure the AI governance layer has not been compromised. Complementary data-layer controls are required to satisfy the ePHI content integrity obligation. Mapping strength: Partial — Governance Layer Only.
§164.312(d) — Authentication (Required)
Section 164.312(d) requires covered entities to implement procedures to verify that a person or entity seeking access to ePHI is who they claim to be. SDOS satisfies this at the AI agent boundary:
- SDOS-IA-01 (Attested Agent Identity) provides cryptographically verifiable identity for every agent operating within a governed session — ensuring the audit trail reflects which agent acted.
- SDOS-IA-02 (Attested Module Identity) verifies module identity before activation, preventing unauthorized or substituted modules from operating within the governed pipeline.
Full Mapping Table — Technical Safeguards (§164.312)¶
| Standard | Implementation Specification | Type | Relevant SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|---|---|
| §164.312(a)(1) Access Control | Unique user identification | Required | SDOS-IA-01 | Strong | Verified agent identity provides unique, verifiable identification for every agent operating in a governed session |
| §164.312(a)(1) Access Control | Emergency access procedure | Required | SDOS-GV-03, SDOS-EN-03 | Partial — Gate Control | Default-deny (GV-03) and fail-closed (EN-03) define the access posture under emergency conditions. Emergency access procedures for human operators are organizational |
| §164.312(a)(1) Access Control | Automatic logoff | Addressable | SDOS-EN-03 | Partial — Session Halt | Fail-closed degradation halts agent sessions when governance is unavailable. Timed session logoff for human users is outside SDOS scope |
| §164.312(a)(1) Access Control | Encryption and decryption | Addressable | — | Out of Scope | ePHI encryption is a data-layer control; SDOS does not store or encrypt ePHI |
| §164.312(b) Audit Controls | (No sub-specifications) | Required | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03, SDOS-EN-04 | Partial — Recording Mechanism | Section 164.312(b) requires covered entities to "record and examine" activity in systems containing or using ePHI. SDOS satisfies the recording obligation directly: complete per-invocation audit trail, append-only integrity, dual repository, tamper-evident egress. The examination obligation — review workflows, analyst triage, follow-up on flagged events — is an organizational obligation outside SDOS scope. OCR enforcement (e.g., Memorial Healthcare 2017, NYP/Columbia 2014) has historically focused on the examination side; covered entities relying on SDOS for §164.312(b) must pair the recording substrate with an organizational examination program. |
| §164.312(c)(1) Integrity | Authenticate or detect alteration/destruction of ePHI | Required | SDOS-IN-01, SDOS-IN-02, SDOS-IN-03, SDOS-EN-04 | Partial — Governance Layer Only | SDOS verifies integrity of the governance layer, not ePHI content. Governance baseline integrity verification and tamper-evident egress records address the governance integrity dimension. Complementary data-layer controls are required to satisfy the full ePHI integrity requirement. |
| §164.312(c)(2) Integrity | Electronic mechanism to corroborate ePHI has not been altered | Addressable | SDOS-AU-02, SDOS-EN-04 | Partial — Governance Layer Only | Append-only log (AU-02) and tamper-evident egress records (EN-04) provide the corroboration mechanism for governance events at the agent dispatch layer. ePHI content integrity requires complementary data-layer controls. |
| §164.312(d) Authentication | Person or entity authentication | Required | SDOS-IA-01, SDOS-IA-02 | Strong | Verified agent identity (IA-01) and verified module identity (IA-02) provide cryptographic authentication at the AI agent boundary |
| §164.312(e)(1) Transmission Security | Guard against unauthorized access during transmission | Required | SDOS-EN-01, SDOS-EN-04 | Partial — Governance Layer Only | Pre-egress policy enforcement (EN-01) blocks unauthorized AI agent outbound operations; governed egress audit (EN-04) records every governed transmission. SDOS governs the AI agent dispatch layer, not ePHI transmission itself. Complementary data-layer transmission controls are required for full §164.312(e)(1) compliance. |
| §164.312(e)(2) Transmission Security | Encryption of ePHI in transit | Addressable | — | Out of Scope | Transport-layer encryption is outside SDOS operational boundary |
Full Mapping Table — Administrative Safeguards (§164.308)¶
| Standard | Implementation Specification | Type | Relevant SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|---|---|
| §164.308(a)(1) Security Management | Risk analysis | Required | SDOS-RM-01, SDOS-RM-03 | Partial — Runtime Input | Dispatch-time risk classification (RM-01) and risk-floor binding (RM-03) provide runtime risk assessment input. Full enterprise risk analysis is an organizational obligation |
| §164.308(a)(1) Security Management | Risk management | Required | SDOS-RM-01, SDOS-RM-02, SDOS-RM-03, SDOS-GV-02 | Partial — Runtime Measures | SDOS controls implement runtime risk management measures. Organizational risk management program is outside scope |
| §164.308(a)(3) Workforce Access | Authorization and supervision | Addressable | SDOS-AD-01, SDOS-GV-03, SDOS-EN-02 | Partial — Agent Access Gate | Default-deny admission (AD-01) and pre-admission (GV-03) enforce access authorization at the AI agent layer. Human workforce access management is organizational |
| §164.308(a)(4) Access Management | Isolating clearinghouse functions | Required | SDOS-GV-04, SDOS-EN-02 | Partial — Isolation Enforcement | Cross-module continuity (GV-04) and subordinate-side gate (EN-02) enforce functional isolation at the module boundary |
| §164.308(a)(5) Workforce Training | Training and awareness | Addressable | — | Out of Scope | Workforce training is an organizational obligation with no runtime substitute |
| §164.308(a)(6) Incident Procedures | Response and reporting | Required | SDOS-AU-01, SDOS-AU-02, SDOS-AU-03 | Weak — Substrate Only | SDOS audit records provide the forensic substrate for incident response procedures. Incident response and reporting are organizational obligations |
| §164.308(a)(7) Contingency Plan | Emergency mode operation | Required | — | Out of Scope — Inverse Posture | Section 164.308(a)(7) governs ePHI availability and continuity during emergencies (Data Backup Plan, Disaster Recovery Plan, Emergency Mode Operation). SDOS-EN-03's fail-closed halt is a confidentiality/integrity-preservation measure that may deny availability when governance fails — the opposite posture. Mapping a halt control to a contingency-availability control is conceptually inverted. Covered entities must implement organizational ePHI continuity controls operating independently of SDOS governance, with explicit consideration of how SDOS halt behavior interacts with the §164.308(a)(7)(ii)(A) Data Backup Plan. |
| §164.308(a)(8) Evaluation | Technical and nontechnical evaluation | Required | SDOS-IN-01, SDOS-IN-02, SDOS-IN-03 | Partial — Continuous Verification | Governance baseline integrity verification provides continuous automated evaluation of the technical control layer |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | §164.308(a)(1): documented risk management controls at the module layer |
| SDOS-GV-02 — Governance-Tiered Model Selection | §164.308(a)(1): risk-proportionate resource allocation |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | §164.312(a)(1): access control — default-deny as an access restriction mechanism |
| SDOS-GV-04 — Cross-Module Governance Continuity | §164.308(a)(4): isolation of functions across module boundaries |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | §164.308(a)(1): enforcement independent of underlying model behavior |
Risk Management (RM)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | §164.308(a)(1): runtime risk classification input to enterprise risk management |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | §164.308(a)(1): risk-proportionate governance resourcing |
| SDOS-RM-03 — Risk-Floor Model Binding | §164.308(a)(1): minimum capability floor for elevated-risk agent operations |
Enforcement (EN)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | §164.312(e)(1): guards against unauthorized access during transmission |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | §164.308(a)(4): secondary enforcement at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | §164.312(a)(1): automatic logoff analog |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | §164.312(b): audit mechanism; §164.312(e)(1): transmission security |
Identity and Attestation (IA)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | §164.312(a)(1): unique user identification; §164.312(d): person/entity authentication |
| SDOS-IA-02 — Attested Module Identity | §164.312(d): authentication of entities accessing governed operations |
Audit (AU)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | §164.312(b): hardware/software mechanism to record activity |
| SDOS-AU-02 — Append-Only Audit Log Integrity | §164.312(b): tamper-evident activity record; §164.312(c)(2): corroboration mechanism |
| SDOS-AU-03 — Dual Audit Trail | §164.312(b): audit continuity and resilience |
Integrity (IN)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | §164.312(c)(1): integrity verification of the governance control layer |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | §164.312(c)(1): detection and response to unauthorized alteration |
| SDOS-IN-03 — Module Manifest Integrity | §164.312(c)(1): cryptographic verification before module activation |
Deliberation (DE)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-DE-01 — Governed Multi-Agent Deliberation | Architectural alignment: structured evaluation independent of the system under evaluation; supports §164.308(a)(1) risk management intent |
| SDOS-DE-02 — Convergence-Based Decision Record | Architectural alignment: durable record of governance deliberation; supports §164.312(b) audit record intent |
Admission (AD)¶
| Control | HIPAA Security Rule Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | §164.312(a)(1): access control — default-deny posture at the agent admission boundary |
Regulatory Currency¶
This mapping reflects the HIPAA Security Rule as currently in force (45 CFR Part 164). HHS published a proposed Security Rule update on January 6, 2025 (NPRM, RIN 0945-AA22). The NPRM, if finalized as proposed, would:
- Eliminate the Required/Addressable distinction — all implementation specifications would become Required.
- Mandate encryption of ePHI at rest and in transit, removing the current Addressable status of §164.312(a)(2)(iv) and §164.312(e)(2)(ii).
- Mandate multi-factor authentication for ePHI access.
- Mandate vulnerability scanning every six months and annual penetration testing.
If the NPRM is finalized as proposed, several entries in this mapping table that are currently rated "Out of Scope" (encryption-related) or "Addressable" (automatic logoff) would become Required. SDOS scope boundaries do not change under the finalized rule, but Out-of-Scope rows must be reread under the new Required framing — and complementary data-layer controls become Required obligations rather than Addressable.
Organizations should review this mapping against any finalized rule changes once HHS publishes the final rule.
Relationship to NIST AI RMF 1.0, EU AI Act, and DORA¶
SDOS is also mapped to the NIST AI Risk Management Framework (AI RMF) 1.0, the EU AI Act, and DORA. For healthcare organizations deploying AI agents, SDOS controls provide a unified runtime governance layer that addresses technical safeguard obligations across multiple frameworks simultaneously.
| SDOS Domain | NIST AI RMF Function | HIPAA Section | EU AI Act Article |
|---|---|---|---|
| Audit (AU) | GOVERN, MANAGE | §164.312(b) | Art. 12 |
| Enforcement (EN) | MANAGE | §164.312(e)(1) | Art. 9, 14 |
| Integrity (IN) | MEASURE | §164.312(c) | Art. 17 |
| Identity & Attestation (IA) | GOVERN | §164.312(d) | Art. 14, 17 |
| Risk Management (RM) | MAP, MANAGE | §164.308(a)(1) | Art. 9 |
Full NIST AI RMF mapping: SDOS Control Catalog and Reference Document v1.9
EU AI Act alignment: SDOS — EU AI Act Alignment
DORA alignment: SDOS — DORA 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 HIPAA Security Rule requirements: [email protected]
SDOS Runtime Governance Framework — HIPAA Security Rule Alignment. Version 1.3. Published 2026-05-03.