{ "dataset": { "meta": { "domain": "compliance", "domain_slug": "compliance", "domain_number": 4, "title": "Apeiris Compliance Control Matrix", "description": "Apeiris Compliance Control Matrix: 48 machine-readable controls across 6 layers.", "version": "1.1.0", "published": "2026-07-02", "layers": 6, "controls_count": 48, "baseline_controls": [ "CA-01", "CA-08", "OB-01", "OB-08", "RF-01", "RF-08", "CI-01", "CI-08", "AU-01" ], "canonical_prefix": "apeiris://compliance/controls/", "attestation_artifact": "ComplianceAttestation", "attestation_control": "AU-08", "alias_domain": "complianceverifier.ai", "frameworks": [ "anthropic_rsp", "aws_artifact", "cobit_2019", "coso_erm", "csa_ai_caiq", "dora", "eu_ai_act", "fedramp_20x", "gdpr", "google_compliance", "iso_27001", "iso_37301", "iso_42001", "microsoft_compliance", "nis2", "nist_800_53", "nist_csf", "okta_governance", "openai_policies", "soc2" ], "lenses": [ "legal_counsel", "grc_auditor", "it_operations", "compliance_officer", "executive" ], "license": "CC BY 4.0", "source": "https://apeiris.ai/domains/compliance/", "integration_endpoint": "https://apeiris.ai/integration/domains/compliance-controls-full.json", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "baseline_control_count": 9, "generated_at": "2026-07-02T00:00:00.000Z", "subtitle": "apeiris.ai/domains/compliance \u2014 Apeiris Compliance", "site": "https://apeiris.ai/domains/compliance", "corpus_url": "https://apeiris.ai/integration/domains/compliance-controls-full.json", "schema_version": "1.1.0", "schema_extended_on": "2026-06-29", "extended_schema_fields": [ "validation_objective", "evidence_required", "machine_tests", "human_review", "blocking_effect", "normative_status", "anti_patterns", "update_status" ] }, "controls": [ { "id": "CA-01", "layer": "CA", "plane": "control", "name": "Regulatory Scope Determination", "plain": "Every AI system deployment must undergo a systematic regulatory scope determination that identifies all applicable regulations, standards, and supervisory obligations before the system enters production, producing a documented scope record that is version-controlled and reviewed whenever deployment context changes.", "threat": { "tags": [ "regulatory-gap", "scope-misclassification", "compliance-blindspot", "over-scoping" ], "desc": "AI systems deployed without systematic regulatory scope analysis may fail to identify applicable obligations, creating undetected compliance gaps that surface only during regulatory examination. Scope misclassification\u2014treating a high-risk system as out-of-scope for the EU AI Act\u2014creates material legal exposure that cannot be remediated post-deployment. Conversely, over-scoping wastes compliance resources and generates audit noise that obscures genuine obligations, reducing the organization's ability to prioritize material risks." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system requirements" }, { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "gdpr", "section": "Art. 35", "title": "Data protection impact assessment" }, { "id": "cobit_2019", "section": "BAI02.01", "title": "Define and maintain business functional requirements" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "iso_42001_2023", "title": "ISO/IEC 42001:2023 \u2014 Artificial Intelligence Management System", "authority": "International Organization for Standardization / International Electrotechnical Commission", "source_type": "standard", "normative_force": "certification-standard", "version": "2023", "published_on": "2023-12-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/81230.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_42001", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 42001:2023 \u2014 Artificial Intelligence Management System requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" }, { "id": "csa_ai_caiq_v1", "title": "CSA AI Controls Matrix (AICM) and AI Consensus Assessments Initiative Questionnaire (AI CAIQ)", "authority": "Cloud Security Alliance", "source_type": "framework", "normative_force": "best-practice", "version": "1.1.0", "published_on": "2025-07-10", "retrieved_on": "2026-06-29", "canonical_url": "https://cloudsecurityalliance.org/artifacts/ai-controls-matrix-v1-1", "license": "open-access", "status": "current", "flagship": false, "source_id": "csa_ai_caiq_v1", "relationship": "informative_reference", "rationale": "Establishes CSA AI Controls Matrix (AICM) and AI Consensus Assessments Initiative Questionnaire (AI CAIQ) requirements informing the apeiris://compliance/controls/CA-01 Regulatory Scope Determination control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured intake questionnaire combined with automated classification logic covering jurisdiction, sector, data types processed, and AI system capability level. Output is a versioned scope record enumerating each applicable regulatory regime with the triggering classification criterion.", "steps": [ "Deploy a regulatory scope questionnaire covering deployment jurisdiction, sector classification, data categories, AI system capability tier, and intended use cases.", "Map questionnaire responses to a regulatory trigger matrix that identifies which regulations, directives, and standards are activated by each attribute combination.", "Produce a versioned scope record for each AI system, store it in the compliance registry, and gate deployment pipeline advancement on scope record approval.", "Re-run scope determination whenever deployment context changes: new jurisdiction, capability expansion, data category addition, or material change in intended use." ], "compliance_officer": { "summary": "Scope determination is the foundation of the entire compliance architecture. Every subsequent control depends on the accuracy of this scope record.", "actions": [ "Own the regulatory trigger matrix and update it within 30 days of any regulatory publication that affects AI systems.", "Review and approve scope records for all high-risk or eu-high-risk-ai tier systems before deployment gate clearance.", "Establish escalation path for ambiguous classifications to legal counsel within a defined SLA." ], "metrics": [ "Percentage of active AI systems with approved scope records: target 100%.", "Mean time from deployment request to approved scope record: target 5 business days.", "Scope record staleness rate (records not reviewed within 12 months): target 0%." ], "failure_signals": [ "Systems in production without an approved scope record.", "Scope records not reviewed following a known regulatory change.", "Classification disputes unresolved beyond the defined SLA." ] }, "legal_counsel": { "summary": "Legal counsel must validate the regulatory trigger matrix and adjudicate ambiguous classifications, particularly for novel AI capabilities with unsettled regulatory status.", "actions": [ "Review and sign off on the regulatory trigger matrix at least annually and following any material regulatory change.", "Adjudicate classification disputes escalated by the compliance officer within the defined SLA.", "Document legal rationale for all out-of-scope determinations for novel or borderline AI system types." ], "failure_signals": [ "Regulatory trigger matrix not reviewed following EU AI Act stagger implementation updates.", "Out-of-scope determinations lacking documented legal rationale.", "Classification disputes pending beyond the defined SLA." ] }, "grc_auditor": { "summary": "Scope records are primary audit artifacts. Auditors verify that the trigger matrix is current, scope records are approved, and that no systems bypassed the scope determination gate.", "actions": [ "Sample scope records for 20% of active AI systems each audit cycle and verify completeness and approval chain.", "Cross-reference the compliance registry against the asset inventory to identify AI systems lacking scope records.", "Verify that the regulatory trigger matrix was updated following each published regulatory change within the review period." ], "metrics": [ "Scope record coverage rate: target 100% of inventoried AI systems.", "Trigger matrix review recency: all updates within 30 days of regulatory publication." ], "failure_signals": [ "AI systems in the asset inventory not present in the compliance registry.", "Scope records approved without legal counsel review for high-risk or eu-high-risk-ai tier systems.", "Trigger matrix version predates the most recent relevant regulatory publication." ] }, "it_operations": { "summary": "IT Operations enforces the deployment gate that blocks systems lacking an approved scope record from advancing in the deployment pipeline.", "actions": [ "Integrate the compliance registry scope record approval status into the CI/CD deployment gate.", "Ensure the deployment gate blocks production promotion for any AI system without an approved scope record.", "Alert the compliance team when a deployed system's scope record reaches its review expiry date." ], "failure_signals": [ "Deployment pipeline advanced without scope record gate check.", "No automated alert triggered when scope records approach review expiry.", "Registry API unavailability causing deployment gate bypass." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises perform ad hoc regulatory scoping driven by legal events rather than systematic pre-deployment analysis. Formalizing a trigger matrix and compliance registry gate moves the organization to a defined, repeatable state." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "multi-tenant" ], "implementers": [ "Compliance Team", "Legal Counsel", "Product Management", "Risk Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "Article 9 of the EU AI Act mandates a risk management system for high-risk AI systems that must identify and analyze known and foreseeable risks, which presupposes that the system has been correctly classified as high-risk through a regulatory scope determination. Without a systematic scope determination, providers cannot know whether Article 9 obligations are triggered. The CA-01 control directly operationalizes this prerequisite determination step.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 requires the organization to identify the compliance obligations that apply to its activities, to have access to them, and to understand their implications. Regulatory scope determination is the primary mechanism for fulfilling this requirement in the context of AI system deployments. The versioned scope record produced by CA-01 serves as the documented output of the \u00a74.5 obligation identification process.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 35", "fit": "direct", "rationale": "GDPR Article 35 requires a Data Protection Impact Assessment before processing that is likely to result in high risk to individuals. For AI systems processing personal data, the scope determination must identify whether GDPR Article 35 obligations are triggered, making CA-01 a prerequisite to DPIA initiation. The regulatory scope record produced by CA-01 documents the GDPR applicability determination that precedes any DPIA.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "BAI02.01", "fit": "partial", "rationale": "COBIT 2019 BAI02.01 addresses defining and maintaining business functional and compliance requirements, which encompasses identifying applicable regulatory requirements as part of solution design. CA-01's scope determination process feeds directly into the requirements baseline that BAI02.01 mandates organizations maintain. The fit is partial because BAI02.01 addresses requirements management broadly, while CA-01 focuses specifically on regulatory scope for AI systems.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 2: Objective Setting", "fit": "adjacent", "rationale": "The COSO ERM Framework's objective-setting component requires organizations to understand the external environment in which they operate, including legal and regulatory constraints, as a foundation for risk identification. Regulatory scope determination operationalizes this external environment analysis for AI systems specifically. The fit is adjacent because COSO ERM addresses enterprise objectives broadly rather than AI system compliance specifically.", "normative_force": "best-practice", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager provides pre-built assessment templates for GDPR, EU AI Act, ISO 27001, and SOC 2 that systematically enumerate the regulatory requirements applicable to an organization's workloads. Regulatory Scope Determination (CA-01) requires producing a versioned scope record identifying all applicable regulatory regimes; Compliance Manager assessment templates serve as a structured starting point for that enumeration, surfacing which framework obligations are activated by a given system's attributes. The fit is partial because Compliance Manager addresses Microsoft-cloud workloads and does not fully substitute for the jurisdiction and sector-specific trigger matrix CA-01 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. CA-01's scope determination should nonetheless record provider safety frameworks like the RSP in the scope record for systems consuming Anthropic models, since the provider's Capability Threshold determinations shape which model versions and safeguards are available to the deployment.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Usage Policies", "fit": "partial", "rationale": "OpenAI's Usage Policies define the permitted and prohibited uses of OpenAI services, constituting a contractual and policy compliance scope for any AI system consuming OpenAI APIs. Regulatory Scope Determination (CA-01) must capture these provider policy obligations in the scope record alongside regulatory obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "AWS security posture documentation", "fit": "adjacent", "rationale": "For AI systems deployed on AWS infrastructure, AWS Artifact's security posture documentation defines the shared responsibility boundary that determines which regulatory obligations AWS covers on behalf of the organization versus those the organization must address independently. Regulatory Scope Determination (CA-01) must account for this boundary when scoping the organization's applicable obligations; without understanding AWS's compliance coverage, the scope record may either duplicate AWS-covered requirements or miss obligations that remain with the organization. The fit is adjacent because AWS Artifact informs the scoping boundary rather than directly specifying which regulations apply.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "adjacent", "rationale": "Google Cloud's shared responsibility matrix explicitly delineates which compliance obligations Google fulfills for GCP-hosted workloads versus those that remain with the customer organization. Regulatory Scope Determination (CA-01) for AI systems on GCP must incorporate this matrix to correctly bound the organization's own compliance scope; obligations already satisfied by Google's certifications reduce the organization's residual scope, while obligations outside Google's coverage must be fully scoped in the CA-01 scope record. The fit is adjacent because the shared responsibility matrix informs scope boundaries rather than triggering or specifying regulatory obligations directly.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_42001", "requirement_id": "\u00a74.1 (Understanding context)", "fit": "direct", "rationale": "ISO/IEC 42001:2023 \u00a74.1 requires organisations to determine external and internal factors affecting AI management; CA-01 regulatory scope determination is the AI-specific implementation of this clause.", "normative_force": "certification-standard", "source_version": "2023", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "csa_ai_caiq", "requirement_id": "GRC-07 (Information System Regulatory Mapping)", "fit": "direct", "rationale": "CSA AI Controls Matrix GRC-07 (Information System Regulatory Mapping) requires organizations to identify and document all relevant standards, regulations, and legal/contractual requirements applicable to the AI service. CA-01's regulatory scope determination directly produces this mapping, and the versioned scope record is the documented artifact GRC-07 expects.", "normative_force": "best-practice", "source_version": "1.1.0", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" } ], "canonical_id": "apeiris://compliance/controls/CA-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI system in the compliance registry must have an approved, version-controlled scope record that correctly identifies all applicable regulatory regimes based on its deployment jurisdiction, sector, data categories, and capability tier, and that was reviewed following the most recent material change to deployment context or applicable regulatory publication. Deployment pipeline advancement must be blocked for any system without an approved scope record.", "evidence_required": [ "compliance_registry_scope_record containing system_id, applicable_regimes[], triggering_criteria[], approved_by, approved_at, and version_id demonstrating a complete and current classification", "regulatory_trigger_matrix with version_date and last_reviewed_on within 30 days of the most recent applicable regulatory publication affecting AI systems in the organization's jurisdictions", "deployment_gate_log entry for the AI system showing scope_record_approval_status was checked before production promotion with artifact scope_record_id referenced", "escalation_record for any ambiguous classification decisions showing legal_counsel_sign_off, resolution_rationale, and resolution_date within the defined SLA" ], "machine_tests": [ "Query compliance registry for AI system by system_id \u2192 assert scope_record.status='approved' and scope_record.reviewed_at is within 12 months of current_date", "Attempt deployment pipeline promotion for system with scope_record.status='pending' \u2192 assert gate blocks promotion with error_code=missing_scope_record and deployment_blocked=true", "Retrieve regulatory_trigger_matrix.version_date \u2192 assert it is within 30 days of the most recent applicable regulatory publication date recorded in the watch list" ], "human_review": [ "Review scope record completeness for a 20% sample of active AI systems by cross-referencing the record's applicable_regimes[] against the system's actual deployment jurisdiction, sector, data categories, and capability tier", "Assess regulatory trigger matrix currency relative to recent publications affecting AI systems and verify out-of-scope determinations for borderline AI system types have documented legal rationale", "Verify that the compliance team's escalation SLA for classification disputes is defined, documented, and that no unresolved disputes remain open beyond that SLA" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Performing regulatory scope determination ad hoc only when a regulatory examination or audit is imminent rather than as a mandatory pre-deployment gate for every AI system", "Using a single shared scope record for all AI systems in a product family without system-specific classification based on each system's capability tier, data categories, and deployment jurisdiction", "Treating scope records as one-time artifacts without versioning or review triggers linked to capability expansions, new jurisdictions, or regulatory publications", "Delegating scope classification approval for high-risk or eu-high-risk-ai tier systems to system owners without required legal counsel review and sign-off", "Conflating scope determination with the DPIA process, producing a single combined document that satisfies neither the CA-01 scope record nor Article 35 DPIA requirements" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-02", "layer": "CA", "plane": "control", "name": "Compliance Framework Selection and Mapping", "plain": "For each AI system, the applicable compliance frameworks must be selected from the organizational catalog and their requirements systematically mapped to organizational controls, producing a harmonized obligation map that eliminates redundant evidence collection and identifies where a single control satisfies multiple framework requirements.", "threat": { "tags": [ "framework-overlap", "redundant-controls", "unmapped-obligation", "audit-fatigue" ], "desc": "Organizations managing multiple compliance frameworks independently generate duplicative evidence collection efforts and miss cross-framework harmonization opportunities. Without a unified obligation map, the same organizational control may be tested separately for SOC 2, ISO 27001, and EU AI Act, wasting resources and creating inconsistent findings. Unmapped obligations\u2014requirements that exist in adopted frameworks but have no corresponding organizational control\u2014constitute hidden compliance gaps that auditors and regulators will eventually surface." }, "standard": [ { "id": "iso_37301", "section": "\u00a76.2", "title": "Compliance objectives and planning to achieve them" }, { "id": "cobit_2019", "section": "MEA03.01", "title": "Identify external compliance requirements" }, { "id": "nist_csf", "section": "GV.PO-01", "title": "Organizational cybersecurity policy established" }, { "id": "soc2", "section": "CC1.1", "title": "COSO Principle 1: Commitment to integrity and ethical values" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-02 Compliance Framework Selection and Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-02 Compliance Framework Selection and Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-02 Compliance Framework Selection and Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-02 Compliance Framework Selection and Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-02 Compliance Framework Selection and Mapping control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a framework catalog that maps each framework's control requirements to a canonical obligation taxonomy. For each AI system, select the applicable frameworks from CA-01 scope records and generate a harmonized obligation map using the catalog. Flag control gaps and redundancies for remediation.", "steps": [ "Build and maintain a framework catalog containing all adopted frameworks, their current versions, and a normalized list of their control requirements mapped to a canonical obligation taxonomy.", "For each AI system, use the CA-01 scope record to select applicable frameworks and generate a harmonized obligation map that cross-references requirements across frameworks.", "Identify harmonization opportunities where a single organizational control satisfies requirements from multiple frameworks and document the cross-framework mappings.", "Flag unmapped obligations\u2014framework requirements without a corresponding organizational control\u2014and route them to CA-06 for gap analysis." ], "compliance_officer": { "summary": "The framework catalog and harmonized obligation map are the operational backbone of the compliance architecture. Maintaining them in current state is the compliance officer's primary ongoing responsibility.", "actions": [ "Maintain the framework catalog and update it within 60 days of any framework version publication.", "Review harmonized obligation maps for all new AI system deployments before production approval.", "Coordinate with legal counsel to validate framework applicability determinations in the obligation map." ], "metrics": [ "Framework catalog coverage: all adopted frameworks present at current version.", "Obligation mapping completion rate: target 100% of applicable requirements mapped.", "Cross-framework harmonization rate: percentage of obligations satisfied by shared controls." ], "failure_signals": [ "Framework catalog version lags published framework updates by more than 60 days.", "Obligation maps with unmapped requirements not routed to CA-06 within defined SLA.", "AI systems in production without an approved harmonized obligation map." ] }, "legal_counsel": { "summary": "Legal counsel validates the applicability determination for each framework in the catalog and advises on how regulatory requirements translate to enforceable organizational obligations.", "actions": [ "Review framework catalog entries for binding-law frameworks and validate requirement interpretations at each major framework version update.", "Advise compliance officer on ambiguous framework applicability determinations where regulatory text is subject to interpretive variance.", "Document legal rationale for framework non-applicability determinations to support audit and regulatory inquiry responses." ], "failure_signals": [ "Binding-law framework requirements interpreted without legal counsel review.", "Framework non-applicability determinations lacking documented legal rationale.", "Obligation maps not updated following legal counsel advisories on regulatory interpretation changes." ] }, "grc_auditor": { "summary": "The harmonized obligation map is the primary artifact for audit scoping. Auditors use it to identify which controls to test and which framework requirements each control is expected to satisfy.", "actions": [ "Use harmonized obligation maps as the primary scoping document for internal audit cycles, testing the controls mapped to each framework's requirements.", "Verify cross-framework harmonization mappings by independently mapping a sample of requirements to organizational controls.", "Report unmapped obligations identified during audit as CA-06 inputs requiring remediation." ], "metrics": [ "Harmonized obligation map completeness: all applicable framework requirements present and mapped.", "Cross-framework mapping accuracy: spot-check of 15% of harmonized mappings confirmed correct." ], "failure_signals": [ "Audit findings identifying framework requirements not present in the obligation map.", "Cross-framework mappings that do not accurately reflect the organizational control's actual scope.", "Framework catalog version used for obligation mapping predates current framework publication." ] }, "executive": { "summary": "Framework harmonization directly reduces compliance operating costs and enables the organization to demonstrate comprehensive assurance posture to regulators and customers without duplicative effort.", "actions": [ "Approve the organizational framework catalog and review framework adoption decisions annually with the compliance officer.", "Review compliance efficiency metrics\u2014harmonization rate and obligation coverage\u2014as part of quarterly GRC reporting." ], "failure_signals": [ "Compliance operating costs not declining as harmonization rate increases.", "Regulatory examination findings identifying framework requirements the organization did not know applied." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations manage framework compliance in silos, with separate teams handling SOC 2, ISO 27001, and EU AI Act independently. A harmonized obligation map is a significant maturity advance that requires centralized ownership and tooling." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "GRC Platform Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a76.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a76.2 requires organizations to establish compliance objectives consistent with identified obligations and plan how to achieve them, which in practice requires mapping those obligations to the organizational controls designed to satisfy them. The harmonized obligation map produced by CA-02 is the direct artifact of this planning requirement. Maintaining it at framework version currency ensures the objectives remain aligned with current regulatory expectations.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.01", "fit": "direct", "rationale": "COBIT 2019 MEA03.01 explicitly requires identifying and keeping up to date with external compliance requirements, including determining how they translate into internal policies and controls. CA-02's framework catalog and obligation mapping process operationalizes this requirement by maintaining a structured, version-controlled mapping from external requirements to organizational controls. The systematic nature of CA-02 satisfies MEA03.01's emphasis on a repeatable, documented identification process.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "GV.PO-01", "fit": "partial", "rationale": "NIST CSF 2.0 GV.PO-01 requires organizational cybersecurity policy to be established, communicated, and enforced, which includes identifying applicable legal and regulatory requirements. CA-02's framework selection and mapping process ensures that the regulatory dimension of organizational policy is grounded in a systematic framework catalog. The fit is partial because GV.PO-01 addresses policy governance broadly while CA-02 focuses specifically on compliance framework mapping for AI systems.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC1.1", "fit": "partial", "rationale": "SOC 2 Trust Services Criteria CC1.1 addresses the COSO Principle of demonstrating commitment to integrity and ethical values, which includes establishing and communicating compliance expectations across the organization. A structured framework catalog and obligation map demonstrates that the organization has systematically identified its compliance obligations rather than relying on ad hoc knowledge. The fit is partial because CC1.1 addresses organizational culture and commitment broadly rather than technical framework mapping specifically.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "adjacent", "rationale": "EU AI Act Article 9(2) requires high-risk AI system providers to establish a risk management system that considers applicable harmonized standards and common specifications, which requires knowing which standards apply and how their requirements map to the provider's risk controls. CA-02's framework mapping process ensures that applicable harmonized standards are identified and their requirements tracked. The fit is adjacent because Article 9 addresses risk management rather than compliance framework administration directly.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Control mapping", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's core function is compliance framework selection and control mapping: it provides a catalog of assessment templates for regulatory frameworks (GDPR, EU AI Act, ISO 27001, SOC 2), maps framework requirements to organizational controls and improvement actions, and tracks harmonized coverage across frameworks. Compliance Framework Selection and Mapping (CA-02) requires exactly these capabilities \u2014 maintaining a framework catalog, generating a harmonized obligation map, and identifying cross-framework redundancy. Organizations using Compliance Manager can treat its assessment library as the implementation vehicle for the CA-02 framework catalog and its control mappings as the harmonized obligation map.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact third-party audit reports (SOC 1/2/3, ISO 27001, FedRAMP) document which regulatory framework requirements AWS already satisfies for shared-responsibility workloads. Compliance Framework Selection and Mapping (CA-02) requires identifying the obligations satisfied by each selected framework and harmonizing them across the organization's control landscape; understanding which requirements AWS's own certifications cover prevents the organization from mapping unnecessary controls for AWS-managed components. The fit is partial because AWS Artifact informs the obligation map for AWS-hosted systems only and does not replace the organization's own framework selection and mapping work.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Regulatory guidance", "fit": "partial", "rationale": "Google Cloud's compliance resource center provides regulatory guidance that specifies which GCP certifications satisfy requirements under frameworks such as ISO 27001, SOC 2, and PCI DSS, and which obligations remain with the customer. Compliance Framework Selection and Mapping (CA-02) must account for GCP's regulatory coverage when generating the harmonized obligation map for GCP-hosted AI systems, so that the map correctly identifies which requirements are addressed by Google's certifications versus those requiring independent organizational controls. The fit is partial because Google's guidance narrows the obligation map scope for GCP environments but does not encompass the full framework selection and mapping work CA-02 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. When CA-02's framework catalog is assembled for AI systems using Anthropic models, the RSP belongs in the catalog as a provider self-governance framework whose Required Safeguards describe the vendor-side control environment, alongside the Usage Policy and commercial terms that carry the customer-facing obligations.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Trust Portal", "fit": "adjacent", "rationale": "OpenAI's Trust Portal publishes the vendor's compliance documentation \u2014 SOC 2 reports, security and privacy documentation \u2014 that enterprises fold into their framework catalog when mapping vendor-side coverage. CA-02's framework selection and mapping should reference this vendor compliance documentation when OpenAI services are in scope.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI system must have a current harmonized obligation map derived from the organizational framework catalog, with all applicable frameworks present at their current published versions and every framework requirement either mapped to an organizational control or explicitly flagged as a gap routed to the CA-06 backlog with a gap_id. No requirement may exist in the obligation map in an unmapped and unrouted state.", "evidence_required": [ "framework_catalog showing each adopted framework with current_version, last_reviewed_on (within 60 days of current framework publication), and requirement_count", "harmonized_obligation_map for the AI system listing each requirement by framework_id and requirement_id, the mapped organizational control_id or gap_id, and a harmonization_group_id where multiple frameworks share one control", "cross_framework_harmonization_report documenting the count of requirements satisfied by shared controls and estimated evidence collection reduction as a percentage", "gap_routing_records for each unmapped requirement showing obligation_id, gap_id, routed_at timestamp, and assigned CA-06 backlog entry confirmation" ], "machine_tests": [ "Load harmonized_obligation_map for each deployed AI system \u2192 assert every requirement row has either control_id is not null or gap_id is not null (no row may have both null)", "Compare framework_catalog.current_version entries against authoritative framework publication databases \u2192 assert all entries have version_date within 60 days of the most recent published version", "Enumerate CA-06 gap_backlog entries originating from this system's obligation map \u2192 assert each has assigned_owner and target_closure_date not null" ], "human_review": [ "Verify cross-framework harmonization accuracy by independently mapping a 15% sample of harmonized requirements to their organizational controls and confirming the control actually satisfies all mapped framework requirements", "Assess whether the framework catalog includes all frameworks identified as applicable in CA-01 scope records for active AI systems and that no adopted framework is absent from the catalog", "Verify that legal counsel has reviewed binding-law framework requirement interpretations for any framework updated or newly adopted in the past 12 months" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Managing each compliance framework in a separate team silo with no cross-framework harmonization, generating redundant evidence collection for the same organizational control across SOC 2, ISO 27001, and EU AI Act", "Maintaining an obligation map as a point-in-time spreadsheet without version control or a defined process to update it when framework versions change", "Marking requirements as satisfied in the obligation map without a corresponding organizational control entry or evidence artifact, creating paper compliance without substantive coverage", "Using a single generic obligation map for all AI systems rather than generating system-specific maps from CA-01 scope records, causing over-scoped or under-scoped obligation coverage", "Allowing the framework catalog to lag published framework versions by more than 60 days without documented review and impact assessment" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-03", "layer": "CA", "plane": "both", "name": "Cross-Domain Evidence Routing", "plain": "Compliance obligations requiring evidence must be systematically mapped to the Apeiris domain that produces the authoritative attestation for that obligation, and evidence routing rules must ensure that attestations from Security, Model, Identity, and other domains are automatically associated with the compliance obligations they satisfy.", "threat": { "tags": [ "evidence-orphan", "cross-domain-gap", "unmapped-attestation", "compliance-dead-zone" ], "desc": "Without explicit evidence routing rules, compliance obligations accumulate without corresponding attestations, and attestations from other Apeiris domains are produced without being associated with the compliance obligations they satisfy. This creates evidence orphans\u2014attestations that exist but are not linked to any compliance requirement\u2014and compliance dead zones where obligations appear unmet despite evidence existing in another domain. During regulatory examination, the inability to route evidence to specific article-level obligations is a material deficiency." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 9(2)", "title": "Risk management system \u2014 continuous iterative process" }, { "id": "iso_37301", "section": "\u00a78.1", "title": "Operational planning and control" }, { "id": "cobit_2019", "section": "MEA03.04", "title": "Obtain assurance of external compliance" }, { "id": "soc2", "section": "CC4.1", "title": "COSO Principle 16 \u2014 Ongoing and separate evaluations of internal control" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-03 Cross-Domain Evidence Routing control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CA-03 Cross-Domain Evidence Routing control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-03 Cross-Domain Evidence Routing control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a cross-domain evidence routing table that maps each compliance obligation (identified by framework, article, and requirement identifier) to the Apeiris domain attestation type that satisfies it. At runtime, evidence packages for each obligation are assembled by querying the appropriate domain's attestation registry using the routing table.", "steps": [ "Build and maintain a cross-domain evidence routing table with rows keyed by compliance obligation identifier and columns specifying the producing Apeiris domain, attestation type, control prefix, and evidence field mappings.", "For each EU AI Act article, GDPR provision, and adopted standard requirement, document which Apeiris domain attestation (SecurityPostureAttestation, ModelAssuranceAttestation, IdentityAttestation, etc.) provides the primary evidence.", "Implement automated evidence assembly that queries each domain's attestation registry using routing table entries and compiles cross-domain evidence packages for each compliance obligation.", "Validate routing table completeness against the CA-02 obligation map, flagging obligations with no routing entry as inputs to CA-06 gap analysis." ], "compliance_officer": { "summary": "The cross-domain routing table translates abstract compliance obligations into concrete Apeiris attestation queries. It is the operational mechanism for demonstrating compliance using federated evidence.", "actions": [ "Own and maintain the cross-domain evidence routing table, updating it within 30 days of any change to the CA-02 obligation map.", "Review routing table completeness quarterly and escalate gaps to CA-06 for remediation.", "Coordinate with domain teams to ensure attestation types cover all compliance-relevant evidence fields required by the routing table." ], "metrics": [ "Routing table coverage: percentage of compliance obligations with at least one routing entry, target 100%.", "Evidence assembly success rate: percentage of obligations for which automated assembly produces a valid evidence package.", "Mean time from obligation identification to routing table entry creation: target 10 business days." ], "failure_signals": [ "Compliance obligations in the obligation map without a routing table entry.", "Automated evidence assembly failures indicating missing or stale domain attestations.", "Routing table not updated following changes to the CA-02 obligation map." ] }, "grc_auditor": { "summary": "The routing table and assembled evidence packages are the primary artifacts for demonstrating compliance during audit. Auditors verify that routing entries are accurate and that assembled evidence is valid and current.", "actions": [ "Use the routing table as the audit trail from each compliance obligation to its supporting evidence.", "Verify a sample of routing entries by querying the referenced domain attestation registry directly and confirming the evidence is valid and within its validity window.", "Flag routing entries pointing to expired or stale attestations as material findings." ], "metrics": [ "Routing entry accuracy: spot-check of 20% of entries confirms correct domain and attestation type mapping.", "Evidence freshness rate: percentage of assembled evidence packages with all attestations within valid_until window." ], "failure_signals": [ "Routing entries pointing to non-existent or superseded attestation types.", "Assembled evidence packages containing attestations outside their validity window.", "Compliance obligations with routing entries that produce no evidence on assembly." ] }, "it_operations": { "summary": "IT Operations maintains the automated evidence assembly infrastructure that queries domain attestation registries using the routing table and produces compliance evidence packages.", "actions": [ "Deploy and maintain the evidence assembly service that executes routing table queries against domain attestation registries.", "Implement alerting for assembly failures, stale attestations, and routing table query errors.", "Ensure domain attestation registry APIs meet the availability and latency SLAs required for timely evidence assembly." ], "failure_signals": [ "Evidence assembly service downtime causing compliance evidence packages to be unavailable for audit.", "Domain attestation registry APIs returning errors or timeouts during assembly queries.", "No alerting configured for assembly failures or stale attestation detection." ] }, "executive": { "summary": "Cross-domain evidence routing is the mechanism that makes the Apeiris federated proof model operational for regulatory compliance. Its effectiveness directly determines whether the organization can demonstrate compliance using machine-readable evidence during examination.", "actions": [ "Receive quarterly briefing on routing table coverage and evidence assembly success rates.", "Approve investment in domain attestation capabilities identified as missing through routing gap analysis." ], "failure_signals": [ "Routing table coverage materially below 100% without an approved remediation plan.", "Regulatory examination requiring manual evidence collection because automated assembly failed." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Cross-domain evidence routing requires both a federated attestation infrastructure and a structured mapping methodology. Most organizations lack both. Initial state is manual evidence mapping; defined state is a maintained routing table with automated assembly." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "federated-enterprise", "high-risk-sector" ], "implementers": [ "Compliance Team", "Platform Engineering", "GRC Platform Team" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Article 9(2) requires the risk management system to run as a continuous, iterative process throughout the AI system lifecycle, with regular systematic review and updating of the risks identified and the measures adopted. Demonstrating that this documented process operates requires linking evidence of risk controls to the specific requirements they address. CA-03's routing table provides the explicit mapping from EU AI Act requirements to the Apeiris domain attestations that demonstrate those measures were implemented, creating the traceable evidence linkage the risk management system presupposes.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a78.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a78.1 requires organizations to plan, implement, control, and maintain processes to meet compliance obligations, including determining evidence criteria. The cross-domain routing table operationalizes the evidence criteria determination by specifying which attestation type satisfies each obligation. Automated evidence assembly implements the maintenance process that \u00a78.1 requires to keep compliance documentation current.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.04", "fit": "direct", "rationale": "COBIT 2019 MEA03.04 (Obtain assurance of external compliance) requires obtaining assurance \u2014 including maintained evidence \u2014 that external compliance requirements are met. CA-03's automated evidence assembly implements this by systematically collecting and associating evidence with compliance obligations via the routing table, providing the obligation-to-attestation traceability that assurance reporting requires.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "SOC 2 CC4.1 (COSO Principle 16) requires the entity to select, develop, and perform ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning. CA-03's routing table ensures those evaluations receive domain-specific attestations as structured evidence inputs. The fit is partial because CC4.1 addresses evaluation of internal control broadly rather than regulatory compliance evidence routing specifically.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "partial", "rationale": "GDPR Article 5(2) establishes the accountability principle, requiring controllers to demonstrate compliance with data processing principles. For AI systems processing personal data, CA-03's evidence routing ensures that attestations from the Privacy and Data domains are associated with the GDPR obligations they satisfy, creating the traceable demonstration that Article 5(2) demands. The fit is partial because CA-03 addresses evidence routing generally while Article 5(2) focuses specifically on personal data processing accountability.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager generates improvement actions tied to specific framework requirements and tracks their completion status, producing structured evidence artifacts that map organizational control outputs to compliance obligation identifiers. Cross-Domain Evidence Routing (CA-03) requires a routing table that maps compliance obligations to evidence-producing controls and enables automated evidence assembly; Compliance Manager improvement action records can serve as evidence artifacts that must be incorporated into the routing table for Microsoft-cloud AI systems. The fit is partial because Compliance Manager's evidence routing is scoped to its own assessment framework and does not integrate directly with Apeiris domain attestation types, requiring a translation layer at the routing table boundary.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance's audit reporting produces structured records of identity decisions, access certification outcomes, and policy enforcement actions that constitute evidence relevant to identity-related compliance obligations such as GDPR Art. 32 access controls and ISO 27001 A.9 access management. Cross-Domain Evidence Routing (CA-03) must include routing entries that map these identity compliance obligations to their evidence sources; for AI systems using Okta for identity governance, Okta audit reports are a primary evidence artifact that the routing table must reference. The fit is partial because Okta's audit reports cover identity-specific obligations only and represent one node in the broader cross-domain evidence routing architecture.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. Anthropic's published capability assessments and reports are vendor-layer evidence artifacts; CA-03's routing table should reference them as the evidence source for obligations that depend on the model provider's safety posture.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every compliance obligation in the CA-02 harmonized obligation map must have at least one entry in the cross-domain evidence routing table specifying the producing Apeiris domain, attestation type, and evidence field mappings, and automated evidence assembly must successfully produce a valid evidence package with all referenced attestations within their valid_until window when queried on demand.", "evidence_required": [ "cross_domain_routing_table entries keyed by compliance_obligation_id, each containing producing_domain (Apeiris domain slug), attestation_type, control_prefix, evidence_field_mappings[], and last_validated_on timestamp", "automated_evidence_assembly_log showing successful assembly for a representative 20% sample of obligations, with package_id, assembled_at, and valid_until for each attestation included in the package", "routing_coverage_report comparing routing table obligation_id count against CA-02 obligation map requirement count, with gap_percentage metric and CA-06 routing for any gaps", "domain_attestation_registry_query_logs confirming routing table entries resolve to attestations with status='valid' and valid_until > current_date for each sampled obligation" ], "machine_tests": [ "For each obligation_id in the CA-02 obligation map, query routing table \u2192 assert routing_entry.producing_domain is a recognized Apeiris domain slug and routing_entry.attestation_type exists in that domain's attestation registry", "Trigger automated evidence assembly for a random sample of 10 obligations \u2192 assert each assembled_package contains no attestations where valid_until < current_date and integrity.hash validates for each included attestation", "Submit an obligation_id with no routing table entry to the evidence assembly service \u2192 assert response contains error_code=routing_gap and the obligation_id appears in the CA-06 gap backlog within 24 hours" ], "human_review": [ "Verify routing table completeness by cross-referencing all obligation identifiers in the CA-02 obligation map against routing table entries, identifying obligations with no entry or entries pointing to deprecated attestation types", "Review a 20% sample of routing entries to confirm the specified domain attestation type actually contains the evidence fields required to satisfy the compliance obligation, not merely a tangentially related attestation", "Assess whether the attestation validity windows referenced in routing entries are appropriate for each compliance obligation's evidence freshness requirements under the applicable regulatory framework" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Manually collecting evidence ad hoc for each audit cycle without a persistent routing table, repeating the same obligation-to-evidence mapping work every time an audit occurs", "Routing all compliance obligations to a single broad-scope attestation type regardless of whether that attestation actually contains evidence for the specific obligation", "Creating routing entries that reference attestation types the domain team no longer produces, resulting in assembly failures discovered only during regulatory examination", "Failing to update the routing table when the CA-02 obligation map is updated following regulatory changes, leaving newly added obligations with no routing entry", "Treating the routing table as a one-time configuration artifact rather than an operational process requiring updates synchronized with every CA-02 obligation map change" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-04", "layer": "CA", "plane": "lifecycle", "name": "Design-Time Compliance Classification", "plain": "Before any AI system enters production, a ComplianceClassificationEvidence artifact must be produced that records the system's classification under each applicable regulatory regime\u2014including EU AI Act risk category, GDPR processing basis, and sector-specific classification\u2014with the classification signed off by both compliance and legal roles and stored in the compliance registry.", "threat": { "tags": [ "pre-deployment-gap", "classification-drift", "unclassified-system", "compliance-debt" ], "desc": "AI systems deployed without a formal compliance classification create compliance debt that is expensive to remediate post-deployment, as architectural decisions may have been made without awareness of applicable obligations. Classification drift occurs when a system's actual capabilities or use expand beyond its initial classification without triggering reclassification, creating a gap between the system's compliance posture and its operational reality. For EU AI Act purposes, deploying a high-risk system without the required conformity assessment is a direct legal violation that cannot be corrected retroactively." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 6", "title": "Classification rules for high-risk AI systems" }, { "id": "gdpr", "section": "Art. 25", "title": "Data protection by design and by default" }, { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "cobit_2019", "section": "BAI03.02", "title": "Design detailed solution components" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-04 Design-Time Compliance Classification control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-04 Design-Time Compliance Classification control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-04 Design-Time Compliance Classification control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-04 Design-Time Compliance Classification control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-04 Design-Time Compliance Classification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Design-time classification is triggered as a mandatory deployment gate. The system's capability manifest, data processing description, sector context, and CA-01 scope record are inputs to a structured classification workflow that produces a signed ComplianceClassificationEvidence artifact stored in the compliance registry and referenced by all downstream compliance controls.", "steps": [ "Implement a design-time classification workflow triggered at the architecture review stage, before any compliance-relevant design decisions are finalized.", "Use the CA-01 scope record and the system's capability manifest as inputs to produce a classification determination for each applicable regime, including EU AI Act risk tier, GDPR lawful basis, and sector-specific categories.", "Produce a ComplianceClassificationEvidence artifact containing the classification outputs, the rationale for each determination, the reviewer identities, and validity bounds.", "Gate production deployment on the existence of a valid, signed ComplianceClassificationEvidence artifact in the compliance registry, and trigger reclassification whenever the capability manifest or deployment context changes materially." ], "compliance_officer": { "summary": "Design-time classification is the compliance architecture's primary mechanism for preventing compliance debt. Every classification determination shapes which downstream controls apply, making accuracy and completeness critical.", "actions": [ "Review and co-sign ComplianceClassificationEvidence artifacts for all systems classified as high-risk or above.", "Maintain the classification workflow and ensure it is triggered at the architecture review stage for all AI system initiatives.", "Establish a classification review trigger process that detects capability expansions and prompts reclassification." ], "metrics": [ "Design-time classification coverage: percentage of production AI systems with a valid ComplianceClassificationEvidence artifact, target 100%.", "Classification recency: percentage of artifacts reviewed within 12 months or following a material capability change.", "Mean time from architecture review trigger to signed artifact: target 10 business days." ], "failure_signals": [ "AI systems in production without a valid ComplianceClassificationEvidence artifact.", "Classification artifacts not updated following documented capability expansions.", "High-risk classifications not co-signed by both compliance and legal roles." ] }, "legal_counsel": { "summary": "Legal counsel must co-sign classifications under binding-law regimes, particularly EU AI Act high-risk and prohibited use determinations, as these carry direct legal liability.", "actions": [ "Co-sign ComplianceClassificationEvidence artifacts for all EU AI Act high-risk and prohibited use determinations.", "Advise on GDPR lawful basis determinations and document legal rationale in the classification artifact.", "Review classification artifacts within the defined SLA to avoid blocking deployment timelines unnecessarily." ], "failure_signals": [ "EU AI Act high-risk classifications signed without legal counsel review.", "GDPR lawful basis determinations not documented in the classification artifact.", "Classification review SLA breached, causing deployment delays attributed to the legal review stage." ] }, "grc_auditor": { "summary": "ComplianceClassificationEvidence artifacts are primary audit artifacts. Auditors verify coverage, accuracy, and that classifications are current relative to the system's actual capabilities.", "actions": [ "Sample ComplianceClassificationEvidence artifacts for 25% of active AI systems each audit cycle and verify classification accuracy against capability manifests.", "Cross-reference classifications against the CA-01 scope registry to confirm consistency.", "Identify systems where capability expansions were not followed by classification review and report as findings." ], "metrics": [ "Classification coverage rate: 100% of production systems with valid artifacts.", "Classification accuracy rate: sampled artifacts correctly classify the system under all applicable regimes." ], "failure_signals": [ "Systems with capability expansions lacking updated classification artifacts.", "Classifications inconsistent with CA-01 scope records.", "Artifacts lacking required co-signatures for high-risk determinations." ] }, "it_operations": { "summary": "IT Operations enforces the deployment gate that requires a valid ComplianceClassificationEvidence artifact and monitors for capability changes that should trigger reclassification.", "actions": [ "Integrate the ComplianceClassificationEvidence validity check into the CI/CD deployment gate.", "Implement monitoring that detects changes to AI system capability manifests and triggers a reclassification workflow notification.", "Maintain audit logs of all deployment gate checks and classification artifact versions associated with each deployment." ], "failure_signals": [ "Deployment gate bypassed without a valid classification artifact.", "No automated detection of capability manifest changes that should trigger reclassification.", "Deployment logs lacking references to classification artifact identifiers." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Pre-deployment compliance classification is rare in practice. Most organizations classify systems reactively when a regulatory examination or audit demands it. The EU AI Act's entry into application is the primary forcing function for organizations to formalize design-time classification." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "Product Management", "Platform Engineering" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 6", "fit": "direct", "rationale": "EU AI Act Article 6 establishes the classification rules for high-risk AI systems, which providers must apply before placing a system on the market or putting it into service. CA-04's design-time classification workflow operationalizes the Article 6 classification determination and produces a documented artifact demonstrating that the classification was performed and is defensible. Failure to perform this classification before deployment is a direct non-compliance with the Act's conformity assessment requirements.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 25", "fit": "direct", "rationale": "GDPR Article 25 requires data protection by design and by default, which includes making design-time determinations about processing activities, applicable lawful bases, and data minimization measures before systems process personal data. CA-04's classification workflow incorporates GDPR processing basis determination as a required classification output, ensuring that these design-time obligations are addressed before deployment rather than retrospectively.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "partial", "rationale": "ISO 37301:2021 \u00a79.1 requires the organization to monitor, measure, analyse and evaluate its compliance performance, which presupposes that the obligations against which performance will be evaluated have been identified and classified. CA-04's design-time classification establishes the classification baseline that makes subsequent performance evaluation meaningful. The fit is partial because \u00a79.1 addresses performance evaluation while CA-04 addresses the prerequisite classification step that enables meaningful monitoring.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "BAI03.02", "fit": "partial", "rationale": "COBIT 2019 BAI03.02 (Design detailed solution components) requires designing solution components in detail against defined requirements, including compliance requirements identified during planning. CA-04 integrates compliance classification into the design process, ensuring that compliance requirements identified through CA-01 and CA-02 are reflected in the design-time artifact. The fit is partial because BAI03.02 addresses solution design broadly while CA-04 focuses specifically on compliance classification documentation.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "adjacent", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk, within the Performance component) requires organizations to identify risks that could prevent achievement of objectives, including compliance obligations. CA-04's design-time classification is a risk identification activity that determines which regulatory regimes impose obligations before the system is deployed, enabling risk-informed design decisions. The fit is adjacent because COSO ERM addresses risk identification broadly while CA-04 addresses compliance classification specifically.", "normative_force": "best-practice", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's pre-built assessment templates for EU AI Act, GDPR, and ISO 27001 operationalize design-time compliance classification by providing structured questionnaires that determine which regulatory obligations apply to a system based on its data processing characteristics, deployment context, and capability tier. Design-Time Compliance Classification (CA-04) requires a workflow that produces a classification determination for each applicable regime before production deployment; Compliance Manager assessment templates provide an implementation vehicle for this workflow, enabling the ComplianceClassificationEvidence artifact to reference structured classification outputs from a recognized GRC platform. Compliance Manager's control mapping outputs can directly populate the classification rationale fields required in the CA-04 artifact.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "direct", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's Capability Threshold construct \u2014 classification of models against thresholds that trigger stronger safeguards \u2014 is a working design pattern for CA-04's design-time compliance classification, and the provider's current ASL determination is an input the ComplianceClassificationEvidence artifact should record for Anthropic-based systems.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Usage Policies", "fit": "partial", "rationale": "OpenAI's Usage Policies defines constraints on permitted and prohibited AI system use cases that must be evaluated at design time to classify the system's compliance posture relative to OpenAI's terms. Design-Time Compliance Classification (CA-04) requires classifying the system under each applicable compliance regime before production deployment; for systems using OpenAI APIs, Usage Policies classification must be included in the ComplianceClassificationEvidence artifact to document that the intended use case was reviewed against OpenAI's use restrictions. The fit is partial because Usage Policies classification is a vendor policy determination rather than a regulatory risk classification, and it supplements the statutory classifications CA-04 primarily addresses.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "AWS security posture documentation", "fit": "partial", "rationale": "For AI systems deployed on AWS, AWS Artifact's security posture documentation establishes which compliance obligations AWS satisfies under the shared responsibility model, directly informing the Design-Time Compliance Classification (CA-04) by defining the classification boundary between AWS-covered and organization-covered obligations. The ComplianceClassificationEvidence artifact produced by CA-04 for AWS-hosted AI systems must reflect this boundary so that the classification accurately represents the organization's residual compliance obligations rather than obligations AWS already satisfies. The fit is partial because AWS security posture documentation is an input to classification rather than a classification criterion in itself.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "partial", "rationale": "Google Cloud's shared responsibility matrix defines which compliance obligations Google fulfills for GCP-hosted workloads and which remain with the customer, directly shaping the Design-Time Compliance Classification (CA-04) for GCP-hosted AI systems by establishing which regulatory regime requirements fall within the organization's residual scope. The ComplianceClassificationEvidence artifact for GCP-hosted AI systems should reference Google's shared responsibility position to justify which obligations the organization has classified as in-scope versus covered by the cloud provider. The fit is partial because the shared responsibility matrix sets classification boundaries rather than performing the classification workflow that CA-04 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Before any AI system enters production, a signed ComplianceClassificationEvidence artifact must exist in the compliance registry containing the system's classification under each applicable regulatory regime identified in the CA-01 scope record, with legal counsel co-signature required for high-risk and eu-high-risk-ai tier determinations, and the artifact must be current with respect to the system's current capability manifest version.", "evidence_required": [ "ComplianceClassificationEvidence artifact containing system_id, capability_manifest_version, classification_outputs[] (each with regime, classification_tier, determination_rationale), compliance_officer_signature, legal_counsel_signature (for high-risk tiers), valid_from, and valid_until", "deployment_gate_log entry showing ComplianceClassificationEvidence.status='valid' was verified before production promotion, with the artifact_id referenced in the gate check record", "capability_manifest document versioned at the time of classification, with the manifest version matching the ComplianceClassificationEvidence.capability_manifest_version field", "reclassification_trigger_log showing that all capability manifest changes since initial classification were evaluated for reclassification need with evaluation_outcome and reviewer_identity recorded" ], "machine_tests": [ "Query compliance registry for AI system by system_id \u2192 assert ComplianceClassificationEvidence.status='valid' and valid_until > current_date", "Attempt deployment pipeline promotion for a system with no valid ComplianceClassificationEvidence in the registry \u2192 assert gate blocks with error_code=missing_classification_artifact and deployment_blocked=true", "For systems with eu_ai_act classification_tier='high_risk', retrieve classification artifact \u2192 assert legal_counsel_signature is present and signed_at timestamp predates the deployment_gate_passed_at timestamp" ], "human_review": [ "Review classification accuracy for a 25% sample of active AI systems by cross-referencing the classification artifact against the current capability manifest and CA-01 scope record to verify the classification tier is correct and the rationale is defensible", "Verify that reclassification workflows were triggered and completed for all systems with documented capability expansions since their most recent classification artifact was signed", "Assess whether GDPR lawful basis determinations in the classification artifact are supported by documented legal rationale covering the specific processing activities the AI system performs" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Performing compliance classification only when a regulatory examination demands it rather than enforcing it as a mandatory pre-deployment gate integrated into the CI/CD pipeline", "Using a single shared ComplianceClassificationEvidence artifact for all AI systems in a product family without per-system classification of each deployed instance's actual capability tier", "Approving EU AI Act high-risk classification determinations at the compliance officer level without required legal counsel co-signature, leaving the determination legally undefended", "Allowing ComplianceClassificationEvidence artifacts to persist without review following capability expansions that may change the applicable regulatory tier, creating classification drift", "Treating GDPR lawful basis determination as a separate DPIA activity rather than as a required classification output field in every CA-04 artifact for systems processing personal data" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-05", "layer": "CA", "plane": "lifecycle", "name": "Regulatory Change Management", "plain": "The organization must maintain a regulatory monitoring capability that tracks changes to applicable regulations and standards, assesses the impact on existing AI system compliance scope and classifications, and updates the compliance architecture within defined timelines to reflect new or amended obligations before their regulatory effective dates.", "threat": { "tags": [ "regulatory-drift", "stale-obligation", "amendment-blindspot", "version-lag" ], "desc": "Regulatory environments governing AI systems are changing rapidly, with the EU AI Act's staggered application dates, ongoing guidance publications, and sector-specific amendments creating a continuously evolving obligation landscape. Organizations that do not monitor regulatory changes systematically will operate with stale compliance architectures, missing new obligations and relying on superseded interpretations. Version lag\u2014where compliance controls are designed against an earlier version of a regulation\u2014is a material risk when regulators enforce against current requirements." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "cobit_2019", "section": "MEA03.02", "title": "Optimize the compliance response" }, { "id": "eu_ai_act", "section": "Art. 43", "title": "Conformity assessment procedures" }, { "id": "nist_csf", "section": "GV.OC-01", "title": "Organizational context is determined" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-05 Regulatory Change Management control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-05 Regulatory Change Management control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-05 Regulatory Change Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-05 Regulatory Change Management control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-05 Regulatory Change Management control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a regulatory watch list covering all jurisdictions and domains in which the organization operates AI systems. Subscribe to authoritative regulatory update sources and implement a structured impact assessment process that evaluates each change against the CA-01 scope registry and CA-02 obligation map. Prioritize changes by impact severity and required response timeline.", "steps": [ "Build and maintain a regulatory watch list keyed by jurisdiction, sector, and regulatory body, with subscription to authoritative sources including the Official Journal of the EU, national competent authority publications, and standards body revision notifications.", "Implement a structured change assessment workflow triggered by each regulatory publication, producing an impact assessment that identifies affected AI systems, impacted obligations, and required updates to scope records, obligation maps, and classifications.", "Assign response timelines to each assessed change based on severity and the regulation's effective date, and track remediation through to completion in the compliance registry.", "Conduct a quarterly regulatory horizon scan to identify anticipated changes before they are published, enabling proactive rather than reactive compliance architecture updates." ], "compliance_officer": { "summary": "Regulatory change management is a continuous operational responsibility. The compliance officer must ensure the watch list is comprehensive, impact assessments are timely, and remediations are completed before regulatory effective dates.", "actions": [ "Own the regulatory watch list and review its coverage quarterly.", "Triage all regulatory publications within 5 business days of receipt and initiate impact assessments for those affecting AI system compliance.", "Report open remediations past their target completion date to executive leadership as at-risk items." ], "metrics": [ "Regulatory watch list coverage: all applicable jurisdictions and regulatory bodies monitored.", "Mean time from regulatory publication to impact assessment completion: target 10 business days.", "Open remediations past target completion date: target 0 at any regulatory effective date." ], "failure_signals": [ "Regulatory publications not triaged within 5 business days.", "Impact assessments not completed before regulatory effective dates.", "Remediations still open at the time a regulatory change becomes enforceable." ] }, "legal_counsel": { "summary": "Legal counsel interprets new regulatory publications and advises on the effective date and enforcement implications of each change, particularly for binding-law regimes where interpretation is contested.", "actions": [ "Review and interpret all regulatory publications from binding-law sources within the defined SLA.", "Advise compliance officer on effective dates, transitional provisions, and enforcement risk for each assessed change.", "Monitor litigation and regulatory enforcement decisions that affect interpretation of applicable regulations and issue updated guidance accordingly." ], "failure_signals": [ "Legal interpretation of regulatory changes not provided within SLA, delaying impact assessment completion.", "Compliance architecture updated based on incorrect effective date interpretation.", "Enforcement decisions affecting regulatory interpretation not communicated to the compliance team." ] }, "grc_auditor": { "summary": "Auditors assess whether the regulatory change management process is operating effectively and whether remediations are completed on time.", "actions": [ "Review the regulatory change log and verify that all publications from watch list sources were triaged within the defined SLA.", "Test a sample of completed impact assessments for accuracy by independently assessing the regulatory change against the CA-01 scope registry.", "Verify that remediations were completed before regulatory effective dates for all changes assessed as requiring architecture updates." ], "metrics": [ "Triage timeliness rate: percentage of publications triaged within 5 business days.", "Remediation on-time rate: percentage of remediations completed before regulatory effective dates." ], "failure_signals": [ "Regulatory change log gaps indicating publications were not received or triaged.", "Remediations completed after regulatory effective dates without documented risk acceptance.", "Impact assessments not cross-referenced against CA-01 scope registry." ] }, "executive": { "summary": "Executive leadership must be informed of regulatory changes that materially affect the organization's compliance posture or create significant remediation effort, enabling resource allocation and risk acceptance decisions.", "actions": [ "Receive quarterly regulatory horizon reports identifying material upcoming changes and estimated remediation effort.", "Approve risk acceptance decisions for remediations that cannot be completed before regulatory effective dates.", "Ensure regulatory change management is resourced adequately given the current AI regulatory environment." ], "failure_signals": [ "Regulatory effective dates passed without executive awareness of material compliance gaps.", "Remediation resource requests denied without documented risk acceptance.", "No quarterly regulatory horizon reporting to executive leadership." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "AI regulatory change management is a new discipline for most enterprises. The EU AI Act's staggered application dates mean organizations must build this capability urgently. Initial state is reactive; managed state features a monitored watch list with tracked remediations and regular horizon scanning." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "Risk Management" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate their compliance management system, including tracking changes in the compliance obligations landscape. CA-05's regulatory change management process directly implements the monitoring requirement by maintaining a watch list and structured change assessment workflow. The impact assessment outputs update the compliance architecture in response to observed changes, satisfying the evaluate-and-respond aspect of \u00a79.1.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.02", "fit": "direct", "rationale": "COBIT 2019 MEA03.02 requires optimizing the compliance response, including tracking changes in regulatory requirements and adjusting policies and controls accordingly. CA-05's structured change assessment and remediation tracking process operationalizes MEA03.02 by ensuring that regulatory changes trigger systematic updates to the compliance architecture rather than ad hoc responses. The watch list and impact assessment workflow provide the structured, repeatable process MEA03.02 requires.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 43", "fit": "partial", "rationale": "EU AI Act Article 43 addresses conformity assessment procedures, which providers must repeat or update when making substantial modifications to high-risk AI systems or when the regulatory framework materially changes. CA-05's regulatory change management process identifies when regulatory changes require conformity assessment updates, triggering the Article 43 procedure. The fit is partial because Article 43 addresses conformity assessment procedures while CA-05 addresses the monitoring process that detects when those procedures must be re-executed.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_csf", "requirement_id": "GV.OC-01", "fit": "partial", "rationale": "NIST CSF 2.0 GV.OC-01 requires organizations to determine their organizational context, including the legal and regulatory requirements that apply to them. CA-05 maintains this organizational context as a living document by tracking regulatory changes and updating the compliance architecture accordingly. The fit is partial because GV.OC-01 addresses establishing organizational context while CA-05 addresses the dynamic process of keeping that context current as regulations evolve.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "adjacent", "rationale": "GDPR Article 5(2) establishes the accountability principle, which includes demonstrating ongoing compliance with GDPR's data processing principles. For AI systems processing personal data, CA-05 ensures that GDPR guidance updates from supervisory authorities and enforcement decisions are tracked and incorporated into the compliance architecture. The fit is adjacent because Article 5(2) addresses accountability broadly while CA-05 addresses the regulatory monitoring process specifically.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager automatically updates its assessment templates and control mappings when the underlying regulatory frameworks change \u2014 for example, when the EU AI Act issues new guidance or GDPR supervisory authorities publish updated enforcement positions \u2014 surfacing these changes as updated improvement actions and revised compliance scores. Regulatory Change Management (CA-05) requires a structured process for detecting regulatory changes and assessing their impact on the compliance architecture; Compliance Manager serves as an automated regulatory watch component for Microsoft-cloud workloads, triggering impact assessments when assessment templates are updated. The direct fit arises because Compliance Manager's framework version tracking is a functional implementation of CA-05's requirement to detect regulatory publications and assess their impact on existing obligation maps and control configurations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy is a versioned policy document \u2014 the current version is RSP v3.3, published 2026-05-26 \u2014 and each new version may revise Capability Thresholds, Required Safeguards, or the ASL-3 Deployment and Security Standards in ways that change the vendor-side control environment for AI systems using Anthropic models. The RSP binds Anthropic rather than its customers, but Regulatory Change Management (CA-05) should include the RSP in its watch list and trigger impact assessments when a new version is published, since RSP changes can affect classification decisions, third-party obligation registers, and evidence routing established under prior versions. The fit is partial because the RSP is a vendor self-governance instrument rather than a statutory regulation, but its versioned update cycle makes it functionally analogous to a regulatory publication for change-management purposes.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI updates its Enterprise Data Processing Addendum and usage policies in response to regulatory changes, particularly GDPR enforcement guidance, EU AI Act implementing measures, and data residency requirements from national authorities. Regulatory Change Management (CA-05) must track updates to the OpenAI Enterprise DPA as a component of the third-party regulatory watch list, since DPA amendments may create new obligations or modify existing ones that affect the organization's compliance architecture for AI systems using OpenAI APIs. The fit is partial because the Enterprise DPA is a contractual instrument rather than a regulation, but DPA updates triggered by regulatory changes qualify as a regulatory change event that CA-05's impact assessment process must evaluate.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "adjacent", "rationale": "AWS publishes updated compliance reports in AWS Artifact when its certifications are renewed or when it achieves new regulatory attestations, which may reflect changes in the regulatory frameworks covering AWS-hosted workloads. Regulatory Change Management (CA-05) should monitor AWS Artifact report updates as part of the regulatory watch list for cloud infrastructure, since changes in AWS's compliance posture can shift the shared responsibility boundary and require updates to the organization's obligation map. The fit is adjacent because AWS Artifact report updates reflect changes in AWS's own compliance status rather than changes in applicable regulations, making them a secondary signal for regulatory change management.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Regulatory guidance", "fit": "adjacent", "rationale": "Google Cloud's compliance resource center publishes updated regulatory guidance and revised shared responsibility documentation when GCP certifications are renewed or when applicable regulations change, providing an additional signal for regulatory change management for GCP-hosted AI workloads. Regulatory Change Management (CA-05) should incorporate Google's compliance guidance updates into the regulatory watch list for cloud infrastructure, enabling the organization to detect when GCP-related compliance posture changes require updates to obligation maps or classifications. The fit is adjacent because Google's regulatory guidance reflects changes in GCP's compliance coverage rather than originating regulatory changes, making it a secondary data source for CA-05's watch list.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a current regulatory watch list covering all applicable jurisdictions and regulatory bodies identified in active CA-01 scope records, and every regulatory publication in the monitoring period must have a completed impact assessment with triage within 5 business days of publication, with all required architecture updates completed before the publication's regulatory effective date.", "evidence_required": [ "regulatory_watch_list document showing all monitored jurisdictions, regulatory_bodies[], authoritative_source_subscriptions[], and last_reviewed_on within the current quarter", "regulatory_change_log entries for each publication in the watch period, each containing publication_id, source, publication_date, triage_completed_at (within 5 business days), and impact_assessment_id or determination='no_impact'", "impact_assessment records for each assessed regulatory change containing affected_ai_systems[], affected_obligations[], required_architecture_updates[], assigned_owner, target_completion_date, and regulatory_effective_date", "remediation_completion_records for each required architecture update showing completed_at before target_completion_date and before regulatory_effective_date, with updated_artifact_ids referenced" ], "machine_tests": [ "Retrieve regulatory_change_log entries for the past 90 days \u2192 assert triage_completed_at - publication_date <= 5 business days for every entry", "For each impact_assessment with required_architecture_updates, query remediation_completion_records \u2192 assert all updates have completed_at that is before both target_completion_date and regulatory_effective_date", "Query regulatory_watch_list jurisdiction coverage against the union of jurisdictions in all active CA-01 scope records \u2192 assert all active jurisdictions are represented in the watch list" ], "human_review": [ "Review regulatory watch list coverage against the full set of jurisdictions and regulatory bodies applicable to the organization's AI portfolio, identifying regulatory bodies present in CA-01 scope records but absent from the watch list", "Assess whether impact assessments for a sample of regulatory changes accurately identified all affected AI systems by independently cross-referencing the change against the CA-01 scope registry", "Verify that quarterly regulatory horizon scans were documented and that anticipated changes triggered proactive assessment before formal publication" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Relying on ad hoc legal counsel notifications or news alerts rather than a systematic watch list with authoritative source subscriptions to Official Journal publications, standards body revision notices, and national competent authority guidance", "Completing impact assessments after regulatory effective dates, converting preventable compliance gaps into actual violations where the organization was aware of the change but did not remediate in time", "Scoping the regulatory watch list narrowly to primary statutes while missing supervisory authority guidance, enforcement decisions, and standard revisions that create material compliance obligations without formal legislative status", "Producing impact assessments that identify affected AI systems based on system type categories rather than by consulting the CA-01 scope registry, missing atypical systems that share a capability tier but differ in jurisdiction or sector", "Treating regulatory change management as a legal team-only responsibility rather than a cross-functional process requiring compliance, IT operations, and risk management participation for full impact assessment coverage" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-06", "layer": "CA", "plane": "control", "name": "Compliance Obligation Gap Analysis", "plain": "The organization must systematically identify compliance obligations for which no organizational control currently provides evidence, produce a prioritized remediation backlog, and track gap closure through to completion, ensuring that every obligation in the CA-02 obligation map has at least one corresponding control with evidence routing configured in CA-03.", "threat": { "tags": [ "control-gap", "unmet-obligation", "evidence-void", "audit-finding" ], "desc": "Compliance obligation gaps\u2014obligations in adopted frameworks for which no organizational control produces evidence\u2014are among the most serious findings in regulatory examinations and external audits. They indicate that the organization adopted a framework without implementing the controls it requires, which regulators interpret as evidence of a compliance management system deficiency rather than mere control weakness. Gaps discovered during examination cannot be closed retrospectively; they generate findings, financial penalties, and reputational harm that documented proactive gap management would have prevented." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.2", "title": "Internal audit" }, { "id": "cobit_2019", "section": "MEA03.03", "title": "Confirm external compliance" }, { "id": "soc2", "section": "CC4.2", "title": "COSO Principle 17 \u2014 Evaluates and communicates deficiencies" }, { "id": "coso_erm", "section": "Principle 10", "title": "Identifies Risk" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-06 Compliance Obligation Gap Analysis control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CA-06 Compliance Obligation Gap Analysis control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-06 Compliance Obligation Gap Analysis control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Gap analysis is performed by comparing the CA-02 obligation map against the CA-03 routing table. Obligations present in the map but absent from the routing table are gaps. Each gap is assessed for severity, applicable regulatory regime, and estimated remediation complexity, then entered into a prioritized remediation backlog with assigned ownership and target closure dates.", "steps": [ "Execute a gap analysis by programmatically comparing the CA-02 obligation map against the CA-03 routing table, identifying all obligations with no routing entry or routing entries pointing to non-existent attestations.", "For each identified gap, produce a gap record documenting the obligation identifier, applicable regulatory regime, gap severity based on normative force and enforcement risk, and whether the gap was previously known.", "Prioritize gaps by severity and route them to the appropriate domain team for remediation, establishing target closure dates based on regulatory effective dates and risk tolerance.", "Track gap closure progress in the compliance registry and report open gaps past their target closure dates to compliance leadership as at-risk items." ], "compliance_officer": { "summary": "Gap analysis is the compliance officer's mechanism for maintaining an accurate, current view of the organization's compliance coverage. It feeds both the remediation backlog and the executive risk posture report.", "actions": [ "Execute gap analysis quarterly and following any update to the CA-02 obligation map or CA-03 routing table.", "Review all new gap records within 5 business days of identification and assign ownership and target closure dates.", "Escalate high-severity gaps in binding-law regimes to legal counsel and executive leadership within the defined SLA." ], "metrics": [ "Open gap count by regime and severity: tracked quarterly with trend.", "Mean time from gap identification to remediation closure: defined by severity tier.", "Percentage of gaps closed before applicable regulatory effective dates: target 100% for binding-law obligations." ], "failure_signals": [ "Gap analysis not executed following updates to the obligation map or routing table.", "High-severity gaps not escalated to leadership within the defined SLA.", "Binding-law obligation gaps open at their regulatory effective date without documented risk acceptance." ] }, "legal_counsel": { "summary": "Legal counsel assesses the legal exposure created by identified gaps, particularly for binding-law obligations where gaps constitute potential violations, and advises on the risk acceptance process for gaps that cannot be closed before effective dates.", "actions": [ "Review high-severity gap records for binding-law regimes and advise on legal exposure and remediation prioritization.", "Draft risk acceptance documentation for gaps that cannot be closed before regulatory effective dates, including the legal basis for the risk acceptance decision.", "Monitor regulatory enforcement actions against organizations with similar gap profiles to calibrate the organization's remediation prioritization." ], "failure_signals": [ "High-severity binding-law gaps without legal counsel review.", "Risk acceptance documentation for open gaps lacking legal rationale.", "Gap remediation prioritization not informed by the current enforcement environment." ] }, "grc_auditor": { "summary": "Auditors use gap analysis outputs as a primary scoping tool and verify that gaps are accurately identified, appropriately prioritized, and closed within defined timelines.", "actions": [ "Review the gap analysis methodology and verify that the comparison between the obligation map and routing table is complete and accurate.", "Test a sample of closed gaps to verify that the remediation actually produced a routing table entry and valid attestation, not just a paper closure.", "Report gaps that were closed without evidence of a functioning routing entry as material findings requiring re-opening." ], "metrics": [ "Gap analysis completeness: all obligations in the CA-02 map present in the gap analysis.", "Closure validity rate: percentage of closed gaps confirmed to have functioning routing entries." ], "failure_signals": [ "Gap analysis methodology not comparing against the full CA-02 obligation map.", "Gaps closed without corresponding routing table entries and valid attestations.", "Open gap count increasing quarter-over-quarter without an approved remediation plan." ] }, "executive": { "summary": "The open gap register is the executive's primary view of compliance exposure. Material gaps in binding-law regimes require executive awareness and may require resource allocation decisions.", "actions": [ "Receive quarterly gap posture briefing showing open gap count, trend, and high-severity items by regime.", "Approve risk acceptance decisions for gaps that cannot be closed before regulatory effective dates.", "Ensure remediation resource allocation is commensurate with the gap severity profile." ], "failure_signals": [ "High-severity binding-law gaps not included in the executive briefing.", "Resource allocation decisions made without awareness of the gap severity profile.", "No formal risk acceptance process for gaps that cannot be closed before regulatory effective dates." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Systematic gap analysis against a structured obligation map is beyond most organizations' current compliance practice. Initial state is gap identification through audit findings; defined state features proactive, scheduled gap analysis with a managed remediation backlog." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "GRC Platform Team", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.2 requires organizations to conduct internal audits to assess whether the compliance management system conforms to the organization's own requirements for compliance and whether it is effectively implemented. Gap analysis is a core internal audit technique that ISO 37301 \u00a79.2 presupposes, as auditors must identify where controls do not satisfy obligations to assess whether the system is effective. CA-06's structured gap analysis operationalizes this requirement with a repeatable, documented methodology.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.03", "fit": "direct", "rationale": "COBIT 2019 MEA03.03 requires confirming external compliance by assessing whether the organization's controls satisfy external requirements and identifying deficiencies that need remediation. CA-06's gap analysis directly implements this requirement by systematically identifying where the control landscape does not cover adopted compliance obligations. The remediation backlog created by CA-06 provides the management mechanism that MEA03.03 requires for addressing identified deficiencies.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "partial", "rationale": "SOC 2 CC4.2 (COSO Principle 17) requires the entity to evaluate and communicate internal control deficiencies in a timely manner to parties responsible for taking corrective action. CA-06's gap analysis identifies compliance deficiencies \u2014 obligations without corresponding controls \u2014 and routes them to the appropriate stakeholders for remediation. The fit is partial because CC4.2 addresses internal control deficiencies broadly while CA-06 focuses on regulatory obligation coverage gaps.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "partial", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires organizations to systematically identify risks that could prevent achievement of objectives, including compliance obligations that are not currently met by organizational controls. CA-06's gap analysis operationalizes compliance risk identification by producing a structured inventory of unmet obligations, which feeds the organization's risk register. The fit is partial because COSO ERM addresses risk identification broadly while CA-06 focuses specifically on compliance control gaps.", "normative_force": "best-practice", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "adjacent", "rationale": "EU AI Act Article 9(2) requires the risk management system for high-risk AI systems to identify and analyze known and reasonably foreseeable risks. For compliance purposes, gaps in evidence coverage for Article 9 obligations represent known compliance risks that must be identified and addressed. CA-06's gap analysis ensures these compliance gaps are treated as risks requiring systematic remediation. The fit is adjacent because Article 9(2) addresses safety and rights risk identification while CA-06 addresses compliance control coverage gaps specifically.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_csf", "requirement_id": "ID.RA-01", "fit": "adjacent", "rationale": "NIST CSF 2.0 ID.RA-01 requires organizations to identify and document vulnerabilities in their assets, which in the compliance context includes vulnerabilities in the compliance control landscape\u2014obligations that lack corresponding controls. CA-06 treats compliance control gaps as a form of organizational vulnerability and applies a risk assessment and remediation process analogous to vulnerability management. The fit is adjacent because ID.RA-01 addresses cybersecurity vulnerability identification while CA-06 addresses compliance control coverage gaps.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's core function is compliance obligation gap analysis: it identifies improvement actions representing framework requirements not yet addressed by organizational controls, assigns them a score impact, and tracks them through to completion. Compliance Obligation Gap Analysis (CA-06) requires identifying obligations in the CA-02 obligation map that lack corresponding controls, producing a prioritized remediation backlog, and tracking gap closure; Compliance Manager implements this workflow for Microsoft-cloud workloads using its improvement action tracking and compliance score delta calculation. The direct fit arises because Compliance Manager's improvement action pipeline is a product-native implementation of CA-06's gap identification and remediation tracking logic, and its outputs can serve as the gap register that CA-06 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "partial", "rationale": "Okta Identity Governance's access certification campaigns systematically identify access control deficiencies \u2014 users with excessive privileges, stale entitlements, or uncertified access \u2014 that represent identity-related compliance obligation gaps under frameworks such as ISO 27001 A.9, SOC 2 CC6.1, and GDPR Art. 32. Compliance Obligation Gap Analysis (CA-06) must incorporate identity compliance gaps identified through Okta's access certification findings into the prioritized remediation backlog, ensuring that identity layer obligations without corresponding control coverage are tracked alongside gaps in other domains. The fit is partial because Okta access certification identifies identity-specific gaps rather than performing the comprehensive cross-domain obligation gap analysis CA-06 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For CA-06's gap analysis, the RSP's routine capability assessments define the vendor-side evidence stream; deployments that rely on Anthropic's safety posture without routing that evidence into their own control framework should surface as gaps in the remediation backlog.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Gap analysis must be executed at least quarterly and within 10 business days following every update to the CA-02 obligation map or CA-03 routing table, producing a complete gap register that identifies every obligation in the CA-02 map without a functioning routing table entry, with every gap assigned an owner, severity, and target closure date that precedes the obligation's regulatory effective date.", "evidence_required": [ "gap_analysis_run_record showing analysis_date, obligation_map_version, routing_table_version, total_obligations_analyzed, gaps_identified_count, analysis_trigger (scheduled or event-driven), and methodology_description", "gap_register entries for each open gap containing obligation_id, applicable_regime, normative_force, gap_severity, assigned_owner, target_closure_date, and escalation_status for high-severity binding-law items", "gap_closure_records showing each closed gap has a corresponding routing_table_entry_id and the entry resolves to a valid attestation confirmed post-closure, with validator_identity and confirmed_at timestamp", "binding_law_gap_escalation_records showing gaps with normative_force='binding-law' were escalated to legal_counsel and executive_leadership within the defined SLA after identification" ], "machine_tests": [ "Execute programmatic comparison of CA-02 obligation_map IDs against CA-03 routing_table obligation_id keys \u2192 assert every obligation_map entry absent from the routing table appears in the open gap_register", "For each gap_register entry with status='closed', query CA-03 routing table by obligation_id \u2192 assert routing entry exists, producing_domain is a valid Apeiris slug, and the referenced attestation has status='valid'", "Filter gap_register for normative_force='binding-law' and status='open' \u2192 assert each entry has an escalation_record with escalated_to containing 'legal_counsel' and escalated_at within the SLA days of gap_identified_at" ], "human_review": [ "Review gap analysis methodology to confirm the comparison covers the full CA-02 obligation map at the version current at analysis time, not a subset or a cached prior version", "Examine a 15% sample of closed gaps to verify each closure is substantive: the routing table entry exists, the referenced attestation is valid, and the evidence field content actually covers the obligation rather than being incidentally included", "Assess remediation backlog prioritization to verify binding-law gaps receive higher priority than voluntary-standard gaps and that all target closure dates precede the applicable regulatory effective dates" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Running gap analysis only before scheduled external audits rather than quarterly and after every CA-02 obligation map or CA-03 routing table update", "Closing gaps by adding a routing table entry pointing to an attestation that does not actually contain evidence for the obligation, producing a paper closure that fails during regulatory examination", "Treating gap analysis as a standalone periodic activity rather than integrating it as an automated trigger on every CA-02 obligation map and CA-03 routing table change", "Prioritizing gap closure by ease of remediation rather than by normative force and regulatory effective date, leaving high-severity binding-law gaps open while easy voluntary-standard gaps are resolved", "Recording gap severity based on the obligation's general importance without reference to its regulatory effective date, causing gaps to remain open past the date the obligation becomes enforceable" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-07", "layer": "CA", "plane": "control", "name": "Third-Party and Supply Chain Compliance Obligations", "plain": "Compliance obligations that flow to AI vendors, model providers, data processors, and other supply chain participants must be systematically identified, documented in binding contractual instruments, and monitored for ongoing compliance, with evidence of third-party compliance collected and incorporated into the organization's compliance evidence packages.", "threat": { "tags": [ "vendor-compliance-gap", "supply-chain-obligation", "third-party-risk", "cascade-liability" ], "desc": "AI system compliance obligations frequently cascade to third parties: GDPR Article 28 requires data processor agreements, EU AI Act Articles 23\u201326 impose obligations on importers, distributors, and deployers, and sector-specific regulations impose third-party due diligence requirements. Organizations that fail to identify and contractually impose these obligations on supply chain participants retain liability for their vendors' non-compliance. Vendor compliance evidence gaps create unsubstantiated claims in the organization's own compliance packages, which collapse under regulatory examination." }, "standard": [ { "id": "iso_37301", "section": "\u00a78.1", "title": "Operational planning and control" }, { "id": "eu_ai_act", "section": "Arts. 23\u201327", "title": "Obligations along the AI value chain (importers, distributors, deployers)" }, { "id": "gdpr", "section": "Art. 28", "title": "Processor contracts and sub-processor management" }, { "id": "cobit_2019", "section": "APO10.03", "title": "Manage vendor relationships and contracts" } ], "sources": [ { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-07 Third-Party and Supply Chain Compliance Obligations control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "For each AI system in scope, identify all third parties in the supply chain and determine which compliance obligations flow to each. Produce a third-party compliance obligation register keyed by vendor and requirement. Implement contractual imposition through DPA amendments, supplier agreements, and compliance schedules. Monitor third-party compliance through attestation collection and periodic review.", "steps": [ "Map the supply chain for each AI system, identifying all AI vendors, model providers, data processors, cloud infrastructure providers, and downstream deployers.", "Determine which compliance obligations flow to each supply chain participant based on their role, data access, and applicable regulatory frameworks, and document this in a third-party compliance obligation register.", "Ensure all identified obligations are reflected in binding contractual instruments: GDPR DPAs for data processors, EU AI Act compliance schedules for model providers and distributors, and sector-specific audit rights clauses for regulated activities.", "Collect compliance evidence from third parties on a schedule aligned with the organization's compliance evidence refresh cycle, and incorporate third-party attestations into the CA-03 routing table as required evidence inputs." ], "compliance_officer": { "summary": "Third-party compliance obligations are an extension of the organization's own compliance posture. The compliance officer must ensure that contractual coverage is complete and that third-party evidence is collected and validated.", "actions": [ "Maintain the third-party compliance obligation register and update it within 30 days of any supply chain change or regulatory update affecting third-party obligations.", "Review third-party compliance evidence on the schedule aligned with the evidence refresh cycle and flag deficiencies for remediation.", "Coordinate with legal counsel to ensure contractual instruments impose all identified obligations and include appropriate audit rights." ], "metrics": [ "Third-party obligation register coverage: all supply chain participants present with obligations documented.", "Contractual coverage rate: percentage of identified obligations reflected in binding contractual instruments, target 100%.", "Third-party evidence collection rate: percentage of required third-party attestations collected within the refresh cycle." ], "failure_signals": [ "Supply chain participants not present in the obligation register.", "Identified obligations not reflected in binding contractual instruments.", "Third-party compliance evidence not collected within the refresh cycle." ] }, "legal_counsel": { "summary": "Legal counsel drafts and reviews contractual instruments that impose compliance obligations on third parties, ensuring they are legally binding and include audit rights, breach notification requirements, and sub-processor management provisions.", "actions": [ "Review and approve all DPAs, AI Act compliance schedules, and supplier compliance agreements before execution.", "Advise on the applicable regulatory requirements that must be reflected in each contract type based on the vendor's role and data access.", "Maintain contract templates that are updated promptly following regulatory changes affecting third-party obligations." ], "failure_signals": [ "Contracts executed without legal counsel review for high-risk or eu-high-risk-ai tier AI system vendors.", "Contract templates not updated following regulatory changes affecting third-party obligations.", "GDPR DPAs lacking sub-processor management provisions required by Article 28(2)." ] }, "grc_auditor": { "summary": "Auditors verify that the third-party obligation register is complete, contractual coverage is binding, and third-party compliance evidence is valid and current.", "actions": [ "Cross-reference the supply chain map against the third-party obligation register to identify unregistered participants.", "Review a sample of third-party contracts to verify that identified obligations are reflected in binding terms.", "Validate third-party compliance attestations by checking their validity windows and the authority of the attesting entity." ], "metrics": [ "Supply chain coverage rate: percentage of supply chain participants with obligation register entries.", "Contractual coverage confirmation: sampled contracts confirm obligations are present in binding terms." ], "failure_signals": [ "Supply chain participants identified in the asset inventory not present in the obligation register.", "Contracts lacking audit rights provisions required for compliance evidence collection.", "Third-party attestations outside their validity window used in the organization's compliance evidence packages." ] }, "it_operations": { "summary": "IT Operations maintains the supply chain map by tracking which third-party services are integrated into each AI system, enabling the compliance team to keep the obligation register current as the supply chain evolves.", "actions": [ "Maintain a service dependency map for each AI system that identifies all integrated third-party APIs, model providers, and data services.", "Alert the compliance team within 5 business days of any new third-party integration or change in an existing integration that may affect compliance obligations.", "Provide technical artifacts including API access logs and data flow diagrams that support vendor attestation validation." ], "failure_signals": [ "New third-party integrations not reflected in the service dependency map within the defined SLA.", "Compliance team not alerted following material changes to third-party integrations.", "Technical artifacts needed for third-party attestation validation not available or current." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Third-party AI compliance obligations are a new legal domain driven by the EU AI Act and updated GDPR enforcement guidance. Most organizations have GDPR DPAs but lack EU AI Act compliance schedules for model providers and distributors. Defined state requires a complete obligation register and contractual coverage for all supply chain roles." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector", "multi-tenant" ], "implementers": [ "Compliance Team", "Legal Counsel", "Procurement", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a78.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a78.1 requires the organization to plan, implement and control the processes needed to meet its compliance obligations, including ensuring that outsourced processes are controlled. CA-07 implements this for AI supply chains by maintaining a third-party obligation register, requiring contractual imposition of compliance requirements on supply chain participants, and monitoring vendor compliance evidence.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Arts. 23\u201327", "fit": "direct", "rationale": "EU AI Act Articles 23, 24 and 26 establish obligations for importers, distributors and deployers of high-risk AI systems, including verification obligations that flow up the supply chain to providers, and Article 25 allocates responsibilities along the AI value chain \u2014 including written agreements with third-party suppliers of components integrated into high-risk AI systems. CA-07's third-party obligation register and contractual coverage mechanism ensures these value-chain obligations are identified and imposed on the appropriate supply chain participants. Failure to impose these obligations contractually leaves the organization as the residual obligor for non-compliance by downstream parties.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 28", "fit": "direct", "rationale": "GDPR Article 28 requires data controllers to use only processors providing sufficient guarantees about appropriate technical and organizational measures, and to implement the relationship through a contract imposing specific obligations on the processor. CA-07's contractual coverage requirement directly implements Article 28 for AI system data processors, ensuring DPAs are executed and include all required provisions including sub-processor management. The evidence collection component ensures ongoing verification of processor compliance.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "APO10.03", "fit": "direct", "rationale": "COBIT 2019 APO10.03 (Manage vendor relationships and contracts) requires formalizing and managing vendor relationships through contracts, including the compliance requirements imposed on suppliers, and monitoring adherence to contractual commitments. CA-07's obligation register, contractual coverage, and periodic attestation collection directly implement this practice for AI supply chain compliance.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC9.2", "fit": "partial", "rationale": "SOC 2 CC9.2 requires organizations to assess vendor and business partner risk by obtaining assurance that third parties manage their controls effectively and by monitoring compliance with service level agreements. CA-07's third-party attestation collection and periodic review implements the monitoring aspect of CC9.2 in the compliance context. The fit is partial because CC9.2 addresses vendor risk broadly in the context of the entity's own SOC 2 controls, while CA-07 addresses the compliance obligations that flow to vendors under applicable regulatory frameworks.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "direct", "rationale": "AWS Artifact provides on-demand access to AWS third-party audit reports (SOC 1 Type II, SOC 2 Type II, SOC 3, ISO 27001, FedRAMP, PCI DSS), which are the primary compliance attestations organizations must collect from AWS as a cloud infrastructure supply chain participant. Third-Party and Supply Chain Compliance Obligations (CA-07) requires systematically collecting compliance evidence from all supply chain participants and incorporating it into the organization's compliance evidence packages; AWS Artifact third-party audit reports are exactly the evidence artifacts CA-07's collection process must obtain for AWS-hosted AI systems. Failure to collect current AWS audit reports when AI systems run on AWS leaves a material gap in the CA-07 supply chain evidence that auditors and regulators will flag.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "direct", "rationale": "Google Cloud's compliance resource center provides certification documentation (ISO 27001, SOC 2, CSA STAR, PCI DSS, and others) that constitutes the third-party compliance attestations CA-07 requires organizations to collect from cloud infrastructure supply chain participants. Third-Party and Supply Chain Compliance Obligations (CA-07) mandates that compliance evidence from GCP \u2014 as a model hosting, data processing, or inference infrastructure provider \u2014 be collected on a defined schedule and incorporated into the compliance evidence packages produced by CA-08. Google's certification documentation provides the audit-verified evidence of GCP's compliance posture that satisfies this collection requirement.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Security Standard", "fit": "direct", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For CA-07, the RSP documents the security posture Anthropic applies to model weights under the ASL-3 Security Standard \u2014 vendor-side assurance that belongs in the third-party obligation register \u2014 while the customer-facing obligations to record contractually come from the Usage Policy and commercial terms.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "direct", "rationale": "OpenAI's Enterprise Data Processing Addendum is the binding contractual instrument governing data processing obligations for organizations using OpenAI APIs, constituting the primary GDPR-required processor agreement that CA-07 mandates be executed with AI model providers who process personal data. Third-Party and Supply Chain Compliance Obligations (CA-07) requires that all identified supply chain compliance obligations be reflected in binding contractual instruments; the OpenAI Enterprise DPA is this instrument for OpenAI as a data processor, and its current execution and content must be verified as part of CA-07's contractual coverage review. The zero data retention options, data residency commitments, and service terms within OpenAI's enterprise offerings must be incorporated into the third-party obligation register with their specific compliance terms documented.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Entitlement Management", "fit": "partial", "rationale": "Okta Identity Governance's Entitlement Management governs the entitlements granted to third-party and vendor accounts, supporting the access dimension of supply chain compliance. CA-07's third-party obligation register extends the same discipline to the full set of compliance obligations imposed on supply chain participants.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "adjacent", "rationale": "Microsoft Purview Compliance Manager assessment templates can be used to assess vendor compliance posture against shared frameworks (ISO 27001, SOC 2), providing a structured method for evaluating whether Microsoft-cloud supply chain participants satisfy the compliance obligations identified in the CA-07 third-party obligation register. Third-Party and Supply Chain Compliance Obligations (CA-07) requires ongoing monitoring of third-party compliance; Compliance Manager's assessment templates enable periodic evaluation of Microsoft cloud service compliance posture as part of the CA-07 evidence collection cycle. The fit is adjacent because Compliance Manager is primarily designed to assess the customer organization's own compliance rather than external vendor supply chain compliance.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every supply chain participant for each AI system in scope must have an entry in the third-party compliance obligation register documenting all flowing obligations and a corresponding executed binding contractual instrument containing audit rights, with third-party compliance attestations collected within the defined refresh cycle and incorporated into the CA-03 routing table as evidence inputs.", "evidence_required": [ "third_party_compliance_obligation_register entries for each supply chain participant containing vendor_id, vendor_role, applicable_obligations[], contract_instrument_id, contract_execution_date, and next_attestation_due_date", "executed_contract_inventory for each supply chain participant showing contract_type (DPA, EU_AI_Act_compliance_schedule, supplier_agreement), execution_date, audit_rights_clause_present=true, and sub_processor_management_clause_present=true for data processors", "third_party_attestation_collection_log showing each attestation collected with collection_date, valid_until, attesting_entity_name, attestation_scope, and the CA-03 routing_table_entry_id that references it", "service_dependency_map for each AI system listing all integrated third-party APIs, model providers, and data services cross-referenced against the obligation register to confirm no vendor is absent from the register" ], "machine_tests": [ "Query service_dependency_map for each AI system \u2192 assert every third_party_id in the map has a corresponding entry in the third_party_compliance_obligation_register", "For each obligation in the obligation register, query contract_inventory by vendor_id \u2192 assert contract.execution_date is not null and contract.audit_rights_clause_present=true", "For each third-party attestation in the collection log, assert attestation.valid_until > current_date and the attestation is referenced by a CA-03 routing table entry with last_updated_at within 10 business days of collection_date" ], "human_review": [ "Review contractual coverage for a 20% sample of supply chain participants by reading the actual contract terms and verifying that all obligations in the register are present as binding provisions rather than referenced by name only", "Assess third-party attestation authority and validity: verify that the attesting entity for each collected attestation has authority to bind the vendor (e.g., an independent auditor's SOC 2 report rather than a vendor self-attestation for high-risk obligations)", "Verify that GDPR DPAs for data processor supply chain participants include all Article 28 required provisions: sub-processor management clauses, breach notification timelines, data subject rights cooperation, and return-or-delete obligations" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Accepting vendor-provided compliance self-attestations for binding-law obligations such as GDPR Art. 28 and EU AI Act Arts. 23\u201327 instead of requiring independent third-party audit reports or certified attestations from authorized bodies", "Executing a GDPR DPA with an AI model provider without also executing an EU AI Act compliance schedule addressing the provider's value-chain obligations under Arts. 24\u201326, leaving AI-specific supply chain obligations uncontracted", "Maintaining a supply chain map that covers only primary vendors and omits sub-processors, embedded model providers within SaaS tools, and API-chained AI services that also process personal data or perform high-risk AI functions", "Collecting third-party attestations once at vendor onboarding and treating them as permanently valid rather than refreshing them on a defined cycle aligned with attestation validity periods and the CA-05 regulatory change management process", "Allowing new third-party integrations to enter production before the service dependency map, obligation register, and contractual coverage have been updated to reflect the new participant" ], "update_status": "current", "layer_code": "CA" }, { "id": "CA-08", "layer": "CA", "plane": "both", "name": "Compliance Architecture Evidence Package", "plain": "At defined intervals and before any regulatory examination or major audit, a Compliance Architecture Evidence Package must be compiled that aggregates the outputs of CA-01 through CA-07, demonstrating that the organization's compliance architecture is documented, justified, current, and operating effectively through a structured presentation traceable to source artifacts.", "threat": { "tags": [ "evidence-incompleteness", "uncompiled-package", "audit-gap", "architecture-undocumented" ], "desc": "A compliance architecture that functions operationally but is not compiled into a coherent evidence package fails to demonstrate its own effectiveness during regulatory examination. Regulators and auditors assessing compliance management systems require a structured presentation of how the organization identified its obligations, selected its frameworks, mapped evidence to requirements, classified its systems, managed regulatory changes, addressed gaps, and governed its supply chain. The absence of a compiled architecture package\u2014even if all underlying activities were performed\u2014creates an evidentiary deficit that cannot be remediated during examination." }, "standard": [ { "id": "iso_37301", "section": "\u00a710.1", "title": "Continual improvement" }, { "id": "eu_ai_act", "section": "Art. 11", "title": "Technical documentation for high-risk AI systems" }, { "id": "soc2", "section": "CC5.3", "title": "COSO Principle 12: Deploys control activities through policies and procedures" }, { "id": "cobit_2019", "section": "MEA01.05", "title": "Ensure the implementation of corrective actions" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CA-08 Compliance Architecture Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CA-08 Compliance Architecture Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CA-08 Compliance Architecture Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CA-08 Compliance Architecture Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CA-08 Compliance Architecture Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "The Compliance Architecture Evidence Package is an aggregated artifact compiled from CA-01 through CA-07 outputs. It includes current scope records, obligation map, routing table, classification artifacts, regulatory change log, gap register, and third-party obligation register, together with a compliance architecture narrative that explains the organization's approach and demonstrates the system's coherence and effectiveness.", "steps": [ "Define the Compliance Architecture Evidence Package schema, specifying which artifact version from each CA control is required, the package structure, and the compilation trigger schedule.", "Automate package compilation by querying the compliance registry for current versions of all required artifacts and assembling them into the package schema with a generation timestamp and integrity hash.", "Include a compliance architecture narrative authored by the compliance officer that explains the organization's scope determination methodology, framework selection rationale, evidence routing approach, and gap remediation posture.", "Store completed packages in the compliance registry with version control, and establish access controls enabling rapid production of the package for regulatory examination on demand within defined SLA." ], "compliance_officer": { "summary": "The Compliance Architecture Evidence Package is the compliance officer's primary deliverable for regulatory examination and executive assurance. Its quality directly reflects the quality of the entire CA layer.", "actions": [ "Author the compliance architecture narrative for each package compilation, documenting the rationale for all major architectural decisions.", "Review and approve the assembled package before each scheduled compilation and before any known examination or audit.", "Maintain package readiness as a standing capability enabling delivery to regulators within 2 business days of request." ], "metrics": [ "Package compilation frequency: at least quarterly and before all known examinations.", "Package completeness rate: all required CA-01 through CA-07 artifacts present at current versions.", "Package readiness: elapsed time from regulatory request to package delivery, target 2 business days." ], "failure_signals": [ "Package compilation skipped for a quarterly period without documented justification.", "Package presented to regulators containing stale CA-01 through CA-07 artifacts.", "Package lacking a compliance architecture narrative authored and approved by the compliance officer." ] }, "grc_auditor": { "summary": "Auditors use the Compliance Architecture Evidence Package as the entry point for compliance architecture assessments, verifying that the package accurately represents the state of each underlying CA control.", "actions": [ "Review the package for completeness against the required artifact schema and identify any missing or stale components.", "Trace a sample of package claims back to source artifacts in the compliance registry to verify accuracy.", "Report package gaps and inaccuracies as CA-layer findings requiring remediation before the next compilation." ], "metrics": [ "Package completeness confirmation: all required artifact types present.", "Claim traceability rate: sampled claims traceable to source artifacts with matching content." ], "failure_signals": [ "Package artifact versions not matching current versions in the compliance registry.", "Compliance architecture narrative not consistent with the underlying artifacts.", "Package compiled without all CA-01 through CA-07 outputs present." ] }, "legal_counsel": { "summary": "Legal counsel reviews the compliance architecture narrative for legal accuracy and co-signs the package for use in regulatory examinations and litigation proceedings.", "actions": [ "Review the compliance architecture narrative for legal accuracy before each package compilation, with particular attention to regulatory interpretation statements.", "Co-sign packages intended for regulatory examination to authenticate the legal accuracy of the architectural claims.", "Advise on privilege considerations for compliance architecture documentation used in the context of regulatory enforcement." ], "failure_signals": [ "Packages presented to regulators without legal counsel review of the architecture narrative.", "Regulatory interpretation statements in the narrative inconsistent with current legal counsel advisories.", "No process for asserting privilege over sensitive compliance architecture documentation." ] }, "executive": { "summary": "The Compliance Architecture Evidence Package is the executive's assurance that the compliance management system is documented, effective, and examination-ready. Executives should understand its contents at a high level and ensure it is maintained as an institutional capability.", "actions": [ "Receive a summary briefing on package compilation results each quarter, including completeness and any identified gaps in the underlying CA controls.", "Ensure organizational commitment to maintaining package readiness as a standing operational capability.", "Review the package before any regulatory examination or major audit to understand the organization's compliance architecture posture." ], "failure_signals": [ "Executive leadership not briefed on package compilation results in the quarter preceding a regulatory examination.", "Package readiness not maintained as a standing capability, requiring emergency compilation for examinations.", "Package gaps identified at the time of regulatory examination due to inadequate quarterly maintenance." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations produce compliance documentation reactively when examinations are announced rather than maintaining a standing evidence package. CA-08 establishes the discipline of continuous package maintenance so that the organization is always examination-ready, which is itself evidence of a mature compliance management system." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "eu-high-risk-ai", "high-risk-sector", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "GRC Platform Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a710.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a710.1 requires organizations to continually improve the suitability, adequacy, and effectiveness of their compliance management system. The Compliance Architecture Evidence Package provides the systematic documentation of the compliance management system's state that enables continual improvement by making architectural decisions visible, comparable across compilation cycles, and subject to review. Each package compilation creates a versioned record that enables the organization to demonstrate improvement over time.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11", "fit": "direct", "rationale": "EU AI Act Article 11 requires providers of high-risk AI systems to draw up technical documentation demonstrating compliance with the Act's requirements before placing the system on the market. The Compliance Architecture Evidence Package, when compiled for a specific AI system, provides the compliance architecture component of the Article 11 technical documentation by documenting the scope determination, classification, framework mapping, and evidence routing decisions. This package makes the compliance management system's outputs traceable and auditable for notified body review.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC5.3", "fit": "partial", "rationale": "SOC 2 CC5.3 addresses the COSO Principle of deploying control activities through policies and procedures, requiring organizations to document that controls are designed and operating effectively. The Compliance Architecture Evidence Package demonstrates that compliance controls are not only designed but are producing structured, verifiable evidence of their operation. The fit is partial because CC5.3 addresses control deployment documentation broadly while CA-08 focuses specifically on compiling compliance architecture evidence.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA01.05", "fit": "direct", "rationale": "COBIT 2019 MEA01.05 (Ensure the implementation of corrective actions) requires tracking that corrective actions arising from performance and conformance monitoring are implemented. CA-08's evidence package compilation reports on package readiness, surfaces missing or stale CA-layer outputs, and drives the corrective actions needed to keep the compliance architecture evidence complete.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "partial", "rationale": "GDPR Article 5(2) establishes the accountability principle, requiring controllers to demonstrate compliance with data processing principles. For AI systems processing personal data, the Compliance Architecture Evidence Package provides the documented demonstration of accountability that Article 5(2) requires, by showing that the organization systematically identified GDPR obligations, mapped them to controls, and monitored compliance. The fit is partial because Article 5(2) addresses accountability for data processing principles while CA-08 compiles compliance architecture evidence across all applicable frameworks.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Component 5 \u2014 Information, Communication, and Reporting", "fit": "adjacent", "rationale": "The COSO ERM 2017 Information, Communication, and Reporting component (Component 5, Principles 18\u201320) requires the organization to leverage information systems and to report on risk, culture, and performance to internal and external stakeholders. CA-08's evidence package is the structured reporting artifact that communicates compliance management system performance and enables that review cycle. The fit is adjacent because COSO ERM addresses enterprise risk reporting broadly while CA-08 focuses specifically on compiling compliance architecture evidence.", "normative_force": "best-practice", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's Compliance Score and associated assessment reports provide structured, quantified compliance posture documentation that can serve as a component of the Compliance Architecture Evidence Package (CA-08), particularly for the obligation map and control effectiveness sections. CA-08 requires compiling current outputs from CA-01 through CA-07 into a coherent package; for organizations using Compliance Manager, its compliance score history and assessment snapshots constitute structured evidence of compliance architecture performance over time that belongs in the package alongside Apeiris attestations. The fit is partial because Compliance Manager output covers only Microsoft-cloud workloads and constitutes one evidence stream within the broader package rather than the complete evidence artifact.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact compliance reports (SOC 2 Type II, ISO 27001, FedRAMP) are supply chain evidence artifacts that must be incorporated into the Compliance Architecture Evidence Package (CA-08) for AI systems deployed on AWS, demonstrating that the infrastructure layer's compliance posture has been assessed and documented. CA-08 requires aggregating outputs from CA-07 (third-party compliance evidence) as well as the compliance architecture narrative; AWS Artifact reports fulfil the supply chain evidence requirement in the CA-07 section of the package for AWS-hosted systems. The fit is partial because AWS Artifact reports cover infrastructure compliance only and do not encompass the application-layer and AI-specific compliance evidence that CA-08 requires from Apeiris domain attestations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "partial", "rationale": "Google Cloud certification documentation (ISO 27001, SOC 2, PCI DSS) constitutes supply chain compliance evidence that belongs in the Compliance Architecture Evidence Package (CA-08) for AI systems hosted on GCP, substantiating the infrastructure compliance claims in the CA-07 section of the package. CA-08 requires a package that presents compliance architecture as traceable to source artifacts; Google's audit-verified certifications are source artifacts for GCP infrastructure compliance that regulators and auditors expect to see referenced when GCP hosts AI systems under examination. The fit is partial because Google certification documentation covers cloud infrastructure compliance rather than the AI-specific compliance obligations that dominate the CA-08 package.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The Capability Reports and Safeguards Reports the RSP requires before deployment decisions are model-provider compliance evidence; CA-08's evidence package should incorporate the currency of such vendor documentation for AI systems built on Anthropic models, alongside CA-07 supply chain evidence and CA-04 classification artifacts.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI's Enterprise Data Processing Addendum and enterprise compliance commitments are binding contractual compliance artifacts that must be included in the Compliance Architecture Evidence Package (CA-08) for AI systems using OpenAI APIs, demonstrating that the data processor relationship is governed by a compliant contractual instrument satisfying GDPR Art. 28 requirements. CA-08 requires the package to aggregate CA-07 supply chain compliance evidence including executed contractual instruments; the OpenAI Enterprise DPA is the primary contractual instrument in the OpenAI supply chain and its current, executed version should be referenced in the package with its version date and key compliance provisions documented in the architecture narrative. The fit is partial because the Enterprise DPA is one supply chain compliance artifact among many that CA-08 must compile, rather than a comprehensive compliance architecture document.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CA-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The Compliance Architecture Evidence Package must exist as a compiled, version-controlled artifact containing current outputs of all CA-01 through CA-07 controls, a compliance architecture narrative authored by the compliance officer, and must be deliverable to a regulator within 2 business days of request. Evidence of the most recent quarterly compilation must be present in the compliance registry.", "evidence_required": [ "compliance_architecture_package record with version identifier, compiled_at timestamp, and artifact_manifest listing each CA-01 through CA-07 artifact version included", "compliance_architecture_narrative document signed by the compliance officer and co-signed by legal counsel, dated within the current compilation cycle", "compliance_registry audit log showing quarterly package compilation events with completeness status for each required artifact", "package_delivery_sla_record documenting elapsed time from last regulatory or audit request to package delivery, confirming target of 2 business days met", "integrity_hash record for the compiled package confirming immutability after approval" ], "machine_tests": [ "Query compliance registry for CA-08 package compiled_at timestamp \u2192 assert value is within 90 days of current date", "Retrieve package artifact_manifest \u2192 assert all 7 artifact types (CA-01 scope_record, CA-02 obligation_map, CA-03 routing_table, CA-04 classification_artifacts, CA-05 regulatory_change_log, CA-06 gap_register, CA-07 third_party_register) are present at non-stale versions", "Check compliance_registry package record for narrative_signed_by field \u2192 assert compliance_officer name and legal_counsel co-signer are populated with dates within the current compilation cycle", "Simulate package retrieval request and measure response time \u2192 assert package is retrievable within the 2-business-day SLA window" ], "human_review": [ "Review the compliance architecture narrative for accuracy, completeness, and consistency with underlying CA-01 through CA-07 artifacts before each regulatory examination", "Assess whether legal counsel has reviewed and co-signed the narrative and whether any regulatory interpretation statements have been updated since last legal review", "Verify that the package compilation schedule is maintained as a standing quarterly discipline rather than triggered only by known examination dates" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Compiling the evidence package only when a regulatory examination is announced rather than maintaining quarterly compilation as a standing operational discipline", "Including stale CA-01 through CA-07 artifact versions in the package without confirming they reflect current system state", "Producing a compliance architecture narrative that was not reviewed by legal counsel for accuracy of regulatory interpretation statements", "Storing the package in an access-restricted location that prevents timely production to regulators within the 2-business-day SLA", "Assembling the package manually from disparate storage locations rather than automating compilation from the compliance registry" ], "update_status": "current", "layer_code": "CA" }, { "id": "OB-01", "layer": "OB", "plane": "data", "name": "Obligation Register", "plain": "Every AI system must have an authoritative, machine-readable inventory of all regulatory, contractual, and certification obligations applicable to it, with each obligation linked to the AI system, jurisdiction, source instrument, and fulfillment status.", "threat": { "tags": [ "obligation-blindness", "untracked-liability", "shadow-compliance", "stale-register" ], "desc": "Without a centralized obligation register, enterprises operate blind to their compliance exposure. Obligations originating from different sources \u2014 contracts, regulation, certification bodies \u2014 accumulate inconsistently across teams. Gaps go undetected until audit findings or enforcement actions surface them." }, "standard": [ { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "coso_erm", "section": "Principle 10", "title": "Identifies Risk" }, { "id": "eu_ai_act", "section": "Art. 9", "title": "Risk management system obligations for high-risk AI" }, { "id": "cobit_2019", "section": "APO12.02", "title": "Analyse risk" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-01 Obligation Register control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-01 Obligation Register control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/OB-01 Obligation Register control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/OB-01 Obligation Register control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/OB-01 Obligation Register control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured obligation register as a machine-readable dataset (JSON-LD or CSV with schema), version-controlled, linked to each AI system by system ID, updated on a defined review cadence, and surfaced through a dashboard with obligation-status views.", "steps": [ "Define a canonical obligation schema covering: obligation_id, source_instrument, jurisdiction, obligation_type (regulatory/contractual/certification), ai_system_scope, fulfillment_status, owner_id, due_date, and evidence_refs.", "Populate the register from all applicable sources: EU AI Act, GDPR, DORA, relevant contracts and DPAs, ISO certifications, and sector-specific requirements.", "Integrate the register with the control matrix so each OB-layer control references the obligations it satisfies.", "Schedule a quarterly obligation review to capture new or amended requirements and update fulfillment status based on evidence collected." ], "compliance_officer": { "summary": "The obligation register is the foundation of the compliance program \u2014 without it, you cannot demonstrate that you know what is required of you.", "actions": [ "Own and maintain the register as a living document updated at least quarterly.", "Coordinate with Legal to capture contractual obligations as they are signed.", "Produce a register completeness report for executive review each quarter." ], "metrics": [ "Register completeness rate: percentage of known AI systems with a populated obligation register (target \u226595%).", "Obligation staleness rate: percentage of obligations not reviewed in more than 90 days (target <5%)." ], "failure_signals": [ "Register not updated following a new regulatory publication or contract signature.", "AI system deployed without a corresponding obligation register entry." ] }, "legal_counsel": { "summary": "Every contract, DPA, and AI addendum generates obligations that must be captured in the register to be enforceable and trackable.", "actions": [ "Review all signed contracts and DPAs and extract AI-specific obligations for register entry.", "Flag any obligation that creates a binding legal duty with a binding-law or contractual classification." ], "failure_signals": [ "Contractual obligations discovered only at audit time rather than at signing.", "Register entries missing jurisdiction or source instrument reference." ] }, "grc_auditor": { "summary": "The obligation register is the primary artifact for audit coverage assessment. Auditors verify completeness, accuracy, and linkage to evidence.", "actions": [ "Pull a full register export and cross-reference against known applicable regulations and contracts.", "Sample 20% of obligations and verify each has an assigned owner and at least one evidence reference.", "Flag obligations with open status and no recent activity." ], "metrics": [ "Owner assignment coverage: percentage of obligations with a named owner (target 100%).", "Evidence linkage rate: percentage of obligations with at least one evidence artifact (target \u226590%)." ], "failure_signals": [ "Register completeness below 90% after six months of operation.", "Obligations found in contracts not reflected in the register." ] }, "it_operations": { "summary": "IT operations must ensure all deployed AI systems are represented in the obligation register and that system identifiers are consistent with the asset inventory.", "actions": [ "Provide a list of all AI systems in production to the compliance team for register population.", "Ensure the register's system identifiers match the CMDB asset inventory." ], "failure_signals": [ "AI systems in production with no corresponding obligation register entry.", "System identifiers in the register inconsistent with the CMDB." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have fragmented obligation tracking across spreadsheets, legal repositories, and compliance tools with no unified AI-specific register." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Compliance Team", "Legal Counsel", "GRC Office" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 requires the organization to systematically identify its compliance obligations arising from its activities, products and services, to have access to them, and to understand their implications. A machine-readable obligation register is the primary mechanism for satisfying this requirement, documenting which obligations apply to each activity.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9", "fit": "direct", "rationale": "EU AI Act Article 9 mandates a risk management system for high-risk AI, which requires identifying and documenting applicable requirements. An obligation register directly operationalizes this identification and tracking requirement across the AI system lifecycle.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "direct", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires the organization to identify risk that impacts the achievement of strategy and business objectives. Compliance obligations represent a category of risk; an obligation register is the mechanism for ensuring all obligations are identified before they become failures.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "APO12.02", "fit": "direct", "rationale": "COBIT 2019 APO12.02 (Analyse Risk) requires a comprehensive view of applicable regulatory and contractual requirements as inputs to risk analysis. An obligation register provides this structured input to risk and compliance management processes.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "partial", "rationale": "GDPR Article 5(2) accountability principle requires controllers to demonstrate compliance with data processing principles. For AI systems processing personal data, an obligation register that captures GDPR obligations supports the accountability documentation required by supervisory authorities.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.1", "fit": "partial", "rationale": "SOC 2 CC2.1 requires that the entity obtains or generates and uses relevant, quality information to support the functioning of internal control. An obligation register provides the authoritative information base for compliance controls to operate against.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager functions as a cloud-native obligation register: it ingests regulatory frameworks (ISO 27001, SOC 2, GDPR, EU AI Act) and surfaces every control as a mapped, trackable obligation linked to an AI system's operating context. The Obligation Register control (OB-01) requires a machine-readable inventory of regulatory, contractual, and certification obligations with fulfillment status \u2014 Compliance Manager's assessment template mechanism provides exactly this structure, including jurisdiction tagging and continuous status updates from Microsoft-managed improvement actions.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact supplies the authoritative compliance reports (SOC 1/2/3, ISO 27001, FedRAMP, PCI DSS, HIPAA) that an enterprise obligation register must incorporate as source instruments when the regulated AI system runs on AWS infrastructure. The Obligation Register control (OB-01) requires each obligation to be linked to its source instrument; AWS Artifact provides the on-demand, versioned access to those instruments so the register can cite accurate report editions and track their renewal dates as obligations in their own right.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "Google Cloud Compliance and Assurance provides the authoritative certifications and regulatory guidance documents that must populate the obligation register for AI systems deployed on GCP. The Obligation Register control (OB-01) requires obligations to be linked to their source instrument with jurisdiction and fulfillment status; Google's compliance resource center delivers versioned audit reports and shared responsibility matrices that clarify which obligations belong to Google versus the customer, enabling the register to accurately scope customer-owned obligations.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. OB-01's obligation register should record the obligations an enterprise actually owes for Anthropic-based systems \u2014 those in the Usage Policy and commercial terms \u2014 with the RSP referenced as the provider self-governance context rather than as a direct source of customer obligations.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "adjacent", "rationale": "OpenAI's Enterprise Data Processing Addendum and service terms introduce a category of contractual AI obligations \u2014 data residency, zero data retention, acceptable use constraints \u2014 that must appear in the obligation register as contract-sourced entries. The Obligation Register control (OB-01) requires obligations from all sources, including enterprise software agreements, to be inventoried with fulfillment status; the Enterprise DPA contains time-bound and jurisdiction-specific obligations that are distinct from regulatory obligations and require separate tracking entries.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "An authoritative, machine-readable obligation register must exist for every AI system in production, containing each applicable regulatory, contractual, and certification obligation with its source instrument, jurisdiction, fulfillment status, and linkage to the AI system identifier. No AI system may reach production without an approved obligation register entry in the compliance registry.", "evidence_required": [ "obligation_register record per AI system with system_id, obligation_id, source_instrument, jurisdiction, obligation_type (regulatory/contractual/certification), and fulfillment_status for each obligation", "compliance_registry deployment_gate log confirming obligation register approval as a prerequisite to production promotion for each AI system", "obligation_register_version_history showing review timestamps and approver identity for each update to the register", "cross-reference report mapping each obligation_id to the CA-01 scope_record and CA-02 obligation_map entries that originally triggered it" ], "machine_tests": [ "Query compliance registry for each production AI system by system_id \u2192 assert obligation_register_status is 'approved' for all systems", "For a newly registered AI system, submit to deployment pipeline without an obligation register entry \u2192 assert deployment gate blocks promotion with error=missing_obligation_register", "Retrieve obligation register for a sample AI system and check each obligation entry \u2192 assert all required fields (source_instrument, jurisdiction, fulfillment_status, obligation_type) are non-null", "Query obligation register for obligations with fulfillment_status='overdue' \u2192 assert each has an active remediation ticket linked in the register" ], "human_review": [ "Review the obligation register for a sample of AI systems to verify that all obligations identified in CA-01 scope records and CA-02 obligation maps are present and accurately classified by type and jurisdiction", "Assess whether obligations from recently enacted or amended regulations have been added to registers within the defined review cadence", "Verify that the obligation register deployment gate is enforced in the CI/CD pipeline and that no production AI systems exist without an approved register entry" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Maintaining obligation tracking in unstructured spreadsheets or document repositories that are not machine-readable or linked to the AI system registry", "Registering obligations at a coarse framework level (e.g., 'EU AI Act') without decomposing to the specific article- or requirement-level obligations that apply to the system", "Failing to update the obligation register when the AI system's deployment context changes (new jurisdiction, capability expansion, new data categories)", "Treating the obligation register as a documentation artifact reviewed annually rather than a live operational record updated as obligations are created, modified, or fulfilled", "Allowing AI systems to reach production without an approved obligation register, relying instead on post-deployment remediation" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-02", "layer": "OB", "plane": "control", "name": "Obligation Owner Assignment", "plain": "Each obligation in the register must have a named, accountable individual assigned as owner, with a designated deputy and a documented escalation path, so that no obligation is left without active human accountability at any point in its lifecycle.", "threat": { "tags": [ "unowned-obligation", "accountability-gap", "escalation-failure", "diffused-responsibility" ], "desc": "Obligations without named owners drift into gray zones of shared or assumed responsibility. When a deadline approaches or an audit arrives, no single individual has the authority or context to drive fulfillment. Escalation chains that exist only informally fail under pressure, resulting in missed obligations that trigger enforcement action or contract breach." }, "standard": [ { "id": "iso_37301", "section": "\u00a75.3", "title": "Organizational roles, responsibilities and authorities" }, { "id": "coso_erm", "section": "Principle 2", "title": "Establishes Operating Structures" }, { "id": "cobit_2019", "section": "MEA02.01", "title": "Monitor internal controls" }, { "id": "soc2", "section": "CC1.3", "title": "Board and management accountability structures" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-02 Obligation Owner Assignment control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-02 Obligation Owner Assignment control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Each obligation register entry carries an owner_id field bound to a named individual, a deputy_owner_id for coverage continuity, an owning_team, and a documented escalation_path. Owner assignments are reviewed on personnel changes and during each quarterly obligation review.", "steps": [ "Extend the obligation register schema to include owner_id (named individual), deputy_owner_id, owning_team, escalation_path, and assignment_date fields.", "Establish an assignment policy: every new obligation must have an owner assigned within five business days of register entry, with no obligation permitted to remain unassigned.", "Automate alerts when an owner leaves the organization or changes roles, triggering a mandatory reassignment workflow with a five-day SLA.", "Conduct a quarterly ownership audit to verify all assignments are current, all deputies are active employees, and escalation paths lead to reachable individuals with sufficient authority." ], "compliance_officer": { "summary": "Ownership assignment converts the obligation register from a document into an accountability system. Without it, obligations are inventoried but not managed.", "actions": [ "Enforce the policy that no obligation may exist in the register without a named owner.", "Review ownership assignments quarterly and after any organizational restructuring.", "Ensure escalation paths are tested at least annually by walking a sample obligation through the escalation chain." ], "metrics": [ "Ownership coverage rate: percentage of obligations with a named owner (target 100%).", "Deputy coverage rate: percentage of obligations with both an owner and an active deputy (target \u226590%)." ], "failure_signals": [ "Any obligation with no named owner for more than five business days.", "Escalation path not updated following an organizational change within 10 business days." ] }, "legal_counsel": { "summary": "For contractual obligations, the owner must understand the legal substance of what is owed. Legal should validate that assigned owners have sufficient authority to fulfill contractual commitments.", "actions": [ "Review owner assignments for high-risk contractual obligations and confirm the owner has authority to bind the organization on fulfillment.", "Flag obligations requiring legal sign-off where the assigned owner is not authorized to make legal representations." ], "failure_signals": [ "Owner assigned to a contractual obligation lacks authority to fulfill or represent the obligation.", "Escalation path for a legal obligation does not route through Legal Counsel." ] }, "grc_auditor": { "summary": "Owner assignment is a foundational accountability control. Auditors verify that assignments are real, current, and tested \u2014 not nominal entries in a register.", "actions": [ "Export the obligation register and verify ownership coverage is 100%.", "Contact a sample of 10% of named owners and confirm they are aware of their obligations and their escalation paths.", "Review change logs to verify ownership was reassigned when relevant personnel changes occurred within the SLA." ], "metrics": [ "Ownership awareness rate: percentage of sampled owners who correctly describe their obligations (target \u226585%).", "Reassignment timeliness: percentage of ownership gaps resolved within five business days of personnel change (target 100%)." ], "failure_signals": [ "Named owners unaware of obligations assigned to them.", "Ownership gaps persisting more than five business days after a personnel change event." ] }, "executive": { "summary": "Obligation owner assignment converts regulatory and contractual risk into personal accountability. Executives must ensure the accountability structure is reflected in performance expectations and backed by delegated authority.", "actions": [ "Ensure obligation ownership is reflected in relevant role descriptions and performance expectations for compliance-critical roles.", "Review the ownership coverage report quarterly as part of the compliance posture review." ], "failure_signals": [ "Ownership coverage below 95% reported at board or audit committee level.", "Enforcement action traced to an obligation that had no active owner at the time of the deadline." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations assign compliance ownership informally. Formal, register-bound owner assignment with documented escalation paths is uncommon outside highly regulated sectors." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "HR / People Operations", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a75.3", "fit": "direct", "rationale": "ISO 37301:2021 \u00a75.3 explicitly requires top management to assign responsibilities and authorities for compliance management roles. Obligation owner assignment is the operational implementation of this requirement at the individual obligation level, ensuring each obligation has a named accountable party.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 2", "fit": "direct", "rationale": "COSO ERM 2017 Principle 2 (Establishes Operating Structures) requires the organization to establish operating structures in the pursuit of strategy and business objectives, including the assignment of authority and responsibility. Obligation owner assignment operationalizes this principle by anchoring each compliance obligation to an individual with defined authority and documented escalation.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 16", "fit": "partial", "rationale": "EU AI Act Article 16 requires providers of high-risk AI systems to establish clear accountability for obligations on authorized representatives and responsible persons. Obligation owner assignment at the register level directly supports traceability of who is accountable for each Article 16 requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA02.01", "fit": "partial", "rationale": "COBIT 2019 MEA02.01 requires monitoring of internal controls, including verification that roles and responsibilities are assigned and functioning. Obligation owner assignment is a prerequisite to the monitoring function, establishing who is responsible before monitoring begins.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC1.3", "fit": "partial", "rationale": "SOC 2 CC1.3 requires management to establish structures, reporting lines, and appropriate authorities and responsibilities for the achievement of objectives. Owner assignment for compliance obligations demonstrates this accountability structure exists at the operational level.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's improvement action mechanism supports obligation owner assignment by allowing each control improvement action to be assigned to a specific user or team, with status tracking tied to the assignee. The Obligation Owner Assignment control (OB-02) requires each obligation to have a named accountable owner with a designated deputy and documented escalation path; Compliance Manager partially satisfies this by enforcing per-action ownership but does not natively model deputy assignment or escalation chains, making this a partial mapping that must be supplemented with process controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Entitlement Management", "fit": "direct", "rationale": "Okta Identity Governance's Entitlement Management assigns named owners and approvers to entitlements, providing a working pattern for anchoring each managed item to an accountable individual with a defined approval path. OB-02 applies the same ownership model to compliance obligations, ensuring every obligation has a named owner and documented escalation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every obligation in the obligation register must have a named, active individual assigned as owner and a designated deputy, with a documented escalation path, such that for any obligation in the register it is possible to identify the accountable person, their deputy, and the escalation chain without ambiguity or vacancy. No obligation may exist in the register in an owner-unassigned state beyond the defined assignment SLA.", "evidence_required": [ "obligation_owner_record per obligation showing owner_name, owner_role, owner_contact, deputy_name, deputy_contact, assigned_at timestamp, and escalation_path identifier", "escalation_path document defining the chain of escalation above the named owner, with named individuals at each escalation tier and response time commitments", "owner_assignment_audit_log showing all ownership changes, vacancy events, and deputy activations with timestamps and triggering events", "obligation_registry staleness report confirming no obligations have been in owner-unassigned status beyond the defined assignment SLA (target: 5 business days)" ], "machine_tests": [ "Query obligation register for any obligation record where owner_name is null or owner_status is 'vacant' \u2192 assert zero results", "Query obligation register for any obligation where deputy_name is null \u2192 assert zero results for obligations classified as 'high-risk' or 'binding-law'", "Simulate owner departure event by marking an owner record as inactive \u2192 assert automated alert fires to the escalation path and deputy is activated within the system", "Retrieve escalation_path records for all obligations \u2192 assert all paths reference named individuals with current active employment status" ], "human_review": [ "Review a sample of obligation owner assignments to confirm that named owners have sufficient authority and organizational context to drive fulfillment of the specific obligation type", "Assess whether escalation paths reflect current organizational structure and whether named escalation contacts are still in their designated roles", "Verify that obligation ownership transfer procedures operate correctly when owners change roles or leave the organization, and that no vacancy period exceeds the defined SLA" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Assigning obligations to team or role names rather than named individuals, creating shared accountability that dissolves under audit pressure", "Designating the compliance officer as owner of all obligations regardless of which functional team is responsible for fulfillment, making ownership a formality without operational teeth", "Failing to update ownership assignments when organizational restructuring occurs, leaving obligations mapped to individuals who no longer have authority over the relevant function", "Maintaining escalation paths in document form outside the obligation register where they are not consulted during automated alert workflows", "Allowing obligation ownership to go unassigned when an owner departs, treating the vacancy as a temporary gap rather than a compliance risk requiring immediate escalation" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-03", "layer": "OB", "plane": "lifecycle", "name": "Obligation Due Date and Milestone Tracking", "plain": "All obligations in the register must carry due dates and milestone breakdowns, with automated early warning notifications delivered to owners and deputies at defined lead-time thresholds, so that fulfillment activities begin with sufficient time to meet regulatory and contractual deadlines.", "threat": { "tags": [ "deadline-miss", "milestone-drift", "late-discovery", "fulfillment-lapse" ], "desc": "Compliance obligations with fixed deadlines \u2014 regulatory filings, conformity assessments, contract deliverables \u2014 are routinely missed because tracking is manual and reactive. Early warning systems do not exist, milestones are not decomposed, and owners are notified too late to remediate. Missed deadlines result in regulatory penalties, contract breaches, and loss of certifications." }, "standard": [ { "id": "iso_37301", "section": "\u00a78.1", "title": "Operational planning and control" }, { "id": "coso_erm", "section": "Principle 10", "title": "Identifies Risk" }, { "id": "cobit_2019", "section": "APO11.03", "title": "Manage quality" }, { "id": "soc2", "section": "CC4.1", "title": "COSO principle monitoring activities" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-03 Obligation Due Date and Milestone Tracking control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/OB-03 Obligation Due Date and Milestone Tracking control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-03 Obligation Due Date and Milestone Tracking control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Obligation register entries include a due_date, a milestones[] array with sub-deadlines, an alert_thresholds configuration (90/30/7 days by default), and an automated notification pipeline that pushes alerts to owners and deputies at each threshold with a weekly obligations-at-risk summary for the compliance officer.", "steps": [ "Extend the obligation register schema with due_date, milestones[] (each with milestone_id, description, due_date, owner_id, status), alert_thresholds[], and last_reminder_sent fields.", "Implement an automated alerting pipeline that evaluates all obligations daily and sends notifications to owners and deputies at the configured thresholds (90, 30, and 7 days before due date by default).", "For multi-stage obligations such as EU AI Act conformity assessments, decompose into milestones with their own due dates, owners, and alert thresholds.", "Produce a weekly obligations-at-risk report for the compliance officer covering all obligations due within 30 days and any past-due obligations, with escalation triggers for obligations with no active milestone progress." ], "compliance_officer": { "summary": "Due date tracking converts the obligation register from a static inventory into a dynamic early warning system. The compliance officer is responsible for ensuring deadlines are accurate and alerts are reaching owners.", "actions": [ "Review and validate due dates for all obligations at register entry and on each quarterly review.", "Monitor the weekly obligations-at-risk report and escalate any items with no documented progress toward fulfillment.", "Ensure milestone decomposition is in place for all multi-stage obligations before the 90-day alert window opens." ], "metrics": [ "On-time fulfillment rate: percentage of obligations fulfilled by their due date (target \u226598%).", "Obligations-at-risk rate: percentage of obligations with a due date within 30 days and no completed fulfillment evidence (target <5%)." ], "failure_signals": [ "Any obligation past due with no documented extension or waiver.", "Owner not notified until fewer than 7 days before a deadline due to alerting pipeline failure." ] }, "grc_auditor": { "summary": "Auditors verify that due dates are realistic, milestones are tracked, and the alerting pipeline is functioning. Past-due obligations with no documentation are a direct audit finding.", "actions": [ "Pull an obligations export and identify any past-due items without a documented waiver or extension.", "Test the alerting pipeline by confirming that a sample of owners received notifications at the expected alert thresholds.", "Review milestones for high-risk obligations and confirm they are decomposed with sub-deadlines and active ownership." ], "metrics": [ "Alert delivery rate: percentage of threshold events that generated a confirmed delivered notification (target 100%).", "Past-due obligation rate: percentage of obligations past due without documented waiver or extension (target 0%)." ], "failure_signals": [ "Alerting pipeline failures not detected and corrected within 24 hours.", "Past-due obligations discovered only at audit time rather than through the monitoring program." ] }, "it_operations": { "summary": "IT operations owns the alerting pipeline infrastructure. Ensuring reliable, auditable notification delivery is a technical dependency for this control.", "actions": [ "Maintain the automated obligation alerting pipeline with delivery logging, failure alerting, and a 99.5% uptime SLA.", "Provide notification delivery logs to the compliance team on request for audit purposes within 48 hours." ], "failure_signals": [ "Notification delivery failures not surfaced within 24 hours of occurrence.", "Alerting pipeline unavailable for more than 4 hours during a business day." ] }, "executive": { "summary": "A missed deadline on a regulatory obligation is a board-level risk event. Executives should receive the obligations-at-risk summary monthly and be escalated any item where a statutory or contractual penalty is at stake.", "actions": [ "Review the monthly obligations-at-risk summary and confirm high-risk items are being actively managed with documented progress.", "Approve escalation procedures for obligations where a missed deadline creates material regulatory or contractual risk." ], "failure_signals": [ "Executive not informed of a material obligation at risk until after the deadline has passed.", "Regulatory penalty imposed due to a missed obligation deadline that was trackable in the register." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations track compliance deadlines in calendars or spreadsheets without automated alerting or milestone decomposition. Automated pipeline-based tracking is not yet standard practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "IT Operations", "GRC Office" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a78.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a78.1 requires operational planning and control to manage compliance obligations, which includes tracking fulfillment timelines and ensuring timely action. Due date and milestone tracking is the direct operationalization of this planning and control requirement.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 43", "fit": "direct", "rationale": "EU AI Act Article 43 establishes conformity assessment obligations with specific procedural and timing requirements tied to deployment approval. Milestone tracking for conformity assessment obligations is necessary to ensure legally mandated timelines are met before placement of high-risk AI systems on the EU market.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "direct", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires identifying risks to the achievement of business objectives. Automated due date and milestone tracking surfaces the risk of deadline-driven compliance failures before they materialize, keeping obligation-timing risk visible and actionable.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "SOC 2 CC4.1 requires ongoing and separate evaluations to ascertain whether components of internal control are present and functioning. Obligation due date tracking and early warning alerts are monitoring activities that provide the ongoing evaluation this criterion requires.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO11.03", "fit": "partial", "rationale": "COBIT 2019 APO11.03 requires managing quality, including tracking action items to closure within defined timeframes. Obligation milestone tracking extends this practice to compliance obligations with regulatory or contractual deadlines that have material consequences for non-delivery.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager tracks improvement actions with target completion dates and progress status, providing a partial implementation of the Obligation Due Date and Milestone Tracking control (OB-03) requirements for deadline management and fulfillment activity scheduling. Compliance Manager's improvement action framework supports lead-time awareness by surfacing overdue and upcoming actions on the compliance dashboard, though it does not natively decompose obligations into sub-milestones or dispatch automated early warning notifications at configurable lead-time thresholds as OB-03 requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's routine capability assessment cadence is a vendor-side rhythm that OB-03-style milestone tracking can mirror: recurring, dated determinations with defined escalation when thresholds are approached.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "adjacent", "rationale": "Okta Identity Governance runs access certification campaigns with defined campaign windows, escalation deadlines, and automated reminders to reviewers \u2014 a milestone-tracking pattern directly applicable to the Obligation Due Date and Milestone Tracking control (OB-03). While access certifications are one category of obligation rather than the full obligation portfolio, the campaign scheduling and automated notification mechanisms in Okta Governance exemplify the early warning and milestone decomposition model that OB-03 requires across all obligation types.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every obligation in the register that carries a regulatory, contractual, or certification deadline must have a structured due date and milestone breakdown recorded in the obligation registry, with automated early warning notifications delivered to the obligation owner and deputy at defined lead-time thresholds before the deadline. Evidence of on-time notifications and owner acknowledgments must be present for all active obligations.", "evidence_required": [ "obligation_deadline_record per obligation showing due_date, milestone_breakdown (array of milestone names and target dates), and lead_time_thresholds (e.g., 30-day, 14-day, 7-day)", "notification_delivery_log confirming automated alerts were dispatched to owner and deputy at each configured lead-time threshold, with dispatch timestamps and delivery confirmation", "owner_acknowledgment_record confirming each threshold notification was acknowledged by the owner or deputy within the defined response window", "milestone_completion_log showing each milestone's actual completion date versus planned date for all active obligations with deadlines within the current reporting cycle" ], "machine_tests": [ "Query obligation register for any active obligation with a due_date within 30 days \u2192 assert notification_delivery_log contains a dispatched alert to owner and deputy within the last 24 hours", "Retrieve obligations with status='active' and check milestone_breakdown \u2192 assert all records contain at least one milestone with a target date prior to the obligation due_date", "Simulate an obligation approaching the 7-day threshold \u2192 assert system fires an escalation alert to both owner and deputy with correct obligation_id, due_date, and outstanding milestone list", "Query notification_delivery_log for the last 90 days \u2192 assert no obligation with a due_date in that window has zero notification events" ], "human_review": [ "Review the milestone breakdown for a sample of obligations to verify that milestones are operationally meaningful decompositions of fulfillment work rather than placeholder dates added to satisfy the control requirement", "Assess whether lead-time notification thresholds are calibrated appropriately to the complexity and urgency of different obligation types, particularly for DORA reporting windows and EU AI Act conformity assessment timelines", "Verify that owner acknowledgment records indicate active engagement rather than automated read receipts, confirming that owners are operationally aware of approaching deadlines" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Tracking due dates without milestone decomposition, leaving owners without a structured action plan and unable to gauge whether they are on pace to meet the deadline", "Setting uniform lead-time notification thresholds across all obligation types rather than calibrating thresholds to the complexity and severity of each obligation class", "Relying on calendar reminders or email drafts rather than a system-driven notification mechanism that creates a delivery and acknowledgment audit trail", "Treating the due date as the activation trigger for fulfillment activity rather than driving work backward from the deadline through milestone planning", "Failing to update milestone dates when fulfillment blockers are identified, leaving the milestone plan stale and unable to serve as an early warning signal" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-04", "layer": "OB", "plane": "control", "name": "EU AI Act Conformity Assessment Obligation Management", "plain": "Organizations developing or deploying high-risk AI systems subject to the EU AI Act must maintain a structured inventory of all provider obligations under Article 16 and the Articles 8\u201315 requirements they incorporate for each in-scope system, with per-Article owner assignment, conformity assessment milestone tracking, and a pre-deployment gate that blocks EU market placement until conformity assessment documentation is complete.", "threat": { "tags": [ "conformity-gap", "high-risk-ai-violation", "market-access-block", "article-noncompliance" ], "desc": "The EU AI Act imposes specific mandatory obligations on providers and deployers of high-risk AI systems, each with defined timelines tied to permitted deployment. Organizations without explicit Article-level tracking deploy systems that are technically non-compliant, exposing them to enforcement by national competent authorities, market access denial, and fines up to 3% of global annual turnover." }, "standard": [ { "id": "eu_ai_act", "section": "Arts. 8\u201315 & Art. 16", "title": "Requirements for high-risk AI systems and provider obligations" }, { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "coso_erm", "section": "Principle 6", "title": "Analyses business context" }, { "id": "cobit_2019", "section": "APO12.04", "title": "Articulate risk" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-04 EU AI Act Conformity Assessment Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-04 EU AI Act Conformity Assessment Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/OB-04 EU AI Act Conformity Assessment Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/OB-04 EU AI Act Conformity Assessment Obligation Management control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "A dedicated EU AI Act obligation module within the obligation register, with each Article 8\u201316 requirement mapped per AI system in scope, each Article assigned to a named owner, all mapped to conformity assessment milestone dates, and a pre-deployment gate enforced in the system deployment pipeline.", "steps": [ "Classify each AI system in the portfolio against the EU AI Act Annex III risk categories and flag all high-risk systems for Articles 8\u201316 obligation tracking.", "Create a structured Article mapping for each in-scope system covering: Art. 9 (risk management system), Art. 10 (data governance), Art. 11 (technical documentation), Art. 12 (record-keeping), Art. 13 (transparency and information), Art. 14 (human oversight measures), Art. 15 (accuracy, robustness, cybersecurity), and Art. 16 (provider obligations).", "Assign an owner to each Article-level obligation and link to a conformity assessment roadmap with milestone dates for each Article, tied to the system's target EU market deployment date.", "Enforce a pre-deployment gate in the release pipeline: no high-risk AI system may be placed on the EU market without a compliance officer sign-off confirming completed conformity assessment and CE marking documentation on file." ], "compliance_officer": { "summary": "EU AI Act conformity assessment is a pre-deployment legal requirement for high-risk AI. Compliance must own the Article-level obligation mapping and gate EU deployment on conformity assessment completion.", "actions": [ "Maintain the classification of all AI systems against EU AI Act Annex III criteria and update on each new system intake.", "Own the conformity assessment roadmap and report progress to executive leadership quarterly.", "Enforce the pre-deployment gate for all high-risk systems before EU market placement, documenting sign-off in the obligation register." ], "metrics": [ "High-risk AI system coverage: percentage of classified high-risk systems with full Articles 8\u201316 obligation mapping (target 100%).", "Conformity assessment completion rate: percentage of high-risk systems with completed conformity assessment before EU market deployment (target 100%)." ], "failure_signals": [ "High-risk AI system deployed in the EU without a completed conformity assessment on file.", "Article-level obligation mapping incomplete for any system with a pending EU market placement date." ] }, "legal_counsel": { "summary": "Legal must advise on the scope of high-risk classification, the applicable conformity assessment path (internal control vs. notified body), and the legal exposure from non-compliant deployment.", "actions": [ "Confirm the legal basis for each AI system's Annex III classification and document the rationale in the obligation register.", "Advise on the conformity assessment path for each in-scope system and confirm it satisfies the Article 43 requirements.", "Review the EU declaration of conformity and technical documentation before any EU market deployment." ], "failure_signals": [ "System deployed to the EU market without a documented legal review of the Annex III classification.", "Conformity assessment path selected without legal sign-off on its adequacy under Article 43." ] }, "grc_auditor": { "summary": "Auditors verify that all high-risk AI systems are classified, Articles 8\u201316 obligations are fully mapped, and conformity assessments are completed before deployment. This is the highest-stakes audit point for EU-market AI deployments.", "actions": [ "Pull the AI system inventory and verify each system has been assessed against the Annex III criteria with documented classification rationale.", "For all high-risk systems, confirm Articles 8\u201316 obligation mapping is complete and each Article has a named owner and milestone dates.", "Verify that no high-risk system was placed on the EU market without a completed conformity assessment document on file, and check the pre-deployment gate logs." ], "metrics": [ "Article mapping completeness: percentage of high-risk systems with all eight Article obligations mapped and owned (target 100%).", "Pre-deployment gate compliance: percentage of EU-deployed high-risk systems with conformity assessment documentation retrievable within 48 hours (target 100%)." ], "failure_signals": [ "High-risk system deployed to the EU with an incomplete Article obligation mapping.", "Conformity assessment documentation not locatable within 48 hours of an audit request." ] }, "executive": { "summary": "EU AI Act enforcement risk is a board-level exposure. Non-compliant deployment of high-risk AI in the EU can result in market access withdrawal, public disclosure of findings, and fines up to 3% of global annual turnover.", "actions": [ "Receive quarterly briefing on EU AI Act conformity assessment status for all high-risk AI systems targeting EU markets.", "Approve the pre-deployment gate policy and ensure it carries sufficient organizational authority to delay product launches when conformity assessment is incomplete." ], "failure_signals": [ "Enforcement action by a national competent authority for a non-compliant high-risk AI deployment.", "Pre-deployment gate bypassed without documented executive waiver." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "EU AI Act obligations are new for most organizations. Article-level tracking at the per-AI-system level is not yet standard practice; most organizations are still at the awareness stage." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "eu-high-risk-ai", "high-risk-sector", "universal-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "Product Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Arts. 8\u201315 & Art. 16", "fit": "direct", "rationale": "EU AI Act Article 16 enumerates the obligations of providers of high-risk AI systems, which incorporate the Section 2 requirements of Articles 8\u201315 (risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy and robustness). Each provision imposes a specific, legally binding requirement on providers, and this control operationalizes per-Article tracking through the conformity assessment lifecycle.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 requires identification of compliance obligations including legal requirements. EU AI Act obligations for high-risk AI systems are binding legal requirements that must be explicitly identified and tracked within the compliance management system.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 6", "fit": "partial", "rationale": "COSO ERM Principle 6 requires analysis of the business context in which risks arise. For organizations deploying AI in the EU, the EU AI Act regulatory context is a defining external factor that shapes enterprise risk exposure and requires structured obligation management to address.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "APO12.04", "fit": "partial", "rationale": "COBIT 2019 APO12.04 (Articulate Risk) requires communicating risk information to stakeholders in a manner that supports decision-making. EU AI Act conformity assessment obligations represent a regulatory risk that must be articulated to product and executive stakeholders through structured obligation management.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager includes an EU AI Act assessment template that maps the Article 16 provider obligations and Articles 8\u201315 requirements onto organizational controls, directly supporting the EU AI Act Conformity Assessment Obligation Management control (OB-04) requirement to maintain a structured Article-level inventory for each high-risk AI system. The assessment template provides per-Article owner assignment fields and tracks conformity assessment status across the full provider obligation set, enabling the pre-deployment gate required by OB-04 by surfacing incomplete assessments before market placement.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "adjacent", "rationale": "AWS Artifact's third-party audit reports (ISO 27001, SOC 2) provide infrastructure-layer assurance documentation that supports EU AI Act conformity assessment for high-risk AI systems running on AWS. The EU AI Act Conformity Assessment Obligation Management control (OB-04) requires conformity assessment documentation to be complete before EU market placement; for cloud-hosted systems, the cloud provider's independent audit reports constitute a required component of the technical documentation under Article 11, making AWS Artifact reports an adjacent input to the OB-04 evidence set.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For OB-04, the RSP's ASL-3 Deployment Standard describes the safeguards Anthropic applies before deploying models past Capability Thresholds; enterprises tracking EU AI Act provider obligations for Anthropic-based high-risk systems can reference that vendor posture as supporting evidence for risk management (Art. 9) documentation, while their own conformity obligations remain theirs to fulfill.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Data Processing Addendum", "fit": "adjacent", "rationale": "OpenAI's Data Processing Addendum is the binding contractual instrument governing personal data processing for enterprise API usage. For EU-deployed high-risk AI systems built on OpenAI services, the DPA is part of the contractual documentation base supporting the provider's conformity assessment obligations tracked by OB-04.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "For each AI system classified as high-risk under the EU AI Act, a structured obligation inventory must exist covering all provider obligations under Article 16 and the Articles 8\u201315 requirements they incorporate, with per-Article owner assignment and conformity assessment milestone tracking; a deployment gate must block EU market placement of any high-risk AI system until conformity assessment documentation is complete and approved.", "evidence_required": [ "eu_ai_act_obligation_inventory per AI system with system_id, risk_classification record referencing CA-01 scope_record, and per-Article obligation record (Arts. 8\u201316) each showing article_id, obligation_text, owner_name, fulfillment_status, and milestone_completion_dates", "conformity_assessment_completion_record showing all required technical documentation artifacts (Art. 11), conformity declaration (Art. 47), and applicable notified body certification or self-assessment justification", "deployment_gate_log confirming EU market placement was blocked until conformity_assessment_status='complete' for each high-risk AI system, with approver identity and approval timestamp", "eu_ai_act_obligation_review_log showing quarterly review events for each Article obligation, confirming continued compliance as the regulation's implementation stagger advances" ], "machine_tests": [ "Submit a deployment request for an AI system with risk_classification='eu-high-risk-ai' and conformity_assessment_status='incomplete' \u2192 assert deployment gate blocks with error=conformity_assessment_incomplete and lists outstanding Article obligations", "Query EU AI Act obligation inventory for all high-risk AI systems \u2192 assert every system has obligation records for all of Articles 9, 10, 11, 12, 13, 14, 15, and 16", "Retrieve obligation records for Art. 9 (risk management) and Art. 11 (technical documentation) \u2192 assert each record has owner_name, fulfillment_status, and at least one milestone with a completion date", "Query deployment gate logs for all EU-market-placed AI systems \u2192 assert conformity_assessment_status was 'complete' at the time of each deployment approval" ], "human_review": [ "Review the Article-level obligation inventory for a sample of high-risk AI systems to verify that obligations are mapped at the specific provision level rather than at the article heading level, and that fulfillment evidence is linked for each completed obligation", "Assess whether the conformity assessment pathway (third-party notified body versus self-assessment) is appropriate for the AI system's use case and risk classification, and whether the justification for self-assessment is documented", "Verify that the deployment gate for EU market placement is enforced in the production pipeline and that no high-risk AI system reached EU market placement with incomplete conformity assessment documentation" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Tracking EU AI Act compliance at the regulation level rather than at the individual article obligation level, resulting in an obligation register that cannot demonstrate which specific provisions have been fulfilled", "Classifying AI systems as low-risk or out-of-scope to avoid EU AI Act high-risk obligations without documented legal rationale in the CA-01 scope record", "Completing conformity assessment documentation after EU market placement has already occurred, treating the gate as a retrospective exercise rather than a pre-deployment prerequisite", "Assigning all EU AI Act article obligations to the compliance officer rather than to the functional owners (e.g., Art. 10 data governance to the data team, Art. 14 human oversight to operations)", "Failing to update the Article-level obligation inventory as the EU AI Act's implementation stagger introduces new provisions that become applicable to existing deployed systems" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-05", "layer": "OB", "plane": "control", "name": "DORA ICT Obligation Tracking", "plain": "Financial entities subject to DORA must maintain structured tracking of all ICT-related obligations across the regulation's five pillars \u2014 ICT risk management, major incident reporting, digital operational resilience testing, ICT third-party risk management, and information sharing \u2014 with alert thresholds calibrated to DORA's strict statutory reporting windows.", "threat": { "tags": [ "dora-noncompliance", "incident-reporting-miss", "resilience-testing-gap", "third-party-risk-blind-spot" ], "desc": "DORA imposes specific, time-bound obligations on financial entities with extremely tight windows, including an initial notification for major ICT incidents due within 4 hours of classifying the incident as major and no later than 24 hours from becoming aware of it. Without explicit obligation tracking calibrated to these deadlines, financial entities miss reporting windows, fail to conduct mandatory threat-led penetration testing on schedule, and cannot demonstrate to competent authorities that ICT third-party risk is managed as required by the regulation." }, "standard": [ { "id": "nist_csf", "section": "GV.OC-03", "title": "Legal, regulatory, and contractual requirements applicable to cybersecurity" }, { "id": "iso_27001", "section": "A.5.31", "title": "Legal, statutory, regulatory and contractual requirements" }, { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "cobit_2019", "section": "MEA03.01", "title": "Identify external compliance requirements" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-05 DORA ICT Obligation Tracking control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-05 DORA ICT Obligation Tracking control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-05 DORA ICT Obligation Tracking control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "A DORA-specific obligation module in the register, organized by regulatory pillar (ICT risk management, incident reporting, TLPT, third-party risk, information sharing), with each Article-level obligation mapped to in-scope entities, assigned to pillar owners, and tracked with alert thresholds that reflect DORA's statutory reporting windows rather than generic 90/30/7-day cycles.", "steps": [ "Enumerate all DORA obligations applicable to each in-scope legal entity by pillar: ICT risk management (Art. 5\u201316), incident reporting (Art. 17\u201323), digital operational resilience testing (Art. 24\u201327), ICT third-party risk management (Art. 28\u201344), and information sharing (Art. 45).", "Assign pillar owners and configure obligation-specific alert thresholds reflecting DORA's tight deadlines: initial notification within 4 hours of classification and no later than 24 hours from awareness, intermediate report within 72 hours of the initial notification, and final report within one month for major ICT incidents.", "Integrate the DORA incident reporting workflow with the incident management platform so that a declared major ICT incident automatically initiates the statutory reporting timeline and notifies the DORA obligation owner.", "Maintain a TLPT (Threat-Led Penetration Testing) schedule aligned with DORA's three-year testing cycle and track completion per critical function, with 12-month and 6-month pre-deadline alerts." ], "compliance_officer": { "summary": "DORA creates legally binding obligations with extremely tight timelines. The compliance officer must ensure DORA obligations are tracked with near-real-time alerting, not quarterly review cycles.", "actions": [ "Own the DORA obligation register and update it as supervisory guidance and regulatory technical standards are published.", "Coordinate with the CISO and incident response team to test the incident reporting obligation workflow at least annually.", "Track TLPT completion against the three-year DORA cycle and report status to executive leadership." ], "metrics": [ "DORA reporting timeliness rate: percentage of major ICT incidents where the initial notification was submitted within 4 hours of classification and no later than 24 hours from awareness (target 100%).", "TLPT coverage rate: percentage of in-scope critical functions tested within the three-year DORA cycle (target 100%)." ], "failure_signals": [ "Major ICT incident initial notification submitted after the 24-hours-from-awareness outer bound set by DORA.", "TLPT not completed for any in-scope critical function within the three-year cycle." ] }, "legal_counsel": { "summary": "DORA is directly applicable regulation in the EU. Legal must confirm applicability to each legal entity, advise on the materiality thresholds that trigger reporting obligations, and review incident reports before submission.", "actions": [ "Confirm the scope of DORA applicability to each legal entity and document the in-scope or out-of-scope classification with rationale.", "Advise on the definition of major ICT incident and the materiality thresholds that trigger the Article 19 reporting obligations.", "Review incident reports for legal accuracy before submission to competent authorities." ], "failure_signals": [ "Legal entity subject to DORA without a documented applicability determination.", "Incident report submitted to a competent authority without legal review where material penalties could result." ] }, "grc_auditor": { "summary": "DORA audits focus on evidence of timely incident reporting, TLPT completion, and ICT third-party risk management. Auditors verify that obligations are tracked and that fulfillment evidence is immediately producible.", "actions": [ "Verify DORA obligation register coverage for each in-scope entity across all five regulatory pillars.", "Review incident logs and confirm that all declared major ICT incidents triggered the DORA reporting workflow and met the prescribed statutory deadlines.", "Confirm TLPT scheduling and completion documentation for all in-scope critical functions, verifying no gaps in the three-year cycle." ], "metrics": [ "DORA obligation coverage: percentage of applicable DORA Articles with a register entry and named pillar owner (target 100%).", "Incident reporting compliance rate: percentage of reported major incidents satisfying all DORA timeline requirements (target 100%)." ], "failure_signals": [ "Major ICT incident with no corresponding DORA reporting workflow triggered.", "TLPT documentation not available within 5 business days of an audit request." ] }, "it_operations": { "summary": "IT operations is the primary source of major ICT incident declarations and the executor of TLPT programs. Integration between incident management and the DORA reporting workflow is a critical technical dependency.", "actions": [ "Integrate the incident management platform with the DORA reporting obligation workflow so that a major ICT incident declaration automatically initiates the notification timeline and alerts the DORA obligation owner.", "Support TLPT execution by providing environment access, architecture diagrams, and technical liaison to authorized testing teams within the DORA-prescribed scoping timelines." ], "failure_signals": [ "Incident management platform not integrated with DORA reporting workflow, requiring manual initiation.", "TLPT blocked by environment access issues with fewer than 30 days remaining before the testing deadline." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "DORA became applicable January 2025. Most financial entities are still building out structured DORA obligation tracking; many are managing requirements through project plans rather than an integrated obligation register." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "CISO Office", "Legal Counsel" ], "frameworks": [ { "framework": "iso_27001", "requirement_id": "A.5.31", "fit": "direct", "rationale": "ISO/IEC 27001:2022 Annex A control 5.31 requires the organization to identify and document the legal, statutory, regulatory and contractual requirements relevant to information security and keep them up to date. DORA obligations for financial entities are a direct instance of the regulatory requirements this control addresses, and ISO 27001 certification does not substitute for DORA compliance.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "GV.OC-03", "fit": "direct", "rationale": "NIST CSF 2.0 GV.OC-03 requires that legal, regulatory, and contractual requirements applicable to cybersecurity be understood and incorporated into governance. DORA's ICT obligations are precisely the class of regulatory requirements this Govern outcome addresses.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 requires organizations to identify and document their compliance obligations including binding regulatory requirements. For financial entities, DORA represents a directly applicable legal obligation that must be explicitly identified and tracked within the compliance management system.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.01", "fit": "direct", "rationale": "COBIT 2019 MEA03.01 (Identify External Compliance Requirements) requires monitoring the regulatory environment and translating requirements into actionable compliance obligations. DORA obligation tracking is a direct application of this management practice for ICT-intensive financial entities.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "A1.2", "fit": "partial", "rationale": "SOC 2 Availability criterion A1.2 requires the entity to have processing and commitments to meet availability objectives. DORA's resilience testing and incident reporting obligations reinforce the availability commitments that SOC 2 trust services criteria capture.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "partial", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires identifying risks to the achievement of objectives, including regulatory obligations owed to supervisors. DORA's time-bound ICT obligations are a category of compliance risk that must be identified and tracked before deadlines are missed.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager provides assessment templates for financial services regulatory frameworks that overlap with DORA's five pillars, including ICT risk management and third-party risk controls, partially supporting the DORA ICT Obligation Tracking control (OB-05). While a dedicated DORA template is evolving, the existing financial services templates in Compliance Manager map ICT resilience obligations with improvement actions that can be adapted to DORA's statutory reporting windows, providing a partial implementation of OB-05's requirement for structured obligation tracking calibrated to DORA's strict timelines.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "adjacent", "rationale": "AWS Artifact provides the financial services compliance reports (SOC 1, SOC 2, ISO 27001, FedRAMP) that financial entities subject to DORA must obtain from ICT third-party providers under DORA's ICT third-party risk management pillar. The DORA ICT Obligation Tracking control (OB-05) requires tracking obligations across DORA's five pillars including ICT third-party risk management; obtaining and maintaining current AWS Artifact reports for cloud service providers is itself a DORA obligation that must be tracked in the OB-05 register with the appropriate review cadence.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "adjacent", "rationale": "Okta Identity Governance's audit reporting capabilities generate the identity decision trails required for DORA's ICT risk management pillar and competent authority reporting under OB-05. DORA mandates that financial entities maintain comprehensive audit logs of ICT access decisions and governance actions; Okta's governance audit reports provide time-stamped, attributable records of access certifications and policy enforcement events that can be incorporated into the structured DORA obligation tracking required by OB-05, particularly for the ICT third-party risk management pillar where vendor access governance must be demonstrable.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Financial entities subject to DORA must have a structured obligation tracking record for all ICT-related obligations across DORA's five pillars, with alert thresholds calibrated to DORA's statutory reporting windows: initial major ICT incident notification within 4 hours of classification and no later than 24 hours from awareness, with intermediate and final reports tracked to their statutory windows. Evidence of on-time alert dispatch for any ICT incident classified as major must be present in the obligation tracking system.", "evidence_required": [ "dora_obligation_register record per financial entity showing all five pillar obligation inventories (ICT risk management, incident reporting, resilience testing, third-party risk, information sharing) with owner assignments and fulfillment status", "ict_incident_classification_log showing each incident's classification event timestamp, major_incident boolean, and the triggered notification workflow initiation timestamp confirming the 4-hour window was met", "dora_incident_notification_record showing initial notification dispatched to the competent authority within 4 hours of classification and no later than 24 hours from awareness, with dispatch timestamp and submission confirmation", "resilience_testing_schedule showing DORA-compliant testing plan (including TLPT where applicable) with completion dates and test results reports" ], "machine_tests": [ "Inject a simulated ICT incident classified as 'major' into the obligation tracking system \u2192 assert automated notification workflow initiates within 4 hours of classification timestamp", "Query DORA obligation register for all five pillar categories \u2192 assert each pillar has at least one obligation record with owner_name, fulfillment_status, and due_date", "Retrieve ICT incident log for the trailing 12 months \u2192 assert every record marked major_incident=true has a corresponding notification_dispatched_at timestamp within 4 hours of classified_at", "Check DORA third-party ICT risk obligation records \u2192 assert each critical ICT third-party provider has an active contract review obligation record with last_reviewed date within the required contractual review cycle" ], "human_review": [ "Review the DORA obligation register across all five pillars to confirm that obligations are mapped at the provision level and that no pillar has obligations without named owners or active milestone tracking", "Assess whether incident classification criteria are clearly defined and operationalized so that the 4-hour notification window can be reliably triggered without requiring case-by-case legal interpretation during an active incident", "Verify that DORA TLPT (threat-led penetration testing) obligations are tracked separately from routine resilience testing and that the testing provider meets DORA's competency requirements" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Applying generic incident response procedures without DORA-specific time window calibration, causing financial entities to miss the initial notification window (4 hours from classification, no later than 24 hours from awareness) during major ICT incidents", "Tracking DORA obligations at the regulation level ('subject to DORA') rather than at the five-pillar and article level, making it impossible to demonstrate specific provision fulfillment during supervisory examination", "Scoping DORA ICT third-party risk obligations only to cloud providers while omitting other critical ICT service providers such as data analytics vendors and software-as-a-service platforms", "Conflating DORA ICT incident reporting with general operational incident management, resulting in major ICT incidents being handled through a workflow that does not trigger the statutory reporting chain", "Failing to maintain evidence of TLPT completion and scope documentation, leaving resilience testing obligations unsubstantiated during competent authority review" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-06", "layer": "OB", "plane": "control", "name": "Contractual AI Obligation Management", "plain": "All AI-specific obligations embedded in customer contracts, data processing agreements, enterprise software agreements, and AI addenda must be systematically extracted at signing, registered with named owners, and tracked for fulfillment so that contractual commitments on data use, model behavior, audit rights, and AI governance are met.", "threat": { "tags": [ "contractual-breach", "shadow-obligation", "dpa-noncompliance", "audit-right-lapse" ], "desc": "AI-specific obligations in contracts are frequently negotiated by legal and then lost in document repositories, never translated into operational tracking. Customer DPAs, AI ethics addenda, and enterprise agreements create binding commitments on data use, model behavior, and audit cooperation that are routinely missed because no operational owner tracks them. Breach of contractual AI obligations exposes the organization to contract termination, damages, and reputational harm." }, "standard": [ { "id": "gdpr", "section": "Art. 28", "title": "Processor obligations under data processing agreements" }, { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "soc2", "section": "CC9.2", "title": "Vendor and business partner risk management" }, { "id": "coso_erm", "section": "Principle 10", "title": "Identifies Risk" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-06 Contractual AI Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-06 Contractual AI Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/OB-06 Contractual AI Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/OB-06 Contractual AI Obligation Management control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-06 Contractual AI Obligation Management control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "A contract obligation extraction workflow integrated with the contract lifecycle management (CLM) system, producing structured obligation records for each AI-specific clause at contract signing, linked to the obligation register with source contract reference, counterparty, clause identifier, and fulfillment status.", "steps": [ "Establish a contract review checklist for all contracts involving AI systems, DPAs, and enterprise AI software, identifying categories of AI-specific clauses that generate operational obligations: data restrictions, model behavior commitments, audit cooperation rights, deletion schedules, and governance certifications.", "Implement an obligation extraction workflow where Legal tags AI-specific obligation clauses in the CLM system and exports structured obligation records to the compliance register within five business days of contract signing.", "Assign each contractual obligation to a functional owner \u2014 Security for audit cooperation clauses, Data Engineering for DPA processing restrictions, Product for model behavior commitments \u2014 with deputy coverage and escalation paths.", "Track audit rights exercise windows and customer audit cooperation deadlines with obligation-specific milestone tracking, including automated reminders when customers have outstanding audit rights that expire." ], "compliance_officer": { "summary": "Contractual AI obligations are operationally indistinct from regulatory obligations once signed. The compliance officer must ensure that every AI-related contract generates register entries and that obligations are tracked with the same rigor as regulatory requirements.", "actions": [ "Ensure all new AI-related contracts and DPAs trigger an obligation extraction workflow before or at signing.", "Review contractual obligation coverage quarterly and identify any contracts that have not been processed through the extraction workflow.", "Escalate to Legal any contractual obligations for which a feasible fulfillment path cannot be documented." ], "metrics": [ "Contract extraction coverage: percentage of active AI-related contracts with obligations extracted into the register (target \u226595%).", "Contractual obligation fulfillment rate: percentage of tracked contractual obligations fulfilled by their due date (target \u226598%)." ], "failure_signals": [ "Customer audit right exercised against an obligation not tracked in the register.", "Contract terminated or disputed due to an unmet AI-specific obligation." ] }, "legal_counsel": { "summary": "Legal is the authoritative source for contractual obligation extraction. Counsel must ensure AI-specific clauses are flagged at negotiation, extracted at signing, and translated into operational language that functional owners can fulfill.", "actions": [ "Review all AI-specific contract clauses during negotiation and flag any obligation that creates an operational tracking requirement before the contract is signed.", "At contract signing, export a structured obligation extract to the compliance team within five business days.", "Maintain a library of AI obligation clause templates that include realistic fulfillment requirements to inform future contract negotiations." ], "failure_signals": [ "Contract signed with AI-specific obligations that were not extracted into the register at signing.", "Obligation clause language so vague that operational fulfillment requirements cannot be determined without further negotiation." ] }, "grc_auditor": { "summary": "Contractual obligations are first-class audit artifacts. Auditors verify that contracts have been processed, obligations are in the register, and customers exercising audit rights receive timely, documented cooperation.", "actions": [ "Request a list of all active AI-related contracts and DPAs and verify each has been processed through the obligation extraction workflow.", "Sample 15% of contractual obligations and confirm each has a named owner, a due date, and at least one evidence artifact.", "Review records of any audit rights exercised by customers and confirm responses were provided within the contractually required response window." ], "metrics": [ "Contract coverage rate: percentage of active AI contracts with at least one obligation register entry (target \u226595%).", "Audit response timeliness: percentage of customer audit requests responded to within the contractual response window (target 100%)." ], "failure_signals": [ "Active AI contracts with no register entries discovered during audit.", "Customer audit response late or materially incomplete." ] }, "it_operations": { "summary": "IT operations must support contractual obligations that involve technical deliverables \u2014 data deletion confirmations, security controls certifications, and audit log exports.", "actions": [ "Maintain a log of contractual technical obligations such as data deletion schedules and encryption requirements, and ensure system configurations satisfy them.", "Respond to contractual audit cooperation requests involving technical evidence within the defined SLA." ], "failure_signals": [ "Data deletion obligation not executed by the contractual deadline.", "Technical audit evidence not producible within 48 hours of a customer audit request." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations lack systematic extraction of AI obligations from contracts. DPA obligations are often tracked separately from the operational compliance program with no linkage to the broader obligation register." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "multi-tenant", "eu-high-risk-ai" ], "implementers": [ "Legal Counsel", "Compliance Team", "Contract Management" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art. 28", "fit": "direct", "rationale": "GDPR Article 28 requires data processing agreements to contain specific contractual obligations on processors, including technical and organizational measures, sub-processor management, and cooperation with supervisory authorities. Tracking these DPA obligations is a direct GDPR compliance requirement for AI systems processing personal data.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 explicitly includes obligations the organization voluntarily chooses to comply with \u2014 including contractual commitments \u2014 as a category of compliance obligation to be identified and tracked. This control operationalizes that requirement specifically for AI-related contracts, DPAs, and enterprise AI agreements.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC9.2", "fit": "direct", "rationale": "SOC 2 CC9.2 requires the entity to assess and manage risks associated with vendors and business partners, including monitoring contractual commitments made to customers. Contractual AI obligation tracking directly supports the assessment and ongoing management required by this criterion.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 26", "fit": "adjacent", "rationale": "EU AI Act Article 26 defines the obligations of deployers of high-risk AI systems, several of which are shaped by the contractual and documentation relationship with the provider (use in accordance with instructions for use, cooperation duties), and Article 25 allocates responsibilities along the AI value chain through written agreements. Tracking these contractual transmissions of regulatory obligation is necessary for supply chain compliance under the EU AI Act.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "partial", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires identifying risks arising from obligations to business partners and customers. Contractual AI obligations represent a category of counterparty risk that must be identified, catalogued, and actively managed to prevent breach-driven losses.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "APO09.04", "fit": "partial", "rationale": "COBIT 2019 APO09.04 (Monitor and report service levels) requires monitoring contractual service commitments and reporting on whether they are being met. AI-specific contractual obligations extend this practice to AI behavioral, data, and governance commitments that go beyond traditional SLA metrics.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Control mapping", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's control mapping capability links organizational controls to contractual framework requirements, providing a structured basis for the Contractual AI Obligation Management control (OB-06) to track obligations extracted from customer DPAs, AI addenda, and enterprise software agreements. The control mapping mechanism partially satisfies OB-06 by connecting contractual commitments on data use and model behavior to specific internal controls, though systematic extraction of AI-specific obligations from contracts at signing and owner assignment requires supplementary workflow tooling beyond what Compliance Manager natively provides.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Artifact agreement", "fit": "partial", "rationale": "AWS Artifact agreements \u2014 including Business Associate Agreements, GDPR Data Processing Addenda, and confidentiality agreements \u2014 constitute a direct category of contractual AI obligations that must be extracted, registered, and tracked under the Contractual AI Obligation Management control (OB-06). Each AWS Artifact agreement accepted by an enterprise creates binding commitments on data handling, audit rights, and compliance cooperation that OB-06 requires to be systematically inventoried with named owners and fulfillment tracking, making AWS Artifact a primary source instrument for the contractual obligation register.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. OB-06's contractual obligation register should therefore capture the Usage Policy and commercial terms as the binding instruments for Anthropic-based systems, with the RSP's Required Safeguards recorded as provider self-governance context relevant to vendor risk assessment.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "direct", "rationale": "OpenAI's Enterprise Data Processing Addendum is a primary example of the contractual AI obligations that the Contractual AI Obligation Management control (OB-06) is designed to govern: it contains specific, time-bound commitments on data use, model behavior constraints, audit rights, zero data retention options, and data residency that must be extracted at signing, assigned to a named owner, and tracked for fulfillment. OB-06 directly targets this obligation class \u2014 AI-specific obligations embedded in enterprise agreements \u2014 making the OpenAI Enterprise DPA a direct mapping to this control's core purpose of preventing DPA obligations from being lost in document repositories after negotiation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Entitlement Management", "fit": "adjacent", "rationale": "Okta Identity Governance's Entitlement Management catalogs granted entitlements with owners and review cycles, a pattern directly analogous to cataloging contractual AI obligations with owners and review dates. OB-06 applies this register discipline to obligations arising from AI-related contracts and DPAs.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All AI-specific obligations embedded in customer contracts, data processing agreements, and AI addenda must be extracted at signing and entered into the obligation register within the defined SLA, with named owners assigned and fulfillment tracking active. No contractual AI obligation may remain unregistered beyond the defined extraction SLA, and evidence of systematic extraction must be present for all AI-related contract types.", "evidence_required": [ "contractual_obligation_extraction_record per contract showing contract_id, signing_date, extraction_completed_at timestamp (confirming SLA met), and list of extracted obligation_ids with each obligation's type (data_use, model_behavior, audit_rights, ai_governance)", "obligation_register entries for each extracted contractual obligation showing owner_name, due_date or review_cadence, and fulfillment_status", "contract_review_queue log confirming all AI-related contracts entered the extraction workflow within the defined trigger period after signing", "audit_rights_fulfillment_record documenting responses to any customer audit requests under AI contractual audit rights provisions, with response timestamps confirming contractual SLA compliance" ], "machine_tests": [ "Register a new AI-related contract in the contract management system \u2192 assert extraction workflow is triggered within the defined SLA and an obligation_extraction_record is created", "Query obligation register for contractual obligations \u2192 assert each record has obligation_type, contract_id reference, owner_name, and fulfillment_status fields populated", "Check obligation_extraction_records for all contracts signed in the trailing 90 days \u2192 assert no record has an extraction_completed_at timestamp beyond the defined SLA after contract signing_date", "Query audit_rights_fulfillment_records for any customer audit requests \u2192 assert each request has a response_dispatched_at timestamp within the contractually committed response window" ], "human_review": [ "Review a sample of AI contract obligation extractions to verify that AI-specific provisions (data use restrictions, model behavior commitments, bias and fairness obligations, audit rights) are extracted at the specific clause level rather than summarized at the contract level", "Assess whether the extraction workflow captures obligations from AI addenda and model cards attached to enterprise software agreements, not only from standalone AI contracts or DPAs", "Verify that obligation owners assigned to contractual AI obligations are the functional owners of the commitment (e.g., data use obligations assigned to the data governance team, not the legal team that negotiated the contract)" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Storing AI contract obligations in legal document management systems without extracting them into the operational obligation register, leaving fulfillment tracking dependent on lawyers remembering what was committed", "Extracting only the highest-level contractual commitments (e.g., 'comply with GDPR') without decomposing to the specific clause-level obligations that impose operational requirements on the data, model, or audit cooperation teams", "Failing to trigger the extraction workflow for AI addenda and AI ethics clauses embedded in broader enterprise software agreements, treating only standalone AI contracts as requiring obligation extraction", "Assigning all contractual AI obligations to the legal team as owner rather than routing each obligation to the functional team accountable for fulfillment", "Not tracking customer audit rights obligations in the obligation register, resulting in audit cooperation requests being handled ad hoc rather than against a defined response SLA" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-07", "layer": "OB", "plane": "control", "name": "Obligation Fulfillment Verification", "plain": "For each obligation in the register, there must be a documented verification step confirming that evidence produced by controls actually satisfies the obligation's specific requirements, with a fulfillment verdict recorded, a second-party verifier identified, and the verdict linked to the evidence artifacts used to reach it.", "threat": { "tags": [ "evidence-gap", "unfulfilled-obligation", "false-compliance", "coverage-mismatch" ], "desc": "Organizations accumulate evidence artifacts that satisfy controls but do not map back to specific obligations. The gap between having a policy document and that policy document satisfying Article 9 of the EU AI Act is where compliance programs fail audits. Without obligation-to-evidence linkage and a second-party fulfillment verification step, organizations report compliance that cannot be demonstrated under external audit pressure." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "coso_erm", "section": "Principle 16", "title": "Reviews Risk and Performance" }, { "id": "soc2", "section": "CC4.2", "title": "Evaluates and communicates deficiencies" }, { "id": "cobit_2019", "section": "MEA02.02", "title": "Review business process controls effectiveness" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-07 Obligation Fulfillment Verification control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-07 Obligation Fulfillment Verification control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/OB-07 Obligation Fulfillment Verification control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-07 Obligation Fulfillment Verification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Each obligation register entry carries an evidence_refs[] array linking to evidence artifact IDs, a fulfillment_verification_method (self-assessment / internal audit / third-party audit), a fulfillment_verdict (fulfilled / partially-fulfilled / open / not-applicable), a verified_by field naming the second-party verifier, and a verification_date. A second-party verification step is required before any verdict can advance to fulfilled.", "steps": [ "Extend the obligation register schema with evidence_refs[] (linking to evidence artifact IDs from the evidence management system), fulfillment_verification_method, fulfillment_verdict, verified_by, and verification_date fields.", "Establish a verification workflow: when an obligation owner marks an obligation as fulfilled, the system routes it to a designated second-party verifier (typically the GRC team or internal audit) who must review the linked evidence and confirm the fulfillment verdict before it is recorded.", "Build and maintain an obligation-to-control coverage map showing which controls produce evidence for which obligations, and automatically flag obligations with no mapped control as coverage gaps requiring remediation.", "Run quarterly obligation fulfillment reviews confirming that evidence artifacts linked to each obligation are current, within their validity period, and meet the specific requirements of the obligation rather than just the general requirements of the producing control." ], "compliance_officer": { "summary": "Fulfillment verification closes the loop between evidence production and obligation satisfaction. Without a second-party verification step, the obligation register reflects aspiration rather than demonstrated compliance.", "actions": [ "Establish and enforce the second-party verification requirement for all obligations before any fulfilled verdict is recorded.", "Maintain the obligation-to-control coverage map and ensure identified coverage gaps generate remediation tasks with assigned owners and deadlines.", "Report obligation fulfillment status and unresolved gaps to executive leadership quarterly." ], "metrics": [ "Obligation fulfillment rate: percentage of obligations with a fulfilled or not-applicable verdict (target \u226590%).", "Evidence linkage rate: percentage of obligations with at least one current, in-validity evidence artifact linked (target \u226595%)." ], "failure_signals": [ "Obligations marked as fulfilled without linked evidence artifacts in the register.", "Obligation-to-control coverage gaps persisting for more than 30 days without a remediation owner assigned." ] }, "grc_auditor": { "summary": "Fulfillment verification is the control auditors test most directly. Auditors pull fulfilled obligations and independently assess whether linked evidence actually satisfies the obligation's stated requirements.", "actions": [ "Export the obligation register and identify all obligations with a fulfilled verdict.", "For a 25% sample, retrieve linked evidence artifacts and independently assess whether they satisfy the specific requirements of the obligation, not just the producing control.", "Document any obligations where linked evidence does not independently satisfy the obligation and report as open audit findings requiring reclassification." ], "metrics": [ "Evidence adequacy rate: percentage of sampled fulfilled obligations where linked evidence independently satisfies the obligation (target \u226595%).", "Verification coverage: percentage of fulfilled obligations with a recorded second-party verifier and verification date (target 100%)." ], "failure_signals": [ "Fulfilled obligations with no linked evidence artifacts in the register.", "Evidence artifacts linked to obligations that are expired, superseded, or scoped to a different system than the obligation requires." ] }, "legal_counsel": { "summary": "For regulatory and contractual obligations, legal must verify that evidence meets the legal standard of the obligation, not merely its operational interpretation, before executive attestation is sought.", "actions": [ "Review fulfillment verification for high-risk regulatory obligations and confirm evidence meets the legal standard required by the source instrument.", "Flag any obligation where the legal interpretation of fulfillment differs from the compliance team's operational assessment and escalate for resolution before the verdict is finalized." ], "failure_signals": [ "Regulatory obligation declared fulfilled based on evidence that does not meet the applicable legal standard of the source instrument.", "Discrepancy between legal and compliance assessments of fulfillment not escalated within 10 business days." ] }, "it_operations": { "summary": "IT operations produces technical evidence artifacts \u2014 logs, configuration exports, test results \u2014 that fulfill technical obligations. Ensuring these artifacts are accessible, current, and properly linked is an IT operational responsibility.", "actions": [ "Maintain evidence artifact repositories with appropriate access controls and ensure artifacts are retrievable by the compliance team within 48 hours of a request.", "Notify the compliance team when evidence artifacts are updated, rotated, or expire so obligation linkages can be refreshed before a fulfillment verdict becomes stale." ], "failure_signals": [ "Technical evidence artifacts not accessible within 48 hours of an audit or verification request.", "Expired evidence artifacts remaining linked to obligations without a refresh notification sent to the compliance team." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Obligation-to-evidence linkage with a second-party fulfillment verification step is rarely implemented in practice. Most organizations have parallel compliance programs and evidence repositories with no formal verification that evidence satisfies specific named obligations." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "GRC Office", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1 requires monitoring, measurement, analysis, and evaluation of compliance performance, explicitly including whether obligations have been met. Obligation fulfillment verification operationalizes this evaluation requirement at the individual obligation level with a documented, second-party verified verdict.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 16", "fit": "direct", "rationale": "COSO ERM 2017 Principle 16 (Reviews Risk and Performance) requires reviewing entity performance and risk based on performance information. Obligation fulfillment verification provides the performance information that drives ongoing review and identifies where controls are failing to satisfy the specific obligations they are designed to address.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "direct", "rationale": "SOC 2 CC4.2 requires the entity to evaluate and communicate internal control deficiencies in a timely manner to those responsible for corrective action. Obligation fulfillment verification identifies gaps between control evidence and specific obligation requirements and routes them to remediation owners.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "direct", "rationale": "EU AI Act Article 9(2) requires a documented risk management process whose steps culminate in the adoption of appropriate and targeted risk management measures (Article 9(2)(d)), subject to regular systematic review. Obligation fulfillment verification provides the documented link between those measures (controls) and the specific requirements they satisfy.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA02.02", "fit": "direct", "rationale": "COBIT 2019 MEA02.02 requires reviewing the effectiveness of business process controls. Obligation fulfillment verification is the mechanism for confirming that compliance controls are effective in satisfying the specific obligations they are designed to address, not just operating as intended.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "partial", "rationale": "GDPR Article 5(2) requires controllers to be able to demonstrate compliance with the data processing principles at any time. Obligation fulfillment verification creates the documented linkage between GDPR obligations and evidence artifacts that makes this demonstration possible under supervisory scrutiny.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's compliance score mechanism provides a quantified fulfillment signal across all tracked improvement actions, partially implementing the Obligation Fulfillment Verification control (OB-07) requirement for a documented fulfillment verdict linked to evidence artifacts. The compliance score aggregates control implementation status with supporting evidence uploads, enabling a second-party verification pattern where Microsoft-managed actions are automatically marked fulfilled based on service telemetry while customer-managed actions require evidence submission and reviewer sign-off \u2014 a partial but meaningful match to OB-07's verdict-plus-evidence linkage requirement.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact's third-party audit reports (SOC 2 Type II, ISO 27001 certificates) serve as second-party verification artifacts for infrastructure-layer obligations tracked by OB-07, providing independent auditor verdicts on AWS control effectiveness. The Obligation Fulfillment Verification control (OB-07) requires a fulfillment verdict from a second-party verifier linked to evidence artifacts; for cloud-hosted AI systems, AWS Artifact reports constitute the verifier-sourced evidence that specific infrastructure obligations (encryption, access control, availability) are fulfilled, satisfying the evidence linkage requirement for that obligation category.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "Google Cloud compliance reports and ISO/SOC certifications provide independent auditor verification for GCP-hosted infrastructure obligations, directly satisfying the second-party verifier requirement in the Obligation Fulfillment Verification control (OB-07). When an enterprise obligation register includes GCP infrastructure controls (e.g., data encryption, access segregation, availability SLAs), Google's compliance reports deliver the externally-sourced fulfillment verdicts with evidence linkage that OB-07 requires, enabling auditors to trace obligation \u2192 verifier \u2192 evidence artifact without relying solely on first-party assertions.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "direct", "rationale": "Okta Identity Governance's access certification campaigns implement the exact second-party fulfillment verification model required by OB-07: a named verifier reviews each access obligation, records a formal verdict (certify or revoke), and the system logs the decision with timestamp, actor, and evidence context. The Obligation Fulfillment Verification control (OB-07) requires a documented verification step with a fulfillment verdict from a second-party verifier linked to evidence artifacts \u2014 Okta's access certification workflow delivers all three components natively for identity-related obligations, making this a direct mapping for the access governance subset of the enterprise obligation portfolio.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The obligation register must contain a fulfillment_verdict for every active obligation, each fulfilled verdict must be confirmed by a named second-party verifier recorded in verified_by, and every fulfilled obligation must have at least one current, in-validity evidence artifact linked in evidence_refs[]. No obligation may carry a fulfilled verdict if the linked evidence artifacts have expired or are scoped to a different system than the obligation requires.", "evidence_required": [ "Obligation register export with evidence_refs[], fulfillment_verdict, fulfillment_verification_method, verified_by, and verification_date populated for each active obligation", "Obligation-to-control coverage map showing which controls produce evidence for each obligation, with coverage gaps flagged as open remediation items with assigned owners", "Second-party verification workflow audit trail showing review initiation, verifier identity, and verdict confirmation steps per obligation", "Evidence artifact validity records confirming each artifact linked to a fulfilled obligation is within its stated validity period at the time of verdict recording", "Quarterly obligation fulfillment review report with verdict distribution summary and unresolved gap count" ], "machine_tests": [ "Query obligation register for records with fulfillment_verdict=fulfilled and evidence_refs[] empty or null \u2192 assert zero results", "Query fulfilled obligation records for entries with verified_by null or equal to obligation_owner (same-person verification) \u2192 assert zero results", "Query obligation register for obligations with coverage_mapped=false and no remediation_owner assigned for more than 30 days \u2192 assert zero results", "Submit an obligation record update setting fulfillment_verdict=fulfilled without a completed second-party verification step flag \u2192 assert system rejects or routes the record to the designated verifier without recording the verdict" ], "human_review": [ "Sample 25% of fulfilled obligations and independently retrieve linked evidence artifacts to assess whether each artifact substantively satisfies the specific legal or contractual requirement of the obligation, not merely the producing control's standard", "Assess the obligation-to-control coverage map for completeness and confirm that all obligations with coverage_mapped=false have active remediation tasks with assigned owners and deadline dates", "Verify that the second-party verification workflow enforces segregation between the obligation owner and the designated verifier for all obligation types, including self-managed contractual obligations" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Marking obligations as fulfilled based solely on the existence of a producing control without verifying that the control's evidence artifacts satisfy the obligation's specific legal or contractual requirements", "Allowing the obligation owner to serve as the second-party verifier, bypassing segregation of duties and making the verification step a self-attestation rather than an independent review", "Linking expired or superseded evidence artifacts to obligations without refreshing them before recording a fulfilled verdict, creating stale compliance records", "Maintaining fulfilled verdicts for obligations whose linked evidence artifacts have subsequently passed their validity period without triggering re-verification workflows", "Recording a single fulfillment verdict for a grouped set of obligations without obligation-specific evidence mapping, preventing auditors from tracing individual obligation satisfaction" ], "update_status": "current", "layer_code": "OB" }, { "id": "OB-08", "layer": "OB", "plane": "lifecycle", "name": "Obligations Evidence Package", "plain": "Compile and package all evidence from OB-01 through OB-07 into a structured, signed obligations evidence package demonstrating that applicable AI obligations are inventoried, owned, tracked by deadline, covered by controls, and verified as fulfilled, suitable for submission to external auditors, notified bodies, and supervisory authorities.", "threat": { "tags": [ "evidence-fragmentation", "audit-readiness-gap", "attestation-failure", "package-incompleteness" ], "desc": "Organizations with functional individual obligation controls still fail audits because evidence is fragmented across systems, not linked to specific obligations, and not assembled into a coherent audit artifact. The inability to produce a complete, well-organized obligations evidence package at audit initiation results in findings that reflect evidence management failures rather than underlying control gaps. Regulators increasingly expect on-demand, structured evidence packages." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.2", "title": "Internal audit of compliance management system" }, { "id": "soc2", "section": "CC4.1", "title": "Ongoing and separate monitoring evaluations" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Documentation keeping" }, { "id": "cobit_2019", "section": "MEA03.04", "title": "Obtain assurance of external compliance" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/OB-08 Obligations Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/OB-08 Obligations Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/OB-08 Obligations Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/OB-08 Obligations Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/OB-08 Obligations Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "An automated evidence aggregation pipeline that collects the current state of each OB-layer control, packages them into a structured OB Evidence Package with a defined manifest and completeness scorecard, and produces a signed, timestamped artifact for executive attestation and audit submission.", "steps": [ "Define the OB Evidence Package manifest: obligation register export (OB-01), ownership assignment report with coverage metrics (OB-02), obligations-at-risk report (OB-03), EU AI Act conformity assessment status per in-scope system (OB-04), DORA obligation status report per pillar (OB-05), contractual obligation extract with fulfillment status (OB-06), fulfillment verification summary with verdict distribution (OB-07), and a package completeness scorecard.", "Implement an automated evidence aggregation pipeline that assembles the OB Evidence Package on demand or on a scheduled quarterly cadence, pulling current data from each OB control's data source and computing the completeness scorecard.", "Compute the package completeness score as a weighted average of individual OB control fulfillment rates, with weights reflecting obligation criticality: regulatory obligations weighted 3x, contractual obligations 2x, and certification obligations 1x.", "Produce a signed, timestamped package artifact with an integrity hash for executive attestation, suitable for submission to external auditors, notified bodies, and supervisory authorities, and file it in a tamper-evident repository with a three-year retention period." ], "compliance_officer": { "summary": "The OB Evidence Package is the deliverable that transforms the obligation management program into an auditable artifact. The compliance officer is responsible for ensuring the package is complete, current, and signed before any scheduled external audit.", "actions": [ "Run the evidence aggregation pipeline quarterly and within 10 business days of any external audit trigger.", "Review the completeness scorecard before package finalization and assign remediation tasks for any OB layer with a score below 80%.", "Obtain executive attestation on the package before submission to external auditors, notified bodies, or regulatory authorities." ], "metrics": [ "Package completeness score: weighted average of OB-01 through OB-07 fulfillment rates (target \u226590%).", "Package production time: elapsed time from audit trigger to a completed, signed package (target \u22645 business days)." ], "failure_signals": [ "Package completeness score below 80% at the time of an external audit initiation.", "Package production time exceeding 10 business days for a scheduled external audit." ] }, "grc_auditor": { "summary": "The OB Evidence Package is the primary artifact submitted to external auditors for obligations layer coverage. Auditors verify package completeness, recency, and the integrity of the executive attestation chain.", "actions": [ "Request the OB Evidence Package at audit initiation and verify it was produced within 90 days or since the last material obligation change, whichever is more recent.", "Verify the completeness scorecard by cross-referencing the stated scores against individual OB control data exports to confirm accuracy.", "Confirm that the package carries a valid executive attestation signature and that the attesting executive reviewed the completeness scorecard before signing." ], "metrics": [ "Package recency: days since the OB Evidence Package was last produced (target \u226490 days at time of audit).", "Attestation validity: percentage of audits where an executive-signed package is produced within 5 business days of audit initiation (target 100%)." ], "failure_signals": [ "OB Evidence Package older than 90 days at the time of external audit initiation.", "Completeness scorecard scores materially inconsistent with the underlying OB control data exports." ] }, "executive": { "summary": "Executive attestation on the OB Evidence Package is a governance commitment that the organization has inventoried, owned, tracked, and verified fulfillment of its AI compliance obligations. Executives should review the completeness scorecard and open gaps before signing.", "actions": [ "Review the OB Evidence Package completeness scorecard and the open-gaps summary before signing the attestation.", "Request a briefing on any OB layer with a completeness score below 80% before providing attestation.", "Ensure the signed package is filed in the tamper-evident repository and retrievable within 48 hours of a regulatory request." ], "failure_signals": [ "Executive attestation provided on a package with a known material coverage gap below 70% without documented acceptance of residual risk.", "Attested package not retrievable within 48 hours of a regulatory or supervisory request." ] }, "legal_counsel": { "summary": "Legal must review the OB Evidence Package before executive attestation to ensure that the fulfillment evidence for regulatory and contractual obligations meets the applicable legal standard and that the attestation language does not create unintended legal representations.", "actions": [ "Review the package before executive attestation and flag any obligations where the fulfillment evidence may not satisfy the applicable legal standard.", "Advise on the form and scope of executive attestation language appropriate for each specific regulatory or notified body submission context." ], "failure_signals": [ "Package submitted to a supervisory authority with fulfillment evidence that does not meet the applicable legal standard for the obligations cited.", "Executive attestation language inadvertently creating legal representations beyond the scope of the evidence in the package." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Automated evidence package compilation for the obligations layer is an emerging practice. Most organizations assemble audit evidence manually and cannot produce a complete, signed obligations evidence package within five business days of an audit trigger." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Compliance Team", "GRC Office", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.2 requires an internal audit function for the compliance management system, including documentation of audit findings and results. The OB Evidence Package provides the structured audit artifact that supports both internal and external audits of the obligation management program.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "direct", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to keep the technical documentation, quality management system documentation, and EU declaration of conformity at the disposal of the national competent authorities for 10 years after the system is placed on the market or put into service. The OB Evidence Package is the obligations-layer component of this retained documentation, aggregating evidence that conformity assessment obligations are tracked and fulfilled.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "direct", "rationale": "SOC 2 CC4.1 requires ongoing and separate evaluations of internal controls with documentation of results. The OB Evidence Package provides the documented evaluation artifact that supports SOC 2 Type II reporting on the effectiveness of the compliance management program.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 16", "fit": "direct", "rationale": "COSO ERM 2017 Principle 16 (Reviews Risk and Performance) requires reviewing risk and entity performance and acting on the results. The OB Evidence Package is the review artifact that communicates obligation management performance and residual gaps to executives, auditors, and regulators.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "MEA03.04", "fit": "direct", "rationale": "COBIT 2019 MEA03.04 (Obtain assurance of external compliance) requires obtaining and reporting assurance of compliance and adherence with external requirements. The OB Evidence Package completeness scorecard provides that assurance reporting for the obligations layer and drives remediation of the gaps it surfaces.", "normative_force": "best-practice", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "partial", "rationale": "GDPR Article 5(2) accountability principle requires controllers to demonstrate compliance with data processing principles at any time upon supervisory request. The OB Evidence Package includes GDPR obligation tracking evidence that directly supports on-demand accountability demonstrations.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager assembles a structured, auditable compliance evidence package by aggregating improvement action completion records, uploaded evidence artifacts, assessment scores, and control implementation details into an exportable compliance posture report \u2014 directly implementing the Obligations Evidence Package control (OB-08) requirement to compile and package all obligation evidence into a structured artifact suitable for external auditors and supervisory authorities. Compliance Manager's assessment export capability produces a point-in-time package covering the full obligation lifecycle from registration through fulfillment verification, matching OB-08's requirement for a signed, complete evidence package spanning OB-01 through OB-07.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact compliance reports and attestations are required components of the Obligations Evidence Package (OB-08) for AI systems running on AWS, providing the independent infrastructure-layer audit evidence that regulators and notified bodies expect to see alongside organizational obligation documentation. OB-08 requires a structured evidence package demonstrating that obligations are inventoried, owned, tracked, and verified; for cloud-hosted systems, AWS Artifact reports satisfy the infrastructure obligation verification layer, and their on-demand, versioned access ensures the evidence package can always cite a current, unmodified third-party attestation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "partial", "rationale": "Google Cloud certification documentation (ISO 27001 certificates, SOC 2 reports, regulatory compliance guides) forms a required component of the Obligations Evidence Package (OB-08) for AI workloads hosted on GCP, supplying the independently-issued infrastructure assurance artifacts that external auditors and supervisory authorities expect to see. OB-08 requires the evidence package to demonstrate obligation fulfillment across all applicable layers; Google's certification documentation provides the cloud infrastructure layer evidence, and its structured format with scope statements and auditor details satisfies the package completeness and audit-readiness requirements that regulators increasingly demand on demand.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. Where an obligations evidence package covers Anthropic-based systems, the provider's published Capability Report and Safeguards Report summaries are the appropriate vendor-layer artifacts to reference for model-provider assurance.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "adjacent", "rationale": "Okta Identity Governance's audit reporting generates comprehensive, exportable logs of all access certifications, policy enforcement decisions, and governance workflow completions that contribute the identity governance evidence layer to the Obligations Evidence Package (OB-08). OB-08 requires the evidence package to be suitable for submission to external auditors and supervisory authorities; Okta audit reports provide the verifiable, time-stamped identity governance evidence that demonstrates obligation fulfillment for the access control and accountability obligations registered in OB-02 and verified in OB-07, completing the OB-01 through OB-07 evidence chain required by OB-08.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/OB-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A complete, signed OB Evidence Package must exist that was produced within 90 days or since the last material obligation change, carries a package completeness score of 90% or higher across all OB-01 through OB-07 components, includes an executive attestation record, and is retrievable with its integrity hash from the tamper-evident repository within 48 hours of a regulatory or supervisory authority request.", "evidence_required": [ "OB Evidence Package manifest listing all OB-01 through OB-07 component artifacts with inclusion status, source system, and component timestamp for each", "Package completeness scorecard with weighted scores per OB layer (regulatory obligations 3x, contractual 2x, certification 1x) and an overall aggregate score", "Executive attestation record with attesting executive identity, attestation_date confirming review occurred after scorecard generation, and cryptographic or wet signature", "Tamper-evident repository record with package_id, produced_at timestamp, integrity_hash, and retention_expiry confirming a three-year minimum retention period", "Aggregation pipeline execution log showing successful data pulls from each OB-01 through OB-07 data source with pull timestamps and confirmation of no pull failures" ], "machine_tests": [ "Request OB Evidence Package via evidence API \u2192 assert response includes manifest, completeness_score \u22650.90, produced_at within 90 days, executive_attested=true, and integrity_hash present", "Query package repository for any 90-day window without a produced package \u2192 assert zero gaps in package production history", "Simulate a regulatory retrieval request and retrieve the package and integrity hash \u2192 assert retrieval completes within 5 minutes with a valid integrity hash", "Validate package manifest against OB-01 through OB-07 artifact registry \u2192 assert no required component has inclusion_status=missing" ], "human_review": [ "Review the completeness scorecard and cross-reference stated scores against underlying OB control data exports to verify that scores reflect actual control fulfillment rather than self-reported estimates", "Confirm executive attestation records show the attesting executive reviewed both the completeness scorecard and the open-gaps summary before signing, and that attestation_date post-dates scorecard generation", "Assess whether the package format and evidence depth are appropriate for the specific submission context \u2014 regulatory authority, notified body, or customer audit \u2014 and that the completeness framing is tailored to the applicable legal standard of the receiving audience" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Self-reporting completeness scores without cross-referencing against underlying OB control data exports, producing inflated metrics that do not reflect actual obligation fulfillment", "Allowing executive attestation to occur before the completeness scorecard is reviewed, converting a governance act into a signature formality disconnected from the current evidence state", "Producing the OB Evidence Package only on external audit trigger rather than on a proactive quarterly schedule, resulting in packages older than 90 days at audit initiation", "Using the same package format and completeness framing for all submission audiences without adapting evidence depth to the applicable legal standard of each receiving authority", "Storing the produced package without an integrity hash, enabling undetected modification of package content between production and submission to an external auditor" ], "update_status": "current", "layer_code": "OB" }, { "id": "RF-01", "layer": "RF", "plane": "lifecycle", "name": "EU AI Act High-Risk AI System Classification", "plain": "Every AI system the enterprise develops or deploys must be evaluated against EU AI Act Annex III prohibited and high-risk categories, with documented classification rationale, ownership, and a schedule for periodic re-evaluation as system capabilities or deployment contexts change.", "threat": { "tags": [ "misclassification-risk", "regulatory-non-compliance", "scope-creep", "undetected-high-risk" ], "desc": "Failure to correctly classify an AI system as high-risk under Annex III exposes the enterprise to enforcement action, market withdrawal orders, and substantial fines. Incremental changes to model capabilities or deployment context can silently shift a system into a higher-risk category without triggering re-assessment. Absence of documented classification rationale leaves the enterprise unable to demonstrate conformity during supervisory inspections." }, "standard": [ { "id": "eu_ai_act", "section": "Annex III, Art. 6", "title": "High-risk AI system classification criteria" }, { "id": "iso_37301", "section": "\u00a74.6", "title": "Compliance risk assessment" }, { "id": "cobit_2019", "section": "APO12", "title": "Managed Risk" }, { "id": "gdpr", "section": "Art. 35", "title": "Data protection impact assessment analogy for AI risk scoping" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-01 EU AI Act High-Risk AI System Classification control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/RF-01 EU AI Act High-Risk AI System Classification control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/RF-01 EU AI Act High-Risk AI System Classification control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/RF-01 EU AI Act High-Risk AI System Classification control.", "reviewed_on": "2026-07-01" }, { "id": "eu_dora_2022_2554", "title": "EU Digital Operational Resilience Act \u2014 Regulation (EU) 2022/2554", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2022/2554", "published_on": "2022-12-14", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554", "license": "open-access", "status": "current", "flagship": false, "source_id": "dora", "relationship": "normative_requirement", "rationale": "Establishes EU Digital Operational Resilience Act \u2014 Regulation (EU) 2022/2554 requirements informing the apeiris://compliance/controls/RF-01 EU AI Act High-Risk AI System Classification control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish a classification register that maps each AI system to Annex III prohibited and high-risk categories, records the classification decision owner, documents the rationale with reference to the specific Annex III entry, and triggers re-evaluation on any material change to model, data, or deployment scope.", "steps": [ "Compile an inventory of all AI systems in development and production and assign a classification owner to each.", "Evaluate each system against all Annex III categories using a documented classification questionnaire with legal review sign-off.", "Record the classification verdict (prohibited, high-risk, general-purpose, or not-in-scope) and publish it in the compliance register.", "Define re-evaluation triggers: model version change, new deployment domain, new user population, or updated regulatory guidance.", "Schedule an annual classification review for all systems regardless of trigger events." ], "compliance_officer": { "summary": "Classification accuracy is your primary exposure control under the EU AI Act. A single missed high-risk classification can result in market withdrawal and fines up to 3% of global annual turnover.", "actions": [ "Own the classification register and ensure it covers 100% of AI systems.", "Coordinate with legal counsel on Annex III interpretation for novel use cases.", "Establish re-evaluation SLAs and monitor for missed triggers." ], "metrics": [ "Classification register completeness: target 100%.", "Re-evaluation trigger response rate: target 100% within 30 days." ], "failure_signals": [ "AI system deployed without a classification record.", "Classification not updated after a material system change.", "Legal review not obtained for borderline Annex III classifications." ] }, "legal_counsel": { "summary": "Annex III classification determinations require legal interpretation of category boundaries, particularly for biometric, critical infrastructure, and employment-related AI systems. Classification opinions should be documented as privileged legal advice.", "actions": [ "Review all borderline classification determinations and issue written opinions.", "Monitor European AI Office guidance updates that may shift classification boundaries.", "Advise on prohibited AI system prohibitions under Art. 5 as a prerequisite to Annex III analysis." ], "failure_signals": [ "Classification made without legal review for Annex III \u00a76 categories.", "No process to ingest European AI Office guidance updates." ] }, "grc_auditor": { "summary": "The classification register is the primary artifact for demonstrating that the enterprise has systematically addressed EU AI Act scope obligations. Audit for completeness, recency, and documented rationale.", "actions": [ "Request classification register export and cross-reference against the AI system inventory.", "Sample 20% of records and verify legal review sign-off and rationale completeness.", "Confirm re-evaluation triggers are defined and enforced in change management workflows." ], "metrics": [ "Classification register coverage vs. AI inventory: target 100%.", "Stale classifications (>12 months without review): target 0." ], "failure_signals": [ "Classification records missing rationale or legal sign-off.", "Re-evaluation trigger not linked to the change management process." ] }, "executive": { "summary": "Misclassification of AI systems is the foundational EU AI Act compliance risk. Executive sponsorship of the classification process ensures legal and compliance have the authority to block deployments pending classification.", "actions": [ "Confirm classification gate is a hard stop in the AI deployment approval workflow.", "Review classification register summary in quarterly governance reporting." ], "failure_signals": [ "Deployment approval granted without a classification record.", "No executive visibility into classification register status." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises lack a systematic Annex III classification process; classification decisions are ad hoc and undocumented." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "eu-high-risk-ai", "high-risk-sector", "universal-enterprise", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "AI Governance Office", "Risk Management" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 6 & Annex III", "fit": "direct", "rationale": "Art. 6 establishes the classification rule for high-risk AI systems and cross-references Annex III, which enumerates the specific product and standalone AI system categories. Enterprises must determine whether their systems fall within these categories before any other conformity obligation applies.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a74.6", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.6 requires the organization to assess compliance risks by relating its compliance obligations to its activities, products, services and relevant aspects of its operations. EU AI Act classification is a mandatory risk-assessment determination of exactly this kind, and the classification register maps naturally onto the compliance risk assessment record \u00a74.6 requires.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO12.02", "fit": "partial", "rationale": "COBIT 2019 APO12.02 covers risk analysis and requires that risk scenarios be identified and assessed systematically. Annex III classification is a regulatory risk scoping activity that fits within the APO12 managed risk domain.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 35", "fit": "adjacent", "rationale": "GDPR Art. 35 DPIA requirements establish a precedent for systematic risk-category determination before deploying processing operations. The EU AI Act classification exercise is structurally analogous and enterprises with mature DPIA processes can extend them to Annex III classification.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 11", "fit": "partial", "rationale": "COSO ERM 2017 Principle 11 (Assesses Severity of Risk, within the Performance component) requires the organization to assess the severity of identified risks. EU AI Act misclassification fits within the regulatory and compliance risk category that COSO ERM treats as a first-order enterprise risk, and RF-01's classification determination is a severity assessment of exactly this kind.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template \u2014 EU AI Act", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager provides an EU AI Act assessment template that maps compliance obligations \u2014 including high-risk AI system classification under Annex III \u2014 to trackable improvement actions and compliance score contributions. Enterprises evaluating AI systems for EU AI Act High-Risk AI System Classification can use the Purview template to scaffold the classification process, record decisions as completed improvement actions, and surface classification gaps as a scored compliance posture item visible to governance stakeholders.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's Capability Threshold classification is structurally analogous to EU AI Act risk classification \u2014 a documented, criteria-driven determination that gates deployment \u2014 and RF-01's classification register can record the provider's current determination as context for Anthropic-based systems.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Usage Policies", "fit": "adjacent", "rationale": "OpenAI's Usage Policies enumerates prohibited use categories \u2014 including certain biometric, deceptive, and high-stakes deployment patterns \u2014 that closely correspond to the EU AI Act Art. 5 prohibited practices and Annex III high-risk categories. For enterprises conducting EU AI Act High-Risk AI System Classification, reviewing OpenAI's prohibited use taxonomy provides a practical signal that a use case may require Annex III scrutiny, although the classification determination itself must be made against the Act's text and with legal review.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Regulatory guidance", "fit": "adjacent", "rationale": "Google Cloud's Compliance and Assurance program publishes regulatory guidance and shared responsibility matrices for AI workloads on GCP, including emerging EU AI Act obligations. Enterprises classifying AI systems under EU AI Act High-Risk AI System Classification can reference Google's regulatory guidance to understand how infrastructure-level controls intersect with application-level classification determinations, and to identify which classification obligations fall within the customer's shared responsibility scope.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "dora", "requirement_id": "Art. 28(3)", "fit": "supporting", "rationale": "DORA Art. 28(3) requires financial entities to maintain a register of information covering all contractual arrangements on the use of ICT services provided by ICT third-party service providers. AI services consumed from third parties fall within this register, and RF-01's EU AI Act classification must align with the entity's DORA ICT third-party risk categorization.", "normative_force": "binding-law", "source_version": "2022/2554", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://compliance/controls/RF-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI system in the enterprise's development or production inventory must have a classification record in the EU AI Act classification register with a verdict (prohibited, high-risk, general-purpose, or not-in-scope), documented rationale citing the specific Annex III entries evaluated, a named classification owner, and legal counsel sign-off for all high-risk and borderline determinations. No system may be deployed without a classification record.", "evidence_required": [ "EU AI Act classification register export with system_id, classification_verdict, annex_iii_entries_evaluated[], classification_owner, classification_date, and legal_sign_off_date for each system", "AI system inventory cross-reference report confirming coverage parity between the full system inventory and the classification register, with unexplained gaps listed as open findings", "Legal review opinion records for all high-risk and borderline classification decisions citing the specific Annex III category and classification rationale", "Re-evaluation trigger log showing change management events (model version, deployment domain, user population changes) linked to re-evaluation workflow initiations with response timestamps", "Annual classification review completion records for all systems confirming review occurred regardless of trigger events" ], "machine_tests": [ "Cross-reference AI system inventory against classification register \u2192 assert zero systems with no corresponding classification record", "Query classification register for records where classification_verdict=high-risk and legal_sign_off_date is null \u2192 assert zero results", "Submit a change management ticket for a model version update \u2192 assert a re-evaluation workflow trigger is automatically created and assigned within 24 hours", "Query classification records with classification_date older than 365 days and no subsequent annual review event \u2192 assert zero results" ], "human_review": [ "Sample 20% of high-risk and borderline classification records and independently assess whether the Annex III rationale citations are accurate and complete, including whether all relevant Annex III categories were considered and non-applicable entries were excluded with documented reasoning", "Verify re-evaluation SLA compliance by reviewing change management tickets for model architecture, training data, and deployment scope changes and confirming re-evaluations were initiated within 30 days of each qualifying trigger", "Assess legal review adequacy for Annex III \u00a75 (critical infrastructure) and \u00a76 (employment and workers management) category evaluations, which require specialist legal interpretation of category boundary conditions under the EU AI Act" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Classifying AI systems by analogy to superficially similar Annex III categories without evaluating each entry individually and documenting which entries were considered and why non-applicable entries were excluded", "Treating classification as a one-time pre-deployment activity and not linking re-evaluation to change management triggers when model architecture, training data, or deployment context changes post-market-placement", "Restricting legal review to systems the compliance team already suspects are high-risk rather than requiring legal sign-off for all borderline determinations where category boundaries are ambiguous", "Using a binary in-scope/out-of-scope classification schema rather than recording the full four-verdict classification with per-Annex-III-entry rationale, preventing auditors from tracing the evaluation methodology", "Deploying general-purpose AI systems without documenting whether they approach Art. 51 GPAI-with-systemic-risk thresholds, creating an unassessed regulatory exposure" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-02", "layer": "RF", "plane": "lifecycle", "name": "EU AI Act Conformity Assessment Pathway Selection", "plain": "High-risk AI systems classified under Annex III must have a documented conformity assessment pathway decision \u2014 internal conformity assessment under Art. 43(2) or third-party notified body assessment under Art. 43(1) \u2014 with the selection rationale recorded before market placement or putting into service.", "threat": { "tags": [ "pathway-misselection", "non-conformity", "notified-body-delay", "inadequate-assessment" ], "desc": "Selecting the wrong conformity assessment pathway exposes the enterprise to invalid CE declarations and potential market withdrawal. Third-party notified body assessments introduce multi-month lead times that, if not anticipated, delay product launch or require emergency remediation. Absence of documented pathway selection rationale prevents the enterprise from demonstrating conformity to market surveillance authorities." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 43", "title": "Conformity assessment procedures for high-risk AI systems" }, { "id": "iso_37301", "section": "\u00a78.1", "title": "Operational planning and control of compliance obligations" }, { "id": "cobit_2019", "section": "APO11", "title": "Managed Quality" }, { "id": "coso_erm", "section": "Principle 13", "title": "Implements Risk Responses" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-02 EU AI Act Conformity Assessment Pathway Selection control.", "reviewed_on": "2026-07-01" }, { "id": "eu_nis2_directive_2022_2555", "title": "EU NIS2 Directive \u2014 Directive (EU) 2022/2555", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2022/2555", "published_on": "2022-12-14", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022L2555", "license": "open-access", "status": "current", "flagship": false, "source_id": "nis2", "relationship": "normative_requirement", "rationale": "Establishes EU NIS2 Directive \u2014 Directive (EU) 2022/2555 requirements informing the apeiris://compliance/controls/RF-02 EU AI Act Conformity Assessment Pathway Selection control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "For each high-risk AI system in the classification register, document the conformity assessment pathway, the legal basis for the selection under Art. 43, the responsible assessment owner, and the projected timeline. Integrate pathway selection into the product development lifecycle gate before market placement.", "steps": [ "For each system in the RF-01 classification register marked high-risk, determine whether it falls under Annex III \u00a71 categories requiring mandatory third-party notified body assessment.", "Document the pathway selection decision with specific reference to the applicable Art. 43 sub-clause and obtain legal counsel sign-off.", "If the third-party pathway is selected, initiate notified body engagement at least 6 months before projected market placement to accommodate assessment lead times.", "If the internal pathway is selected, confirm the quality management system under RF-03 is in place and self-assessment is conducted against all Annex IV requirements.", "Record pathway decisions in the conformity register with version control and link records to the technical documentation package." ], "compliance_officer": { "summary": "Pathway selection is an irrevocable decision that determines the audit structure for each high-risk AI system. Internal pathway errors cannot be remediated after the CE declaration is issued without full re-assessment.", "actions": [ "Maintain a conformity pathway register cross-referenced to the classification register.", "Enforce a legal sign-off gate for every pathway selection decision.", "Track notified body engagement timelines and escalate delays." ], "metrics": [ "Pathway selection documented for 100% of high-risk systems before market placement.", "Notified body engagement lead time: target at least 6 months before projected placement." ], "failure_signals": [ "High-risk system reaches market placement without a documented pathway selection.", "Third-party pathway required but notified body not engaged within required lead time." ] }, "legal_counsel": { "summary": "Art. 43 pathway selection requires legal interpretation of which Annex III categories mandate third-party notified body assessment and which permit internal conformity procedures. Written legal opinions protecting pathway decisions are essential.", "actions": [ "Issue written pathway selection opinions for all high-risk systems.", "Monitor delegated acts under Art. 43(5) that may modify pathway requirements.", "Advise on equivalence of harmonized standards to Annex IV requirements for internal assessments." ], "failure_signals": [ "Pathway selection made without legal sign-off.", "No monitoring process in place for delegated act modifications to Art. 43." ] }, "grc_auditor": { "summary": "Pathway selection records are evidence that the enterprise has exercised the required conformity assessment judgment under Art. 43. Audit for documentation completeness, legal sign-off, and timeline feasibility.", "actions": [ "Compare the conformity pathway register against the high-risk classification register for completeness.", "Verify legal sign-off is present on each pathway decision record.", "For notified body pathways, confirm engagement evidence exists at required lead times." ], "metrics": [ "Pathway selection coverage of high-risk systems: target 100%.", "Legal sign-off rate on pathway decisions: target 100%." ], "failure_signals": [ "Pathway record missing or unsigned for any high-risk system.", "Notified body engagement timeline is non-compliant with regulatory lead time requirements." ] }, "it_operations": { "summary": "IT operations must ensure that product release gates enforce pathway selection as a hard prerequisite, blocking deployment until compliance and legal sign-off is documented.", "actions": [ "Implement a deployment gate in the CI/CD pipeline that requires a conformity pathway record identifier before a high-risk AI system image can be pushed to production.", "Integrate pathway status into the compliance dashboard for real-time visibility." ], "failure_signals": [ "Deployment completed without a conformity pathway record in the system of record.", "Pipeline gate bypassed via emergency change process without escalation." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have no formal conformity assessment pathway process; the concept is often conflated with general quality management rather than treated as a distinct EU AI Act obligation." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "eu-high-risk-ai", "high-risk-sector", "universal-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "AI Product Management", "QA/Testing Team" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 43", "fit": "direct", "rationale": "Art. 43 is the primary operative provision governing conformity assessment pathway selection, distinguishing between systems that require notified body involvement and those eligible for internal assessment procedures. Compliance with this control is a mandatory prerequisite to lawful market placement of high-risk AI systems.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a78.1", "fit": "direct", "rationale": "ISO 37301 \u00a78.1 requires that compliance obligations be operationalized into documented procedures. Conformity assessment pathway selection is a compliance obligation under the EU AI Act that must be reflected in operational controls and decision records.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO11.04", "fit": "partial", "rationale": "COBIT 2019 APO11.04 covers quality assurance and independent review, which maps to the notified body assessment pathway. The framework's distinction between internal quality assurance and independent review aligns with the Art. 43 pathway choice.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 13", "fit": "adjacent", "rationale": "COSO ERM 2017 Principle 13 (Implements Risk Responses, within the Performance component) requires the organization to identify and select risk responses. Conformity assessment pathway selection is a regulatory risk response decision that should be documented using the same structured evaluation methodology.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template \u2014 EU AI Act", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's EU AI Act assessment template includes conformity assessment pathway obligations as trackable improvement actions mapped to specific article requirements. Enterprises selecting a conformity assessment pathway for EU AI Act Conformity Assessment Pathway Selection under Art. 43 can use the Purview template to document the pathway decision, assign ownership, and surface the status as a compliance score contribution, helping ensure pathway selection is governed within the broader compliance management workflow rather than handled as an isolated legal decision.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "nis2", "requirement_id": "Art. 21 (Cybersecurity risk management)", "fit": "supporting", "rationale": "NIS2 Art. 21 mandates risk management measures for critical infrastructure operators; AI systems in-scope for NIS2 require RF-02 obligation registration to capture national transposition differences.", "normative_force": "binding-law", "source_version": "2022/2555", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" } ], "canonical_id": "apeiris://compliance/controls/RF-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every high-risk AI system in the classification register must have a conformity assessment pathway record specifying the Art. 43 legal basis for pathway selection, a named assessment owner, legal counsel sign-off, and a projected assessment timeline. For systems on the third-party pathway, notified body engagement evidence must show initiation at least 6 months before the projected market placement date. No high-risk system may reach market placement without a completed and legally signed pathway record.", "evidence_required": [ "Conformity pathway register export with system_id, pathway_type (internal/third-party), art_43_basis, assessment_owner, legal_sign_off_date, and projected_placement_date for each high-risk system", "Legal pathway selection opinion for each high-risk system citing the specific Art. 43 sub-clause and confirming the pathway type is legally permissible for the applicable Annex III category", "Notified body engagement records with engagement_initiation_date, notified_body_id, and projected assessment completion date for all third-party pathway systems", "CI/CD pipeline gate enforcement log confirming deployment was blocked for high-risk AI system images without a valid pathway record identifier in the release metadata", "Conformity pathway version history with change log linking each pathway record revision to the CE declaration version it supports" ], "machine_tests": [ "Cross-reference high-risk AI system classification register against conformity pathway register \u2192 assert zero high-risk systems with no corresponding pathway record", "Query conformity pathway records where legal_sign_off_date is null \u2192 assert zero results", "Attempt to push a high-risk AI system container image to production without a pathway record identifier in the image metadata \u2192 assert CI/CD pipeline rejects the push with error_code=missing_conformity_pathway", "Query third-party pathway records where (projected_placement_date - notified_body_engagement_date) < 180 days \u2192 assert zero results" ], "human_review": [ "Review legal pathway selection opinions for Annex III \u00a71 (biometrics, remote biometric identification) systems and verify opinions correctly identify whether mandatory third-party notified body assessment applies under Art. 43(1) versus internal pathway permissibility under Art. 43(2)", "Verify timeline feasibility for third-party pathway systems by confirming notified body engagement was initiated with adequate lead time relative to projected market placement and that projected assessment completion dates are consistent with the notified body's stated assessment duration", "Assess whether internal conformity assessment pathway self-assessments are conducted against all Annex IV requirements or only a subset, and confirm a quality management system per Art. 17 is documented and operational before self-assessment proceeds" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Selecting the internal conformity assessment pathway for Annex III \u00a71 biometric or remote biometric identification system categories that legally require third-party notified body assessment under Art. 43(1), producing an invalid CE declaration", "Documenting pathway selection retroactively after market placement rather than before, creating records that cannot satisfy Art. 43 timing requirements and may constitute a false conformity declaration", "Treating legal sign-off on pathway selection as a checkbox approval without requiring legal counsel to evaluate whether the specific Annex III category and Art. 43 sub-clause permit the chosen pathway", "Initiating notified body engagement simultaneously with projected market placement rather than at least 6 months in advance, creating authorization timeline risk that may delay or prevent market entry", "Treating pathway selection as a static decision without version-controlling it when system scope or Annex III classification changes, losing the audit trail of which pathway applied to each deployed version" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-03", "layer": "RF", "plane": "both", "name": "EU AI Act Technical Documentation Package (Art. 11)", "plain": "High-risk AI systems must be accompanied by a complete, current technical documentation package as specified in EU AI Act Art. 11 and Annex IV, covering system description, development methodology, training data, testing results, risk management measures, and post-market monitoring arrangements, maintained throughout the system lifecycle.", "threat": { "tags": [ "incomplete-documentation", "documentation-staleness", "audit-failure", "traceability-gap" ], "desc": "Incomplete or outdated technical documentation is the most common EU AI Act conformity failure and the primary basis for market surveillance authority enforcement actions. Documentation gaps prevent notified bodies from completing conformity assessments, causing costly delays. Stale documentation \u2014 not updated to reflect model or data changes \u2014 invalidates existing CE declarations and exposes operators to market-surveillance corrective measure orders under Art. 79." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 11 & Annex IV", "title": "Technical documentation requirements for high-risk AI systems" }, { "id": "iso_27001", "section": "A.5.9", "title": "Inventory of information and associated assets" }, { "id": "iso_37301", "section": "\u00a77.5", "title": "Documented information" }, { "id": "cobit_2019", "section": "BAI03", "title": "Managed Solutions Identification and Build" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-03 EU AI Act Technical Documentation Package (Art. 11) control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/RF-03 EU AI Act Technical Documentation Package (Art. 11) control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/RF-03 EU AI Act Technical Documentation Package (Art. 11) control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/RF-03 EU AI Act Technical Documentation Package (Art. 11) control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/RF-03 EU AI Act Technical Documentation Package (Art. 11) control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain an Annex IV-structured technical documentation package for each high-risk AI system in a version-controlled repository. Assign a documentation owner responsible for currency. Trigger documentation updates on any change to model architecture, training data, intended purpose, or risk management measures. Link documentation version to the CE declaration and conformity pathway record.", "steps": [ "Create an Annex IV documentation template covering all required sections: general description, capabilities and limitations, training data specifications, testing and validation results, risk management system documentation, post-market monitoring plan, instructions for use, and quality management system reference.", "Assign a technical documentation owner for each high-risk AI system with authority to approve updates.", "Integrate documentation update triggers into the model change management workflow: any change to model architecture, training data composition, intended use case, or deployment context must initiate a documentation review.", "Store all documentation versions in a controlled repository with retention of prior versions for 10 years after market placement as required by Art. 18.", "Before notified body submission or CE declaration, conduct a documentation completeness review against the Annex IV checklist with legal and compliance sign-off." ], "compliance_officer": { "summary": "The technical documentation package is the foundational artifact for EU AI Act conformity and the first document market surveillance authorities will request. Completeness and currency are non-negotiable.", "actions": [ "Own the Annex IV documentation completeness checklist and conduct quarterly reviews.", "Enforce documentation update triggers in the model change management process.", "Confirm 10-year retention obligations are met in the document management system." ], "metrics": [ "Annex IV section completeness per system: target 100%.", "Documentation staleness gap (days since last review vs. last model change): target 0." ], "failure_signals": [ "Any Annex IV section missing or marked as placeholder.", "Documentation not updated within 30 days of a qualifying model change." ] }, "legal_counsel": { "summary": "Technical documentation completeness is a legal conformity requirement, not an engineering best practice. Gaps in documentation invalidate CE declarations and can trigger Art. 79 corrective action orders.", "actions": [ "Review documentation packages prior to CE declaration issuance.", "Advise on Art. 18 retention obligations and documentation controller responsibilities.", "Monitor harmonized standard updates that may modify Annex IV interpretation." ], "failure_signals": [ "CE declaration issued without legal review of the underlying documentation.", "Documentation retention policy not aligned with the Art. 18 10-year requirement." ] }, "grc_auditor": { "summary": "The technical documentation package is the primary evidence artifact for EU AI Act conformity. Audit for Annex IV completeness, version currency, and linkage to CE declarations and change management records.", "actions": [ "Request documentation packages for all high-risk systems and evaluate against the Annex IV checklist.", "Verify version numbers link to the active CE declaration and conformity pathway record.", "Confirm change management tickets reference documentation update completion." ], "metrics": [ "Documentation completeness score per system: target 100% of Annex IV sections.", "Change management tickets with completed documentation update: target 100%." ], "failure_signals": [ "Documentation version predates the most recent model change.", "Annex IV sections missing or containing placeholder content." ] }, "it_operations": { "summary": "IT operations must provide a controlled documentation repository with versioning, access controls, and retention policies aligned with Art. 18 requirements.", "actions": [ "Provision a version-controlled document repository with role-based access, audit logging, and 10-year retention policy.", "Integrate the documentation repository with the model registry so each model version is linked to its documentation version.", "Implement automated staleness alerts when a model version changes without a corresponding documentation update." ], "failure_signals": [ "Documentation repository lacks version control or audit logging.", "Model registry and documentation repository are decoupled with no automated linkage." ] } }, "maturity": { "current": "developing", "target": "defined", "notes": "Most AI teams maintain partial documentation but lack the structured Annex IV format and version-control linkage required for regulatory conformity." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "eu-high-risk-ai", "high-risk-sector", "universal-enterprise", "federated-enterprise" ], "implementers": [ "AI Engineering", "Compliance Team", "Technical Documentation Team", "Legal Counsel" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 11 & Annex IV", "fit": "direct", "rationale": "Art. 11 imposes a mandatory obligation on providers of high-risk AI systems to draw up technical documentation before market placement, and Annex IV specifies the required documentation sections. This control implements the documentation assembly and maintenance obligation in its entirety.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27001", "requirement_id": "A.5.9", "fit": "partial", "rationale": "ISO 27001 A.5.9 requires an inventory of information assets and their associated owners. Treating the technical documentation package as a controlled information asset with assigned ownership and version management aligns with this requirement and supports broader ISMS integration.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_37301", "requirement_id": "\u00a77.5", "fit": "direct", "rationale": "ISO 37301 \u00a77.5 requires that documented information be created, maintained, and controlled as evidence of compliance. The Annex IV technical documentation package is precisely the documented information required to evidence EU AI Act conformity obligations.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "BAI03.07", "fit": "partial", "rationale": "COBIT 2019 BAI03.07 covers solution documentation and knowledge transfer, requiring that solution documentation be maintained throughout the solution lifecycle. This maps to the ongoing maintenance obligation for Annex IV documentation across the AI system lifecycle.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "GV.OC-03", "fit": "adjacent", "rationale": "NIST CSF 2.0 GV.OC-03 requires that legal, regulatory, and contractual requirements be understood and incorporated into governance. Technical documentation serves as evidence that legal requirements are understood and operationalized, supporting the broader governance context.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template \u2014 EU AI Act", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's EU AI Act assessment template maps Annex IV technical documentation requirements to improvement actions that can track the status of each documentation section as a compliance score component. For EU AI Act Technical Documentation Package (Art. 11), Purview provides an actionable framework for breaking the Annex IV documentation obligation into discrete, assignable tasks with completion tracking and governance visibility, supporting the documentation owner's obligation to maintain a complete and current package.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS compliance audit reports (ISO 27001, SOC 2, FedRAMP) that serve as foundational infrastructure attestation evidence when assembling the EU AI Act Technical Documentation Package under Art. 11 and Annex IV. Because Annex IV requires documentation of the AI system's development and deployment environment controls, AWS compliance reports can be incorporated by reference into the technical documentation package to evidence the security and compliance posture of the underlying cloud infrastructure on which the high-risk AI system operates.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "partial", "rationale": "Google Cloud's Compliance and Assurance resource center provides certification documentation \u2014 including ISO 27001, SOC 2, and cloud-specific attestations \u2014 that can be incorporated by reference into the EU AI Act Technical Documentation Package for high-risk AI systems deployed on GCP. Annex IV \u00a71(d) requires documentation of the technical measures taken to ensure security, robustness, and accuracy; Google's certification documentation provides third-party validation of the underlying infrastructure controls that support those measures.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For RF-03's technical documentation package, Anthropic's published model documentation and capability reporting supply the model-provider inputs to Annex IV sections describing the model layer of the system.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI's Enterprise Data Processing Addendum documents data handling practices, sub-processor arrangements, and data retention policies that must be reflected in the training data and data handling sections of the EU AI Act Technical Documentation Package under Annex IV \u00a71(e). Enterprises using OpenAI APIs as a component of a high-risk AI system must include the DPA as a vendor data processing evidence artifact within the technical documentation package to demonstrate that data governance obligations are satisfied throughout the AI system's data supply chain.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/RF-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Each high-risk AI system must have an Annex IV technical documentation package with all required sections substantively populated \u2014 no missing sections or placeholder content \u2014 version-controlled and linked to the current CE declaration, updated within 30 days of any qualifying model or deployment scope change, and retained in a controlled repository for 10 years from market placement date as required by Art. 18.", "evidence_required": [ "Annex IV completeness checklist per high-risk system with completion status for each required section, documentation owner sign-off, and compliance team approval date", "Technical documentation version history linking each documentation version to the corresponding model version, CE declaration version, and the change management ticket that triggered the update", "Model change management tickets with documentation update completion confirmation timestamp within 30 days of each qualifying model or deployment scope change event", "Documentation repository access log and retention policy configuration confirming role-based access controls, full version history, and a 10-year minimum retention period anchored to market placement date", "Pre-submission documentation completeness review record with legal and compliance sign-off completed before notified body submission or CE declaration issuance" ], "machine_tests": [ "Query documentation repository for high-risk system documentation records with any Annex IV section status=missing or status=placeholder \u2192 assert zero results", "Query model registry for model versions with a production_release_date more than 30 days before the most recent documentation_update_date \u2192 assert zero results", "Attempt to push a high-risk AI system image to production without a linked documentation_version_id in the model registry \u2192 assert pipeline deployment gate blocks the push", "Query CE declaration records and verify each declaration links to a documentation version retrievable from the controlled repository \u2192 assert 100% linkage with retrievable artifacts" ], "human_review": [ "Review Annex IV documentation packages for a 25% sample of high-risk systems and assess substantive completeness \u2014 including training data specification quality, testing and validation methodology adequacy, and risk management measure specificity \u2014 not merely whether sections are populated", "Verify that model change management tickets for architecture, training data, and deployment scope changes all triggered documentation reviews and that documentation updates are substantive rather than boilerplate additions that do not reflect the actual change", "Confirm that the document repository retention policy is anchored to market_placement_date rather than document_creation_date and that retention enforcement prevents deletion during the active 10-year period for each system" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Populating Annex IV sections with generic boilerplate text that satisfies structural completeness checks without providing the substantive technical content \u2014 architecture details, training data composition, specific risk measures \u2014 required for conformity assessment", "Treating the technical documentation package as a pre-market artifact and failing to update it when model architecture, training data, or deployment context changes after market placement, creating stale conformity records", "Linking a single documentation version to multiple deployed model versions without per-version traceability, preventing reconstruction of which documentation applied to any specific deployed instance", "Storing documentation in a system lacking version history and audit logging, preventing reconstruction of the documentation state applicable at any prior point in the system lifecycle", "Setting the 10-year retention clock from document creation date rather than from market placement date, systematically under-retaining post-placement documentation revisions" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-04", "layer": "RF", "plane": "lifecycle", "name": "EU AI Act Post-Market Monitoring Plan (Art. 72)", "plain": "High-risk AI system providers must establish and operate a post-market monitoring system as required by EU AI Act Art. 72, collecting, documenting, and analyzing data on system performance throughout the operational lifecycle, and reporting serious incidents and malfunctions to market surveillance authorities within the prescribed timelines.", "threat": { "tags": [ "undetected-degradation", "serious-incident-underreporting", "monitoring-coverage-gap", "post-market-noncompliance" ], "desc": "Without a structured post-market monitoring system, AI system performance degradation goes undetected until it causes serious harm, triggering both enforcement and reputational damage. Late or absent serious incident reporting under Art. 73 is an independent regulatory violation that can result in market withdrawal orders. Absence of monitoring data prevents the provider from demonstrating ongoing conformity during market surveillance inspections." }, "standard": [ { "id": "eu_ai_act", "section": "Art. 72\u201373", "title": "Post-market monitoring and serious incident reporting" }, { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis, and evaluation" }, { "id": "nist_csf", "section": "DE.CM", "title": "Continuous Monitoring" }, { "id": "cobit_2019", "section": "DSS01", "title": "Managed Operations" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-04 EU AI Act Post-Market Monitoring Plan (Art. 72) control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/RF-04 EU AI Act Post-Market Monitoring Plan (Art. 72) control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a post-market monitoring plan for each high-risk AI system specifying metrics, data collection methods, analysis frequency, serious incident escalation thresholds, and reporting procedures. Integrate monitoring data into the technical documentation package and trigger documentation updates when monitoring reveals material changes in system performance.", "steps": [ "Draft a post-market monitoring plan for each high-risk AI system specifying: key performance indicators, data collection sources, collection frequency, analysis methodology, and thresholds for triggering serious incident assessment.", "Define serious incident criteria aligned with EU AI Act Art. 3(49) and establish an escalation workflow with defined timelines: immediate internal escalation, then competent authority notification within the Art. 73 windows \u2014 no later than 15 days for serious incidents generally, 2 days for widespread infringement or a serious incident involving critical infrastructure, and 10 days in the event of a death.", "Implement automated monitoring pipelines that collect inference-time performance data, fairness metrics, and error rates, storing results in a tamper-evident log.", "Conduct quarterly post-market monitoring reviews, comparing current performance against the baseline established in the Annex IV documentation.", "Publish an annual post-market monitoring summary and incorporate findings into the technical documentation package update cycle." ], "compliance_officer": { "summary": "Post-market monitoring is an ongoing legal obligation, not a one-time assessment. The plan must be operational before market placement and monitoring data must be available to market surveillance authorities on request.", "actions": [ "Review and approve post-market monitoring plans for each high-risk AI system.", "Maintain an incident log and verify notification timelines are met for all qualifying events.", "Ensure annual monitoring summaries are incorporated into the technical documentation package." ], "metrics": [ "Post-market monitoring plan coverage of high-risk systems: target 100%.", "Serious incident notification SLA compliance: target 100%." ], "failure_signals": [ "High-risk system in production without an approved post-market monitoring plan.", "Serious incident notification deadline missed.", "Quarterly review not completed within 30 days of period close." ] }, "grc_auditor": { "summary": "Post-market monitoring records are the primary evidence of ongoing conformity after market placement. Audit for plan completeness, monitoring data currency, and incident log integrity.", "actions": [ "Request post-market monitoring plans and verify they cover all Art. 72 required elements.", "Sample monitoring data logs for completeness and tamper-evidence controls.", "Review incident logs and verify notification records for any qualifying serious incidents." ], "metrics": [ "Monitoring data retention completeness: target 100% of required collection periods.", "Incident log entries with documented disposition: target 100%." ], "failure_signals": [ "Monitoring gaps exceeding defined collection frequency thresholds.", "Incident log entries with no documented disposition or notification record." ] }, "it_operations": { "summary": "IT operations must provision and maintain the monitoring infrastructure, ensuring data pipeline reliability, log integrity, and integration with the compliance reporting workflow.", "actions": [ "Deploy monitoring data pipelines with tamper-evident logging and defined retention periods.", "Implement alerting on threshold breaches that automatically creates incident tickets in the compliance workflow.", "Ensure monitoring infrastructure has defined availability SLAs to prevent monitoring gaps." ], "failure_signals": [ "Monitoring pipeline downtime exceeds acceptable gap thresholds.", "Threshold breach alerts not routed to the compliance team within the defined SLA." ] }, "executive": { "summary": "Post-market monitoring failures have resulted in enforcement actions against AI providers in analogous regulated industries. Executive sponsorship ensures adequate resourcing and that incident escalation paths reach decision-makers without delay.", "actions": [ "Receive quarterly post-market monitoring summary in governance reporting.", "Ensure serious incident escalation path includes executive notification for life-risk events." ], "failure_signals": [ "Executive not notified of serious incidents meeting Art. 73 reporting thresholds.", "Post-market monitoring program under-resourced relative to the number of high-risk systems in production." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Post-market monitoring for AI systems is nascent; most enterprises apply product monitoring practices without the EU AI Act-specific incident classification and notification obligations." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "eu-high-risk-ai", "high-risk-sector", "universal-enterprise", "federated-enterprise" ], "implementers": [ "AI Operations", "Compliance Team", "Security Operations", "Legal Counsel" ], "frameworks": [ { "framework": "eu_ai_act", "requirement_id": "Art. 72\u201373", "fit": "direct", "rationale": "Art. 72 mandates that providers establish a post-market monitoring system proportionate to the nature and risk of the AI system, and Art. 73 requires serious incident reporting to competent authorities within defined timelines. This control directly implements both obligations.", "normative_force": "binding-law", "source_version": "2024/1689", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 37301 \u00a79.1 requires organizations to monitor, measure, analyze, and evaluate their compliance management system performance. Post-market monitoring of high-risk AI systems is a primary compliance performance measurement obligation under this clause.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "DE.CM-09", "fit": "partial", "rationale": "NIST CSF 2.0 DE.CM-09 addresses continuous monitoring of computing hardware, software, and services for anomalies. AI system performance monitoring for EU AI Act compliance extends this continuous monitoring capability into the regulatory performance domain.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "DSS01.03", "fit": "partial", "rationale": "COBIT 2019 DSS01.03 covers monitoring of IT infrastructure, requiring that performance data be collected and reviewed against defined thresholds. This practice extends naturally to AI system performance monitoring as part of a managed operations framework.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 16", "fit": "partial", "rationale": "COSO ERM 2017 Principle 16 (Reviews Risk and Performance, within the Review and Revision component) requires ongoing review of risk and performance based on actual data. Post-market monitoring data provides the empirical basis for reviewing and revising AI risk management measures in response to observed performance.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager tracks improvement actions and compliance scores over time, enabling ongoing measurement of compliance posture changes \u2014 a function directly analogous to the post-market monitoring obligation under EU AI Act Art. 72. For EU AI Act Post-Market Monitoring Plan (Art. 72), Purview's improvement action tracking can complement the technical monitoring pipeline by providing a compliance-management-layer view of monitoring obligation fulfillment, escalation of unresolved actions, and trend reporting for management review.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's commitment to ongoing capability assessment of deployed models is the vendor-side analogue of Art. 72 post-market monitoring; RF-04's monitoring plan should note reliance on provider-side monitoring where the model layer is Anthropic-operated.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/RF-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every high-risk AI system in production must have an approved post-market monitoring plan covering all Art. 72 required elements, with monitoring data current and free of gaps exceeding the defined collection interval, and all qualifying serious incidents must have documented competent authority notification records delivered within Art. 73 prescribed timelines \u2014 no later than 15 days for serious incidents generally, 2 days for widespread infringement or critical-infrastructure incidents, and 10 days in the event of a death \u2014 from the point of detection.", "evidence_required": [ "Post-market monitoring plan per high-risk system with metrics[], collection_sources[], collection_frequency, serious_incident_thresholds[], escalation_workflow, and notification_timelines defined and approved before market placement", "Tamper-evident monitoring data log with inference-time performance metrics, fairness metrics, error rates, and collection timestamps covering the full production period with no gaps exceeding the defined collection frequency", "Serious incident log with incident_id, detection_timestamp, internal_escalation_timestamp, competent_authority_notification_timestamp, notification_method, and disposition for each qualifying event under Art. 3(49)", "Quarterly post-market monitoring review report comparing current performance metrics against the Annex IV baseline with identified deviations documented and assigned for remediation", "Annual post-market monitoring summary artifact incorporated into the technical documentation package update with version linkage" ], "machine_tests": [ "Query monitoring data log for each high-risk system and identify gaps between consecutive collection records exceeding the defined collection_frequency threshold \u2192 assert zero gap violations", "Query monitoring pipeline threshold breach events and verify each has a corresponding compliance incident ticket created within the defined SLA \u2192 assert 100% ticket creation within SLA", "Submit a simulated serious incident meeting Art. 3(49) criteria via the incident intake workflow \u2192 assert internal escalation fires within 1 hour and a competent authority notification draft is generated within 24 hours", "Compute checksums over stored monitoring log segments and compare to stored integrity records in the tamper-evident log \u2192 assert zero checksum mismatches across all high-risk system logs" ], "human_review": [ "Review the post-market monitoring plan for each high-risk system and assess whether the defined serious incident thresholds are aligned with Art. 3(49) criteria and whether performance metrics cover the specific risk profile documented in the system's Annex IV risk management section", "Inspect the serious incident log and verify that notification records exist with appropriate timestamps for all qualifying events; for incidents classified as non-serious, assess whether the classification rationale is documented and was reviewed by a second party", "Evaluate quarterly monitoring review reports for substantive trend analysis rather than threshold compliance confirmation only, and confirm findings are linked to remediation actions with assigned owners and deadlines" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Drafting a post-market monitoring plan with vague metric descriptions and qualitative thresholds rather than quantitative definitions, making automated serious incident detection impossible and classification subjective", "Setting serious incident thresholds above Art. 3(49) definitional criteria, systematically under-classifying events that trigger mandatory reporting obligations", "Collecting monitoring data in mutable logs without integrity controls such as hash chaining or append-only storage, compromising the admissibility of monitoring records as regulatory evidence", "Treating post-market monitoring as a documentation obligation fulfilled by plan existence rather than an operational system producing continuous data, resulting in monitoring plans with no corresponding monitoring data", "Initiating competent authority notification only after internal incident resolution rather than within Art. 73 prescribed timelines from the point of detection, inverting the legal notification sequence" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-05", "layer": "RF", "plane": "control", "name": "FedRAMP Authorization Support for AI Systems", "plain": "AI systems processed on cloud infrastructure serving federal agencies must operate under a valid FedRAMP authorization \u2014 either a FedRAMP-authorized cloud service or an agency ATO \u2014 with continuous monitoring controls maintained and annual assessment obligations met, and with AI-specific control enhancements documented in the system security plan.", "threat": { "tags": [ "unauthorized-federal-cloud-use", "ato-lapse", "continuous-monitoring-gap", "ai-control-gap-in-ssp" ], "desc": "AI systems operating on cloud infrastructure without valid FedRAMP authorization violate federal procurement rules and expose both the vendor and the agency to legal and reputational risk. ATO lapses result in mandatory system suspension under OMB Circular A-130. Absence of AI-specific control documentation leaves the system security plan incomplete, creating gaps that emerge during annual assessments and triggering costly remediation cycles." }, "standard": [ { "id": "nist_csf", "section": "GV.OC-03", "title": "Legal, regulatory, and contractual cybersecurity requirements" }, { "id": "aws_artifact", "section": "FedRAMP Package", "title": "AWS FedRAMP Authorized Services" }, { "id": "microsoft_compliance", "section": "FedRAMP High", "title": "Microsoft Azure FedRAMP High Authorization" }, { "id": "google_compliance", "section": "FedRAMP High", "title": "Google Cloud FedRAMP High Authorization" } ], "sources": [ { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/RF-05 FedRAMP Authorization Support for AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-05 FedRAMP Authorization Support for AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/RF-05 FedRAMP Authorization Support for AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/RF-05 FedRAMP Authorization Support for AI Systems control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/RF-05 FedRAMP Authorization Support for AI Systems control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a FedRAMP authorization inventory mapping each AI system to its cloud service provider authorization package. Document AI-specific control enhancements in the SSP. Operate a continuous monitoring program aligned with FedRAMP Rev. 5 requirements, including monthly vulnerability scanning, annual assessments, and Plan of Action and Milestones management.", "steps": [ "Inventory all AI systems processing federal data and map each to the underlying FedRAMP-authorized cloud service provider package.", "Document AI-specific control enhancements in the system security plan, covering model access controls, inference data handling, training data provenance, and AI-specific incident response procedures.", "Implement continuous monitoring controls per FedRAMP Rev. 5 requirements: monthly vulnerability scans, annual penetration testing, configuration management, and incident response testing.", "Establish a Plan of Action and Milestones process for AI-specific findings with defined remediation timelines and executive escalation for high-risk items.", "Coordinate with the sponsoring federal agency or Joint Authorization Board for authorization maintenance, including annual assessment scheduling and significant change notifications." ], "compliance_officer": { "summary": "FedRAMP authorization is a hard prerequisite for AI systems serving federal agencies. ATO lapse results in mandatory suspension; no compensating controls substitute for a valid authorization.", "actions": [ "Maintain a FedRAMP authorization status register for all AI systems in federal use.", "Track annual assessment deadlines and initiate engagements at least 90 days in advance.", "Coordinate significant change notifications with the FedRAMP program management office." ], "metrics": [ "FedRAMP authorization currency rate: target 100%.", "Annual assessment completion within the scheduled window: target 100%." ], "failure_signals": [ "AI system processing federal data without a current ATO.", "Annual assessment deadline missed or assessment window exceeded.", "Significant change deployed without FedRAMP PMO notification." ] }, "grc_auditor": { "summary": "FedRAMP continuous monitoring evidence is the primary artifact for demonstrating ongoing authorization compliance. Audit for monthly deliverable completeness, POA&M currency, and SSP AI-control coverage.", "actions": [ "Request the FedRAMP continuous monitoring package and verify monthly deliverables are complete and timely.", "Review the SSP for AI-specific control documentation coverage.", "Audit the POA&M for open high-risk items and verify remediation timelines are being met." ], "metrics": [ "Monthly FedRAMP deliverable completeness: target 100%.", "POA&M items past due: target 0 for high and critical findings." ], "failure_signals": [ "Missing monthly deliverables.", "SSP lacks AI-specific control documentation.", "High-risk POA&M items past remediation deadline." ] }, "it_operations": { "summary": "IT operations is responsible for executing FedRAMP continuous monitoring activities and producing the monthly deliverables that maintain authorization currency.", "actions": [ "Execute monthly vulnerability scanning and configuration compliance checks per the FedRAMP Rev. 5 continuous monitoring strategy.", "Automate POA&M tracking and remediation status reporting.", "Maintain FedRAMP boundary documentation including AI system data flows." ], "failure_signals": [ "Monthly vulnerability scan not completed on schedule.", "FedRAMP system boundary documentation not updated after infrastructure change." ] }, "executive": { "summary": "FedRAMP authorization is a business enablement requirement for any AI product serving the federal market. Loss of authorization results in immediate revenue impact and customer notification obligations.", "actions": [ "Confirm FedRAMP authorization status is included in executive compliance dashboards.", "Ensure budget and staffing support for annual assessment cycles and continuous monitoring operations." ], "failure_signals": [ "ATO lapse not escalated to executive level before customer impact.", "Annual assessment budget not approved in advance of the scheduled window." ] } }, "maturity": { "current": "developing", "target": "managed", "notes": "Enterprises with existing FedRAMP authorizations often lack AI-specific SSP enhancements; FedRAMP AI guidance is still evolving through NIST AI RMF integration." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "high-risk-sector", "cloud-native", "federated-enterprise", "multi-tenant" ], "implementers": [ "IT Security", "Cloud Engineering", "FedRAMP PMO", "Compliance Team" ], "frameworks": [ { "framework": "nist_csf", "requirement_id": "GV.OC-03", "fit": "direct", "rationale": "NIST CSF 2.0 GV.OC-03 requires that legal and regulatory requirements be understood and incorporated into cybersecurity governance. FedRAMP authorization requirements are the primary regulatory obligation for AI systems on federal cloud infrastructure and must be managed as a first-order governance item.", "normative_force": "supervisory-guidance", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_artifact", "requirement_id": "FedRAMP High Package", "fit": "direct", "rationale": "AWS Artifact provides access to FedRAMP authorization packages for AWS GovCloud and other FedRAMP-authorized services. Enterprises deploying AI systems on AWS must reference these packages when establishing their own authorization boundary and system security plan.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "FedRAMP High & DoD IL5", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager provides FedRAMP High assessment templates, and Azure Government holds FedRAMP High authorization and DoD Impact Level 5 provisional authorization \u2014 separate authorization regimes whose packages serve as foundational authorization evidence for AI systems deployed on Azure Government cloud.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "FedRAMP High", "fit": "direct", "rationale": "Google Cloud Compliance and Assurance provides FedRAMP High authorization packages for Google Cloud Government environments, which form the foundational authorization boundary for AI systems deployed on Google Cloud serving federal agencies.", "normative_force": "best-practice", "source_version": "2026", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "iso_27001", "requirement_id": "A.5.31", "fit": "adjacent", "rationale": "ISO/IEC 27001:2022 Annex A control 5.31 requires identification of applicable legal, statutory, regulatory, and contractual requirements. FedRAMP authorization obligations are regulatory requirements that must be identified and reflected in the organization's information security controls.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_policies", "requirement_id": "Data residency commitments", "fit": "adjacent", "rationale": "OpenAI Enterprise data residency commitments and service terms address where inference data is processed and stored \u2014 a determinative factor when assessing whether an AI system using OpenAI APIs falls within or outside the FedRAMP authorization boundary. For FedRAMP Authorization Support for AI Systems, enterprises must evaluate OpenAI's data residency options against FedRAMP boundary requirements and document any data flows to non-FedRAMP-authorized OpenAI environments in the system security plan, as such flows may require compensating controls or boundary exclusions.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "direct", "rationale": "Okta Identity Governance provides FedRAMP-authorized access certification campaigns and audit trails that directly satisfy FedRAMP Rev. 5 continuous monitoring requirements for access management controls (AC-2, AC-6). For FedRAMP Authorization Support for AI Systems, Okta's access certification capabilities generate the periodic user access review evidence required for FedRAMP annual assessments, while its governance workflow and audit reporting features produce the documentation artifacts needed to demonstrate that AI system access is managed in accordance with the system security plan throughout the authorization period.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/RF-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI system processing federal agency data must be mapped to a current, valid FedRAMP authorization with no lapse in ATO status; AI-specific control enhancements must be documented in the SSP covering model access controls, inference data handling, training data provenance, and AI-specific incident response procedures; and FedRAMP Rev. 5 continuous monitoring monthly deliverables must be complete and submitted on time for every reporting period.", "evidence_required": [ "FedRAMP authorization inventory mapping each AI system to its cloud service provider authorization package with ato_status, effective_date, expiry_date, and authorization_type (CSP package or agency ATO) for each system", "System security plan (SSP) AI-specific sections with substantive coverage of model access controls, inference data handling procedures, training data provenance controls, and AI-specific incident response procedures", "FedRAMP continuous monitoring monthly deliverable package for each reporting period with deliverable_type, completion_date, submission_date, and status for vulnerability scan results and configuration compliance reports", "Plan of Action and Milestones (POA&M) with item_id, finding_severity, assigned_remediation_date, and current_status for all open findings including AI-specific items, with zero past-due high or critical items", "Significant change notification records submitted to the FedRAMP PMO for all qualifying changes to the AI system boundary, model versions, or federal agency data flows, with submission timestamps" ], "machine_tests": [ "Query FedRAMP authorization inventory for AI systems with ato_status=expired, ato_status=missing, or expiry_date within 90 days \u2192 assert zero expired or missing, flag approaching expirations", "Query continuous monitoring deliverable log for each AI system \u2192 assert no reporting period has status=missing or status=submitted_late", "Validate SSP AI-specific sections against a defined checklist of required topics (model access, inference data handling, training data provenance, AI incident response) \u2192 assert all checklist items have substantive content and no items are marked as placeholder", "Query POA&M for items with finding_severity=high or finding_severity=critical and remediation_date in the past \u2192 assert zero past-due high or critical items" ], "human_review": [ "Review SSP AI-specific control enhancement sections for substantive adequacy, confirming that model access controls, inference data handling, and training data provenance sections describe the actual AI system architecture rather than referencing generic NIST 800-53 control language", "Verify significant change notification records and confirm all qualifying changes \u2014 new AI model versions, modified inference data flows, new federal agency integrations, and authorization boundary changes \u2014 were assessed for significant change status and submitted to the FedRAMP PMO within required timelines", "Assess POA&M remediation timelines for AI-specific findings and verify that executive escalation was initiated for high and critical items approaching or past remediation deadlines, and that no items were closed without documented remediation evidence" ], "blocking_effect": "blocks-deployment", "normative_status": "supervisory-guidance", "anti_patterns": [ "Treating the FedRAMP authorization of the underlying cloud service provider as sufficient authorization for the AI system without assessing whether AI-specific capabilities, inference data flows, and model access patterns fall within the authorized boundary", "Allowing ATO renewal timelines to slip by initiating annual assessment engagements less than 90 days before the assessment window, creating authorization lapse risk that mandates service suspension for federal agency customers", "Populating SSP AI-specific sections with generic NIST 800-53 control language without documenting AI-system-specific implementation details such as model versioning procedures, inference pipeline architecture, and training data access segregation controls", "Managing POA&M items in spreadsheets disconnected from the continuous monitoring workflow, preventing automated tracking of remediation deadlines and creating manual escalation gaps for high-severity items", "Deploying updated AI model versions to federal agency environments without assessing whether the change constitutes a significant change under the FedRAMP significant change policy, bypassing required PMO notification and potentially invalidating the ATO" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-06", "layer": "RF", "plane": "control", "name": "SOC 2 AI-Specific Evidence Production", "plain": "The enterprise must map AI system controls to the AICPA Trust Services Criteria applicable to its SOC 2 report scope, identify AI-specific evidence requirements not addressed by legacy control mappings, and produce and maintain current evidence that AI systems satisfy the applicable Trust Services Criteria throughout the audit period.", "threat": { "tags": [ "evidence-gap", "audit-qualified-opinion", "trust-criteria-noncompliance", "ai-control-mapping-failure" ], "desc": "Legacy SOC 2 control mappings developed before AI system adoption do not address the inference pipeline, training data pipeline, or model governance controls that now constitute material components of the system of controls. Auditors increasingly issue qualified opinions or exceptions when AI components lack mapped controls. SOC 2 report qualifications damage customer trust and can trigger contractual notification obligations in enterprise agreements." }, "standard": [ { "id": "soc2", "section": "CC6.1\u2013CC6.8", "title": "Common Criteria \u2014 Logical and Physical Access Controls" }, { "id": "iso_37301", "section": "\u00a79.1.3", "title": "Development of indicators" }, { "id": "cobit_2019", "section": "APO14", "title": "Managed Data" }, { "id": "nist_csf", "section": "ID.AM", "title": "Asset Management" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-06 SOC 2 AI-Specific Evidence Production control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/RF-06 SOC 2 AI-Specific Evidence Production control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/RF-06 SOC 2 AI-Specific Evidence Production control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/RF-06 SOC 2 AI-Specific Evidence Production control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/RF-06 SOC 2 AI-Specific Evidence Production control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Extend the SOC 2 control environment mapping to cover AI-specific components: model training pipeline, model inference infrastructure, training data access and handling, model versioning and change management, and AI incident response. Map each AI component to the applicable Trust Services Criteria and produce evidence artifacts for each mapped control.", "steps": [ "Conduct an AI component inventory scoped to the SOC 2 report boundary, identifying all AI systems, training pipelines, inference endpoints, and model governance processes in scope.", "Map each AI component to applicable Trust Services Criteria: CC6 for logical access to AI models and training data, CC7 for AI system operations and anomaly detection, CC9 for AI vendor risk management, and Availability, Confidentiality, and Processing Integrity criteria as applicable.", "Identify control gaps where AI components lack mapped controls and initiate control design for each gap with target completion dates.", "Establish evidence collection procedures for each AI control, including automated evidence collection from model governance platforms, training pipeline logs, and inference monitoring systems.", "Coordinate with the SOC 2 auditor during audit planning to align on AI component scope and evidence expectations before the audit period begins." ], "compliance_officer": { "summary": "SOC 2 AI control coverage is increasingly a customer diligence requirement. Proactive mapping and evidence production prevents audit exceptions and supports enterprise sales.", "actions": [ "Review AI component inventory for SOC 2 scope completeness annually before audit period.", "Coordinate with external auditors on AI-specific evidence expectations during audit planning.", "Track control gap remediation timelines and escalate delays." ], "metrics": [ "AI component SOC 2 control coverage: target 100% of in-scope components.", "Control gap remediation completion before audit period start: target 100%." ], "failure_signals": [ "AI components in scope without mapped TSC controls.", "Audit exception raised for an AI component without prior identification in the gap assessment." ] }, "grc_auditor": { "summary": "The AI control mapping matrix is the primary pre-audit artifact for demonstrating that AI components are covered in the SOC 2 control environment. Review for coverage completeness and evidence quality.", "actions": [ "Review the AI component mapping matrix against the complete SOC 2 scope inventory.", "Sample AI control evidence and evaluate against the applicable Trust Services Criteria requirements.", "Coordinate with external auditors on AI-specific testing procedures during audit planning." ], "metrics": [ "TSC mapping coverage of AI components: target 100%.", "Evidence artifacts rated as sufficient by auditors: target 100%." ], "failure_signals": [ "Unmapped AI components discovered during audit fieldwork.", "Evidence artifacts rejected or qualified by external auditors." ] }, "it_operations": { "summary": "IT operations must implement and maintain the technical controls that produce SOC 2 evidence for AI components, including access logs, inference logs, model version records, and training pipeline audit trails.", "actions": [ "Implement access logging for all model training and inference infrastructure with SIEM integration.", "Maintain a model version registry with change log for SOC 2 change management evidence.", "Automate evidence collection from AI platform monitoring tools and store in the compliance evidence repository." ], "failure_signals": [ "Access logs for AI infrastructure not retained for the full audit period.", "Model change management records missing or incomplete for the SOC 2 period." ] }, "executive": { "summary": "A qualified SOC 2 opinion or exception on AI controls damages customer trust and can trigger enterprise contract notification obligations. Executive sponsorship signals commitment to the assurance program.", "actions": [ "Include SOC 2 AI control coverage status in quarterly governance reporting.", "Ensure audit remediation resources are funded and prioritized." ], "failure_signals": [ "Qualified SOC 2 opinion issued without prior escalation to executive level.", "SOC 2 remediation items not funded within agreed timelines." ] } }, "maturity": { "current": "developing", "target": "managed", "notes": "Most SOC 2 programs predate AI system adoption; AI components are often excluded from scope or mapped superficially without AI-specific evidence." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "multi-tenant", "high-risk-sector" ], "implementers": [ "GRC Team", "IT Operations", "Audit Liaison", "Compliance Team" ], "frameworks": [ { "framework": "soc2", "requirement_id": "CC6.1, CC7.1, CC9.2", "fit": "direct", "rationale": "The AICPA Trust Services Criteria are the authoritative source for SOC 2 control requirements. CC6 covers logical access controls applicable to AI model and training data access; CC7 covers system operations and anomaly detection applicable to AI inference monitoring; CC9 covers third-party AI vendor risk management.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "iso_37301", "requirement_id": "\u00a79.1.3", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1.3 requires the organization to develop indicators to evaluate its compliance performance. SOC 2 report production is a contractual compliance obligation for most enterprise SaaS providers, and AI control coverage indicators of the kind RF-06 produces surface material compliance performance deficiencies.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO14.01", "fit": "partial", "rationale": "COBIT 2019 APO14.01 requires defining and communicating the organization's data management strategy, roles and responsibilities. AI training data handling and access controls sit within this managed-data governance scope, and the practice gives SOC 2 auditors a governance framework reference for evaluating data management controls.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "ID.AM-01", "fit": "adjacent", "rationale": "NIST CSF 2.0 ID.AM-01 requires that assets be identified and documented. AI component inventory as a prerequisite to SOC 2 control mapping aligns with this asset management requirement and supports broader cybersecurity governance.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27001", "requirement_id": "A.5.23", "fit": "partial", "rationale": "ISO 27001 A.5.23 covers information security for use of cloud services, which encompasses AI inference and training infrastructure on cloud platforms. SOC 2 evidence for AI cloud components supports this control and enables cross-framework evidence reuse.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager provides a dedicated SOC 2 assessment template with control mappings to the AICPA Trust Services Criteria, including CC6 (logical access), CC7 (system operations), and CC9 (vendor risk management). For SOC 2 AI-Specific Evidence Production, the Purview SOC 2 template enables enterprises to extend existing control mappings to cover AI components by adding AI-specific improvement actions within each Trust Services Criteria domain, generating a compliance score that reflects AI coverage gaps and providing audit-ready evidence documentation for each mapped AI control.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "direct", "rationale": "AWS Artifact provides on-demand access to AWS SOC 1, SOC 2, and SOC 3 audit reports that constitute the primary infrastructure-layer evidence for inherited controls in SOC 2 AI-Specific Evidence Production for AI systems hosted on AWS. Enterprises scoping AI training pipelines and inference infrastructure on AWS within their SOC 2 report boundary must obtain and reference the AWS SOC 2 report to evidence inherited CC6, CC7, and CC9 controls, enabling the enterprise's auditor to rely on AWS's third-party assessment for the infrastructure layer while the enterprise demonstrates its application-layer AI controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "direct", "rationale": "Google Cloud's Compliance and Assurance resource center provides SOC 2 Type II audit reports for GCP infrastructure services that serve as foundational evidence for inherited controls in SOC 2 AI-Specific Evidence Production. For AI training and inference workloads hosted on GCP, enterprises must reference the Google Cloud SOC 2 report in their control mapping matrix to document that physical security, environmental controls, and platform-level logical access controls are covered by Google's third-party attestation, allowing the enterprise to focus its own SOC 2 AI evidence production on application-layer and AI-specific controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI's Enterprise Data Processing Addendum and enterprise compliance commitments document the data handling, sub-processing, and security practices applicable to API-based AI integrations. For SOC 2 AI-Specific Evidence Production, the OpenAI Enterprise DPA provides the vendor compliance documentation required to satisfy SOC 2 CC9.2 (third-party vendor risk management) for AI systems that incorporate OpenAI APIs, demonstrating that the enterprise has obtained and reviewed the vendor's data processing commitments as part of its third-party risk management program.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "direct", "rationale": "Okta Identity Governance provides access certification campaigns, segregation of duties enforcement, and immutable audit trails for identity decisions that directly generate evidence for SOC 2 Trust Services Criteria CC6.1 (logical access), CC6.2 (new access), and CC6.3 (access modification and removal). For SOC 2 AI-Specific Evidence Production, Okta's governance audit reports serve as the primary access control evidence for AI system access management, covering user provisioning, periodic certification, and de-provisioning events in a format that SOC 2 auditors can validate as meeting CC6 requirements.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/RF-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The AI component control mapping matrix must cover 100% of in-scope AI systems mapped to applicable Trust Services Criteria, with current evidence artifacts present for each mapped control demonstrating that the control operated effectively throughout the audit period. No in-scope AI component may lack a corresponding TSC mapping and evidence artifact at the time of auditor fieldwork.", "evidence_required": [ "ai_component_inventory listing all in-scope AI systems, training pipelines, and inference endpoints with their SOC 2 boundary status (in-scope/out-of-scope)", "tsc_control_mapping_matrix cross-referencing each AI component to applicable TSC criteria (CC6.1-CC6.8, CC7.1-CC7.5, CC9.2) with mapped control descriptions", "inference_access_log showing authenticated access events to AI model endpoints with user_id, resource, action, and timestamp for the full audit period", "model_change_management_record documenting each model version change with change_id, approver_id, approval_date, and change rationale", "third_party_ai_vendor_compliance_report (SOC 2 Type II or equivalent) for each external AI provider in scope for CC9.2 vendor risk management" ], "machine_tests": [ "Query ai_component_inventory for systems flagged as 'in-scope' without a TSC mapping entry \u2192 assert zero results (100% coverage)", "Query tsc_control_mapping_matrix for CC6 controls on AI systems \u2192 assert all entries have evidence_artifact_ids referencing stored artifacts with collected_at within the audit period", "Retrieve access log for AI inference endpoint over audit period \u2192 assert log contains no gaps exceeding 24 hours and all entries include user_id and action fields", "Check model_change_management_record for the audit period \u2192 assert every model deployment event has approver_id and approval_date populated" ], "human_review": [ "Review the TSC mapping matrix for AI components to assess whether the mapped controls substantively address the Trust Services Criteria rather than superficially referencing them", "Evaluate evidence artifact quality for each AI TSC mapping by sampling at least 3 AI components and confirming the evidence would satisfy auditor expectations for the applicable criteria", "Assess whether the AI vendor due diligence file for CC9.2 includes current (within 12 months) SOC 2 Type II reports or equivalent attestations for each external AI provider" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Scoping AI training and inference infrastructure out of the SOC 2 boundary without documented justification, creating a gap between actual risk and auditor-assessed risk", "Mapping all AI components to a single generic CC6.1 control without specifying which AI-specific access control mechanisms satisfy the criteria", "Collecting evidence artifacts only at audit fieldwork time rather than maintaining contemporaneous evidence throughout the audit period", "Using inherited cloud infrastructure controls (e.g., AWS SOC 2 report) as the sole AI evidence without demonstrating application-layer and model-layer controls", "Treating third-party AI API providers as out of scope for CC9.2 vendor risk without documenting the risk acceptance rationale" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-07", "layer": "RF", "plane": "lifecycle", "name": "ISO 42001 Certification Pathway", "plain": "The enterprise must assess its current AI management system against ISO/IEC 42001:2023 requirements, define a gap closure roadmap, and manage the certification pathway including scope definition, policy and objective establishment, internal audit, management review, and certification body engagement.", "threat": { "tags": [ "ai-management-immaturity", "certification-gap", "scope-undefined", "continual-improvement-failure" ], "desc": "Without an ISO 42001-aligned AI management system, the enterprise lacks the systematic framework to demonstrate AI governance maturity to customers, regulators, and partners. Certification gaps become visible during enterprise procurement diligence and can disqualify vendors from regulated sector contracts. An undefined scope leads to certification bodies issuing qualified certificates that exclude material AI operations, undermining the value of the certification." }, "standard": [ { "id": "iso_37301", "section": "\u00a74\u201310", "title": "ISO 37301 management system structure \u2014 Annex SL parallel" }, { "id": "iso_27001", "section": "\u00a74\u201310", "title": "ISO 27001 ISMS structure \u2014 Annex SL integration pathway" }, { "id": "cobit_2019", "section": "EDM01", "title": "Ensured Governance Framework Setting and Maintenance" }, { "id": "nist_csf", "section": "GV.RM", "title": "Risk Management Strategy" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-07 ISO 42001 Certification Pathway control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/RF-07 ISO 42001 Certification Pathway control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/RF-07 ISO 42001 Certification Pathway control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Conduct an ISO 42001 gap assessment, establish an AI management system policy and objectives, define the certification scope, implement the required AIMS controls, complete an internal audit cycle, and engage an accredited certification body. Treat certification as a lifecycle commitment with annual surveillance and three-year recertification cycles.", "steps": [ "Commission an ISO 42001 gap assessment against all clauses of the standard, documenting current state maturity and gap severity for each requirement.", "Define the AIMS scope statement covering the AI systems, organizational units, and processes in scope for certification, with explicit exclusions justified.", "Establish the AI management system policy signed by executive leadership, AI objectives aligned with organizational strategy, and risk and impact assessment procedures.", "Implement gap closure actions from the gap assessment, prioritizing Clause 6 (planning), Clause 8 (operation), and Clause 9 (performance evaluation) as the most substantive certification requirements.", "Complete at least one full internal audit cycle against the complete standard, address findings, and conduct a management review before certification body engagement.", "Engage an accredited ISO 42001 certification body for a Stage 1 documentation review and Stage 2 implementation audit." ], "compliance_officer": { "summary": "ISO 42001 certification is an emerging customer expectation in regulated sectors and a differentiator in enterprise AI procurement. The certification pathway requires sustained commitment across 12 to 18 months from gap assessment to initial certificate.", "actions": [ "Sponsor the ISO 42001 gap assessment and gap closure roadmap.", "Coordinate with legal counsel on scope definition to ensure material AI operations are included.", "Track gap closure milestones and escalate resourcing gaps." ], "metrics": [ "Gap assessment completion: target within 90 days of program launch.", "Gap closure roadmap milestone adherence: target 80% on-schedule." ], "failure_signals": [ "Scope definition excludes material AI operations without documented justification.", "Gap closure milestones delayed by more than one quarter without executive escalation." ] }, "legal_counsel": { "summary": "Certification scope and public certification claims carry legal weight. Representing ISO 42001 certification in customer contracts or marketing before the certificate is issued, or without disclosing material scope exclusions, creates misrepresentation exposure.", "actions": [ "Review the certification scope statement to confirm material AI operations are included and any exclusions are documented and defensible.", "Review all customer-facing and contractual claims about ISO 42001 status before publication, distinguishing 'pursuing certification' from 'certified'.", "Review the certification body engagement agreement for confidentiality, audit access, and certificate use terms." ], "failure_signals": [ "Certification claimed in sales or contractual materials before certificate issuance.", "Material scope exclusions not disclosed where customers reasonably rely on certification coverage.", "Certification body agreement executed without counsel review of certificate use and confidentiality terms." ] }, "grc_auditor": { "summary": "The internal AIMS audit cycle is a mandatory precondition for certification: stage 1 expects a completed internal audit and management review. Auditors validate gap closure evidence and confirm the AIMS operates before the certification body samples it.", "actions": [ "Execute the full internal AIMS audit cycle against ISO 42001 clauses 4\u201310 before certification body stage 1.", "Verify gap closure evidence for each roadmap item and confirm nonconformities are corrected with root-cause records.", "Validate that management review records cover the required inputs and produce documented decisions." ], "metrics": [ "Internal audit coverage of ISO 42001 clauses: target 100% before stage 1.", "Internal audit nonconformities closed before stage 2: target 100%.", "Gap closure evidence completeness across the roadmap: target 100%." ], "failure_signals": [ "Internal AIMS audit performed by personnel who designed the audited controls, breaking independence.", "Stage 1 findings recurring at stage 2 without documented corrective action.", "Management review held without the required inputs or without recorded decisions." ] }, "it_operations": { "summary": "Many AIMS controls rest on operational evidence \u2014 logging, access control, change management, and monitoring for in-scope AI systems. Certification audits sample operational records, so evidence must be retrievable without manual reconstruction.", "actions": [ "Maintain an operational inventory of in-scope AI systems mapped to the AIMS controls each system supports.", "Ensure logging and monitoring retention windows cover the certification audit sampling period.", "Assign named system owners to support certification evidence pulls within defined turnaround times." ], "failure_signals": [ "In-scope AI systems missing from the operational inventory or unmapped to AIMS controls.", "Evidence pulls requiring manual reconstruction because records were not retained or indexed.", "Operational changes to in-scope systems made outside the AIMS change management process." ] }, "executive": { "summary": "ISO 42001 certification is a strategic differentiator in enterprise AI procurement and requires sustained commitment across 12 to 18 months. Top management participation in the AIMS management review is a certification requirement, not a delegable formality.", "actions": [ "Charter the certification program with a defined budget, milestones, and an accountable sponsor.", "Participate directly in AIMS management reviews and approve the certification scope.", "Review certification pathway milestones quarterly and resolve escalated resourcing gaps." ], "failure_signals": [ "Management review delegated below top management or skipped in the certification cycle.", "Certification program unfunded beyond the initial gap assessment.", "Scope decisions made for expedience that exclude material AI operations without executive sign-off." ] } }, "maturity": { "current": "developing", "target": "managed", "notes": "ISO 42001 is a new standard (2023); most enterprises are at the gap assessment stage with few having achieved initial certification." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "regulated-ai" ], "implementers": [ "GRC Team", "Compliance Officer", "Executive Leadership", "Internal Audit" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a74\u201310", "fit": "direct", "rationale": "ISO 37301 provides the Annex SL management system structure that is directly parallel to ISO 42001. Enterprises with existing ISO 37301 compliance management systems have the foundational clause structure already in place and can integrate AIMS requirements as an extension.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27001", "requirement_id": "\u00a74\u201310", "fit": "direct", "rationale": "ISO 27001 shares the Annex SL management system structure with ISO 42001, enabling integrated certification audits. Enterprises can extend their ISMS to cover the AIMS scope, reducing duplication of governance clauses while maintaining separate control sets.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9, Art. 17", "fit": "partial", "rationale": "EU AI Act Article 9 (risk management system) and Article 17 (quality management system for high-risk AI) align substantially with ISO 42001 AIMS requirements. ISO 42001 certification is an emerging conformity pathway that provides evidence of Article 9 and 17 compliance.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "EDM01", "fit": "adjacent", "rationale": "COBIT 2019 EDM01 (Ensured Governance Framework Setting and Maintenance) encompasses the governance structure that ISO 42001 certification validates for AI management systems.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "ISO 42001 assessment", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager includes an ISO 42001 assessment template that maps Microsoft cloud control coverage to ISO 42001 clauses, enabling enterprises to leverage inherited controls and focus certification efforts on organizational process gaps.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/RF-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The enterprise must have completed a formal ISO 42001 gap assessment against all clauses, defined a scope statement covering material AI operations, and either achieved initial certification or is executing an active gap closure roadmap with milestone adherence above 80% and a scheduled certification body engagement date. No material AI operation may be excluded from the defined AIMS scope without documented justification.", "evidence_required": [ "iso_42001_gap_assessment_report documenting current maturity and gap severity ratings against all clauses of ISO/IEC 42001:2023 with completion date", "aims_scope_statement signed by executive leadership defining the AI systems, organizational units, and processes in scope with explicit exclusions and their justifications", "ai_management_system_policy document signed by executive leadership establishing the AI policy, objectives, and governance framework", "gap_closure_roadmap with milestone schedule, owner assignments, target completion dates, and current milestone adherence rate", "internal_audit_record covering the complete ISO 42001 clause set with findings, ratings, and remediation status" ], "machine_tests": [ "Check gap_closure_roadmap for milestones with target_date in the past and status not equal to 'complete' \u2192 assert milestones past due represent less than 20% of total milestone count", "Verify aims_scope_statement document has executive_signature and signed_date fields populated \u2192 assert both fields are non-null", "Query internal_audit_record for coverage of ISO 42001 clauses 4-10 \u2192 assert all seven clause groups have at least one audit finding entry (even if finding is 'no exception')" ], "human_review": [ "Assess whether the AIMS scope statement includes all material AI systems actually in production operation or documents substantive justification for each exclusion", "Review the gap assessment for clause 6 (Planning), clause 8 (Operation), and clause 9 (Performance Evaluation) to confirm gap severity ratings reflect actual program maturity rather than aspirational state", "Evaluate the gap closure roadmap for realistic resourcing: confirm each open gap item has an owner with the requisite authority and budget commitment" ], "blocking_effect": "blocks-deployment", "normative_status": "certification-standard", "anti_patterns": [ "Defining the AIMS scope to exclude material production AI systems (e.g., customer-facing AI agents) while including only experimental or low-risk AI workloads", "Conducting a gap assessment using internal resources without reference to the accredited certification body's interpretation of clause requirements, leading to scope disagreements during Stage 1 audit", "Treating ISO 42001 as a documentation project rather than a management system commitment, producing policies without corresponding operational procedures or evidence", "Failing to integrate the AIMS with the existing ISMS (ISO 27001) or compliance management system, creating parallel audit obligations with duplicated evidence requirements", "Engaging a certification body before completing an internal audit cycle, resulting in Stage 2 failures that could have been identified and remediated internally" ], "update_status": "current", "layer_code": "RF" }, { "id": "RF-08", "layer": "RF", "plane": "evidence", "name": "Regulatory Framework Evidence Package", "plain": "The Regulatory Framework evidence package compiles attestation-ready evidence from RF-01 through RF-07 into a structured package demonstrating that the enterprise has addressed EU AI Act classification, GDPR AI obligations, DORA ICT risk, SOC 2 AI coverage, and ISO 42001 pathway requirements.", "threat": { "tags": [ "attestation-gap", "evidence-fragmentation", "stale-artifacts", "package-integrity-failure" ], "desc": "Without a compiled, structured evidence package, regulatory layer coverage cannot be efficiently demonstrated to auditors, regulators, or enterprise customers. Individual control evidence artifacts that are not assembled and validated as a package may be stale, inconsistent, or missing for specific regulatory frameworks, producing an incomplete attestation that fails customer or regulatory review." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation" }, { "id": "eu_ai_act", "section": "Art. 11, Art. 18", "title": "Technical documentation and record-keeping obligations" }, { "id": "cobit_2019", "section": "MEA01", "title": "Managed Performance and Conformance Monitoring" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/RF-08 Regulatory Framework Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/RF-08 Regulatory Framework Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Compile and maintain an RF evidence package by aggregating the primary evidence artifact from each of RF-01 through RF-07, validating artifact freshness, and producing a signed attestation record with the ComplianceAttestation structure. Automate package compilation to enable on-demand generation with current artifacts.", "steps": [ "Define the RF evidence package schema specifying the required artifact type, validity period, and verdict field for each RF-01 through RF-07 control.", "Implement an evidence aggregation pipeline that retrieves the current primary artifact for each RF control from the compliance evidence repository.", "Validate artifact freshness by checking collected_at and valid_until fields against the current timestamp and flagging any stale or missing artifacts.", "Produce the ComplianceAttestation record with verdict, confidence, collected_at, valid_from, valid_until, and integrity.hash fields.", "Store the compiled package with an immutable audit trail entry recording the compiler identity, compilation timestamp, and artifact manifest." ], "compliance_officer": { "summary": "The RF evidence package is the primary deliverable for regulatory layer attestation. It must be compilable on demand and reflect current evidence state across all seven RF-layer controls.", "actions": [ "Review the RF evidence package on a quarterly basis to confirm artifact freshness and package completeness.", "Escalate stale or missing RF evidence artifacts to the responsible control owner for immediate remediation.", "Coordinate evidence package production with audit preparation cycles." ], "metrics": [ "RF evidence package compilability: target 100% on-demand without missing artifacts.", "Artifact freshness rate: target 100% of artifacts within their defined validity period." ], "failure_signals": [ "RF evidence package cannot be compiled due to missing artifacts for any RF control.", "Package integrity hash validation fails on retrieval." ] }, "legal_counsel": { "summary": "The RF evidence package is designed to be produced to regulators, auditors, and enterprise customers. Every external production is a legal act: privilege, accuracy of regulatory claims, and production procedure must be controlled.", "actions": [ "Review the package for privileged or work-product material before any external production.", "Validate that regulatory posture claims in the package match the actual state of classification, conformity, and monitoring evidence.", "Define and approve the external production procedure, including who may release the package and under what conditions." ], "failure_signals": [ "Package produced to an external party without counsel review.", "Package asserting certifications or authorizations the organization does not currently hold.", "No documented record of what was produced to whom and when." ] }, "grc_auditor": { "summary": "The RF evidence package is the audit entry point for the regulatory framework layer. Package completeness against RF-01 through RF-07 and artifact freshness are auditable claims that must be independently verified each cycle.", "actions": [ "Verify package completeness against the RF-01 through RF-07 artifact inventory on each assembly cycle.", "Test integrity hashes on package retrieval and confirm the signed attestation record verifies.", "Sample artifacts for freshness against their declared validity periods." ], "metrics": [ "Package completeness against the RF control inventory: target 100%.", "Integrity hash verification pass rate on retrieval: target 100%.", "Sampled artifacts within validity period: target 100%." ], "failure_signals": [ "Package assembled ad hoc rather than through the defined compilation process.", "Artifacts missing validity metadata, making freshness unverifiable.", "Hash or signature verification failures on retrieval." ] }, "it_operations": { "summary": "On-demand package compilation depends on a healthy automated pipeline and integrity-protected storage. Compilation failures discovered at request time defeat the control's purpose.", "actions": [ "Operate and monitor the automated package compilation pipeline with alerting on failed runs.", "Manage integrity-protected storage for compiled packages, including hash generation and verification tooling.", "Run periodic compilation drills to confirm on-demand generation works before a regulator asks." ], "failure_signals": [ "Compilation pipeline failures unresolved past the defined SLA.", "Package storage without integrity verification or with mutable retention.", "Compilation drill failures repeated across consecutive cycles." ] }, "executive": { "summary": "The RF evidence package is the organization's on-demand proof of regulatory readiness for AI systems. It backs board attestations, customer assurance requests, and regulator responses; inability to produce it on request is itself a finding.", "actions": [ "Receive a quarterly package status summary covering completeness, freshness, and compilation health.", "Approve the policy governing external sharing of the package and its artifacts.", "Escalate and resource remediation when package completeness falls below target." ], "failure_signals": [ "A regulator or enterprise customer request that cannot be answered from the package within the defined SLA.", "Package status absent from compliance reporting for consecutive quarters.", "External sharing occurring outside the approved policy." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Evidence package compilation is typically manual in most enterprises; automation of evidence aggregation and attestation generation is a key maturity advancement." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "regulated-ai" ], "implementers": [ "GRC Team", "Compliance Officer", "IT Operations", "Audit Liaison" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 37301 \u00a79.1 requires monitoring, measurement, analysis and evaluation of compliance performance. The RF evidence package is the primary artifact demonstrating that the enterprise has evaluated its performance against all regulatory framework obligations in the RF layer.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11, Art. 18", "fit": "direct", "rationale": "EU AI Act Articles 11 and 18 require technical documentation and record-keeping for high-risk AI systems. The RF evidence package satisfies the documentation compilation requirement by assembling the AI Act classification, conformity assessment, and risk management evidence into a structured record.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA01", "fit": "partial", "rationale": "COBIT 2019 MEA01 (Managed Performance and Conformance Monitoring) covers the monitoring and reporting of compliance performance. The RF evidence package supports MEA01 by providing the structured evidence record that management reviews to assess regulatory framework conformance.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" } ], "canonical_id": "apeiris://compliance/controls/RF-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The Regulatory Framework evidence package must be compilable on demand with artifacts covering all RF-layer controls (RF-01 through RF-07), each artifact must be current within its defined validity period, and the package must produce a structured attestation record with a verifiable sha256 integrity hash. No attestation issuance may proceed with a stale artifact or a missing control coverage record for any RF-layer control.", "evidence_required": [ "rf_evidence_package_manifest listing all artifact_ids, artifact_types, collected_at timestamps, and valid_until dates for each RF-01 through RF-07 control", "attestation_record with ComplianceAttestation structure including actor, intent, verdict, collected_at, valid_from, valid_until, and integrity.hash (sha256)", "artifact_freshness_report confirming each component artifact is within its defined validity window at package compilation time", "control_coverage_matrix mapping each RF-01 through RF-07 control to its primary evidence artifact with pass/fail/conditional verdict for each", "package_integrity_manifest with sha256 hash of the complete package contents and Ed25519 signature by the producer verifier" ], "machine_tests": [ "Compile RF evidence package \u2192 assert all RF-01 through RF-07 controls have at least one artifact with collected_at within the defined refresh period and verdict not null", "Verify package_integrity_manifest sha256 hash against actual package contents \u2192 assert hashes match (zero-byte delta)", "Query artifact_freshness_report for artifacts where valid_until is less than current timestamp \u2192 assert zero stale artifacts in the compiled package", "Attempt to generate ComplianceAttestation with a missing RF-04 artifact \u2192 assert system returns error with error_code=missing_required_artifact and blocks attestation issuance" ], "human_review": [ "Review the evidence package for completeness by sampling RF-01, RF-04, and RF-07 artifacts and confirming the underlying evidence substantively addresses the control rather than referencing placeholder documents", "Assess the validity period settings for each artifact type to confirm refresh intervals are calibrated to the rate of regulatory change and audit cycle frequency", "Verify the attestation record producer_verifier identity and confirm the signing key is managed under the enterprise PKI policy" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Compiling the evidence package immediately before auditor fieldwork rather than maintaining current artifacts throughout the compliance period, masking control failures that existed within the period", "Including artifact placeholders or draft documents in the package without marking them as incomplete, causing auditors to misinterpret evidence quality", "Omitting the integrity hash and signature from the package, making it impossible to prove the evidence was not modified after collection", "Using a single compiled PDF as the entire evidence package without machine-readable structure, preventing automated validation and cross-domain evidence reuse", "Failing to validate artifact freshness at package compilation time, resulting in an attestation that includes expired or superseded evidence" ], "update_status": "current", "layer_code": "RF" }, { "id": "CI-01", "layer": "CI", "plane": "control", "name": "Compliance Control Testing Program", "plain": "The enterprise must maintain a documented program for regularly testing the operational effectiveness of AI compliance controls, with defined test plans, frequencies, execution records, and results that feed into the remediation and reporting cycle.", "threat": { "tags": [ "control-effectiveness-gap", "paper-compliance", "test-lapse", "ai-drift-undetected" ], "desc": "Without systematic testing, compliance controls may exist on paper but fail in practice. AI systems can introduce novel failure modes \u2014 model drift, data pipeline changes, API deprecation \u2014 that quietly invalidate controls without triggering alerts. Untested controls create false assurance in audit reports and leave the enterprise exposed to regulatory findings when external auditors independently test controls." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1.2", "title": "Sources of feedback on compliance performance" }, { "id": "soc2", "section": "CC4.1, CC4.2", "title": "COSO Principles \u2014 Monitoring Activities" }, { "id": "nist_800_53", "section": "CA-2", "title": "Control Assessments" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-01 Compliance Control Testing Program control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CI-01 Compliance Control Testing Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish a risk-ranked control test plan covering all active AI compliance controls, assign test frequencies based on control risk rating, execute tests on schedule, record results, and route exception items to the remediation register.", "steps": [ "Inventory all active AI compliance controls and assign a risk rating (high/medium/low) that determines test frequency: high = quarterly, medium = semi-annual, low = annual.", "Document a test plan for each control specifying the test objective, test method, evidence to be reviewed, pass/fail criteria, and responsible tester.", "Execute tests per schedule, record results with evidence references, and generate exception items for any failed or qualified test.", "Route exception items to the remediation register with owner assignment and target completion date.", "Produce a quarterly testing summary report for the compliance governance committee." ], "compliance_officer": { "summary": "The control testing program is the primary mechanism for converting paper compliance into verified operational effectiveness. Test execution coverage and exception resolution velocity are the leading indicators of program health.", "actions": [ "Review quarterly testing summary and exception register for escalation items.", "Confirm test frequency assignments are reviewed annually and updated for risk rating changes.", "Ensure model update events trigger out-of-cycle tests for affected controls." ], "metrics": [ "Scheduled test execution coverage: target 95%.", "Exception items resolved within target completion date: target 90%." ], "failure_signals": [ "High-risk controls with lapsed testing (test_frequency exceeded without execution).", "Exception items overdue by more than 30 days without documented escalation." ] }, "legal_counsel": { "summary": "Control test results are discoverable records. A failed test that is documented but never remediated or risk-accepted is evidence of known non-compliance; test evidence handling must align with retention and privilege policy.", "actions": [ "Define the handling procedure for test results that indicate regulatory non-compliance, including when counsel must be engaged.", "Advise on privilege treatment for sensitive test findings before broad distribution.", "Review exception acceptance decisions that carry regulatory exposure and confirm documented risk acceptance by an authorized owner." ], "failure_signals": [ "Failed tests with regulatory implications left open without documented remediation or risk acceptance.", "Test evidence deleted inconsistently with the retention schedule.", "Exception acceptances made by owners without authority over the underlying obligation." ] }, "grc_auditor": { "summary": "Internal audit both relies on and independently re-performs control tests. The testing program's design quality \u2014 independence, versioned test scripts, risk-ranked frequency \u2014 determines how much audit reliance it can carry.", "actions": [ "Validate that test design and execution are independent of the control owners being tested, or that compensating oversight exists.", "Re-perform a sample of control tests each cycle and compare results to recorded outcomes.", "Verify that exception items route to the remediation register and age within SLA." ], "metrics": [ "Re-performance agreement rate with recorded test results: target 95% or higher.", "Exception items aging within SLA: target 90%.", "Test scripts under version control with change history: target 100%." ], "failure_signals": [ "Control owners testing their own controls without independent review.", "Test scripts modified without versioning, making historical results unreproducible.", "Exception items closed without evidence of remediation." ] }, "it_operations": { "summary": "Automated control tests need pipeline integration, stable test environments, and monitored execution. A silently failing test harness produces false assurance at scale.", "actions": [ "Implement and maintain automated test harnesses integrated with AI system pipelines.", "Schedule test execution per the risk-ranked frequency plan and alert on missed or failed runs.", "Maintain test environment parity with production for controls whose behavior is environment-dependent." ], "failure_signals": [ "Automated tests failing or skipped without alerting.", "Test coverage gaps appearing after AI system changes because harnesses were not updated.", "Test environments drifted from production, invalidating results." ] }, "executive": { "summary": "The testing program converts stated compliance into verified operational effectiveness. Chronic exception backlogs and coverage gaps are leading indicators of compliance failure and require executive-level escalation and funding decisions.", "actions": [ "Review the quarterly testing summary, including coverage, pass rates, and the exception register.", "Act on escalated exception items that exceed remediation SLAs.", "Fund test automation where manual testing constrains coverage of high-risk controls." ], "failure_signals": [ "Exception backlog growing across consecutive quarters without intervention.", "Test coverage below target for high-risk controls with no remediation plan.", "Escalated exceptions closed by acceptance without documented rationale." ] } }, "maturity": { "current": "developing", "target": "managed", "notes": "Most enterprises test controls annually at most; AI-specific controls often lack defined test procedures and are excluded from testing programs." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "regulated-ai" ], "implementers": [ "GRC Team", "Internal Audit", "Compliance Officer", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1.2 requires the organization to draw on defined sources of feedback on its compliance performance. Control test results are a primary feedback source: testing is the mechanism by which the enterprise learns whether its controls actually fulfill obligations rather than merely existing on paper, and routes that feedback into remediation and reporting.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.1, CC4.2", "fit": "direct", "rationale": "SOC 2 CC4 (COSO Monitoring Activities) requires that the organization selects, develops, and performs ongoing evaluations of controls. CI-01 directly implements CC4.1 (ongoing evaluation) and CC4.2 (communication of deficiencies).", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_800_53", "requirement_id": "CA-2", "fit": "direct", "rationale": "NIST SP 800-53 CA-2 requires control assessments at defined frequencies. CI-01 implements this requirement for AI-specific compliance controls with risk-tiered assessment frequencies.", "normative_force": "voluntary-standard", "source_version": "Rev5", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "partial", "rationale": "EU AI Act Article 9(2) requires the risk management system to be a continuous, iterative process requiring regular systematic review and updating, including of the risk management measures adopted under Article 9(2)(d). Control testing provides the recurring evidence that risk management measures remain effective after initial implementation.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 15", "fit": "direct", "rationale": "COSO ERM 2017 Principle 15 (Assesses Substantial Change) requires the organization to identify and assess changes that may substantially affect strategy and business objectives. CI-01's requirement to trigger out-of-cycle tests on AI system changes implements this principle for AI compliance controls.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement actions", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's improvement action framework enables enterprises to assign test responsibilities, record test results, and track remediation for each mapped compliance control, directly supporting CI-01's testing program structure.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's recurring capability assessments \u2014 scheduled evaluations against defined thresholds with documented results \u2014 model the same test-on-cadence discipline CI-01 requires for AI compliance controls.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "nist_800_53", "requirement_id": "CA-7", "fit": "adjacent", "rationale": "NIST SP 800-53 CA-7 (Continuous Monitoring) complements CA-2 (Control Assessments) by establishing the ongoing monitoring program. CI-01's risk-tiered testing program bridges between point-in-time assessments and the continuous monitoring covered by CI-02.", "normative_force": "voluntary-standard", "source_version": "Rev5", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" } ], "canonical_id": "apeiris://compliance/controls/CI-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every AI compliance control designated as active in the compliance program must have at least one documented test executed within its defined testing frequency cycle, with the test result recorded as pass/fail/exception and all exception items linked to an open remediation record. No compliance control may have lapsed testing (last_tested_at exceeding the defined test frequency) without an approved deferral record.", "evidence_required": [ "control_test_plan documenting each active compliance control with test_id, test_frequency, test_method, and responsible_tester", "test_execution_record for each completed test including control_id, test_id, execution_date, result (pass/fail/exception), tester_id, and methodology_notes", "exception_register linking each test exception to a remediation_record with owner_id, target_completion_date, and current_status", "testing_calendar showing scheduled test dates for all active controls across the forward 12-month period", "management_attestation signed by the compliance officer confirming the testing program scope and execution status as of the attestation date" ], "machine_tests": [ "Query control_test_plan for all active controls \u2192 assert each control has a test_execution_record with execution_date within the control's defined test_frequency window", "Query exception_register for open exceptions \u2192 assert each exception has an open remediation_record with target_completion_date in the future or a documented escalation record if overdue", "Query testing_calendar for controls with no scheduled test date in the next 90 days \u2192 assert zero controls lack a next_scheduled_test_date", "Retrieve test execution records for the past 12 months \u2192 assert test execution coverage is at least 95% of scheduled tests (excluding documented deferrals)" ], "human_review": [ "Review a sample of test execution records (minimum 5) to confirm test methodology is substantive \u2014 tests should validate operational effectiveness, not merely document that the control exists", "Assess the exception register to determine whether exception item remediation timelines are realistic and whether overdue items have been escalated appropriately", "Evaluate the testing calendar to confirm test frequency assignments reflect control risk ratings \u2014 higher-risk controls should have shorter test cycles" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Scheduling all compliance control tests annually regardless of risk rating, resulting in high-risk AI controls going 12 months between effectiveness validations", "Recording test results as 'pass' without documenting the test methodology or evidence reviewed, making it impossible to reproduce or validate the test conclusion", "Closing exception items by reclassifying them as 'accepted risk' without documented risk owner approval and supporting risk analysis", "Separating the control testing program from the AI model lifecycle \u2014 not triggering new control tests when models are updated, retrained, or new AI capabilities are deployed", "Treating control testing as a GRC team function in isolation without involving the IT operations and model engineering teams who operate the controls being tested" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-02", "layer": "CI", "plane": "monitoring", "name": "Continuous Compliance Monitoring", "plain": "The enterprise must operate automated compliance monitoring pipelines that continuously assess AI systems against defined obligations, alert on control failures or emerging gaps in near-real-time, and maintain an auditable alert history with assigned response records.", "threat": { "tags": [ "monitoring-gap", "silent-violation", "configuration-drift", "delayed-detection" ], "desc": "Point-in-time compliance assessments leave extended windows during which AI systems may silently violate obligations \u2014 particularly as model versions, data pipelines, and integrations change without triggering compliance reviews. Configuration drift in AI infrastructure, silent model behavior changes, and API deprecation can all create compliance violations that go undetected until the next scheduled assessment." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1.1", "title": "Monitoring, measurement, analysis and evaluation \u2014 General" }, { "id": "nist_csf", "section": "DE.CM", "title": "Continuous Monitoring" }, { "id": "eu_ai_act", "section": "Art. 72", "title": "Post-market monitoring" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-02 Continuous Compliance Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CI-02 Continuous Compliance Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CI-02 Continuous Compliance Monitoring control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy automated compliance monitors for each obligation designated as continuously monitored, configure alert routing to named owners, retain alert events with response records, and regularly test monitor health to confirm coverage is operational.", "steps": [ "Classify each AI compliance obligation as 'continuously monitored' or 'periodically tested' based on obligation change velocity and risk level.", "Implement automated monitors for each 'continuously monitored' obligation, configuring check frequency, alert thresholds, and routing to named owners.", "Instrument AI systems to emit compliance telemetry (configuration state, output filter status, access control state) that feeds monitoring pipelines.", "Configure alert routing with SLA-tiered response requirements: high-severity alerts require acknowledgment within 4 hours, medium within 24 hours.", "Test monitoring pipeline health monthly by injecting synthetic violation events and confirming alert generation within the defined detection window." ], "compliance_officer": { "summary": "Continuous monitoring converts the compliance program from reactive (audit-driven) to proactive (event-driven). Pipeline health and alert response velocity are the primary program health indicators.", "actions": [ "Review the obligation coverage matrix quarterly to assess whether 'periodic-only' designations remain appropriate.", "Track alert response SLA adherence and escalate chronic SLA misses.", "Confirm monitoring pipeline health test results monthly." ], "metrics": [ "Obligation continuous monitoring coverage: target 100% of high-risk obligations.", "Alert response SLA adherence: target 95% within defined SLA." ], "failure_signals": [ "Monitoring pipeline for a high-risk obligation has not executed successfully within 2x its check frequency.", "Alert events with no assigned responder after 24 hours." ] }, "legal_counsel": { "summary": "Monitoring alerts are records: an unactioned alert evidencing a known violation is a liability, and some monitored events trigger statutory notification clocks. Alert taxonomy and retention need legal review.", "actions": [ "Define which alert categories require notification analysis \u2014 EU AI Act Art. 73 serious incidents, GDPR Art. 33 breaches, DORA major ICT incidents \u2014 and route them to counsel on trigger.", "Review the alert retention policy against record-keeping obligations and litigation hold procedures.", "Advise on documentation standards for alert dispositions so response records are defensible." ], "failure_signals": [ "Alerts indicating potentially notifiable events not routed to counsel within the defined window.", "Alert history purged inconsistently with retention obligations or during an active hold.", "Alert dispositions recorded without sufficient detail to reconstruct the response decision." ] }, "grc_auditor": { "summary": "The monitoring coverage map and alert response records are primary audit evidence for operating effectiveness. Auditors test whether monitors cover the obligation register and whether alert responses are complete and timely.", "actions": [ "Audit monitor coverage against the obligation register and flag high-risk obligations without healthy monitors.", "Sample alert events and verify complete response records: assignment, action, disposition, and timestamps.", "Verify monitor health tests execute on schedule and failures are remediated." ], "metrics": [ "High-risk obligations with healthy continuous monitors: target 100%.", "Sampled alerts with complete response records: target 95%.", "Monitor health test execution adherence: target 100%." ], "failure_signals": [ "Monitors disabled or modified without a change record.", "Alert queues bulk-closed without individual review.", "Coverage map stale relative to the current obligation register." ] }, "it_operations": { "summary": "IT operations owns pipeline reliability, alert routing, and monitor deployment. Monitoring that silently stops running is worse than no monitoring \u2014 it manufactures false assurance.", "actions": [ "Deploy and maintain compliance monitoring pipelines with health checks and failure alerting.", "Manage alert routing configuration so every alert lands with a named, staffed responder queue.", "Execute monitor health tests on schedule and remediate pipeline failures within SLA." ], "failure_signals": [ "Pipeline outages detected only when an expected alert never arrived.", "Alerts routed to unstaffed or deprecated queues.", "Monitor deployments not tracked, leaving coverage unverifiable." ] }, "executive": { "summary": "Continuous monitoring gives leadership near-real-time compliance posture instead of annual audit snapshots. Chronic alert SLA misses and persistent coverage gaps are early warnings that deserve executive attention before regulators surface them.", "actions": [ "Review the monthly monitoring posture summary covering coverage, alert volumes, and SLA adherence.", "Fund monitoring coverage expansion for high-risk obligations still on periodic-only review.", "Escalate chronic alert response SLA misses to accountable owners." ], "failure_signals": [ "Repeated alert SLA misses without recorded escalation.", "High-risk obligation coverage gaps persisting across quarters.", "Monitoring posture absent from executive compliance reporting." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most AI compliance programs rely on periodic assessments; automated continuous monitoring of AI-specific obligations is an emerging capability." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "regulated-ai" ], "implementers": [ "IT Operations", "GRC Team", "Compliance Officer", "Security Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1.1", "fit": "direct", "rationale": "ISO 37301 \u00a79.1.1 requires that the organization determines what needs to be monitored and measured. CI-02 implements this through the obligation coverage matrix and automated monitoring pipeline.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "DE.CM-01", "fit": "direct", "rationale": "NIST CSF 2.0 DE.CM (Continuous Monitoring) requires that assets and technology infrastructure are monitored to find anomalies and indicators of compromise. CI-02 extends this to compliance obligation monitoring for AI systems.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 72", "fit": "direct", "rationale": "EU AI Act Article 72 requires providers of high-risk AI systems to implement post-market monitoring systems. CI-02's continuous monitoring pipeline is the primary technical implementation of the Article 72 post-market monitoring requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 32", "fit": "partial", "rationale": "GDPR Article 32 requires appropriate technical and organizational measures to ensure ongoing confidentiality, integrity, and availability. Continuous monitoring of AI system compliance with data protection obligations implements the 'ongoing' character of this requirement.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "fedramp_20x", "requirement_id": "KSI-MLA", "fit": "direct", "rationale": "FedRAMP 20x replaces control-by-control assessment with machine-validatable Key Security Indicators; the KSI-MLA (Monitoring, Logging, and Auditing) indicator family requires continuous, automated validation that monitoring, logging, and audit capabilities are operating. CI-02 extends this continuous-validation model to AI-specific compliance obligations for federal AI deployments.", "normative_force": "regulation", "source_version": "20x", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance score monitoring", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's real-time compliance score and alert capabilities provide the infrastructure-layer continuous monitoring for compliance obligations mapped to Microsoft cloud services, enabling enterprises to implement CI-02 requirements for their Microsoft-hosted AI workloads.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The enterprise must operate automated monitoring pipelines covering 100% of AI obligations designated as continuously monitored in the compliance program, with alert latency not exceeding the defined maximum detection window, and all alert events retained with a machine-readable audit trail. No obligation designated as continuously monitored may remain in an undetected violation state for longer than the defined maximum detection window.", "evidence_required": [ "monitoring_pipeline_inventory listing each automated compliance monitor with obligation_id, monitor_id, check_frequency, alert_channel, and last_successful_run timestamp", "alert_log showing all compliance alert events with obligation_id, detected_at, severity, alert_channel, and assigned_responder for the review period", "false_positive_rate_report quantifying alert noise by obligation and monitor, with tuning actions taken for monitors exceeding the defined false positive threshold", "obligation_coverage_matrix confirming which obligations are covered by automated monitoring vs. periodic testing, with justification for any obligation placed in periodic-only mode", "monitoring_health_report confirming pipeline availability and last successful execution timestamp for each monitor" ], "machine_tests": [ "Inject a synthetic obligation violation event into the AI system under test \u2192 assert alert is generated with detected_at within the defined maximum detection window", "Query monitoring_pipeline_inventory for monitors with last_successful_run exceeding twice the check_frequency \u2192 assert zero monitors in degraded state", "Disable a monitoring pipeline for an obligation designated 'continuously monitored' \u2192 assert health report generates a pipeline_failure alert within one check_frequency cycle", "Query obligation_coverage_matrix for obligations without a monitor_id or a test_schedule_id \u2192 assert zero obligations have neither coverage type" ], "human_review": [ "Review the obligation coverage matrix to assess whether obligations designated as periodic-only monitoring are justified by the obligation's actual change velocity and risk level", "Evaluate a sample of alert events to confirm response records demonstrate appropriate urgency \u2014 alerts with severity 'high' should have responder assignment within the defined SLA", "Assess monitoring pipeline health report for patterns of recurring monitor failures that may indicate systemic reliability issues masking real compliance violations" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Treating continuous monitoring as synonymous with quarterly compliance assessments \u2014 point-in-time assessments cannot detect transient AI model behavior violations or configuration drift between assessment cycles", "Configuring monitoring alerts to route to a shared mailbox with no assigned owner, resulting in alert fatigue and unacknowledged compliance violations", "Monitoring only infrastructure-layer compliance signals (e.g., cloud configuration) without coverage of AI model-layer obligations (e.g., output filtering status, bias threshold adherence)", "Failing to test monitoring pipelines themselves \u2014 monitors that silently fail provide false assurance of compliance coverage while real violations go undetected", "Setting alert thresholds so conservatively that normal AI system behavior generates constant false positives, causing operations teams to disable or ignore the monitoring" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-03", "layer": "CI", "plane": "reporting", "name": "AI-Specific Compliance KPIs", "plain": "The enterprise must define, collect, and report a set of AI-specific compliance program KPIs covering obligation coverage, evidence freshness, audit finding rate, remediation velocity, and training completion rate on a defined cadence to governance stakeholders.", "threat": { "tags": [ "kpi-absence", "qualitative-blindness", "trend-invisibility", "governance-gap" ], "desc": "Without quantitative KPIs, compliance programs operate on qualitative judgments that mask systematic weaknesses. AI systems introduce rapidly changing obligation landscapes \u2014 new model versions, new data pipelines, new regulatory guidance \u2014 that create compliance gaps that are only detectable through trend analysis. Without defined KPIs, compliance degradation is invisible until external audit findings reveal it." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1.3", "title": "Development of indicators" }, { "id": "cobit_2019", "section": "MEA01.04", "title": "Report performance" }, { "id": "eu_ai_act", "section": "Art. 17(1)(i)", "title": "Quality management system \u2014 serious-incident reporting procedures" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-03 AI-Specific Compliance KPIs control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a KPI set covering all five baseline compliance performance dimensions, establish objective measurement methodologies for each KPI, collect measurements at the defined reporting cadence, and present results with trend analysis to the compliance governance committee.", "steps": [ "Define the five baseline AI compliance KPIs with objective measurement methodologies: (1) obligation coverage rate = active obligations with current controls / total active obligations, (2) evidence freshness rate = controls with artifacts within validity period / total controls, (3) audit finding rate = audit exceptions per 100 controls tested, (4) remediation velocity = average days to close exception items, (5) training completion rate = staff completing AI compliance training / required staff.", "Identify the data sources and collection method for each KPI measurement, preferring automated data extraction over manual tallying.", "Establish KPI target thresholds calibrated to regulatory obligations and risk tolerance \u2014 not set to be trivially achievable.", "Produce KPI measurement reports at the defined cadence (minimum quarterly) with current values, prior period comparison, and trend direction.", "Present KPI results to the compliance governance committee with root cause analysis for any KPI below threshold." ], "compliance_officer": { "summary": "KPIs convert the compliance program from an activity tracker to a performance management system. Trend direction across consecutive periods is as important as the absolute KPI value.", "actions": [ "Review KPI measurement methodology annually to confirm measurements remain objective and reproducible.", "Present KPI results with trend analysis to the compliance governance committee at each meeting.", "Initiate root cause analysis for any KPI below threshold within 5 business days of measurement." ], "metrics": [ "KPI reporting cadence adherence: target 100% of defined reporting periods with measurement records.", "KPIs within threshold: target 4 of 5 baseline KPIs within threshold at each reporting period." ], "failure_signals": [ "KPI measurement not produced for a defined reporting period.", "KPI results not presented to governance committee within the defined reporting window." ] }, "legal_counsel": { "summary": "KPI reports circulated to governance bodies are discoverable. An adverse trend that leadership saw and did not act on is worse in litigation than one never measured \u2014 measurement must therefore be paired with documented response.", "actions": [ "Review KPI report distribution lists and retention treatment with discoverability in mind.", "Advise that below-threshold KPI results carry documented management responses or risk acceptances.", "Review any external use of KPI results to ensure claims do not overstate compliance posture." ], "failure_signals": [ "Adverse KPI trends presented to governance without a recorded management response.", "KPI results quoted externally in ways that overstate the underlying measurement.", "KPI reports retained inconsistently with the records schedule." ] }, "grc_auditor": { "summary": "KPIs are management's own performance assertions, so audit tests measurement integrity: methodology objectivity, reproducibility from source data, and completeness of trend reporting.", "actions": [ "Validate that each KPI has a documented, objective, reproducible measurement methodology.", "Re-compute a sample of KPI values from source data each cycle and compare to reported values.", "Verify trend reporting is complete \u2014 no periods silently omitted after adverse results." ], "metrics": [ "Sampled KPI re-computation agreement with reported values: target 100%.", "KPIs with current documented methodology (reviewed within 12 months): target 100%.", "Reporting periods with complete KPI records: target 100%." ], "failure_signals": [ "KPI definitions changed without documentation or restatement of trend history.", "Source data unavailable for re-computation of reported values.", "Adverse periods missing from trend presentations." ] }, "it_operations": { "summary": "Reliable KPIs need automated data pipelines and available dashboards. Manual spreadsheet compilation introduces error and delay that undermine the measurement integrity the control depends on.", "actions": [ "Automate KPI data collection from the obligation register, evidence stores, and remediation tracker.", "Maintain KPI dashboards with defined refresh cadences and alerting on pipeline failures.", "Preserve source data snapshots supporting each reported period for re-computation." ], "failure_signals": [ "KPI values compiled manually from spreadsheets outside the pipeline.", "Dashboards serving stale data past the defined refresh window.", "Source snapshots missing for prior reporting periods." ] }, "executive": { "summary": "Compliance KPIs are the leadership steering instrument for the program: trend direction tells you where to invest before failures surface. The control only works if governance actually reviews the results and directs resources accordingly.", "actions": [ "Review KPI results and trend analysis at each governance committee meeting.", "Direct resources at KPIs persistently below threshold and track the response to closure.", "Approve changes to the KPI set so measurement continuity is a deliberate decision." ], "failure_signals": [ "KPI review skipped in consecutive governance meetings.", "Sustained adverse trends with no recorded resourcing or remediation decision.", "KPI set changed mid-year without governance approval." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most AI compliance programs lack defined KPIs specific to AI obligations; general GRC metrics (number of policies, number of training completions) do not measure AI compliance effectiveness." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "regulated-ai" ], "implementers": [ "Compliance Officer", "GRC Team", "Executive Leadership" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1.3", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1.3 requires the organization to develop indicators to evaluate its compliance performance. CI-03's KPI program is the direct implementation of this requirement, converting the indicator mandate into measurable, reportable performance data.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA01.04", "fit": "direct", "rationale": "COBIT 2019 MEA01.04 (Report Performance) requires that performance reporting be produced and communicated to stakeholders. CI-03's KPI measurement and governance committee reporting implement this requirement.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17(1)(i)", "fit": "partial", "rationale": "EU AI Act Article 17(1)(i) requires the quality management system to include procedures related to the reporting of serious incidents in accordance with Article 73. CI-03's KPI program includes incident-reporting timeliness among the compliance performance signals measured and reported to governance stakeholders, evidencing that this quality management element is operating.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "adjacent", "rationale": "GDPR Article 5(2) accountability principle requires that controllers demonstrate compliance with data protection principles. CI-03's evidence freshness and obligation coverage KPIs support accountability demonstration for AI systems processing personal data.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 19", "fit": "direct", "rationale": "COSO ERM 2017 Principle 19 (Communicates Risk Information) requires the organization to use communication channels to convey risk information across the entity. CI-03's compliance KPIs are the quantitative risk communication vehicle, conveying compliance performance signals to governance stakeholders on a defined cadence.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance score", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's compliance score provides an automated, continuously updated KPI for obligation coverage and improvement action completion across Microsoft-hosted AI workloads, serving as one input to the CI-03 KPI dashboard for enterprises in the Microsoft ecosystem.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The compliance program must produce a defined set of AI-specific KPIs covering all five baseline dimensions (obligation coverage, evidence freshness, audit finding rate, remediation velocity, training completion) on a defined reporting cadence, with each KPI having a documented target threshold, a current measured value, and a trend direction indicator. No KPI may report a null measured_value at the defined reporting cadence without a documented exception.", "evidence_required": [ "kpi_definition_register listing each KPI with kpi_id, name, definition, measurement_method, data_source, target_threshold, and reporting_frequency", "kpi_measurement_report for the current period containing measured_value, prior_period_value, trend_direction, and within_threshold flag for each defined KPI", "kpi_trend_history covering at least four consecutive reporting periods per KPI to enable trend analysis", "management_reporting_record confirming KPI results were presented to the compliance governance committee with attendance record and date", "remediation_action_record for each KPI where measured_value is outside the target_threshold, with root_cause, corrective_action, and target_return_to_threshold_date" ], "machine_tests": [ "Query kpi_definition_register \u2192 assert all five baseline KPI categories (obligation_coverage, evidence_freshness, audit_finding_rate, remediation_velocity, training_completion) have at least one defined KPI with a target_threshold value", "Query kpi_measurement_report for current reporting period \u2192 assert all defined KPIs have a measured_value and within_threshold flag set (not null)", "Query kpi_trend_history \u2192 assert each KPI has measurement records covering the last four consecutive reporting periods without gaps", "For each KPI where within_threshold is false \u2192 assert a remediation_action_record exists with corrective_action and target_return_to_threshold_date populated" ], "human_review": [ "Review KPI definitions to assess whether the measurement methodology is objective and reproducible \u2014 KPIs with subjective measurement criteria should be redesigned with quantitative data sources", "Evaluate KPI target thresholds to confirm they are calibrated to the enterprise's regulatory obligations and risk tolerance, not set to be trivially achievable or aspirationally unattainable", "Assess the management reporting record to confirm KPI results are presented to governance stakeholders with sufficient trend context to enable informed compliance oversight decisions" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Defining KPIs as percentage values without specifying the numerator and denominator data sources, making it impossible to reproduce the measurement or audit its accuracy", "Setting all KPI targets at 100% without acknowledging that some variance is inherent, creating pressure to manipulate measurements rather than drive genuine improvement", "Reporting KPIs only as point-in-time snapshots without trend data, masking systematic deterioration that only becomes visible across multiple consecutive periods", "Selecting KPIs that measure compliance program activity (e.g., number of policies reviewed) rather than compliance program effectiveness (e.g., percentage of obligations with current verified evidence)", "Siloing AI compliance KPIs from enterprise risk reporting dashboards, preventing board and executive visibility into AI-specific compliance performance trends" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-04", "layer": "CI", "plane": "operations", "name": "Compliance Tooling Implementation", "plain": "The enterprise must deploy and manage a suite of compliance tooling covering evidence collection, obligation tracking, audit management, and remediation tracking \u2014 integrated with AI system pipelines to automate evidence ingestion and produce immutable audit trails.", "threat": { "tags": [ "manual-process-failure", "chain-of-custody-gap", "fragmented-audit-trail", "tooling-isolation" ], "desc": "Without purpose-fit compliance tooling, evidence management defaults to spreadsheets and email threads, creating fragmented audit trails with no chain of custody. Manual processes introduce error rates that scale with AI system complexity, and the absence of immutable audit trails makes it impossible to prove that evidence was not modified after collection \u2014 a critical deficiency in regulatory investigations." }, "standard": [ { "id": "iso_37301", "section": "\u00a77.5", "title": "Documented information" }, { "id": "soc2", "section": "CC4.2", "title": "COSO Monitoring \u2014 Communication of Deficiencies" }, { "id": "cobit_2019", "section": "APO11", "title": "Managed Quality" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-04 Compliance Tooling Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CI-04 Compliance Tooling Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CI-04 Compliance Tooling Implementation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy a compliance tooling stack covering all four functional domains, integrate each tool with AI system monitoring infrastructure via API or pipeline, configure immutable audit trails, and validate integrations through regular testing.", "steps": [ "Assess the four functional domain requirements: evidence collection (automated artifact ingestion from AI systems), obligation tracking (obligation registry with status and owner), audit management (test scheduling, execution, and results), remediation tracking (exception items with owner, date, and status).", "Select or configure tools for each functional domain, prioritizing platforms with AI-specific templates and API integration capabilities over general-purpose tools requiring manual data entry.", "Implement API integrations between the compliance tooling stack and AI system monitoring infrastructure, model governance platforms, and CI/CD pipelines.", "Configure immutable audit trail settings in each tool (append-only logs, tamper-evident storage) and validate that direct modification of stored evidence is rejected.", "Conduct monthly integration health tests by triggering evidence collection events and confirming artifact storage with complete metadata fields." ], "compliance_officer": { "summary": "Compliance tooling converts the compliance program from document-centric to evidence-centric, enabling automated audit artifact production and defensible chain of custody. Tooling gaps are multipliers on manual process error rates.", "actions": [ "Review the tooling capability gap assessment semi-annually and prioritize gap closure in budget planning.", "Confirm integration health test results monthly and escalate failures to IT operations.", "Require that new AI system deployments include compliance tooling integration as a deployment prerequisite." ], "metrics": [ "Functional domain tooling coverage: target 100% (all four domains with deployed tools).", "Integration health test pass rate: target 100% monthly." ], "failure_signals": [ "Any functional domain operating without a deployed tool (manual process only).", "Integration health test failure not resolved within 5 business days." ] }, "legal_counsel": { "summary": "Compliance tooling processes regulated data and produces audit trails that may become evidence. Tool vendor contracts need data protection terms, and audit trail retention must respect both the records schedule and litigation holds.", "actions": [ "Review tooling vendor contracts for data processing terms, access rights, and audit trail ownership.", "Confirm audit trail retention configuration matches the records schedule and supports litigation holds.", "Advise on cross-border considerations where tooling stores compliance data outside the deployment jurisdiction." ], "failure_signals": [ "Compliance data processed by a tooling vendor without an executed DPA.", "Audit trails purged during an active legal hold.", "Tooling data residency inconsistent with regulatory commitments." ] }, "grc_auditor": { "summary": "Auditors rely on tooling-generated evidence, so audit trail immutability and integration coverage determine reliance. Evidence produced outside the tooling chain of custody requires separate, costlier validation.", "actions": [ "Verify immutable audit trail configuration on each tool in the stack.", "Test integration coverage against the AI system inventory and flag systems outside the tooling pipeline.", "Sample automated evidence artifacts for accuracy against source systems." ], "metrics": [ "AI systems integrated with the compliance tooling stack: target 100%.", "Audit trail integrity checks passed: target 100%.", "Sampled automated evidence artifacts verified accurate: target 100%." ], "failure_signals": [ "Evidence handled manually outside the tooling chain of custody.", "New AI systems deployed without compliance tooling integration.", "Audit trail configuration weakened without change approval." ] }, "it_operations": { "summary": "IT operations owns deployment, integration, and health of the compliance tooling stack. Integration decay is the dominant failure mode: pipelines that worked at deployment quietly break as AI systems evolve.", "actions": [ "Deploy and integrate compliance tools with AI system pipelines via supported APIs.", "Run monthly integration health tests and remediate failures within SLA.", "Manage tooling upgrades and patches so versions stay within vendor support windows." ], "failure_signals": [ "Integration health failures accumulating without remediation.", "Tooling running unsupported versions.", "Evidence ingestion gaps appearing after AI pipeline changes." ] }, "executive": { "summary": "Tooling investment converts the compliance program from document-centric to evidence-centric, and its return shows up as automated audit artifact production and lower manual error rates. Functional domains left on manual processes are risk multipliers.", "actions": [ "Approve the compliance tooling roadmap and budget against the capability gap assessment.", "Review the semi-annual gap assessment and prioritize closure of uncovered functional domains.", "Require tooling integration as a deployment prerequisite for new AI systems." ], "failure_signals": [ "Functional domains left on manual processes across consecutive budget cycles.", "Tooling spend growing without gains in integration coverage.", "New AI systems approved for deployment without tooling integration." ] } }, "maturity": { "current": "initial", "target": "optimizing", "notes": "Most enterprises have fragmented compliance tooling with limited AI system integration; fully integrated compliance tooling stacks with AI-specific pipelines are an emerging capability." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector" ], "implementers": [ "IT Operations", "GRC Team", "Compliance Officer", "DevOps" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a77.5", "fit": "direct", "rationale": "ISO 37301 \u00a77.5 requires that the organization maintains documented information as evidence of its compliance management system. CI-04's compliance tooling is the operational infrastructure that creates, controls, and retains this documented information with the required integrity and availability.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "direct", "rationale": "SOC 2 CC4.2 requires that the organization communicates control deficiencies to those responsible for corrective action. CI-04's remediation tracking tooling is the primary mechanism for deficiency communication, owner assignment, and corrective action tracking.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 11, Art. 18", "fit": "direct", "rationale": "EU AI Act Articles 11 and 18 require technical documentation and record-keeping for high-risk AI systems. CI-04's evidence collection tooling is the operational infrastructure that creates and maintains the documentation required by these articles.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "APO11.05", "fit": "partial", "rationale": "COBIT 2019 APO11.05 (Maintain continuous improvement) requires that quality-related data be collected and analysed to drive improvement. CI-04's compliance tooling provides the data collection infrastructure that makes continuous improvement data-driven rather than judgment-based.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Manager platform", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager is a primary compliance tooling platform for Microsoft-ecosystem enterprises, providing obligation tracking, improvement action management, evidence documentation, and compliance score reporting that covers three of the four CI-04 functional domains (obligation tracking, audit management, and evidence collection for Microsoft cloud services).", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to compliance reports and agreements for AWS services, supporting the evidence collection functional domain of CI-04 for AI workloads hosted on AWS. Integration of AWS Artifact report retrieval into the compliance tooling stack enables automated ingestion of infrastructure-layer compliance evidence without manual download processes.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance Reports Manager", "fit": "partial", "rationale": "Google Cloud's Compliance Reports Manager provides downloadable compliance reports for GCP services that serve as infrastructure-layer evidence artifacts for AI workloads on GCP. Integrating GCP compliance report retrieval into the CI-04 tooling stack enables automated evidence collection for the GCP infrastructure layer of AI compliance.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The enterprise must operate a deployed compliance tooling stack covering all four functional domains (evidence collection, obligation tracking, audit management, remediation tracking), with each tool integrated via API or pipeline to the AI system monitoring infrastructure and producing machine-readable outputs with immutable audit trails. No compliance function may operate exclusively via manual processes for obligations that generate ongoing evidence.", "evidence_required": [ "compliance_tooling_inventory listing each deployed tool with tool_id, vendor, functional_domain, integration_points, and operational_since date", "integration_test_record confirming each compliance tool's API or pipeline integration to the AI system monitoring infrastructure, with last_tested_at timestamp and pass/fail result", "evidence_collection_pipeline_diagram showing the data flow from AI system sources through the compliance tooling stack to the evidence repository with integration method for each hop", "tooling_capability_gap_assessment documenting any compliance functions not yet covered by deployed tooling with risk rating and planned remediation timeline", "audit_trail_record from the compliance tooling confirming immutable logging of evidence collection events with user_id, action, timestamp, and artifact_id" ], "machine_tests": [ "Trigger an automated evidence collection event via the compliance tooling API \u2192 assert evidence artifact is stored in the repository with artifact_id, collected_at, and source_system fields populated within the defined SLA", "Query compliance_tooling_inventory for functional_domains \u2192 assert at least one tool is deployed covering each of: evidence_collection, obligation_tracking, audit_management, remediation_tracking", "Attempt to modify a stored evidence artifact directly in the repository bypassing the compliance tooling audit trail \u2192 assert operation is rejected with error_code=unauthorized_direct_modification", "Query integration_test_record for integrations with last_tested_at exceeding 30 days \u2192 assert zero integrations lack a recent test record" ], "human_review": [ "Review the tooling capability gap assessment to confirm that manual processes remaining in place for any compliance function have compensating controls and a realistic remediation timeline", "Evaluate the audit trail record for chain of custody integrity \u2014 artifacts should have an unbroken event log from collection through storage with no anonymous or system-account-only events", "Assess whether the compliance tooling stack covers the full AI system lifecycle (not just production compliance) \u2014 training data approvals, model evaluation gates, and change management events should produce tooling-integrated evidence" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Deploying compliance tooling for evidence storage while leaving evidence collection manual, creating a fragmented audit trail where artifact provenance cannot be established", "Using a single general-purpose GRC tool that lacks AI-specific obligation templates or integration hooks for AI system monitoring data, resulting in manual data entry for all AI compliance evidence", "Failing to configure immutable audit trails in the compliance tooling, allowing evidence artifacts to be modified after collection without a detectable change record", "Treating compliance tooling implementation as a one-time deployment project rather than an ongoing integration program \u2014 AI system architecture changes that break tool integrations go undetected", "Purchasing compliance tooling without budgeting for the API integration work required to connect it to AI system monitoring infrastructure, leaving the tool operating in isolation from actual AI system data" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-05", "layer": "CI", "plane": "lifecycle", "name": "Compliance Training and Awareness Program", "plain": "The enterprise must operate a structured compliance training and awareness program that educates AI development teams, business stakeholders, and senior leadership on applicable regulations, their specific obligations, and the consequences of noncompliance\u2014with completion tracked and attestation recorded.", "threat": { "tags": [ "awareness-gap", "noncompliance-by-ignorance", "obligation-misinterpretation", "training-deficit" ], "desc": "AI systems are built and deployed by teams whose primary domain is engineering or business, not compliance. Without targeted training, developers make design decisions that inadvertently violate GDPR data minimization principles, EU AI Act conformity requirements, or sector-specific AI use restrictions. The consequential gap is not bad intent but uninformed action\u2014a threat that formal awareness programs directly neutralize." }, "standard": [ { "id": "iso_37301", "section": "\u00a77.3", "title": "Awareness \u2014 compliance obligations" }, { "id": "eu_ai_act", "section": "Art. 9(5)", "title": "Risk management system \u2014 human oversight training" }, { "id": "gdpr", "section": "Art. 39(1)(b)", "title": "DPO tasks \u2014 awareness-raising and training of staff" }, { "id": "coso_erm", "section": "Principle 5", "title": "Attracts, Develops, and Retains Capable Individuals" } ], "sources": [ { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CI-05 Compliance Training and Awareness Program control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CI-05 Compliance Training and Awareness Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Role-based training curriculum mapped to obligation types; mandatory annual completion with attestation; AI-specific modules for developers, product managers, and executives; supplemented by just-in-time compliance alerts on regulatory updates.", "steps": [ "Define the role-based training matrix: AI developers (data handling, model documentation, prohibited use cases), product managers (conformity assessment, user rights), executives (liability exposure, board-level governance obligations).", "Develop or procure AI-specific compliance training modules covering applicable regulations (EU AI Act, GDPR, sector-specific rules) with scenario-based content reflecting the organization's AI use cases.", "Deploy training through a tracked learning management system (LMS) with completion certificates and attestation records retained for audit.", "Send just-in-time compliance awareness notices when significant regulatory guidance changes (e.g., new EU AI Act delegated acts, GDPR enforcement decisions relevant to AI).", "Measure training effectiveness through annual knowledge assessments and update content based on audit finding trends." ], "compliance_officer": { "summary": "The training program converts regulatory obligation awareness into individual-level accountability. Own the curriculum, track completion, and use audit finding trends to update content priorities.", "actions": [ "Approve the role-based training matrix and annual curriculum updates.", "Monitor completion rates by role and department, escalating non-compliance to HR and department heads.", "Review knowledge assessment results annually and direct curriculum updates toward areas of persistent misunderstanding." ], "metrics": [ "Annual training completion rate: target \u226595% of in-scope staff by fiscal year end.", "Knowledge assessment pass rate: target \u226585% of participants pass on first attempt.", "Time to first training completion for new hires: target within 30 days of onboarding." ], "failure_signals": [ "Department completion rates below 80% at 60 days before fiscal year end.", "Knowledge assessment pass rates below 70% for a specific role category." ] }, "legal_counsel": { "summary": "Training content must accurately represent legal obligations, including jurisdictional nuances and enforcement trends. Review curriculum for legal accuracy and ensure updates are triggered by material regulatory developments.", "actions": [ "Review all training modules for legal accuracy before initial deployment and after material regulatory changes.", "Provide the compliance training team with advance notice of regulatory developments requiring curriculum updates.", "Document legal review of training content as evidence of due diligence in regulatory proceedings." ], "failure_signals": [ "Training content not reviewed by legal counsel following a material regulatory change.", "Curriculum that omits jurisdiction-specific requirements applicable to the organization's AI deployments." ] }, "grc_auditor": { "summary": "Training completion records and attestations are audit evidence of the organization's accountability posture. Verify completeness, recency, and the accuracy of completion tracking during audit engagements.", "actions": [ "Request LMS completion records for the audit period and verify against the employee roster.", "Confirm that training content was reviewed for accuracy within the prior 12 months.", "Sample attestation records for a subset of staff to verify documentation integrity." ], "metrics": [ "Completion record retention: attestations available for 100% of in-scope staff for the audit period.", "Training content review frequency: legal review within prior 12 months." ], "failure_signals": [ "Completion records missing for more than 10% of in-scope staff.", "Training content not updated within 18 months despite material regulatory changes." ] }, "executive": { "summary": "Compliance training is a liability management investment. Executives with demonstrable training completion reduce personal exposure in regulatory inquiries. Require a quarterly training completion report and include completion rates in executive scorecards.", "actions": [ "Complete executive-tier AI compliance training annually and retain attestation records.", "Receive quarterly training completion rate reports by department.", "Include training completion as a performance objective for department heads." ], "failure_signals": [ "Executive team completion rate below 100% by fiscal year end.", "No training completion dashboard delivered to executive leadership in any quarter." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations provide generic data privacy training. AI-specific compliance training covering EU AI Act obligations, model documentation requirements, and human oversight obligations is rare." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "HR / Learning & Development" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a77.3", "fit": "direct", "rationale": "ISO 37301 \u00a77.3 explicitly requires that persons doing work under the organization's control are aware of the compliance policy, their contribution to the compliance management system, and the implications of not conforming. CI-05 directly implements this awareness requirement through a structured, role-differentiated training program.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(5)", "fit": "direct", "rationale": "EU AI Act Article 9(5) requires that the risk management system include appropriate measures to ensure that persons interacting with high-risk AI systems have sufficient knowledge and capability to perform their oversight functions. Training programs are the primary mechanism for building this required competence across AI development and deployment teams.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 39(1)(b)", "fit": "direct", "rationale": "GDPR Article 39(1)(b) assigns Data Protection Officers the task of monitoring compliance with the Regulation and with internal data protection policies, including awareness-raising and training of staff involved in processing operations. The CI-05 training program operationalizes this awareness-raising and training obligation across all AI development and deployment teams handling personal data.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 5", "fit": "partial", "rationale": "COSO ERM 2017 Principle 5 (Attracts, Develops, and Retains Capable Individuals) requires the organization to build the human capital needed to carry out its risk management responsibilities. Compliance training ensures that personnel managing AI compliance risks have the competence required to execute their obligations effectively.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC1.4", "fit": "partial", "rationale": "SOC 2 CC1.4 (COSO Principle 4) addresses the organization's commitment to competence through policies that consider the necessary skills and knowledge. Compliance training completion records directly evidence the organization's commitment to ensuring personnel have the required AI compliance competencies.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "openai_policies", "requirement_id": "Usage Policies", "fit": "partial", "rationale": "OpenAI's Usage Policies defines prohibited and restricted use cases for AI systems built on OpenAI APIs, including specific prohibitions on generating certain content categories, circumventing safety systems, and deploying into high-risk contexts without appropriate safeguards. The Compliance Training and Awareness Program (CI-05) must include role-specific training on these policy obligations for AI development and deployment teams, since violations of the Usage Policies expose the enterprise to API termination, regulatory scrutiny, and contractual liability. Usage Policies training is most critical for product managers and developers making deployment decisions.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. CI-05 training for teams building on Anthropic models should cover what the RSP does and does not do: the ASL-3 Deployment Standard governs Anthropic's own deployment safeguards, while the team's operative obligations come from the Usage Policy and commercial terms.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All in-scope personnel have completed role-specific AI compliance training within the required period, with attestation records documenting individual completion stored in a tracked learning management system. Training content must have been reviewed for legal accuracy within the prior 12 months.", "evidence_required": [ "LMS completion records listing employee_id, role_category, training_module_id, completion_timestamp, and pass/fail status for all in-scope staff during the audit period", "Training attestation certificates signed by each participant and retained for the audit period, covering EU AI Act, GDPR, and sector-specific AI obligation modules", "Training curriculum legal review sign-off from counsel documenting reviewer identity, review date, and specific regulatory changes prompting the review", "Knowledge assessment results by role category showing aggregate pass rates and individual scores for the current training cycle", "Just-in-time compliance notice log showing distribution date, recipient list, and triggering regulatory event for each notice issued in the period" ], "machine_tests": [ "Query LMS API for all in-scope staff with completion_status != 'completed' and training_due_date < today \u2192 assert 0 records returned", "Query training records for new hires with onboarding_date < (today - 30 days) and initial_training_completed = false \u2192 assert 0 records", "Check each active training module's last_legal_review_date \u2192 assert all dates fall within the prior 12 months", "Query knowledge assessment records for the current cycle \u2192 assert role-aggregate pass rate >= 85% for each role category" ], "human_review": [ "Review the role-based training matrix to confirm it covers EU AI Act obligations, model documentation requirements, prohibited use cases, and human oversight duties differentiated by role tier", "Assess knowledge assessment pass rates by role category and determine whether persistent failures below threshold indicate curriculum gaps requiring update", "Verify that just-in-time regulatory notices were issued following material regulatory changes during the period and that distribution lists matched in-scope personnel" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Delivering generic data privacy training that does not distinguish AI-specific obligations (model documentation, prohibited use cases, human oversight) from general data protection, leaving developers uninformed about EU AI Act conformity requirements", "Treating compliance training as a one-time onboarding activity with no annual refresh cycle or regulatory update triggers, causing obligation awareness to drift as regulations evolve", "Tracking training completion in spreadsheets or email acknowledgments rather than an auditable LMS with timestamped records, making it impossible to produce individual-level attestation evidence in regulatory proceedings", "Providing identical training modules to all roles rather than role-differentiated curriculum distinguishing developer, product manager, and executive obligation sets", "Deploying training content without legal accuracy review following material regulatory changes, creating compliance-by-ignorance risk from outdated obligation descriptions" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-06", "layer": "CI", "plane": "control", "name": "Internal Audit of AI Compliance Controls", "plain": "The enterprise must conduct regular internal audits of the AI compliance program, using independent auditors with AI domain competence, and report findings with root cause analysis and remediation recommendations to senior management and the audit committee.", "threat": { "tags": [ "governance-blind-spot", "audit-gap", "undetected-systemic-noncompliance", "oversight-failure" ], "desc": "Without independent internal audit, compliance programs develop blind spots that survive management reviews because those reviews are conducted by the same teams responsible for compliance. AI compliance is particularly vulnerable because the technical complexity of AI systems allows noncompliance to be masked behind engineering jargon. Internal auditors with AI-specific competence provide the independent perspective required to surface systemic weaknesses before they become regulatory findings." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.2", "title": "Internal audit" }, { "id": "soc2", "section": "CC4.2", "title": "COSO Principle 17 \u2014 Evaluates and Communicates Deficiencies" }, { "id": "cobit_2019", "section": "MEA02.04", "title": "Identify and report control deficiencies" }, { "id": "coso_erm", "section": "Principle 15", "title": "Assesses Substantial Change" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-06 Internal Audit of AI Compliance Controls control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CI-06 Internal Audit of AI Compliance Controls control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CI-06 Internal Audit of AI Compliance Controls control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CI-06 Internal Audit of AI Compliance Controls control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Annual internal audit plan covering the full CI control matrix; auditors independent of compliance operations; findings reported to the audit committee with root cause analysis; management responses tracked through CI-07.", "steps": [ "Develop an annual internal audit plan that covers each CI-layer control with a risk-based prioritization, identifying AI-specific risk areas such as evidence completeness for high-risk AI systems and obligation coverage gaps.", "Assign auditors who are independent of compliance operations and have documented AI domain competence or access to an AI technical advisor.", "Execute audits using a standard fieldwork methodology: document review, management inquiry, transaction testing, and control re-performance.", "Issue formal audit reports with findings classified by severity, root cause analysis, and remediation recommendations; route all findings to CI-07 for tracking.", "Present audit results to the audit committee within 30 days of fieldwork completion and track management responses." ], "compliance_officer": { "summary": "Internal audit provides independent assurance of the compliance program's effectiveness. Support auditor access and use findings as management improvement inputs, not just reporting obligations.", "actions": [ "Ensure auditors have unrestricted access to compliance documentation, tooling, and personnel.", "Provide formal management responses to all audit findings within 15 business days of draft report issuance.", "Track the percentage of prior-year audit findings that have been closed on schedule." ], "metrics": [ "Annual internal audit completion rate: target 100% of planned audit scope completed.", "Management response timeliness: target 100% of responses provided within 15 business days.", "Prior-year finding closure rate: target \u226585% of prior findings closed within agreed remediation timelines." ], "failure_signals": [ "Audit scope reductions due to resource constraints without audit committee approval.", "Management responses overdue for more than 30% of findings." ] }, "grc_auditor": { "summary": "You are the primary actor in CI-06. Maintain auditor independence, document fieldwork rigorously, and ensure findings are actionable and root-cause-driven rather than symptom-focused.", "actions": [ "Document independence confirmations for all audit team members before each engagement.", "Apply a standardized finding classification scheme (critical, high, medium, low) with defined severity criteria.", "Deliver draft reports to compliance management within 10 business days of fieldwork completion." ], "metrics": [ "Audit fieldwork documentation completeness: 100% of findings backed by documented evidence.", "Finding actionability rate: target \u226590% of findings include root cause analysis and specific remediation recommendations." ], "failure_signals": [ "Audit team lacks documented AI domain competence for AI-specific audit areas.", "Findings issued without root cause analysis or remediation recommendations." ] }, "executive": { "summary": "Internal audit of AI compliance provides the board with independent assurance that the compliance program operates as represented. Require audit committee oversight and personal sign-off on management responses to critical findings.", "actions": [ "Ensure the audit committee reviews all internal audit reports within 30 days of issuance.", "Require management responses to critical findings to be personally approved by the Chief Compliance Officer.", "Include internal audit finding trends in enterprise risk reporting to the board." ], "failure_signals": [ "Audit committee review of internal audit reports deferred more than 60 days.", "Critical findings from two consecutive audits without demonstrated root cause remediation." ] }, "legal_counsel": { "summary": "Internal audit reports constitute documentation that may be discoverable in regulatory proceedings. Advise on privilege strategy for audit documentation and ensure regulatory disclosure obligations related to material audit findings are met.", "actions": [ "Review audit report distribution protocols to minimize unnecessary disclosure of sensitive findings.", "Advise on whether material internal audit findings trigger regulatory disclosure obligations.", "Confirm that audit documentation retention aligns with applicable statutory requirements." ], "failure_signals": [ "Audit reports distributed without legal review of privilege implications.", "Material findings with potential regulatory disclosure implications not escalated to legal counsel within 5 business days." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Internal audit functions rarely have AI-specific competence. AI compliance audits are typically piggy-backed onto broader IT audits without dedicated scope or specialized methodology." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Internal Audit", "Compliance Team", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.2", "fit": "direct", "rationale": "ISO 37301 \u00a79.2 explicitly mandates that organizations conduct internal audits of their compliance management system at planned intervals to determine whether the system conforms to planned arrangements and is effectively implemented. CI-06 directly operationalizes this mandatory requirement with an AI-domain-competent audit program.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "direct", "rationale": "SOC 2 CC4.2 (COSO Principle 17) requires that organizations evaluate and communicate internal control deficiencies in a timely manner to parties responsible for taking corrective action. CI-06's audit reporting and management response process directly satisfies this criterion for the AI compliance control domain.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA02.04", "fit": "direct", "rationale": "COBIT 2019 MEA02.04 (Identify and report control deficiencies) requires that internal control deficiencies be identified and communicated to those responsible for corrective action. The internal audit function established by CI-06 is the primary mechanism through which this identification and communication obligation is fulfilled for AI compliance controls.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)", "fit": "partial", "rationale": "EU AI Act Article 9(2) requires the risk management system to run as a continuous iterative process requiring regular systematic review and updating throughout the AI system lifecycle. Internal audits of AI compliance controls provide the independent review mechanism that validates whether these risk management measures remain effective and are being properly applied.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 15", "fit": "partial", "rationale": "COSO ERM 2017 Principle 15 (Assesses Substantial Change) requires the organization to identify and assess internal and external changes that may substantially affect its risk profile. Internal audit of AI compliance controls is the structured mechanism for identifying when AI-related changes have created new compliance gaps that require management attention.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's Assessment Templates provide pre-built, regulation-specific control catalogs (ISO 27001, SOC 2, GDPR, EU AI Act) that internal auditors can use as fieldwork scope documents for AI compliance audits. The Internal Audit of AI Compliance Controls (CI-06) requires auditors with documented AI domain competence and a standard fieldwork methodology; Compliance Manager templates supply the control inventory and evidentiary requirements that auditors need to structure their document review and testing procedures, reducing audit preparation time and ensuring scope completeness against each regulatory framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact's SOC 2 Type II reports and ISO 27001 certificates provide independently verified evidence of AWS infrastructure control effectiveness that internal auditors must review when examining AI systems deployed on AWS. CI-06's internal audit methodology requires that auditors assess the full control environment, including underlying infrastructure controls; for cloud-hosted AI systems, AWS Artifact reports constitute the third-party audit evidence that satisfies infrastructure control testing requirements without requiring the enterprise to independently audit AWS data centers.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "partial", "rationale": "Google Cloud's compliance certifications (ISO 27001, SOC 2, PCI DSS, FedRAMP) and associated audit reports provide auditor-grade evidence of GCP infrastructure control effectiveness for AI workloads hosted on Google Cloud. CI-06's internal audit program must incorporate Google Cloud certification documentation when scoping audits of GCP-hosted AI systems \u2014 these certifications reduce the audit evidence burden for platform-layer controls while providing the independent assurance required to support a complete internal audit finding set.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance's Audit Reporting generates structured logs of access certification decisions, policy enforcement events, segregation-of-duties violations, and governance workflow completions that internal auditors need to assess identity control effectiveness for AI system environments. CI-06 requires auditors to execute transaction testing and control re-performance; Okta's audit reports provide the identity governance transaction data required to verify that AI system access was properly authorized, certified, and revoked during the audit period, directly supporting the audit fieldwork documentation completeness target.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "An internal audit covering the full CI-layer control matrix has been completed within the current annual cycle by auditors with documented AI domain competence who are independent of compliance operations. All findings include root cause analysis and have been routed to the remediation register with management responses provided within 15 business days of draft report issuance.", "evidence_required": [ "Annual internal audit plan signed by the Chief Audit Executive, identifying scope, risk-based prioritization, and AI competence documentation for all audit team members", "Auditor independence declarations for each team member confirming no organizational reporting line to the compliance function under review", "Audit fieldwork workpapers documenting control testing methodology, evidence reviewed, and basis for each finding classification", "Formal audit report with findings classified by severity (critical/high/medium/low), root cause analysis, and specific remediation recommendations per finding", "Management response letters providing corrective action commitments, named owners, and due dates for each finding, submitted within 15 business days of draft issuance" ], "machine_tests": [ "Query remediation register for audit findings where management_response_date > (finding_issued_date + 15 business days) \u2192 assert 0 overdue responses", "Query audit team roster for all engagements and cross-reference against AI competence documentation registry \u2192 assert 100% of engagements document AI domain competence for in-scope areas", "Check audit plan scope against CI-layer control inventory (CI-01 through CI-08) \u2192 assert all 8 controls appear in audit scope" ], "human_review": [ "Assess auditor independence declarations for all team members, verifying no material organizational conflict with compliance operations personnel who own the controls under audit", "Review audit findings for root cause specificity \u2014 confirm findings address systemic causes rather than surface symptoms that are likely to recur in subsequent cycles", "Evaluate audit committee presentation timing and committee response documentation to confirm genuine board-level engagement with findings rather than pro-forma receipt" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Assigning IT auditors without AI domain competence to audit AI compliance controls, producing findings that miss technical root causes specific to model lifecycle, data governance, or EU AI Act conformity obligations", "Conducting AI compliance audits as a subset of broader IT audits without dedicated scope, resulting in superficial coverage that treats AI-specific controls as generic IT controls", "Issuing audit reports with symptom-level findings ('training completion was low') without root cause analysis, preventing the remediation register from addressing the underlying systemic failure", "Routing audit findings to a general action log rather than requiring formal management responses, leaving the audit committee unable to assess whether the organization has accepted or contested each finding", "Using auditors who are organizationally supervised by the compliance function they are auditing, eliminating the independence that gives internal audit assurance value" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-07", "layer": "CI", "plane": "lifecycle", "name": "Remediation Tracking and Closure", "plain": "The enterprise must operate a systematic remediation tracking system that receives compliance gaps from all identification sources, assigns owners and due dates, tracks progress to closure, escalates overdue items, and verifies that remediation has been implemented before closing tickets.", "threat": { "tags": [ "finding-drift", "remediation-abandonment", "recurrence", "accountability-gap" ], "desc": "Compliance findings are only valuable if they are remediated. Without systematic tracking, findings accumulate in audit reports while the underlying control failures persist. Organizations with fragmented tracking\u2014findings in one system, remediation in another, closure undocumented\u2014cannot demonstrate to regulators that identified deficiencies were actually resolved. For AI compliance, where findings often have technical root causes, informal remediation processes frequently result in recurrence within one or two audit cycles." }, "standard": [ { "id": "iso_37301", "section": "\u00a710.2", "title": "Noncompliance and corrective action" }, { "id": "soc2", "section": "CC4.2", "title": "COSO Principle 17 \u2014 Communicates Deficiencies" }, { "id": "cobit_2019", "section": "MEA02.04", "title": "Identify and report control deficiencies" }, { "id": "nist_csf", "section": "RS.MI", "title": "Incident Mitigation \u2014 corrective action tracking" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-07 Remediation Tracking and Closure control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CI-07 Remediation Tracking and Closure control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Centralized remediation register in the compliance tooling platform; each ticket has owner, severity classification, root cause, remediation plan, target date, and verification evidence; automated escalation on overdue items; closure requires evidence of remediation verification.", "steps": [ "Configure the remediation tracking module in the compliance tooling platform (CI-04) to receive tickets from all CI-layer control failure sources: CI-01 test failures, CI-02 monitoring alerts, and CI-06 audit findings.", "Define a standardized ticket schema: finding source, severity, affected control, root cause, assigned owner, remediation plan, target closure date, and verification criteria.", "Implement automated escalation rules: medium-severity tickets overdue by 30 days escalate to the control owner's manager; high-severity overdue by 15 days escalate to the compliance officer; critical-severity overdue by 7 days escalate to the executive team.", "Require remediation verification before ticket closure: the ticket owner documents the corrective action taken, and the compliance team independently verifies effectiveness using a re-test or re-assessment.", "Report weekly on open remediation tickets by severity and age; present a monthly remediation velocity trend to compliance leadership." ], "compliance_officer": { "summary": "The remediation register is your accountability instrument. No finding is closed without verified effectiveness. Own the escalation policy and review the weekly open ticket report.", "actions": [ "Review the weekly open remediation ticket report and personally contact owners of all overdue high-severity items.", "Approve remediation plans for critical findings before remediation begins.", "Verify closure evidence for all high and critical findings before approving ticket closure." ], "metrics": [ "Remediation closure rate within agreed timelines: target \u226590% of tickets closed by due date.", "Mean days to close by severity: critical \u226415 business days, high \u226430, medium \u226460.", "Recurrence rate: percentage of closed findings that reappear in the next audit cycle, target \u226410%." ], "failure_signals": [ "More than 20% of open tickets overdue by more than 30 days.", "Critical finding open for more than 15 business days without a documented remediation plan." ] }, "grc_auditor": { "summary": "The remediation register is central audit evidence that identified deficiencies were resolved. Verify register completeness, closure verification quality, and recurrence patterns during audit engagements.", "actions": [ "Request the full remediation register for the audit period and verify that all prior audit findings have linked tickets.", "Sample closed tickets to verify that closure evidence demonstrates effective remediation, not just cosmetic process changes.", "Analyze recurrence patterns to identify systemic root causes not being addressed by point-in-time remediation." ], "metrics": [ "Register completeness: 100% of audit findings have linked remediation tickets.", "Closure verification documentation rate: target 100% of closed high and critical tickets have verification evidence." ], "failure_signals": [ "Audit findings without linked remediation tickets.", "Tickets closed without documented verification evidence for high-severity items." ] }, "it_operations": { "summary": "Many remediation actions require technical implementation. Participate in remediation planning for technical findings and deliver implementation evidence that satisfies compliance verification requirements.", "actions": [ "Accept assignment of technically-rooted remediation tickets and deliver implementation within agreed timelines.", "Provide detailed technical evidence (configuration changes, deployment records, test results) sufficient for compliance verification.", "Flag dependencies between remediation actions and infrastructure change windows to prevent timeline surprises." ], "failure_signals": [ "Technical remediation tickets unacknowledged for more than 5 business days.", "Remediation evidence insufficient for compliance verification on more than 10% of closed tickets." ] }, "executive": { "summary": "Unresolved compliance findings are quantified regulatory exposure. Require monthly remediation velocity reporting and authorize emergency resource allocation for critical findings that are approaching escalation thresholds.", "actions": [ "Receive monthly remediation velocity report as part of the compliance scorecard.", "Authorize additional resources for remediation when critical finding age approaches the escalation threshold.", "Require root cause analysis reports for any finding that recurs in consecutive audit cycles." ], "failure_signals": [ "Critical findings open beyond 30 days without executive-level escalation.", "Overall remediation closure rate below 75% for two consecutive quarters." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations track remediation in audit management tools that are disconnected from compliance monitoring and control testing systems. Verification of remediation effectiveness before ticket closure is rarely enforced." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "cloud-native", "federated-enterprise" ], "implementers": [ "Compliance Team", "Internal Audit", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a710.2", "fit": "direct", "rationale": "ISO 37301 \u00a710.2 requires organizations to determine the causes of noncompliances, take corrective actions, and review the effectiveness of those corrective actions. CI-07 operationalizes this entire corrective action lifecycle through a systematic tracking and verification process with defined escalation triggers.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "direct", "rationale": "SOC 2 CC4.2 requires that identified internal control deficiencies are communicated to parties responsible for taking corrective action and that deficiencies are remediated on a timely basis. The CI-07 remediation register with owner assignment, escalation, and independent verification is the direct implementation of this criterion.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA02.04", "fit": "direct", "rationale": "COBIT 2019 MEA02.04 (Identify and report control deficiencies) requires identifying control deficiencies and reporting them to stakeholders so that remedial actions are initiated in a timely manner. The CI-07 escalation framework and closure verification requirements are the operational mechanisms through which reported deficiencies are driven to verified closure for AI compliance controls.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 20", "fit": "partial", "rationale": "EU AI Act Article 20 requires providers of high-risk AI systems to undertake corrective actions when their systems do not conform to the requirements of the Act. The CI-07 remediation tracking system provides the documented corrective action evidence required to demonstrate compliance with this obligation to market surveillance authorities.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_csf", "requirement_id": "RS.MI", "fit": "adjacent", "rationale": "NIST CSF 2.0 RS.MI (Incident Mitigation) addresses activities to contain events and prevent their expansion. The systematic tracking and closure discipline required for compliance remediation follows the same structural pattern, and organizations with mature incident mitigation processes can extend those processes to compliance remediation workflows.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's Improvement Actions function as a purpose-built remediation tracking system \u2014 each action has an assigned owner, implementation status, test evidence requirement, and directly links to the regulatory obligation it addresses. For enterprises using Compliance Manager as part of their CI-04 tooling stack, Improvement Actions can serve as the primary remediation register for compliance gaps identified against Microsoft regulatory templates, satisfying CI-07's requirements for owner assignment, target dates, and evidence-verified closure without a separate tracking tool.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Workflows", "fit": "adjacent", "rationale": "Okta Workflows provides no-code automation for identity remediation tasks \u2014 revocations, escalations, and notifications triggered by governance events. CI-07's remediation tracking applies the same automation pattern to compliance findings, routing remediation tasks to owners and verifying closure.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every compliance gap identified by control testing (CI-01), monitoring (CI-02), or internal audit (CI-06) has a corresponding remediation ticket with an assigned single owner, target date, documented root cause, remediation plan, and independently verified closure evidence. No critical-severity ticket is open beyond 15 business days without a documented executive escalation record.", "evidence_required": [ "Remediation register export listing all open and closed tickets with source_control, severity, assigned_owner, root_cause, remediation_plan, target_date, and actual_closure_date for the full audit period", "Closure verification records for each high and critical ticket documenting the independent verifier identity, verification method (re-test, configuration check, or re-assessment), and verification outcome", "Automated escalation log showing escalation trigger events and management acknowledgment timestamps for all overdue items during the period", "Recurrence analysis report identifying any finding appearing in both the current and prior audit cycle, with root cause explanation for recurrence", "Weekly remediation velocity reports showing open ticket counts by severity and age distribution across the audit period" ], "machine_tests": [ "Query remediation register for tickets with severity = 'critical' AND status = 'open' AND days_open > 15 AND executive_escalation_record IS NULL \u2192 assert 0 results", "Query all closed tickets where severity IN ('high','critical') AND closure_verification_evidence IS NULL \u2192 assert 0 results", "Query all remediation tickets for the current audit period and verify each links to a source finding in CI-01, CI-02, or CI-06 \u2192 assert 100% source traceability" ], "human_review": [ "Review a sample of closed high and critical tickets to verify closure evidence demonstrates genuine root cause remediation rather than administrative ticket closure without corrective action implementation", "Analyze recurrence patterns across the current and prior audit cycle to identify control areas where remediation consistently addresses symptoms rather than systemic causes", "Assess escalation protocol effectiveness by reviewing overdue ticket distribution and confirming escalations were triggered and produced documented management responses within defined thresholds" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Closing remediation tickets based on the owner's self-certification that corrective action was taken without independent verification evidence, allowing cosmetic process changes to satisfy closure criteria", "Maintaining parallel remediation tracking across audit tools, GRC platforms, and email without a single authoritative register, creating gaps that regulators can identify as evidence of unmanaged remediation", "Treating all findings as equal priority regardless of severity classification, allowing critical control failures to age alongside low-priority documentation gaps without differentiated escalation", "Assigning remediation tickets to team queues rather than named single owners, diffusing accountability and producing predictable due-date slippage without clear escalation targets", "Permitting ticket closure without documented root cause analysis, enabling recurring findings to accumulate across audit cycles because the systemic cause is never formally addressed" ], "update_status": "current", "layer_code": "CI" }, { "id": "CI-08", "layer": "CI", "plane": "both", "name": "Compliance Implementation Evidence Package", "plain": "The enterprise must compile a structured evidence package demonstrating that CI-layer controls are tested, monitored, trained on, internally audited, and remediated\u2014suitable for regulatory inspection, external audit, and executive attestation of the AI compliance program's operational effectiveness.", "threat": { "tags": [ "evidence-incompleteness", "regulatory-inspection-failure", "attestation-gap", "audit-readiness-failure" ], "desc": "An AI compliance program that operates but cannot demonstrate its operation is indistinguishable from one that does not exist in the eyes of regulators, external auditors, and counterparties. Evidence package gaps are frequently discovered only when an inspection or audit is initiated, leaving insufficient time to reconstruct evidence. For AI systems subject to EU AI Act conformity assessments or SOC 2 audits, an incomplete CI evidence package is itself a material finding that elevates regulatory risk." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.3", "title": "Management review \u2014 documented evidence" }, { "id": "eu_ai_act", "section": "Art. 18", "title": "Technical documentation retention" }, { "id": "soc2", "section": "CC2.2", "title": "COSO Principle 14 \u2014 Communicates Internally" }, { "id": "gdpr", "section": "Art. 5(2)", "title": "Accountability \u2014 demonstrating compliance" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CI-08 Compliance Implementation Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CI-08 Compliance Implementation Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CI-08 Compliance Implementation Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CI-08 Compliance Implementation Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CI-08 Compliance Implementation Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Structured evidence package compiled from CI-01 through CI-07 outputs: control test results, monitoring alert logs, KPI scorecards, tooling health reports, training completion records, internal audit reports, and remediation closure evidence. Package assembled in the compliance tooling platform with integrity hash and executive attestation.", "steps": [ "Define the CI evidence package inventory: control test plans and results (CI-01), monitoring pipeline logs and alert records (CI-02), KPI scorecards (CI-03), tooling health reports (CI-04), training completion attestations (CI-05), internal audit reports and management responses (CI-06), and remediation register exports (CI-07).", "Configure the compliance tooling platform to automatically assemble the CI evidence package on a defined cadence (minimum quarterly; continuously for high-risk AI deployments).", "Apply SHA-256 hash verification to all evidence artifacts in the package at the time of assembly to establish chain-of-custody integrity.", "Obtain executive attestation on the quarterly evidence package summary, documenting that CI-layer controls are operating effectively to the best of management's knowledge.", "Retain assembled evidence packages for a minimum of 3 years (or as required by applicable regulation) and validate package completeness against the CI-layer control inventory at each assembly cycle." ], "compliance_officer": { "summary": "The CI evidence package is the authoritative artifact proving your compliance program operates as designed. Own the assembly process, verify completeness before executive attestation, and treat gaps as high-priority remediation items.", "actions": [ "Verify evidence package completeness against the CI control inventory before each quarterly assembly.", "Brief executive leadership on evidence package status prior to requesting attestation.", "Maintain a completeness log documenting any evidence gaps and their approved exceptions." ], "metrics": [ "Evidence package completeness rate: target 100% of CI-layer controls represented in each package.", "Artifact integrity verification rate: target 100% of artifacts hash-verified at assembly.", "Executive attestation timeliness: target signed within 10 business days of package assembly completion." ], "failure_signals": [ "Evidence package completeness below 90% at any quarterly assembly.", "Executive attestation delayed more than 20 business days after assembly completion." ] }, "legal_counsel": { "summary": "The evidence package is a legal document that may be presented in regulatory proceedings. Review package structure for regulatory completeness, advise on privilege protections, and confirm retention periods align with applicable law.", "actions": [ "Review the evidence package structure annually to confirm it satisfies disclosure requirements under applicable AI regulations and data protection law.", "Advise on which package components may be subject to legal privilege and how to preserve that status.", "Confirm statutory retention periods for each evidence artifact type and verify the retention policy reflects the longest applicable requirement." ], "failure_signals": [ "Evidence package structure not reviewed by legal counsel in the prior 12 months.", "Retention policy shorter than the longest applicable statutory requirement." ] }, "grc_auditor": { "summary": "The CI evidence package is the primary artifact for external audit engagements and regulatory inspections. Audit the package assembly process, verify artifact integrity, and test a sample of artifacts against source documentation.", "actions": [ "Request the full CI evidence package for the audit period and verify completeness against the CI control inventory.", "Independently verify SHA-256 hashes for a sample of artifacts to confirm integrity has been maintained since assembly.", "Test a sample of evidence artifacts against underlying source records to verify authenticity." ], "metrics": [ "Package completeness: 100% of CI-layer controls have evidence artifacts in the package.", "Hash verification accuracy: 100% of sampled artifacts hash-match the assembly record." ], "failure_signals": [ "Missing evidence for any CI-layer control in the package.", "Hash mismatches for any sampled artifact." ] }, "executive": { "summary": "Your attestation on the CI evidence package is a personal affirmation that the AI compliance program operated effectively. Require a briefing before each attestation and treat evidence gaps as material risk items requiring immediate escalation.", "actions": [ "Review the evidence package completeness summary before signing the quarterly attestation.", "Require the compliance officer to brief on any evidence gaps before attestation is requested.", "Include CI evidence package completeness as a metric in the enterprise compliance dashboard presented to the board." ], "failure_signals": [ "Attestation requested without a compliance officer completeness briefing.", "Evidence package completeness below 90% at the time of attestation request." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises assemble audit evidence reactively in response to external audit requests. Proactive, continuously assembled evidence packages with integrity verification are rare and represent a significant maturity advance." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Compliance Team", "Internal Audit", "Legal Counsel" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.3", "fit": "direct", "rationale": "ISO 37301 \u00a79.3 requires top management to conduct management reviews of the compliance management system, supported by documented evidence of compliance performance, audit results, and corrective action status. The CI evidence package provides exactly the documentation required to support this management review obligation.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "direct", "rationale": "EU AI Act Article 18 requires that providers of high-risk AI systems draw up and keep technical documentation that demonstrates compliance with the requirements of the Act. The CI evidence package is the technical documentation artifact that demonstrates the compliance program's operational effectiveness throughout the AI system lifecycle.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "direct", "rationale": "GDPR Article 5(2) (the accountability principle) requires that controllers be able to demonstrate compliance with the data protection principles. The CI evidence package compiled under CI-08 is the primary accountability artifact for demonstrating that the organization's AI compliance program was operating effectively throughout the review period.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.2", "fit": "partial", "rationale": "SOC 2 CC2.2 (COSO Principle 14) requires that organizations internally communicate information necessary for the functioning of internal control. The CI evidence package supports this requirement by providing a structured, integrity-verified record of compliance program activities available to all relevant internal stakeholders and external auditors.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 20", "fit": "partial", "rationale": "COSO ERM Principle 20 (Reports on Enterprise Risk, Culture, and Performance) requires that organizations communicate risk information to boards, management, and external stakeholders. The CI evidence package provides the structured risk evidence that supports this communication obligation for AI compliance risks specifically.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "MEA03.04", "fit": "partial", "rationale": "COBIT 2019 MEA03.04 (Obtain assurance of external compliance) requires obtaining assurance of compliance with external requirements. The CI evidence package serves as the documentation basis for that assurance, and its structured assembly process ensures that compliance posture can be articulated to regulatory bodies and auditors on demand.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager generates exportable assessment reports from its regulatory templates that constitute structured compliance evidence artifacts suitable for inclusion in the CI evidence package. The Compliance Implementation Evidence Package (CI-08) requires a structured collection of control test results, monitoring outputs, and KPI scorecards; for Microsoft 365 and Azure AI deployments, Compliance Manager assessment exports provide a pre-formatted, regulator-ready evidence artifact covering the Microsoft control layer, reducing manual compilation effort and supporting the package integrity requirements CI-08 mandates.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact's downloadable SOC 2 Type II reports, ISO 27001 certificates, and FedRAMP authorization packages are third-party compliance artifacts that must be included in the CI evidence package for organizations running AI workloads on AWS infrastructure. CI-08 requires that the evidence package demonstrate operational effectiveness across the full AI system stack; for cloud-deployed systems, AWS Artifact reports supply the platform-layer compliance evidence without which the package would be incomplete and could fail regulatory inspection for infrastructure controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "Google Cloud's compliance reports and certification documents (SOC 2, ISO 27001, ISO 27017, PCI DSS) provide auditor-grade evidence of GCP infrastructure controls that must be included in the CI evidence package for GCP-hosted AI deployments. CI-08 requires hash-verified artifact integrity and completeness against the full CI control inventory; for organizations using GCP, Google compliance reports constitute the platform-layer evidence artifacts that complete the package and support regulatory inspection of the infrastructure on which AI systems operate.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI's Enterprise Data Processing Addendum constitutes a contractual compliance artifact that documents the data handling, retention, and subprocessor obligations governing AI systems built on OpenAI APIs. CI-08's evidence package must include third-party compliance agreements to demonstrate that the organization's AI compliance program accounts for all applicable obligations; the Enterprise DPA and its associated service terms provide the contractual evidence layer required to demonstrate that data protection obligations arising from OpenAI API usage have been formally documented and accepted.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. CI-08's evidence package should document that vendor self-governance context was assessed for Anthropic-based systems, referencing current RSP documentation and published Capability Report summaries as the provider-layer evidence.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CI-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A structured evidence package containing artifacts from all CI-layer controls (CI-01 through CI-07) has been assembled on a defined cadence, with SHA-256 hash verification applied to every artifact, completeness verified at 100% against the CI control inventory, and executive attestation signed within 10 business days of assembly completion. The package must be retrievable for regulatory inspection within 24 hours of any request.", "evidence_required": [ "CI evidence package index listing every artifact type, artifact filename, SHA-256 hash, collection timestamp, and source control reference for each included artifact", "Executive attestation signature document confirming the package represents a complete and accurate record of CI-layer control operation for the period covered, signed by the CCO or designated executive", "Package completeness verification log documenting the compliance officer's artifact-by-artifact review against the CI control inventory, with any approved exceptions and exception justification", "SHA-256 hash verification report confirming all artifacts in the package match their recorded hashes, generated at the time of each inspection or audit request", "Retention policy documentation confirming storage period meets the longest applicable statutory requirement across all regulatory frameworks the package covers" ], "machine_tests": [ "Recompute SHA-256 hashes for all artifacts in the assembled package and compare against the package index \u2192 assert 100% hash matches with zero discrepancies", "Query package index artifact types against the CI control inventory \u2192 assert completeness = 100% with no unrepresented CI controls", "Check executive attestation signature timestamp against package assembly completion timestamp \u2192 assert signature date is within 10 business days of assembly_completed_date" ], "human_review": [ "Review the completeness verification log against the full CI-layer control inventory to confirm no control is unrepresented and all approved exceptions are documented with adequate justification", "Assess artifact collection timestamps across the package to confirm distribution across the review period rather than clustering near the assembly date, evidencing contemporaneous collection", "Evaluate the exception register for approved completeness gaps and determine whether exceptions are escalated appropriately and present no material risk to attestation integrity" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Assembling the evidence package reactively in the weeks before a scheduled audit rather than on a continuous or quarterly cadence, producing artifact timestamps that reveal retroactive collection to any auditor who inspects ingestion dates", "Attaching evidence artifacts to the package without computing SHA-256 hashes, making it impossible to demonstrate integrity if an auditor or regulator attempts hash verification of the produced artifacts", "Obtaining executive attestation without a prior compliance officer completeness briefing, exposing the signer to personal liability for attesting to a package with undisclosed gaps", "Storing evidence packages in shared file systems without write-once or version-lock controls, allowing post-assembly modification that silently breaks hash integrity", "Including vendor compliance reports with audit periods that do not overlap the organization's review period, creating temporal gaps in platform-layer evidence that auditors will identify as coverage holes" ], "update_status": "current", "layer_code": "CI" }, { "id": "AU-01", "layer": "AU", "plane": "lifecycle", "name": "Audit Readiness Program", "plain": "The organization must maintain a continuous audit-ready state by pre-organizing evidence packages for each applicable compliance framework, ensuring all required artifacts are current, validated, and accessible at any time without emergency preparation.", "threat": { "tags": [ "audit-failure", "evidence-gap", "regulatory-noncompliance", "last-minute-scramble" ], "desc": "Organizations that prepare for audits reactively face elevated risk of examination failure, evidence gaps, and regulatory findings. When evidence packages are assembled under time pressure, errors and omissions increase significantly. Regulators and notified bodies that treat inadequate preparation as a control deficiency can escalate findings to material noncompliance, triggering enforcement action that the audit failure itself may not have warranted." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.2", "title": "Internal audit" }, { "id": "soc2", "section": "CC4.1", "title": "COSO Principle 16 \u2014 ongoing and separate evaluations of internal controls" }, { "id": "cobit_2019", "section": "MEA02", "title": "Managed System of Internal Control" }, { "id": "gdpr", "section": "Art. 5(2)", "title": "Accountability principle \u2014 demonstrating compliance at any time" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-01 Audit Readiness Program control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-01 Audit Readiness Program control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/AU-01 Audit Readiness Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a living evidence library organized by framework and obligation, with scheduled refresh cycles, completeness scoring, and automated staleness alerts. Each framework package contains a checklist of required artifact types, their current collection status, responsible owners, and next-review dates. Automated completeness scores trigger escalation when any package falls below threshold.", "steps": [ "Inventory all applicable compliance frameworks and produce a structured evidence package template for each, specifying required artifact types, acceptable formats, refresh cadences, and owner assignments.", "Implement automated completeness scoring for each package, triggering alerts when artifact staleness exceeds defined thresholds (e.g., 90 days for continuous controls, 12 months for annual assessments).", "Conduct quarterly mock audits against the highest-risk framework packages to validate that evidence is accurate, retrievable, and sufficient to support examiner review without additional preparation.", "Establish a formal pre-audit dry-run procedure at least 60 days before any scheduled examination, providing remediation time before formal commencement." ], "compliance_officer": { "summary": "Audit readiness is a continuous program, not a point-in-time event. You own the evidence library and must ensure each framework package remains current and complete throughout the year \u2014 not only when an audit is imminent.", "actions": [ "Define the authoritative list of applicable frameworks and assign package owners for each.", "Review completeness scores monthly and escalate any package below 85% to the GRC committee.", "Conduct or sponsor quarterly mock audit exercises and publish findings to the GRC committee." ], "metrics": [ "Overall evidence package completeness rate: target \u226595%.", "Percentage of artifacts refreshed within required cadence: target 100%.", "Mock audit pass rate: target \u226590%." ], "failure_signals": [ "Any framework package below 85% completeness for more than 30 consecutive days.", "More than two consecutive quarters without a mock audit exercise.", "Evidence artifacts not refreshed within defined staleness thresholds." ] }, "grc_auditor": { "summary": "The audit readiness program is the primary mechanism for demonstrating the compliance program's operational effectiveness. Assess whether evidence packages are genuinely maintained continuously or assembled on demand in response to audit notifications.", "actions": [ "Request completeness score history for each framework package and validate artifact timestamps for distribution across the year.", "Sample 15% of required artifacts per package and confirm they meet the defined refresh cadence.", "Review mock audit reports and track whether identified gaps were remediated before the next exercise." ], "metrics": [ "Evidence package completeness rate: target \u226595%.", "Artifact refresh compliance rate: target 100%.", "Time-to-close for mock audit findings: target \u226445 days." ], "failure_signals": [ "Evidence packages assembled retroactively within 30 days of an audit announcement.", "Artifact timestamps clustered around audit notification dates rather than distributed across the calendar year.", "Repeated mock audit findings in the same control area across consecutive quarters." ] }, "legal_counsel": { "summary": "Continuous audit readiness reduces legal exposure by ensuring the organization can demonstrate compliance at any point in time, not only during scheduled audits. This is directly relevant to regulatory enforcement contexts where point-in-time snapshots may be insufficient.", "actions": [ "Review evidence package templates to confirm legal privilege considerations are addressed for sensitive artifacts.", "Advise on document retention policies that satisfy both audit readiness and litigation hold requirements.", "Ensure the regulatory examination response program is aligned with the audit readiness program cadence." ], "failure_signals": [ "Evidence packages contain legally privileged documents without appropriate handling controls.", "Retention policies conflict between audit readiness requirements and litigation hold obligations." ] }, "executive": { "summary": "Audit readiness is a board-level governance indicator. Continuous readiness reduces the cost and disruption of regulatory examinations and demonstrates mature compliance operations to investors, insurers, and counterparties.", "actions": [ "Receive quarterly dashboard reporting on evidence package completeness scores across all applicable frameworks.", "Sponsor adequate resourcing for the evidence library, mock audit program, and remediation cycles.", "Review and approve the audit readiness program charter annually." ], "failure_signals": [ "Compliance team reporting emergency evidence assembly in preparation for any audit.", "Completeness scores showing a declining trend over two consecutive quarters without a documented remediation plan." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises treat audit readiness as a periodic event rather than a continuous program. Continuous evidence libraries with automated staleness tracking and quarterly mock audits are emerging best practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "GRC Operations", "Legal Counsel", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.2 requires internal audits at planned intervals to provide information on whether the compliance management system conforms to requirements and is effectively implemented and maintained. Continuous audit readiness operationalizes this by keeping the evidence base those audits draw on current \u2014 completeness scoring, staleness alerting, and mock audit exercises \u2014 rather than producing point-in-time snapshots only when an audit is imminent.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "direct", "rationale": "SOC 2 CC4.1 addresses ongoing and separate evaluations of internal controls aligned with COSO Principle 16. Pre-organized evidence packages enable the service auditor to efficiently assess control design and operating effectiveness across the entire examination period without requiring the service organization to assemble evidence reactively.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA02", "fit": "direct", "rationale": "COBIT 2019 MEA02 (Managed System of Internal Control) requires continuous monitoring of internal control effectiveness. The audit readiness program implements this by maintaining current evidence of control operation across all applicable frameworks and applying completeness scoring to identify gaps before they become examination findings.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "direct", "rationale": "GDPR Article 5(2) imposes the accountability principle requiring controllers to demonstrate compliance with data protection principles at any time upon request from a supervisory authority. Continuous audit readiness directly implements this requirement by ensuring evidence is maintained and accessible on a perpetual basis, not only during planned audit periods.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17(1)(k)", "fit": "partial", "rationale": "EU AI Act Article 17(1)(k) requires the quality management system of providers of high-risk AI systems to include systems and procedures for record-keeping of all relevant documentation and information. Audit readiness packages serve as the operational mechanism for maintaining these records in a state accessible to market surveillance authorities at any point during the system lifecycle.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Principle 16", "fit": "partial", "rationale": "COSO ERM 2017 Principle 16 (Reviews Risk and Performance) requires the organization to review entity performance and consider risk as part of that review. The audit readiness program operationalizes continuous review of compliance control performance through completeness scoring, staleness alerting, and mock audit exercises.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager provides pre-built assessment templates for ISO 27001, SOC 2, GDPR, and EU AI Act that operationalize continuous audit readiness \u2014 the core purpose of AU-01. The Audit Readiness Program maps directly to Compliance Manager's design: maintaining per-framework assessment completeness scores, tracking improvement actions to verified closure, and keeping evidence packages current year-round rather than assembling them only when an examination is imminent. Compliance Manager's staleness alerting and completeness scoring directly implement the automated completeness monitoring described in AU-01.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact provides on-demand access to AWS SOC 1/2/3, ISO 27001, FedRAMP, PCI DSS, and HIPAA reports that serve as third-party evidence inputs required in audit readiness packages for organizations with AWS infrastructure. AU-01 requires evidence packages to be current and accessible without emergency preparation; AWS Artifact's on-demand retrieval model ensures these cloud provider compliance artifacts can be incorporated into a continuously current evidence library, satisfying the Audit Readiness Program's artifact refresh cadence requirements for cloud-layer controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "Google Cloud Compliance & Assurance publishes regulatory audit reports and certifications covering ISO 27001, SOC 2, PCI DSS, and FedRAMP for GCP workloads that are required evidence inputs in AU-01 audit readiness packages for organizations running compliance-relevant workloads on GCP. AU-01's requirement to maintain continuously current, accessible evidence packages extends to cloud provider attestations; Google's compliance resource center enables these GCP-specific artifacts to be retrieved and kept current within the evidence library without ad hoc emergency retrieval when an examination is announced.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization maintains a continuously current evidence library for each applicable compliance framework with completeness scores at or above 95%, all artifacts refreshed within defined cadence thresholds, and at least four quarterly mock audit exercises completed in the review year with findings closed within 45 days. No framework evidence package was assembled reactively within 30 days of an audit notification.", "evidence_required": [ "Evidence library completeness score history for each applicable framework, showing scores recorded at least monthly and distributed across the review period rather than spiking near audit notification dates", "Artifact staleness tracking report showing each artifact type's last_refreshed_date and compliance status against the defined maximum staleness threshold", "Quarterly mock audit reports documenting scope, methodology, findings, and participants for each of the four required exercises in the review year", "Mock audit finding remediation records confirming all gaps identified in each exercise were closed within 45 days of report issuance", "Annual audit readiness program charter or review sign-off from the Chief Compliance Officer confirming applicable framework inventory and program scope" ], "machine_tests": [ "Query completeness score history for all framework packages \u2192 assert no package fell below 85% completeness for more than 30 consecutive days in the review period", "Query artifact metadata for each framework package \u2192 assert all artifacts have last_refreshed_timestamp within the defined staleness threshold for their artifact type", "Query mock audit schedule and completion records for the current year \u2192 assert at least 4 exercises have documented completion reports" ], "human_review": [ "Analyze artifact timestamp distributions for each framework package to determine whether evidence reflects continuous collection across the year or retroactive assembly clustered near audit notifications", "Review mock audit after-action reports across consecutive exercises to assess whether identified gaps recur, indicating systematic remediation failure rather than improving readiness posture", "Assess the framework applicability inventory to confirm it covers all regulatory frameworks currently applicable to the organization's AI deployments, including any frameworks added since the last annual program review" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Treating audit readiness as a project that activates upon receipt of an audit notification rather than a continuous program with year-round evidence maintenance and completeness scoring", "Measuring readiness only at the aggregate framework completeness level without tracking individual artifact staleness, allowing critical evidence types to expire while the overall score remains above threshold", "Conducting mock audits in the same familiar control areas each quarter without rotating scope across the full control matrix, leaving unexamined areas to accumulate silent gaps between cycles", "Centralizing evidence library ownership entirely within the GRC team without distributing artifact refresh responsibility to control owners, creating a single point of failure when GRC capacity is constrained during actual examinations", "Relying exclusively on vendor-provided cloud compliance reports without maintaining internally generated evidence for organizational controls, producing packages that cannot demonstrate the enterprise's own control operation to auditors" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-02", "layer": "AU", "plane": "data", "name": "Evidence Collection, Curation, and Validation", "plain": "The organization must systematically gather, organize, timestamp, and validate all compliance evidence artifacts, ensuring each artifact is authentic, complete, traceable to its source, and fit for purpose before incorporation into any compliance package or attestation.", "threat": { "tags": [ "evidence-tampering", "incomplete-evidence", "chain-of-custody-failure", "stale-artifacts" ], "desc": "Untrusted, incomplete, or stale evidence artifacts undermine the validity of compliance attestations and expose the organization to adverse audit findings. Evidence that lacks provenance metadata or has an unverified chain of custody can be challenged by auditors or regulators. Fraudulent or manipulated artifacts submitted to auditors may constitute obstruction and trigger enforcement escalation beyond the original compliance matter, resulting in liability that far exceeds the underlying control gap." }, "standard": [ { "id": "iso_37301", "section": "\u00a77.5.3", "title": "Control of documented information" }, { "id": "soc2", "section": "CC2.2", "title": "Internal communication of information necessary for control function" }, { "id": "gdpr", "section": "Art. 5(2)", "title": "Accountability \u2014 demonstrability through maintained records" }, { "id": "cobit_2019", "section": "APO11", "title": "Managed Quality" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-02 Evidence Collection, Curation, and Validation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement an evidence repository with ingestion pipelines that automatically capture metadata \u2014 source system, collection timestamp, collector identity, artifact hash \u2014 at the moment of collection. Validation rules enforce completeness, format compliance, and freshness before artifacts are promoted to the active evidence library. Manual curation workflows handle artifacts that cannot be automatically validated.", "steps": [ "Define an artifact taxonomy for each applicable framework, specifying required evidence types, acceptable formats, mandatory metadata fields, and maximum staleness thresholds for each artifact type.", "Build or configure automated ingestion pipelines for high-volume evidence sources (log exports, policy attestations, scan results), capturing SHA-256 hash and collection timestamp at ingest without manual intervention.", "Implement a validation gate that checks completeness, format compliance, metadata presence, and freshness before promoting artifacts to the active evidence library; rejected artifacts route to a curation queue.", "Require manual validation and curator sign-off for artifacts that cannot be automatically validated, maintaining a documented review trail for each manually curated artifact.", "Run monthly reconciliation reports comparing the artifact inventory against framework requirements to identify collection gaps before they become examination findings." ], "compliance_officer": { "summary": "Evidence quality is the foundation of every audit outcome. You own the evidence taxonomy and validation standards \u2014 weak standards here propagate to every downstream attestation and multiply the risk of adverse examination findings.", "actions": [ "Define and publish the evidence taxonomy and quality standards for each applicable framework, reviewing annually or after any framework update.", "Review monthly reconciliation reports and escalate collection gaps exceeding 10% in any framework to the GRC committee.", "Approve the list of evidence sources authorized for automated ingestion." ], "metrics": [ "Evidence artifact validation pass rate: target \u226598%.", "Collection gap rate against framework requirements: target <5%.", "Percentage of artifacts with complete metadata (hash, timestamp, source): target 100%." ], "failure_signals": [ "Validation failures exceeding 5% of ingested artifacts for any framework.", "Artifacts promoted to the active library with missing provenance metadata.", "Reconciliation reports showing persistent collection gaps in the same control areas over consecutive months." ] }, "grc_auditor": { "summary": "Evidence quality directly determines audit efficiency and outcome. Assess whether artifacts are genuinely collected contemporaneously with the compliance activities they document, or assembled retrospectively in preparation for an examination.", "actions": [ "Inspect artifact ingestion timestamps and compare against the compliance activity periods they are intended to evidence.", "Sample 20% of artifacts and validate that computed SHA-256 hashes match the repository ingestion records.", "Review validation gate rejection logs to identify evidence quality patterns requiring systematic correction." ], "metrics": [ "Artifact hash integrity verification pass rate: target 100%.", "Percentage of artifacts with contemporaneous collection timestamps: target \u226595%.", "Validation gate rejection rate trend: target declining quarter-over-quarter." ], "failure_signals": [ "Artifact ingestion timestamps clustered retroactively around audit preparation periods.", "Hash mismatches between repository records and physical artifact content.", "Evidence sources ingesting into the repository without authorization entries." ] }, "it_operations": { "summary": "IT Operations is responsible for operating evidence ingestion pipelines and ensuring the technical infrastructure for evidence collection is reliable, auditable, and tamper-resistant. Pipeline reliability is a direct input to evidence validity.", "actions": [ "Deploy and maintain automated ingestion pipelines for all authorized evidence sources with monitoring for collection failures.", "Ensure ingestion infrastructure captures SHA-256 hashes and collection timestamps at ingest without manual intervention.", "Monitor pipeline health and alert on collection failures within 4 hours of occurrence." ], "failure_signals": [ "Ingestion pipeline failures going undetected for more than 4 hours.", "Hash computation errors or missing timestamps in ingestion records.", "Unauthorized evidence sources bypassing the ingestion pipeline and entering the repository through manual upload." ] }, "legal_counsel": { "summary": "Evidence chain of custody has direct legal implications. Collection procedures must satisfy evidentiary standards if artifacts may be required in regulatory proceedings or litigation, and retention periods must account for applicable statutes of limitation.", "actions": [ "Review evidence collection procedures for admissibility considerations in regulatory enforcement contexts relevant to each applicable regulatory regime.", "Confirm that retention periods for evidence artifacts align with applicable statutes of limitation and regulatory record-keeping obligations.", "Advise on handling of legally privileged artifacts within the evidence repository to prevent inadvertent disclosure." ], "failure_signals": [ "Evidence procedures lack documented chain of custody sufficient for regulatory submission purposes.", "Retention schedules that do not account for applicable statutes of limitation or regulatory hold requirements." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations collect evidence manually and ad hoc. Automated ingestion with hash-at-collection and validation gates is emerging best practice but not yet common across compliance teams." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "multi-tenant" ], "implementers": [ "Compliance Team", "GRC Operations", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a77.5.3", "fit": "direct", "rationale": "ISO 37301:2021 \u00a77.5.3 requires documented information to be controlled to ensure it remains available, suitable for use, and adequately protected. Automated evidence collection with hash capture, validation, and promotion gates directly satisfies this requirement by ensuring only valid, complete artifacts enter the active evidence library.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC2.2", "fit": "direct", "rationale": "SOC 2 CC2.2 requires communication of information necessary for control function. Evidence artifacts documenting control operation must be accurate and current to support service auditor reliance. Validation gates prevent stale or incomplete artifacts from misrepresenting control effectiveness.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "direct", "rationale": "GDPR accountability requires controllers to be able to demonstrate compliance with data protection principles at the time of any supervisory authority investigation. Evidence artifacts with verified provenance, hash integrity, and chain of custody are the practical mechanism for satisfying this obligation under examination.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "APO11.05", "fit": "direct", "rationale": "COBIT 2019 APO11.05 (Maintain continuous improvement) requires that quality-related data be collected and analysed to drive continuous improvement. Evidence quality validation ensures the compliance program produces reliable, auditable data for management review and external audit reliance across all applicable frameworks.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "iso_27001", "requirement_id": "A.5.33", "fit": "partial", "rationale": "ISO 27001:2022 A.5.33 addresses protection of records. Evidence artifacts containing sensitive compliance or security data must be protected from unauthorized modification, which is enforced by hash-at-collection and append-only repository controls.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 18", "fit": "partial", "rationale": "EU AI Act Article 18 requires providers of high-risk AI systems to draw up and keep technical documentation for inspection by competent authorities. Evidence collection and curation controls operationalize the ongoing maintenance of this documentation in a validated, retrievable form throughout the system lifecycle.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Control mapping", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's control mapping and evidence attachment features support the AU-02 Evidence Collection process by organizing compliance artifacts against specific framework control requirements, enabling structured collection workflows and completeness tracking within the Microsoft 365 ecosystem. Compliance Manager's improvement action evidence model implements a subset of the artifact taxonomy and validation workflow described in AU-02; however, AU-02 extends further to require cryptographic hash capture, automated ingestion pipelines, and append-only repository controls not natively provided by Compliance Manager.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS Artifact third-party audit reports \u2014 SOC 2 Type II, ISO 27001 certification letters, FedRAMP packages \u2014 are a defined evidence artifact class that must be systematically collected, timestamped, and curated under the AU-02 evidence management program. The artifact validation process in AU-02 \u2014 freshness thresholds tied to audit period end dates, provenance metadata, and completeness scoring \u2014 applies directly to AWS Artifact reports, which have defined validity windows (typically one year from the audit period end date) that must be tracked against each applicable framework's evidence refresh requirements.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "partial", "rationale": "Google Cloud certification documentation \u2014 including ISO 27001 certificates, SOC 2 Type II reports, PCI DSS attestations, and FedRAMP authorizations \u2014 are a specific evidence artifact class subject to the AU-02 evidence collection, curation, and validation requirements for GCP-hosted workloads. These artifacts have defined publication cadences and audit period windows that must be tracked within the AU-02 artifact taxonomy, including freshness thresholds, SHA-256 hash capture at ingest, and completeness validation before promotion to the active evidence library.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For AU-02, Anthropic's published Capability Report and Safeguards Report summaries and model documentation are vendor-layer evidence artifacts to be collected, validated, and curated for organizations deploying Anthropic systems in regulated contexts.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "OpenAI's Enterprise Data Processing Addendum creates mandatory evidence collection obligations \u2014 data processing activity records, subprocessor lists, and DPA compliance documentation \u2014 that must be systematically gathered and curated under the AU-02 evidence collection program for organizations using OpenAI services in regulated environments. These DPA artifacts have defined currency requirements and provenance requirements consistent with the AU-02 validation framework, as supervisory authorities may request them under GDPR Article 30 records of processing obligations or EU AI Act Article 18 technical documentation requirements.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance audit reporting generates identity governance evidence artifacts \u2014 access certification campaign records, segregation of duties enforcement logs, policy enforcement actions, and governance workflow completion records \u2014 that must be collected, validated, and curated under the AU-02 evidence program. These identity governance artifacts are required evidence for SOC 2 CC6 controls, ISO 27001 Annex A.9 controls, and GDPR Article 32 security of processing obligations, and must meet the AU-02 freshness thresholds, provenance metadata requirements, and hash-at-collection standards before promotion to the active evidence library.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "Every compliance evidence artifact in the active evidence library has a SHA-256 hash computed at the moment of collection, a documented source_system and collector_identity, a collection_timestamp within the required freshness window for its artifact type, and has passed all validation gate checks prior to promotion. No artifact with missing or failed provenance metadata exists in the active library.", "evidence_required": [ "Evidence repository ingestion log showing source_system, collector_identity, collection_timestamp, and SHA-256_hash computed at ingest for every artifact collected during the audit period", "Validation gate rejection log documenting all artifacts that failed validation checks, the specific failure reason (missing hash, staleness, format error, incomplete metadata), and their disposition", "Manual curation workflow records for artifacts that bypassed automated validation, including curator identity, review method, artifact authenticity basis, and sign-off timestamp", "Monthly reconciliation reports comparing the artifact inventory against per-framework requirements, identifying collection gaps by artifact type and their age in days", "SHA-256 hash integrity verification report for the audit period confirming no mismatches between ingestion records and current artifact content in the repository" ], "machine_tests": [ "Query evidence repository active library for artifacts where SHA256_hash IS NULL OR collection_timestamp IS NULL OR source_system IS NULL \u2192 assert 0 records", "Recompute SHA-256 hashes for a 20% random sample of active library artifacts and compare against ingestion records \u2192 assert 100% match with no discrepancies", "Query validation gate promotion log for records where validation_result = 'fail' AND status = 'promoted' \u2192 assert 0 records (no invalid artifacts promoted to active library)" ], "human_review": [ "Review manual curation workflow records to confirm curated artifacts received genuine authenticity and completeness review rather than administrative approval without source verification", "Analyze validation gate rejection patterns across source systems to identify systematic evidence quality issues requiring ingestion pipeline remediation rather than individual artifact rework", "Assess artifact freshness distribution against per-framework staleness thresholds to identify artifact types approaching expiry before the next scheduled collection cycle" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Collecting evidence artifacts by manual download and file upload without computing SHA-256 hashes at the point of collection, making post-collection tampering undetectable by any subsequent integrity verification", "Maintaining a mutable evidence repository without append-only or write-once controls, permitting artifact modification after initial validation without generating an audit trail of the change", "Ingesting artifacts from source systems without recording the source system identity and collector credentials in the ingestion record, destroying chain of custody and making provenance unverifiable under regulatory examination", "Auto-promoting artifacts through the validation gate without checking freshness against framework-specific staleness thresholds, allowing expired artifacts to persist in the active library undetected until an auditor requests them", "Treating vendor-provided compliance reports as pre-validated artifacts exempt from the standard ingestion pipeline, creating an undocumented exception class that bypasses hash capture and provenance metadata requirements" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-03", "layer": "AU", "plane": "control", "name": "Auditor Access and Cooperation Protocols", "plain": "The organization must define and implement documented procedures for providing regulators, notified bodies, and external auditors timely and appropriately scoped access to evidence, personnel, and systems, while protecting privileged information and maintaining a complete cooperation log for all examiner interactions.", "threat": { "tags": [ "auditor-obstruction", "unauthorized-disclosure", "access-scope-creep", "cooperation-failure" ], "desc": "Uncontrolled or undocumented auditor access creates dual risks: obstruction findings from inadequate cooperation, and unauthorized disclosure of sensitive data from over-broad access grants. Without defined protocols, individual employees may inadvertently disclose legally privileged information or provide inconsistent responses across multiple examiners. Regulators interpreting uncoordinated responses as evasion may escalate routine examinations to formal enforcement proceedings, transforming a manageable compliance matter into existential organizational risk." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.3", "title": "Management review" }, { "id": "gdpr", "section": "Art. 31", "title": "Cooperation with supervisory authority" }, { "id": "eu_ai_act", "section": "Art. 74", "title": "Market surveillance and control of AI systems" }, { "id": "soc2", "section": "CC2.3", "title": "External communication of relevant information to interested parties" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-03 Auditor Access and Cooperation Protocols control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-03 Auditor Access and Cooperation Protocols control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-03 Auditor Access and Cooperation Protocols control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish a central audit coordination function that controls all examiner communication, scopes access requests against a pre-approved framework, maintains a cooperation log, and routes requests to appropriate subject matter experts through defined escalation paths. All external communications involving compliance matters route through the designated audit coordinator.", "steps": [ "Designate an audit coordinator role (typically the Chief Compliance Officer or a qualified delegate) as the single point of contact for all regulatory and external audit interactions.", "Develop a written auditor access protocol defining response timelines by regulator type, access scoping procedures, document production workflows, and escalation paths for contested or over-broad requests.", "Implement a cooperation log capturing all examiner contacts, requests, responses, and document productions with timestamps, responsible parties, and disposition for each item.", "Train all employees likely to receive regulatory inquiries on the protocol, including the mandatory requirement to route all contact through the audit coordinator without exception.", "Conduct an annual simulation exercise testing response to an unannounced regulatory examination against the documented protocol and publish an after-action report." ], "compliance_officer": { "summary": "You are the primary interface with regulators and auditors. The protocol must achieve genuine cooperation while protecting legally privileged information and preventing inadvertent disclosure by employees who lack the context to scope responses appropriately.", "actions": [ "Own and maintain the auditor access protocol, reviewing annually or after any significant regulatory contact that surfaces gaps.", "Personally review or approve all document productions to external parties before transmittal.", "Maintain the cooperation log and report quarterly to legal counsel and executive leadership." ], "metrics": [ "Protocol response deadline compliance rate: target 100%.", "Cooperation log completeness: all examiner contacts logged within 24 hours of occurrence.", "Annual simulation exercise completion: target 100%." ], "failure_signals": [ "Regulatory contacts occurring outside the defined audit coordinator channel.", "Document productions transmitted without prior compliance officer review and approval.", "Response deadline misses against any regulatory commitment." ] }, "legal_counsel": { "summary": "Auditor access protocols have significant legal dimensions including attorney-client privilege, work product protection, and the legal consequences of inadequate cooperation. Legal sign-off is required before any contested access request is refused or any document production is released.", "actions": [ "Draft and review the auditor access protocol to ensure privilege protections are adequately incorporated for all applicable regulatory regimes.", "Advise on each document production request to identify potentially privileged materials before release.", "Provide legal guidance on cooperation obligations versus legally contestable requests for each applicable regulatory authority." ], "failure_signals": [ "Privileged materials produced to regulators without prior legal review.", "Employees responding to regulatory requests without routing through the audit coordinator.", "Protocol that fails to distinguish between routine audit requests and formal enforcement inquiries." ] }, "grc_auditor": { "summary": "The cooperation log is the primary audit artifact for this control. Assess whether all examiner contacts are documented, whether access was appropriately scoped, and whether the protocol was followed consistently across all examination interactions.", "actions": [ "Review the cooperation log for completeness against all known regulatory examination periods.", "Assess whether document productions were reviewed and approved prior to release in accordance with protocol.", "Verify that employees received protocol training and that training records are current and complete." ], "metrics": [ "Cooperation log completeness rate: target 100% of known regulatory contacts documented.", "Protocol training completion rate: target 100% of in-scope personnel annually.", "Document production approval compliance rate: target 100%." ], "failure_signals": [ "Gaps in the cooperation log during known examination periods.", "Undocumented or informal regulatory contacts discovered through other review channels.", "Training completion rates below 95% for personnel likely to receive regulatory inquiries." ] }, "executive": { "summary": "Regulatory examination outcomes depend significantly on the quality of cooperation protocols. Senior leadership visibility ensures adequate resourcing and sets the organizational tone for genuine cooperation as a matter of corporate culture.", "actions": [ "Receive a summary briefing before any significant regulatory examination commences.", "Sponsor the annual simulation exercise and review the after-action report.", "Approve the auditor access protocol and any material amendments." ], "failure_signals": [ "Regulatory escalations occurring without prior executive awareness.", "Examination response resources insufficient to meet regulatory response deadlines.", "Protocol not reviewed or updated in more than 24 months." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many organizations lack formal auditor access protocols and rely on ad hoc responses to regulatory contact. Defined protocols with a central coordinator, scoped access procedures, and a cooperation log represent a significant maturity improvement." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Compliance Team", "Legal Counsel", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.3.2", "fit": "partial", "rationale": "ISO 37301:2021 \u00a79.3.2 requires management review inputs to include information on compliance performance, nonconformities, and relevant feedback from interested parties. Formal cooperation protocols create the documented record of regulator and external auditor interactions that feeds this management review input.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 31", "fit": "direct", "rationale": "GDPR Article 31 imposes a mandatory obligation to cooperate with the supervisory authority on request. Defined cooperation protocols operationalize this legal obligation while managing the dual risk of inadequate cooperation findings and over-broad disclosure through scoped access procedures and legal review requirements.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 74(12)\u2013(13)", "fit": "direct", "rationale": "EU AI Act Article 74(12) requires operators to grant market surveillance authorities full access to the documentation and to the training, validation and testing data sets used for the development of high-risk AI systems, and Article 74(13) provides for access to source code upon reasoned request. The cooperation protocol implements the structured response to these EU AI Act examination powers, including documentation access procedures, expert designation, and production workflows.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC2.3", "fit": "partial", "rationale": "SOC 2 CC2.3 addresses external communication with parties who need information about the system. The auditor access protocol manages the critical external communication channel with service auditors and notified bodies, providing a controlled framework for sharing compliance information.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03.04", "fit": "partial", "rationale": "COBIT 2019 MEA03.04 (Obtain assurance of external compliance) entails managed engagement with the external assurance providers and authorities performing that assessment. Defined cooperation protocols implement the structured external engagement mechanism, ensuring regulatory interactions are documented, scoped, and managed through an accountable coordination function.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "adjacent", "rationale": "Microsoft Purview Compliance Manager assessment exports and compliance score reports are a primary category of documentation produced to auditors and regulators during examinations of Microsoft 365 and Azure-hosted workloads. The AU-03 Auditor Access and Cooperation Protocols must define how Compliance Manager assessment reports are scoped, retrieved, and formally produced to examiners under the document production workflow, ensuring these outputs are included in the cooperation log and reviewed by the audit coordinator before transmittal.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Artifact agreement", "fit": "adjacent", "rationale": "AWS Artifact's artifact agreement mechanism provides NDA-bound access to AWS compliance reports for auditors and regulators, creating a defined channel through which third-party examiners can access cloud compliance evidence. The AU-03 Auditor Access and Cooperation Protocols must incorporate AWS Artifact access grant procedures into the document production workflow and cooperation log so that examiner access to AWS compliance reports is documented, scoped appropriately, and tracked as part of the formal production record.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access Requests", "fit": "partial", "rationale": "Okta Identity Governance's Access Requests provides time-bound, approval-gated access grants with a complete request-and-approval audit trail. AU-03's auditor access protocols apply the same pattern to external examiner access: scoped grants, documented approvals, and automatic expiry.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "All regulatory and external auditor interactions during the audit period are logged in the cooperation register within 24 hours of occurrence, every document production was reviewed and approved by the audit coordinator before transmittal, and no regulatory response deadline was missed. The auditor access protocol has been reviewed within the prior 24 months and all personnel in roles likely to receive regulatory inquiries hold current training records.", "evidence_required": [ "Cooperation register for the audit period listing every examiner contact with contact_date, regulator_identity, contact_type, request_description, response_deadline, response_submitted_date, and document_production_id for each production made", "Document production approval log showing audit coordinator and legal counsel pre-transmittal sign-off timestamp for each document set produced to examiners during the period", "Annual simulation exercise report documenting scenario design, participants, findings, and after-action remediation items for the exercise conducted in the review year", "Protocol training completion records for all personnel in roles likely to receive direct regulatory inquiry, showing completion within the prior 12 months", "Auditor system access provisioning records for any system access granted to examiners, including access_scope, provisioning_date, provisioning_authority, and access_revocation_date" ], "machine_tests": [ "Query cooperation register for contacts where log_entry_timestamp > (contact_date + 1 business day) \u2192 assert 0 records (all contacts logged within 24 hours)", "Query document production log for productions without a pre-transmittal audit_coordinator_approval_record \u2192 assert 0 unapproved productions", "Query protocol training records for personnel in regulated roles \u2192 assert 0 active in-scope personnel with last_completion_date > (today - 365 days)" ], "human_review": [ "Review a sample of cooperation register entries against known examination correspondence to assess whether informal interactions (phone calls, in-person conversations) were captured or whether only written contacts were logged", "Assess document productions for appropriate scope by reviewing produced sets against request descriptions to verify materials were limited to requested items and potentially privileged content received legal review before inclusion", "Evaluate the annual simulation exercise after-action report for realism, confirming the scenario tested an unannounced examination response rather than a pre-scripted walkthrough of a known procedure" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Permitting employees to respond directly to regulatory inquiries without routing through the designated audit coordinator, generating inconsistent responses across multiple examiners that regulators may interpret as evasion", "Logging examiner contacts in email threads or personal notes rather than a centralized cooperation register, making it impossible to produce a complete cooperation history if a regulator requests all examination correspondence records", "Granting examiners broad system access beyond the requested scope without documenting the access grant and revocation, creating unauthorized disclosure risk and a governance failure auditable in subsequent engagements", "Producing documents to regulators without prior legal review for privilege, submitting attorney-client privileged materials that permanently waive privilege over sensitive compliance strategy communications", "Failing to revoke examiner system access credentials at the conclusion of an examination, leaving persistent access that constitutes both a security control failure and a scope-management deficiency" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-04", "layer": "AU", "plane": "data", "name": "Audit Trail Integrity", "plain": "The organization must maintain tamper-evident audit logs for all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 with cryptographic integrity verification and documented chain of custody ensuring log authenticity can be verified at any point during the retention period.", "threat": { "tags": [ "log-tampering", "chain-of-custody-failure", "evidence-destruction", "insider-manipulation" ], "desc": "Mutable compliance audit logs are vulnerable to insider modification following adverse events, destroying the evidentiary record needed to demonstrate control operation. Attackers with access to compliance systems who anticipate regulatory scrutiny may purge or alter logs to conceal control failures. Jurisdictions with mandatory breach notification or regulatory reporting obligations treat log destruction as an independent aggravated violation, significantly increasing penalties beyond the original compliance matter." }, "standard": [ { "id": "iso_27001", "section": "A.8.15", "title": "Logging \u2014 protection of log information" }, { "id": "soc2", "section": "CC7.2", "title": "Monitoring of system components for anomalous behavior" }, { "id": "gdpr", "section": "Art. 5(1)(f)", "title": "Integrity and confidentiality of personal data" }, { "id": "eu_ai_act", "section": "Art. 12", "title": "Record-keeping for high-risk AI systems" } ], "sources": [ { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-04 Audit Trail Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/AU-04 Audit Trail Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-04 Audit Trail Integrity control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-04 Audit Trail Integrity control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Deploy append-only log storage with cryptographic chaining for compliance program activity logs. Each log batch is hashed and the hash incorporated into the next batch, creating a tamper-evident chain. Logs are replicated to an immutable secondary store within 60 seconds of generation. Log integrity is verified on a daily schedule and any chain break or gap triggers immediate alert.", "steps": [ "Identify all compliance program systems generating audit-relevant events and configure them to emit structured log records (JSON with defined schema) to a centralized log aggregation pipeline.", "Deploy an append-only log store with cryptographic chaining; each log batch is hashed and the hash incorporated into the subsequent batch header to create a tamper-evident sequence.", "Replicate logs to an immutable secondary store (WORM object storage or a separate cloud account with object lock enabled) within 60 seconds of generation to prevent local tampering before replication.", "Run automated integrity verification daily, computing hash chains against the stored records and alerting on any break, gap, or hash mismatch within 1 hour of detection.", "Maintain a log custody register documenting all personnel with access to log infrastructure, with quarterly access reviews and removal of unnecessary permissions." ], "compliance_officer": { "summary": "Audit trail integrity is the foundation of your ability to reconstruct the compliance program's historical operation under examination. Any gap or break in the audit trail is a material control deficiency that must be investigated and reported immediately.", "actions": [ "Require IT Operations to report any audit trail integrity alert to the compliance officer within 1 hour of detection.", "Review the log custody register quarterly and approve access removals for personnel who no longer require access.", "Include audit trail integrity verification status in quarterly GRC committee reporting." ], "metrics": [ "Log integrity verification pass rate: target 100% on daily verification cadence.", "Time-to-alert on integrity break: target <1 hour from detection.", "Log custody register review completion: target 100% quarterly." ], "failure_signals": [ "Any log integrity break not investigated and resolved within 24 hours.", "Log gaps discovered during examination that were not detected by automated daily verification.", "Access to log infrastructure not reviewed in more than 90 days." ] }, "grc_auditor": { "summary": "Audit trail integrity is a prerequisite for reliance on any compliance evidence. Independently verify the cryptographic chain and check for evidence of retroactive modification before relying on log-based evidence.", "actions": [ "Request the cryptographic hash chain for compliance logs covering the audit period and perform independent hash chain verification.", "Confirm immutable secondary store timestamps against primary log timestamps to verify timely replication occurred throughout the audit period.", "Review the log custody register and access log for any unauthorized modifications to log infrastructure during the audit period." ], "metrics": [ "Cryptographic chain verification pass rate: target 100%.", "Primary-to-secondary replication latency compliance: target <60 seconds for \u226599.9% of log batches.", "Unauthorized log infrastructure access incidents: target zero." ], "failure_signals": [ "Hash chain breaks or unexplained gaps during the audit period.", "Primary and secondary log stores with inconsistent content for the same time period.", "Log infrastructure access occurring outside approved change windows without documented justification." ] }, "it_operations": { "summary": "You are responsible for operating the tamper-evident log infrastructure. The integrity of this system is foundational to the organization's ability to defend its compliance posture under regulatory examination and litigation.", "actions": [ "Operate and maintain append-only log stores with cryptographic chaining for all compliance-relevant system categories.", "Ensure replication to immutable secondary storage occurs within 60 seconds and monitor replication pipeline health continuously.", "Run and report on daily automated integrity verification, escalating any failure to the compliance officer within 1 hour." ], "failure_signals": [ "Replication latency exceeding 60 seconds for more than 0.1% of log batches.", "Integrity verification failures not escalated within the defined 1-hour SLA.", "Append-only constraints bypassed for any reason without documented emergency change control." ] }, "legal_counsel": { "summary": "Tamper-evident audit trails are critical for regulatory defense and litigation. Log integrity directly affects the admissibility and weight of compliance evidence in enforcement proceedings and determines whether the organization can reconstruct its compliance posture for any historical period.", "actions": [ "Advise on log retention periods required by each applicable regulatory regime and ensure retention configurations reflect the longest applicable period.", "Review log custody procedures to ensure they satisfy evidentiary standards for potential regulatory submissions.", "Issue litigation holds explicitly covering compliance audit logs whenever enforcement risk is identified." ], "failure_signals": [ "Log retention periods not aligned with the longest applicable regulatory or litigation hold requirement.", "Compliance logs destroyed before a litigation hold was issued when enforcement risk was foreseeable." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain mutable log stores without cryptographic integrity verification. WORM storage and cryptographic chaining for compliance program logs is emerging enterprise practice beyond regulated financial services." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "eu-high-risk-ai" ], "implementers": [ "IT Operations", "Platform Engineering", "Compliance Team" ], "frameworks": [ { "framework": "iso_27001", "requirement_id": "A.8.15", "fit": "direct", "rationale": "ISO 27001:2022 A.8.15 requires logging of activities and protection of log facilities against modification and unauthorized access. Cryptographic chaining and append-only storage directly implement the tamper protection requirement for compliance audit logs containing sensitive control operation records.", "normative_force": "certification-standard", "source_version": "2022", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC7.2", "fit": "direct", "rationale": "SOC 2 CC7.2 requires monitoring of system components to detect anomalous behavior that could indicate a security or control failure. Automated integrity verification of the cryptographic hash chain implements continuous anomaly detection for compliance log tampering, including detection of subtle retroactive modifications.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 5(1)(f)", "fit": "partial", "rationale": "GDPR Article 5(1)(f) requires appropriate security for personal data including protection against unauthorized alteration. Compliance audit trails that contain records of personal data processing activities \u2014 including consent records, access logs, and DSAR responses \u2014 are subject to this integrity requirement.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 12", "fit": "direct", "rationale": "EU AI Act Article 12 requires high-risk AI systems to automatically generate logs to enable traceability and monitoring. Tamper-evident audit trail controls ensure these mandatory logs are protected from modification and retain their evidentiary value for market surveillance authority review throughout the required retention period.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "DSS06.03", "fit": "partial", "rationale": "COBIT 2019 DSS06.03 addresses managing roles, responsibilities, access privileges, and levels of authority for business process controls. The log custody register and quarterly access review process operationalize this control for compliance audit trail infrastructure specifically.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "PR.DS-01", "fit": "partial", "rationale": "NIST CSF 2.0 PR.DS-01 requires that the confidentiality, integrity, and availability of data-at-rest are protected. Cryptographic chaining and WORM storage implement continuous integrity protection for compliance audit data at rest throughout its retention period.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "partial", "rationale": "AWS SOC 2 Type II reports available through AWS Artifact include independent third-party verification of AWS CloudTrail integrity controls, S3 Object Lock WORM storage implementations, and log protection mechanisms. For organizations with compliance audit logs stored on AWS infrastructure, these SOC 2 reports provide third-party assurance that the cloud-layer log storage platform satisfies AU-04 tamper-evidence requirements at the provider layer, complementing the organization's own cryptographic chaining controls and serving as evidence in the AU-04 log custody register.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "partial", "rationale": "Google Cloud's shared responsibility matrix and compliance documentation define GCP's responsibilities for audit log integrity, Cloud Storage object lock (WORM) controls, and Cloud Audit Logs immutability for GCP-hosted workloads. Organizations storing compliance audit logs on GCP must incorporate Google's shared responsibility documentation into the AU-04 audit trail integrity program to demonstrate that cloud-layer log protection satisfies the tamper-evidence requirement, particularly for immutable secondary replication and the append-only log store described in AU-04.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance maintains system event logs for all identity governance decisions \u2014 access certifications, policy enforcement actions, provisioning changes, and role assignments \u2014 that are a critical component of the compliance audit trail covered by AU-04. These Okta governance event logs must be integrated into the organization's tamper-evident log custody framework with cryptographic integrity verification, as they constitute compliance evidence subject to the AU-04 requirement that audit trail integrity be verifiable at any point during the retention period.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "adjacent", "rationale": "Microsoft Purview Compliance Manager maintains activity logs of all compliance assessment actions \u2014 score changes, evidence uploads, improvement action updates, and reviewer approvals \u2014 within the Microsoft 365 audit log infrastructure. These Compliance Manager audit events are subject to the AU-04 tamper-evidence requirements when they form part of the compliance program's audit trail, and organizations must ensure Microsoft 365 Compliance Manager activity logs are included in the log custody register and integrated into the integrity verification scope.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The audit log system must maintain a cryptographically chained, append-only record of all compliance program activities \u2014 including policy attestations, control assessments, evidence submissions, and configuration changes \u2014 such that any attempt to modify, delete, or insert log records is detectable within 24 hours of occurrence. Automated daily hash chain verification must confirm log integrity continuously and alert the compliance officer within 1 hour of any detected break.", "evidence_required": [ "cryptographic_hash_chain_report listing hash values for each log batch and chain linkage between successive batches, covering the full audit period with no unexplained gaps", "WORM_storage_replication_log confirming each log batch was replicated to immutable secondary store within 60 seconds, with source generation timestamp and secondary write timestamp for each batch", "daily_integrity_verification_report showing automated hash chain verification results, detected breaks, and alert dispatch timestamps for each verification run in the last 30 days", "log_custody_register documenting all personnel with access to log infrastructure, last quarterly access review date, and access removal records for personnel no longer requiring access", "log_gap_analysis_report confirming no unexplained gaps in log sequence numbers or timestamps for the audit period" ], "machine_tests": [ "Attempt to modify a compliance log record directly via the log store API \u2192 assert HTTP 403 or equivalent rejection and detection of unauthorized access attempt in the integrity monitoring alert queue", "Insert a backdated log record with timestamp 30 days prior into the log sequence \u2192 assert hash chain verification detects the chain break and generates a compliance officer alert within the configured verification window", "Stop log replication pipeline for 90 seconds \u2192 assert lag monitoring system generates an alert before the 120-second replication SLA threshold", "Query the most recent integrity verification job result \u2192 assert execution timestamp is within 25 hours and result is PASS with hash counts matching expected log batch count for the period" ], "human_review": [ "Review the log custody register and confirm all access permissions are justified by current role assignments, that quarterly access reviews were completed, and that access was removed for any personnel who changed roles or departed", "Assess the integrity verification failure response procedure to confirm that any hash chain break triggers compliance officer notification within the 1-hour SLA and that the escalation path is documented and tested", "Verify that the immutable secondary store is governed by a separate administrative domain from the primary log store, preventing a single insider compromise from tampering with both the primary and secondary records simultaneously" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Storing compliance audit logs in mutable databases or cloud buckets without object lock enabled, permitting silent retroactive deletion or modification by privileged insiders without triggering integrity alerts", "Running daily integrity verification but routing alerts to the security team rather than the compliance officer, creating a response gap where enforcement action may proceed without compliance awareness of evidence loss", "Relying on a single log repository without an immutable secondary store in a separate administrative domain, leaving the entire audit trail vulnerable to a single infrastructure compromise or insider with elevated access", "Configuring log retention to the shortest applicable regulatory period without identifying the longest applicable period across all jurisdictions and litigation hold obligations, causing premature destruction of records subject to longer hold requirements", "Treating integrity verification failures as low-priority security tickets rather than immediate compliance escalation items, allowing the compliance team to remain unaware of potential evidentiary loss during regulatory examinations" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-05", "layer": "AU", "plane": "lifecycle", "name": "Regulatory Examination Response Program", "plain": "The organization must maintain documented procedures for responding to regulatory inquiries, examinations, and enforcement actions, covering intake triage, response team activation, document production workflow, regulator communication management, and post-examination review to capture lessons learned.", "threat": { "tags": [ "regulatory-enforcement", "examination-escalation", "inadequate-response", "privilege-waiver" ], "desc": "Uncoordinated responses to regulatory inquiries increase the likelihood of inadvertent admissions, privilege waivers, and inconsistent position-taking across multiple simultaneous examinations. Failure to meet response deadlines is itself a regulatory violation in many jurisdictions. Absent a defined response program, organizations frequently provide over-broad document productions that expand the scope of the original inquiry, creating self-inflicted examination scope creep that escalates manageable compliance matters into existential enterprise risk." }, "standard": [ { "id": "iso_37301", "section": "\u00a710.2", "title": "Nonconformity and corrective action \u2014 regulatory response context" }, { "id": "gdpr", "section": "Art. 31", "title": "Cooperation with supervisory authority" }, { "id": "eu_ai_act", "section": "Art. 74", "title": "Market surveillance authority cooperation" }, { "id": "cobit_2019", "section": "MEA03", "title": "Managed External Compliance Requirements" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-05 Regulatory Examination Response Program control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-05 Regulatory Examination Response Program control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/AU-05 Regulatory Examination Response Program control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/AU-05 Regulatory Examination Response Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a tiered response protocol that classifies regulatory contacts by type and risk level, activates appropriate response teams with defined roles, manages all external communications through a single channel, and produces post-examination after-action reports to improve future response quality.", "steps": [ "Develop a regulatory examination response playbook defining triage criteria for classifying inquiries (routine information request, examination, formal investigation, enforcement action) with corresponding response team composition and escalation paths for each tier.", "Establish a regulatory response team with defined roles: response coordinator, legal counsel lead, subject matter expert pool, document production manager, and executive sponsor.", "Define document production workflows including legal privilege review, scoping analysis, production log, and transmittal documentation required for every document production to any regulatory body.", "Create regulator-specific response guides for each material regulatory relationship, including applicable statutory deadlines, preferred communication formats, and jurisdictional cooperation obligations.", "Conduct post-examination after-action reviews within 30 days of examination closure, documenting lessons learned and updating the response playbook with identified improvements." ], "compliance_officer": { "summary": "Regulatory examination response is a cross-functional program requiring coordination across compliance, legal, IT, and executive functions. Undefined response procedures are among the most common preventable causes of examination escalations \u2014 the organization's response posture frequently determines outcome more than the underlying compliance position.", "actions": [ "Own and maintain the regulatory examination response playbook, updating after each examination and annually as a minimum.", "Serve as response coordinator for all examinations unless formally delegated to a qualified deputy.", "Report to executive leadership within 24 hours of any formal examination or enforcement notification." ], "metrics": [ "Regulatory response deadline compliance rate: target 100%.", "Post-examination after-action review completion rate: target 100% within 30 days of closure.", "Playbook currency: reviewed and updated within 12 months." ], "failure_signals": [ "Any missed regulatory response deadline regardless of cause.", "Post-examination review not completed within 30 days of examination closure.", "Playbook last updated more than 12 months ago." ] }, "legal_counsel": { "summary": "Legal counsel is essential to managing privilege, scoping productions, and advising on jurisdictional cooperation obligations. Every formal examination must have assigned legal counsel with a defined, written role in the response team before any response is submitted.", "actions": [ "Provide legal review of all document productions before transmittal to any regulatory authority.", "Advise on the scope of cooperation obligations versus legally contestable requests for each applicable regulator.", "Maintain a regulatory relationship register documenting all active and historical regulatory interactions and applicable deadlines." ], "failure_signals": [ "Document productions transmitted without prior legal review.", "Legal counsel not engaged until after the first regulatory response has already been submitted.", "No documented legal position on cooperation obligations for material regulatory relationships." ] }, "grc_auditor": { "summary": "The regulatory examination response program is a control in its own right. Assess whether procedures are documented, followed consistently, and produce defensible outcomes \u2014 not only whether examinations ultimately resulted in no adverse findings.", "actions": [ "Review the response playbook for completeness against the organization's current regulatory exposure profile.", "Sample recent regulatory responses and verify adherence to documented procedures at each stage.", "Review post-examination after-action reports and assess whether identified improvements were implemented within committed timeframes." ], "metrics": [ "Response playbook coverage of material regulatory relationships: target 100%.", "Procedure adherence rate for sampled regulatory responses: target \u226595%.", "After-action improvement implementation rate: target \u226590% within 90 days of after-action completion." ], "failure_signals": [ "Playbook that does not cover all material regulatory relationships.", "Examination responses that deviated from documented procedure without a recorded justification.", "After-action recommendations not implemented within committed timeframes." ] }, "executive": { "summary": "Regulatory examination outcomes are enterprise-level risk matters. Executive sponsorship ensures adequate resourcing and signals the organization's commitment to genuine regulatory cooperation as a governance priority.", "actions": [ "Receive notification within 24 hours of any formal examination or enforcement notification.", "Approve the regulatory examination response playbook and any material amendments.", "Review post-examination after-action summaries and sponsor improvement programs where systemic issues are identified." ], "failure_signals": [ "Examinations escalating to enforcement without prior executive awareness.", "Inadequate resourcing causing regulatory response deadline misses.", "Systemic examination failures recurring without an executive-sponsored remediation program." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations respond to regulatory examinations reactively without formal programs. Defined response teams with tiered playbooks, after-action reviews, and regulator-specific guides represent a significant maturity improvement." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Legal Counsel", "Compliance Team", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a710.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a710.2 requires organizations to take corrective action when compliance nonconformities occur and evaluate the need to update compliance risks. Formal examination response procedures operationalize the structured organizational response when regulators identify or allege compliance nonconformities.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "gdpr", "requirement_id": "Art. 31", "fit": "direct", "rationale": "GDPR Article 31 requires controllers to cooperate with supervisory authorities on request. The examination response program operationalizes this legal obligation by defining how cooperation is structured, documented, and managed to demonstrate genuine compliance with the duty to cooperate under investigation.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art. 74(12)\u2013(13)", "fit": "direct", "rationale": "EU AI Act Article 74(12)\u2013(13) grants market surveillance authorities access to the documentation, data sets, and \u2014 upon reasoned request \u2014 source code of high-risk AI systems. The regulatory examination response program provides the operational framework for managing EU AI Act examinations under these access powers with appropriate scoping and privilege protection.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA03.04", "fit": "direct", "rationale": "COBIT 2019 MEA03.04 (Obtain assurance of external compliance) entails engaging with external assurance providers and regulators in a managed way. The examination response program implements the structured external engagement mechanism with defined roles, escalation paths, and coordination requirements.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 10", "fit": "partial", "rationale": "COSO ERM 2017 Principle 10 (Identifies Risk) requires the organization to identify risks to strategy and business objectives. Regulatory examination and enforcement actions are among the most significant enterprise risks that the response program is designed to mitigate through defined procedures and preparation.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager assessment reports and current compliance scores are key documentation produced to regulators during examinations covering ISO 27001, SOC 2, GDPR, and EU AI Act obligations managed within Compliance Manager. The AU-05 Regulatory Examination Response Program's document production workflow must include procedures for exporting and producing Compliance Manager assessment reports within applicable response deadlines, ensuring the response team can identify which assessment outputs are responsive to each regulatory inquiry type and retrieve them without delay.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact compliance reports \u2014 SOC 1/2/3, ISO 27001, FedRAMP, HIPAA, and PCI DSS attestations \u2014 are first-response documents in regulatory examinations of cloud infrastructure compliance and must be incorporated into the AU-05 Regulatory Examination Response Program's document production workflow. The response program must include regulator-specific procedures for identifying which AWS Artifact reports are responsive to each examination inquiry, retrieving current versions on demand, and producing them within applicable regulatory response deadlines without emergency manual retrieval.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. In a regulatory examination touching Anthropic-based systems, the response program should be able to produce the provider's published safety framework documentation \u2014 the RSP and its Required Safeguards \u2014 alongside the Usage Policy and commercial terms that define the enterprise's own obligations.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Trust Portal", "fit": "adjacent", "rationale": "OpenAI's Trust Portal provides on-demand access to the vendor's audit reports and compliance documentation. A regulatory examination response program must be able to produce vendor-layer compliance evidence for AI services in scope, and the Trust Portal is the documented retrieval channel for OpenAI-dependent deployments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must have a documented, tested examination response program with a current regulatory playbook, a defined response team with assigned roles and named deputies, and regulator-specific response guides for each material regulatory relationship, such that any formal regulatory inquiry is triaged within 4 business hours and a response team with appropriate legal representation is activated within 24 hours of receipt. Zero regulatory response deadlines may be missed.", "evidence_required": [ "regulatory_examination_response_playbook with version date within the last 12 months, documented tier classification criteria (routine, examination, investigation, enforcement), and response team activation procedures for each tier", "response_team_roster documenting all designated team members by role (response coordinator, legal counsel lead, SME pool, document production manager, executive sponsor) with named deputies and current contact information", "document_production_log from all regulatory responses in the last 24 months confirming legal privilege review, scoping analysis, and production transmittal documentation were completed for each production", "post_examination_after_action_report for each examination closed in the last 24 months, completed within 30 days of closure and showing lessons-learned implementation status and playbook update record", "regulatory_response_deadline_compliance_record listing all response deadlines and submission dates for the last 24 months, confirming zero missed deadlines" ], "machine_tests": [ "Submit a simulated regulatory inquiry notification to the response intake process \u2192 assert intake is logged, triage classification is assigned, and response coordinator notification is generated within 4 business hours", "Query the playbook version timestamp and last review date \u2192 assert the playbook was reviewed and updated within the last 12 months", "Check post-examination after-action reports for all examinations closed in the last 24 months \u2192 assert 100% of reports were completed within 30 days of examination closure" ], "human_review": [ "Review a sample of regulatory response submissions and trace each through the documented procedure, verifying that legal counsel approval was obtained and documented before each document production", "Interview the designated response coordinator to assess whether they can activate the full response team without relying on undocumented institutional knowledge and are familiar with the playbook tier classification criteria", "Evaluate the regulator-specific response guides for coverage of all material regulatory relationships and verify that statutory response deadlines are accurately reflected and that regulator-preferred communication channels are documented" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Responding to formal regulatory examinations with ad hoc teams assembled after receipt rather than activating a pre-defined response team, causing coordination delays and role confusion that increase the risk of missing statutory response deadlines", "Producing documents to a regulatory authority without prior legal privilege review, inadvertently waiving attorney-client privilege over sensitive compliance communications and creating evidentiary exposure that expands the examination scope", "Treating all regulatory contacts as equivalent without tiered classification, causing over-resource allocation to routine information requests while under-resourcing formal examinations or enforcement actions that require executive awareness", "Failing to conduct post-examination after-action reviews within 30 days of closure, forfeiting the institutional learning that would prevent the same procedural errors \u2014 including deadline misses and over-broad document productions \u2014 from recurring in subsequent examinations", "Maintaining a single examination response playbook without regulator-specific guides, creating gaps in procedure coverage for regulators with unique statutory deadlines, jurisdictional cooperation obligations, or preferred communication format requirements" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-06", "layer": "AU", "plane": "lifecycle", "name": "Audit Finding Remediation Program", "plain": "The organization must systematically address findings from regulators, notified bodies, internal auditors, and external auditors through a formal remediation program that tracks findings to verified closure, conducts root-cause analysis for repeat and critical items, validates remediation effectiveness through independent confirmation, and escalates systemic patterns for executive review.", "threat": { "tags": [ "unresolved-findings", "repeat-deficiencies", "remediation-drift", "systemic-noncompliance" ], "desc": "Audit findings not tracked to independently verified closure create persistent compliance gaps that compound over time and signal to regulators a compliance program that is nominally compliant but operationally ineffective. Repeat findings in the same control area across successive audit cycles are treated by regulators as evidence of systemic noncompliance, elevating enforcement risk beyond any individual finding. Superficial remediation that addresses the symptom without the root cause produces findings that formally close but reopen in the next audit cycle, undermining examiner confidence in the organization's compliance posture." }, "standard": [ { "id": "iso_37301", "section": "\u00a710.2", "title": "Nonconformity and corrective action" }, { "id": "soc2", "section": "CC4.2", "title": "Evaluation and communication of identified deficiencies" }, { "id": "cobit_2019", "section": "MEA02.04", "title": "Identify and report control deficiencies" }, { "id": "coso_erm", "section": "Principle 17", "title": "Pursues Improvement in ERM" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-06 Audit Finding Remediation Program control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-06 Audit Finding Remediation Program control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Maintain a centralized finding register tracking all audit findings from all sources to independently verified closure. Each finding record contains root-cause classification, corrective action plan, responsible owner, target close date, verification method, and verification evidence. Findings are reported to the GRC committee monthly with aging analysis, and repeat findings trigger mandatory root-cause analysis before a corrective action plan is approved.", "steps": [ "Deploy a centralized finding register capturing findings from internal audits, external audits, regulatory examinations, and self-assessments, with standardized fields for severity, root-cause category, corrective action plan, owner, target date, verification method, and status.", "Implement a finding severity classification scheme (critical, high, medium, low) with corresponding maximum remediation timelines and escalation requirements for overdue items at each severity level.", "Require documented root-cause analysis for all critical and high findings before a corrective action plan is approved, and for any finding that recurs in the same control area within 24 months.", "Define verification requirements specifying that corrective actions are independently verified (by internal audit, GRC, or an independent reviewer) with verification evidence attached to the finding record before formal closure.", "Produce monthly aging reports for the GRC committee showing open finding counts by severity, owner, and source, with automatic escalation of overdue critical findings to executive leadership." ], "compliance_officer": { "summary": "Finding remediation is where the compliance program demonstrates its operational capacity to improve. A finding register that grows without verified closures signals a broken remediation process to every examiner who requests it \u2014 and they all do.", "actions": [ "Own the finding register and ensure all findings are entered within 5 business days of identification.", "Review the monthly aging report and escalate overdue critical and high findings to the GRC committee and executive leadership.", "Approve corrective action plans for all critical findings before remediation commences." ], "metrics": [ "Critical finding close rate within defined SLA: target 100%.", "High finding close rate within defined SLA: target \u226595%.", "Repeat finding rate (same control area, within 24 months): target <10%." ], "failure_signals": [ "Any critical finding open beyond the defined SLA without documented escalation and executive awareness.", "Repeat findings in the same control area in successive audit cycles.", "Finding register entries without corrective action plans, assigned owners, or target close dates." ] }, "grc_auditor": { "summary": "The finding register is the primary artifact for assessing remediation program effectiveness. Assess finding aging trends, verification quality, and repeat finding patterns \u2014 not just whether individual findings are marked closed.", "actions": [ "Review the finding register for completeness against all known audit, examination, and self-assessment activities for the audit period.", "Sample 25% of closed findings and verify that closure evidence demonstrates actual remediation rather than procedural close-out without substantive change.", "Analyze repeat finding patterns and assess whether root-cause analyses address systemic issues or only proximate causes." ], "metrics": [ "Finding register completeness: target 100% of known findings captured.", "Independently verified closure rate: target \u226595% of closed findings with verification evidence attached.", "Repeat finding rate over rolling 24-month window: target <10%." ], "failure_signals": [ "Findings closed without independent verification evidence in the finding record.", "Same control area generating findings in two or more consecutive audit cycles.", "Root-cause analyses identifying only proximate causes without systemic analysis or organizational contributing factors." ] }, "it_operations": { "summary": "IT Operations owns remediation for all technical and IT-related findings. Technical finding remediation requires change management rigor to ensure remediation actions are themselves controlled and documented.", "actions": [ "Accept ownership of all IT-related findings assigned in the finding register and provide scheduled status updates.", "Route all technical corrective actions through the change management process and document change tickets in the finding record.", "Provide verification artifacts (scan results, configuration exports, penetration test evidence) to confirm technical remediation is complete and independently verifiable." ], "failure_signals": [ "Technical findings remediated outside the change management process without documented justification.", "Verification artifacts submitted that do not include independent test evidence (e.g., self-certifications without scan output).", "IT finding remediation consistently exceeding defined SLAs without escalation." ] }, "executive": { "summary": "The finding remediation program is a leading indicator of compliance program health that board audit committees and regulators scrutinize closely. Persistent or growing open finding counts signal resource or governance gaps requiring executive intervention.", "actions": [ "Receive quarterly executive summary of finding aging, severity distribution, source breakdown, and repeat finding trends.", "Sponsor root-cause analysis programs for systemic findings and assign accountable ownership at the appropriate organizational level.", "Treat unresolved critical findings as a standing agenda item for board or audit committee meetings." ], "failure_signals": [ "Critical findings reported to the board that were not previously escalated to executive leadership.", "Systemic repeat findings without an executive-sponsored improvement program with milestones and accountability.", "Finding remediation resources insufficient to meet SLA targets across the program." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations track findings in spreadsheets without formal verification requirements, root-cause analysis mandates, or repeat-finding analysis. A centralized register with independently verified closure is an emerging best practice." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "multi-tenant" ], "implementers": [ "Compliance Team", "GRC Operations", "IT Operations", "Executive Leadership" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a710.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a710.2 requires the organization to react to noncompliances, take action to control and correct them, deal with the consequences, and evaluate the need to eliminate root causes so that nonconformities do not recur. The finding remediation program with root-cause analysis and verified closure directly implements these corrective action requirements.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC4.2", "fit": "direct", "rationale": "SOC 2 CC4.2 requires evaluation and communication of identified internal control deficiencies to responsible parties in a timely manner. The finding register and remediation tracking program operationalize assignment, closure verification, and escalation to ensure deficiencies reach the appropriate decision-makers.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA02.04", "fit": "direct", "rationale": "COBIT 2019 MEA02.04 (Identify and report control deficiencies) requires organizations to identify control deficiencies and report them so that remedial actions are taken. The finding remediation program implements the formal remediation cycle for control deficiencies identified through audit activity, with defined SLAs and independent verification.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 17", "fit": "partial", "rationale": "COSO ERM 2017 Principle 17 (Pursues Improvement in ERM) requires the organization to pursue improvement of enterprise risk management. The finding remediation program \u2014 with its finding register, root-cause analysis, escalation timelines, and independently verified closure \u2014 is the structured improvement loop for compliance controls identified as deficient through audit activity.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 9(2)(d) & Art. 20", "fit": "partial", "rationale": "EU AI Act Article 9(2)(d) requires the adoption of appropriate and targeted risk management measures as part of the continuous risk management process, and Article 20 requires providers to immediately take the necessary corrective actions when a high-risk AI system is not in conformity. The finding remediation program implements the systematic corrective action capability these obligations require across all applicable compliance domains.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 25(1)", "fit": "adjacent", "rationale": "GDPR Article 25(1) requires data protection by design and by default, including appropriate technical and organizational measures. Systematic finding remediation ensures that identified data protection control gaps are addressed through verified corrective actions rather than remaining as acknowledged but unresolved risks.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "direct", "rationale": "Microsoft Purview Compliance Manager's Improvement Action framework is a direct implementation of the AU-06 Audit Finding Remediation Program for compliance gaps identified within Compliance Manager's assessment scope. Improvement Actions provide structured tracking of compliance control gaps from identification through verified remediation \u2014 with owner assignments, status progression, evidence attachment, and completion review \u2014 mirroring the centralized finding register requirements in AU-06. Organizations using Compliance Manager must integrate Improvement Action status directly into the AU-06 finding register to prevent parallel tracking of the same remediation items across two systems.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "partial", "rationale": "Okta Identity Governance access certification campaigns generate identity governance findings \u2014 over-privileged accounts, policy violations, dormant access, segregation of duties conflicts \u2014 that are a primary input source for the AU-06 centralized finding register. Okta certification results and the revocation actions completed through Okta governance workflows provide the independently verifiable remediation evidence required by AU-06 for formally closing access-related audit findings, with Okta's campaign completion records serving as the verification artifact attached to each finding before closure.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a centralized finding register with zero overdue critical findings beyond defined SLAs, at least 95% of closed findings supported by independently verified remediation evidence, and a repeat finding rate in the same control area below 10% over any rolling 24-month window, demonstrating that root-cause analysis is eliminating systemic deficiencies rather than merely closing proximate findings.", "evidence_required": [ "finding_register export showing all findings from internal audit, external audit, regulatory examinations, and self-assessments with severity classification, root-cause category, corrective action plan, assigned owner, target close date, verification method, and current status", "independently_verified_closure_records for all findings marked closed in the last 12 months, including the type of verification evidence and the identity of the independent reviewer who confirmed remediation before formal closure", "root_cause_analysis_reports for all critical and high findings and any findings recurring in the same control area within a 24-month window, completed before the corrective action plan was approved", "monthly_aging_reports for the last 6 months showing open finding counts by severity, owner, and source with evidence of GRC committee distribution and documented escalation for overdue items", "corrective_action_change_tickets for all IT-related findings, confirming technical remediation was processed through the change management system with change records attached to the finding" ], "machine_tests": [ "Query the finding register for critical findings with a target close date older than the defined SLA \u2192 assert zero overdue critical findings exist without documented executive escalation and awareness", "Pull all findings marked closed in the last 12 months and check for the independent verification evidence field \u2192 assert \u226595% of closed findings have an independently produced verification artifact attached", "Query for findings in the same control area open or closed within any 24-month window across two audit cycles \u2192 assert the repeat finding rate is below 10%", "Check all critical and high findings for an attached root-cause analysis report with completion date before the corrective action plan approval date \u2192 assert 100% compliance" ], "human_review": [ "Sample 25% of closed findings and assess whether the attached verification evidence demonstrates substantive remediation \u2014 scan results, configuration exports, or re-test output \u2014 rather than a responsible owner self-certification without independent confirmation", "Review root-cause analyses for repeat findings in the same control area and evaluate whether analyses identify systemic and organizational contributing factors or address only proximate causes that leave the underlying deficiency intact", "Assess the finding aging trend over the last 4 monthly reporting periods to evaluate whether the remediation program is closing findings faster than new ones are being identified, or whether a backlog is accumulating indicating insufficient remediation capacity" ], "blocking_effect": "requires-review", "normative_status": "certification-standard", "anti_patterns": [ "Closing findings based on the responsible owner self-certifying that remediation is complete, without requiring independently produced verification evidence such as scan results, configuration exports, or re-test output from a party other than the owner", "Tracking findings in separate registers by audit source \u2014 one spreadsheet for internal audit, another for SOC 2 findings, another for regulatory examination items \u2014 preventing detection of cross-source repeat findings in the same control area over the 24-month window", "Conducting root-cause analysis only for critical findings while treating high findings as requiring only corrective action plans, allowing systemic issues at the high severity tier to recur without systematic root-cause identification or organizational accountability", "Setting remediation target dates by negotiation with the responsible owner rather than by severity-based SLA, enabling indefinite deferral of high findings through repeated date extension approvals without GRC committee escalation", "Closing findings immediately upon corrective action implementation without a mandatory validation period to confirm the remediation is effective under normal operating conditions, resulting in formal closure before the fix has been proven sustainable" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-07", "layer": "AU", "plane": "both", "name": "Multi-Framework Evidence Reuse", "plain": "The organization must implement a systematic approach to maximizing evidence reuse across multiple compliance frameworks by mapping overlapping requirements, maintaining a shared master evidence repository with multi-framework tagging, and generating framework-specific evidence packages from the single authoritative evidence source to eliminate duplicative collection burdens.", "threat": { "tags": [ "evidence-duplication", "audit-fatigue", "framework-misalignment", "evidence-version-drift" ], "desc": "Organizations managing multiple compliance frameworks independently create redundant evidence collection burdens, evidence version drift between separately maintained framework packages, and inconsistent control narratives that invite examiner scrutiny. Evidence collected separately for each framework introduces temporal inconsistencies that can appear to auditors as ad hoc compliance activity rather than systematic operations. Without a master repository, updates to source controls are frequently not reflected in all framework packages, creating stale evidence that may contradict current state representations." }, "standard": [ { "id": "iso_37301", "section": "\u00a74.5", "title": "Compliance obligations" }, { "id": "soc2", "section": "CC1.5", "title": "COSO Principle 5 \u2014 Holds individuals accountable for internal control responsibilities" }, { "id": "cobit_2019", "section": "APO02", "title": "Managed Strategy" }, { "id": "nist_csf", "section": "GV.OC-03", "title": "Legal, regulatory, and contractual cybersecurity requirements understood and managed" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/AU-07 Multi-Framework Evidence Reuse control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Build a cross-framework control mapping that identifies evidence reuse opportunities, consolidates evidence collection into a single master repository with multi-framework tagging, and generates framework-specific evidence packages on demand from the master evidence set. A mapping matrix maintains the relationship between master controls, their evidence artifacts, and the multiple framework requirements each artifact satisfies.", "steps": [ "Conduct a cross-framework mapping exercise for all applicable frameworks, identifying overlapping requirements and cataloging evidence artifact types that satisfy multiple framework obligations with a single collection.", "Build or configure a master evidence repository where each artifact is tagged with all framework requirements it satisfies, enabling automated generation of framework-specific evidence packages without additional collection.", "Assign a single collection owner per artifact type, eliminating parallel collection workflows for identical evidence required by multiple frameworks.", "Implement framework-specific package generation that assembles required artifacts from the master repository and applies framework-appropriate metadata formatting for each target framework.", "Run quarterly mapping accuracy reviews to ensure the cross-framework map reflects changes in framework version requirements, new applicable frameworks, or organizational control changes." ], "compliance_officer": { "summary": "Multi-framework evidence reuse directly reduces the compliance team's workload while improving consistency across audits. The mapping matrix is a living document \u2014 it must be actively maintained as frameworks update and the organization's compliance portfolio evolves.", "actions": [ "Sponsor the cross-framework mapping exercise and assign mapping owners for each framework relationship.", "Review and approve the mapping matrix annually and after any material framework version update.", "Measure and report the evidence reuse rate as a core compliance efficiency metric." ], "metrics": [ "Evidence reuse rate (artifacts satisfying more than one framework as a percentage of total artifacts): target \u226540%.", "Cross-framework mapping currency (updated within 12 months or after any framework change): target 100%.", "Audit preparation time reduction year-over-year: target \u226520%." ], "failure_signals": [ "Evidence artifacts being collected separately for each framework without reuse mapping despite overlapping requirements.", "Cross-framework map not updated within 12 months or after a major framework version change.", "Framework-specific packages containing different versions of the same underlying evidence artifact for the same period." ] }, "grc_auditor": { "summary": "Evidence reuse mapping is both an efficiency mechanism and a consistency assurance tool. Verify that mapped reuse is substantively valid \u2014 that artifacts genuinely satisfy all mapped requirements, not merely superficially overlap with them.", "actions": [ "Review the cross-framework mapping matrix for accuracy by sampling 15% of reuse mappings and assessing whether each mapped artifact genuinely satisfies every requirement to which it is mapped.", "Verify that framework-specific packages assembled from the master repository contain consistent artifact versions for the same time period.", "Assess whether single-owner assignments create collection gaps when owners are unavailable." ], "metrics": [ "Mapping accuracy rate (sampled reuse mappings verified as substantively valid): target \u226595%.", "Framework package version consistency rate (same artifact version across all mapped packages for a period): target 100%.", "Single-owner coverage rate for all artifact types: target 100%." ], "failure_signals": [ "Reuse mappings that stretch evidence to nominally satisfy requirements it does not genuinely address.", "Framework packages assembled from different artifact versions for the same compliance period.", "Evidence artifact types without assigned single owners creating collection accountability gaps." ] }, "it_operations": { "summary": "The master evidence repository infrastructure must support multi-framework tagging, version control, and automated package generation at scale, including during peak audit seasons when multiple framework packages may be generated simultaneously.", "actions": [ "Deploy a master evidence repository with multi-framework tagging, version control, and role-based access by framework.", "Build or configure automated framework-specific package generation workflows that assemble from the master repository without manual artifact copying.", "Ensure repository performance supports parallel package generation across multiple frameworks during audit season without degradation." ], "failure_signals": [ "Repository lacking version control for evidence artifacts, preventing rollback to prior period states.", "Framework package generation requiring manual artifact assembly rather than automated repository queries.", "Repository performance degrading during audit season when parallel package generation places concurrent load." ] }, "legal_counsel": { "summary": "Evidence reuse across frameworks must account for differences in evidentiary standards, privilege regimes, and production obligations between regulatory bodies. An artifact appropriate for one regulatory context may carry different implications when produced to a different authority.", "actions": [ "Review cross-framework reuse mappings to identify cases where evidence appropriate for one regulatory context may carry different legal implications in another.", "Advise on privilege treatment for evidence artifacts that may be reused across regulatory frameworks with different production and discovery obligations.", "Confirm that evidence reuse does not create inadvertent privilege waivers when the same artifact is produced to multiple regulatory bodies." ], "failure_signals": [ "Evidence produced to one regulator without accounting for the implications if the same artifact is subsequently required by a different regulatory authority.", "Reuse mappings that ignore jurisdictional differences in evidentiary standards or privilege regimes." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Cross-framework evidence reuse is an aspirational practice for most organizations. Systematic mapping matrices with a master repository and automated package generation represent an advanced compliance operations model that few enterprises have implemented." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "cloud-native", "high-risk-sector", "federated-enterprise", "multi-tenant" ], "implementers": [ "GRC Operations", "Compliance Team", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a74.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a74.5 requires the organization to identify its compliance obligations and understand how they apply to its activities. Multi-framework evidence reuse operationalizes the efficient satisfaction of overlapping obligations by mapping them to a unified evidence collection rather than maintaining redundant parallel programs.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO02.06", "fit": "partial", "rationale": "COBIT 2019 APO02.06 (Communicate the I&T strategy and direction) requires communicating the strategy and its implications to stakeholders. A unified multi-framework evidence strategy must be communicated to control owners and evidence producers so that overlapping obligations are satisfied from shared evidence rather than framework-siloed programs; AU-07's mapping is the artifact that communicates that strategy.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC1.5", "fit": "partial", "rationale": "SOC 2 CC1.5 (COSO Principle 5) requires the entity to hold individuals accountable for their internal control responsibilities. A single master evidence repository with clear single-owner assignments implements the accountability structure for compliance evidence management across all applicable frameworks, reducing the accountability diffusion that occurs in framework-siloed approaches.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "GV.OC-03", "fit": "partial", "rationale": "NIST CSF 2.0 GV.OC-03 requires that legal, regulatory, and contractual requirements regarding cybersecurity \u2014 including privacy and civil liberties obligations \u2014 are understood and managed. Multi-framework mapping implements the systematic analysis of overlapping compliance obligations this outcome requires, without over-investment in framework-specific silos.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Actions", "fit": "adjacent", "rationale": "Microsoft Purview Compliance Manager structures compliance requirements around improvement actions that map to multiple regulatory frameworks simultaneously. The multi-framework evidence reuse approach aligns with Compliance Manager's cross-framework assessment model and can serve as an alternative implementation path for organizations in the Microsoft ecosystem.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Art. 17(1)", "fit": "adjacent", "rationale": "EU AI Act Article 17(1) requires quality management systems that integrate with other applicable regulatory requirements including ISO 9001 and ISO 27001. Multi-framework evidence reuse enables efficient integration of EU AI Act documentation requirements with existing ISO, SOC 2, and GDPR compliance programs without duplicative collection burden.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "AWS Artifact compliance reports span multiple regulatory frameworks simultaneously \u2014 a single AWS SOC 2 Type II report provides evidence across ISO 27001, PCI DSS, HIPAA, and SOC 2 control objectives \u2014 making them a prime candidate for multi-framework tagging under the AU-07 evidence reuse program. The AU-07 cross-framework mapping should tag AWS Artifact reports against all frameworks they satisfy in the master evidence repository, enabling a single report retrieval to populate multiple framework-specific packages without duplicative collection and directly operationalizing the evidence reuse principle for cloud infrastructure compliance evidence.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "partial", "rationale": "Google Cloud compliance reports and shared responsibility documentation apply across multiple frameworks (ISO 27001, SOC 2, PCI DSS, FedRAMP) and can be mapped to overlapping requirements in the AU-07 master evidence repository. A single Google Cloud SOC 2 report satisfies control requirements across multiple frameworks for GCP-hosted components, and the AU-07 cross-framework mapping should tag GCP compliance artifacts against all applicable frameworks to eliminate duplicative retrieval cycles for each separate assessment.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance audit reports satisfy overlapping requirements across SOC 2 (CC6.1, CC6.3), ISO 27001 (Annex A.9), GDPR (Article 32), and EU AI Act identity control obligations \u2014 making Okta governance exports a prime candidate for multi-framework evidence reuse under AU-07. The AU-07 cross-framework mapping should tag Okta audit reports against all applicable frameworks in the master repository so a single governance report export can populate multiple assessment packages without separate per-framework collection, directly reducing the duplicative collection burden described in the AU-07 threat model.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. Anthropic's published capability assessment documentation is a single vendor-layer evidence source that AU-07's reuse matrix can map against multiple frameworks \u2014 EU AI Act risk management evidence, ISO 42001 supplier assessment, and SOC 2 vendor management \u2014 rather than collecting it separately per framework.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "adjacent", "rationale": "OpenAI's Data Processing Addendum satisfies overlapping requirements across GDPR Article 28 (processor agreements), EU AI Act data governance provisions, and sector-specific AI regulatory frameworks \u2014 making DPA documentation suitable for multi-framework tagging in the AU-07 master evidence repository. Organizations should map OpenAI DPA artifacts against all applicable frameworks in their evidence reuse matrix so that DPA-related compliance evidence is collected once and referenced across all applicable assessments rather than separately obtained for each framework review.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a cross-framework evidence mapping matrix and a master evidence repository in which at least 40% of evidence artifacts are tagged to satisfy more than one compliance framework obligation, with all framework-specific packages assembled exclusively from the master repository using the same artifact versions across all framework packages for any given compliance period, and the mapping matrix reviewed within 12 months or within 30 days of any framework version change.", "evidence_required": [ "cross_framework_mapping_matrix with last review date within 12 months, listing all applicable frameworks, overlapping requirements, and evidence artifact IDs mapped to multiple framework obligations with substantive fit rationale for each mapping", "master_evidence_repository_export showing multi-framework tag assignments for each artifact, confirming the reuse rate (artifacts tagged to more than one framework as a percentage of total artifacts) is \u226540%", "framework_specific_package_generation_log confirming packages were assembled from the master repository for the last audit cycle, with source artifact IDs, version numbers, and framework destination recorded for each assembly run", "mapping_accuracy_review_report from the last quarterly review, documenting sampled reuse mappings with substantive accuracy verification results and any corrections applied to invalid mappings", "artifact_owner_assignment_record listing the single collection owner for each artifact type in the master repository with current assignment date and coverage plan for owner absence" ], "machine_tests": [ "Generate framework-specific evidence packages for two different frameworks from the same compliance period \u2192 assert both packages reference the same artifact version IDs from the master repository for all overlapping requirements with no version discrepancies", "Query the master repository for all artifacts tagged to multiple frameworks \u2192 assert the reuse rate (multi-tagged artifacts as a percentage of total) is \u226540%", "Query the cross-framework mapping matrix for last review date \u2192 assert the mapping was reviewed and updated within the last 12 months or within 30 days of any identified framework version change", "Attempt to generate a framework package by uploading an artifact directly outside the master repository workflow \u2192 assert the package generation system enforces repository-sourced assembly and rejects or flags manually inserted artifacts" ], "human_review": [ "Sample 15% of reuse mappings from the cross-framework matrix and assess whether each mapped artifact genuinely satisfies every requirement to which it is tagged, distinguishing substantive overlap from nominal categorization that stretches evidence beyond its actual coverage", "Review single-owner assignments for all artifact types and evaluate whether documented coverage plans for owner absence prevent collection gaps that would break the single-source integrity guarantee during audit season", "Assess whether legal differences in evidentiary standards or privilege treatment across mapped regulatory bodies have been considered for artifacts tagged to multiple frameworks \u2014 particularly artifacts that may carry different implications when produced to different regulatory authorities" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Maintaining separate evidence collection workflows for each compliance framework with the same underlying artifacts collected and stored independently per framework, allowing temporal version drift between simultaneously maintained framework packages that appear contradictory under regulatory scrutiny", "Building the cross-framework mapping matrix during initial program setup and not maintaining it as frameworks update, resulting in stale mappings that no longer reflect current requirements after framework version changes and creating invalid evidence reuse claims", "Assigning multiple co-owners to artifact types to reduce single-owner bottleneck risk without establishing a single authoritative collection procedure, allowing inconsistent artifact versions and numbering between co-owners that undermine the master source guarantee", "Mapping evidence artifacts to framework requirements based on superficial categorization overlap rather than substantive compliance coverage \u2014 such as mapping a generic security scan to an AI transparency requirement \u2014 inflating reuse metrics without genuine multi-framework compliance", "Generating framework-specific packages by manually copying artifacts from the master repository rather than through automated repository queries, breaking the version consistency guarantee and introducing the risk of different artifact versions appearing in packages for the same compliance period" ], "update_status": "current", "layer_code": "AU" }, { "id": "AU-08", "layer": "AU", "plane": "data", "name": "ComplianceAttestation Production", "plain": "The organization must produce a ComplianceAttestation artifact that packages evidence from the full AU layer \u2014 audit readiness state (AU-01), curated evidence artifacts (AU-02), auditor cooperation records (AU-03), audit trail integrity verification (AU-04), examination response program status (AU-05), finding remediation status (AU-06), and multi-framework evidence map currency (AU-07) \u2014 into a signed, versioned attestation conforming to the Apeiris evidence ontology and consumable by internal governance, external auditors, and the Apeiris evidence graph.", "threat": { "tags": [ "attestation-failure", "stale-attestation", "incomplete-evidence-package", "signature-spoofing" ], "desc": "Compliance programs that cannot produce a coherent, signed attestation artifact are unable to demonstrate systemic control operation to downstream consumers in federated enterprise environments. Stale or unsigned attestations are rejected by automated compliance gates and may misrepresent the current compliance posture to parties who rely on them. An attestation that omits evidence from one or more AU controls creates a materially incomplete representation of compliance status that, if relied upon by auditors or regulators, exposes the organization to liability for misrepresentation." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1.5", "title": "Record-keeping" }, { "id": "soc2", "section": "CC2.2", "title": "Communication of information necessary for compliance reporting" }, { "id": "eu_ai_act", "section": "Art. 43", "title": "Conformity assessment procedures" }, { "id": "gdpr", "section": "Art. 5(2)", "title": "Accountability \u2014 demonstrability of compliance through documented evidence" } ], "sources": [ { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/AU-08 ComplianceAttestation Production control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Produce ComplianceAttestation artifacts through an automated assembly pipeline that collects evidence summaries from AU-01 through AU-07, applies completeness thresholds before verdict assignment, computes a SHA-256 content hash, and produces an Ed25519-signed attestation object conforming to the Apeiris evidence ontology. Attestations are versioned, timestamped, and stored in the evidence graph with valid_from and valid_until bounds. Issuance cadence is configurable by consumer context.", "steps": [ "Implement an attestation assembly pipeline that queries the status of all upstream AU controls: AU-01 evidence library completeness, AU-02 artifact validation pass rate, AU-03 cooperation log currency, AU-04 integrity verification recency, AU-05 examination response program status, AU-06 open finding SLA compliance, and AU-07 mapping currency.", "Define completeness thresholds for each upstream AU control required before a 'pass' verdict can be issued \u2014 for example: AU-01 completeness \u226595%, AU-04 integrity verified within 24 hours, AU-06 zero overdue critical findings, AU-07 mapping updated within 12 months.", "Implement all required Apeiris evidence ontology fields: evidence_id, actor, intent, action, resource, policy, obligation, verdict (pass/fail/conditional/inconclusive/not-applicable), blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, reviewed_on, source_freshness_status, residual_risk, producer_verifier, consumer_verifiers, evidence_completeness_status, runtime_gate_required, integrity.hash (SHA-256), and integrity.signature (Ed25519).", "Configure attestation issuance cadence per deployment context: continuous for high-risk AI contexts (valid_until = 24h), daily for enterprise governance contexts, and on-demand for audit submission requests.", "Publish completed attestations to the Apeiris evidence graph at the canonical URI apeiris://compliance/controls/AU-08 with registered consumer_verifiers for all authorized downstream compliance gates." ], "compliance_officer": { "summary": "The ComplianceAttestation is the authoritative output of the entire AU layer. Its verdict directly represents the current compliance posture across all AU controls. You own the issuance policy, completeness thresholds, and consumer_verifier authorization.", "actions": [ "Define and approve the completeness thresholds for each upstream AU control required before a 'pass' verdict can be issued.", "Review attestation verdicts weekly and investigate any transition from 'pass' to 'conditional' or 'fail' within 24 hours.", "Approve each consumer_verifier registration before any external party is authorized to rely on the attestation." ], "metrics": [ "ComplianceAttestation pipeline issuance success rate: target 100% on the defined cadence.", "Attestation 'pass' rate: target \u226590% of issuances.", "Attestation staleness rate (expired without re-issuance): target 0%." ], "failure_signals": [ "Attestation pipeline failing to produce an artifact on the defined issuance cadence.", "Attestation verdict transitioning to 'fail' without compliance officer notification within 24 hours.", "Downstream consumers relying on an expired attestation without having received an updated version." ] }, "grc_auditor": { "summary": "The ComplianceAttestation is the primary deliverable for external audit reliance. Verify the cryptographic integrity of the attestation itself, and trace claimed upstream control statuses back to their source AU control evidence.", "actions": [ "Obtain the current ComplianceAttestation and verify the SHA-256 content hash and Ed25519 signature against the attestation registry.", "Trace each upstream AU control status field in the attestation back to its source evidence in the corresponding AU control and confirm the claimed status is accurate.", "Review the valid_from and valid_until bounds to confirm the attestation was current throughout the examination period." ], "metrics": [ "Attestation cryptographic verification pass rate: target 100%.", "Upstream control status traceability rate: target 100% of claimed evidence fields traced to verified source.", "Attestation currency during examination period: target 100%." ], "failure_signals": [ "Attestation SHA-256 hash or Ed25519 signature verification failure.", "Upstream AU control status claims not supported by corresponding source evidence in the AU control record.", "Attestation valid_until expired before the end of the examination period without re-issuance." ] }, "it_operations": { "summary": "IT Operations operates the attestation assembly pipeline and signing key infrastructure. Pipeline reliability, signing key management, and evidence graph publication are critical operational responsibilities with direct compliance impact.", "actions": [ "Operate the attestation assembly pipeline with a 99.9% uptime SLA and alert the compliance officer on any pipeline failure within 15 minutes.", "Manage Ed25519 signing keys with HSM protection and annual key rotation, maintaining signature continuity for existing attestations across key rotations.", "Publish completed attestations to the Apeiris evidence graph within 15 minutes of generation, with automatic validity period management and expiry notifications." ], "failure_signals": [ "Attestation pipeline downtime exceeding the defined SLA without escalation to the compliance officer.", "Ed25519 signing keys stored outside HSM or key rotation cadence exceeding 12 months.", "Attestation publication to the evidence graph delayed more than 15 minutes after pipeline generation." ] }, "legal_counsel": { "summary": "The ComplianceAttestation is a formal compliance representation that may be relied upon by regulators and external counterparties. Legal review of the attestation's verdict scope and consumer_verifier registrations is required before external publication.", "actions": [ "Review the attestation scope and verdict field definitions before authorizing any external consumer_verifier registration to ensure representations are legally accurate.", "Advise on the legal effect of a 'pass' verdict in each applicable regulatory jurisdiction where the attestation may be relied upon.", "Confirm that attestation valid_until periods are conservative enough to prevent reliance on stale verdicts by downstream parties." ], "failure_signals": [ "External consumer_verifiers registered without legal review of the attestation scope and the legal representations contained in a 'pass' verdict.", "Attestation relied upon by external parties in regulatory submissions without prior legal sign-off on the scope of representation." ] }, "executive": { "summary": "The ComplianceAttestation provides board-level visibility into the current compliance posture in a single signed, machine-readable artifact. Executive oversight of attestation verdicts is a governance best practice for organizations operating in regulated or high-risk AI contexts.", "actions": [ "Receive a weekly dashboard of ComplianceAttestation verdict history and any transitions to conditional or fail.", "Approve the initial configuration of consumer_verifiers \u2014 the list of external parties authorized to rely on the organization's attestation.", "Review the attestation program charter and completeness threshold configuration annually to ensure it reflects the current regulatory obligation scope." ], "failure_signals": [ "Attestation verdict transitioning to 'fail' without executive notification.", "External parties relying on the attestation for material business or regulatory purposes without executive awareness.", "Attestation scope not updated to reflect newly applicable regulatory obligations within 90 days of identification." ] } }, "maturity": { "current": "initial", "target": "optimizing", "notes": "Automated signed attestation artifacts conforming to a formal evidence ontology represent advanced compliance practice. Most organizations produce manual compliance reports without cryptographic integrity, machine-readable structure, or federated consumption capability." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Compliance Team", "GRC Operations", "Legal Counsel", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1.5", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1.5 requires the organization to keep records demonstrating the results of its compliance monitoring and evaluation activities. The ComplianceAttestation artifact is the authoritative versioned record of compliance monitoring results for the entire AU layer, satisfying this record-keeping requirement in a cryptographically verifiable form.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC2.2", "fit": "direct", "rationale": "SOC 2 CC2.2 requires communication of information necessary for control function to responsible parties. The ComplianceAttestation provides the structured, machine-readable communication of AU layer compliance control status to governance, audit, and external consumer parties in a consistent, verifiable format.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art. 43(1)", "fit": "direct", "rationale": "EU AI Act Article 43(1) requires conformity assessment procedures for high-risk AI systems with documentation demonstrating compliance available for regulatory inspection. The ComplianceAttestation implements the structured conformity evidence package for EU AI Act examination, providing a signed artifact with complete upstream evidence references.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "direct", "rationale": "GDPR Article 5(2) accountability requires controllers to demonstrate compliance with data protection principles on demand. The ComplianceAttestation is the primary instrument for demonstrating this compliance through a signed, verifiable evidence package that can be produced to supervisory authorities without emergency preparation.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA03.03", "fit": "partial", "rationale": "COBIT 2019 MEA03.03 requires confirming compliance with external requirements and reporting compliance status. The ComplianceAttestation provides the formal confirmation artifact with cryptographic integrity and machine-readable structure that enables automated compliance status reporting across all applicable frameworks.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Principle 20", "fit": "partial", "rationale": "COSO ERM Principle 20 requires the board to oversee risk and internal control performance. The ComplianceAttestation provides a board-accessible artifact for compliance risk oversight with explicit pass/fail verdicts, residual risk fields, and confidence basis that enable meaningful governance review without requiring deep technical examination.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance Reports", "fit": "adjacent", "rationale": "AWS Artifact provides machine-readable cloud provider compliance reports that serve as upstream evidence inputs to the ComplianceAttestation. The attestation's evidence_completeness_status and consumer_verifiers fields can reference whether cloud provider compliance artifacts from AWS Artifact have been incorporated as supporting evidence.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "partial", "rationale": "Microsoft Purview Compliance Manager's compliance score aggregates assessment statuses across ISO 27001, SOC 2, GDPR, and EU AI Act controls into a quantitative readiness indicator directly relevant to the AU-08 ComplianceAttestation verdict. The attestation assembly pipeline described in AU-08 should incorporate Compliance Manager scores as upstream evidence inputs for frameworks assessed within Compliance Manager, with Compliance Manager assessment currency and score thresholds contributing to the evidence_completeness_status and confidence_basis fields of the signed ComplianceAttestation artifact.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "Google Cloud compliance reports \u2014 SOC 2 Type II, ISO 27001 certificates, and PCI DSS attestations \u2014 are upstream evidence inputs that must be retrieved and referenced in the AU-08 ComplianceAttestation for organizations operating compliance-relevant workloads on GCP. The ComplianceAttestation's evidence_completeness_status field should reflect whether current Google Cloud compliance reports are present and within their validity windows, as gaps in cloud provider evidence directly reduce the attestation's overall confidence and may prevent a 'pass' verdict where cloud infrastructure controls are part of the compliance scope.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "Okta Identity Governance audit reports on access certifications, policy enforcement outcomes, and governance workflow completions are identity compliance evidence inputs that the AU-08 ComplianceAttestation pipeline must incorporate when producing attestations for identity-governed systems. The ComplianceAttestation's evidence_completeness_status should reflect whether current Okta governance audit reports are present and within freshness thresholds, as identity governance evidence is a required component for attestations covering access control compliance across SOC 2 CC6, ISO 27001 Annex A.9, and GDPR Article 32 frameworks.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. Where the attested system incorporates Anthropic models, AU-08's ComplianceAttestation should reference the currency of provider-layer documentation \u2014 RSP version and published Capability Report summaries \u2014 in its residual_risk and evidence completeness assessment.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Trust Portal", "fit": "adjacent", "rationale": "OpenAI's Trust Portal supplies vendor compliance reports and security documentation that constitute upstream evidence inputs when the attested system incorporates OpenAI services. AU-08's ComplianceAttestation should reference the currency of vendor-layer compliance documentation for such systems.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/AU-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must produce a ComplianceAttestation artifact that bears a valid Ed25519 signature, a SHA-256 content hash that matches the artifact, and a valid_until timestamp in the future, accurately reflects the current status of all AU-01 through AU-07 upstream controls against defined completeness thresholds, and is issued on the configured cadence with zero staleness periods where valid_until has expired without re-issuance.", "evidence_required": [ "compliance_attestation_artifact in JSON conforming to the Apeiris evidence ontology with all required fields populated: evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, reviewed_on, source_freshness_status, residual_risk, producer_verifier, consumer_verifiers, evidence_completeness_status, runtime_gate_required, integrity.hash, integrity.signature", "signature_verification_log confirming Ed25519 signature verification passes against the declared producer_verifier public key for each attestation issued in the last 30 days", "pipeline_issuance_log showing attestation generation timestamps, upstream AU control status inputs, completeness threshold evaluation results, and verdict determinations for each issuance in the last 30 days", "ed25519_key_management_record confirming HSM storage of signing keys, key rotation date within the last 12 months, and signature continuity documentation across key rotation events", "consumer_verifier_registry listing all authorized downstream parties with the legal review approval date and scope-of-representation review confirmation for each registered consumer" ], "machine_tests": [ "Query the Apeiris evidence graph for the current ComplianceAttestation \u2192 assert the artifact exists, valid_until is in the future, SHA-256 hash matches the artifact content, and Ed25519 signature verifies against the declared producer_verifier public key", "Force AU-06 finding register to contain a critical finding overdue beyond its defined SLA \u2192 assert the next pipeline issuance produces verdict=conditional or verdict=fail rather than verdict=pass", "Advance the system clock past the attestation valid_until timestamp without triggering a re-issuance cycle \u2192 assert consumer_verifier access returns a staleness alert and the compliance officer notification is generated within the configured alert window", "Submit a tampered attestation artifact with one field modified to the verification endpoint \u2192 assert Ed25519 signature verification fails and the rejection is logged with both the expected and received artifact hashes" ], "human_review": [ "Trace each upstream AU control status field in the current attestation back to its source evidence in the corresponding AU control and confirm the claimed status is accurate, current, and supported by the evidence described in evidence_completeness_status", "Review the consumer_verifier registry and assess whether all registered downstream consumers received legal review of the scope of representation conveyed by a pass verdict before being granted reliance rights on the attestation", "Evaluate whether the valid_until configuration is appropriate for each consumer context \u2014 no more than 24 hours for high-risk AI runtime gates and no more than 7 days for enterprise governance dashboards \u2014 and confirm that runtime gate consumers are not relying on attestations with validity windows designed for governance reporting" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing ComplianceAttestation artifacts by manually assembling upstream control statuses into a document without an automated pipeline, creating human error risk in status reporting and inability to meet continuous issuance cadence requirements for high-risk AI runtime gate contexts", "Storing Ed25519 signing keys in environment variables, secrets managers, or file system locations without HSM protection, making the signing key a vulnerability that can be exfiltrated to forge attestations that pass signature verification", "Applying a single long valid_until period \u2014 such as 90 days \u2014 across all consumer contexts regardless of whether the consumer uses the attestation as a runtime action gate or a governance dashboard, creating unacceptably stale runtime gates while over-burdening governance consumers with unnecessary reissuance frequency", "Issuing pass verdicts without defining and enforcing documented completeness thresholds for all upstream AU controls, allowing a pass attestation to be produced even when AU-06 has overdue critical findings or AU-04 has unresolved integrity breaks", "Registering external consumer_verifiers without legal review of the scope of representation conveyed by the verdict field, creating unintended compliance representations to regulators or counterparties who may rely on the attestation in regulatory submissions or contract negotiations" ], "update_status": "current", "layer_code": "AU" }, { "id": "CG-01", "layer": "CG", "plane": "control", "name": "Compliance Governance Structure", "plain": "The organization must establish a formal compliance governance structure that includes a compliance committee, designates a Chief Compliance Officer or equivalent role, defines reporting lines from compliance functions to senior leadership and the board, and documents escalation paths for material compliance issues including those arising from AI systems.", "threat": { "tags": [ "governance-vacuum", "accountability-gap", "escalation-failure", "reporting-opacity" ], "desc": "Without a formal governance structure, compliance responsibilities remain diffuse and unowned. AI regulatory obligations accumulate without anyone accountable for resolution. When enforcement actions arise, the absence of defined escalation paths delays response, compounds penalties, and prevents the board from exercising its oversight duty." }, "standard": [ { "id": "iso_37301", "section": "\u00a75.1", "title": "Leadership and commitment \u2014 governance body responsibilities" }, { "id": "coso_erm", "section": "Component 1", "title": "Governance and Culture \u2014 tone at the top and accountability structures" }, { "id": "cobit_2019", "section": "APO01", "title": "Managed I&T Management Framework \u2014 governance structure and roles" }, { "id": "eu_ai_act", "section": "Article 17", "title": "Quality management system \u2014 compliance function requirements" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-01 Compliance Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-01 Compliance Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-01 Compliance Governance Structure control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-01 Compliance Governance Structure control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Charter a Compliance Committee with defined membership, quorum rules, and cadence. Designate a Chief Compliance Officer (CCO) or equivalent with direct board access. Document reporting lines in an organizational compliance map and escalation matrix covering regulatory, ethics, and AI-specific incidents.", "steps": [ "Draft and ratify a Compliance Committee charter defining membership (CCO, General Counsel, CTO, CISO, CFO), quorum requirements, meeting cadence, and decision authority.", "Define the CCO role with explicit reporting lines to the CEO and a direct channel to the board's Audit and Risk Committee; document in the organizational chart.", "Create an escalation matrix mapping compliance issue types (regulatory inquiry, enforcement action, material AI risk event, data breach) to escalation paths, timeframes, and responsible parties.", "Publish the governance structure to all employees and include acknowledgment in annual compliance training." ], "compliance_officer": { "summary": "The CCO role must be formally chartered with explicit authority, resources, and board access to be effective. A compliance function without structural independence is a governance fiction.", "actions": [ "Ensure the CCO role is documented in corporate bylaws or board resolution with explicit authority scope.", "Establish a direct reporting line to the Audit and Risk Committee, bypassing management for material issues.", "Conduct quarterly Compliance Committee meetings with documented agendas, minutes, and action item tracking." ], "metrics": [ "Percentage of escalation events resolved within defined SLA: target 95%.", "Compliance Committee meeting attendance rate: target 80% quorum per meeting." ], "failure_signals": [ "CCO has no direct board access.", "Compliance Committee has not met in 90+ days.", "Escalation matrix is undocumented or more than 12 months out of date." ] }, "legal_counsel": { "summary": "The governance structure must align with applicable regulatory requirements for designated compliance officers, particularly under EU AI Act, GDPR, and sector-specific frameworks.", "actions": [ "Review CCO role definition against regulatory requirements in all applicable jurisdictions.", "Ensure escalation paths cover regulatory notification obligations with appropriate timelines.", "Advise on privilege protections for compliance communications flowing through the committee." ], "failure_signals": [ "CCO role does not meet regulatory designation requirements.", "Escalation matrix omits mandatory regulatory notification timelines.", "Legal hold procedures not integrated into compliance escalation paths." ] }, "executive": { "summary": "Board-level visibility into the compliance governance structure is a prerequisite for exercising fiduciary duty, particularly as AI regulatory exposure increases.", "actions": [ "Receive and approve the Compliance Committee charter at the board level.", "Ensure the CCO has a standing agenda item on Audit and Risk Committee meetings.", "Review and ratify the escalation matrix annually." ], "failure_signals": [ "No board resolution establishing the compliance function.", "CCO has not presented to the board in the last two quarters.", "Escalation matrix has not been reviewed at board level in 12+ months." ] }, "grc_auditor": { "summary": "Internal audit must independently verify that the governance structure exists, is operational, and functions as documented.", "actions": [ "Obtain and review the Compliance Committee charter, CCO role description, and escalation matrix.", "Interview CCO and at least two board members to verify their understanding of escalation paths.", "Review meeting minutes for the last four Compliance Committee sessions to confirm quorum and action tracking." ], "metrics": [ "Committee meeting cadence compliance: target 100%.", "Escalation SLA adherence: target 95%." ], "failure_signals": [ "Committee charter is draft or unapproved.", "Meeting minutes show less than quorum in the majority of sessions.", "CCO cannot demonstrate a direct board communication channel." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most enterprises have informal compliance functions without formal charters or defined board escalation paths for AI-specific risks." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Legal & Compliance", "Executive Leadership", "Board of Directors", "GRC Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a75.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a75.1 directly requires top management to demonstrate leadership and commitment to the compliance management system, including establishing governance structures with defined roles and responsibilities. Compliance committees and CCO roles are the primary mechanism for satisfying this clause.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 1 \u2014 Governance and Culture", "fit": "direct", "rationale": "COSO ERM Component 1 establishes governance and culture as the foundation of enterprise risk management, requiring boards to exercise oversight and management to establish operating structures and attract capable individuals. The compliance committee structure directly implements this component.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "cobit_2019", "requirement_id": "APO01", "fit": "direct", "rationale": "COBIT 2019 APO01 (Managed I&T Management Framework) requires establishing roles, responsibilities, and accountability for I&T governance including compliance functions. The compliance governance structure maps directly to this management objective.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 17", "fit": "direct", "rationale": "EU AI Act Article 17 requires providers of high-risk AI systems to implement a quality management system that includes clear responsibilities, documented governance, and senior accountability. A formal compliance governance structure is the organizational prerequisite for meeting this article.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Article 24", "fit": "direct", "rationale": "GDPR Article 24 places responsibility for compliance on the controller and requires implementation of appropriate technical and organizational measures. The compliance governance structure is the organizational measure that enables the controller to demonstrate accountability across AI data processing activities.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "The Compliance Governance Structure control requires formally chartered governance bodies, defined reporting lines, and documented escalation paths for AI compliance obligations. Microsoft Purview Compliance Manager's Assessment templates map internal governance structure to specific regulatory frameworks (ISO 27001, SOC 2, EU AI Act), assigning control ownership and accountability at the committee and role level. This directly operationalizes the governance structure requirement by creating auditable evidence of compliance responsibility assignment and escalation documentation within the Compliance Manager platform.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Entitlement Management", "fit": "partial", "rationale": "Okta Identity Governance's Entitlement Management defines who may hold which entitlements and who approves them, operationalizing accountability structures in the identity layer. CG-01's compliance governance structure requires the same explicit role and accountability definitions for compliance obligations across the organization.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Responsible Scaling Officer", "fit": "adjacent", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's designation of a Responsible Scaling Officer accountable for policy implementation is a concrete governance pattern: CG-01 requires the same named-accountability structure for the enterprise's own compliance obligations, including those arising from AI provider relationships.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "adjacent", "rationale": "The Compliance Governance Structure control requires escalation paths for material compliance failures, including those arising from vendor data processing obligations. OpenAI's Enterprise DPA designates data processing responsibilities and compliance obligations at the contracting level that must be reflected in the organization's compliance governance structure\u2014specifically, which role is accountable for DPA compliance and what the escalation path is for data processing incidents. This is an adjacent fit because it informs the scoping of governance responsibilities rather than defining the governance structure itself.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-01", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must have a formally chartered Compliance Committee with documented meeting minutes showing quorum was achieved in at least 80% of scheduled sessions in the last 12 months, a CCO or equivalent with a documented direct reporting channel to the board Audit and Risk Committee that bypasses management for material issues, and a current escalation matrix reviewed within 12 months covering all material compliance issue types including AI regulatory incidents.", "evidence_required": [ "compliance_committee_charter signed and approved by the board with defined membership composition, quorum rules, meeting cadence, decision authority scope, and AI regulatory obligation coverage", "cco_role_documentation including the CCO written authority scope, direct reporting line to the Audit and Risk Committee as documented in board resolution or equivalent formal governance instrument, and organizational chart placement", "compliance_committee_meeting_minutes for the last 12 months showing attendees, quorum status at each session, agenda items including AI compliance matters, and action item tracking with completion status", "escalation_matrix covering all material compliance issue types \u2014 regulatory inquiry, enforcement action, material AI risk event, data breach \u2014 with defined escalation paths, response timeframes, and responsible parties for each tier", "board_resolution or formal charter ratification record establishing the compliance governance structure with effective date and scope of authority" ], "machine_tests": [ "Query compliance committee meeting records for the last 12 months \u2192 assert quorum was achieved in \u226580% of scheduled sessions and all sessions have documented minutes with assigned action items", "Check the escalation matrix document metadata for last review date \u2192 assert the matrix was reviewed and updated within the last 12 months", "Verify the CCO role documentation explicitly names the Audit and Risk Committee as the board-level escalation recipient for material compliance issues \u2192 assert direct board access is structurally documented rather than managed at management discretion" ], "human_review": [ "Interview the CCO and at least two board members independently to verify they can describe the escalation path for a material AI regulatory incident without reference to documentation, confirming the governance structure is operationally understood and not merely formally documented", "Review the Compliance Committee charter for completeness against designated compliance officer requirements in all applicable jurisdictions, including EU AI Act Article 17 quality management requirements and any sector-specific CCO designation requirements", "Assess whether the CCO authority scope is operationally honored by evaluating whether the CCO has independent access to the board agenda without requiring management approval to raise compliance matters at the Audit and Risk Committee level" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Designating the CCO as a direct report to the General Counsel or CFO without independent board access, eliminating structural independence and creating a reporting relationship that may suppress escalation of material compliance issues implicating those functions", "Documenting the Compliance Committee structure without enforcing regular meetings with quorum requirements, producing a governance structure that exists on paper but does not generate the deliberative record regulators examine when assessing whether governance is operationally active", "Creating a single escalation matrix covering all issue types at a generic level without issue-type-specific paths, timelines, or responsible parties, leaving response teams without actionable guidance when a specific type of enforcement action or AI risk event arrives", "Treating the compliance governance charter as a one-time setup rather than a living instrument with mandatory annual review, allowing the escalation matrix to become outdated as new AI regulatory obligations emerge without triggering a governance-level update", "Combining the CCO and CISO roles without a separate compliance reporting channel to the board, conflating security incident response with regulatory compliance escalation and depriving the board of unfiltered compliance risk signals independent of the security function" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-02", "layer": "CG", "plane": "control", "name": "Compliance Policy Framework for AI", "plain": "The organization must maintain a documented, board-approved policy framework that governs how AI regulatory obligations are identified, tracked, assigned, and satisfied. This framework must cover all applicable jurisdictions, define the policy hierarchy from enterprise-level obligations down to system-specific requirements, and be reviewed at least annually or upon material regulatory change.", "threat": { "tags": [ "policy-gap", "regulatory-exposure", "ungoverned-ai-deployment", "obligation-drift" ], "desc": "Organizations deploying AI without a policy framework accumulate regulatory obligations that are never formally assigned or tracked. As AI regulatory requirements proliferate across jurisdictions, ungoverned deployments create silent exposure. When regulators examine compliance posture, the absence of a policy framework signals systemic governance failure and invites broader scrutiny." }, "standard": [ { "id": "iso_37301", "section": "\u00a78.1", "title": "Operational planning and control \u2014 compliance obligations documentation" }, { "id": "eu_ai_act", "section": "Article 9", "title": "Risk management system \u2014 policy-level obligations for high-risk AI" }, { "id": "gdpr", "section": "Article 24", "title": "Responsibility of the controller \u2014 organizational measures" }, { "id": "nist_csf", "section": "GV.OC", "title": "Organizational Context \u2014 policy and regulatory alignment" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-02 Compliance Policy Framework for AI control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Establish a tiered policy architecture: (1) enterprise AI compliance policy (board-approved); (2) domain-specific standards covering each applicable regulatory framework; (3) system-level procedures mapped to individual AI deployments. Maintain a regulatory change tracking process with assigned obligation owners and annual review cycle.", "steps": [ "Conduct a regulatory inventory spanning all jurisdictions of AI operation and identify all applicable frameworks (EU AI Act, GDPR, sector-specific regulations, national AI laws).", "Draft and obtain board approval for an enterprise AI compliance policy establishing obligations, scope, roles, and enforcement mechanisms.", "Develop framework-specific standards that translate regulatory requirements into internal controls, assign owners to each obligation, and link policies to control implementations.", "Establish a regulatory monitoring process to detect new or amended regulations and trigger policy updates; schedule mandatory annual review of the full policy framework." ], "compliance_officer": { "summary": "The policy framework is the CCO's primary tool for translating external regulatory obligations into internal requirements. It must be living documentation that evolves with the regulatory environment.", "actions": [ "Maintain a regulatory inventory updated within 30 days of any material change to applicable AI regulations.", "Ensure every AI system in production is covered by at least one policy document with named owner and review date.", "Report policy framework coverage gaps to the Compliance Committee quarterly." ], "metrics": [ "Policy coverage rate for production AI systems: target 100%.", "Policy review completion within annual cycle: target 100%.", "Regulatory change response time (policy update within 90 days of effective date): target 95%." ], "failure_signals": [ "AI systems in production with no policy coverage.", "Policy framework last reviewed more than 14 months ago.", "No documented process for tracking regulatory changes." ] }, "legal_counsel": { "summary": "The policy framework must translate legal obligations accurately into internal requirements and must be updated as regulatory landscapes shift across all operating jurisdictions.", "actions": [ "Review enterprise AI compliance policy for legal accuracy and completeness across all applicable jurisdictions.", "Advise on enforceability of internal policy mechanisms and ensure they do not create unintended admissions.", "Monitor legislative developments and provide timely legal guidance to trigger policy updates." ], "failure_signals": [ "Policy framework does not address EU AI Act obligations for high-risk systems.", "No legal review of policy framework in the last 12 months.", "Framework fails to address sector-specific regulatory requirements." ] }, "grc_auditor": { "summary": "Internal audit verifies that the policy framework is complete, current, and operationally effective \u2014 not merely a document repository.", "actions": [ "Verify the regulatory inventory covers all known applicable frameworks and has been updated within 30 days of any material regulatory change.", "Sample 10 AI systems and confirm each has policy coverage with named owners and current review dates.", "Test the regulatory monitoring process by presenting a recent regulatory update and tracing the response through the policy update cycle." ], "metrics": [ "AI system policy coverage: target 100%.", "Framework annual review completion: target 100%." ], "failure_signals": [ "Regulatory inventory has gaps in applicable jurisdiction coverage.", "Policy documents have not been reviewed within 14 months.", "No evidence of a regulatory monitoring process." ] }, "executive": { "summary": "The board must approve the enterprise AI compliance policy and receive regular reporting on framework currency as the regulatory environment for AI evolves rapidly.", "actions": [ "Approve the enterprise AI compliance policy and any material amendments.", "Receive annual reporting on policy framework coverage and regulatory change management effectiveness.", "Ensure adequate resources are available for policy maintenance and regulatory monitoring." ], "failure_signals": [ "Enterprise policy has not received board approval.", "Board has not received a policy framework status report in 12+ months.", "Resource constraints are delaying policy updates to new regulations." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most enterprises have general compliance policies that do not address AI-specific regulatory obligations; AI regulatory coverage is typically an afterthought." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Legal & Compliance", "Policy Management", "AI Governance", "GRC Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a78.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a78.1 requires the organization to plan, implement, control, and review processes needed to meet compliance obligations. A documented policy framework is the foundational mechanism for operationalizing this requirement across all AI systems.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 9", "fit": "direct", "rationale": "EU AI Act Article 9 requires a risk management system that identifies and analyzes known and foreseeable risks and implements risk management measures. A policy framework that maps obligations to controls is the organizational implementation of this systematic requirement.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Article 5(2) and Article 24", "fit": "direct", "rationale": "GDPR Article 5(2) enshrines the accountability principle requiring controllers to demonstrate compliance. Article 24 requires implementation of appropriate organizational measures. A documented AI compliance policy framework is the primary organizational measure for demonstrating GDPR accountability.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_csf", "requirement_id": "GV.OC-03", "fit": "direct", "rationale": "NIST CSF 2.0 GV.OC-03 requires that legal, regulatory, and contractual requirements regarding cybersecurity \u2014 including privacy obligations \u2014 are understood and managed as part of organizational context. A policy framework that translates external obligations into internal controls directly implements this outcome.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 2 \u2014 Strategy and Objective-Setting", "fit": "partial", "rationale": "COSO ERM Component 2 requires the organization to define risk appetite and align strategy with core values and obligations. A compliance policy framework that translates regulatory obligations into organizational requirements supports this component by grounding strategy in a documented compliance baseline.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "The Compliance Policy Framework for AI control requires a tiered policy architecture mapping enterprise obligations to framework-specific standards and system-level procedures across all applicable regulatory frameworks. Microsoft Purview Compliance Manager's Assessment templates provide pre-built mappings for GDPR, EU AI Act, ISO 27001, and SOC 2 that directly instantiate the framework-specific policy coverage required by this control. Improvement Action tracking enables organizations to assign and monitor policy-level obligations, satisfying the obligation tracking and assignment dimension of the policy framework requirement.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "The Compliance Policy Framework for AI control requires organizations to identify and track compliance obligations across all applicable regulatory frameworks, including those imposed by cloud infrastructure providers. AWS Artifact's Compliance report access and Artifact agreements provide formal documentation of AWS's regulatory posture (SOC 1/2/3, ISO 27001, FedRAMP, PCI DSS) that enterprises must incorporate into their AI compliance policy framework when AWS hosts their AI workloads. This is a partial fit because it addresses the cloud provider obligation layer of the policy framework rather than the full enterprise-level policy architecture.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "partial", "rationale": "The Compliance Policy Framework for AI control requires clear assignment of obligations from enterprise level down to system level across all applicable jurisdictions. Google Cloud's Shared responsibility matrix and Regulatory guidance define which compliance obligations are Google's versus the customer's for GCP-hosted AI workloads, directly informing the policy framework partitioning for organizations deploying AI on GCP. This is a partial fit because it establishes the cloud-layer obligation boundary within the policy framework rather than the full enterprise AI policy architecture.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Required Safeguards", "fit": "direct", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. As a published, versioned policy that translates risk thresholds into Required Safeguards, the RSP is a reference model for CG-02's policy framework \u2014 the enterprise analogue being a board-approved framework that translates AI regulatory obligations into enforced controls.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "direct", "rationale": "The Compliance Policy Framework for AI control requires the organization's policy framework to cover all AI regulatory obligations, including those arising from AI vendor contracts across all applicable jurisdictions. OpenAI's Enterprise DPA and service terms define data processing obligations, retention constraints, and jurisdiction-specific requirements that enterprises must formally assign to responsible parties and track within their AI compliance policy framework. This is a direct fit because these documents are AI-specific regulatory policy artifacts that must be integrated into the tiered policy architecture as formal obligations with assigned owners and verification procedures.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Workflows", "fit": "partial", "rationale": "Okta Workflows codifies policy decisions as executable automation \u2014 the identity-layer analogue of translating written policy into enforced controls. CG-02's compliance policy framework requires the same translation of AI regulatory obligations from policy documents into operational controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-02", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The organization must maintain a board-approved enterprise AI compliance policy, a regulatory inventory covering all applicable frameworks across all jurisdictions of AI operation updated within 30 days of any material regulatory change, and a documented policy hierarchy extending from the enterprise policy to system-specific procedures for every AI system in production, with all policy documents reviewed within the last 14 months and a demonstrated process for completing policy updates within 90 days of material regulatory change.", "evidence_required": [ "board_approved_enterprise_ai_compliance_policy with formal board ratification record, approval date within the last 14 months, and defined scope covering all applicable AI regulatory obligations across all operating jurisdictions", "regulatory_inventory spanning all jurisdictions of AI operation listing all applicable frameworks, assigned obligation owners for each framework, and last update date confirming review within 30 days of any material regulatory change", "policy_coverage_map linking every AI system in the production AI inventory to at least one policy document with a named owner, last review date within 14 months, and applicable regulatory frameworks identified", "regulatory_change_tracking_log for the last 24 months showing detected regulatory changes, policy update decisions triggered, update completion dates, and compliance with the 90-day response target for each change", "framework_specific_standards_documentation for each applicable regulatory framework, mapping framework requirements to internal controls and assigning named owners responsible for each obligation" ], "machine_tests": [ "Query the policy coverage map against the AI system production inventory \u2192 assert every registered production AI system has at least one policy document with a review date within the last 14 months and a named owner", "Query the regulatory inventory last update timestamp \u2192 assert the inventory was reviewed and updated within 30 days of the most recent material regulatory change affecting any applicable framework", "Check the enterprise AI compliance policy ratification record \u2192 assert it carries a board-level approval signature or formal ratification dated within the last 14 months" ], "human_review": [ "Trace a regulatory change from the last 12 months through the change tracking log to confirm that a policy update was triggered, assigned, completed within 90 days, and the updated policy was reviewed and formally approved by the responsible owner", "Interview the policy owners for two AI systems sampled from the production inventory to verify they can accurately describe the specific regulatory obligations and internal controls that apply to those systems without relying on generic enterprise policy references", "Assess whether the policy framework explicitly addresses EU AI Act conformity obligations for any high-risk AI systems, including system-level technical documentation and risk management requirements, rather than relying solely on general data protection or security policies to satisfy AI-specific obligations" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Maintaining a single enterprise-level AI compliance policy document without framework-specific standards or system-level procedures, leaving individual AI deployments without actionable policy guidance and producing unverifiable compliance claims for specific systems under regulatory examination", "Building the regulatory inventory at initial program launch and not updating it as new AI regulations become effective across operating jurisdictions, leaving newly applicable obligations unassigned and untracked in the policy framework", "Obtaining board approval for the enterprise AI compliance policy once at launch and treating it as perpetual without annual review and reapproval cycles, allowing the policy to become materially outdated as the AI regulatory landscape evolves", "Assigning all AI policy obligations to the compliance function at the enterprise level without naming system-specific owners for individual AI deployments, creating accountability gaps where policy requirements are formally documented but have no operational owner ensuring implementation", "Treating the 90-day regulatory change response target as aspirational without a documented escalation trigger when the target is missed, resulting in AI systems operating under outdated policy coverage that does not reflect current regulatory requirements while the gap is not formally flagged" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-03", "layer": "CG", "plane": "control", "name": "Senior and Board-Level Accountability for AI Compliance", "plain": "The board of directors and C-suite must have documented visibility into the organization's AI compliance posture, including material risks, regulatory obligations, and program effectiveness. Accountability must be formally assigned at the board level through committee mandate and at the executive level through defined roles with AI compliance responsibilities.", "threat": { "tags": [ "accountability-gap", "board-blindness", "c-suite-disengagement", "fiduciary-failure" ], "desc": "When AI compliance accountability stops below the board level, material regulatory risks accumulate without adequate oversight. In enforcement actions, regulators increasingly examine whether boards exercised appropriate oversight of AI systems. Absent formal accountability structures, senior leaders may lack the information needed to make informed decisions about AI deployment risk, creating both legal exposure and reputational harm." }, "standard": [ { "id": "iso_37301", "section": "\u00a75.1", "title": "Leadership and commitment \u2014 top management accountability obligations" }, { "id": "coso_erm", "section": "Component 1", "title": "Governance and Culture \u2014 board oversight responsibilities" }, { "id": "eu_ai_act", "section": "Article 26", "title": "Obligations of deployers \u2014 senior management accountability" }, { "id": "cobit_2019", "section": "MEA02", "title": "Manage System of Internal Controls \u2014 board and management oversight" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-03 Senior and Board-Level Accountability for AI Compliance control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-03 Senior and Board-Level Accountability for AI Compliance control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-03 Senior and Board-Level Accountability for AI Compliance control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-03 Senior and Board-Level Accountability for AI Compliance control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Assign AI compliance accountability to the Audit and Risk Committee by board resolution. Designate an executive (typically CCO or CTO) as responsible for AI compliance reporting to the board. Establish a quarterly board reporting cadence with standardized AI compliance dashboards. Document accountability assignments in role charters and committee mandates.", "steps": [ "Adopt a board resolution assigning AI compliance oversight to the Audit and Risk Committee, including review of AI regulatory posture, material risks, and program effectiveness at least quarterly.", "Designate an executive-level owner for AI compliance reporting who is responsible for preparing board-level AI compliance dashboards and presenting them at each committee meeting.", "Define AI compliance KPIs and thresholds for board reporting, including open regulatory obligations, material incidents, and program health indicators.", "Embed AI compliance accountability into executive performance evaluation criteria and document in role descriptions." ], "compliance_officer": { "summary": "The CCO must ensure board-level reporting is substantive \u2014 not a checkbox. Reports must convey material risks with sufficient context for board members to exercise meaningful oversight.", "actions": [ "Prepare and present an AI compliance dashboard to the Audit and Risk Committee at every quarterly meeting.", "Escalate material AI compliance incidents to the board chair within 24 hours of identification.", "Maintain a register of all board resolutions and committee mandates related to AI compliance accountability." ], "metrics": [ "Board reporting cadence adherence: target 100% of quarterly cycles.", "Material incident escalation to board within 24 hours: target 100%." ], "failure_signals": [ "Board has not received an AI compliance report in more than 90 days.", "No board resolution assigning AI compliance oversight exists.", "CCO has not presented to the board or Audit Committee in two or more consecutive quarters." ] }, "legal_counsel": { "summary": "Board accountability for AI compliance is increasingly a legal requirement in regulated industries and jurisdictions, and formal documentation of accountability reduces directors' liability exposure.", "actions": [ "Draft board resolutions assigning AI compliance oversight to the appropriate committee with clear mandate language.", "Advise on director duty-of-care requirements as they relate to AI regulatory compliance.", "Review executive role descriptions to ensure AI compliance accountability is legally and operationally sound." ], "failure_signals": [ "No board resolution establishing AI compliance oversight exists.", "Director duty-of-care analysis has not considered AI regulatory obligations.", "Role charters do not include AI compliance accountability." ] }, "executive": { "summary": "Board members and C-suite leaders must treat AI compliance accountability as a core governance obligation, not a delegated technical function.", "actions": [ "Participate in or chair Audit and Risk Committee reviews of AI compliance posture.", "Ensure AI compliance is on the board's annual agenda and review cycle.", "Hold executives accountable for AI compliance performance through evaluation criteria." ], "failure_signals": [ "AI compliance is not an agenda item at Audit and Risk Committee meetings.", "No executive has AI compliance as a formal performance objective.", "Board members cannot articulate the organization's top two AI compliance risks." ] }, "grc_auditor": { "summary": "Audit must verify that board-level accountability is operationally real \u2014 backed by documented resolutions, meeting records, and evidence of substantive oversight.", "actions": [ "Review board resolutions, committee charters, and meeting minutes for evidence of AI compliance oversight.", "Interview at least two board members or committee members to test their understanding of AI compliance obligations.", "Verify that AI compliance dashboard reports were presented and discussed at each required committee meeting." ], "metrics": [ "Board reporting cadence: 100% of required meetings include AI compliance item.", "Material incident escalation timeliness: target 100% within 24 hours." ], "failure_signals": [ "Meeting minutes do not reference AI compliance in quarterly committee sessions.", "No board resolution exists assigning AI compliance accountability.", "Board members interviewed cannot identify current material AI compliance risks." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Board-level AI compliance accountability is rarely formalized; most enterprises delegate entirely to operational teams without board visibility." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Board of Directors", "Executive Leadership", "Legal & Compliance", "GRC Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a75.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a75.1 requires top management to demonstrate leadership and commitment by taking accountability for the effectiveness of the compliance management system. This control directly operationalizes that requirement through formal board resolutions and executive accountability assignments.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 1 \u2014 Board Oversight", "fit": "direct", "rationale": "COSO ERM requires the board to exercise oversight of risk including compliance risk, and to set the tone from the top. Formal board accountability structures for AI compliance directly implement this governance requirement.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Article 26", "fit": "direct", "rationale": "EU AI Act Article 26 imposes obligations on deployers of high-risk AI systems including ensuring human oversight and taking appropriate corrective actions. Board-level accountability structures are the organizational mechanism for ensuring these deployer obligations are met.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "MEA02", "fit": "direct", "rationale": "COBIT 2019 MEA02 requires management of the system of internal controls, including board and senior management oversight and accountability for control effectiveness. AI compliance accountability structures directly satisfy this management practice.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC1.1", "fit": "partial", "rationale": "SOC 2 TSC CC1.1 requires the board to exercise oversight responsibility, including oversight of the design and operating effectiveness of internal controls. AI compliance accountability at the board level supports the SOC 2 control environment component.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "direct", "rationale": "The Senior and Board-Level Accountability for AI Compliance control requires documented board visibility into compliance posture with meaningful, quantifiable program effectiveness metrics. Microsoft Purview Compliance Manager's Compliance Score provides a real-time, quantitative board-level compliance posture indicator across applicable regulatory frameworks, while Improvement Action tracking surfaces material gaps requiring executive attention. These capabilities directly satisfy the board reporting requirement by providing standardized, evidence-backed dashboards that replace narrative-only compliance reporting with scored, auditable assessments.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Responsible Scaling Officer", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's Responsible Scaling Officer construct \u2014 a named executive accountable for policy compliance, with defined escalation to leadership \u2014 is the provider-side pattern CG-03 requires enterprises to mirror: formal board and C-suite accountability for AI compliance risks.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "The Senior and Board-Level Accountability for AI Compliance control requires C-suite accountability for material AI compliance risks, including those arising from vendor relationships with regulatory implications. OpenAI's Enterprise DPA and service terms are executed at the enterprise contracting level and impose data processing and jurisdiction-specific obligations that represent material compliance exposure requiring executive visibility and reporting to the board. This is a partial fit because it establishes accountability obligations at the vendor contract layer that must flow into board-level AI compliance reporting.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "The Senior and Board-Level Accountability for AI Compliance control requires documented reporting lines from compliance functions to the board with verifiable evidence of governance effectiveness. Okta Identity Governance's governance reporting and Access Certifications capabilities produce compliance evidence for identity-related decisions\u2014access certification completion records, policy exception approvals, escalation outcomes\u2014that support the upward reporting chain and provide the board with verifiable records of identity-layer compliance governance effectiveness. This is a partial fit because it covers the identity governance layer of the accountability reporting structure rather than the full board-level compliance posture.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-03", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The board of directors has a formal, documented mandate for AI compliance oversight via committee resolution, an executive owner is designated in their role charter with AI compliance accountability, and at least one quarterly board compliance report has been presented within the current 90-day window with meeting minutes documenting AI compliance as a substantive agenda item and material risks discussed.", "evidence_required": [ "board_resolution_document with committee_name, effective_date, scope (AI compliance oversight mandate), and authorizing_signatories confirming formal assignment of AI compliance oversight", "executive_role_charter or position_description for CCO or designated executive containing explicit AI compliance accountability language and board reporting obligation, with effective_date and incumbent name", "compliance_committee_meeting_minutes from each of the prior four quarters documenting AI compliance agenda item, attendance by designated executive, and material risks discussed or acknowledged", "ai_compliance_dashboard report presented to board, timestamped within the prior 90 days, with KPI section, regulatory obligation status, and material risk disclosures" ], "machine_tests": [ "Query governance document registry for board_resolution with scope='ai_compliance_oversight' \u2192 assert document exists with effective_date populated, committee_name present, and at least one authorizing_signatory", "Query HR or role-management system for executive role matching designated AI compliance owner \u2192 assert record contains ai_compliance_accountability=true and board_reporting_obligation documented with review_date within 12 months", "Query compliance committee meeting records for the prior 90 days \u2192 assert at least one meeting_minutes record with agenda_item containing 'AI Compliance' and presenter_role matching designated executive" ], "human_review": [ "Interview at least two board committee members to confirm they can articulate the organization's top AI compliance risks and when they last received a substantive AI compliance briefing with outcome-based metrics", "Review board resolution and committee mandate language for substantive AI compliance scope rather than a generic 'risk oversight' delegation that does not name AI systems or regulatory frameworks", "Verify that the AI compliance dashboard presented to the board includes outcome-based indicators (open regulatory obligations, incident frequency, remediation lag) rather than exclusively activity-based metrics (training completion, policy review counts)" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Delegating all AI compliance oversight to the CISO or technology team without a formal board-level mandate, leaving the Audit and Risk Committee uninformed of AI regulatory exposure", "Producing AI compliance dashboards for the board that consist solely of training completion rates and policy review counts without regulatory obligation status or material risk disclosures", "Treating a single line item in an annual enterprise risk report as equivalent to quarterly substantive AI compliance board reporting with named obligations and risk thresholds", "Assigning AI compliance accountability to a junior GRC role without board-level reporting authority, creating an accountability gap at the executive layer that regulators will identify during enforcement inquiries", "Creating a board resolution that assigns AI compliance to 'IT Risk' without defining reporting cadence, escalation triggers, or the scope of AI systems and regulatory frameworks covered" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-04", "layer": "CG", "plane": "control", "name": "Compliance Risk Appetite Definition", "plain": "The organization must formally define and document its compliance risk appetite \u2014 the maximum level of compliance risk it is willing to accept \u2014 including quantitative and qualitative thresholds for different categories of regulatory obligation, and the specific conditions that trigger escalation, remediation, or deployment halt.", "threat": { "tags": [ "undefined-risk-appetite", "threshold-ambiguity", "uncontrolled-regulatory-exposure", "inconsistent-enforcement" ], "desc": "Without a defined compliance risk appetite, individual teams make inconsistent judgments about acceptable regulatory exposure. AI deployments proceed without a clear standard for when risk is too high. Enforcement actions reveal that the organization had no basis for the risk decisions it made, eliminating defenses and signaling systemic governance failure to regulators." }, "standard": [ { "id": "coso_erm", "section": "Component 2", "title": "Strategy and Objective-Setting \u2014 risk appetite and tolerance definition" }, { "id": "iso_37301", "section": "\u00a76.1", "title": "Actions to address risks and opportunities \u2014 risk appetite integration" }, { "id": "cobit_2019", "section": "APO12", "title": "Manage Risk \u2014 risk appetite and threshold definition" }, { "id": "eu_ai_act", "section": "Article 9", "title": "Risk management system \u2014 acceptable risk level determination" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-04 Compliance Risk Appetite Definition control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-04 Compliance Risk Appetite Definition control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-04 Compliance Risk Appetite Definition control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-04 Compliance Risk Appetite Definition control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define compliance risk appetite at three levels: (1) enterprise level (board-approved maximum exposure across all regulatory frameworks); (2) domain level (framework-specific thresholds, e.g., GDPR, EU AI Act, sector regulators); (3) system level (per-AI-deployment risk tolerance). Establish a documented trigger matrix specifying required actions at each risk level.", "steps": [ "Convene the Compliance Committee to define and ratify compliance risk appetite statements covering regulatory, reputational, and financial dimensions of non-compliance for AI systems.", "Translate the risk appetite into quantitative thresholds (e.g., maximum number of open critical findings, maximum remediation lag in days, maximum financial exposure as a percentage of revenue) and qualitative criteria.", "Document a trigger matrix mapping risk levels to required actions: (green) monitor; (amber) escalate to CCO; (red) escalate to board, consider deployment pause.", "Integrate the risk appetite and trigger matrix into AI system approval workflows so deployment decisions reference documented thresholds." ], "compliance_officer": { "summary": "The risk appetite definition is the CCO's operational mandate. Without it, compliance officers cannot make principled deployment decisions or escalation recommendations.", "actions": [ "Lead the risk appetite definition process with input from Legal, Finance, and the business, and obtain board ratification.", "Ensure the trigger matrix is embedded in AI deployment approval workflows.", "Review and update risk appetite statements annually or when material regulatory changes occur." ], "metrics": [ "Risk appetite statement coverage for all applicable regulatory frameworks: target 100%.", "Trigger matrix integrated into AI deployment workflows: target 100% of production AI systems." ], "failure_signals": [ "Risk appetite has not been formally documented or board-approved.", "No trigger matrix exists or it is not integrated into deployment processes.", "Risk appetite has not been reviewed in more than 18 months." ] }, "legal_counsel": { "summary": "Risk appetite statements must accurately reflect legal exposure and use legally defensible language that does not inadvertently admit to intentional non-compliance.", "actions": [ "Review risk appetite statements for legal accuracy and ensure they reflect current regulatory requirements.", "Advise on language in trigger matrices to ensure 'acceptable risk' thresholds do not create admissions in litigation or enforcement.", "Ensure risk appetite covers jurisdictional differences in regulatory requirements." ], "failure_signals": [ "Risk appetite statements use language that could be construed as accepting known legal violations.", "Jurisdictional differences in regulatory requirements are not reflected in risk appetite.", "Legal counsel has not reviewed risk appetite in more than 12 months." ] }, "executive": { "summary": "The board must formally approve the compliance risk appetite as it defines the boundaries of acceptable regulatory exposure for the entire organization.", "actions": [ "Review and approve the compliance risk appetite statements at least annually.", "Ensure the risk appetite is consistent with the organization's overall risk appetite framework.", "Receive reporting on how current compliance risk compares to the approved appetite." ], "failure_signals": [ "Compliance risk appetite has not received board approval.", "Risk appetite is inconsistent with the enterprise risk appetite framework.", "Board has not reviewed compliance risk appetite in 18+ months." ] }, "grc_auditor": { "summary": "Audit must verify that the risk appetite is documented, approved, operationalized, and consistently applied across AI deployment decisions.", "actions": [ "Obtain and review the board-approved compliance risk appetite statements and trigger matrix.", "Test operationalization by sampling five recent AI deployment decisions and verifying they referenced the risk appetite thresholds.", "Verify annual review completion and board approval records." ], "metrics": [ "Compliance risk appetite documentation completeness: 100%.", "AI deployment decisions referencing risk appetite: target 100% of sampled decisions." ], "failure_signals": [ "Risk appetite is undocumented or not board-approved.", "AI deployment decisions do not reference risk appetite thresholds.", "No evidence of annual review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Compliance risk appetite for AI is almost universally undefined; even organizations with strong general risk appetite frameworks have not extended them to AI regulatory exposure." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Executive Leadership", "Legal & Compliance", "Risk Management", "GRC Team" ], "frameworks": [ { "framework": "coso_erm", "requirement_id": "Component 2 \u2014 Risk Appetite", "fit": "direct", "rationale": "COSO ERM Component 2 is the primary authoritative source for risk appetite definition methodology, requiring organizations to define acceptable variation in performance relative to business objectives. The compliance risk appetite definition directly implements COSO ERM Component 2 for regulatory obligations.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "iso_37301", "requirement_id": "\u00a76.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a76.1 requires the organization to determine compliance risks and opportunities and to take actions to address them. Defining a risk appetite provides the threshold against which compliance risks are assessed and prioritized.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "APO12.02", "fit": "direct", "rationale": "COBIT 2019 APO12 Manage Risk requires defining risk appetite and tolerance and ensuring that risk responses align with these thresholds. A compliance risk appetite with quantitative triggers is the direct implementation of APO12 for regulatory risk.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 9(2)", "fit": "partial", "rationale": "EU AI Act Article 9(2) requires risk management systems to identify and analyze known and reasonably foreseeable risks and to evaluate the risks based on appropriate risk metrics. A compliance risk appetite provides the acceptance criteria against which these AI-specific risks are evaluated.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC3.2", "fit": "partial", "rationale": "SOC 2 TSC CC3.2 requires the organization to assess risks to the achievement of objectives, which includes compliance objectives. Risk appetite definitions support the risk assessment process required under the SOC 2 CC3 Common Criteria.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "direct", "rationale": "The Compliance Risk Appetite Definition control requires formally defined quantitative and qualitative thresholds for acceptable regulatory exposure. Microsoft Purview Compliance Manager's Compliance Score provides a quantitative baseline against which risk appetite thresholds can be formally defined\u2014for example, specifying that a score below 70% for GDPR or EU AI Act assessments triggers mandatory escalation. Control mapping enables identification of which unmapped controls represent acceptable residual risk versus those requiring remediation, directly operationalizing the risk appetite decision-making and threshold definition process across regulatory frameworks.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Thresholds", "fit": "direct", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's Capability Thresholds are an explicit, published formalization of AI risk appetite \u2014 quantified thresholds beyond which additional safeguards are mandatory \u2014 and CG-04's compliance risk appetite definition applies the same threshold-with-consequences structure to regulatory obligations.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Usage Policies", "fit": "partial", "rationale": "The Compliance Risk Appetite Definition control requires the organization to document conditions that represent zero-tolerance compliance risk, triggering mandatory escalation. OpenAI's Usage Policies and Data residency commitments define hard boundaries for permissible use and data handling that establish the compliance floor for organizations using OpenAI services\u2014representing non-negotiable risk appetite limits that must be reflected in the enterprise compliance risk appetite definition. This is a partial fit because it establishes vendor-imposed risk floor constraints rather than enabling the full enterprise-level risk appetite framework design.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access Certifications", "fit": "partial", "rationale": "Okta Identity Governance's Access Certifications let organizations set certification campaign frequency and scope according to risk, an operational expression of risk appetite in the identity layer. CG-04's compliance risk appetite definition requires the same explicit calibration of review intensity to obligation risk.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-04", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A board-ratified compliance risk appetite statement exists with quantitative thresholds (maximum open critical findings, maximum remediation lag in days) and qualitative criteria for each applicable regulatory framework, and a trigger matrix mapping risk levels to required escalation or deployment-halt actions is documented and embedded in AI deployment approval workflows, with annual board review confirmed within the last 12 months.", "evidence_required": [ "board_ratified_risk_appetite_statement containing quantitative_thresholds per regulatory framework, qualitative_criteria, approval_date, and board_signatory \u2014 confirmed reviewed and approved within the last 12 months", "compliance_trigger_matrix document defining green/amber/red risk levels with threshold values, required_actions at each level (monitor/escalate-to-CCO/deployment-pause), responsible_role, and response SLA", "ai_deployment_approval_records for at least three recent production deployments each showing explicit risk_appetite_reference field with threshold_check_outcome (pass/escalate/hold) documented", "annual_review_record confirming risk appetite was presented to and ratified by the board within the last 12 months, including any revision history and legal counsel sign-off date" ], "machine_tests": [ "Query risk appetite register for a board-approved document with scope='ai_compliance' \u2192 assert approval_date is within the last 12 months and quantitative_thresholds are populated for each regulatory framework in scope", "Query AI deployment approval workflow records for the last five production deployments \u2192 assert each record contains risk_appetite_check with threshold_value, actual_value, and outcome fields present and non-null", "Query trigger matrix document for red-level entry \u2192 assert blocking_action is defined as 'deployment-pause' or 'board-escalation' with responsible_role and response_SLA populated" ], "human_review": [ "Assess whether risk appetite thresholds are substantively tied to specific regulatory frameworks in scope (EU AI Act, GDPR, sector regulations) rather than generic percentage statements disconnected from actual regulatory obligations", "Verify that the trigger matrix has been embedded in AI deployment approval workflows by walking through a recent deployment decision with the CCO and confirming the threshold check occurred and was documented", "Review risk appetite statements for legal counsel sign-off confirming language does not inadvertently admit to accepting known violations or create admissions that could be used in enforcement proceedings" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Defining compliance risk appetite at the enterprise level as a single generic 'low risk tolerance' statement without quantitative thresholds specific to each applicable regulatory framework and AI system category", "Operating AI deployment workflows without an embedded trigger matrix reference, leaving risk appetite thresholds as a paper document that is never consulted during actual deployment decisions", "Setting risk appetite thresholds so permissive (e.g., 'up to 30 open critical findings acceptable') that they provide no meaningful constraint on deployment decisions or escalation triggers before regulatory exposure materializes", "Allowing risk appetite statements to remain unchanged for 18+ months despite material regulatory changes such as EU AI Act applicability dates, new sector guidance, or significant expansion of the AI system portfolio", "Using a financial risk appetite framework verbatim for compliance risk without adapting thresholds to reflect non-financial regulatory obligations where remediation lag \u2014 not financial loss \u2014 is the primary measurable exposure metric" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-05", "layer": "CG", "plane": "control", "name": "Compliance Program Resourcing", "plain": "The organization must ensure the compliance program has adequate and documented resources \u2014 including budget, qualified staffing, and appropriate tooling \u2014 to identify, assess, and satisfy all compliance obligations across applicable regulatory frameworks for AI systems. Resource adequacy must be formally reviewed annually and any identified gaps must be escalated to executive leadership.", "threat": { "tags": [ "resource-starvation", "compliance-program-degradation", "tooling-gap", "coverage-understaffing" ], "desc": "Under-resourced compliance programs fail silently. Obligations accumulate, reviews are deferred, and coverage gaps widen without triggering visible alarms. When enforcement actions arrive, resource constraints do not constitute a legal defense and often signal to regulators that the organization treated compliance as a cost center rather than an operational requirement. AI regulatory obligations require specialized expertise that generalist compliance teams cannot absorb without deliberate investment." }, "standard": [ { "id": "iso_37301", "section": "\u00a77.1", "title": "Resources \u2014 ensuring adequate resources for the compliance management system" }, { "id": "coso_erm", "section": "Component 1", "title": "Governance and Culture \u2014 attracting and retaining capable individuals" }, { "id": "eu_ai_act", "section": "Article 17", "title": "Quality management system \u2014 resourcing requirements for compliance" }, { "id": "cobit_2019", "section": "APO07", "title": "Manage Human Resources \u2014 compliance staffing and capability planning" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-05 Compliance Program Resourcing control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CG-05 Compliance Program Resourcing control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CG-05 Compliance Program Resourcing control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-05 Compliance Program Resourcing control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-05 Compliance Program Resourcing control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define compliance program resource requirements across three dimensions: (1) personnel \u2014 headcount, qualifications, and coverage ratios by regulatory domain; (2) budget \u2014 annual compliance program budget as a proportion of total regulatory exposure; (3) tooling \u2014 compliance management platforms, monitoring tools, and assessment capabilities. Document resource adequacy annually with a formal gap analysis.", "steps": [ "Conduct an annual compliance program resource assessment that inventories current personnel, budget, and tools against the full scope of regulatory obligations and identifies coverage gaps.", "Define minimum staffing ratios and qualification requirements for AI-specific compliance roles (e.g., AI regulatory counsel, AI risk analyst, compliance engineer) and include these in the resource plan.", "Establish a budget allocation process that ties compliance program funding to the inventory of regulatory obligations and the risk appetite \u2014 higher-risk regulatory environments require proportionally more investment.", "Present the resource assessment and identified gaps to the CCO and executive leadership annually, with a remediation plan and timeline for any gaps that exceed acceptable coverage thresholds." ], "compliance_officer": { "summary": "The CCO must proactively identify and escalate resource constraints before they result in compliance coverage gaps, not after a regulatory event reveals them.", "actions": [ "Conduct and document an annual resource assessment covering headcount, qualifications, budget, and tooling against the full regulatory obligation inventory.", "Present resource gaps and remediation requirements to executive leadership with timeline and cost estimates.", "Maintain a staffing plan that accounts for planned regulatory expansions and AI deployment growth." ], "metrics": [ "Compliance staffing coverage ratio: target 100% of regulatory obligations covered by qualified staff.", "Annual resource assessment completion: target 100% within Q1 of each fiscal year." ], "failure_signals": [ "Regulatory obligations lack named staff owners.", "Compliance budget has not been reviewed against regulatory obligation growth in 18+ months.", "AI-specific compliance roles are vacant or filled by unqualified staff." ] }, "executive": { "summary": "Executive leadership must treat compliance program resourcing as a material investment decision that reflects the organization's risk appetite and regulatory exposure.", "actions": [ "Review and approve the annual compliance program resource plan, including budget allocation and headcount.", "Ensure that AI deployment growth plans account for corresponding compliance program resourcing requirements.", "Escalate compliance resourcing gaps that exceed risk appetite thresholds to the board." ], "failure_signals": [ "Compliance program budget has not grown in proportion to AI regulatory obligation expansion.", "AI deployment roadmap does not include compliance resourcing analysis.", "Resource gaps have not been escalated to the board despite exceeding thresholds." ] }, "grc_auditor": { "summary": "Internal audit must assess whether the compliance program is resourced proportionally to its obligations and whether resource constraints are being identified and addressed.", "actions": [ "Review the annual resource assessment and verify it covers all applicable regulatory frameworks.", "Interview compliance staff to assess workload and identify coverage gaps not reflected in official reporting.", "Compare compliance program budget against industry benchmarks and regulatory obligation scope." ], "metrics": [ "Resource assessment completion: 100% annually.", "Identified resource gaps with documented remediation plans: target 100%." ], "failure_signals": [ "Resource assessment has not been completed in 18+ months.", "Compliance staff interviews reveal unacknowledged coverage gaps.", "No remediation plans exist for identified resource gaps." ] }, "it_operations": { "summary": "IT Operations must ensure compliance tooling is adequately provisioned, maintained, and integrated into operational workflows to support the compliance program.", "actions": [ "Maintain and update compliance management platform licenses and integrations.", "Ensure monitoring tools cover all AI systems within regulatory scope.", "Provide compliance team with technical support for tooling that supports regulatory evidence collection." ], "failure_signals": [ "Compliance management platforms have expired licenses or unsupported versions.", "Monitoring tools do not cover all in-scope AI systems.", "Evidence collection tooling produces gaps in audit trails." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Compliance program resourcing is rarely formally assessed against AI regulatory obligations; most organizations rely on general compliance teams without AI-specific expertise." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Legal & Compliance", "Executive Leadership", "Finance", "GRC Team" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a77.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a77.1 explicitly requires top management to determine and provide the resources needed for the establishment, implementation, maintenance, and continual improvement of the compliance management system. This control operationalizes \u00a77.1 through formal resourcing assessment and budget allocation processes.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 1 \u2014 Attract and Retain Capable Individuals", "fit": "direct", "rationale": "COSO ERM Component 1 requires the organization to attract, develop, and retain individuals aligned with the objectives of the entity. Defining staffing requirements and qualifications for AI compliance roles directly implements this principle.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Article 17(1)(l)", "fit": "direct", "rationale": "EU AI Act Article 17(1)(l) requires the quality management system of high-risk AI providers to cover resource management, including security-of-supply related measures. Adequate compliance program resourcing implements this quality management system element for high-risk AI providers.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "cobit_2019", "requirement_id": "APO07", "fit": "partial", "rationale": "COBIT 2019 APO07 (Manage Human Resources) requires managing the acquisition, development, and retention of HR to meet enterprise objectives. Applying APO07 principles to compliance staffing ensures the compliance function has appropriately qualified personnel for AI regulatory obligations.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "soc2", "requirement_id": "CC1.4", "fit": "partial", "rationale": "SOC 2 TSC CC1.4 requires the organization to demonstrate commitment to attracting, developing, and retaining competent individuals. Compliance program staffing plans and qualification requirements directly support the CC1.4 competence objective.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "The Compliance Program Resourcing control requires adequate tooling to identify, assess, and satisfy compliance obligations across all applicable regulatory frameworks for AI systems. Microsoft Purview Compliance Manager directly satisfies the tooling dimension of this control by providing Assessment templates for GDPR, EU AI Act, ISO 27001, and SOC 2, Improvement Action tracking for obligation management, and Compliance Score monitoring for program health. For organizations in the Microsoft 365 ecosystem, deploying Compliance Manager constitutes a formal response to the tooling resource requirement, with audit-ready evidence that the tool is operational.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Compliance report access", "fit": "partial", "rationale": "The Compliance Program Resourcing control requires adequate resources for compliance evidence collection across all applicable frameworks, including those covering cloud infrastructure. AWS Artifact's Compliance report access and Third-party audit reports provide on-demand SOC 1/2/3, ISO 27001, FedRAMP, and PCI DSS attestations that cover the AWS infrastructure layer\u2014reducing the manual evidence collection burden and audit preparation resources the compliance program would otherwise need to maintain. This is a partial fit because it reduces the resourcing requirement for cloud infrastructure compliance evidence collection rather than addressing the full program staffing, budget, and tooling assessment.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Compliance report", "fit": "partial", "rationale": "The Compliance Program Resourcing control requires adequate tooling and documentation resources to cover all applicable compliance frameworks, including those governing cloud-hosted AI workloads. Google Cloud's Compliance reports and Certification documentation in the compliance resource center provide pre-compiled regulatory evidence for GCP's posture (ISO 27001, SOC 2, FedRAMP, GDPR), reducing the headcount and budget required to maintain compliance coverage for AI systems hosted on GCP. This is a partial fit because it reduces the resourcing burden for the cloud infrastructure compliance layer but does not address the full program staffing, budget allocation, or tooling adequacy assessment.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "The Compliance Program Resourcing control requires that compliance programs have qualified staffing and budget allocated to satisfy all AI regulatory obligations, including those from AI vendor contracts. OpenAI's Enterprise DPA and service terms impose ongoing data processing monitoring, regulatory tracking, and jurisdiction-specific compliance obligations that require dedicated qualified compliance staff to review, manage, and audit. This is a partial fit because it identifies a specific resourcing obligation that compliance programs must budget for when using OpenAI Enterprise services, rather than providing guidance on the full resource adequacy assessment methodology.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "partial", "rationale": "The Compliance Program Resourcing control requires that compliance programs have adequate tooling to execute compliance obligations efficiently without relying solely on manual headcount. Okta Identity Governance's Access Certifications campaigns and Okta Workflows automate identity-related compliance tasks\u2014periodic access reviews, segregation of duties enforcement, and audit evidence generation\u2014reducing the manual staffing burden for identity compliance program execution. This is a partial fit because it reduces the resourcing requirement for the identity layer of the compliance program rather than addressing the full multi-domain staffing, budget, and tooling adequacy assessment.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-05", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "The compliance program has a documented annual resource assessment \u2014 completed within the current fiscal year \u2014 that maps qualified headcount, allocated budget, and active tooling to each regulatory obligation in scope for AI systems, identifies any coverage gaps, and has been formally presented to executive leadership with documented gap remediation plans or explicit board-approved acceptance rationale for each unresolved gap.", "evidence_required": [ "annual_resource_assessment_report dated within the current fiscal year containing headcount_by_regulatory_domain, qualification_evidence for each AI compliance role, budget_allocation by obligation category, and tooling_inventory with coverage_scope listing in-scope AI systems", "executive_presentation_record or board_committee_minutes documenting CCO presentation of resource assessment results with named attendees and executive acknowledgment or formal approval", "staffing_plan document defining minimum qualification requirements for AI-specific compliance roles (EU AI Act specialist, AI risk analyst, compliance engineer) with named_incumbent or open_requisition for each required role", "gap_remediation_plan for each identified resource gap with owner, target_date, budget_approved status, and current_status \u2014 or a formal board-approved acceptance record for gaps accepted as residual risk", "compliance_tooling_inventory listing each platform with license_status, coverage_scope (which AI systems are covered), and last_validated_date confirming active integration with data sources" ], "machine_tests": [ "Query compliance document registry for resource_assessment with fiscal_year=current \u2192 assert document exists with completion_date within last 12 months and headcount_mapping populated for each active regulatory framework in scope", "Query role management system for each AI compliance role defined in the staffing plan \u2192 assert each role has named_incumbent or open_requisition with filled_by_date, and qualifications_verified=true for all filled roles", "Query compliance tooling inventory for each tool \u2192 assert license_status='active', coverage_verified=true, and last_validated_date within last 6 months for each tool listed" ], "human_review": [ "Interview compliance staff at two levels (CCO and an operational compliance analyst) to identify unacknowledged coverage gaps not surfaced in the official resource assessment, particularly for AI-specific regulatory obligations added in the prior 12 months", "Review whether the compliance program budget has grown proportionally to AI deployment growth and regulatory obligation expansion by comparing year-over-year budget figures against the regulatory obligation inventory count and AI system portfolio size", "Assess whether AI-specific compliance roles are genuinely qualified for EU AI Act, GDPR, and sector AI regulation by reviewing credentials and relevant prior experience, rather than being repurposed general compliance professionals without AI regulatory training" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Assigning EU AI Act compliance obligations to a general privacy counsel with no AI regulatory training and marking the coverage gap as 'closed' based on headcount alone without verifying substantive qualification", "Conducting a resource assessment that lists tools and headcount without mapping them to specific regulatory obligations, making it impossible to identify which obligations lack qualified coverage", "Treating the resource assessment as a one-time baseline rather than an annual process that must be updated as new AI systems are deployed and the regulatory obligation scope expands", "Maintaining compliance tooling licenses that have expired or lost active integrations with AI system data sources without updating the resource adequacy assessment to reflect the resulting evidence collection gap", "Presenting resource gaps to executive leadership without documented remediation plans or explicit board-approved acceptance of residual coverage risk, allowing gaps to persist indefinitely without governance accountability" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-06", "layer": "CG", "plane": "control", "name": "Compliance Incident Response", "plain": "The organization must maintain documented procedures for responding to compliance incidents including regulatory inquiries, enforcement actions, and material compliance failures affecting AI systems. Procedures must define trigger conditions, response roles, notification timelines, containment actions, and post-incident review requirements.", "threat": { "tags": [ "regulatory-breach", "enforcement-action", "notification-failure", "uncoordinated-response" ], "desc": "Uncoordinated responses to compliance incidents compound initial violations. Late regulatory notifications trigger additional penalties. Public disclosures made without legal review create new liability. When multiple teams respond independently without a defined playbook, the organization's response reveals governance failure as clearly as the underlying incident. AI systems present novel compliance incident scenarios \u2014 discriminatory outputs, model failures, unauthorized data use \u2014 that general incident response procedures have not anticipated." }, "standard": [ { "id": "gdpr", "section": "Article 33", "title": "Notification of a personal data breach to the supervisory authority" }, { "id": "iso_37301", "section": "\u00a710.2", "title": "Nonconformity and corrective action \u2014 compliance failure response" }, { "id": "eu_ai_act", "section": "Article 73", "title": "Reporting of serious incidents" }, { "id": "nist_csf", "section": "RS.CO", "title": "Respond \u2014 Communications during incident response" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-06 Compliance Incident Response control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Develop a Compliance Incident Response Playbook that categorizes incident types (regulatory inquiry, enforcement action, material breach, AI-specific incident), defines severity levels, assigns response roles, specifies notification timelines for each regulatory framework, and documents containment and remediation actions. Conduct tabletop exercises at least annually.", "steps": [ "Categorize compliance incident types relevant to AI systems including: discriminatory AI output, unauthorized AI data processing, AI system failure with regulatory consequence, regulatory inquiry, formal enforcement action, and material audit finding.", "Define severity levels (P1-P4) with corresponding escalation paths, notification obligations, and response timeframes for each incident type and regulatory framework (GDPR 72-hour breach notification, EU AI Act serious incident reporting, sector-specific requirements).", "Assign incident response roles including Incident Commander (CCO), Legal Lead (General Counsel), Communications Lead, Technical Lead (CTO), and external counsel liaison.", "Conduct annual tabletop exercises simulating at least one AI-specific compliance incident scenario and document lessons learned and playbook updates." ], "compliance_officer": { "summary": "The CCO serves as Incident Commander for material compliance incidents and must ensure procedures are maintained, tested, and actionable \u2014 not theoretical documents that fail under pressure.", "actions": [ "Maintain the Compliance Incident Response Playbook with current regulatory notification timelines and contact information for all relevant regulators.", "Activate incident response procedures within defined trigger thresholds and document all actions taken.", "Lead post-incident reviews and implement lessons learned within 30 days of incident closure." ], "metrics": [ "Regulatory notification SLA compliance: target 100%.", "Annual tabletop exercise completion: target 100%.", "Post-incident review completion within 30 days: target 100%." ], "failure_signals": [ "Playbook does not include AI-specific incident scenarios.", "Regulatory notification timelines have not been reviewed in 12+ months.", "No tabletop exercise has been conducted in the last 18 months." ] }, "legal_counsel": { "summary": "Legal counsel must be embedded in compliance incident response procedures to ensure notifications are legally sound, privilege is preserved, and responses do not create additional liability.", "actions": [ "Review and maintain notification templates for each applicable regulator with legally reviewed language.", "Ensure attorney-client privilege protections are invoked from the first moment of incident response.", "Provide real-time legal guidance during active enforcement actions and regulatory inquiries." ], "failure_signals": [ "Notification templates have not been reviewed by legal counsel.", "Incident response procedures do not include privilege protection steps.", "Legal counsel is not in the immediate notification chain for P1/P2 incidents." ] }, "it_operations": { "summary": "IT Operations must be prepared to provide rapid technical evidence collection, system logs, and AI model artifacts upon activation of compliance incident response.", "actions": [ "Maintain evidence preservation capabilities for AI systems including log retention, model version snapshots, and inference records.", "Support the technical investigation workstream during compliance incidents.", "Ensure incident response tooling integrations are tested and functional prior to a live incident." ], "failure_signals": [ "Log retention periods do not cover regulatory investigation windows.", "AI model version artifacts are not preserved in a retrievable format.", "Evidence collection has not been tested in the last 12 months." ] }, "executive": { "summary": "Executive leadership must be informed rapidly during material compliance incidents and must authorize any public communications or regulatory responses that carry organizational commitment.", "actions": [ "Ensure the escalation matrix routes P1 compliance incidents to the CEO and board chair within 4 hours.", "Authorize all formal regulatory responses and public communications.", "Participate in post-incident reviews for P1 and P2 incidents." ], "failure_signals": [ "P1 incidents have reached regulators before executive leadership was informed.", "CEO is not in the notification chain for enforcement actions.", "Post-incident reviews are not occurring for material incidents." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI-specific compliance incident scenarios are rarely included in incident response playbooks; most organizations rely on general breach response procedures that do not address AI regulatory notification obligations." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise" ], "implementers": [ "Legal & Compliance", "GRC Team", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Article 33 and Article 34", "fit": "direct", "rationale": "GDPR Articles 33 and 34 impose mandatory breach notification timelines (72 hours to supervisory authority, without undue delay to data subjects) that are directly operationalized by compliance incident response procedures. AI systems that process personal data are subject to these notification obligations.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Article 73", "fit": "direct", "rationale": "EU AI Act Article 73 requires providers of high-risk AI systems to report serious incidents to the market surveillance authorities within defined timelines \u2014 no later than 15 days after awareness, 2 days for widespread infringement or a serious incident involving critical infrastructure, and 10 days in the event of the death of a person \u2014 building on the post-market monitoring required by Article 72. Compliance incident response procedures must address these AI-specific notification obligations.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_37301", "requirement_id": "\u00a710.2", "fit": "direct", "rationale": "ISO 37301:2021 \u00a710.2 requires the organization to react to noncompliances, evaluate the need for corrective action, identify root causes, implement the actions needed, and review the effectiveness of actions taken. Compliance incident response procedures directly implement these corrective action requirements.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_csf", "requirement_id": "RS.CO and RS.AN", "fit": "partial", "rationale": "NIST CSF 2.0 RS.CO requires coordinated response activities and RS.AN requires analysis during incident response. While NIST CSF is security-focused, its incident response communication and analysis principles apply equally to compliance incident response coordination.", "normative_force": "voluntary-standard", "source_version": "2.0", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 4 \u2014 Review and Revision", "fit": "partial", "rationale": "COSO ERM Component 4 requires the organization to review risk and performance and revise its risk management approach based on changes. Post-incident reviews following compliance incidents directly implement this review and revision requirement.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "microsoft_compliance", "requirement_id": "Improvement Action", "fit": "direct", "rationale": "The Compliance Incident Response control requires documented procedures covering notification timelines, response roles, and containment actions for regulatory incidents affecting AI systems. Microsoft Purview Compliance Manager's Improvement Actions for GDPR, EU AI Act, and SOC 2 include specific incident notification and breach response actions\u2014mapping regulatory notification timelines (e.g., GDPR Article 33's 72-hour requirement) and response obligations to the organization's control framework. This directly supports the procedure documentation requirement by providing framework-specific incident response guidance integrated into the compliance management workflow.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "AWS security posture documentation", "fit": "partial", "rationale": "The Compliance Incident Response control requires procedures that address notification timelines and response roles when compliance incidents involve cloud infrastructure. AWS Artifact's security posture documentation and Artifact agreements specify AWS's incident notification obligations to enterprise customers\u2014including timelines within which AWS will notify organizations of security events with compliance implications\u2014that enterprises must integrate into their compliance incident response playbooks for AWS-hosted AI workloads. This is a partial fit because it addresses the cloud provider's incident notification obligations as mandatory inputs to enterprise incident response procedures rather than defining the full response framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Shared responsibility matrix", "fit": "partial", "rationale": "The Compliance Incident Response control requires incident response procedures that address regulatory notification obligations across all applicable jurisdictions and infrastructure layers. Google Cloud's Shared responsibility matrix and Regulatory guidance define which incident response and breach notification obligations belong to Google versus the customer for GCP-hosted AI workloads\u2014including GDPR breach notification timelines\u2014that enterprises must incorporate into their compliance incident response playbooks. This is a partial fit because it addresses the cloud-layer responsibility partition for incident response rather than the full enterprise compliance incident response framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "ASL-3 Deployment Standard", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's deployment safeguards include rapid response when safeguards prove insufficient \u2014 a provider-side escalation pattern relevant to CG-06; the enterprise's own incident response must nonetheless satisfy its statutory notification obligations (GDPR Art. 33, EU AI Act Art. 73) independently of provider processes.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "The Compliance Incident Response control requires procedures that address regulatory notification timelines for incidents involving AI service provider data processing. OpenAI's Enterprise DPA includes data breach notification clauses specifying the procedures and timelines under which OpenAI will notify enterprise customers of data incidents\u2014obligations that enterprises must incorporate into their compliance incident response procedures to ensure regulatory notification requirements under GDPR and other frameworks are met end-to-end. This is a partial fit because it covers the AI vendor breach notification layer of compliance incident response rather than the full enterprise incident response procedure framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "partial", "rationale": "The Compliance Incident Response control requires documented procedures including evidence collection and containment verification phases of the incident response lifecycle. Okta Identity Governance's Audit reporting provides comprehensive pre-incident audit trails\u2014authentication events, access grants, governance decisions\u2014that are essential evidence artifacts in compliance incident investigations, particularly for unauthorized access incidents with regulatory notification implications. This is a partial fit because it supports the evidence collection and investigation phase of compliance incident response rather than defining the full incident response procedure framework.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-06", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A documented Compliance Incident Response Playbook exists covering at least four AI-specific incident scenario types (discriminatory AI output, unauthorized AI data processing, regulatory inquiry, enforcement action), defines severity levels P1-P4 with named role assignments and notification timelines specific to each applicable regulatory framework (GDPR 72h, EU AI Act Article 73), and has been exercised in a tabletop simulation of an AI compliance scenario within the last 18 months with documented lessons-learned outcomes.", "evidence_required": [ "compliance_incident_response_playbook document containing ai_incident_scenario_list (minimum four types), severity_level_definitions (P1-P4) with escalation_paths, regulatory_notification_timeline_matrix per framework with specific SLAs, named_role_assignments for Incident Commander/Legal Lead/Technical Lead, and containment_action_steps", "tabletop_exercise_record dated within the last 18 months documenting scenario_type (must be AI compliance scenario), participants by named role, findings, and lessons_learned items with remediation_action_owner and completion_status", "notification_template_set for each applicable regulatory authority with legal_counsel_review_date within the last 12 months confirming language is current and jurisdiction-appropriate", "incident_response_log for any compliance incidents in the last 24 months showing incident_id, severity_level, trigger_timestamp, notification_sent_timestamp, regulatory_authority_notified, and SLA_compliance status for each framework-governed notification" ], "machine_tests": [ "Query incident response playbook registry \u2192 assert playbook exists with last_updated_date within 12 months, ai_incident_scenarios_count >= 4, and all P1 response roles have named_incumbent populated", "Query tabletop exercise registry \u2192 assert at least one exercise record with scenario_type='ai_compliance', exercise_date within last 18 months, and lessons_learned_status='documented' with at least one remediation_action assigned", "Query incident logs for any P1/P2 incidents requiring regulatory notification \u2192 assert each incident has notification_timestamp - trigger_timestamp value within the applicable framework SLA (e.g., <= 72 hours for GDPR Article 33) and notification_status='sent'" ], "human_review": [ "Walk through a tabletop simulation of an EU AI Act Article 73 serious incident scenario to assess whether the Incident Commander and Legal Lead can execute notification steps and draft a regulator notification without requiring external counsel to draft from scratch under time pressure", "Review notification templates for each applicable regulatory authority to confirm they are pre-approved, jurisdiction-specific, and contain all legally required elements \u2014 not generic forms requiring extensive customization during an active incident", "Verify that AI-specific incident scenarios are genuinely distinct from general IT breach scenarios by examining whether the playbook addresses AI output-level incidents (e.g., discriminatory model decisions, AI system failures with regulatory consequences) that have no analog in security breach procedures" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Applying a cybersecurity breach notification playbook directly to AI compliance incidents without adding AI-specific scenarios such as discriminatory output, unauthorized model use, or EU AI Act Article 73 serious incident reporting", "Listing legal counsel as a named incident response role without confirming availability via a retainer or on-call arrangement, creating a bottleneck precisely when time-bound regulatory notifications (GDPR 72-hour, EU AI Act) are required", "Maintaining regulatory notification timelines based on guidance reviewed 18+ months ago without validating against current regulatory requirements, particularly where EU AI Act implementation guidance has evolved", "Conducting annual tabletop exercises exclusively on IT security scenarios without ever simulating a compliance incident triggered by AI system behavior, leaving the AI compliance playbook completely untested", "Treating the incident response playbook as a static document without a defined review trigger when new AI systems are deployed or new regulatory frameworks with notification obligations become applicable to the organization" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-07", "layer": "CG", "plane": "control", "name": "Compliance Program Metrics and KPIs", "plain": "The organization must define, collect, and report a structured set of compliance program metrics and KPIs at both the board level and operational level, enabling meaningful assessment of compliance program health, effectiveness, and trend direction for AI systems and obligations.", "threat": { "tags": [ "measurement-blindness", "metric-manipulation", "board-misreporting", "program-degradation" ], "desc": "Compliance programs without rigorous metrics produce the illusion of effectiveness while failing to detect deteriorating controls. Board-level reporting based on activity metrics (trainings completed, policies updated) obscures outcome metrics (incidents, regulatory findings, remediation lags). When enforcement actions occur, organizations are unable to demonstrate that their metrics program would have detected the compliance failure, further undermining their defense." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.1", "title": "Monitoring, measurement, analysis and evaluation \u2014 compliance program metrics" }, { "id": "cobit_2019", "section": "MEA01", "title": "Manage Performance and Conformance Monitoring \u2014 KPI definition and reporting" }, { "id": "coso_erm", "section": "Component 5", "title": "Information, Communication, and Reporting \u2014 performance metrics and board reporting" }, { "id": "eu_ai_act", "section": "Article 17", "title": "Quality management system \u2014 performance monitoring and measurement" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-07 Compliance Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-07 Compliance Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-07 Compliance Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-07 Compliance Program Metrics and KPIs control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define a two-tier metric framework: (1) board-level metrics (5-8 KPIs covering program health, regulatory exposure, and material incidents) reported quarterly; (2) operational metrics (15-25 indicators covering control effectiveness, obligation coverage, and remediation velocity) reported monthly. Include leading and lagging indicators and trend lines over at least four reporting periods.", "steps": [ "Define board-level KPIs for AI compliance including: open regulatory obligations rate, critical finding remediation lag, compliance incident frequency, AI system coverage rate, and policy currency rate.", "Define operational metrics covering control-level effectiveness: audit finding closure rate, AI system compliance assessment completion rate, training completion rate, regulatory monitoring coverage, and risk appetite threshold breaches.", "Implement metric collection using automated tooling where possible, with defined data sources, collection frequency, and owner responsible for each metric.", "Establish reporting cadences: board-level KPI dashboard quarterly, operational metrics to CCO monthly, and trend analysis with four-period historical view." ], "compliance_officer": { "summary": "The CCO is responsible for metric integrity \u2014 ensuring metrics reflect actual compliance program performance, not activity theater. Metrics must include outcome indicators alongside activity indicators and be resistant to manipulation.", "actions": [ "Define and maintain the metric framework with explicit definitions, data sources, and calculation methods for each KPI.", "Ensure metrics include both leading indicators (upcoming obligation deadlines, control gaps identified) and lagging indicators (incidents, regulatory findings).", "Present the board-level KPI dashboard at every Compliance Committee meeting with trend analysis." ], "metrics": [ "Board KPI reporting cadence: 100% of quarterly cycles.", "Operational metric data completeness: target 95% of metrics with current data at reporting time.", "Metric framework review: completed annually." ], "failure_signals": [ "Metrics consist exclusively of activity measures with no outcome indicators.", "Board-level KPI dashboard has not been presented in two or more consecutive quarters.", "Metric definitions are undocumented or inconsistently applied." ] }, "grc_auditor": { "summary": "Internal audit must independently verify the accuracy and completeness of compliance metrics and assess whether the metric framework provides meaningful visibility into program health.", "actions": [ "Independently verify a sample of reported metrics against underlying data sources.", "Assess whether the metric framework includes adequate outcome indicators for AI compliance.", "Review trend data to identify metric patterns inconsistent with other evidence of program health." ], "metrics": [ "Metric accuracy rate (audit-verified vs. reported): target 98%.", "Outcome indicator coverage: all critical compliance domains have at least one outcome KPI." ], "failure_signals": [ "Reported metrics are inconsistent with underlying data.", "No outcome metrics exist for any compliance domain.", "Trend data shows metric manipulation patterns." ] }, "executive": { "summary": "Executive leadership must demand metrics that enable real governance decisions, not activity reports that provide false assurance.", "actions": [ "Review and approve the board-level KPI framework annually.", "Challenge the CCO when metrics show trends inconsistent with known program challenges.", "Use metrics to drive resource allocation and risk appetite decisions." ], "failure_signals": [ "Board-level reporting consists only of completion rates and training statistics.", "Executives cannot describe what the metrics would show before a compliance failure is detected.", "Metric framework has never been challenged or revised." ] }, "it_operations": { "summary": "IT Operations must provide automated metric collection infrastructure that ensures data quality and eliminates manual reporting errors.", "actions": [ "Implement automated data collection for compliance metrics from source systems.", "Ensure compliance dashboards have reliable data pipelines with defined refresh frequencies.", "Alert on data quality issues that would affect metric accuracy." ], "failure_signals": [ "Metrics are collected manually with no automated data pipelines.", "Dashboard data is more than 48 hours stale at reporting time.", "No data quality monitoring exists for compliance metric sources." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most compliance programs rely on activity-based metrics; outcome metrics for AI compliance are rarely defined and almost never presented at board level." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "federated-enterprise", "eu-high-risk-ai" ], "implementers": [ "Legal & Compliance", "GRC Team", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.1", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.1 explicitly requires the organization to determine what needs to be monitored and measured, the methods for monitoring, measurement, analysis and evaluation, and when results shall be evaluated. This control directly operationalizes \u00a79.1 through a structured KPI framework with defined data sources and reporting cadences.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA01", "fit": "direct", "rationale": "COBIT 2019 MEA01 (Manage Performance and Conformance Monitoring) requires collecting and processing performance and conformance monitoring data and reporting on performance. The compliance program KPI framework directly implements MEA01 for the compliance management domain.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "coso_erm", "requirement_id": "Component 5 \u2014 Information, Communication, and Reporting", "fit": "direct", "rationale": "COSO ERM Component 5 requires leveraging information and technology to support effective risk management and communicating risk information to enable decision-making. Compliance program metrics are the primary information mechanism for enabling board-level risk decisions.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "eu_ai_act", "requirement_id": "Article 17(1)", "fit": "partial", "rationale": "EU AI Act Article 17(1) requires providers of high-risk AI systems to maintain a documented quality management system whose elements \u2014 including examination, test and validation procedures (point (d)), post-market monitoring (point (h)), and serious-incident reporting (point (i)) \u2014 generate measurable operational outputs. CG-07's compliance program KPIs aggregate these signals to demonstrate that the quality management system is operating as documented.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "soc2", "requirement_id": "CC4.1 and CC4.2", "fit": "partial", "rationale": "SOC 2 TSC CC4.1 and CC4.2 require the organization to evaluate and remediate deficiencies in internal controls. Compliance metrics that identify control gaps and track remediation velocity directly support the SOC 2 monitoring and evaluation requirements.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Compliance Score", "fit": "direct", "rationale": "The Compliance Program Metrics and KPIs control requires structured metrics at both the board and operational levels to enable meaningful assessment of compliance program health and trend direction for AI obligations. Microsoft Purview Compliance Manager's Compliance Score directly provides the quantitative board-level KPI required by this control\u2014a real-time, framework-disaggregated compliance posture measure\u2014while Improvement Action tracking supports the operational metric layer by quantifying remediation velocity, open gap count, and obligation assignment coverage. This directly satisfies both tiers of the metrics framework the control requires.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability assessment", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. The RSP's dated, recurring capability assessments with published determinations illustrate measurable safety-governance reporting; CG-07's compliance KPIs apply the same measurable-cadence discipline to the enterprise compliance program.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Data residency commitments", "fit": "partial", "rationale": "The Compliance Program Metrics and KPIs control requires metrics covering all compliance obligations to enable complete program health assessment. OpenAI's Data residency commitments and service terms define trackable, verifiable obligations\u2014data location, retention period, and jurisdiction-specific regulatory adherence\u2014that must appear as measurable items in the compliance program's operational metrics framework when using OpenAI services. This is a partial fit because it adds AI vendor obligation tracking as a necessary dimension of the operational metrics framework rather than defining the full board-level and operational KPI structure.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Audit reporting", "fit": "direct", "rationale": "The Compliance Program Metrics and KPIs control requires a structured set of operational compliance metrics that reflect control effectiveness and trend direction rather than activity volume alone. Okta Identity Governance's governance reporting and Access Certifications metrics directly provide outcome-based operational compliance KPIs for the identity domain\u2014access certification completion rates, policy exception volumes, segregation of duties violation counts, and governance workflow resolution times\u2014exactly the kind of outcome-based operational metrics the control requires. This is a direct fit for the identity layer of the operational metrics tier, complementing board-level reporting with verifiable identity governance performance data.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-07", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A two-tier compliance metrics framework exists with at least five board-level KPIs (including at least one outcome indicator per applicable regulatory framework) and at least fifteen operational metrics covering obligation coverage, remediation velocity, and control effectiveness, with automated data collection from source systems and four consecutive periods of historical trend data available at reporting time.", "evidence_required": [ "kpi_framework_document defining each metric with metric_name, metric_type (leading/lagging/outcome/activity), calculation_method, data_source, collection_frequency, reporting_tier (board/operational), and metric_owner \u2014 with annual_review_date within the last 12 months", "board_kpi_dashboard reports for at least four consecutive quarters showing trend data, with compliance_committee_meeting_minutes confirming each was presented and received by the Compliance Committee", "operational_metrics_report for the current reporting period showing current_value for all defined operational metrics with data_source attribution and freshness_timestamp <= 48 hours at time of report generation", "metric_data_pipeline_health_log confirming automated collection pipeline is active for each metric, with last_successful_collection_timestamp and error_rate for the preceding 30 days" ], "machine_tests": [ "Query the KPI registry \u2192 assert board_tier_kpis >= 5, at least one KPI with metric_type='outcome' exists for each regulatory framework in scope, and each KPI has data_source and collection_frequency populated", "Query operational metric data store \u2192 assert at least 15 operational metrics exist with current_value populated within the last 24 hours and 4-period historical trend data available for each metric", "Query compliance dashboard data pipeline health \u2192 assert all metric pipelines have status='active', last_successful_run within last 24 hours, and error_rate < 5% for the preceding 30 days" ], "human_review": [ "Review the board-level KPI set to confirm it includes substantive outcome metrics (open regulatory obligation rate, remediation lag days, compliance incident frequency) rather than exclusively activity-based metrics such as training completion counts and policy review completions", "Interview the CCO and a board committee member separately to assess whether board members can interpret the KPI trend data and whether it has influenced actual governance decisions such as resource allocation, risk appetite revision, or deployment holds in the past year", "Verify four-period historical trend data accuracy by spot-checking two metrics against their source systems to confirm values are accurately calculated and consistently defined across reporting periods without retroactive adjustment" ], "blocking_effect": "advisory", "normative_status": "certification-standard", "anti_patterns": [ "Defining board-level KPIs exclusively as activity metrics (training completed, policies updated, audits scheduled) with no outcome or effectiveness indicators that would detect a compliance failure before it becomes an enforcement action", "Collecting compliance metrics manually through spreadsheet consolidation rather than automated data pipelines, creating data quality risks and enabling metric adjustment that is difficult to detect in trend analysis", "Reporting a single aggregate compliance score without framework-disaggregated metrics, allowing deterioration in specific regulatory domains (EU AI Act, GDPR) to be masked by a stable overall average", "Presenting only point-in-time metric values at board meetings without historical trend data across at least four periods, making it impossible for the board to distinguish temporary fluctuations from structural program deterioration", "Defining metrics without specifying the exact calculation method and authoritative data source, allowing inconsistent calculation between reporting periods that produces artificial trend patterns disconnected from actual program performance" ], "update_status": "current", "layer_code": "CG" }, { "id": "CG-08", "layer": "CG", "plane": "both", "name": "Compliance Governance Evidence Package", "plain": "This control produces the ComplianceAttestation artifact \u2014 the authoritative governance-layer evidence package that aggregates, validates, and cryptographically seals evidence from all compliance domain layers (CA, OB, RF, CI, AU, CG) into a top-level attestation demonstrating that board accountability, policy framework, risk appetite, and program oversight are documented, operational, and current.", "threat": { "tags": [ "attestation-gap", "evidence-incompleteness", "governance-assertion-failure", "audit-readiness-failure" ], "desc": "Without a consolidated governance evidence package, compliance attestations are fragmented assertions that cannot withstand regulatory scrutiny. Individual domain controls may be documented while governance-level failures \u2014 absent board oversight, unresourced programs, undefined risk appetite \u2014 remain invisible. Regulators and auditors increasingly require enterprise-level attestations that demonstrate governance effectiveness, not just control existence. The absence of a consolidated package signals that the organization cannot account for its own compliance posture." }, "standard": [ { "id": "iso_37301", "section": "\u00a79.2", "title": "Internal audit \u2014 evidence of compliance program effectiveness" }, { "id": "eu_ai_act", "section": "Article 17", "title": "Quality management system \u2014 documentation and evidence requirements" }, { "id": "gdpr", "section": "Article 5(2)", "title": "Accountability principle \u2014 demonstrating compliance" }, { "id": "coso_erm", "section": "Component 5", "title": "Information, Communication, and Reporting \u2014 evidence-based governance reporting" } ], "sources": [ { "id": "microsoft_purview_compliance_2024", "title": "Microsoft Purview Compliance Manager", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://learn.microsoft.com/en-us/purview/compliance-manager", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_purview_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Microsoft Purview Compliance Manager requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_artifact_compliance_2024", "title": "AWS Artifact (Compliance Reports)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://aws.amazon.com/artifact/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_artifact_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Artifact (Compliance Reports) requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "google_cloud_compliance_2024", "title": "Google Cloud Compliance & Assurance", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://cloud.google.com/security/compliance", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_cloud_compliance_2024", "relationship": "informative_reference", "rationale": "Establishes Google Cloud Compliance & Assurance requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_rsp_2024", "title": "Anthropic Responsible Scaling Policy v3.3", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "3.3", "published_on": "2026-05-26", "retrieved_on": "2026-06-29", "canonical_url": "https://www.anthropic.com/responsible-scaling-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_rsp", "relationship": "informative_reference", "rationale": "Establishes Anthropic Responsible Scaling Policy v3.3 requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "openai_enterprise_policies_2024", "title": "OpenAI Enterprise Privacy", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://openai.com/enterprise-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_enterprise_policies_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Enterprise Privacy requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "okta_identity_governance_2025", "title": "Okta Identity Governance", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.okta.com/products/identity-governance/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_identity_governance_2025", "relationship": "informative_reference", "rationale": "Establishes Okta Identity Governance requirements informing the apeiris://compliance/controls/CG-08 Compliance Governance Evidence Package control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Aggregate attestation evidence from all six compliance domain layers (CA, OB, RF, CI, AU, CG). Validate completeness against the evidence ontology schema (evidence_id, actor, intent, action, resource, policy, obligation, verdict, blocking_effect, confidence, collected_at, valid_until, integrity.hash, integrity.signature). Apply Ed25519 signature to the consolidated package. Publish the ComplianceAttestation artifact with canonical ID AU-08.", "steps": [ "Collect governance-layer evidence artifacts from all CG-01 through CG-07 controls: committee charter, CCO designation, board resolutions, policy framework documentation, risk appetite statements, resource assessment, incident response playbook, and KPI dashboards.", "Validate that all six compliance domain layers have submitted their layer-attestation evidence packages with valid verdicts, and that no blocking-level findings remain open without documented exception.", "Assemble the ComplianceAttestation package following the evidence ontology schema, populating all required fields including verdict (pass/conditional/fail), blocking_effect, confidence, confidence_basis, valid_from, valid_until, and residual_risk.", "Apply sha256 hash to the assembled package, sign with the Ed25519 key held by the CCO or designated signing authority, and publish the ComplianceAttestation artifact to the evidence registry with canonical_id AU-08.", "Present the sealed ComplianceAttestation to the Compliance Committee for board-level ratification and include it in the organization's compliance disclosure registry." ], "compliance_officer": { "summary": "The ComplianceAttestation Production is the CCO's signature deliverable \u2014 the authoritative statement of the organization's compliance posture that aggregates all domain evidence into a board-ratified attestation.", "actions": [ "Initiate the ComplianceAttestation assembly process on the defined cycle (quarterly or upon material change) by triggering evidence collection from all domain layer owners.", "Validate completeness of all incoming evidence packages against the evidence ontology schema before assembly.", "Sign and publish the ComplianceAttestation artifact after board committee ratification, and maintain version history." ], "metrics": [ "ComplianceAttestation production cadence: 100% of required cycles completed on schedule.", "Evidence package completeness at assembly: target 100% of required fields populated.", "Open blocking findings at attestation time: target 0 (all must be resolved or carry a board-approved exception)." ], "failure_signals": [ "ComplianceAttestation has not been produced in more than 90 days.", "Evidence packages from one or more domain layers are missing or incomplete.", "Blocking-level findings remain open without documented exception at attestation time." ] }, "legal_counsel": { "summary": "The ComplianceAttestation is a legal document that may be presented to regulators, auditors, and counterparties. Legal review of the attestation language, scope limitations, and liability implications is required before publication.", "actions": [ "Review the ComplianceAttestation artifact for legal accuracy and appropriate scope limitations before publication.", "Advise on disclosure obligations triggered by the attestation (e.g., regulatory filing requirements, contractual disclosure provisions).", "Ensure the attestation's validity period and residual risk statements are legally defensible." ], "failure_signals": [ "ComplianceAttestation is published without legal review.", "Attestation scope limitations are absent or legally indefensible.", "Residual risk statements have not been reviewed by legal counsel." ] }, "grc_auditor": { "summary": "Internal audit must independently verify that the ComplianceAttestation is based on complete, accurate evidence and that the production process is controlled and repeatable.", "actions": [ "Independently verify that all six domain layer evidence packages are complete and traceable to underlying control documentation.", "Validate that the Ed25519 signature and sha256 hash are correctly applied and verifiable.", "Assess the ComplianceAttestation production process for completeness, integrity controls, and alignment with the evidence ontology schema." ], "metrics": [ "Domain layer evidence completeness: 100% of required layers represented.", "Attestation integrity: signature and hash verified for 100% of published attestations.", "Audit trail completeness: every attestation production cycle has complete chain-of-custody documentation." ], "failure_signals": [ "Evidence packages for one or more domain layers are absent from the attestation.", "Signature or hash verification fails on the published attestation.", "No audit trail exists for the attestation production process." ] }, "executive": { "summary": "The board must ratify the ComplianceAttestation as the authoritative statement of the organization's compliance posture, accepting the accountability that this ratification represents.", "actions": [ "Review and ratify the ComplianceAttestation at the Compliance Committee meeting following each production cycle.", "Ensure that any conditional or failing verdict in the attestation triggers a board-level remediation review.", "Authorize the use of the ComplianceAttestation in regulatory filings, contractual disclosures, and external certifications." ], "failure_signals": [ "Board has not ratified the most recent ComplianceAttestation.", "Conditional or failing verdicts in the attestation have not triggered board-level remediation review.", "Attestation is presented to external parties without board ratification." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Consolidated compliance attestation artifacts are rare; most organizations produce domain-specific compliance reports that are never integrated into a unified governance-level evidence package." }, "capability_risk": { "capability_level": "none" }, "tiers": [ "universal-enterprise", "high-risk-sector", "eu-high-risk-ai", "federated-enterprise", "multi-tenant" ], "implementers": [ "Legal & Compliance", "GRC Team", "Executive Leadership", "IT Operations" ], "frameworks": [ { "framework": "iso_37301", "requirement_id": "\u00a79.2 and \u00a79.3", "fit": "direct", "rationale": "ISO 37301:2021 \u00a79.2 requires internal audit to provide evidence of compliance program effectiveness and \u00a79.3 requires management review of the compliance management system. The ComplianceAttestation Production directly satisfies the evidence and management review requirements by producing a consolidated, signed evidence artifact.", "normative_force": "certification-standard", "source_version": "2021", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Article 17 and Article 11", "fit": "direct", "rationale": "EU AI Act Article 17 requires documentation of the quality management system and Article 11 requires technical documentation demonstrating conformity. The ComplianceAttestation Production is the governance-layer mechanism for producing consolidated conformity evidence for high-risk AI systems.", "normative_force": "binding-law", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "gdpr", "requirement_id": "Article 5(2)", "fit": "direct", "rationale": "GDPR Article 5(2) requires the controller to be able to demonstrate compliance with the data protection principles. The ComplianceAttestation provides the consolidated, cryptographically signed evidence artifact that enables this demonstration.", "normative_force": "binding-law", "source_version": "2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "coso_erm", "requirement_id": "Component 5 \u2014 Reporting", "fit": "direct", "rationale": "COSO ERM Component 5 requires reporting on risk-related information, including compliance risk, to stakeholders. The ComplianceAttestation Production is the formal reporting mechanism that consolidates compliance evidence for board-level and external stakeholder communication.", "normative_force": "industry-framework", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "informs" }, { "framework": "soc2", "requirement_id": "CC4.1", "fit": "partial", "rationale": "SOC 2 TSC CC4.1 requires the organization to evaluate and communicate deficiencies in controls on a timely basis. The ComplianceAttestation Production process evaluates control effectiveness across all domain layers and communicates the consolidated verdict to the board.", "normative_force": "certification-standard", "source_version": "2017", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "cobit_2019", "requirement_id": "MEA03", "fit": "direct", "rationale": "COBIT 2019 MEA03 (Manage Compliance with External Requirements) requires monitoring regulatory compliance and managing the outcomes. The ComplianceAttestation Production is the culminating control that aggregates compliance evidence from all domain layers and produces the governance-level compliance verdict.", "normative_force": "industry-framework", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "asserted", "relation": "equivalent_to" }, { "framework": "microsoft_compliance", "requirement_id": "Assessment template", "fit": "direct", "rationale": "The Compliance Governance Evidence Package control produces the ComplianceAttestation artifact by aggregating, validating, and sealing evidence from all compliance domain layers. Microsoft Purview Compliance Manager generates Assessment template completion records, Control mapping documentation, and timestamped Compliance Score snapshots that are structured, auditable evidence artifacts satisfying this control's aggregation requirement. These outputs provide framework-mapped, time-stamped compliance control evidence that can be directly incorporated into the consolidated governance evidence package and referenced within the ComplianceAttestation integrity structure.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "aws_artifact", "requirement_id": "Third-party audit report", "fit": "direct", "rationale": "The Compliance Governance Evidence Package control requires the ComplianceAttestation artifact to aggregate evidence from all applicable compliance layers, including cloud infrastructure. AWS Artifact's Third-party audit reports (SOC 1/2/3, ISO 27001, FedRAMP, PCI DSS) and Compliance report access provide formally audited, independently attested evidence of AWS infrastructure compliance posture that must be included in the governance evidence package for organizations running AI workloads on AWS. These reports are direct evidence inputs\u2014sourced from authoritative third-party auditors\u2014that satisfy the cloud-layer evidence dimension of the ComplianceAttestation artifact.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "google_compliance", "requirement_id": "Certification documentation", "fit": "direct", "rationale": "The Compliance Governance Evidence Package control requires comprehensive aggregation of evidence from all applicable compliance layers, with completeness validated against the evidence ontology schema. Google Cloud's Certification documentation and Compliance reports provide independently verified evidence of GCP's regulatory posture (ISO 27001, SOC 2, FedRAMP, GDPR) for AI workloads hosted on GCP that must be incorporated into the governance evidence package to demonstrate cloud-layer compliance coverage. These certification documents are audit-ready evidence artifacts that satisfy the cloud infrastructure evidence dimension of the ComplianceAttestation package.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_rsp", "requirement_id": "Capability Report", "fit": "partial", "rationale": "The Anthropic Responsible Scaling Policy (v3.3, 2026-05-26) is Anthropic's public self-governance framework: it defines Capability Thresholds that, when reached, require Required Safeguards \u2014 the ASL-3 Deployment Standard and ASL-3 Security Standard \u2014 before Anthropic deploys or continues to scale a model. It binds Anthropic, not enterprise customers, whose duties arise from the Usage Policy and commercial terms. For CG-08's governance evidence package, current RSP documentation and published Capability Report summaries are the provider-layer governance evidence to include when the attested estate depends on Anthropic models.", "normative_force": "best-practice", "source_version": "3.3", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "openai_policies", "requirement_id": "Enterprise DPA", "fit": "partial", "rationale": "The Compliance Governance Evidence Package control requires the ComplianceAttestation artifact to include evidence from all obligation sources, including AI vendor contracts with regulatory implications. OpenAI's Enterprise DPA, zero data retention documentation, and service terms are contractual compliance documents that must be included in the governance evidence package as evidence that data processing obligations and jurisdiction-specific regulatory requirements have been formally accepted, documented, and assigned for ongoing compliance. This is a partial fit because it addresses the AI vendor contractual evidence layer rather than the full multi-layer evidence aggregation across all compliance domain controls.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" }, { "framework": "okta_governance", "requirement_id": "Access certification", "fit": "partial", "rationale": "The Compliance Governance Evidence Package control requires the ComplianceAttestation artifact to aggregate evidence from all compliance domain layers, including identity governance. Okta Identity Governance's Access certification campaign records and Audit reporting outputs are identity-layer compliance evidence artifacts\u2014documenting periodic access reviews, policy enforcement decisions, segregation of duties attestations, and governance workflow completions\u2014that must be incorporated into the governance evidence package to demonstrate identity control effectiveness within the overall ComplianceAttestation. This is a partial fit because it contributes the identity evidence dimension to the comprehensive governance evidence package rather than spanning the full multi-layer attestation.", "normative_force": "best-practice", "source_version": "2024", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "informs" } ], "canonical_id": "apeiris://compliance/controls/CG-08", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "validation_objective": "A ComplianceAttestation artifact exists with a verifiable Ed25519 signature and matching sha256 hash, containing complete evidence references from all six compliance domain layers (CA, OB, RF, CI, AU, CG), with a verdict of 'pass' or 'conditional' (where conditional entries have board-approved exception records with remediation target dates), produced within its declared valid_from to valid_until window, and formally ratified by the Compliance Committee with documented meeting minutes.", "evidence_required": [ "compliance_attestation_artifact containing evidence_id, actor (CCO designation), verdict (pass/conditional/fail), blocking_effect, confidence, confidence_basis, collected_at, valid_from, valid_until, residual_risk, integrity.hash (sha256), integrity.signature (Ed25519), and domain_layer_evidence_refs for all six layers (CA, OB, RF, CI, AU, CG)", "domain_layer_evidence_package for each of the six compliance layers confirming layer_attestation_verdict in ['pass', 'conditional'] and evidence_completeness_status='complete' with no unresolved blocking findings", "board_committee_ratification_record documenting Compliance Committee meeting date, named attendees confirming quorum, and formal approval of the ComplianceAttestation with resolution of any conditional verdict exceptions", "attestation_production_chain_of_custody log recording evidence_collection_completed_at, validation_completed_at, package_assembled_at, hash_applied_at, signature_applied_at, and board_ratification_date in sequence", "signature_verification_record confirming Ed25519 public_key_id used, signature_timestamp, and verification_outcome='valid' from an independent verification run against the published artifact" ], "machine_tests": [ "Load ComplianceAttestation artifact \u2192 assert sha256(artifact_body) == integrity.hash, assert Ed25519 verify(integrity.signature, artifact_body, cco_public_key) == true, and assert valid_until > now()", "Query domain_layer_evidence_refs in the attestation \u2192 assert all six layers (CA, OB, RF, CI, AU, CG) are present, each with layer_attestation_verdict in ['pass', 'conditional'], and assert no layer has verdict='fail' without a corresponding board_approved_exception record", "Compare attestation timestamps \u2192 assert collected_at is within valid_from..valid_until window and valid_until - valid_from <= configured_maximum_validity_period (default 90 days for high-risk AI systems)", "Query board_ratification record for the current attestation \u2192 assert ratification_date <= 7 days after package_assembled_at, ratification_status='approved', and committee_quorum_met=true" ], "human_review": [ "Verify that each of the six domain layer evidence packages contains substantive control evidence rather than self-asserted verdicts by spot-checking at least one domain layer and tracing its layer_attestation_verdict to underlying control documentation and test artifacts", "Review conditional verdict entries in the ComplianceAttestation to confirm each has a documented exception_rationale, board_approved_acceptance record, residual_risk assessment, and remediation_target_date rather than an open-ended or indefinitely deferred exception", "Assess whether the attestation validity period (valid_from to valid_until) is appropriate for the organization's AI system risk profile \u2014 specifically whether the period is short enough that material changes (new obligations, system modifications, incidents) would trigger re-attestation before validity expires" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing a ComplianceAttestation by aggregating self-asserted control verdicts from internal teams without independent evidence validation, creating a signed artifact that appears authoritative but lacks substantive verification of the underlying claims", "Applying an Ed25519 signature to an incomplete ComplianceAttestation package with missing domain layers or unpopulated evidence ontology fields, then presenting it to regulators as a complete conformity demonstration under EU AI Act Article 11", "Setting a validity period (valid_until) extending 12 or more months for high-risk AI systems, allowing a stale attestation to remain in circulation long after the underlying controls may have degraded or regulatory requirements changed", "Using the ComplianceAttestation as a deploy-once artifact without a defined re-attestation trigger for material changes such as new regulatory obligations, significant AI system modifications, or material compliance incidents that invalidate prior evidence", "Ratifying the ComplianceAttestation at a Compliance Committee meeting where domain layer evidence packages were distributed but not substantively reviewed, converting the board ratification into a pro forma sign-off rather than substantive governance oversight" ], "update_status": "current", "layer_code": "CG" } ] } }