SDOS Runtime Governance Framework — SOC 2 Alignment¶
SDOS Version: 1.9
Standard: SOC 2 — Trust Services Criteria (2017 with 2022 revisions), AICPA
Framework: AICPA TSC (CC, A, PI, C, P categories)
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 AICPA SOC 2 Trust Services Criteria (TSC). It is intended to assist service organizations, auditors, and security teams evaluating SDOS as a technical control layer within SOC 2 audit scope — particularly where AI agent operations fall within or adjacent to systems covered by a SOC 2 engagement.
This is an informative alignment document. It does not constitute a SOC 2 report, an auditor's opinion, or a determination of TSC compliance. Organizations must engage a licensed CPA firm for formal SOC 2 examinations.
Applicability¶
This document applies to service organizations deploying agentic AI workflows within systems subject to SOC 2 examination. It is relevant when:
- An AI agent operates within or adjacent to systems in scope of a SOC 2 Type I or Type II engagement, or
- A service organization is documenting AI agent governance controls in a description of the system for SOC 2 purposes, or
- An auditor is evaluating whether runtime governance controls satisfy specific Trust Services Criteria at the AI agent boundary.
This document focuses on the Common Criteria (CC) category, which applies to all SOC 2 engagements, and the Availability (A) and Processing Integrity (PI) categories where SDOS has meaningful alignment.
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 criterion. |
| Partial — [qualifier] | SDOS addresses a defined subset. The qualifier identifies what is covered and what requires additional controls. |
| Weak — Substrate Only | SDOS produces data or infrastructure that enables compliance but does not itself satisfy the criterion. |
| Out of Scope | The criterion falls entirely outside the operational boundary of a runtime governance framework. |
SOC 2 Trust Services Criteria Categories¶
| Category | Abbreviation | Applicability |
|---|---|---|
| Security | CC | Required for all SOC 2 engagements |
| Availability | A | Optional — systems with uptime commitments |
| Processing Integrity | PI | Optional — systems where complete, accurate processing is critical |
| Confidentiality | C | Optional — systems handling confidential information |
| Privacy | P | Optional — systems handling personal information |
Glossary¶
| Term | Definition |
|---|---|
| TSC | Trust Services Criteria — AICPA framework for SOC 2 examinations |
| CC | Common Criteria — the security category required in all SOC 2 engagements |
| SOC 2 Type I | Point-in-time assessment of control design suitability |
| SOC 2 Type II | Period-of-time assessment of control operating effectiveness |
| Point of dispatch | The moment a task is assigned to an agent before tool execution; the primary SDOS enforcement boundary |
| Governed egress | Outbound operations subject to pre-execution policy enforcement before results are returned |
| Fail-closed degradation | When governance infrastructure is unavailable, SDOS halts operations requiring active governance evaluation |
Scope Statement¶
SDOS operates at the point of dispatch. In a SOC 2 context, SDOS governs what AI agents are permitted to do before they execute — enforcing access policy, logging every invocation, and blocking unauthorized operations. This covers the agent-layer slice of the Common Criteria and selected additional TSC categories.
Within scope: Logical access controls (CC6), system operations monitoring (CC7), change management (CC8), risk classification substrate at the dispatch layer (CC3), availability controls at the agent layer (A1), and processing integrity authorization-boundary controls (PI1).
Note on CC1 and CC2. The SOC 2 Common Criteria CC1 (Control Environment) and CC2 (Communication and Information) are mandatory components of every SOC 2 examination and are always in scope for the auditor. SDOS does not implement CC1 or CC2 — those are organizational obligations of the service organization. The "Outside SDOS Operational Boundary" table below identifies where complementary organizational controls are required; it does not exclude these criteria from the auditor's testing scope.
Outside SDOS Operational Boundary (must be addressed by complementary organizational controls):
| TSC Category | Content | Why Out of Scope |
|---|---|---|
| CC1 | Control environment | Organizational governance and leadership |
| CC2 | Communication and information | Organizational communication obligations |
| P (Privacy) | Personal information handling | Data processing and storage layer |
| C (Confidentiality) | Confidential information protection | Data storage and encryption layer |
| Physical security criteria | Physical access | Physical security layer |
Points of Focus and Sampling Considerations¶
Points of Focus (PoF). SOC 2 testing is performed against the AICPA's points of focus for each Trust Services Criterion, not against the criterion text alone. The mapping table identifies which SDOS controls satisfy each criterion at the design level. For an auditor preparing a Type I or Type II testing plan, the SDOS controls primarily address the following points of focus categories: identity and credentialing PoFs under CC6.1/CC6.2/CC6.3; system operations and anomaly detection PoFs under CC7.2/CC7.3; change authorization and integrity PoFs under CC8.1; and audit record generation, protection, and review PoFs under CC7.2 (cross-criterion). Auditors should map each cited control to specific PoFs against the AICPA's current Points of Focus library before drafting test steps.
Sampling and population considerations. SDOS-AU-01 generates a per-invocation audit record. In a 100-agent fleet operating at typical agentic-workflow rates, the population for a Type II audit period can range from hundreds of thousands to tens of millions of records. For sampling:
- Population definition: the set of governed agent invocations during the audit period, derived from the SDOS-AU-01 record stream.
- Sampling unit: a single governed invocation (recommended) or an admission event (for AD-01 testing).
- Completeness assertion: the most common Type II finding category for log-based controls. Auditors should test record sequence integrity (AU-02 append-only verification) and dual-repository reconciliation (AU-03) to corroborate that the audit population is complete.
- Stratification: sampling should reflect the distribution of risk classifications produced by RM-01 to ensure higher-risk invocations are adequately represented.
These are starting-point considerations; final sampling design is the auditor's professional judgment per AICPA AT-C 105.
Strongest Alignment: CC6, CC7, and CC8¶
CC6 — Logical and Physical Access Controls
CC6 mandates that access to systems and data is restricted to authorized users and processes. SDOS implements this at the agent dispatch layer:
- SDOS-GV-03 and SDOS-AD-01 satisfy CC6.1 (Logical access security measures) — default-deny admission gate ensures only authorized agents operate.
- SDOS-EN-01 and SDOS-EN-02 satisfy CC6.1 and CC6.6 (Restrict access to the system) — pre-egress enforcement and subordinate gate enforce access at the execution boundary.
- SDOS-IA-01 and SDOS-IA-02 satisfy CC6.2 (Prior to issuing credentials) — verified identity ensures every agent and module is uniquely identified before operating.
- SDOS-GV-02 and SDOS-RM-03 satisfy CC6.3 (Role-based access) — risk-tiered model selection enforces capability-appropriate access.
CC7 — System Operations
CC7 mandates that systems are monitored and anomalies are detected and addressed. SDOS provides:
- SDOS-AU-01 satisfies CC7.2 (Monitor system components) — per-invocation audit records provide continuous monitoring data at the AI agent layer.
- SDOS-IN-01 and SDOS-IN-02 satisfy CC7.3 (Evaluate security events) — baseline integrity verification and drift detection provide automated anomaly detection with halt response.
- SDOS-AU-02 satisfies CC7.2's integrity requirement — append-only logs ensure monitoring data is not tampered with.
CC8 — Change Management
CC8 mandates that changes to infrastructure are authorized, documented, and tested. SDOS provides:
- SDOS-IN-01 satisfies CC8.1 (Changes are authorized) — governance baseline integrity verification ensures no unauthorized configuration changes take effect.
- SDOS-IN-02 satisfies CC8.1 (Changes are tested and approved) — baseline drift detection halts operations if unauthorized changes are detected before execution.
- SDOS-IN-03 satisfies CC8.1 at the module level — module manifest integrity verifies the integrity of AI modules before activation.
Full Mapping Table¶
| SOC 2 TSC Criterion | SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|
| CC3.1 Risk assessment process | RM-01, RM-02 | Partial — Dispatch-Layer Risk Tiering | Dispatch-time risk classification provides a continuous, automated risk tiering mechanism at each agent execution. CC3.1's risk assessment process obligation operates at the organizational level — identifying, analyzing, and managing risks to organizational objectives. SDOS provides the technical risk classification substrate at the AI agent layer; the organizational risk assessment process is a management obligation outside SDOS scope. |
| CC3.2 Risk identification | RM-01, IN-01, IN-02 | Partial — Risk Substrate | Dispatch-time risk classification + governance drift detection provide technical risk identification signals at the AI agent and governance configuration layers. CC3.2's risk identification obligation includes identifying risks across the organization's operations, assets, and environment — an organizational-scope obligation for which SDOS contributes a technical data substrate. |
| CC5.2 Select and develop control activities | GV-01, GV-03, EN-01 | Weak — Substrate Only | SDOS is itself a control activity — it does not implement the organizational process for selecting and developing control activities that CC5.2 governs. SDOS audit data and governance baseline records can support an organization's control activity documentation, but the selection, design, and management of the control program is an organizational obligation outside SDOS scope. |
| CC6.1 Logical access security measures | GV-03, AD-01, EN-01, EN-02 | Strong | Default-deny + pre-egress enforcement + subordinate gate = logical access restriction at AI agent layer |
| CC6.2 Prior to issuing system credentials | IA-01, IA-02 | Strong | Cryptographic identity verification for agents and modules before any operation |
| CC6.3 Role-based access and least privilege | GV-02, RM-03, AD-01 | Strong | Risk-tiered model selection + risk-floor binding + default-deny = role-based least-privilege enforcement |
| CC6.6 Restrict access to authorized users | GV-03, EN-01, EN-02, AD-01 | Strong | Config-governed activation + pre-egress enforcement = authorized-access-only operation |
| CC6.7 Restrict transmission of confidential information | EN-01, EN-02, EN-04 | Strong | Pre-egress enforcement governs what AI agents can transmit; tamper-evident audit records each transmission event |
| CC6.8 Prevent unauthorized software | GV-01, IA-02, IN-03 | Strong | Config-governed activation + verified module identity + manifest integrity = unauthorized software prevention |
| CC7.1 Detect and monitor for new vulnerabilities | IN-01, IN-02 | Partial — governance scope | Baseline integrity + drift detection cover governance configuration; general vulnerability scanning is infrastructure-layer |
| CC7.2 Monitor system components for anomalies | AU-01, AU-02, IN-01, IN-02 | Strong | Per-invocation records + append-only integrity + baseline monitoring = anomaly detection substrate at AI agent layer |
| CC7.3 Evaluate and respond to security events | IN-02, EN-03, AU-01 | Partial — Technical Containment | Drift detection (IN-02) + fail-closed halt (EN-03) = automated technical containment at the governance layer. "Response" here refers to governance-layer containment — not organizational incident response. Investigation, escalation, and recovery are organizational obligations outside SDOS scope. |
| CC7.4 Respond to identified security incidents | EN-03, AU-01, AU-02 | Partial — containment | Fail-closed degradation provides automated containment; IR process is organizational |
| CC7.5 Identify and develop remediation activities | IN-01, IN-02, AU-01 | Weak — Substrate Only | SDOS provides detection data and audit records; remediation planning is organizational |
| CC8.1 Authorize, design, test changes | IN-01, IN-02, IN-03 | Strong | Baseline integrity + drift detection + module manifest = change authorization and integrity at governance layer |
| CC9.1 Identify and assess risk from vendors | — | Weak — Substrate Only | CC9.1 governs the AICPA vendor management lifecycle: pre-engagement risk identification, due diligence, ongoing monitoring, and termination. SDOS audit data and dispatch-time classification can feed an organization's vendor monitoring program, but SDOS does not perform the procurement, qualification, contractual due diligence, or termination obligations that CC9.1 actually tests. Vendor management is an organizational obligation outside SDOS operational boundary. |
| CC9.2 Monitor compliance of vendors | AU-01, IN-01 | Partial — monitoring data | Per-invocation audit + baseline integrity provide vendor compliance monitoring substrate |
| A1.1 Availability — capacity planning | RM-02, EN-03 | Partial — governance scope | Complexity-tiered resource allocation + fail-closed degradation cover governance layer availability; infrastructure capacity planning is out of scope |
| A1.2 Availability — environmental protection | EN-03 | Weak — Substrate Only | Fail-closed degradation addresses governance infrastructure availability; physical environmental protection is out of scope |
| A1.3 Availability — recovery procedures | EN-03, AU-03 | Partial — governance layer | Fail-closed halt + dual audit trail enable governance recovery; system recovery is infrastructure-layer |
| PI1.1 Processing integrity — inputs | GV-01, RM-01, AD-01 | Partial — Authorization Scope | Config-governed activation, dispatch-time classification, and default-deny enforce input authorization boundaries. PI1.1's accuracy and completeness obligations for input data are model- and pipeline-layer concerns outside SDOS scope. |
| PI1.2 Processing integrity — system processing | EN-01, EN-02, GV-05 | Partial — Authorization Scope | SDOS enforces authorization boundaries on processing operations (what an agent is permitted to do). PI1.2's correctness, completeness, and accuracy obligations for processing output (e.g., model output correctness) are model-layer concerns outside SDOS scope. Blocking an unauthorized egress does not validate the accuracy of the output that produced it. |
| PI1.3 Processing integrity — outputs | EN-04, AU-01 | Partial — Authorization Scope | Tamper-evident egress audit + per-invocation records establish that an output was authorized and capture what was emitted. PI1.3's output accuracy/completeness obligations remain a model- and pipeline-layer concern. |
| PI1.4 Processing integrity — stored items | AU-02, IN-01 | Partial — governance scope | Append-only audit integrity + baseline verification cover governance data; data storage integrity is infrastructure-layer |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | CC6.8/CC8.1: unauthorized software prevention and change authorization |
| SDOS-GV-02 — Governance-Tiered Model Selection | CC6.3: role-based access tiering |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | CC6.1/CC6.6: logical access restriction foundation |
| SDOS-GV-04 — Cross-Module Governance Continuity | CC6.2: identity continuity across module boundaries |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | PI1.2: processing integrity independent of model behavior |
Risk Management (RM)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | CC3.1/CC3.2: continuous risk assessment at execution |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | A1.1: governance layer capacity management |
| SDOS-RM-03 — Risk-Floor Model Binding | CC6.3: minimum capability floor as access restriction |
Enforcement (EN)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | CC6.1/CC6.7/PI1.2: access and transmission enforcement |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | CC6.1/PI1.2: secondary enforcement at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | A1.2/CC7.4: availability posture and incident containment |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | CC6.7/PI1.3: transmission restriction and output integrity |
Identity and Attestation (IA)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | CC6.2/CC6.6: credentialing and authorized access |
| SDOS-IA-02 — Attested Module Identity | CC6.2/CC6.8: module identity is verified before activation |
Audit (AU)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | CC7.2/PI1.3: monitoring and output integrity records |
| SDOS-AU-02 — Append-Only Audit Log Integrity | CC7.2: tamper-proof monitoring data |
| SDOS-AU-03 — Dual Audit Trail | A1.3/CC9.2: recovery and vendor compliance monitoring |
Integrity (IN)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | CC7.1/CC8.1/PI1.4: vulnerability detection and change authorization |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | CC7.3/CC8.1: anomaly response and change control |
| SDOS-IN-03 — Module Manifest Integrity | CC6.8/CC8.1: module integrity before activation |
Admission (AD)¶
| Control | SOC 2 Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | CC6.1/CC6.6/PI1.1: access restriction at input boundary |
SOC 2 Context: AI Systems in Service Organization Audits¶
SOC 2 examinations are increasingly encountering AI systems in scope — but audit programs rarely have established procedures for evaluating AI agent governance. The Common Criteria's CC6 (logical access) and CC7 (system operations) were written for traditional software systems. Agentic AI workflows introduce governance challenges that the criteria weren't designed to test: agents that make access decisions dynamically, that can invoke downstream tools at runtime, and that may behave differently depending on model alignment.
SDOS addresses this gap directly. The controls documented here provide auditors with a testable, mechanism-specific governance layer at the AI agent boundary — one that maps to existing CC criteria without requiring new audit procedures.
SOC 2 Type II: SDOS-AU-02 (append-only audit log integrity) and SDOS-AU-01 (per-invocation records) provide the period-of-time evidence trail that Type II opinions require. Specifically, SDOS-AU-02's append-only structure means every record in the log represents a governance decision made during the audit period — the population from which a Type II auditor can draw the sample for operating effectiveness testing.
Relationship to Other Frameworks¶
SDOS is also mapped to NIST AI RMF 1.0, EU AI Act, DORA, HIPAA, PCI-DSS v4.0, CIS Controls v8, ISO 42001, FedRAMP Rev 5, and CMMC 2.0. For organizations subject to multiple frameworks, SDOS controls address overlapping technical requirements simultaneously.
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 SOC 2 Trust Services Criteria: [email protected]
SDOS Runtime Governance Framework — SOC 2 Trust Services Criteria Alignment. Version 1.3. Published 2026-05-03. Last updated 2026-05-12.