SDOS Runtime Governance Framework — PCI-DSS v4.0 Alignment¶
SDOS Version: 1.9
Standard: PCI DSS v4.0 — Payment Card Industry Data Security Standard, Version 4.0
Note: PCI DSS v4.0.1 (a limited revision with no mapping-impacting requirement changes) was published May 2024. This mapping applies to both versions.
Effective Date: March 31, 2024
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 requirements of PCI DSS v4.0. It is intended to assist QSAs, CISOs, and payment security teams evaluating SDOS as a technical control layer for AI systems operating in or near cardholder data environments (CDEs).
This is an informative alignment document. It does not constitute a Report on Compliance (ROC), a Self-Assessment Questionnaire (SAQ), or a determination of PCI DSS compliance. Organizations must engage a Qualified Security Assessor (QSA) for formal compliance validation.
Applicability¶
This document applies to organizations deploying agentic AI workflows in environments where AI agents may access, process, route, or produce outputs that interact with cardholder data environment (CDE) systems. It is relevant when:
- An AI agent operates within scope of a CDE or is connected to in-scope systems, or
- The organization is evaluating whether a runtime governance layer satisfies specific PCI DSS technical requirements, or
- A service provider is demonstrating technical controls governing AI agent operations to a merchant or acquiring bank.
This document does not address PCI DSS requirements for cardholder data storage, encryption, physical security, or vendor qualification — 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 requirement. |
| 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 requirement. |
| Out of Scope | The requirement falls entirely outside the operational boundary of a runtime governance framework. |
Glossary¶
| Term | Definition |
|---|---|
| CDE | Cardholder data environment — systems that store, process, or transmit cardholder data or sensitive authentication data |
| CHD | Cardholder data — at minimum, the PAN (primary account number) |
| QSA | Qualified Security Assessor — PCI SSC-authorized entity that performs on-site PCI DSS assessments |
| 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 operates in three modes: (1) infrastructure unavailability — governance services offline, operations halt rather than proceed ungoverned; (2) baseline integrity failure — governance configuration drift detected, system halts until integrity is restored; (3) partial-degradation states — when a subset of governance controls is unavailable, operations subject to those controls halt while unaffected operations may continue. The net posture in all three modes is fail-closed: ungoverned execution is blocked, not permitted. |
Scope Statement¶
SDOS operates at the point of dispatch. In a CDE 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 PCI DSS 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):
| Requirement | Obligation | Why Out of Scope |
|---|---|---|
| Req 3 | Protect stored cardholder data | SDOS has no data storage function |
| Req 4 | Encrypt transmission of CHD | Network/transport layer encryption |
| Req 5 | Anti-malware software | Endpoint protection layer |
| Req 6 | Develop/maintain secure systems and software | SDLC and code review — pre-deployment |
| Req 9 | Physical access controls | Physical security layer |
| Req 12.6 | Security awareness education | Organizational/staffing obligation |
| Req 11.4 | Penetration testing program | External red-team activity |
Strongest Alignment: Requirements 7, 8, and 10¶
Note: Requirement 12.3 (Targeted Risk Analysis) is mapped as Partial — Risk Input Only. SDOS dispatch-time classification provides input to a PCI TRA but does not constitute the formal documented process required by 12.3.
Requirement 10 — Log and Monitor All Access to System Components and Cardholder Data
PCI DSS Requirement 10 mandates audit log generation, protection, and review for all access to CDE system components. SDOS satisfies the technical log generation and protection requirements 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.
- SDOS-AU-02 maintains logs in an append-only structure, directly satisfying Req 10.3.2's tamper-protection requirement.
- SDOS-AU-03 writes records to two independent repositories, satisfying Req 10.3.3's backup requirement.
- SDOS-EN-04 writes a tamper-evident record of every governed egress operation.
Requirement 7 — Restrict Access to System Components and Cardholder Data by Business Need to Know
Requirement 7 mandates that access to CDE components is restricted to only what is necessary. 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.
- SDOS-GV-03 and SDOS-AD-01 implement default-deny — every agent starts without access and must be explicitly admitted.
- SDOS-GV-02 and SDOS-RM-03 tier access by risk classification — higher-risk operations require higher-capability models.
Requirement 8 — Identify Users and Authenticate Access to System Components
Requirement 8 mandates unique identification and authentication for all users and system components. SDOS provides this at the AI agent boundary:
- SDOS-IA-01 provides cryptographically verified unique identity for every agent operating in a governed session.
- SDOS-IA-02 verifies module identity before activation, ensuring no unregistered component executes.
Full Mapping Table¶
| PCI-DSS v4.0 Requirement | SDOS Controls | Mapping Strength | Notes |
|---|---|---|---|
| 7.2 Access defined by need to know | GV-01, GV-03, AD-01 | Strong | Config-governed activation + default-deny = need-to-know enforcement at the AI agent dispatch layer. Coverage is scoped to the AI dispatch boundary; full system component scope requires complementary infrastructure access controls. |
| 7.2.2 Access by job classification and function | GV-02, RM-01, RM-03 | Strong | Risk-tiered model selection + dispatch-time risk classification = functional access tiering |
| 7.2.5 Application/system accounts managed | AD-01, IA-01 | Partial — Pre-Admission Gate | SDOS gates agent admission and verifies identity at the point of dispatch. Account provisioning, deprovisioning, access-right certification, and periodic review are organizational lifecycle obligations outside the dispatch boundary. |
| 7.3 Access controlled via access control system | GV-03, EN-01, EN-02 | Strong | Pre-egress enforcement + subordinate gate = enforced access control at the AI agent dispatch boundary. Coverage is scoped to the AI dispatch layer; full system component scope requires complementary infrastructure controls. |
| 8.2.1 All user/system IDs unique | IA-01, IA-02 | Strong | Verified agent and module identity ensures unique, verifiable identification per invocation |
| 8.6 System/application account behaviors managed | IA-01, GV-01, GV-04 | Partial — Runtime Session Scope | SDOS maintains verified identity and cross-module continuity within a governed session. Account behavior management requirements covering inter-session access reviews, inactivity disabling, and provisioning controls are organizational obligations outside the dispatch boundary. |
| 10.2 Audit logs implemented | AU-01, AU-03 | Strong | Per-invocation audit records + dual trail = full detection substrate at the agent layer |
| 10.2.1.1 Individual access to CDE logged | AU-01, IA-01 | Strong | Per-invocation record tied to verified agent identity |
| 10.2.1.2 Actions by privileged accounts logged | AU-01, GV-02 | Partial — dispatch scope | SDOS logs dispatch and risk tier; post-execution actions outside the dispatch boundary are not captured by SDOS |
| 10.3.2 Audit logs protected from modification | AU-02, EN-04 | Strong | Append-only log integrity + tamper-evident audit directly satisfy this requirement |
| 10.3.3 Audit logs promptly backed up | AU-03 | Partial — structural only | Dual audit trail provides structural redundancy; backup schedule is a deployment configuration obligation |
| 10.4 Audit logs reviewed for anomalies | AU-01, AU-02 | Weak — Substrate Only | SDOS generates and protects logs; anomaly review requires external SIEM or analyst workflow |
| 11.5.2 Change-detection mechanism alerts on unauthorized modification | IN-01, IN-02, IN-03 | Partial — Governance Configuration Scope | Governance baseline integrity (IN-01), drift detection with halt (IN-02), and module manifest integrity (IN-03) implement a change-detection mechanism that alerts on unauthorized modification of SDOS governance configuration and module manifests. Full 11.5.2 compliance also requires file-integrity monitoring across the broader CDE — outside SDOS scope. |
| 6.4.3 Detection of unauthorized changes to payment-page scripts | IN-01, IN-03 | Weak — Substrate Only | The integrity-verification model SDOS applies to governance configuration and module manifests is structurally analogous to 6.4.3's script-change-detection requirement; SDOS does not itself monitor payment-page scripts in a CDE web layer. |
| 12.3 Targeted risk analyses performed | RM-01, RM-02 | Partial — Risk Input Only | SDOS dispatch-time classification provides automated risk input at point of execution. PCI TRA is a formal documented process with specific required elements — scoping, methodology, documentation, and risk owner sign-off. SDOS provides input to a PCI TRA but does not constitute the formal documented analysis required by 12.3. |
| 12.3.4 Technologies reviewed periodically | IN-01, IN-02 | Partial — runtime only | Baseline integrity verification covers governance drift; organizational policy required for periodic review cycles |
Mapping by SDOS Domain¶
Governance (GV)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-GV-01 — Configuration-Governed Module Activation | Req 7.2: access defined by policy; Req 10.2: audit infrastructure |
| SDOS-GV-02 — Governance-Tiered Model Selection | Req 7.2.2: function-based access tiering |
| SDOS-GV-03 — Default-Deny Pre-Admission Policy | Req 7: need-to-know enforcement; Req 8: access restriction |
| SDOS-GV-04 — Cross-Module Governance Continuity | Req 8.6: system account continuity across module boundaries |
| SDOS-GV-05 — Model-Alignment-Independent Policy Enforcement | Req 7.3: enforcement independent of underlying system behavior |
Risk Management (RM)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-RM-01 — Dispatch-Time Risk Classification | Req 12.3: targeted risk analysis at point of execution |
| SDOS-RM-02 — Complexity-Tiered Resource Allocation | Req 12.3: risk-proportionate resource allocation |
| SDOS-RM-03 — Risk-Floor Model Binding | Req 7.2.2: minimum capability floor for elevated-risk operations |
Enforcement (EN)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-EN-01 — Pre-Egress Policy Enforcement | Req 7.3: access enforcement at the execution boundary |
| SDOS-EN-02 — Subordinate-Side Enforcement Gate | Req 7.3: secondary enforcement at module boundary |
| SDOS-EN-03 — Fail-Closed Degradation | Req 12: operational resilience posture |
| SDOS-EN-04 — Governed Egress with Tamper-Evident Audit | Req 10.3.2: tamper-evident output records |
Identity and Attestation (IA)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-IA-01 — Attested Agent Identity | Req 8.2.1: unique identification; Req 10.2.1.1: identity in audit records |
| SDOS-IA-02 — Attested Module Identity | Req 8.2.1: unique module identification before activation |
Audit (AU)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-AU-01 — Per-Invocation Audit Record | Req 10.2: audit log generation for every CDE access event |
| SDOS-AU-02 — Append-Only Audit Log Integrity | Req 10.3.2: protection from unauthorized modification |
| SDOS-AU-03 — Dual Audit Trail | Req 10.3.3: audit log backup and redundancy |
Integrity (IN)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-IN-01 — Governance Baseline Integrity Verification | Req 11.5.2: change-detection mechanism for governance configuration |
| SDOS-IN-02 — Baseline Drift Detection and System Halt | Req 11.5.2: automated detection of unauthorized change with halt response |
| SDOS-IN-03 — Module Manifest Integrity | Req 11.5.2: module manifest integrity covers the governance configuration component of change detection |
Admission (AD)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-AD-01 — Default-Deny Agent Pre-Admission | Req 7: default-deny as the access control foundation |
Risk Scoring (RS)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-RS-01 — Quantified Risk Scoring and ROSI Evaluation | Req 12.3: dispatch-time risk quantification provides automated risk measurement input to Targeted Risk Analysis documentation. SDOS provides the runtime risk-measurement signal; the formal documented TRA process remains an organizational obligation. |
Detection (DE)¶
| Control | PCI-DSS Relevance |
|---|---|
| SDOS-DE — Detection Domain Controls | No direct PCI-DSS requirement maps primarily to the SDOS detection domain. AU-domain controls (AU-01, AU-02) serve as the substrate for detection workflows addressed by Req 10.4 (anomaly review), rated Weak — Substrate Only in the full mapping table. |
Relationship to Other Frameworks¶
SDOS is also mapped to NIST AI RMF 1.0, EU AI Act, DORA, and HIPAA. 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 PCI-DSS requirements: [email protected]
SDOS Runtime Governance Framework — PCI-DSS v4.0 Alignment. Version 1.3. Published 2026-05-03.