Skip to content

SDOS Runtime Governance Framework — CIS Controls v8 Alignment

Control Mapping to CIS Controls v8

SDOS Version: 1.9
Standard: CIS Critical Security Controls Version 8
Published: May 2021
Note: CIS v8.1 introduced supplemental implementation guidance without changing control numbers or Safeguard definitions. This mapping is compatible with v8.1.
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 CIS Critical Security Controls v8. It is intended to assist security teams, CISOs, and compliance practitioners evaluating SDOS as a technical control layer for AI systems within CIS-aligned security programs.

This is an informative alignment document. It does not constitute a CIS-certified assessment or a determination of CIS Controls implementation status. Organizations should engage qualified practitioners for formal Implementation Group (IG) assessments.


Applicability

This document applies to organizations deploying agentic AI workflows within environments governed by CIS Controls v8. It is relevant when:

  • An AI agent operates within scope of systems subject to CIS Controls implementation, or
  • The organization is evaluating whether a runtime governance layer satisfies specific CIS Safeguards at the AI agent boundary, or
  • A security team is documenting AI-layer controls against an existing CIS Controls program.

This document does not address CIS Controls Safeguards for endpoint protection, network monitoring, malware defenses, or application security — 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 Safeguard.
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 Safeguard.
Out of Scope The Safeguard falls entirely outside the operational boundary of a runtime governance framework.

CIS Implementation Groups

CIS Controls v8 organizes Safeguards into three Implementation Groups (IGs) based on organizational risk profile:

IG Profile
IG1 Basic cyber hygiene — small/low-risk organizations
IG2 Foundational controls — mid-size organizations with sensitive data
IG3 Advanced controls — large or high-risk organizations

SDOS most directly addresses IG2 and IG3 Safeguards in the audit, access control, and account management domains.


Glossary

Term Definition
CIS Controls CIS Critical Security Controls — a prioritized set of actions to protect against known attack techniques
Safeguard An individual action within a CIS Control
IG Implementation Group — risk-tiered grouping of Safeguards (IG1/IG2/IG3)
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 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.

Scope Statement

SDOS operates at the point of dispatch. In a CIS Controls context, SDOS governs what AI agents are permitted to do before they execute — enforcing access policy, logging every invocation, and blocking unauthorized outbound operations. This covers the agent-layer slice of CIS Controls technical requirements.

Within scope: Access control enforcement at dispatch, audit log generation and integrity, agent and module identity verification, pre-egress enforcement, and governance baseline integrity.

Outside SDOS Operational Boundary (must be addressed by complementary organizational controls):

CIS Control Safeguard Area Why Out of Scope
CIS Control 1 Inventory and Control of Enterprise Assets Asset discovery — infrastructure layer
CIS Control 2 Inventory and Control of Software Assets Software inventory — pre-deployment
CIS Control 7 Continuous Vulnerability Management Vulnerability scanning — security operations layer
CIS Control 9 Email and Web Browser Protections Email/browser security — endpoint layer
CIS Control 10 Malware Defenses Anti-malware — endpoint protection layer
CIS Control 12 Network Infrastructure Management Network architecture — infrastructure layer
CIS Control 16 Application Software Security SDLC and code review — pre-deployment

Strongest Alignment: Controls 5, 6, and 8

CIS Control 8 — Audit Log Management

CIS Control 8 mandates collection, protection, and review of audit log data. SDOS satisfies the technical log generation and protection Safeguards at the AI agent layer:

  • SDOS-AU-01 generates a structured audit record for every agent invocation — every access event is captured before the result is returned (Safeguard 8.2: Collect Audit Logs).
  • SDOS-AU-02 maintains logs in an append-only structure, directly satisfying Safeguard 8.3's retention and protection requirement.
  • SDOS-AU-03 writes records to two independent repositories, satisfying Safeguard 8.3's redundancy objective.
  • SDOS-EN-04 writes a tamper-evident record of every governed egress operation.

CIS Control 6 — Access Control Management

CIS Control 6 mandates that access to assets is managed through the principle of least privilege. SDOS implements this at the agent dispatch layer:

  • SDOS-GV-01 allows only explicitly configured modules to activate — access is defined by policy, not default (Safeguard 6.1: Establish Access Granting Process).
  • SDOS-GV-03 and SDOS-AD-01 implement default-deny — every agent starts without access and must be explicitly admitted (Safeguard 6.3: Require MFA / least-privilege baseline).
  • SDOS-EN-01 and SDOS-EN-02 enforce access policy at the execution boundary, not merely at configuration time.

CIS Control 5 — Account Management

CIS Control 5 mandates that accounts are uniquely identified and managed throughout their lifecycle. SDOS provides this at the AI agent boundary:

  • SDOS-IA-01 provides cryptographically verified unique identity for every agent operating in a governed session (Safeguard 5.3: Disable Dormant Accounts analog — agents without verified identity cannot activate).
  • SDOS-IA-02 verifies module identity before activation, ensuring no unregistered component executes (Safeguard 5.1: Establish and Maintain Inventory of Accounts).

Full Mapping Table

CIS Controls v8 Safeguard SDOS Controls Mapping Strength Notes
5.1 Establish and maintain inventory of accounts IA-01, IA-02 Strong Verified agent + module identity creates a verified account inventory at the AI agent layer
5.2 Use unique passwords IA-01 Partial — identity scope SDOS provides cryptographic agent identity verification; human password policy is outside runtime scope
5.3 Disable dormant accounts GV-01, IA-02 Strong Unregistered or inactive modules cannot activate — equivalent to account dormancy enforcement at the AI agent dispatch layer. CIS 5.3's full scope (45-day inactivity threshold for human accounts, quarterly service account reviews) is an organizational obligation; SDOS coverage is scoped to AI agent and module activation.
5.4 Restrict administrator privileges GV-02, RM-03, AD-01 Strong Risk-tiered model selection + default-deny admission = privileged access restriction at agent level
6.1 Establish and maintain access granting process GV-01, GV-03, AD-01 Strong Config-governed module activation + default-deny = formalized access granting at dispatch
6.2 Establish and maintain access revoking process GV-01, IN-02 Partial — Configuration Enforcement Once governance configuration is updated to revoke access, SDOS-GV-01 enforces the revocation at dispatch and IN-02 detects configuration drift. The access revoking process — defining revocation triggers, documented procedures, periodic review cycles, and who executes revocation — is an organizational obligation outside the dispatch boundary.
6.3 Require MFA for externally-exposed applications IA-01, IA-02 Partial — Identity Substrate SDOS provides the cryptographic key/manifest factor ("something you have") for agent identity verification. Full MFA for externally-exposed applications requires a second factor from human IAM integration — not provided by runtime governance.
6.4 Require MFA for remote network access EN-01, EN-02, IA-01 Partial — Identity Substrate Pre-egress enforcement + cryptographic identity verification cover the AI agent outbound boundary. Full MFA for remote access requires a second authentication factor from human IAM integration — not provided by runtime governance.
6.8 Define and maintain role-based access control GV-02, RM-01, RM-03 Strong Risk-tiered model selection + dispatch-time classification = role-based access at agent layer
8.1 Establish and maintain audit log management process AU-01, AU-02, AU-03 Strong Per-invocation records + append-only integrity + dual trail = full audit log management substrate
8.2 Collect audit logs AU-01, EN-04 Strong Every agent invocation and governed egress operation produces a structured audit record
8.3 Ensure adequate audit log storage AU-03 Partial — structural only Dual audit trail provides structural redundancy; storage capacity is a deployment configuration obligation
8.4 Standardize time synchronization AU-01 Partial — record scope Per-invocation records include timestamps; NTP synchronization is an infrastructure-layer obligation
8.5 Collect detailed audit logs AU-01, IA-01 Strong Structured audit records include agent identity, operation type, risk classification, and outcome
8.7 Collect URL request audit logs EN-01, EN-04 Partial — governed egress Pre-egress enforcement and tamper-evident audit cover AI agent outbound operations; general URL logging is infrastructure-layer
8.11 Conduct audit log reviews AU-01, AU-02 Weak — Substrate Only SDOS generates and protects logs; anomaly review requires external SIEM or analyst workflow
4.1 Establish and maintain a secure configuration process IN-01, GV-01 Strong Governance baseline integrity verification + config-governed activation = secure configuration enforcement at the AI governance layer
4.2 Establish and maintain a secure configuration process for network infrastructure IN-01, IN-03 Partial — governance scope Baseline integrity + module manifest integrity cover governance configuration; network infrastructure configuration is infrastructure-layer
4.3 Configure automatic session locking on enterprise assets EN-03 Partial — governance scope Fail-closed degradation implements governance session halt; endpoint session lock is outside runtime scope
4.8 Uninstall or disable unnecessary services on enterprise assets GV-01, AD-01 Strong Config-governed activation + default-deny = only explicitly configured modules active; no implicit functionality
13.1 Centralize security event alerting AU-01, AU-02, AU-03 Weak — Substrate Only SDOS generates structured audit data; centralized alerting requires external SIEM integration
16.1 Establish and maintain a secure application development process IN-03, GV-01 Partial — module scope Module manifest integrity + config-governed activation cover AI module integrity; general SDLC is pre-deployment

Mapping by SDOS Domain

Governance (GV)

Control CIS Controls v8 Relevance
SDOS-GV-01 — Configuration-Governed Module Activation CIS 6.1: access granting process; CIS 4.1: baseline configuration
SDOS-GV-02 — Governance-Tiered Model Selection CIS 6.8: role-based access control tiering
SDOS-GV-03 — Default-Deny Pre-Admission Policy CIS 6.1/6.2: access enforcement foundation
SDOS-GV-04 — Cross-Module Governance Continuity CIS 5.1: account inventory continuity across module boundaries
SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement CIS 6.1: enforcement independent of underlying system behavior

Risk Management (RM)

Control CIS Controls v8 Relevance
SDOS-RM-01 — Dispatch-Time Risk Classification CIS 6.8: risk-based access tiering at point of execution
SDOS-RM-02 — Complexity-Tiered Resource Allocation CIS 6.8: risk-proportionate resource allocation
SDOS-RM-03 — Risk-Floor Model Binding CIS 5.4: minimum capability floor for elevated-risk operations

Enforcement (EN)

Control CIS Controls v8 Relevance
SDOS-EN-01 — Pre-Egress Policy Enforcement CIS 6.4: access enforcement at execution boundary
SDOS-EN-02 — Subordinate-Side Enforcement Gate CIS 6.4: secondary enforcement at module boundary
SDOS-EN-03 — Fail-Closed Degradation CIS 4: operational resilience posture at the governance layer
SDOS-EN-04 — Governed Egress with Tamper-Evident Audit CIS 8.2: audit record for every governed output operation

Identity and Attestation (IA)

Control CIS Controls v8 Relevance
SDOS-IA-01 — Attested Agent Identity CIS 5.1: account inventory; CIS 8.5: identity in audit records
SDOS-IA-02 — Attested Module Identity CIS 5.1: module account inventory before activation

Audit (AU)

Control CIS Controls v8 Relevance
SDOS-AU-01 — Per-Invocation Audit Record CIS 8.2/8.5: audit log generation for every agent access event
SDOS-AU-02 — Append-Only Audit Log Integrity CIS 8.3: protection from unauthorized modification
SDOS-AU-03 — Dual Audit Trail CIS 8.3: audit log storage redundancy

Integrity (IN)

Control CIS Controls v8 Relevance
SDOS-IN-01 — Governance Baseline Integrity Verification CIS 4.1: secure configuration enforcement at governance layer
SDOS-IN-02 — Baseline Drift Detection and System Halt CIS 4.1: automated detection of unauthorized governance configuration change
SDOS-IN-03 — Module Manifest Integrity CIS 16.1: integrity verification before module activation

Admission (AD)

Control CIS Controls v8 Relevance
SDOS-AD-01 — Default-Deny Agent Pre-Admission CIS 6: default-deny as the access control foundation

Risk Scoring (RS)

Control CIS Controls v8 Relevance
SDOS-RS-01 — Quantified Risk Scoring and ROSI Evaluation No direct CIS Controls v8 analog. Dispatch-time risk quantification generates the measurement substrate that feeds CIS 18 (Penetration Testing) remediation prioritization and organizational risk management workflows — Weak — Substrate Only.

Controls Without Direct SDOS Analog

CIS Control 14 (Security Awareness) and CIS Control 17 (Incident Response Management) address organizational and process obligations that fall outside the operational boundary of a runtime governance framework. SDOS audit data (AU-01/AU-02/AU-03) serves as input into incident response workflows but does not satisfy the IR program requirements of CIS Control 17.

The SDOS Deliberation (DE) domain — which governs multi-agent deliberation panels and convergence-based decision records — has no direct CIS Controls v8 analog. This domain addresses AI-specific governance obligations that predate the current CIS Controls scope.


Relationship to Other Frameworks

SDOS is also mapped to NIST AI RMF 1.0, EU AI Act, DORA, HIPAA, and PCI-DSS v4.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.10


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 CIS Controls v8 requirements: [email protected]


SDOS Runtime Governance Framework — CIS Controls v8 Alignment. Version 1.3. Published 2026-05-03.

View library changelog →