{ "dataset": { "meta": { "title": "Apeiris Privacy Control Matrix", "subtitle": "apeiris.ai/domains/privacy — Apeiris Privacy", "domain": "privacy", "namespace": "apeiris://privacy", "site": "https://apeiris.ai/domains/privacy", "corpus_url": "https://apeiris.ai/integration/domains/privacy-controls-full.json", "version": "1.2.0", "schema_version": "1.1.0", "generated_at": "2026-07-02T00:00:00.000Z", "generated_by": "build-integration.mjs", "source_schema": "https://schema.apeiris.ai/privacy/v1/privacy-controls.schema.json", "license": "CC BY 4.0", "license_url": "https://creativecommons.org/licenses/by/4.0/", "cors": "enabled", "baseline_control_count": 9, "baseline_controls": [ "DC-01", "DC-03", "DG-01", "DG-05", "DS-01", "DP-01", "DP-05", "PM-01", "PC-08" ], "frameworks": [ "anthropic_privacy", "aws_privacy", "ccpa", "cnil_ai", "dpdp", "edpb_opinion_28_2024", "eu_ai_act", "eu_data_act", "eu_data_gov_act", "gdpr", "google_saif", "iso_27701", "lgpd", "microsoft_rai", "nist_pf", "okta_iam", "openai_privacy", "pipl", "quebec_law25", "uk_duaa" ], "profiles": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "planes": [ "data", "lifecycle" ], "has_warnings": false, "warning_count": 0, "content_hash": "sha256:pending", "controls_count": 49, "published": "2026-07-02", "source_freshness": { "status": "current", "checked_on": "2026-07-02", "review_cadence": "quarterly" }, "layers": 6, "domain_number": 3, "domain_slug": "privacy", "canonical_prefix": "apeiris://privacy/controls/", "attestation_artifact": "PrivacyAttestation", "attestation_control": "PC-08", "alias_domain": "privacyverifier.ai", "integration_endpoint": "https://apeiris.ai/integration/domains/privacy-controls-full.json", "source": "https://apeiris.ai/domains/privacy/", "lenses": [ "privacy_engineer", "dpo", "data_governance", "grc_auditor", "software_engineering" ], "description": "Apeiris Privacy Control Matrix: 49 machine-readable controls across 6 layers for verifying data protection and data subject rights governance." }, "controls": [ { "id": "DC-01", "layer": "DC", "plane": "data", "name": "Personal Data Inventory", "plain": "Every category of personal data processed by AI systems is cataloged with its lawful basis, source, and purpose so that accountability can be demonstrated and rights requests can be fulfilled.", "threat": { "tags": [ "uncontrolled-data-flows", "unmapped-personal-data", "dsar-failure" ], "desc": "Without a structured inventory, organizations cannot demonstrate lawful basis for processing, respond to DSARs, or scope breach notifications. Untracked personal data in AI training corpora creates latent GDPR Art 5 accountability failures." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(a)/Art 30", "title": "Lawfulness of processing and records of processing activities" }, { "id": "nist_pf", "section": "ID.IM-P1", "title": "Systems/products/services that process data are inventoried" }, { "id": "iso_27701", "section": "7.2.8", "title": "Records related to processing of PII" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-02" }, { "id": "brazil_lgpd_2018", "title": "Brazil Lei Geral de Proteção de Dados (LGPD) — Law No. 13,709/2018", "authority": "National Congress of Brazil", "source_type": "regulation", "normative_force": "binding-law", "version": "13709/2018", "published_on": "2018-08-14", "retrieved_on": "2026-06-29", "canonical_url": "https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm", "license": "open-access", "status": "current", "flagship": false, "source_id": "lgpd", "relationship": "normative_requirement", "rationale": "Establishes Brazil Lei Geral de Proteção de Dados (LGPD) — Law No. 13,709/2018 requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "china_pipl_2021", "title": "China Personal Information Protection Law (PIPL)", "authority": "Standing Committee of the National People's Congress of China", "source_type": "regulation", "normative_force": "binding-law", "version": "2021", "published_on": "2021-08-20", "retrieved_on": "2026-06-29", "canonical_url": "http://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html", "license": "open-access", "status": "current", "flagship": false, "source_id": "china_pipl_2021", "relationship": "normative_requirement", "rationale": "Establishes China Personal Information Protection Law (PIPL) requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-02" }, { "id": "quebec_law_25_2021", "title": "Quebec Act Respecting the Protection of Personal Information in the Private Sector (Law 25)", "authority": "Assemblée nationale du Québec", "source_type": "regulation", "normative_force": "binding-law", "version": "2021", "published_on": "2021-09-22", "retrieved_on": "2026-06-29", "canonical_url": "https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1", "license": "open-access", "status": "current", "flagship": false, "source_id": "quebec_law_25_2021", "relationship": "normative_requirement", "rationale": "Establishes Quebec Act Respecting the Protection of Personal Information in the Private Sector (Law 25) requirements informing the apeiris://privacy/controls/DC-01 Personal Data Inventory control.", "reviewed_on": "2026-07-01" }, { "id": "plot4ai", "title": "PLOT4ai — Practical Library Of Threats 4 AI", "authority": "PLOT4ai", "source_type": "community", "normative_force": "best-practice", "version": "1.0", "published_on": "2022-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://plot4.ai/library", "relationship": "supporting_guidance", "note": "PLOT4ai Privacy & Data Protection threats inform personal-data inventory scope." } ], "implementation": { "pattern": "Deploy a data catalog integrated with AI pipeline CI/CD that discovers, registers, and continuously tracks every personal data category entering training or inference workflows; every catalog entry must carry a verified lawful basis, originating source reference, and assigned data steward before the data can be admitted to any AI processing job.", "steps": [ "Run automated data flow scanning across all AI data ingestion pipelines, training jobs, and inference endpoints to discover existing personal data categories and their sources", "For each discovered category, create a catalog record capturing: data type, lawful basis under GDPR Art 6 or Art 9, originating collection source, AI processing purpose, retention schedule, and responsible data steward", "Register the catalog as the authoritative ROPA feed and configure pipeline admission gates to reject any training dataset or inference input referencing an unregistered data category", "Schedule DPO quarterly review of all catalog entries and automate staleness alerts when a pipeline references a data source that has not been re-validated within the review window" ], "anti_patterns": [ "Maintaining the inventory as a static spreadsheet disconnected from actual data pipelines — it becomes stale within weeks and provides no runtime accountability", "Scoping the inventory only to structured database fields while ignoring unstructured sources such as documents, emails, and API feeds that frequently appear in AI training corpora" ] }, "validation": { "design_check": [ "All personal data categories processed by AI systems are registered in the inventory with documented lawful basis under GDPR Art 6 or Art 9 [ref:gdpr_2016_679]", "The inventory is structurally linked to the ROPA and captures controller identity, processor chain, retention period, and purpose for each entry [ref:iso_27701_2019]", "Pipeline CI/CD gates enforce that no new training dataset or inference data source may enter production without a corresponding registered inventory entry [ref:nist_pf_1_0]" ], "runtime_test": [ "Inject a synthetic unregistered personal data category into a staging pipeline and verify the admission gate rejects it and raises an alert", "Submit a simulated DSAR for a test data subject seeded across three registered sources and confirm the inventory enables complete identification of all processing activities within 24 hours", "Add a new data feed to a training pipeline without updating the catalog and verify the staleness alerting mechanism fires within the defined SLA window" ], "evidence": [ "privacy:data-inventory — Machine-readable export of all registered personal data categories including lawful basis, purpose, and data steward assignments [unverified]", "privacy:ropa-extract — GDPR Art 30 ROPA record countersigned by the DPO covering all AI system processing activities [unverified]", "privacy:data-flow-map — Automated data flow diagram from pipeline instrumentation showing all personal data ingestion paths and their inventory registration IDs [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The personal data inventory is the technical foundation for all downstream privacy controls; without it, purpose limitation, consent linkage, and rights fulfillment cannot be implemented reliably in AI systems.", "actions": [ "Deploy data flow scanning tooling integrated with pipeline orchestration to auto-discover personal data categories in training and inference data sources", "Build inventory registration as a CI/CD gate that blocks training datasets from admission without a validated catalog entry carrying lawful basis and data steward", "Expose inventory APIs so downstream controls — consent registry, purpose mapping, DSAR fulfillment — can query registration status and lawful basis programmatically at runtime" ], "failure_signals": [ "Training jobs consume data sources not present in the inventory", "DSAR response teams cannot locate all processing activities for a specific data subject within 24 hours using the catalog alone", "Inventory record count does not increase when new AI features ship new data sources to production" ] }, "dpo": { "summary": "The personal data inventory is the primary accountability artifact required by GDPR Art 5(2) and Art 30; it must be complete, current, and DPO-countersigned to serve as evidence during supervisory authority investigations.", "actions": [ "Review and countersign the ROPA quarterly to confirm all AI system processing activities are captured and lawful bases remain valid under current regulatory interpretations", "Mandate that all new AI projects submit an inventory registration before data processing begins, enforced as a prerequisite gate in the DPIA process", "Use the inventory as the authoritative basis for breach notification scoping to ensure all affected data categories are identified and reported within GDPR Art 33 timeframes" ], "failure_signals": [ "AI systems process personal data categories absent from the ROPA", "Lawful basis fields in the inventory are marked 'TBD' or reference consent that has since been withdrawn", "The DPO cannot produce a complete inventory within one business day of a supervisory authority inquiry" ] }, "data_governance": { "summary": "The personal data inventory is the authoritative catalog for all AI-processed personal data; governance must assign stewards, measure completeness, and integrate the inventory with broader enterprise data governance.", "actions": [ "Assign named data stewards to each registered personal data category with explicit accountability for keeping entries current and accurate", "Report inventory completeness metrics — percentage of known data flows with registered entries — to the data governance committee monthly", "Cross-reference the personal data inventory against the enterprise data catalog to prevent AI-specific processing activities from being siloed outside broader governance controls" ], "failure_signals": [ "Data steward assignments in the inventory are blank or point to departed employees", "Automated pipeline audit reveals inventory completeness below 95% of active data flows", "The AI data catalog is maintained separately from the enterprise data catalog with no reconciliation or synchronization mechanism" ] }, "grc_auditor": { "summary": "The personal data inventory is the primary audit artifact for GDPR Art 30 compliance and establishes the scope baseline for every other privacy control assessment.", "actions": [ "Sample 20% of AI training datasets each quarter and verify each has a corresponding inventory entry with a valid, documented lawful basis", "Cross-reference inventory entries against DPIA records to confirm that all high-risk AI processing activities have completed impact assessments before going live", "Issue synthetic DSAR test cases and measure the proportion of processing activities correctly identified from inventory within the statutory response window" ], "metrics": [ "Percentage of active AI data flows with registered inventory entries (target: 100%)", "Average time from DSAR receipt to complete data subject record assembly via inventory query (target: <72 hours)" ], "failure_signals": [ "Quarterly sampling reveals processing activities not present in the inventory", "ROPA has not been updated within the past quarter despite new AI features being deployed", "More than 5% of inventory entries lack a documented lawful basis or carry a withdrawn consent reference" ] }, "software_engineering": { "summary": "Every data pipeline ingesting personal data must validate against the inventory registry before processing; unapproved data flows must fail at the CI/CD gate, not at audit time.", "actions": [ "Implement an inventory validation step in data pipeline CI/CD that rejects any pipeline referencing an unregistered personal data category", "Emit structured telemetry from all data ingestion components that includes the inventory registration ID, enabling processing to be traced to a specific catalog entry", "Build automated staleness detection by comparing pipeline data source manifests against inventory entries on each deployment and surfacing mismatches as build warnings" ], "failure_signals": [ "Data pipeline configurations do not reference inventory registration IDs in their metadata or telemetry", "CI/CD pipelines successfully deploy new data sources without triggering an inventory registration workflow", "No structured logs link model training runs to specific inventory-registered data categories" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain a static ROPA that does not capture AI-specific training data flows; the target state is a living catalog integrated into pipeline CI/CD with automated staleness detection and DPO review cadence." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "DPO Office", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 30", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-01 directly implements GDPR Art 30 records of processing activities by maintaining a structured catalog of all AI-processed personal data categories with lawful basis, purpose, source, and controller/processor identity.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "ID.IM-P1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-01 implements the NIST Privacy Framework Inventory and Mapping category (ID.IM-P): systems, products, and services that process data are inventoried (ID.IM-P1), with data elements and purposes captured per ID.IM-P5/P6, establishing the data footprint that grounds privacy risk management.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27701", "requirement_id": "7.2.8", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-01 aligns with ISO/IEC 27701:2019 clause 7.2.8 by maintaining records related to the processing of PII that link data categories to controllers, processors, purposes, and retention schedules required for PIMS certification.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Model and Data Inventory Management", "rationale": "SAIF's Model and Data Inventory Management control requires organizations to inventory models, datasets, and ML artifacts so that tampering and unauthorized use are detectable; DC-01 extends that inventory discipline to the personal data categories entering AI pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF inventories ML models/artifacts for tamper detection, a related discipline but not the personal-data catalog with lawful basis DC-01 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Lake Formation Data Catalog", "rationale": "AWS Lake Formation provides a central catalog for discovering, registering, and governing data sources across a data lake. It enables organizations to maintain a structured inventory of personal data categories with fine-grained access controls, supporting GDPR Art 30 Records of Processing Activities requirements for AI workloads processing personal data.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Lake Formation supplies a central data catalog that can hold the inventory but not the lawful-basis, purpose, steward, or admission-gate elements.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Data Map", "rationale": "Microsoft Purview Data Map provides automated data discovery, classification, and lineage tracking across the enterprise data estate including Azure AI workloads. It maintains a living catalog of data assets and their lineage, directly supporting personal data inventory requirements by mapping data flows through AI training and inference pipelines.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Purview Data Map auto-discovers and maps AI data flows, covering cataloging/lineage but not the lawful-basis and admission-gate governance DC-01 needs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "lgpd", "requirement_id": "Art. 37", "fit": "direct", "rationale": "Brazil LGPD Art. 37 requires controllers to maintain a record of personal data processing activities; DC-01 personal data inventory directly satisfies this obligation for Brazilian data subjects.", "normative_force": "binding-law", "source_version": "13709/2018", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "pipl", "requirement_id": "Art. 55 (protection impact assessment)", "fit": "partial", "rationale": "China PIPL Art. 55 requires personal information protection impact assessments for sensitive processing, automated decision-making, and cross-border transfers; DC-01's inventory is the prerequisite data asset register for scoping those assessments.", "normative_force": "binding-law", "source_version": "2021", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "quebec_law25", "requirement_id": "s. 3.3 (Privacy Impact Assessment)", "fit": "direct", "rationale": "Quebec Law 25 amended the Private Sector Act (P-39.1) to require privacy impact assessments (s. 3.3) for information system and electronic service delivery projects involving personal information; DC-01's inventory underpins the PIA scope determination for Quebec data subjects.", "normative_force": "binding-law", "source_version": "2021", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-01 rejects any training or inference input referencing a personal-data category not catalogued with a documented lawful basis, admitting only permitted data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Personal data cannot be governed if it cannot be found. DC-01 establishes the foundational inventory that makes every downstream privacy control — consent linkage, purpose limitation, rights fulfillment, and breach scoping — operable at scale. Without this control, AI systems accumulate unaccountable data liabilities that compound with each training run.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-01", "validation_objective": "Every personal data category processed by AI systems must have a corresponding catalog entry with a documented lawful basis, originating source, and named data steward before that data is admitted to any training or inference pipeline. Pipeline admission gates must reject any training dataset or inference input referencing an unregistered data category.", "evidence_required": [ "data_inventory_export — machine-readable export of all registered personal data categories with fields: data_type, lawful_basis_article, source_id, ai_processing_purpose, retention_schedule, and data_steward", "ropa_extract — GDPR Art 30 Records of Processing Activities countersigned by the DPO covering all AI system processing activities in the audit period", "pipeline_admission_gate_log — structured log showing dataset ID, inventory registration lookup result (pass/reject), and timestamp for every pipeline execution in the audit period", "data_flow_scan_report — automated scan output mapping all personal data ingestion paths to their inventory registration IDs with coverage percentage" ], "machine_tests": [ "Inject a synthetic unregistered personal data category into a staging pipeline dataset → assert pipeline admission gate returns reject status and raises an alert within 5 minutes", "Submit a DSAR for a synthetic test data subject seeded across three registered inventory entries → assert complete set of processing activities is returned via inventory API within 24 hours", "Add a new data feed to a staging pipeline without updating the catalog → assert staleness alerting fires within the defined SLA window and the pipeline is blocked on next execution" ], "human_review": [ "Review the ROPA quarterly to confirm all active AI system processing activities are captured and lawful basis fields are current and non-withdrawn", "Assess whether data steward assignments are populated and assigned to current employees for every registered personal data category", "Verify that the pipeline admission gate enforcement is active and that no active training jobs reference data categories absent from the inventory" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Maintaining the personal data inventory as a static spreadsheet disconnected from pipeline CI/CD, causing it to become stale within weeks of new AI features shipping", "Scoping the inventory only to structured database fields while ignoring unstructured sources such as documents, API feeds, and scraped web content that appear in AI training corpora", "Recording a single inventory entry per system rather than per data category, making it impossible to scope DSAR responses or breach notifications to specific data types", "Allowing training pipelines to proceed without querying the inventory admission gate by marking all existing datasets as pre-approved without individual registration review", "Using 'legitimate interests' as a catch-all lawful basis in inventory entries without documenting the specific balancing test outcome required under GDPR Art 6(1)(f)" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-02", "layer": "DC", "plane": "data", "name": "Special Category Data Classification", "plain": "Special category personal data under GDPR Art 9 and sensitive personal information under CCPA is identified and classified wherever it appears in AI training and inference pipelines, and heightened controls are applied automatically.", "threat": { "tags": [ "unlawful-art9-processing", "sensitive-data-in-training-corpus", "explicit-consent-missing" ], "desc": "AI training corpora frequently contain health, ethnicity, or biometric data without explicit consent or another Art 9(2) basis. Without classification, sensitive data enters pipelines without trigger of heightened controls." }, "standard": [ { "id": "gdpr", "section": "Art 9", "title": "Processing of special categories of personal data" }, { "id": "edpb_opinion_28_2024", "section": "Opinion §3", "title": "Special category data in AI training corpora" }, { "id": "ccpa", "section": "§1798.121", "title": "Sensitive personal information" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-01" }, { "id": "edpb_opinion_28_2024", "title": "EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models", "authority": "European Data Protection Board", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "28/2024", "published_on": "2024-12-17", "retrieved_on": "2026-06-28", "canonical_url": "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "edpb_opinion_28_2024", "relationship": "supporting_guidance", "rationale": "Establishes EDPB Opinion 28/2024 — Data Protection Aspects Related to AI Models requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-02" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DC-02 Special Category Data Classification control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy automated classification scanning across all AI data ingestion paths that detects special category data — health, biometric, racial/ethnic origin, religious belief, sexual orientation, political opinion — and triggers a heightened-controls workflow requiring an explicit Art 9(2) basis record and enhanced access restriction before that data may be used in any AI training or inference operation.", "steps": [ "Deploy data classification tooling with classifiers for each GDPR Art 9 category and CCPA sensitive personal information category to scan all AI training datasets and inference input streams", "For each detected special category data instance, create a classification record that identifies the category, the Art 9(2) basis (or equivalent state law exception), the specific model or pipeline that requires access, and the DPO acknowledgment", "Automatically apply heightened access controls — encryption-at-rest with separate key management, role-based access limited to authorized processors, audit logging of every access — to any dataset containing special category data", "Block any AI training run or inference deployment that processes special category data without a validated Art 9(2) basis record in the classification registry" ], "anti_patterns": [ "Relying on data providers to self-declare the absence of special category data without independent scanning — inferred attributes such as health conditions from behavioral data are frequently missed", "Applying a single classification label to entire datasets when only a subset of records contains special category data, leading to over-restriction or under-restriction depending on the default" ] }, "validation": { "design_check": [ "Automated classification scanners are deployed and cover all GDPR Art 9 categories and CCPA sensitive personal information categories for every AI data ingestion path [ref:gdpr_2016_679]", "A classification registry records the Art 9(2) basis, DPO acknowledgment, and access restriction profile for every dataset confirmed to contain special category data [ref:edpb_opinion_28_2024]", "Pipeline admission gates block training and inference jobs processing special category data without a valid, unexpired classification registry entry [ref:nist_pf_1_0]" ], "runtime_test": [ "Inject a synthetic dataset containing clearly marked health and biometric fields into a staging pipeline and verify the classifier detects both categories and triggers the heightened-controls workflow", "Attempt to launch a training job against a dataset flagged as containing Art 9 data without a valid classification registry entry and confirm the job is blocked and an alert is raised", "Audit the access logs for a dataset containing special category data and verify that every access is attributed to an authorized processor role with a documented purpose" ], "evidence": [ "privacy:special-category-classification-registry — Export of all datasets classified as containing special category data with Art 9(2) basis, DPO acknowledgment, and access restriction profile [unverified]", "privacy:classifier-scan-report — Output of the most recent automated classification scan across active AI training datasets showing coverage and detection results [unverified]", "privacy:heightened-access-audit — Access log demonstrating that special category datasets were accessed only by authorized roles within the review period [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Special category classification must be embedded in the data pipeline as a blocking gate, not a downstream audit; classifiers must cover inferred sensitive attributes — not just explicitly labeled fields — because AI systems frequently derive Art 9 data from non-obvious signals.", "actions": [ "Train and deploy classifiers for all eight GDPR Art 9 categories plus CCPA sensitive personal information, including inference-based detection for attributes such as health status inferred from behavioral patterns", "Integrate classification output into the pipeline admission gate so that any dataset with a special category detection score above threshold is automatically placed in a restricted staging area pending DPO review", "Build a classification registry API that training infrastructure queries before launching any job, rejecting runs that lack a valid registry entry for every special category dataset in scope" ], "failure_signals": [ "Classification scans are run only on initial dataset ingestion and not re-run when datasets are updated or augmented", "Inferred sensitive attributes — health conditions derived from purchase behavior, ethnicity inferred from name or location — are not in scope for the classifier", "Training jobs referencing special category datasets complete successfully without any registry lookup" ] }, "dpo": { "summary": "Special category data processing requires an explicit Art 9(2) basis for every AI use case; the DPO must review and acknowledge each classification registry entry and confirm the legal basis is adequate before processing begins.", "actions": [ "Review all datasets flagged by the classifier and formally acknowledge the applicable Art 9(2) basis — explicit consent, vital interests, substantial public interest, or another enumerated exception — for each AI use case", "Require a DPIA for any AI system that processes special category data before the classification registry entry is validated and the pipeline is unblocked", "Monitor EDPB guidance on AI and special category data — particularly Opinion 28/2024 — and update legal basis assessments when regulatory interpretation shifts" ], "failure_signals": [ "Classification registry entries are approved without a formal DPO acknowledgment or reference to a specific Art 9(2) basis", "AI systems processing health or biometric data for training lack completed DPIAs", "Legal basis records in the registry are not updated following new EDPB opinions or supervisory authority decisions" ] }, "data_governance": { "summary": "Special category data classification requires coordination with the data domain's sensitivity taxonomy to avoid conflicting classification schemes; the privacy classification owns the legal obligation layer while the data domain owns the technical taxonomy.", "actions": [ "Align special category classification labels with the enterprise data sensitivity taxonomy from the Data domain (DX-01) to ensure consistent tagging across the data governance stack", "Establish a data stewardship process requiring stewards to confirm or contest classifier detections and escalate borderline cases to the DPO within a defined SLA", "Report special category data exposure metrics — number of datasets, processing volume, Art 9(2) basis coverage — to the data governance committee quarterly" ], "failure_signals": [ "Privacy classification labels and data sensitivity taxonomy labels are maintained in separate systems with no reconciliation", "Data stewards are not notified when classifiers flag a dataset under their stewardship as containing special category data", "The data governance committee has no visibility into the volume or basis coverage of special category data processed in AI systems" ] }, "grc_auditor": { "summary": "Every instance of special category data processing in AI must be traceable to a valid Art 9(2) basis in the classification registry; absence of a registry entry or an expired basis constitutes an audit finding requiring immediate remediation.", "actions": [ "Sample classification scanner output and verify that detected special category instances have corresponding registry entries with valid, non-expired Art 9(2) basis records", "Review DPIAs for all AI systems processing special category data to confirm that the impact assessment scope matches the classification registry entries", "Test the pipeline admission gate by attempting a training run against a special category dataset with an expired registry entry and confirm it is blocked" ], "metrics": [ "Percentage of special category datasets with valid Art 9(2) basis records in the classification registry (target: 100%)", "Time from classifier detection to DPO acknowledgment and registry entry creation (target: <5 business days)" ], "failure_signals": [ "Special category datasets are present in production AI pipelines without corresponding classification registry entries", "Art 9(2) basis records are documented only at the system level, not at the dataset level, preventing granular accountability", "DPIAs have not been completed for AI systems processing Art 9 health or biometric data" ] }, "software_engineering": { "summary": "Classification must run as an automatic pre-processing step at data ingestion, and the classification result must be a required metadata field that downstream pipeline components validate before consuming a dataset.", "actions": [ "Integrate classification scanning as a mandatory step in the data ingestion pipeline that annotates every dataset with classification metadata including detected categories, confidence scores, and registry entry reference", "Enforce that training framework job launchers reject any dataset configuration missing a valid classification metadata annotation", "Implement alert routing so that classifier detections of new special category data in existing datasets trigger an immediate Slack or PagerDuty notification to the DPO and data steward" ], "failure_signals": [ "Dataset objects in the training platform lack a classification metadata field or carry a default 'unclassified' value", "The training job launcher does not validate classification status before starting a run", "No alerting exists for re-scans that detect new special category data in datasets previously cleared as non-sensitive" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations lack automated Art 9 classification for AI training corpora; the target state is a managed classification capability with automated scanning, a maintained registry, and DPO-gated pipeline admission." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Data Governance", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 9", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-02 directly addresses GDPR Art 9 by implementing classification detection and legal basis documentation for all special category personal data processed by AI systems, enabling the heightened controls Art 9(1) requires.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "edpb_opinion_28_2024", "requirement_id": "Opinion §3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-02 implements the EDPB's Opinion 28/2024 guidance on special category data in AI training corpora by requiring classification scanning and Art 9(2) basis validation before any special category data may enter an AI pipeline.", "source_version": "28/2024", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.121", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-02 partially satisfies CCPA §1798.121 sensitive personal information requirements by classifying and applying heightened controls to sensitive personal information categories; full compliance requires additional consumer rights notice obligations addressed in the DG layer.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Google Cloud Sensitive Data Protection (Cloud DLP)", "rationale": "Google Cloud's Sensitive Data Protection service provides over 200 built-in infoType detectors covering GDPR Art 9 special categories including health data, ethnicity indicators, biometrics, and religious information. The service can inspect and classify data in AI training pipelines in real-time, and its de-identification API transforms or removes sensitive values before they enter model training.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Cloud DLP's 200+ infoType detectors classify Art 9 categories in pipelines, covering detection but not the Art 9(2)-basis registry and DPO gate.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon Macie Sensitive Data Discovery", "rationale": "Amazon Macie uses machine learning and pattern matching to automatically discover and classify sensitive personal data in Amazon S3, including GDPR special category data such as health information, financial data, and national identification numbers. Macie identifies European-specific data types including EU tax identification numbers and identity card numbers relevant to Art 9 classification obligations.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Macie ML-classifies special-category and EU-specific data, covering detection but not the Art 9(2)-basis registry or DPO acknowledgment gate.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Information Protection Classification", "rationale": "Microsoft Purview provides AI-powered classification with sensitivity labels for special category data. New AI-powered classification tools detect sensitive information and compliance risks with greater accuracy across structured and unstructured data sources, enabling automated classification of GDPR Art 9 data entering AI pipelines and triggering heightened control policies.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Purview classification and sensitivity labels detect Art 9 data and can trigger policies, but stop short of the Art 9(2)-basis registry and DPO gate.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-02 scans datasets for GDPR Art 9 special-category data and blocks processing without a documented Art 9(2) basis, restricting use to lawfully-processable data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "cross_domain": { "references": [ { "uri": "apeiris://data/controls/DX-01", "relationship": "related", "note": "DC-02 receives sensitivity taxonomy input from the Data domain data classification control; DC-02 owns the legal obligation layer for Art 9 special category data." } ] }, "thesis_type": "preventive", "matrix_thesis": "Special category data in AI training corpora is the highest-risk privacy liability an organization can carry — unlawful processing of health, biometric, or ethnic origin data carries maximum GDPR fines and supervisory authority investigation. DC-02 makes the invisible visible by classifying sensitive data at ingestion and enforcing that no AI pipeline may process it without a documented and DPO-acknowledged legal basis.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-02", "validation_objective": "Every AI training dataset and inference input stream must be scanned for GDPR Art 9 special category data and CCPA sensitive personal information before processing begins. Any dataset containing detected special category data must have a corresponding classification registry entry with a documented Art 9(2) basis and DPO acknowledgment before the pipeline is permitted to execute.", "evidence_required": [ "special_category_classification_registry — export of all datasets classified as containing special category data with fields: detected_categories[], art9_basis, dpo_acknowledgment_date, access_restriction_profile, and registry_expiry", "classifier_scan_report — most recent automated classification scan output across active AI training datasets showing coverage percentage, detected categories, and confidence scores", "heightened_access_audit_log — access log for special category datasets showing every access attributed to an authorized processor role with documented purpose within the review period", "dpia_records — completed Data Protection Impact Assessments for all AI systems processing Art 9 data, including scope matching classification registry entries" ], "machine_tests": [ "Inject a synthetic dataset containing clearly labeled health and biometric fields into a staging pipeline → assert classifier detects both Art 9 categories and triggers the heightened-controls workflow blocking pipeline execution", "Attempt to launch a training job against a dataset flagged as containing Art 9 data without a valid classification registry entry → assert job is rejected with error code=missing_classification_registry_entry and a DPO alert is raised", "Submit an access request to a special category dataset from an unauthorized role → assert the request is denied and the attempt is logged in the heightened access audit log" ], "human_review": [ "DPO review and formal acknowledgment of each classification registry entry, confirming the applicable Art 9(2) basis is adequate and not expired for the specific AI use case", "Review classifier accuracy assessment including false-negative rate for inferred sensitive attributes such as health conditions derived from behavioral or purchase data", "Assess whether DPIA scope for each AI system processing Art 9 data matches the full set of classification registry entries for that system" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Relying on data providers to self-declare the absence of special category data without running independent automated classification scans across ingested datasets", "Running classification scans only at initial dataset ingestion and not re-running when datasets are updated, augmented, or combined with other sources", "Scoping classifiers only to explicitly labeled fields and missing inferred sensitive attributes — health conditions from behavioral data, ethnicity from name or location — that are frequently present in AI training corpora", "Applying a single classification label to an entire dataset when only a subset of records contains special category data, causing over- or under-restriction of the full dataset", "Using Art 9(2)(j) (scientific research) as a default justification for AI training without demonstrating that the processing meets the research necessity threshold" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-03", "layer": "DC", "plane": "data", "name": "Consent Registry", "plain": "A versioned, auditable registry links every consent record to the data collection, training dataset version, and inference context it covers, enabling consent to be proved, audited, and withdrawn cleanly.", "threat": { "tags": [ "consent-record-gap", "consent-withdrawal-not-propagated", "inability-to-prove-consent" ], "desc": "Absence of a versioned consent registry makes it impossible to prove that consent was obtained for a specific training run or that withdrawal was honored across all downstream systems." }, "standard": [ { "id": "gdpr", "section": "Art 7/Art 6(1)(a)", "title": "Conditions for consent and consent as lawful basis" }, { "id": "ccpa", "section": "§1798.135", "title": "Methods for submitting requests to opt-out" }, { "id": "dpdp", "section": "s. 6", "title": "Consent as basis for processing personal data" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-02" }, { "id": "india_dpdpa_2023", "title": "Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India)", "authority": "Parliament of India / Ministry of Electronics and Information Technology", "source_type": "binding-law", "normative_force": "binding-law", "version": "Act 2023; Rules 2025", "published_on": "2023-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.meity.gov.in/data-protection-framework", "license": "public-domain", "status": "current", "flagship": false, "source_id": "dpdp", "relationship": "normative_requirement", "rationale": "Establishes Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India) requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DC-03 Consent Registry control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Build a centralized, append-only consent registry that stores a versioned record for every consent event — grant, restriction, and withdrawal — and links each record to the specific dataset version, model training run, or inference deployment it authorizes; the registry must be queryable by data subject, dataset ID, and training run ID to support audit and rights fulfillment.", "steps": [ "Design an append-only consent event schema capturing: data subject identifier (hashed), consent version, scope (data category and purpose), granted/restricted/withdrawn status, timestamp, collection mechanism, and the dataset or pipeline version the consent covers", "Deploy the registry with cryptographic integrity protection — each event record signed or hashed into an audit chain — so that the consent history cannot be altered retroactively", "Wire training pipeline launchers and inference deployment gates to query the consent registry at job start, confirming that valid, non-withdrawn consent exists for every data subject whose data appears in the training batch", "Expose a withdrawal API that accepts rights-request signals from all consent collection points and writes a withdrawal event to the registry with a propagation deadline triggering the DC-05 propagation workflow" ], "anti_patterns": [ "Storing consent as a boolean flag in the user profile table rather than as a versioned, scoped event log — a flag cannot prove what was consented to, when, or for which specific data use", "Linking consent only to the originating data collection event without forward-linking to the specific AI training dataset versions and model deployments that relied on that consent" ] }, "validation": { "design_check": [ "The consent registry stores versioned, timestamped events with scope attributes linking each record to specific data categories, processing purposes, and dataset versions [ref:gdpr_2016_679]", "Registry records are cryptographically integrity-protected to prevent retroactive alteration of consent history [ref:iso_27701_2019]", "Training pipeline launchers perform a consent registry query before executing any job and log the query result and the specific registry entries relied upon [ref:nist_pf_1_0]" ], "runtime_test": [ "Insert a withdrawal event for a synthetic data subject into the registry and verify that a training pipeline attempting to use that subject's data is blocked within the propagation SLA", "Query the registry for a specific historical training run and confirm that the response identifies every consent record relied upon, including their scope and validity period at the time of the run", "Attempt to insert a backdated consent event and verify that the registry rejects it or flags it as a tamper attempt via the integrity protection mechanism" ], "evidence": [ "privacy:consent-registry-export — Signed export of the consent event log for the audit period showing all grant, restriction, and withdrawal events with scope and timestamp [unverified]", "privacy:training-run-consent-manifest — Per-training-run record listing every consent registry entry queried, the result, and the dataset version covered [unverified]", "privacy:consent-integrity-attestation — Cryptographic verification proof confirming the consent event chain has not been altered since last audit [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The consent registry is a core infrastructure component, not a compliance artifact; it must be a queryable service that training pipelines and inference deployments call at runtime to confirm authorization before processing any data subject's personal data.", "actions": [ "Build the registry as an append-only event store with a query API supporting lookups by data subject ID, dataset version, and processing purpose", "Integrate a consent check as a mandatory pre-flight step in the training pipeline orchestrator so that jobs without full consent coverage are rejected before they consume any compute", "Implement bidirectional linking: when a consent record is created, record which dataset versions it authorizes; when a dataset version is created, record which consent records authorize it" ], "failure_signals": [ "Training pipeline logs do not include a consent registry query ID or result for each run", "The registry cannot answer 'which training runs used data subject X's data?' within a single API call", "Withdrawal events are written to the registry but the training pipeline admission gate is not notified within the propagation SLA" ] }, "dpo": { "summary": "The consent registry is the primary legal proof artifact that consent was obtained, was valid at the time of processing, and has been honored on withdrawal; the DPO must be able to produce registry evidence in response to supervisory authority inquiries.", "actions": [ "Review the consent registry schema and confirm it captures all GDPR Art 7 validity requirements: freely given, specific, informed, and unambiguous, with a positive opt-in mechanism", "Establish a consent version management policy so that when the processing purpose changes, existing consent records are invalidated and fresh consent is collected before the new purpose is activated", "Use the registry as the primary evidence source for responding to Art 15 access requests that ask what the data subject consented to and when" ], "failure_signals": [ "Consent records in the registry do not include the specific purpose and data category scope — they contain only a generic 'I agree' marker", "The registry has no version management: changed processing purposes did not trigger consent renewal", "The DPO cannot produce a consent proof within the GDPR Art 12 one-month response window using registry data alone" ] }, "data_governance": { "summary": "The consent registry must be treated as a critical governance data asset with its own retention policy, access controls, and data quality SLAs, distinct from the personal data it governs.", "actions": [ "Define retention policies for the consent registry itself: consent records must be retained for the duration of the processing activity plus the applicable statute of limitations for regulatory action", "Implement access controls on the registry so that only authorized systems can write consent events and only authorized personnel can query the full history", "Report consent registry coverage metrics — percentage of data subjects in active training datasets with linked consent records — to the governance committee monthly" ], "failure_signals": [ "The consent registry itself lacks a defined retention and disposal policy", "Any internal system can write to the consent registry without authorization controls, enabling consent fabrication", "Coverage metrics are not tracked — the organization cannot state what percentage of training data is covered by linked consent records" ] }, "grc_auditor": { "summary": "The consent registry must be auditable end-to-end: every consent event must be attributable to a specific collection mechanism, every training run must reference specific consent records, and withdrawals must be traceable to propagation completion.", "actions": [ "Audit a sample of training runs and verify each has a consent manifest linking to valid registry entries that were not withdrawn at the time of the run", "Test the integrity protection mechanism by attempting to query a consent record that was modified outside the registry and confirming the tamper detection fires", "Review the withdrawal-to-propagation chain for a sample of withdrawal events and verify propagation completed within the statutory timeframe" ], "metrics": [ "Percentage of active training datasets with 100% consent registry coverage for all included data subjects (target: 100%)", "Consent withdrawal propagation completion rate within the statutory window (target: 100%)" ], "failure_signals": [ "Training run manifests are absent or do not reference specific consent registry entry IDs", "Withdrawal events exist in the registry without a corresponding propagation completion record", "The registry integrity check fails for any entry in the audit sample" ] }, "software_engineering": { "summary": "The consent registry must be designed as a durable, high-availability service with strict consistency guarantees — a training job that proceeds on the basis of stale consent data is a legal liability, not just a technical debt.", "actions": [ "Deploy the registry on storage with strong consistency semantics — eventual consistency is not acceptable for a consent system where stale reads could permit processing after withdrawal", "Implement a circuit breaker on the consent registry client so that training pipelines fail closed (reject the job) if the registry is unavailable, rather than proceeding on cached data", "Build automated testing of the consent check integration into every training pipeline's CI/CD pipeline so that a registry bypass is caught before deployment" ], "failure_signals": [ "The consent registry client uses cached or eventually consistent reads that may not reflect recent withdrawal events", "Training pipelines succeed when the consent registry is unreachable rather than failing closed", "No automated tests verify that the consent check integration correctly rejects jobs when consent is absent or withdrawn" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations store consent as a user profile attribute without versioning or linkage to specific AI training runs; the target state is a versioned, append-only registry integrated into training pipeline admission gates." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "DPO Office", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-03 implements GDPR Art 7 by creating a verifiable, versioned record of consent that can demonstrate consent was freely given, specific, informed, and unambiguous at the time each AI training run or inference deployment was authorized.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.135", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-03 partially satisfies CCPA §1798.135 by maintaining a registry of consumer opt-out signals that can be queried by AI pipeline admission gates; full compliance requires integration with the consumer-facing opt-out mechanism addressed in the DG layer.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "dpdp", "requirement_id": "s. 6", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-03 partially satisfies India DPDPA s. 6 by establishing a consent record that links each data subject's consent to specific processing purposes; full compliance requires the consent notice requirements addressed in the DG layer.", "source_version": "Act 2023; Rules 2025", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum — training data commitments", "rationale": "Anthropic's enterprise API terms specify that API customer inputs and outputs are not used for model training by default. Any use of customer data for training requires explicit opt-in consent. This positions Anthropic as a processor that respects the controller's consent governance, meaning enterprise consent registry decisions directly govern whether data flows into training pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic's no-training-by-default term respects controller consent but does not provide the versioned, dataset-linked consent registry itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI Data Processing Addendum — customer content and training commitments", "rationale": "OpenAI's DPA and enterprise privacy terms specify that API data is not used for model training by default. Customers must explicitly opt in to allow data use for training or capability improvement. This creates a clear consent linkage that enterprise consent registries must track: API customers are responsible for representing that they hold necessary consents before providing personal data to the OpenAI API.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI's default no-training term places consent responsibility on the customer but does not supply the versioned append-only consent registry.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Universal Directory — custom profile attributes for consent state", "rationale": "Okta Universal Directory stores consent responses as user profile attributes, including explicit opt-in to terms of service and specific data processing purposes. Under GDPR, user consent must be an affirmative opt-in, and Okta's directory enables organizations to store, query, and audit consent state alongside identity records, providing an authoritative consent registry linked to verified identities.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Universal Directory can store and audit consent state as identity attributes, but lacks the append-only versioning and dataset linkage DC-03 mandates.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-03 rejects any training job whose data-subject population lacks full consent-registry coverage, ensuring only consented data is used.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Consent that cannot be proved is consent that does not exist in law. DC-03 builds the versioned, auditable consent registry that transforms consent from a transient checkbox event into a durable authorization record linked to specific training datasets and model deployments — making it possible to prove, audit, and cleanly honor withdrawal across all downstream systems.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-03", "validation_objective": "A versioned, append-only consent registry must exist and contain a record linking every consent grant, restriction, and withdrawal to the specific data categories, processing purposes, and dataset versions it covers. Training pipeline launchers must query the registry at job start and log the consent registry entries relied upon; any training job whose data subject population lacks full consent registry coverage must be rejected.", "evidence_required": [ "consent_registry_export — cryptographically signed export of the consent event log for the audit period showing all grant, restriction, and withdrawal events with fields: data_subject_hash, consent_version, scope_categories[], scope_purposes[], dataset_version_ids[], status, and timestamp", "training_run_consent_manifest — per-training-run record listing every consent registry entry queried, the lookup result (covered/not-covered), and the dataset version scoped", "consent_integrity_attestation — cryptographic proof (hash chain or merkle root) confirming the consent event log has not been altered since the last audit attestation", "consent_withdrawal_propagation_log — records showing withdrawal events received by the registry and the corresponding training pipeline freeze actions taken within the SLA" ], "machine_tests": [ "Insert a withdrawal event for a synthetic data subject currently in a staging training dataset → assert the pipeline admission gate rejects the next training job referencing that subject's data within the propagation SLA", "Query the consent registry for a specific historical training run ID → assert the response identifies every consent registry entry relied upon, their scope, and validity status at time of the run", "Attempt to insert a backdated consent event into the registry with a timestamp preceding the current audit chain head → assert the registry rejects or flags it as a tamper attempt via the integrity protection mechanism" ], "human_review": [ "Review the consent registry schema to confirm it captures all GDPR Art 7 validity requirements: freely given, specific, informed, and unambiguous, with a positive opt-in mechanism and no bundled ToS acceptance", "Assess whether consent version management is active — changes to processing purpose must invalidate existing consent records and trigger fresh consent collection before the new purpose is activated", "Verify that training run consent manifests are complete and that no training runs in the audit period proceeded without querying the consent registry and recording a manifest" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Storing consent as a boolean flag in the user profile table rather than as a versioned, scoped event log — a flag cannot prove what was consented to, when, or for which specific AI data use", "Linking consent only to the originating data collection event without forward-linking to the specific AI training dataset versions and model deployments that relied on it", "Using eventual consistency storage for the consent registry where stale reads could permit training to proceed after a withdrawal event has been written but not yet replicated", "Allowing training pipeline engineers to bypass the consent registry check by launching jobs directly against raw data without going through the pipeline admission gate", "Treating a single broad consent for 'product improvement' as sufficient authorization for all AI training purposes without purpose-specific consent scoping" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-04", "layer": "DC", "plane": "data", "name": "Consent Signal Validation", "plain": "Incoming consent signals are validated for authenticity, completeness, and compliance with the legal standard of being freely given, specific, informed, and unambiguous before they are accepted into the consent registry.", "threat": { "tags": [ "forged-consent-signal", "dark-pattern-consent", "bundled-consent" ], "desc": "Invalid consent signals — obtained via dark patterns, bundled with service terms, or coerced — do not satisfy the GDPR Art 7 conditions for consent (Art 7(2) presentation, Art 7(4) conditionality) and cannot lawfully authorize AI training. Validation at ingestion prevents invalid signals from polluting the registry." }, "standard": [ { "id": "gdpr", "section": "Art 7(2)/Art 7(4)/Recital 32", "title": "Conditions for consent — presentation, conditionality, unambiguous indication" }, { "id": "edpb_opinion_28_2024", "section": "Opinion §3.2", "title": "Model anonymity and personal data extraction from AI models" }, { "id": "nist_pf", "section": "CT.PO-P1", "title": "Policies and procedures for authorizing data processing (including consent)" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-01" }, { "id": "edpb_opinion_28_2024", "title": "EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models", "authority": "European Data Protection Board", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "28/2024", "published_on": "2024-12-17", "retrieved_on": "2026-06-28", "canonical_url": "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "edpb_opinion_28_2024", "relationship": "supporting_guidance", "rationale": "Establishes EDPB Opinion 28/2024 — Data Protection Aspects Related to AI Models requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DC-04 Consent Signal Validation control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement a consent signal validation pipeline that evaluates each incoming consent event against a rule engine encoding the GDPR Art 7 validity criteria before writing it to the consent registry; signals failing validation are quarantined with a structured rejection reason and routed to the DPO for remediation rather than silently discarded or accepted.", "steps": [ "Define a consent validity schema that captures the GDPR Art 7 criteria: the consent must be distinguishable from other matters and presented in plain language (Art 7(2)), and must not be bundled as a general condition of service (Art 7(4))", "Build a validation rule engine that evaluates each incoming consent signal against: (a) positive opt-in mechanism (no pre-ticked boxes), (b) granular purpose specificity (one purpose per consent signal), (c) absence of coercive bundling with service terms, and (d) verified collection mechanism identifier", "Route signals failing validation to a quarantine queue with a structured rejection reason, notify the DPO and product team, and prevent the signal from being written to the main consent registry", "Log all validation outcomes — pass and fail — in an immutable validation audit log that supports regulatory inquiry into consent collection practices" ], "anti_patterns": [ "Validating only the technical format of the consent signal (is it a valid JSON object?) without validating the consent mechanism that produced it (was it a pre-ticked box? bundled with ToS acceptance?)", "Silently discarding invalid consent signals without alerting the DPO or recording the rejection — rejected signals are evidence of potentially unlawful consent collection practices that must be investigated" ] }, "validation": { "design_check": [ "The consent validation rule engine evaluates the GDPR Art 7(2) and Art 7(4) criteria — positive opt-in, granular purpose specificity, plain language, and non-coercive mechanism — before accepting a signal into the registry [ref:gdpr_2016_679]", "Consent signals collected via bundled ToS acceptance or pre-ticked boxes are detected and quarantined with a rejection reason documented in the validation audit log [ref:edpb_opinion_28_2024]", "All validation outcomes — pass and fail — are recorded in an immutable audit log enabling post-hoc regulatory review of consent collection practices [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit a synthetic consent signal bundled with a service ToS acceptance and verify the validation engine detects the bundling, quarantines the signal, and alerts the DPO", "Submit a valid positive opt-in consent signal for a single specific purpose and verify it passes validation and is written to the registry with a validation pass record in the audit log", "Submit a consent signal with a pre-ticked checkbox marker in its metadata and verify it is quarantined with the rejection reason 'non-positive-opt-in'" ], "evidence": [ "privacy:consent-validation-audit-log — Immutable log of all consent signal validation outcomes including pass/fail, rejection reason, and collection mechanism identifier [unverified]", "privacy:consent-quarantine-report — Summary of quarantined consent signals by rejection reason and originating product surface for the audit period [unverified]", "privacy:consent-mechanism-review — DPO-signed review of each active consent collection mechanism confirming compliance with GDPR Art 7(2)/7(4) validity criteria [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Consent signal validation must be a synchronous gate at the boundary between consent collection and the consent registry — invalid signals must be rejected before they enter the system of record, not flagged after the fact.", "actions": [ "Instrument all consent collection surfaces to emit structured metadata with each signal, including: collection mechanism type, UI element used, whether other agreements were co-presented, and the specific purpose scope selected", "Build the validation rule engine as a stateless microservice that can be called synchronously by any consent collection surface before writing to the registry", "Create a dark-pattern detection rule set based on EDPB guidelines on consent and update it whenever new regulatory guidance is published" ], "failure_signals": [ "Consent signals arrive at the registry without a collection mechanism identifier, making it impossible to evaluate how they were obtained", "The validation service runs asynchronously after registry write, meaning invalid signals have already been accepted before validation completes", "No dark-pattern detection rules exist in the validation engine" ] }, "dpo": { "summary": "Consent signal validation is the control that prevents the consent registry from being populated with legally invalid records that cannot support AI training authorization; the DPO must define the validity criteria and review all quarantined signals.", "actions": [ "Define the consent validity criteria in a DPO-approved policy document that is translated into the validation rule engine's rule set", "Review all quarantined consent signals weekly to assess whether the rejection indicates a systemic problem with a specific consent collection mechanism that requires product remediation", "Maintain a consent mechanism inventory listing every active consent collection surface, its mechanism type, and the DPO's current validity assessment" ], "failure_signals": [ "The DPO has not reviewed quarantined consent signals in the past month", "Consent mechanisms flagged as potentially non-compliant in previous reviews are still active without documented remediation", "There is no DPO-approved policy document defining the consent validity criteria that the validation engine enforces" ] }, "data_governance": { "summary": "Consent signal quality is a data quality dimension; governance must track consent validation pass rates as a KPI and escalate persistent rejection patterns as data quality incidents.", "actions": [ "Define consent validation pass rate as a tracked data quality metric and include it in the monthly data governance committee report", "Classify repeated quarantine events from the same consent collection surface as a data quality incident requiring a root cause analysis within 10 business days", "Ensure that the consent mechanism inventory maintained by the DPO is synchronized with the consent collection surface registry maintained by product and engineering" ], "failure_signals": [ "Consent validation pass rate is not measured or reported", "Repeated quarantine events from the same product surface are treated as isolated technical errors rather than systemic consent collection failures", "The consent mechanism inventory is out of date — it does not reflect all active consent collection surfaces" ] }, "grc_auditor": { "summary": "The consent signal validation audit log provides the evidence chain linking each accepted consent record to a validated collection mechanism; auditors must verify that the validation rules are current, that quarantine alerts are reviewed, and that rejected signals are not improperly re-admitted.", "actions": [ "Sample the consent registry and validate that each accepted entry has a corresponding validation pass record in the audit log with a recognized collection mechanism identifier", "Review the quarantine report and confirm that each quarantine event was reviewed by the DPO and either remediated or escalated within the defined SLA", "Test that quarantined signals cannot be manually admitted to the registry without DPO approval by attempting a bypass and confirming it is blocked and logged" ], "metrics": [ "Consent signal validation pass rate by collection mechanism (target: track and investigate any mechanism below 95%)", "Mean time from quarantine event to DPO review and resolution (target: <5 business days)" ], "failure_signals": [ "Registry entries exist without a corresponding validation pass record in the audit log", "Quarantine events older than 10 business days have not been reviewed by the DPO", "The validation rule set has not been updated following the publication of EDPB Opinion 28/2024" ] }, "software_engineering": { "summary": "Consent signal validation is an ingestion-layer control that must be versioned alongside the consent registry schema; rule set updates must be deployed without downtime and must not invalidate previously validated signals.", "actions": [ "Version the validation rule set so that each consent signal is validated against the rule version active at the time of submission, and the applied rule version is recorded in the audit log", "Deploy the validation service with a blue-green deployment model so that rule set updates can be applied without dropping consent signals during the transition", "Write integration tests covering all rejection scenarios — bundled ToS, pre-ticked checkbox, missing purpose specificity — and run them in CI/CD on every rule set change" ], "failure_signals": [ "The validation rule version is not recorded in the audit log — it is impossible to determine which rules applied to a given historical consent signal", "Rule set updates require service downtime, creating a window during which consent signals bypass validation", "No integration tests cover dark-pattern detection scenarios" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations accept consent signals from collection surfaces without systematic validity validation; the target state is a synchronous validation gate with a rule engine encoding Art 7(2)/7(4) criteria and an immutable audit log of all outcomes." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Software Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 7(2)/Art 7(4)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-04 implements the GDPR Art 7 conditions for consent by validating that every incoming signal is presented clearly and distinguishably (Art 7(2)), is not bundled as a condition of service (Art 7(4)), and meets the Art 4(11) definition of freely given, specific, informed, and unambiguous consent before it is accepted into the consent registry.", "source_version": "2016/679", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "edpb_opinion_28_2024", "requirement_id": "Opinion §3.2", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "EDPB Opinion 28/2024 §3.2 assesses when AI models trained on personal data can be considered anonymous, including the likelihood of extracting or regurgitating training data; DC-04's validation of consent signals for training data addresses the lawfulness questions the Opinion raises for models that cannot be treated as anonymous.", "source_version": "28/2024", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.PO-P1", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-04 implements NIST Privacy Framework CT.PO-P1 — policies, processes, and procedures for authorizing data processing (including individual consent), revoking authorizations, and maintaining authorizations — by validating consent signals before they authorize AI processing.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta API Access Management — OAuth scopes and consent", "rationale": "Okta API Access Management enforces consent-based scopes at the API access layer, ensuring that downstream services and AI pipelines can only access data attributes for which the user has provided valid consent. OAuth 2.0 scopes linked to consent records in Universal Directory enforce purpose limitation at the access control plane.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Okta OAuth consent scopes enforce purpose-limited access at the API layer, a different mechanism than validating consent signals against Art 7(2)/7(4).", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI Enterprise Privacy — customer responsibility for lawful data use", "rationale": "OpenAI's enterprise privacy terms require that customers represent and warrant they have obtained all necessary consents and authorizations before providing personal data to the OpenAI API. This upstream consent validation obligation means that organizations must implement consent signal validation as a pipeline gate before API calls that transmit personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's warranty that customers hold necessary consents motivates a validation gate but provides no mechanism to test signals against Art 7 conditions.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Privacy Policy and Consumer Terms — training data opt-in/opt-out", "rationale": "Anthropic's Privacy Policy and Consumer Terms document when user data may be used for model training and the opt-in/opt-out controls available; DC-04's validation gate is the enterprise-side mechanism for honoring equivalent consent signals.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic's opt-in/opt-out consent documentation is related governance but does not validate incoming consent signals for dark patterns or bundling.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-04 quarantines consent signals collected via dark patterns or pre-ticked boxes so they never authorize AI processing, keeping only validly-obtained data in scope.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "A consent registry populated with invalid signals provides the appearance of compliance while creating compounding legal exposure — every AI training run authorized on the basis of a dark-pattern or bundled consent is unlawful. DC-04 enforces legal validity at ingestion so that the consent registry contains only signals that can withstand regulatory scrutiny.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-04", "validation_objective": "Every incoming consent signal must pass a synchronous validation rule engine encoding GDPR Art 7(2)/7(4) criteria before it is written to the consent registry. Signals collected via dark patterns, pre-ticked boxes, or bundled ToS acceptance must be quarantined with a structured rejection reason and must not enter the registry as valid authorization for AI data processing.", "evidence_required": [ "consent_validation_audit_log — immutable log of all consent signal validation outcomes with fields: signal_id, collection_mechanism_id, validation_rule_version, result (pass/quarantine), rejection_reason (if quarantined), and timestamp", "consent_quarantine_report — summary of quarantined consent signals by rejection_reason and originating product surface for the audit period, with DPO review timestamps", "consent_mechanism_inventory — DPO-signed inventory of all active consent collection surfaces listing mechanism_type, UI_element_used, purpose_scope, and current validity_assessment", "validation_rule_set_version_log — versioned history of the validation rule engine rule sets with effective dates and references to the regulatory guidance prompting each update" ], "machine_tests": [ "Submit a synthetic consent signal with a bundled ToS acceptance marker in its metadata → assert the validation engine quarantines the signal with rejection_reason=bundled-tos-acceptance and raises a DPO alert", "Submit a valid positive opt-in consent signal for a single specific purpose with a recognized collection mechanism ID → assert it passes validation and is written to the consent registry with a validation_pass record in the audit log", "Submit a consent signal with a pre-ticked checkbox marker → assert it is quarantined with rejection_reason=non-positive-opt-in and that the signal does not appear in the consent registry" ], "human_review": [ "DPO review of all quarantined consent signals in the audit period to assess whether rejections indicate systemic problems with specific consent collection mechanisms requiring product remediation", "Review the validation rule set for completeness against current EDPB guidance on consent — particularly dark-pattern detection criteria from EDPB Opinion 28/2024 — and confirm the rule set was updated following recent regulatory guidance", "Assess whether the consent mechanism inventory is current and reflects all active consent collection surfaces, including recently launched product features" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Validating only the technical format of the consent signal (valid JSON structure) without validating the consent mechanism that produced it (was it a pre-ticked box, bundled with ToS, or coerced by a service gate?)", "Running consent signal validation asynchronously after the signal has already been written to the registry, allowing invalid signals to enter the system of record before validation completes", "Silently discarding invalid consent signals without alerting the DPO or recording the rejection in an immutable audit log — rejected signals are evidence of potentially unlawful consent collection practices", "Using a single universal collection_mechanism_id of 'web-form' across all consent surfaces without capturing the specific UI element and co-presented materials", "Applying the same validation rules to all jurisdictions without accounting for jurisdiction-specific consent standards such as CCPA opt-out vs. GDPR opt-in requirements" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-05", "layer": "DC", "plane": "data", "name": "Consent Withdrawal Processing", "plain": "Consent withdrawal requests are processed within statutory timeframes and propagated to all downstream AI systems, training pipelines, and processors, with propagation evidence maintained for audit.", "threat": { "tags": [ "withdrawal-not-honored", "stale-consent-retained", "downstream-processors-not-notified" ], "desc": "Failure to honor withdrawal in a timely manner and propagate it to all downstream systems — including model training queues and third-party processors — is a direct GDPR Art 7(3) violation with enforcement precedent." }, "standard": [ { "id": "gdpr", "section": "Art 7(3)/Art 17", "title": "Right to withdraw consent and right to erasure" }, { "id": "ccpa", "section": "§1798.120", "title": "Right to opt-out of sale or sharing" }, { "id": "dpdp", "section": "s. 6(4)", "title": "Right to withdraw consent" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-02" }, { "id": "india_dpdpa_2023", "title": "Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India)", "authority": "Parliament of India / Ministry of Electronics and Information Technology", "source_type": "binding-law", "normative_force": "binding-law", "version": "Act 2023; Rules 2025", "published_on": "2023-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.meity.gov.in/data-protection-framework", "license": "public-domain", "status": "current", "flagship": false, "source_id": "dpdp", "relationship": "normative_requirement", "rationale": "Establishes Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India) requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DC-05 Consent Withdrawal Processing control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement a withdrawal processing workflow triggered by any consent withdrawal event in the registry that automatically: (1) freezes the data subject's data from entering any new training run or inference job, (2) dispatches propagation notifications to all registered downstream processors with a timestamped receipt requirement, and (3) records a propagation completion audit trail when each processor confirms receipt and compliance.", "steps": [ "On receipt of a withdrawal event in the consent registry, immediately set a 'processing-frozen' flag on all personal data records for the data subject in the data inventory to prevent them from being selected for new training runs or inference jobs", "Query the processor registry to identify all downstream AI systems and third-party processors that hold or have processed the data subject's data, and dispatch a withdrawal notification to each within one hour of the withdrawal event", "Implement a propagation acknowledgment protocol where each downstream processor returns a timestamped receipt confirming they have quarantined the data subject's data and removed it from active pipeline queues", "Escalate to the DPO any processor that has not returned a propagation acknowledgment within the statutory window minus a safety buffer, and document the escalation in the propagation audit trail" ], "anti_patterns": [ "Treating consent withdrawal as a data deletion request handled only by the user-facing product database while leaving the data subject's personal data in training pipeline staging areas, data lakes, and third-party processor environments", "Relying on periodic batch jobs to propagate withdrawal notifications rather than near-real-time event-driven propagation — batch delays can cause statutory violations when the withdrawal-to-stop-processing window is short" ] }, "validation": { "design_check": [ "The withdrawal processing workflow triggers automatically on every withdrawal event in the consent registry and applies a processing-freeze within one hour of receipt [ref:gdpr_2016_679]", "A processor registry lists all downstream AI systems and third-party processors that must be notified on withdrawal, and the notification dispatch is automated rather than manual [ref:ccpa_cpra_2023]", "Propagation acknowledgment records are maintained for each withdrawal event, with escalation triggered automatically for processors that do not acknowledge within the statutory window [ref:india_dpdpa_2023]" ], "runtime_test": [ "Submit a withdrawal event for a synthetic data subject currently queued in a staging training dataset and verify the processing-freeze flag is applied and the training job is blocked before it starts", "Trigger a withdrawal notification to a test downstream processor endpoint and verify the notification arrives within the defined SLA and that a receipt is recorded in the propagation audit trail", "Simulate a non-responsive processor by blocking the acknowledgment endpoint and verify the escalation alert fires to the DPO within the defined escalation window" ], "evidence": [ "privacy:withdrawal-processing-audit-trail — Per-withdrawal event record showing freeze timestamp, notification dispatch log, and propagation acknowledgment receipts from all downstream processors [unverified]", "privacy:propagation-sla-report — Report of all withdrawal events in the audit period with propagation completion times relative to the statutory window [unverified]", "privacy:processor-acknowledgment-log — Signed acknowledgment records from all downstream processors confirming withdrawal was honored within the required timeframe [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Withdrawal propagation is an event-driven distributed systems problem: a withdrawal event must trigger a fan-out to every processor holding the data subject's data, with guaranteed delivery, acknowledgment tracking, and dead-letter handling for non-responsive endpoints.", "actions": [ "Implement withdrawal propagation as an event-driven workflow with guaranteed-delivery semantics — use a durable message queue with dead-letter handling so that propagation notifications are never silently dropped", "Maintain a processor registry as a service that can be queried at propagation time to get the current list of all downstream systems that hold or process a specific data subject's data", "Build an acknowledgment tracking dashboard visible to privacy engineering and the DPO showing real-time propagation status for each open withdrawal event" ], "failure_signals": [ "Withdrawal notifications are sent via fire-and-forget HTTP calls with no acknowledgment tracking or retry logic", "The processor registry is a static spreadsheet rather than a queryable service — it cannot be reliably enumerated for an automated propagation fan-out", "No alerting exists for withdrawal events that have not received full propagation acknowledgment within the statutory window" ] }, "dpo": { "summary": "Consent withdrawal is a legally enforceable right under GDPR Art 7(3) with an immediacy obligation; the DPO must ensure that the withdrawal processing SLA is defined in data processing agreements and that enforcement mechanisms exist for non-compliant processors.", "actions": [ "Define withdrawal processing SLAs in all data processing agreements with downstream processors and confirm those SLAs satisfy the statutory requirement to process withdrawal 'without undue delay'", "Review the escalation queue weekly for processors that have not acknowledged withdrawal notifications and initiate contractual enforcement for persistent non-compliance", "Maintain a withdrawal processing record that can be produced to supervisory authorities demonstrating that every withdrawal request was processed within the statutory window" ], "failure_signals": [ "Data processing agreements with downstream processors do not specify a withdrawal propagation acknowledgment SLA", "The DPO escalation queue contains unacknowledged processors that have been pending for more than the statutory window", "No withdrawal processing record exists that can be produced to a supervisory authority" ] }, "data_governance": { "summary": "Withdrawal propagation completeness is a data governance KPI; governance must ensure the processor registry is current, completeness is measured, and persistent non-compliant processors are escalated.", "actions": [ "Maintain the processor registry as an authoritative, versioned asset updated whenever new downstream processors are onboarded or existing ones are decommissioned", "Report withdrawal propagation completeness — percentage of withdrawal events with full processor acknowledgment within the statutory window — to the governance committee monthly", "Classify processors with a pattern of late or missing acknowledgments as elevated governance risk and require remediation plans within 30 days" ], "failure_signals": [ "The processor registry was last updated more than 90 days ago and does not reflect recently onboarded AI services", "Withdrawal propagation completeness is not tracked as a governance metric", "Processors with repeated acknowledgment delays have not been escalated through the governance process" ] }, "grc_auditor": { "summary": "Withdrawal processing compliance requires auditable evidence that every withdrawal event was processed within the statutory window and that all downstream processors acknowledged compliance; gaps in the propagation audit trail are findings requiring immediate remediation.", "actions": [ "Sample 20% of withdrawal events in the audit period and verify each has a complete propagation audit trail with processor acknowledgment timestamps within the statutory window", "Cross-reference the processor registry against the organization's vendor list to confirm all downstream processors that may hold personal data are registered for withdrawal notification", "Test the escalation mechanism by reviewing whether DPO alerts were generated for any processors that failed to acknowledge within the SLA" ], "metrics": [ "Percentage of withdrawal events with full propagation completion within the statutory window (target: 100%)", "Percentage of downstream processors in the registry with a current data processing agreement specifying withdrawal SLAs (target: 100%)" ], "failure_signals": [ "Withdrawal events in the audit sample have incomplete propagation audit trails with missing processor acknowledgments", "Downstream processors handling personal data for AI purposes are not in the withdrawal processor registry", "DPO escalation alerts were not generated for processors exceeding the SLA despite the monitoring system being active" ] }, "software_engineering": { "summary": "Withdrawal propagation is a distributed systems reliability requirement: the propagation workflow must handle processor endpoint failures gracefully with retry, dead-letter queuing, and circuit-breaker patterns — a failed notification must never result in silent non-propagation.", "actions": [ "Implement withdrawal propagation using a durable message queue with at-least-once delivery, exponential backoff retry, and a dead-letter queue for endpoints that fail after the maximum retry count", "Build the processing-freeze flag as an atomic write operation with conflict detection so that concurrent training job launchers cannot race past the freeze before it is applied", "Integrate withdrawal propagation end-to-end tests into the staging environment CI pipeline, simulating non-responsive processors and verifying that dead-letter handling and DPO alerting function correctly" ], "failure_signals": [ "Withdrawal propagation uses synchronous HTTP calls with no retry logic — a transient network failure silently drops the notification", "The processing-freeze flag is applied asynchronously after the withdrawal event is written, creating a race condition where a training job can start before the freeze is set", "No end-to-end tests cover the withdrawal propagation failure path" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations process withdrawal only at the primary database level without automated propagation to AI pipelines and downstream processors; the target state is an event-driven propagation workflow with guaranteed delivery and a processor acknowledgment audit trail." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Software Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 7(3)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-05 implements GDPR Art 7(3) by establishing a withdrawal processing workflow that stops processing without undue delay and propagates the withdrawal to all downstream AI systems and processors with auditable completion evidence.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.120", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-05 satisfies CCPA §1798.120 opt-out rights by implementing automated propagation of opt-out signals to all downstream systems and third-party processors sharing or selling personal data, with acknowledgment tracking.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "dpdp", "requirement_id": "s. 6(4)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-05 partially satisfies India DPDPA s. 6(4), which grants the data principal the right to withdraw consent at any time with ease comparable to giving it; full compliance requires integration with the Data Fiduciary erasure obligations addressed in the DP layer.", "source_version": "Act 2023; Rules 2025", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "okta_iam", "requirement_id": "Okta Lifecycle Management — automated deprovisioning workflows", "rationale": "Okta Lifecycle Management automates downstream deprovisioning when users exercise their right to withdraw consent or be forgotten. Automated workflows can manage account suspension, deactivation, and deletion across connected applications when a consent withdrawal event fires, propagating the withdrawal through the identity-connected application stack.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Lifecycle Management auto-deprovisions connected apps on withdrawal, propagating across the identity stack but not to training queues or with ack SLAs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Zero Data Retention (ZDR) Addendum", "rationale": "Anthropic offers a Zero Data Retention addendum ensuring that API inputs and outputs are processed only for real-time abuse detection and then immediately discarded with no persistence. This mechanism directly supports consent withdrawal by ensuring that for ZDR customers, there is no retained data to delete upon withdrawal—the architecture is designed for statelessness by default.", "normative_force": "best-practice", "fit": "supporting", "fit_rationale": "Anthropic ZDR keeps no retained data to delete on withdrawal, structurally easing fulfillment but not processing or propagating withdrawal events.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI privacy request processing — data deletion", "rationale": "OpenAI supports data deletion requests via its DSAR process (dsar@openai.com). For API customers, data controls allow configuration of retention and deletion preferences. Enterprise customers can request deletion of stored personal data, and OpenAI retains only an audit record of the deletion request itself to evidence compliance, not the underlying data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI's DSAR deletion process removes vendor-held data on request, covering withdrawal at the vendor layer but not enterprise-wide propagation or freeze SLAs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-05 freezes a subject's data on consent withdrawal and prevents it entering any new training or inference job, stopping use of no-longer-permitted data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "The right to withdraw consent is only meaningful if withdrawal propagates completely and verifiably across every system that relied on that consent. DC-05 implements withdrawal as a distributed systems guarantee — not a UI event — ensuring that every AI pipeline, training queue, and downstream processor receives and acknowledges the withdrawal within the statutory window, with evidence maintained for regulatory inspection.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-05", "validation_objective": "Every consent withdrawal event must trigger an automated processing-freeze on the data subject's data within one hour and dispatch propagation notifications to all registered downstream processors. The processing-freeze must prevent the data subject's data from entering any new training run or inference job, and all downstream processors must return timestamped propagation acknowledgments within the statutory SLA window.", "evidence_required": [ "withdrawal_processing_audit_trail — per-withdrawal-event record with fields: withdrawal_event_id, data_subject_hash, freeze_applied_timestamp, notification_dispatch_log[], and propagation_acknowledgment_receipts[] from each downstream processor with timestamps", "propagation_sla_compliance_report — report of all withdrawal events in the audit period showing propagation completion times relative to the statutory window, with SLA breach flags and escalation records", "processor_acknowledgment_log — signed acknowledgment records from each registered downstream processor confirming withdrawal was honored and data quarantined within the required timeframe", "processor_registry_snapshot — current list of all downstream AI systems and third-party processors registered to receive withdrawal propagation notifications, with DPA references" ], "machine_tests": [ "Submit a withdrawal event for a synthetic data subject currently queued in a staging training dataset → assert the processing-freeze flag is applied and the training job is blocked before execution begins", "Trigger a withdrawal notification to a test downstream processor endpoint → assert the notification arrives within the defined dispatch SLA and a receipt is recorded in the propagation audit trail", "Simulate a non-responsive processor by blocking its acknowledgment endpoint → assert the escalation alert fires to the DPO within the defined escalation window and an open propagation case is created" ], "human_review": [ "Review the processor registry to confirm all downstream AI systems and third-party processors that may hold personal data are registered and have current DPA clauses specifying withdrawal propagation SLAs", "Assess the open propagation case queue for any withdrawal events where processor acknowledgment is overdue, and verify that DPO escalation was initiated and documented for each overdue case", "Verify that data processing agreements with downstream processors contain enforceable withdrawal acknowledgment SLAs and that persistent non-compliance has been escalated to contractual enforcement" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Treating consent withdrawal as a user-facing product database event while leaving the data subject's personal data in training pipeline staging areas, data lakes, and third-party processor environments without propagation", "Using periodic batch jobs to propagate withdrawal notifications rather than near-real-time event-driven propagation — batch delays cause statutory violations when the withdrawal-to-stop-processing window is short", "Applying the processing-freeze asynchronously after the withdrawal event is written, creating a race condition where a training job can start before the freeze is set", "Using a static list of downstream processors hardcoded in the propagation workflow rather than querying a dynamic processor registry — newly onboarded processors are silently excluded from withdrawal notifications", "Treating propagation as complete when the notification is published to the message bus rather than when all subscriber acknowledgments are received and recorded" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-06", "layer": "DC", "plane": "data", "name": "Data Purpose Limitation Mapping", "plain": "Each AI data use is mapped to its original collection purpose and a documented compatibility assessment is required before data is repurposed for AI training or inference beyond that original purpose.", "threat": { "tags": [ "purpose-creep", "unauthorized-repurposing", "training-on-incompatible-purpose-data" ], "desc": "GDPR Art 5(1)(b) prohibits further processing incompatible with the original purpose. AI training frequently repurposes data collected for a different context, creating systematic purpose limitation violations." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(b)/Art 6(4)", "title": "Purpose limitation and compatibility assessment" }, { "id": "nist_pf", "section": "ID.IM-P5", "title": "The purposes for the data actions are inventoried" }, { "id": "iso_27701", "section": "7.2", "title": "Purposes of personal information processing" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DC-06 Data Purpose Limitation Mapping control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Build a purpose mapping registry that links every AI data use to the original collection purpose recorded in the data inventory, and require a documented Art 6(4) compatibility assessment — signed by the DPO — before any data is used for an AI purpose that was not explicitly stated at collection time.", "steps": [ "For every AI use case, retrieve the original collection purpose from the data inventory (DC-01) for each data category in scope and document the mapping between the original purpose and the proposed AI purpose", "Conduct and document an Art 6(4) compatibility assessment for any proposed AI data use where the AI purpose differs from the original collection purpose, evaluating: (a) link between original and AI purpose, (b) context of collection, (c) nature and sensitivity of data, (d) consequences for data subjects, and (e) safeguards applied", "Require DPO sign-off on all compatibility assessments before the AI use case is permitted to ingest the relevant data, and record the assessment outcome in the purpose mapping registry", "Integrate purpose validation into the data pipeline admission gate so that training jobs can only access datasets whose purpose mapping has been assessed as compatible or for which a new lawful basis has been established" ], "anti_patterns": [ "Using a broad original purpose statement such as 'to improve our services' to justify any AI use without conducting a specific compatibility assessment — regulators and courts have consistently rejected vague purpose statements as insufficient under Art 5(1)(b)", "Conducting the compatibility assessment after data has already been ingested into a training pipeline rather than as a prerequisite gate before ingestion begins" ] }, "validation": { "design_check": [ "Every AI use case has a documented purpose map linking the AI processing purpose to the original collection purpose for each data category in scope [ref:gdpr_2016_679]", "All AI use cases where the AI purpose differs from the original collection purpose have a documented and DPO-signed Art 6(4) compatibility assessment before data ingestion is permitted [ref:iso_27701_2019]", "Pipeline admission gates validate that a purpose compatibility record exists and is approved before a training job can access any dataset [ref:nist_pf_1_0]" ], "runtime_test": [ "Attempt to launch a training job against a dataset where the AI purpose has not been mapped to the original collection purpose and confirm the job is blocked at the pipeline admission gate", "Submit a compatibility assessment for a proposed AI use case and verify the DPO approval workflow routes correctly and records the outcome in the purpose mapping registry", "Introduce a new AI purpose for an existing dataset without updating the purpose map and verify the staleness alert fires and blocks the next training run against that dataset" ], "evidence": [ "privacy:purpose-mapping-registry — Export of all AI use case purpose maps linking AI processing purposes to original collection purposes for each in-scope data category [unverified]", "privacy:compatibility-assessment-log — DPO-signed compatibility assessments for all AI uses where repurposing was required, including the Art 6(4) factor evaluation [unverified]", "privacy:purpose-gate-audit-log — Pipeline admission gate log showing purpose validation results for all training runs in the audit period [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Purpose limitation is enforced at the data pipeline layer by requiring every dataset access to carry a validated purpose mapping reference; the admission gate prevents training jobs from consuming data whose purpose map has not been assessed and approved.", "actions": [ "Build a purpose mapping service that stores compatibility assessments keyed by dataset ID and AI use case ID, and expose a query API for the pipeline admission gate", "Integrate purpose validation as a required step in the dataset registration workflow so that no dataset can be marked 'training-eligible' without a linked purpose map", "Implement drift detection that alerts when a dataset's original collection purpose changes — for example when the source product's privacy policy is updated — requiring re-assessment of all downstream AI use cases" ], "failure_signals": [ "Training datasets do not carry a purpose mapping reference in their metadata — the pipeline has no programmatic access to purpose compatibility status", "Datasets are marked 'training-eligible' by default without requiring a purpose mapping assessment", "No mechanism exists to detect when a dataset's source changes its stated collection purpose" ] }, "dpo": { "summary": "The DPO must sign off on every Art 6(4) compatibility assessment before AI repurposing is permitted; the assessment must be substantive, not formulaic, and must honestly evaluate the potential consequences for data subjects.", "actions": [ "Establish a compatibility assessment template that requires evaluators to address all five Art 6(4) factors explicitly with concrete reasoning rather than generic statements", "Maintain a log of all compatibility assessments and their outcomes, including cases where the assessment concluded that repurposing was incompatible and a new lawful basis was required", "Monitor regulatory guidance and enforcement decisions on purpose limitation in AI contexts — particularly EDPB and ICO decisions — and update assessment templates when interpretations shift" ], "failure_signals": [ "Compatibility assessments are one-line statements asserting compatibility without factor analysis", "The DPO has approved assessments for AI use cases that claim compatibility with an original purpose of 'service improvement' without specificity", "No record exists of assessments that concluded repurposing was incompatible — an absence of rejections suggests the process is not substantive" ] }, "data_governance": { "summary": "Purpose limitation mapping requires governance to maintain authoritative records of original collection purposes and to ensure that AI product teams are aware of purpose constraints when scoping new features.", "actions": [ "Maintain original collection purposes in the data inventory (DC-01) as a governed attribute with change management — updates require DPO review since they affect all downstream compatibility assessments", "Include purpose limitation review as a mandatory step in the AI feature design review process so that engineers identify and assess repurposing risks before development begins", "Report the proportion of AI training datasets with completed purpose maps and approved compatibility assessments to the governance committee quarterly" ], "failure_signals": [ "Original collection purposes in the data inventory are written as broad, vague statements that cannot support a specific compatibility assessment", "AI feature design reviews do not include a purpose limitation checkpoint", "Governance committee reporting does not track purpose mapping coverage for AI datasets" ] }, "grc_auditor": { "summary": "Purpose limitation compliance requires auditable evidence that every AI data use was assessed for compatibility before processing began; assessments must be substantive, DPO-signed, and linked to specific dataset versions.", "actions": [ "Sample AI training datasets and verify each has a purpose mapping record linking the AI purpose to the original collection purpose and a dated DPO-signed compatibility assessment", "Review rejected compatibility assessments and confirm they resulted in either use case cancellation or establishment of a new lawful basis rather than informal workarounds", "Assess whether compatibility assessments reference specific original collection purpose text from the relevant privacy notice, confirming the assessment is grounded in actual disclosed purposes" ], "metrics": [ "Percentage of active AI training datasets with a completed and DPO-approved purpose mapping assessment (target: 100%)", "Number of compatibility assessments concluding incompatibility per quarter (a zero result warrants process review)" ], "failure_signals": [ "AI training datasets lack purpose mapping records or carry unapproved draft assessments", "All compatibility assessments in the sample conclude compatibility — the process shows no evidence of substantive evaluation", "Purpose maps reference privacy notice language from notices that predate the AI use case, suggesting assessments were not updated when the AI purpose was defined" ] }, "software_engineering": { "summary": "Purpose limitation is a dataset metadata concern that must be enforced at the API and pipeline layers; no dataset should be accessible to a training job without a validated purpose mapping reference in its metadata.", "actions": [ "Add a 'purpose_mapping_id' field to the training dataset schema as a required field; the pipeline launcher validates the ID against the purpose mapping service before allowing job execution", "Build a purpose mapping webhook that fires when a dataset's training-eligibility status changes — for example when an assessment is approved or when a previously approved assessment is revoked — so dependent pipelines can react", "Include purpose limitation validation in the automated integration test suite for all data access services to prevent regressions in the enforcement gate" ], "failure_signals": [ "Dataset objects in the training platform do not have a purpose_mapping_id field", "The pipeline launcher does not call the purpose mapping service before executing a training job", "Revoking a previously approved compatibility assessment does not trigger any notification to dependent training pipelines" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations lack a structured process for assessing compatibility between original collection purposes and AI training uses; the target state is a purpose mapping registry with DPO-gated compatibility assessments integrated into the pipeline admission gate." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "DPO Office", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(b)/Art 6(4)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-06 implements GDPR Art 5(1)(b) purpose limitation and Art 6(4) compatibility assessment requirements by creating a purpose mapping registry and requiring DPO-approved assessments before personal data is used for AI purposes beyond the original collection context.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "ID.IM-P5", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-06 implements NIST Privacy Framework ID.IM-P5 — the purposes for the data actions are inventoried — by mapping every AI data category to its authorized processing purposes and blocking out-of-purpose use.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27701", "requirement_id": "7.2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-06 partially satisfies ISO 27701 clause 7.2 by documenting the purposes of personal information processing and requiring compatibility assessments when AI use cases extend beyond original stated purposes.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Training Data Management", "rationale": "SAIF's Training Data Management control requires that data used to train and evaluate models is appropriate and authorized for the intended use, mitigating the Unauthorized Training Data risk; DC-06's purpose mapping operationalizes that authorization for personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF Training Data Management authorizes data for intended use, adjacent to purpose limitation but not the Art 6(4) compatibility assessment DC-06 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Lake Formation Fine-Grained Access Control", "rationale": "AWS Lake Formation implements purpose-based data access through column-level, row-level, and cell-level security policies. These policies can be configured to enforce purpose limitation by granting AI workloads access only to the specific data attributes required for their documented processing purpose, with all access decisions logged in CloudTrail for audit.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Lake Formation fine-grained access restricts AI workloads to purpose-necessary fields, enforcing part of the control but not the Art 6(4) assessment.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — Privacy & Security goals", "rationale": "The Microsoft Responsible AI Standard v2 Privacy & Security goals require AI systems to comply with Microsoft's privacy and security policies, including limiting data collection and use to the stated purpose; DC-06 implements the equivalent purpose-limitation mapping for enterprise AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Microsoft RAI Standard's purpose-limitation goal aligns with DC-06's intent but states a principle rather than the mapping and Art 6(4) assessment mechanism.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-06 requires a signed Art 6(4) compatibility assessment before repurposed personal data can be ingested, confining AI use to purpose-permitted data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "AI training is the canonical purpose-creep scenario: data collected to power a product feature is repurposed into a training corpus without the people it describes ever consenting to that use. DC-06 makes purpose limitation operational by requiring a documented compatibility assessment for every AI data use before ingestion begins, creating an auditable chain of deliberate authorization rather than silent repurposing.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-06", "validation_objective": "Every AI use case that processes personal data for a purpose different from its original collection context must have a documented GDPR Art 6(4) compatibility assessment, signed by the DPO, before data ingestion is permitted. The pipeline admission gate must validate that a purpose_mapping_id referencing an approved compatibility assessment exists for every dataset before the training job executes.", "evidence_required": [ "purpose_mapping_registry_export — export of all AI use case purpose maps with fields: use_case_id, dataset_id, original_collection_purpose, ai_processing_purpose, assessment_outcome (compatible/incompatible/new-basis-established), dpo_signature, and approval_date", "compatibility_assessment_log — DPO-signed compatibility assessments for all AI uses where repurposing was required, including Art 6(4) factor evaluations: link_between_purposes, collection_context, data_nature_and_sensitivity, consequences_for_subjects, and safeguards_applied", "purpose_gate_audit_log — pipeline admission gate log showing purpose_mapping_id lookup result (pass/reject) and dataset_id for all training runs in the audit period", "purpose_drift_alert_log — alerts generated when a dataset's original collection purpose changed requiring re-assessment of downstream AI use cases" ], "machine_tests": [ "Attempt to launch a training job against a dataset whose purpose_mapping_id field is absent → assert the pipeline admission gate rejects the job with error_code=missing_purpose_mapping", "Submit a compatibility assessment for a proposed AI use case through the DPO approval workflow → assert the workflow routes correctly and records the outcome in the purpose mapping registry with a DPO signature and effective date", "Introduce a new AI purpose for an existing dataset without updating the purpose map → assert the staleness alert fires and the next training run against that dataset is blocked" ], "human_review": [ "DPO review of all compatibility assessments to confirm they address all five Art 6(4) factors with concrete reasoning and that none are generic statements asserting compatibility with 'service improvement' without specificity", "Assess whether any training dataset has a compatibility assessment concluding incompatibility and verify it resulted in use case cancellation or a documented new lawful basis rather than an informal workaround", "Review the purpose_gate_audit_log for any training runs that completed without a valid purpose_mapping_id lookup and investigate how the gate was bypassed" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Using a broad original purpose statement such as 'to improve our services' as a blanket justification for any AI training use without conducting a specific compatibility assessment for each AI use case", "Conducting the compatibility assessment after data has already been ingested into a training pipeline rather than as a prerequisite gate before ingestion begins", "Allowing the dataset to be marked 'training-eligible' by default without requiring a purpose mapping assessment as a mandatory step in the dataset registration workflow", "Failing to re-assess compatibility when the original collection purpose changes — for example when the source product's privacy notice is updated to narrow its stated purposes", "Treating DPO sign-off on compatibility assessments as a rubber stamp by routing all assessments to the DPO without substantive factor analysis pre-populated by the requesting team" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-07", "layer": "DC", "plane": "data", "name": "Children's Data Controls", "plain": "AI systems that may process data relating to minors implement age verification, require parental consent where required, and exclude children's data from training corpora by default.", "threat": { "tags": [ "coppa-violation", "art8-violation", "age-verification-bypass" ], "desc": "AI training corpora routinely contain content from children without parental consent. Absence of age verification and default exclusion of children's data creates systematic GDPR Art 8 and CCPA minor protections violations." }, "standard": [ { "id": "gdpr", "section": "Art 8", "title": "Conditions applicable to children's consent" }, { "id": "ccpa", "section": "§1798.120 (minors)", "title": "Minor consumer protections and opt-in requirements" }, { "id": "uk_duaa", "section": "children provisions", "title": "Children's data protections" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-07 Children's Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DC-07 Children's Data Controls control.", "reviewed_on": "2026-07-02" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/DC-07 Children's Data Controls control.", "reviewed_on": "2026-07-02" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DC-07 Children's Data Controls control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement a children's data control layer with three components: (1) age estimation or verification at data ingestion that flags records potentially relating to minors, (2) a default-exclude policy that removes flagged records from AI training datasets unless parental consent is explicitly documented in the consent registry, and (3) a children's data audit that samples training corpora periodically to detect and remove improperly admitted minor-related records.", "steps": [ "Deploy age estimation classifiers across all AI training data sources that flag records where the data subject is identified as or likely to be under the applicable age threshold — 16 in GDPR default, 13 in CCPA, 18 for certain CCPA minor protections", "Apply a default-exclude policy to all flagged records: they are automatically removed from training dataset candidates unless the consent registry contains a verified parental consent record for the specific data subject and the specific AI processing purpose", "Implement a sampling audit that randomly draws records from finalized training datasets and applies the age classifier, flagging any records that bypassed the default-exclude filter, and routing findings to the DPO within 24 hours", "Maintain a children's data control report covering: number of records flagged, number excluded by default, number admitted on the basis of parental consent, and number found in the post-hoc audit" ], "anti_patterns": [ "Relying solely on user-declared age at account creation without any independent age estimation — minors routinely declare false ages to access services, and AI training corpora inherit this inaccuracy", "Applying children's data controls only to explicitly child-directed services while ignoring general-audience platforms where significant numbers of minor users are statistically certain to be present" ] }, "validation": { "design_check": [ "Age estimation or verification classifiers are deployed across all AI data ingestion paths with documented accuracy thresholds and a default-exclude policy for records above the uncertainty threshold [ref:gdpr_2016_679]", "A parental consent verification mechanism is in place and linked to the consent registry, with parental consent records required before any minor-flagged record is admitted to a training dataset [ref:ccpa_cpra_2023]", "Post-hoc sampling audits are scheduled and running on all finalized training datasets with findings routed to the DPO within 24 hours of detection [ref:uk_duaa_2025]" ], "runtime_test": [ "Inject synthetic records with declared ages of 12, 15, and 17 into a training data candidate set and verify that the age classifier flags all three and the default-exclude policy removes them from the final training dataset", "Insert a synthetic parental consent record in the consent registry for a specific minor data subject and verify that the record is admitted to the training dataset when re-processed", "Run the post-hoc sampling audit against a training dataset and verify that it correctly identifies injected minor records that were not flagged by the ingestion classifier" ], "evidence": [ "privacy:childrens-data-control-report — Per-training-dataset report showing count of records flagged by age classifier, excluded by default policy, admitted on parental consent, and found in post-hoc audit [unverified]", "privacy:parental-consent-registry — Export of parental consent records in the consent registry linked to specific data subjects and AI processing purposes [unverified]", "privacy:age-classifier-accuracy-assessment — Technical accuracy evaluation of the age estimation classifier including false-negative rate and threshold calibration [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Children's data controls require age estimation at ingestion combined with a default-exclude policy that cannot be overridden without a verified parental consent record; the control must cover all general-audience platforms, not just explicitly child-directed services.", "actions": [ "Train and deploy age estimation classifiers calibrated to err on the side of flagging borderline cases as minor-related, accepting higher false-positive rates in exchange for lower false-negative rates given the severity of the regulatory consequence", "Implement the default-exclude policy as a mandatory filter in the training dataset finalization step that removes all minor-flagged records before the dataset is sealed for a training run", "Build the parental consent admission path as an exception workflow requiring explicit DPO review before a minor's data may be admitted, rather than an automated override" ], "failure_signals": [ "Age estimation is not run on general-audience platform data on the assumption that 'most users are adults'", "The default-exclude policy can be overridden by training pipeline engineers without DPO involvement", "The age classifier's false-negative rate — minors it fails to flag — has not been measured or documented" ] }, "dpo": { "summary": "Children's data protections are among the most rigorously enforced privacy rights; the DPO must ensure that the default-exclude policy is genuine, that parental consent is verifiable, and that findings from post-hoc audits are remediated without exception.", "actions": [ "Review and approve the age threshold settings for each jurisdiction where personal data is collected, accounting for GDPR Art 8's range (13–16 per member state choice), CCPA's 13/16 thresholds, and UK DUAA requirements", "Personally review and approve every parental consent admission exception before a minor's data is admitted to a training dataset — this must not be an automated or delegatable decision", "Require immediate remediation for any minor records found in post-hoc audits: the affected training run must be assessed for whether the model needs to be retrained without the improperly admitted data" ], "failure_signals": [ "Age thresholds are set at a single global value without jurisdiction-specific calibration", "Parental consent admissions are approved by the training team without DPO review", "Post-hoc audit findings are logged but remediation is deferred rather than treated as an immediate priority" ] }, "data_governance": { "summary": "Children's data is a governance-elevated data category requiring its own stewardship rules, access controls, and reporting; governance must ensure that the children's data control report is reviewed at every data governance committee meeting.", "actions": [ "Classify children's data as an elevated-sensitivity data category in the data inventory with restricted steward access and mandatory DPO involvement for any processing decisions", "Include the children's data control report as a standing agenda item in the data governance committee meeting, with trend analysis of flagging and admission rates", "Require that any AI use case involving a platform with a significant minor user base complete a children's data impact assessment as a prerequisite for DPO approval" ], "failure_signals": [ "Children's data is not classified as a distinct elevated-sensitivity category in the data inventory", "The data governance committee has never reviewed a children's data control report", "AI use cases involving platforms with known minor user populations have not completed children's data impact assessments" ] }, "grc_auditor": { "summary": "Children's data compliance is a zero-tolerance area; any minor's data found in a training corpus without verified parental consent is an audit finding requiring immediate escalation regardless of the count.", "actions": [ "Conduct an independent sampling audit of all training datasets covering AI use cases that touch general-audience platforms, using the age classifier independently of the production system to check for false-negative rates", "Review the parental consent admission log and verify each admission has a DPO approval record and a verifiable parental consent record in the consent registry", "Cross-reference the age threshold settings against the regulatory requirements of each jurisdiction where data subjects reside and flag any settings that fall below the required threshold" ], "metrics": [ "Count of minor records found in finalized training datasets without parental consent (target: zero)", "Post-hoc audit sampling rate across finalized training datasets per quarter (target: minimum 10% of dataset records)" ], "failure_signals": [ "Any minor record is found in a finalized training dataset without a corresponding parental consent record", "The independent audit classifier detects minor records at a rate significantly higher than the production system, indicating a high false-negative rate in production", "Age threshold settings do not match the requirements of the highest-protection jurisdiction applicable to the data subjects" ] }, "software_engineering": { "summary": "The default-exclude policy must be implemented as a non-bypassable filter in the training dataset finalization pipeline; there must be no engineering-level override path that admits minor-flagged records without triggering the DPO approval workflow.", "actions": [ "Implement the age-flag and default-exclude logic as a mandatory, non-configurable filter in the training dataset builder — not as an optional pre-processing step that engineers can skip", "Build the parental consent admission path as a separate, explicitly-approved pipeline variant that requires a DPO approval token in its configuration — absence of the token causes the job to fail", "Add automated tests that verify the default-exclude filter is applied on every training dataset finalization and that the filter cannot be disabled via configuration flags" ], "failure_signals": [ "The age-flag filter is implemented as an optional preprocessing step with a configuration flag that can be set to 'skip'", "Engineers can launch training jobs against the full unfiltered dataset by omitting the children's data filter configuration", "No automated tests exist that verify the default-exclude filter is applied during dataset finalization" ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations apply children's data controls only to explicitly child-directed services; the target state is a default-exclude policy applied to all AI training data from general-audience platforms with automated age estimation and post-hoc audit sampling." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Legal/Compliance", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 8", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-07 implements GDPR Art 8 by establishing age verification, parental consent requirements, and a default-exclude policy for children's data across all AI training corpora where data subjects may include minors.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.120 (minors)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-07 implements CCPA §1798.120 minor consumer protections by requiring opt-in consent for consumers aged 13-15 and parental consent for consumers under 13 before their data may be used in AI training or sharing.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "children provisions", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-07 partially satisfies UK DUAA children's data protections by implementing age estimation and default-exclude policies for AI training data; full compliance requires implementation of UK Children's Code specific safeguards addressed in the DG layer.", "source_version": "2025 c.15", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aws_privacy", "requirement_id": "AWS Shared Responsibility Model — customer obligations for children's data", "rationale": "AWS documents that compliance with children's privacy laws such as COPPA rests with the customer under the shared responsibility model; DC-07 implements the customer-side age-signal detection and heightened-consent controls for AI workloads on AWS.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS's shared-responsibility note assigns COPPA duty to the customer, giving responsibility context but no age-verification or parental-consent mechanism.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DC-07 excludes minor records from training datasets absent verified parental consent, keeping unlawfully-held children's data out of AI training.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Children's personal data in AI training corpora represents one of the most serious and least visible regulatory risks in AI development — minors cannot meaningfully consent, parental consent is rarely obtained, and training corpora scraped from general-audience platforms are statistically certain to contain children's data. DC-07 makes the default 'children's data excluded' rather than 'adults assumed', treating protection as the starting point rather than an exception to be justified.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-07", "validation_objective": "All AI training datasets must be scanned by an age estimation classifier before finalization, and records identified as relating to minors must be excluded by default unless a corresponding verified parental consent record exists in the consent registry. Post-hoc sampling audits must confirm that no minor records are present in finalized training datasets without documented parental consent.", "evidence_required": [ "childrens_data_control_report — per-training-dataset report with fields: records_scanned, records_flagged_as_minor, records_excluded_by_default_policy, records_admitted_on_parental_consent (with consent_registry_ids[]), and records_found_in_post_hoc_audit", "parental_consent_registry_export — export of all parental consent records linked to specific minor data subjects and AI processing purposes, with consent_source and verification_method fields", "age_classifier_accuracy_assessment — technical evaluation of the age estimation classifier including false_negative_rate (minors not flagged), threshold calibration by jurisdiction, and date of last accuracy review", "post_hoc_audit_log — sampling audit records showing dataset_id, sample_size, minor_records_found, and DPO_notification_timestamp for each audit run" ], "machine_tests": [ "Inject synthetic records with declared ages of 12, 15, and 17 into a training data candidate set → assert the age classifier flags all three records and the default-exclude policy removes them from the finalized training dataset", "Insert a synthetic parental consent record in the consent registry for a specific minor data subject and re-process the dataset → assert the minor's record is admitted to the training dataset and the admission is logged with the consent_registry_id", "Attempt to launch a training job with the age-flag filter disabled via a configuration flag → assert the pipeline launcher rejects the job with error_code=children_filter_required" ], "human_review": [ "DPO personal review and approval of every parental consent admission exception before a minor's data is admitted to a training dataset, with DPO sign-off recorded in the childrens_data_control_report", "Review age threshold settings against the regulatory requirements of each applicable jurisdiction — GDPR Art 8 member state thresholds (13-16), CCPA 13/16 thresholds, and UK DUAA requirements — and flag any settings below the required threshold", "Assess whether the age classifier's false-negative rate is acceptable and whether any minor records found in post-hoc audits indicate systemic classifier failures requiring retraining or threshold recalibration" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Relying solely on user-declared age at account creation without running independent age estimation — minors routinely declare false ages to access general-audience services, and AI training corpora inherit this inaccuracy at scale", "Applying children's data controls only to explicitly child-directed services while ignoring general-audience platforms where significant numbers of minor users are statistically certain to be present", "Implementing the default-exclude filter as an optional configuration step that training pipeline engineers can skip by omitting the filter flag in their job specification", "Allowing parental consent admission to be approved by the training team without DPO personal review, treating it as an automated exception rather than a rights-sensitive human decision", "Running the age classifier only at dataset creation time and not re-running on dataset updates or augmentations that add new records from sources not previously scanned" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-08", "layer": "DC", "plane": "data", "name": "Consent Change Propagation", "plain": "Consent updates — additions, restrictions, or withdrawals — are propagated from the consent registry to all downstream systems including model training pipelines and third-party processors in a defined, auditable sequence.", "threat": { "tags": [ "consent-change-not-propagated", "stale-consent-state", "cross-system-inconsistency" ], "desc": "Distributed AI systems — with multiple microservices, external processors, and regional deployments — frequently operate with stale consent state due to propagation delays or failures. Consistency across distributed systems is a technical prerequisite for accountability." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)/Art 7(3)", "title": "Accountability for consent state and withdrawal" }, { "id": "iso_27701", "section": "7.3.7", "title": "Obligations to inform third parties of consent changes" }, { "id": "nist_pf", "section": "CT.DM-P7", "title": "Mechanisms for transmitting processing permissions with data elements" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DC-08 Consent Change Propagation control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement a consent change event bus that publishes every consent state change — grant, restriction, or withdrawal — as a durable, typed event that downstream systems consume via subscriptions; each subscriber must acknowledge receipt and return a propagation completion confirmation within a defined SLA, with the consent registry tracking propagation status until all subscribers have confirmed.", "steps": [ "Define a consent change event schema with: event type (grant/restrict/withdraw), data subject identifier (hashed), scope (data category and purpose), effective timestamp, and a unique event ID for tracking", "Deploy a durable event bus — using a message broker with at-least-once delivery — that all downstream systems and third-party processors subscribe to for consent change events relevant to their data processing activities", "Implement a propagation acknowledgment protocol where each subscriber returns a typed acknowledgment event referencing the consent change event ID and confirming the system has updated its consent state and halted any in-scope processing", "Monitor propagation completeness in real time and alert the DPO when any subscriber has not acknowledged a consent change event within the defined SLA, maintaining an open propagation case until all acknowledgments are received" ], "anti_patterns": [ "Implementing consent change propagation as a point-to-point notification from the registry to a static list of known subscribers — this pattern breaks silently when new systems are added and fails to discover dynamically provisioned AI pipelines", "Treating propagation as complete when the event is published to the bus rather than when all subscriber acknowledgments are received — publication without confirmed consumption provides no accountability guarantee" ] }, "validation": { "design_check": [ "A typed consent change event schema is defined and all consent state changes in the registry publish events conforming to this schema to the durable event bus [ref:gdpr_2016_679]", "All downstream AI systems and third-party processors are registered as subscribers to the consent change event bus, and new system onboarding includes mandatory subscriber registration [ref:iso_27701_2019]", "Propagation completeness tracking is in place and alerts the DPO when any subscriber acknowledgment is overdue relative to the defined SLA [ref:nist_pf_1_0]" ], "runtime_test": [ "Publish a synthetic consent restriction event for a test data subject and verify that all registered downstream subscribers receive the event and return acknowledgments within the SLA window", "Simulate a subscriber outage by taking a test subscriber offline and verify that the propagation tracking system detects the missing acknowledgment and raises a DPO alert within the escalation window", "Onboard a new test downstream system without registering it as a consent change subscriber and verify that the subscriber registration gate blocks the system from accessing personal data until it is registered" ], "evidence": [ "privacy:consent-change-propagation-log — Durable log of all consent change events published on the event bus with per-subscriber acknowledgment timestamps and open case records for pending acknowledgments [unverified]", "privacy:subscriber-registry — Current list of all registered consent change event subscribers including downstream AI systems and third-party processors [unverified]", "privacy:propagation-sla-compliance-report — Report of all consent change events in the audit period with propagation completeness rates and SLA adherence by subscriber [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Consent change propagation is a distributed systems problem requiring the same engineering rigor as financial transaction propagation — guaranteed delivery, acknowledgment tracking, dead-letter handling, and consistency verification across all subscribers.", "actions": [ "Choose a message broker that provides at-least-once delivery with consumer group acknowledgments, and configure subscriber clients to process events idempotently so duplicate deliveries do not corrupt consent state", "Build the subscriber registry as a service component so that new downstream system onboarding automatically triggers subscription registration and initial consent state synchronization", "Implement a consent state reconciliation job that periodically compares the consent registry's authoritative state against each subscriber's locally cached consent state, flagging and correcting divergences" ], "failure_signals": [ "The event bus uses a fire-and-forget publish model without consumer acknowledgment tracking", "New AI systems are deployed that access personal data without being registered as consent change event subscribers", "No reconciliation mechanism exists to detect subscribers whose local consent state has diverged from the authoritative registry" ] }, "dpo": { "summary": "Consent change propagation is an accountability obligation under GDPR Art 5(2); the DPO must be able to demonstrate that every consent change was communicated to and acknowledged by every system and processor that relies on that consent.", "actions": [ "Define SLAs for propagation acknowledgment by subscriber type in data processing agreements: immediate systems (training pipeline launchers) require acknowledgment within 1 hour; third-party processors within 24 hours", "Review the open propagation case queue weekly and initiate contractual enforcement for third-party processors with persistent acknowledgment failures", "Require that the propagation log is produced as evidence in response to any data subject rights request that questions whether their consent change was honored across all systems" ], "failure_signals": [ "Data processing agreements do not specify consent change propagation acknowledgment SLAs for processors", "Open propagation cases exist for subscribers that have not acknowledged consent changes older than the applicable SLA", "The propagation log cannot be produced to demonstrate that a specific consent change was honored across all systems" ] }, "data_governance": { "summary": "The subscriber registry is a governance asset that must be maintained as an authoritative list of all systems with access to personal data; its completeness directly determines the effectiveness of consent change propagation.", "actions": [ "Govern the subscriber registry as an authoritative asset with change management: additions require security and privacy review, and removals must confirm that no personal data access paths remain after deregistration", "Include subscriber registry completeness as a governance KPI: the registry must account for 100% of systems known to access personal data, including AI microservices and third-party processors", "Report propagation completeness rates by subscriber class to the data governance committee quarterly, with trend analysis to identify recurring problem subscribers" ], "failure_signals": [ "The subscriber registry is maintained informally and has not been reconciled against the data inventory's processor list within the past quarter", "Systems accessing personal data are decommissioned without being removed from the subscriber registry, creating phantom entries that generate false-positive propagation failures", "Propagation completeness rates are not tracked or reported to the governance committee" ] }, "grc_auditor": { "summary": "Consent change propagation completeness is a directly auditable compliance obligation; the propagation log must show a complete acknowledgment chain for every consent change event, and any open cases must have documented escalation records.", "actions": [ "Sample consent change events from the propagation log and verify each has acknowledgment records from all registered subscribers within the applicable SLA", "Cross-reference the subscriber registry against the data inventory processor list to identify systems accessing personal data that are not registered as consent change subscribers", "Review open propagation cases and assess whether DPO escalation actions have been taken for all cases exceeding the acknowledgment SLA" ], "metrics": [ "Consent change propagation completeness rate — percentage of events with full subscriber acknowledgment within SLA (target: 100%)", "Subscriber registry coverage — percentage of personal data access systems registered as consent change subscribers (target: 100%)" ], "failure_signals": [ "Consent change events in the propagation log have missing or late subscriber acknowledgments without corresponding escalation records", "The subscriber registry covers fewer than 100% of systems identified in the data inventory as accessing personal data", "Open propagation cases exist for consent changes older than twice the applicable SLA without documented DPO escalation" ] }, "software_engineering": { "summary": "The consent change event bus must be designed for reliability-first: at-least-once delivery, idempotent consumer processing, dead-letter queues for failed deliveries, and a circuit breaker that denies personal data access to subscribers with unresolved propagation failures.", "actions": [ "Implement subscriber clients with idempotent event processing using the consent change event ID as a deduplication key, so that redelivered events do not cause duplicate consent state updates", "Deploy a dead-letter queue for consent change events that exceed the maximum delivery retry count, and route dead-letter entries to an immediate DPO alert rather than silent discard", "Build a circuit breaker that denies personal data access API calls from any subscriber that has an unacknowledged consent change event older than the escalation threshold, forcing the subscriber to resolve its propagation backlog before resuming access" ], "failure_signals": [ "Subscriber clients do not implement idempotent processing — redelivered events cause consent state flip-flop", "Failed event deliveries are silently discarded rather than routed to a dead-letter queue", "Personal data access APIs do not check propagation status before serving data to subscriber systems with outstanding unacknowledged consent change events" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations propagate consent changes through point-to-point notifications or batch jobs without acknowledgment tracking or completeness verification; the target state is a durable event bus with subscriber acknowledgment tracking and completeness monitoring integrated with the consent registry." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai" ], "implementers": [ "Privacy Engineering", "Software Engineering", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(2)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DC-08 partially satisfies GDPR Art 5(2) accountability obligation by maintaining a propagation log that demonstrates consent changes were communicated to and acknowledged by all downstream systems; full accountability requires integration with DC-05 withdrawal processing.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.3.7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 7.3.7 requires controllers to inform third parties with whom PII has been shared of any modification, withdrawal, or objection; DC-08's propagation and acknowledgment mechanism operationalizes that obligation.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DC-08 implements NIST Privacy Framework CT.DM-P7 — mechanisms for transmitting processing permissions and related data values with data elements — by propagating consent-state changes to every downstream processing point with acknowledgment tracking.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta Workflows — event-driven lifecycle automation", "rationale": "Okta Lifecycle Management provides event-driven workflows that propagate consent state changes from Universal Directory to all connected applications in real-time. When a consent record is updated—whether expanded or withdrawn—Okta event hooks trigger downstream provisioning and deprovisioning actions, ensuring consent changes propagate across the application stack without manual intervention.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta Workflows event hooks propagate consent-state changes to connected apps in real time, covering propagation but not the complete acknowledgment-chain SLA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI API data controls — retention and training configuration", "rationale": "OpenAI's API data control configuration allows enterprise customers to update data processing preferences, and changes take effect for subsequent API calls. Changes to consent-linked data retention settings propagate through OpenAI's data handling infrastructure; customers are responsible for ensuring their own downstream systems receive and honor consent change signals from their end-users.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI API config changes take effect on later calls at the vendor layer but do not propagate consent changes across the enterprise's downstream systems.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum — processing on documented instructions", "rationale": "Under Anthropic's DPA, enterprise customers can update data processing instructions, and Anthropic commits to processing data only in accordance with documented controller instructions. Changes to consent-linked processing instructions—such as switching to ZDR or expanding retention opt-in—take effect upon written confirmation, creating a documented change propagation record.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic honors updated processing instructions on confirmation, a vendor-layer change record rather than an estate-wide consent-change propagation mechanism.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "In distributed AI architectures, consent consistency is a distributed systems problem that requires the same engineering discipline as financial transaction consistency — eventual consistency is not acceptable when the gap between consent state and processing state creates a legal violation. DC-08 enforces consent change propagation as a reliability obligation with guaranteed delivery, acknowledgment tracking, and access denial for non-compliant subscribers.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-08", "validation_objective": "All downstream systems and third-party processors must have a confirmed, timestamped acknowledgment for every consent change event published since the system's onboarding date, and no subscriber may hold a propagation acknowledgment gap older than the contractually defined SLA window. The consent registry propagation log must show a closed, complete acknowledgment chain for 100% of consent change events in the audit period.", "evidence_required": [ "consent_change_propagation_log with event_id, event_type (grant/restrict/withdraw), data_subject_hash, scope, published_at, and per-subscriber acknowledgment timestamps for every event in the audit period", "subscriber_registry listing all downstream AI systems and third-party processors registered to receive consent change events, with onboarding date and subscription scope", "propagation_sla_compliance_report showing completeness rate per subscriber class and flagging any acknowledgment gaps exceeding the SLA threshold", "dpo_escalation_records documenting DPO alerts raised for overdue acknowledgments and resolution actions taken", "dead_letter_queue_report showing any consent change events that failed delivery with disposition (redelivered, escalated, or discarded)" ], "machine_tests": [ "Publish a synthetic consent-withdrawal event for a test data subject → assert all registered subscribers return acknowledgment events referencing the event_id within the defined SLA window", "Take a registered subscriber offline for 10 minutes then restore it → assert the propagation tracking system raises a DPO alert before the SLA expires and clears the alert upon receipt of the late acknowledgment", "Attempt to register a new downstream system for personal data access without first registering it as a consent-change-event subscriber → assert the access registration gate returns an error requiring subscriber registration first", "Inject a duplicate delivery of a consent change event to a subscriber → assert the subscriber processes the event idempotently and does not flip-flop consent state" ], "human_review": [ "Review the subscriber registry against the data inventory processor list to confirm every system known to process personal data is registered as a consent change event subscriber", "Assess open propagation cases to verify DPO escalation actions have been taken for all acknowledgment gaps exceeding the SLA, and confirm resolution evidence is documented", "Review data processing agreements with third-party processors to verify they specify consent change propagation acknowledgment SLAs consistent with the event bus configuration" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Treating propagation as complete when the event is published to the bus rather than when all subscriber acknowledgments are received, providing no accountability guarantee for consent state consistency", "Maintaining a static hardcoded list of notification targets instead of a dynamic subscriber registry, causing silently missed propagation when new AI systems or pipelines are provisioned", "Relying on batch consent state synchronization jobs (e.g., nightly reconciliation) rather than event-driven propagation, leaving hours-long windows where downstream systems process data under stale consent state", "Silently discarding undeliverable consent change events instead of routing them to a dead-letter queue and triggering DPO escalation", "Allowing subscriber systems to continue accessing personal data after an unacknowledged consent change event has aged past the SLA threshold, rather than enforcing a circuit-breaker suspension" ], "update_status": "current", "layer_code": "DC" }, { "id": "DC-09", "layer": "DC", "plane": "data", "name": "Data Collection Layer Evidence Package", "plain": "Compile a quarterly DC-layer evidence package consolidating artifacts from DC-01 through DC-08 to demonstrate that consent collection basis, training data governance, and consent change propagation controls are current, complete, and audit-ready. The package is a required input to PC-08 (PrivacyAttestation) production.", "threat": { "tags": [ "consent-evidence-gap", "attestation-unverifiable", "dpa-audit-readiness-deficit" ], "desc": "Without periodic structured compilation of DC-layer evidence, the PrivacyAttestation (PC-08) rests on assertions from individual controls rather than compiled and reviewed evidence. Gaps in consent basis documentation or propagation completeness are only visible through compilation." }, "standard": [ { "id": "gdpr", "section": "Art. 5(2)", "title": "Accountability for demonstrating lawful consent basis" }, { "id": "iso_27701", "section": "7.3", "title": "Consent management documentation and review" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records determined, documented, implemented, and reviewed" } ], "sources": [ { "id": "gdpr_2016", "title": "General Data Protection Regulation (GDPR) — Regulation (EU) 2016/679", "authority": "European Parliament and Council", "source_type": "regulation", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "public-domain", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes General Data Protection Regulation (GDPR) — Regulation (EU) 2016/679 requirements informing the apeiris://privacy/controls/DC-09 Data Collection Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "International Organization for Standardization", "source_type": "standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-29", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DC-09 Data Collection Layer Evidence Package control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-29", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DC-09 Data Collection Layer Evidence Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a quarterly evidence compilation process for the DC layer. Collect required artifacts from DC-01 through DC-08 including consent basis records, training data lineage documentation, and propagation completeness reports. Review completeness and identify gaps. Produce a signed evidence package for PC-08 attestation input.", "steps": [ "Define the DC-layer evidence package schema: required_artifacts[], acceptance_criteria[], gap_register, package_owner, DPO sign-off requirement, and retention policy.", "For each control in DC-01 through DC-08, define required evidence artifacts: DC-01 (consent basis register), DC-02/DC-03 (training data consent records, data subject right fulfillment logs), DC-04/DC-05 (cross-border transfer mechanism records), DC-06/DC-07 (retention schedule, data minimization review), DC-08 (propagation completeness report, acknowledgment log).", "Compile artifacts quarterly: generate consent completeness reports from the consent registry, pull propagation acknowledgment logs, and stage all artifacts for DPO review.", "Conduct a DPO-led review session to evaluate completeness, identify gaps, and assign remediation owners.", "Produce a signed DC-layer evidence package with an overall verdict and gap register, and submit it as input to the PC-08 PrivacyAttestation production cycle.", "Retain the package for the required period — minimum the longer of applicable regulatory retention or statute of limitations for privacy claims." ] }, "frameworks": [ { "framework": "gdpr", "requirement_id": "Art. 5(2)", "fit": "direct", "rationale": "GDPR Art. 5(2) requires controllers to demonstrate compliance with data protection principles. DC-09 is the structured compilation artifact that demonstrates DC-layer compliance to supervisory authorities.", "normative_force": "binding-law", "source_version": "2016/679", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.3", "fit": "direct", "rationale": "ISO/IEC 27701 clause 7.3 requires documented procedures for consent management. DC-09 provides the periodic evidence compilation that demonstrates those procedures are effective in practice.", "normative_force": "certification-standard", "source_version": "2019", "reviewed_on": "2026-06-29", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "direct", "rationale": "NIST Privacy Framework CT.DM-P8 requires audit/log records to be determined, documented, implemented, and reviewed in accordance with policy; DC-09 instantiates that review discipline at the consent collection layer.", "normative_force": "voluntary-standard", "source_version": "1.0", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Distributed AI deployments create consent state inconsistency risk at scale — consent may be lawfully collected but inadequately propagated to all processing points. DC-09 transforms the consent layer from a set of independently-assessed controls into a holistically-reviewed evidence package, making the distinction between controls deployed and controls effective visible and auditable.", "meta": { "authored_on": "2026-06-29", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DC-09", "validation_objective": "A complete DC-layer evidence package must be compiled and reviewed by the DPO or privacy lead on a quarterly cadence, consolidating artefacts from DC-01 through DC-08 that demonstrate the lawful basis, consent integrity, minimisation compliance, and propagation completeness of all personal data collection activities. No quarterly period may elapse without a documented, signed evidence package.", "evidence_required": [ "dc_layer_evidence_package with compilation timestamp, review sign-off by DPO or designated privacy lead, and index of artefacts sourced from DC-01 through DC-08", "consent_registry_snapshot showing all active consent records with lawful basis, scope, and expiry as of the package compilation date", "data_minimisation_audit_report confirming that data fields collected across AI pipelines align with stated purposes and minimisation commitments from DC-03 and DC-04", "propagation_completeness_summary from DC-08 covering the full quarter with per-subscriber acknowledgment rates", "dpo_sign_off_record with reviewer identity, review date, findings, and any remediation actions raised" ], "machine_tests": [ "Trigger the evidence package compilation pipeline for the current quarter → assert all DC-01 through DC-08 artefact slots are populated and the package status is 'complete' before DPO review is requested", "Query the evidence package index for the prior three quarters → assert each quarter has a package record with a non-null dpo_sign_off_record and no package is older than 95 days from the preceding package's compilation date", "Simulate a missing DC-05 (consent withdrawal log) artefact in the package compilation run → assert the pipeline halts with status 'incomplete' and raises an alert rather than producing a partial package" ], "human_review": [ "Assess the completeness and quality of artefacts included in the evidence package, verifying that each DC-layer control is represented by at least one current artefact with a retrieval date within the quarter", "Review findings and remediation actions documented in the DPO sign-off record to confirm open issues have been escalated appropriately and closed items have supporting resolution evidence" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Compiling the evidence package as a manual one-off exercise triggered only in response to a regulatory inquiry rather than on a standing quarterly schedule with automated artefact collection", "Producing a package that lists artefact references without including the artefacts themselves or verifying they are retrievable, creating a false assurance of completeness", "Allowing the DPO sign-off to occur without a structured review against each DC-layer control, reducing the package to a rubber-stamp exercise rather than a substantive accountability demonstration", "Storing the quarterly evidence package in a location inaccessible to auditors or regulators, undermining its purpose as an accountability artefact under GDPR Art 5(2)" ], "update_status": "current", "validation": { "design_check": [ "The DC-layer evidence package schema defines required artifacts for each of DC-01 through DC-08 with acceptance criteria, a named package owner, and a DPO sign-off requirement [ref:gdpr]", "The compilation pipeline halts with status 'incomplete' when any control's artifact slot is missing rather than producing a partial package [ref:iso_27701_2019]", "Each quarterly package carries a signed DPO review record with reviewer identity, findings, and remediation assignments [ref:nist_pf_1_0]" ], "runtime_test": [ "Trigger a compilation run with a deliberately missing DC-05 artifact and verify the pipeline halts with status 'incomplete' and raises an alert instead of emitting a partial package", "Query the package index for the prior four quarters and verify each has a signed package with no gap exceeding 95 days between compilation dates", "Select three artifacts at random from the latest package index and verify each is retrievable and its retrieval date falls within the covered quarter" ], "evidence": [ "privacy:dc-evidence-package — Quarterly DC-layer evidence package with artifact index, gap register, and DPO sign-off [unverified]", "privacy:consent-registry-snapshot — Point-in-time consent registry export with lawful basis, scope, and expiry per record [unverified]", "privacy:propagation-completeness-summary — DC-08 propagation report with per-subscriber acknowledgment rates for the quarter [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Automate artifact collection from DC-01 through DC-08 so the quarterly package is compiled by pipeline, not by hand, and a missing artifact fails the run instead of shipping a gap.", "actions": [ "Build a compilation pipeline that pulls each DC-layer control's evidence artifact by ID and halts with an alert when any slot is empty", "Emit a machine-readable package index with per-artifact retrieval timestamps so completeness can be verified programmatically" ], "failure_signals": [ "Evidence packages are assembled manually from shared drives in the week before an audit", "Package compilation succeeds even when a DC-layer control produced no artifact for the quarter" ] }, "dpo": { "summary": "Treat the quarterly DC-layer package as the standing proof of Art 5(2) accountability for consent and collection — review it substantively, sign it, and track every gap to remediation.", "actions": [ "Conduct a structured quarterly review of the package against each DC-layer control before signing", "Require a remediation owner and due date for every gap recorded in the gap register" ], "failure_signals": [ "Sign-off records exist without documented findings or gap entries across multiple consecutive quarters", "A supervisory authority inquiry cannot be answered from the most recent package alone" ] }, "data_governance": { "summary": "Anchor the package to the same catalog identifiers used by DC-01 so every consent, classification, and propagation artifact traces back to a governed data category.", "actions": [ "Reconcile the package's artifact index against the personal data inventory each quarter to catch data categories with no evidence coverage", "Report package completeness and open-gap counts to the data governance committee" ], "failure_signals": [ "Artifacts in the package reference data categories that no longer exist in the inventory, or vice versa", "Gap register items persist across quarters without an assigned owner" ] }, "grc_auditor": { "summary": "Audit the package as the single consolidated exhibit for the DC layer — verify artifact completeness, retrieval dates within the quarter, and a substantive DPO sign-off.", "actions": [ "Sample artifacts from the latest package and verify each is retrievable and current for the covered quarter", "Compare the package schema against DC-01 through DC-08 evidence_required lists to confirm nothing was silently descoped" ], "metrics": [ "Percentage of DC-layer controls represented by a current artifact in the latest package (target: 100%)", "Maximum gap in days between consecutive quarterly packages (target: <= 95)" ], "failure_signals": [ "Package references artifacts that cannot be produced on request", "DPO sign-off predates the compilation timestamp of artifacts it purports to cover" ] }, "software_engineering": { "summary": "Expose each DC-layer control's evidence as a queryable artifact endpoint so the package compiler consumes structured outputs rather than screenshots and exports.", "actions": [ "Version evidence artifacts and include content hashes in the package index so tampering or drift is detectable", "Wire package compilation into scheduled CI so a failed or skipped quarterly run pages the owning team" ], "failure_signals": [ "Evidence artifacts are unversioned files with no integrity hash in the package index", "The quarterly compilation job has no owner and failures go unnoticed until audit time" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations assemble consent-layer evidence reactively when a regulator or auditor asks; the target state is a standing quarterly compilation pipeline with automated artifact collection, gap tracking, and DPO sign-off." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Privacy Engineering", "GRC" ], "layer_code": "DC" }, { "id": "DG-01", "layer": "DG", "plane": "lifecycle", "name": "Data Processing Register", "plain": "An Article 30-compliant Record of Processing Activities covering all AI-related processing is maintained and kept current with each model deployment, update, or decommission.", "threat": { "tags": [ "art30-non-compliance", "undemonstrated-lawful-processing", "regulatory-audit-failure" ], "desc": "Art 30 RoPA is the foundational accountability artifact. Absence or staleness — especially where AI deployments create new processing activities not reflected in the register — is among the most common GDPR enforcement findings." }, "standard": [ { "id": "gdpr", "section": "Art 30", "title": "Records of processing activities" }, { "id": "iso_27701", "section": "7.2.1", "title": "Privacy information management records" }, { "id": "nist_pf", "section": "ID.IM-P8", "title": "Data processing is mapped" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-02" }, { "id": "eu_data_gov_act_2022_868", "title": "EU Data Governance Act — Regulation (EU) 2022/868", "authority": "European Parliament and Council of the European Union", "source_type": "regulation", "normative_force": "binding-law", "version": "2022/868", "published_on": "2022-06-03", "retrieved_on": "2026-06-29", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R0868", "license": "open-access", "status": "current", "flagship": false, "source_id": "eu_data_gov_act_2022_868", "relationship": "normative_requirement", "rationale": "Establishes EU Data Governance Act — Regulation (EU) 2022/868 requirements informing the apeiris://privacy/controls/DG-01 Data Processing Register control.", "reviewed_on": "2026-07-01" }, { "id": "plot4ai", "title": "PLOT4ai — Practical Library Of Threats 4 AI", "authority": "PLOT4ai", "source_type": "community", "normative_force": "best-practice", "version": "1.0", "published_on": "2022-01-01", "retrieved_on": "2026-07-08", "canonical_url": "https://plot4.ai/library", "relationship": "supporting_guidance", "note": "PLOT4ai Data & Data Governance + Privacy & Data Protection threat categories inform the processing register." } ], "implementation": { "pattern": "Maintain a structured RoPA in a governed data-catalog or GRC platform, linked to each AI system deployment record so that model promotion to production triggers an automated RoPA update workflow.", "steps": [ "Define a canonical RoPA schema that includes AI-specific fields: model name, training data categories, inference data flow, automated decision indicator, and retention period.", "Integrate the RoPA update workflow with CI/CD pipelines so every model deployment, configuration change, or decommission event creates a RoPA change ticket routed to the DPO for review within 48 hours.", "Conduct a quarterly RoPA accuracy review — compare the register against the live AI system inventory, infrastructure network diagrams, and processor DPA schedules to close gaps.", "Store the RoPA in a version-controlled system with immutable audit trail so each revision, approval, and export is timestamped and attributable." ], "anti_patterns": [ "Maintaining RoPA in an unversioned spreadsheet outside the GRC system, making concurrent edits and historical comparison impossible.", "Treating AI inference pipelines as extensions of existing processing activities rather than distinct entries, obscuring the actual scope of AI-related processing from regulators." ] }, "validation": { "design_check": [ "Verify the RoPA contains an entry for every AI system in the inventory and that each entry includes purpose, lawful basis, data categories, retention period, and processor references [ref:gdpr_2016_679].", "Confirm the RoPA is updated within 48 hours of any AI system deployment, update, or decommission by reviewing the change log against the CI/CD deployment history [ref:iso_27701_2019].", "Validate that DPO sign-off is recorded for each RoPA entry and that the RoPA is accessible to the supervisory authority on request [ref:nist_pf_1_0]." ], "runtime_test": [ "Trigger a simulated model deployment to a non-production environment and verify that the RoPA update workflow fires, creates a ticket, and routes it to the DPO queue within the SLA window.", "Request an export of the RoPA in a machine-readable format and compare it against the live AI system inventory to identify any missing or stale entries.", "Simulate a supervisory authority examination scenario by presenting the RoPA to a privacy auditor and measuring the time-to-produce and completeness score." ], "evidence": [ "privacy:ropa-export — Full RoPA export from GRC system covering all AI processing activities [unverified]", "privacy:ropa-change-log — Version history showing update timestamps correlated with AI deployment events [unverified]", "privacy:dpo-sign-off — DPO approval records for each RoPA entry with date and identity [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The RoPA is the machine-readable manifest of what AI systems process; engineer it as a living artifact that updates automatically on deployment events rather than a document maintained manually.", "actions": [ "Build a RoPA schema with AI-specific fields and expose it as a structured API so downstream tools can query current processing scope.", "Wire the CI/CD deployment gate to require a RoPA entry ID before a model can promote to production.", "Implement a drift-detection job that compares the RoPA against infrastructure telemetry nightly and raises alerts on discrepancies." ], "failure_signals": [ "RoPA entries reference model versions that no longer exist in the model registry.", "New AI systems are found in network traffic analysis that have no corresponding RoPA entry.", "RoPA update timestamps lag deployment timestamps by more than 72 hours." ] }, "dpo": { "summary": "The RoPA is your primary accountability instrument and the first document any DPA will request; ensuring it covers AI processing activities with specificity is a non-negotiable baseline.", "actions": [ "Establish a quarterly RoPA accuracy review cadence with the AI governance team and document findings.", "Require written DPO sign-off before any new AI system enters production, with the RoPA entry as a pre-condition for sign-off.", "Maintain a DPA-ready export of the RoPA that can be produced within two hours of an authority request." ], "failure_signals": [ "AI systems are deployed without DPO notification or RoPA update.", "The RoPA does not distinguish AI-automated decisions from manual processing.", "Processing purposes for AI systems are described at such a high level of abstraction that they cannot be meaningfully reviewed." ] }, "data_governance": { "summary": "The RoPA is the authoritative map of data flows through AI systems; governance must ensure it reflects the actual data lineage from ingestion through training, inference, and archival.", "actions": [ "Map each RoPA entry to the corresponding data lineage graph in the data catalog so that changes to upstream data assets trigger RoPA review.", "Define ownership for each RoPA entry — a named data steward accountable for accuracy.", "Integrate RoPA entries with the data classification taxonomy so that each entry specifies the sensitivity tier of data processed." ], "failure_signals": [ "RoPA entries list data categories at too coarse a level — 'personal data' without specifying categories such as health, financial, or behavioral.", "No clear owner is named for a RoPA entry, making accuracy reviews impossible to attribute.", "Data lineage tools show data flows not reflected in the RoPA." ] }, "grc_auditor": { "summary": "DG-01 is a mandatory control under GDPR Art 30 and the first evidence item auditors will request; its completeness and currency are direct indicators of overall program maturity.", "actions": [ "Pull the RoPA from the GRC system and cross-reference every entry against the AI system inventory for completeness.", "Review change logs to verify RoPA updates align with known deployment events and that gaps are explained.", "Assess whether the RoPA format would satisfy a DPA examination by comparing it against the EDPB's published RoPA guidance." ], "metrics": [ "RoPA coverage ratio: percentage of production AI systems with a current RoPA entry (target 100%).", "RoPA update lag: average hours between AI system deployment and corresponding RoPA update (target < 48 h)." ], "failure_signals": [ "RoPA coverage ratio below 100% at any audit point.", "Update lag exceeding 72 hours for any deployment event.", "DPO sign-off records missing for one or more RoPA entries." ] }, "software_engineering": { "summary": "Treat the RoPA as structured data owned by the deployment pipeline, not a document owned by compliance — the CI/CD system is the source of truth for when processing activities begin and end.", "actions": [ "Add a pre-production deployment check that validates the model's RoPA entry ID exists and is in 'approved' status before allowing the deployment to proceed.", "Emit structured deployment events (model name, version, data categories, purpose) to the governance event bus so the GRC system can auto-populate RoPA drafts.", "Include RoPA entry ID in the model card and in the model registry record so every artifact points to its governance record." ], "failure_signals": [ "Deployment pipelines have no reference to or dependency on governance identifiers.", "Model cards do not include a privacy section linking to the RoPA entry.", "Model decommission events do not trigger any RoPA update." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain partial RoPAs that do not fully enumerate AI processing activities; reaching 'defined' requires integrating RoPA updates into automated deployment workflows." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Data Governance", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 30", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-01 implements the Art 30 obligation to maintain records of processing activities, specifically requiring coverage of AI-related processing and timeliness aligned with deployment cadence.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.2.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 7.2.1 requires that the PIMS maintain records of processing activities; DG-01 operationalizes this with AI-specific fields and automated update triggers.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "ID.IM-P8", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "DG-01 implements NIST Privacy Framework ID.IM-P8 — data processing is mapped, illustrating the data actions, associated data elements, and component owners/operators — by maintaining the authoritative processing register for AI systems.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Model and Data Inventory Management", "rationale": "SAIF's Model and Data Inventory Management control requires a maintained inventory of models, datasets, and ML artifacts; DG-01's processing register extends that inventory into the GDPR Art 30 accountability record for AI processing activities.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF model/data inventory is a related cataloging discipline but not the Art 30 RoPA legal accountability record with lawful bases and purposes DG-01 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Lake Formation and Glue Data Catalog — centralized governance registry", "rationale": "AWS Lake Formation Data Catalog provides a centralized governance registry that records all data assets, their schemas, access policies, and usage history. For AI workloads, Lake Formation creates an auditable register of which datasets are used in which ML training jobs, supporting data processing register requirements with technical traceability.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Lake Formation/Glue catalog records datasets and ML-job usage for traceability but not the Art 30 legal fields such as lawful basis and controller roles.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Data Map — lineage tracking", "rationale": "Microsoft Purview Data Map captures end-to-end data lineage across Azure services, automatically recording data movement into and out of AI training and inference systems. This automated lineage tracking provides the technical foundation for a data processing register by documenting every transformation and processing activity that personal data undergoes in AI pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Data Map captures end-to-end AI data lineage, a technical foundation for the register but not the Art 30 legal RoPA content itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_data_gov_act", "requirement_id": "Art. 20 (transparency requirements for data altruism organisations)", "fit": "supporting", "rationale": "EU Data Governance Act (2022/868) Art. 20 requires recognised data altruism organisations to keep full and accurate records of data processing — who processed the data, when, and for what purpose; DG-01's processing register provides the equivalent record-keeping for DGA-governed data use.", "normative_force": "binding-law", "source_version": "2022/868", "reviewed_on": "2026-07-02", "basis": "anchored", "relation": "satisfies" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Maintaining a current, AI-inclusive Record of Processing Activities is the foundational accountability obligation under GDPR Art 30 and the primary instrument through which an organization demonstrates that it understands what it processes. Without a complete and timely RoPA, all downstream privacy controls lack a verified scope to operate against.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-01", "validation_objective": "The organisation must maintain an Article 30-compliant Record of Processing Activities that is current as of the most recent model deployment or processing change, contains a complete entry for every AI-related processing activity, and is retrievable on demand within the timeframe required by the supervisory authority. No AI model deployment may proceed without a corresponding ROPA entry being approved and live.", "evidence_required": [ "ropa_record for each AI processing activity including controller identity, purposes, data subject categories, data categories, recipient categories, international transfer references, retention periods, and technical/organisational measures", "ropa_change_log showing every update made in the audit period with triggering event (new deployment, processing change), author, and approval timestamp", "deployment_gate_evidence showing that the ROPA update was approved before the corresponding AI model was deployed to production", "dpo_review_record confirming DPO review of ROPA completeness at least annually or after material changes", "ropa_retrieval_test_record demonstrating the ROPA can be produced in response to a supervisory authority request within the required timeframe" ], "machine_tests": [ "Trigger a simulated AI model deployment to the staging gate → assert the gate checks for a corresponding approved ROPA entry and blocks deployment if no entry exists or the entry is in 'draft' status", "Query the ROPA for an AI pipeline that was decommissioned in the prior quarter → assert the entry shows a decommission date and a retention schedule, not an active processing status", "Submit the ROPA export endpoint request → assert the response returns a complete, parseable record within 60 seconds and the record count matches the expected active processing activity count from the data inventory" ], "human_review": [ "Review a sample of ROPA entries against the corresponding AI system documentation to verify that purposes, data categories, and retention periods are accurate and not boilerplate copy-paste from prior entries", "Assess the ROPA change log against the deployment history to confirm every AI deployment in the audit period has a corresponding approved ROPA entry with a pre-deployment approval timestamp", "Verify that international transfer references in ROPA entries correctly link to active entries in the DG-03 transfer mechanism registry" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Maintaining the ROPA as a static Word or Excel document updated on an ad hoc basis rather than as a system-of-record with automated deployment gate integration", "Creating a single generic ROPA entry covering all AI processing activities rather than per-purpose, per-system entries, preventing meaningful accountability demonstration", "Populating ROPA retention periods with 'as long as necessary' or similar indefinite language rather than specific, justified time periods with review triggers", "Allowing AI model deployments to proceed before the corresponding ROPA entry is approved, creating a retroactive documentation pattern that cannot demonstrate pre-deployment lawfulness", "Failing to update ROPA entries when an AI model's processing scope changes materially (new data categories, new purposes, new processors), leaving stale entries that misrepresent actual processing" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-02", "layer": "DG", "plane": "lifecycle", "name": "Data Processor Agreements", "plain": "All third-party AI data processors operate under current Art 28-compliant Data Processing Agreements specifying subject matter, nature, purpose, duration, and audit rights before any personal data is shared.", "threat": { "tags": [ "processor-operating-outside-scope", "no-audit-rights", "processor-breach-without-notification" ], "desc": "Outsourcing AI processing to providers without current Art 28-compliant DPAs means the controller remains liable for processor non-compliance without contractual recourse. Sub-processor chains without DPAs compound this exposure." }, "standard": [ { "id": "gdpr", "section": "Art 28", "title": "Processor obligations and controller-processor contracts" }, { "id": "iso_27701", "section": "8.2", "title": "Conditions for sharing PII with processors" }, { "id": "ccpa", "section": "§1798.140(ag)", "title": "Service provider contractual requirements" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DG-02 Data Processor Agreements control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a processor register linked to the RoPA, with each AI processor entry holding the current DPA reference, sub-processor list, audit rights confirmation, and last-reviewed date; contract renewals and sub-processor changes trigger automatic review alerts.", "steps": [ "Build and maintain a processor register that cross-references each Art 30 RoPA entry with the corresponding DPA document ID, effective date, and sub-processor schedule.", "Before onboarding any new AI processor or expanding data sharing to an existing processor, require legal sign-off that a current Art 28-compliant DPA is in place and covers the specific processing activity.", "Audit sub-processor notification processes annually — verify each processor has a mechanism to notify you of sub-processor additions with sufficient notice to object.", "Perform biennial DPA gap assessments against the current EDPB standard contractual clauses template and update agreements where clauses are outdated." ], "anti_patterns": [ "Treating AI API usage as a software service rather than data processing, thereby bypassing DPA requirements on the assumption that the provider's Terms of Service are sufficient.", "Accepting processor DPAs that do not enumerate permitted sub-processors or that grant blanket sub-processor addition rights without notification, leaving the controller unable to object to new sub-processor appointments." ] }, "validation": { "design_check": [ "Confirm that every AI processor in the RoPA has a corresponding DPA reference in the processor register and that the DPA covers all processing activities listed [ref:gdpr_2016_679].", "Verify that each DPA includes audit rights — either direct audit or third-party certification — and that the organization has exercised or evaluated these rights in the last 24 months [ref:iso_27701_2019].", "Check that the processor register captures sub-processor lists for each AI provider and that sub-processor change notifications have been received and reviewed [ref:ccpa_cpra_2023]." ], "runtime_test": [ "Attempt to onboard a new AI processor through the standard procurement workflow and verify the workflow blocks data sharing until a DPA is in place and registered.", "Request a sub-processor list from three AI processors and verify the list matches the entries in the processor register.", "Simulate a processor audit rights exercise by requesting the most recent third-party audit report from a major AI provider and confirming it was received and reviewed." ], "evidence": [ "privacy:processor-register — Complete processor register with DPA reference, effective date, and sub-processor schedule for each AI provider [unverified]", "privacy:dpa-documents — Executed DPA documents for each AI processor showing Art 28-required clauses [unverified]", "privacy:processor-audit-records — Records of audit rights exercise or third-party certification review for each AI processor [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Every API call that sends personal data to an AI provider is a controller-to-processor transfer; engineer the data-sharing layer to refuse transmission if the processor is not registered with a current DPA.", "actions": [ "Build a processor allowlist that the data-sharing layer validates against before routing personal data to any external AI endpoint.", "Emit structured events whenever personal data is sent to an external processor so the processor register can track data flow volume and categories.", "Implement automated sub-processor inventory comparison — fetch processor sub-processor lists via their published APIs or feeds and flag discrepancies against the register." ], "failure_signals": [ "Personal data is sent to AI provider endpoints that are not listed in the processor register.", "DPA effective dates have lapsed but data flows to the processor continue.", "Sub-processor notifications are received by legal but not reflected in the engineering-level processor allowlist." ] }, "dpo": { "summary": "The DPA is the legal instrument through which controller accountability extends to processor behavior; without current, Art 28-compliant DPAs, the controller's liability is unlimited and without contractual recourse.", "actions": [ "Maintain a DPA renewal calendar so that agreements expiring within 90 days are flagged for renewal before expiry.", "Review each new AI provider's proposed DPA against the Art 28 mandatory clauses checklist before any personal data is shared.", "Require processors to provide evidence of their own sub-processor DPAs upon request, and review this evidence annually for major AI providers." ], "failure_signals": [ "AI providers are added to the technology stack without a DPA in place.", "DPAs in the register are over two years old without a gap assessment.", "Processor breach notifications are received but the DPA does not specify the required notification timeline." ] }, "data_governance": { "summary": "The processor register is the contractual anchor for every external AI data flow; governance must ensure no data product can route personal data to an unregistered or unapproved processor.", "actions": [ "Integrate the processor register with the data catalog so that data products referencing external AI endpoints inherit processor compliance status.", "Establish a processor classification taxonomy — distinguishing AI training processors, inference processors, and telemetry processors — so DPA scope is granular.", "Define a data-minimization review step in the processor onboarding workflow that confirms only necessary data categories are shared before DPA signing." ], "failure_signals": [ "Data pipelines are found routing personal data to AI processors not listed in the governance register.", "Processor data categories in DPAs do not match the actual data categories flowing through the integration.", "No governance owner is named for the processor relationship." ] }, "grc_auditor": { "summary": "DPA completeness is a direct audit finding under GDPR Art 28; every AI processor relationship without a current DPA is a discrete violation, and sub-processor chains without DPAs multiply the exposure.", "actions": [ "Cross-reference the processor register against the RoPA to verify every processor named in the RoPA has a current DPA.", "Sample three AI processor DPAs and verify they contain all Art 28(3) mandatory clauses — subject matter, duration, nature, purpose, data type, data subject categories, controller obligations.", "Confirm that the organization has a documented process for handling sub-processor objections under Art 28(2)." ], "metrics": [ "DPA coverage ratio: percentage of AI processors in the RoPA with a current DPA (target 100%).", "DPA review age: proportion of DPAs reviewed within the last 24 months (target 100%)." ], "failure_signals": [ "Any AI processor found without a DPA is an immediate high-severity finding.", "DPAs that do not include audit rights provisions.", "Sub-processor lists not maintained or not reconciled with processor notifications." ] }, "software_engineering": { "summary": "The processor allowlist is a runtime control — build it into the data-sharing layer as a hard dependency so personal data cannot reach an unregistered AI endpoint regardless of configuration.", "actions": [ "Implement a processor guard middleware that checks the destination endpoint against the approved processor register before transmitting any request containing personal data.", "Add processor registration status to the secrets or configuration management system so deployments that reference unregistered processors fail at startup.", "Log all outbound calls to AI processors with correlation IDs so that data flows can be audited against the processor register after the fact." ], "failure_signals": [ "Outbound requests to AI provider endpoints that are not in the processor allowlist succeed without error.", "No structured logging of which AI processor received which categories of data.", "Feature flags or environment overrides can bypass the processor guard middleware." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have DPAs for primary AI vendors but lack systematic coverage of sub-processors and do not enforce DPA status as a prerequisite to data sharing at the technical layer." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Legal/Compliance", "DPO Office", "Procurement" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 28", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-02 directly implements the Art 28 obligation to ensure processing by a processor takes place under a contract with mandatory clauses, covering all AI data processors and their sub-processors.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "8.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 8.2 requires that PII sharing with processors be governed by contractual controls; DG-02 operationalizes this with a processor register and DPA lifecycle management process.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "ccpa", "requirement_id": "§1798.140(ag)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CCPA/CPRA requires service provider contracts that prohibit selling or using personal information beyond the specified purpose; DG-02's DPA regime covers this obligation though CCPA service provider contracts have different mandatory clauses than GDPR Art 28.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "regulation", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum (DPA)", "rationale": "Anthropic offers a GDPR-aligned Data Processing Addendum to enterprise API customers, establishing the controller-processor relationship, processing purposes, security obligations, sub-processor list, and Standard Contractual Clauses for EU data transfers. The DPA is available on request and is required for any enterprise customer processing EU personal data through the Claude API.", "normative_force": "best-practice", "fit": "direct", "fit_rationale": "Anthropic's GDPR-aligned Art 28 DPA with processing purposes, sub-processors, and SCCs is itself the processor agreement DG-02 requires for that vendor.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI Data Processing Addendum — GDPR Art 28 processor terms", "rationale": "OpenAI's DPA is the GDPR Article 28 contract enabling use of the OpenAI API for processing personal data in GDPR compliance. It covers controller-processor obligations, authorized processing purposes, sub-processor disclosure, security measures, breach notification timelines, and SCCs for international data transfers. It is available to API and enterprise customers.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "OpenAI's DPA is expressly the GDPR Art 28 processor contract covering purposes, sub-processors, security, and SCCs that DG-02 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_privacy", "requirement_id": "AWS Data Processing Addendum (GDPR DPA)", "rationale": "AWS offers a GDPR-compliant Data Processing Addendum covering all AWS services used to process personal data. The AWS DPA includes GDPR Article 28 processor commitments, sub-processor lists, data security obligations, breach notification procedures, and SCCs for transfers of EU personal data to third countries. Acceptance is part of the AWS Service Terms.", "normative_force": "best-practice", "fit": "direct", "fit_rationale": "The AWS GDPR DPA provides Art 28 processor commitments, sub-processor lists, and SCCs, directly satisfying DG-02 for AWS-processed personal data.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Product Terms and Data Processing Agreement", "rationale": "Microsoft's Product Terms include a comprehensive Data Processing Agreement covering all Azure AI services with GDPR Article 28 processor commitments, sub-processor disclosure, data security measures, and SCCs. The EU Standard Contractual Clauses are incorporated by reference for international data transfers, and Microsoft commits to operating within the EU Data Boundary for qualifying services.", "normative_force": "best-practice", "fit": "direct", "fit_rationale": "Microsoft's Product Terms DPA carries full Art 28 processor commitments, sub-processor disclosure, and SCCs, directly meeting DG-02 for Azure AI.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "supporting", "rationale": "DG-02 requires a current Art 28-compliant DPA before any third-party processor handles data, governing the AI data supply chain's processor tier.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party AI data processor engaged by the organisation must operate under a…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every third-party AI data processor engaged by the organisation must operate under a…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"Every third-party AI data processor engaged by the organisation must operate under a…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Ensuring every AI data processor operates under a current Art 28-compliant DPA is the contractual mechanism through which the controller extends accountability to its supply chain. Without enforceable DPAs covering AI-specific processing activities and sub-processor chains, the controller cannot demonstrate compliance and has no contractual recourse when processor failures occur.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-02", "validation_objective": "Every third-party AI data processor engaged by the organisation must operate under a current, executed, Art 28-compliant Data Processing Agreement that specifies subject matter, nature, purpose, duration, data categories, data subject categories, controller obligations, and processor obligations. No processing by a third party may begin or continue without a current DPA in place.", "evidence_required": [ "executed_dpa_record for each third-party AI processor including processor name, effective date, scope of processing, sub-processor authorisation clause, and controller audit rights provision", "processor_registry listing all currently engaged third-party AI processors with DPA reference, expiry or review date, and sub-processor list", "dpa_completeness_review showing that each DPA was assessed against an Art 28 checklist prior to execution", "sub_processor_change_notification_log documenting all sub-processor additions or changes communicated by processors during the audit period with controller acknowledgment or objection record", "dpa_renewal_tracking_report showing DPAs due for renewal in the next 90 days and current renewal status" ], "machine_tests": [ "Query the processor registry for all active processors → assert every processor entry has a corresponding executed DPA record with effective_date and no past-due review date", "Trigger a new AI vendor onboarding workflow → assert the workflow blocks data transfer enablement until a DPA record is marked 'executed' by an authorised signatory", "Submit a sub-processor change notification from a test processor → assert the notification is logged and a controller review task is created, and the new sub-processor is not activated until the review task is closed" ], "human_review": [ "Review a sample of executed DPAs against the Art 28 compliance checklist to verify that all required clauses are present and that sub-processor authorisation terms, audit rights, and security obligation provisions are substantive rather than boilerplate", "Assess the sub-processor change notification log to confirm the organisation has reviewed and accepted or objected to all processor-initiated sub-processor changes in the audit period, with no unanswered notifications older than the contractual review window" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Using a processor's own standard DPA template without reviewing it against Art 28 requirements, accepting terms that may favour the processor and omit controller audit rights or breach notification obligations", "Treating a vendor's acceptance of privacy terms embedded in general terms of service as an Art 28-compliant DPA, when such terms typically lack the required processing specificity", "Failing to maintain a processor registry and allowing DPAs to lapse without renewal, creating gaps in lawful processing authorization", "Not tracking sub-processor changes communicated by processors, allowing unauthorised sub-processors to handle personal data without the controller's knowledge or objection opportunity", "Granting data access to a third-party processor before the DPA is fully executed on the grounds that negotiations are near-complete" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-03", "layer": "DG", "plane": "lifecycle", "name": "International Transfer Mechanism Registry", "plain": "A registry of all international personal data transfers documents the legal mechanism (adequacy, SCCs, BCRs, or derogation) and the current validity of each mechanism for every third country data flow.", "threat": { "tags": [ "invalid-transfer-mechanism", "invalidated-adequacy-decision", "outdated-sccs" ], "desc": "Following Schrems II, organizations relying on invalidated or improperly-implemented transfer mechanisms face enforcement action. AI providers often route training data and inference inputs through jurisdictions requiring a documented and current transfer mechanism." }, "standard": [ { "id": "gdpr", "section": "Art 46/Art 49", "title": "Transfers subject to appropriate safeguards / derogations" }, { "id": "uk_duaa", "section": "international transfer provisions", "title": "UK international data transfer requirements" }, { "id": "nist_pf", "section": "ID.DE-P3", "title": "Contracts with ecosystem parties implement privacy program measures" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-01" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DG-03 International Transfer Mechanism Registry control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a transfer mechanism registry that maps each international data flow to its legal basis, links to the applicable mechanism document, and tracks validity status with automated alerts on mechanism expiry or adequacy decision changes.", "steps": [ "Identify all third-country data flows created by AI systems — including inference API calls, training data exports, telemetry, and logging — and map each to the destination country.", "For each destination country, document the applicable transfer mechanism: adequacy decision (with expiry date), standard contractual clauses (with version and execution date), binding corporate rules reference, or Art 49 derogation justification.", "Subscribe to EU Commission adequacy decision change notifications and EDPB guidance updates; trigger a registry review whenever a relevant decision is amended or invalidated.", "Review the full transfer mechanism registry annually and after any significant change in AI provider infrastructure, including provider cloud region changes that may introduce new third-country flows." ], "anti_patterns": [ "Assuming that a processor DPA implicitly covers international transfer legality without separately documenting the transfer mechanism — DPAs govern the controller-processor relationship but do not independently establish transfer lawfulness.", "Relying on adequacy decisions without monitoring their validity status, especially for countries subject to ongoing CJEU challenges or whose adequacy is contingent on specific safeguards being maintained." ] }, "validation": { "design_check": [ "Verify the transfer mechanism registry covers all third-country destinations identified in the RoPA for AI processing activities, with no gaps [ref:gdpr_2016_679].", "Confirm that each transfer mechanism entry includes a mechanism type, document reference, effective date, validity status, and next review date [ref:uk_duaa_2025].", "Validate that a change-alert process exists for adequacy decision status and that alerts are routed to the DPO with a defined response SLA [ref:nist_pf_1_0]." ], "runtime_test": [ "Simulate an adequacy decision invalidation by marking a test entry as 'invalidated' and verify the alert fires, routes to the DPO queue, and triggers a transfer suspension workflow.", "Request the transfer mechanism registry export and cross-reference it against network flow analysis of AI provider API calls to identify any undocumented third-country flows.", "Verify that the SCCs version in use for each transfer is the current 2021 EC SCC template and that any older SCCs have a migration plan or have been replaced." ], "evidence": [ "privacy:transfer-mechanism-registry — Complete export of the international transfer registry with mechanism type and validity status for each third-country flow [unverified]", "privacy:scc-documents — Executed SCC documents with processor for each non-adequate third country flow [unverified]", "privacy:adequacy-decision-monitoring-log — Records of adequacy decision status checks with dates and actions taken [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Every AI API call that crosses a jurisdictional boundary is a data transfer requiring a documented legal mechanism; map the network layer to the legal layer to ensure no unregistered third-country flow exists.", "actions": [ "Enumerate all external AI endpoint destinations and resolve their IP ranges to geolocation to identify third-country flows that may not be apparent from provider documentation.", "Build a transfer gate that checks the destination country against the transfer mechanism registry before routing personal data, blocking flows to countries with no valid mechanism.", "Instrument all outbound AI calls with destination-country tags so the transfer mechanism registry can be auto-populated with actual flow data." ], "failure_signals": [ "AI provider infrastructure migrates to a new region without triggering a transfer mechanism review.", "Telemetry and logging data flows to third countries without a documented transfer mechanism.", "Transfer gate has exceptions or bypass paths that allow unregistered transfers." ] }, "dpo": { "summary": "The transfer mechanism registry is the documentary proof of Art 46 compliance; every gap represents an unlawful transfer that the controller is currently committing.", "actions": [ "Review the transfer mechanism registry quarterly and whenever a new AI system is deployed or an existing provider changes their infrastructure region.", "Maintain an adequacy decision watchlist covering all destination countries and subscribe to EDPB and EU Commission update channels.", "Ensure that each SCCs package is signed by both parties and that the DPO or authorized signatory name is on record for each execution." ], "failure_signals": [ "Transfers are occurring to a country whose adequacy decision has been invalidated or suspended.", "SCCs in use are the pre-2021 template that has been superseded.", "No TIA has been conducted for SCC-based transfers to high-risk jurisdictions." ] }, "data_governance": { "summary": "International transfer mechanisms are a governance constraint on where AI workloads can run; governance must ensure that infrastructure placement decisions are evaluated against the transfer mechanism registry before deployment.", "actions": [ "Add a transfer mechanism check to the AI system design review process so that proposed infrastructure regions are validated before architecture is finalized.", "Integrate the transfer mechanism registry with the data catalog so that data products display the transfer mechanism required for each destination.", "Establish a data residency policy that defines which data categories may be transferred internationally and under which mechanisms." ], "failure_signals": [ "AI workloads are deployed to cloud regions in third countries without a prior transfer mechanism assessment.", "Data residency policy does not address AI inference data or training data separately from operational data.", "Transfer mechanism registry is not consulted during vendor evaluation for AI services." ] }, "grc_auditor": { "summary": "International transfer compliance is a high-visibility enforcement area; auditors must verify that every third-country data flow has a currently valid mechanism and that mechanism validity is actively monitored.", "actions": [ "Cross-reference the transfer mechanism registry against the RoPA to verify all third-country flows identified in the RoPA have a registered mechanism.", "Verify that SCCs in use are the current 2021 version and that Transfer Impact Assessments have been completed where required.", "Confirm that a process exists to respond to adequacy decision changes within a defined timeframe and that the process has been tested." ], "metrics": [ "Transfer mechanism coverage: percentage of third-country data flows with a documented and currently valid transfer mechanism (target 100%).", "SCC currency rate: percentage of SCC-based transfers using the 2021 or later template (target 100%)." ], "failure_signals": [ "Any third-country data flow without a documented transfer mechanism is an immediate critical finding.", "Adequacy decisions relied upon are under active CJEU challenge without a contingency mechanism in place.", "No evidence of transfer impact assessment for SCC-based transfers to high-risk jurisdictions." ] }, "software_engineering": { "summary": "Build transfer destination awareness into the API routing layer so that the system can refuse to send personal data to a jurisdiction without a valid transfer mechanism before the request is made.", "actions": [ "Implement destination-country tagging in the API client layer, resolving each AI provider endpoint to its jurisdiction at startup.", "Integrate the transfer mechanism registry API into the deployment configuration so services fail startup if they reference a destination with no valid mechanism.", "Log transfer mechanism status as a structured field in all outbound request logs to support retrospective audit." ], "failure_signals": [ "API clients do not know the jurisdiction of their destination endpoints.", "Transfer mechanism status is not reflected in deployment configuration or runtime checks.", "No structured logging of destination jurisdiction for outbound AI API calls." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Organizations typically have SCCs for primary AI providers but lack a systematic registry covering all AI-related third-country flows and have no automated monitoring for adequacy decision changes." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "Legal/Compliance", "DPO Office", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 46", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-03 implements the Art 46 requirement to document appropriate safeguards for international transfers, covering all AI-related third-country data flows with mechanism type, document reference, and validity tracking.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "international transfer provisions", "fit": "partial", "direction": "control-supports-requirement", "rationale": "The UK DUAA establishes an independent UK international transfer regime with its own adequacy regulations and ICARTs; DG-03's registry approach applies to UK transfers with UK-specific mechanism categories.", "source_version": "2025 c.15", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "ID.DE-P3", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "DG-03 implements NIST Privacy Framework ID.DE-P3 — contracts with data processing ecosystem parties are used to implement appropriate privacy program measures — by registering the transfer mechanism (adequacy decision, SCCs, BCRs) that legally authorizes each cross-border processing relationship.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI data residency — regional storage options", "rationale": "OpenAI offers data residency options for eligible enterprise and API customers, allowing selection of data at-rest storage in the US, EU, UK, Japan, Canada, South Korea, Singapore, Australia, India, and UAE. API customers can explicitly select US or EU for data processing on supported endpoints. These options must be registered in the international transfer mechanism registry alongside their applicable legal basis.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI data-residency options are a transfer-limiting choice that must be recorded in the registry, an input to DG-03 rather than the registry itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft EU Data Boundary Commitment", "rationale": "Microsoft's EU Data Boundary is a contractual commitment to store and process all customer data and pseudonymized personal data for core cloud services, including Azure AI services, within EU/EFTA regions. Microsoft publishes transfer impact assessment documentation specifically covering Azure AI services, enabling organizations to assess transfer compliance for EU personal data processed through Microsoft AI infrastructure.", "normative_force": "best-practice", "fit": "supporting", "fit_rationale": "Microsoft's EU Data Boundary is a specific transfer safeguard whose TIA docs feed a registry entry, supporting but not constituting the transfer registry.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS GDPR compliance whitepaper — data transfer mechanisms", "rationale": "AWS provides Standard Contractual Clauses, Binding Corporate Rules, and regional data residency controls that enable customers to restrict personal data processing to specific AWS Regions. AWS's GDPR compliance whitepaper details the available transfer mechanisms and provides guidance on conducting transfer impact assessments for AWS-based AI workloads processing EU personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS supplies SCCs, BCRs, and residency controls plus TIA guidance, the mechanisms the registry catalogs, but not the transfer registry DG-03 maintains.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum — Standard Contractual Clauses", "rationale": "Anthropic's DPA includes Standard Contractual Clauses for transfers of EEA personal data to third countries. For EU enterprise customers, the DPA with SCCs serves as the registered international transfer mechanism for any Anthropic API usage that involves EU personal data, and should be captured in the organization's transfer mechanism registry.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's DPA SCCs are the transfer mechanism for one vendor that populates a registry entry, supporting but not building the DG-03 registry.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "DG-03 blocks any international transfer to a non-adequate country without an active documented legal mechanism in the registry, permitting only lawful data transfers.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Documenting and validating the legal mechanism for every international AI data transfer is the prerequisite to lawful cross-border processing under GDPR Chapter V. AI systems that route personal data through cloud providers across jurisdictions without a current, valid transfer mechanism create ongoing unlawful transfer exposure that cannot be remediated retroactively.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-03", "validation_objective": "Every international personal data transfer made by AI systems must be documented in a current transfer mechanism registry specifying the transfer destination, legal basis (adequacy decision, SCCs, BCRs, or applicable derogation), and validity status of that mechanism. No transfer to a non-adequate country may proceed without an active, documented legal mechanism in the registry.", "evidence_required": [ "transfer_mechanism_registry_entry for each international transfer route including destination country, processor or recipient identity, legal basis, mechanism document reference (e.g., SCC execution date), and validity period or review date", "adequacy_decision_validity_check showing that all transfers relying on EU adequacy decisions reference the current, valid decision and are flagged for review if the decision is under challenge or review", "sccs_execution_records for each transfer relying on Standard Contractual Clauses, including the module used, execution date, and counterparty", "bcr_approval_record for any intra-group transfers relying on Binding Corporate Rules, including the supervisory authority approval date and scope", "transfer_mechanism_review_log showing annual or triggered review of each registry entry for continued validity" ], "machine_tests": [ "Query the transfer mechanism registry for all active international transfers → assert every entry has a legal basis field with a non-null, recognised value (adequacy/SCCs/BCRs/derogation) and no entry has a past-due review date", "Trigger a new international data flow configuration in the AI pipeline management system → assert the configuration gate checks the transfer mechanism registry and blocks activation if no valid registry entry exists for the destination country", "Inject a test adequacy decision expiry event for a destination country → assert the registry flags all affected entries as 'validity-review-required' and creates review tasks within 24 hours" ], "human_review": [ "Review a sample of SCC-based transfer entries to verify the correct module was selected for the transfer relationship (controller-to-controller, controller-to-processor, processor-to-processor) and that the SCCs were executed before the transfer commenced", "Assess the registry for completeness against the AI system data flow maps to confirm that every identified international transfer route has a corresponding registry entry, with no unregistered transfer routes" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Relying on a destination country's general reputation for data protection rather than identifying a specific legal transfer mechanism, leaving transfers without a documented lawful basis", "Failing to track adequacy decision validity and continuing to transfer data under an adequacy decision that has been invalidated or is under Schrems-style legal challenge", "Using a single set of SCCs to cover all processors in a country rather than executing separate SCCs for each transfer relationship, making it impossible to demonstrate per-transfer lawfulness", "Treating the transfer mechanism registry as a one-time compliance exercise rather than a living document subject to annual review and event-triggered updates when legal mechanisms change", "Not identifying AI-specific transfer routes such as inference API calls to US-based LLM providers as international transfers subject to GDPR Chapter V requirements" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-04", "layer": "DG", "plane": "lifecycle", "name": "Transfer Impact Assessment", "plain": "Transfer Impact Assessments are conducted for every data transfer to a non-adequate third country relying on SCCs, documenting the legal landscape of the destination country and the supplementary measures in place.", "threat": { "tags": [ "scc-protections-undermined", "no-documented-tia", "dpa-enforcement-action" ], "desc": "SCCs provide adequate safeguards only if the destination country's law does not undermine the contractual protections. EDPB Guidelines 05/2021 require a TIA before relying on SCCs, and DPAs have taken enforcement action where TIAs were absent." }, "standard": [ { "id": "gdpr", "section": "Art 46", "title": "Transfers subject to appropriate safeguards — SCC conditions" }, { "id": "uk_duaa", "section": "TIA equivalent", "title": "UK transfer risk assessment requirements" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-04 Transfer Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/DG-04 Transfer Impact Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-04 Transfer Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DG-04 Transfer Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-04 Transfer Impact Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "For each SCC-based transfer to a non-adequate third country, complete a structured TIA using the EDPB six-step methodology, document the legal surveillance landscape of the destination, identify supplementary measures, and record the outcome in the transfer mechanism registry.", "steps": [ "Identify all SCC-based transfers to non-adequate countries in the transfer mechanism registry and prioritize TIA completion based on data sensitivity and transfer volume.", "Conduct the TIA using the EDPB six-step methodology: map the transfer, verify the transfer tool, assess the third country legal order, identify and adopt supplementary measures, take formal procedural steps, and re-evaluate periodically.", "Document the legal surveillance landscape of each destination country — specifically whether laws exist that require disclosure to authorities in ways that would undermine SCC protections — using EDPB country-specific guidance where available.", "Select and implement supplementary measures for high-risk destinations: encryption at rest and in transit with key control retained in the EEA, pseudonymization before transfer, or contract-level access restrictions that bind the importer.", "Record the TIA outcome — go, conditional-go, or no-go — in the transfer mechanism registry and set a review trigger for any change in the destination country's legal landscape." ], "anti_patterns": [ "Completing a TIA as a checkbox exercise that concludes 'SCCs are sufficient' without actually assessing the destination country's legal order or identifying any supplementary measures.", "Treating a TIA as a one-time document rather than a living assessment that must be re-evaluated when the legal landscape of the destination country changes." ] }, "validation": { "design_check": [ "Confirm that a TIA exists for each SCC-based transfer to a non-adequate third country listed in the transfer mechanism registry [ref:gdpr_2016_679].", "Verify that each TIA references the EDPB six-step methodology and documents the legal surveillance assessment for the specific destination country [ref:edpb_opinion_28_2024].", "Check that the TIA identifies supplementary measures where the legal landscape assessment raised concerns, and that those measures are implemented and verifiable [ref:uk_duaa_2025]." ], "runtime_test": [ "Select three SCC-based transfers and verify that completed TIAs exist in the governance archive with a documented legal landscape assessment and outcome decision.", "Verify that the TIA review trigger process works by simulating a destination country legal landscape change notification and confirming the review is initiated within the defined SLA.", "Confirm that supplementary measures identified in TIAs are actually implemented by testing — for example, verifying encryption key custody for transfers relying on encryption as a supplementary measure." ], "evidence": [ "privacy:tia-documents — Completed TIA documents for each SCC-based transfer to a non-adequate third country with EDPB six-step methodology applied [unverified]", "privacy:supplementary-measures-log — Documentation of implemented supplementary measures with technical verification for each TIA outcome [unverified]", "privacy:tia-review-log — Records of periodic TIA reviews and re-evaluations triggered by destination country legal landscape changes [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The supplementary measures required by a TIA are engineering deliverables — encryption key custody, data minimization before transfer, pseudonymization — and must be implemented and verifiable, not merely stated in a document.", "actions": [ "For transfers relying on encryption as a supplementary measure, implement client-side encryption with EEA-controlled keys and verify the importer cannot access plaintext.", "Where pseudonymization is the supplementary measure, implement it in the data pipeline before the transfer gate and verify re-identification keys are not co-transferred.", "Build TIA outcome status into the transfer gate so transfers to destinations with a 'no-go' TIA outcome are blocked at the infrastructure level." ], "failure_signals": [ "Encryption keys for 'encrypted transfer' supplementary measures are held by the importer, negating the measure.", "TIA supplementary measures are documented but no implementation evidence exists.", "Transfer gates do not enforce TIA outcome status." ] }, "dpo": { "summary": "TIAs are mandatory for SCC-based transfers and must reflect an actual legal landscape assessment, not boilerplate — DPA enforcement actions have specifically targeted superficial TIAs that did not assess the destination country's surveillance laws.", "actions": [ "Review TIAs for all major AI provider SCC-based transfers and verify that the legal landscape assessment is specific to the destination country and current.", "Establish a country watch list with review triggers — countries with active legislative changes to surveillance or data access laws must trigger immediate TIA re-review.", "Where TIA outcomes are 'conditional-go', personally verify that the supplementary measures are implemented before signing off on the transfer." ], "failure_signals": [ "TIAs contain generic legal landscape assessments not specific to the destination country.", "TIAs have not been reviewed since initial completion despite changes in the destination country's legal landscape.", "DPO sign-off is absent from TIA outcome documents." ] }, "data_governance": { "summary": "TIA outcomes constrain where AI processing can occur; governance must ensure that infrastructure placement decisions respect TIA restrictions and that 'no-go' outcomes result in actual transfer suspension.", "actions": [ "Add TIA status as a governance attribute in the data catalog for all third-country AI processing destinations.", "Require TIA completion as a gate in the AI system procurement process for any provider with infrastructure in non-adequate countries.", "Track the average time to complete TIAs so that procurement timelines account for the assessment period." ], "failure_signals": [ "AI systems are deployed to third-country infrastructure without a preceding TIA completion.", "TIA 'no-go' outcomes do not result in documented transfer suspension.", "Procurement timeline does not include TIA completion as a milestone." ] }, "grc_auditor": { "summary": "TIA completeness is an increasingly examined compliance item; auditors should assess both the existence and quality of TIAs, specifically whether the legal landscape assessment is substantive.", "actions": [ "Verify TIAs exist for all SCC-based transfers to non-adequate countries and that each TIA documents the EDPB six-step methodology.", "Assess TIA quality by reviewing the legal landscape section for the three highest-risk destination countries — verify country-specific rather than generic analysis.", "Confirm that TIA review triggers are in place and that the review process has been activated at least once since the TIA was first completed." ], "metrics": [ "TIA coverage rate: percentage of SCC-based transfers to non-adequate countries with a completed TIA (target 100%).", "TIA review currency: percentage of TIAs reviewed within the last 12 months or following a destination country change (target 100%)." ], "failure_signals": [ "SCC-based transfers to non-adequate countries without a TIA are an immediate critical finding.", "TIA legal landscape sections that are identical across different destination countries indicate template completion without genuine assessment.", "Supplementary measures identified in TIAs cannot be evidenced at the technical layer." ] }, "software_engineering": { "summary": "TIA supplementary measures are engineering constraints — implement them as technical controls with evidence artifacts, not as policy statements in a legal document.", "actions": [ "For each TIA outcome with supplementary measures, create an engineering task to implement and test the measure, linking the task to the TIA document ID.", "Build automated tests that verify supplementary measures remain in place — for example, tests that confirm encryption keys are not co-located with the data they protect in the importer's environment.", "Include TIA outcome status in the service's runtime configuration so the service can report its transfer compliance status via a health endpoint." ], "failure_signals": [ "No engineering tasks are associated with TIA supplementary measure requirements.", "Automated tests for supplementary measure implementation do not exist.", "Service configuration does not reflect TIA outcome constraints." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations have not conducted TIAs for AI provider SCC-based transfers with the rigor required by EDPB Guidelines 05/2021, particularly regarding the destination country legal landscape assessment." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai" ], "implementers": [ "Legal/Compliance", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 46", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-04 operationalizes the Art 46 requirement that SCCs are sufficient only when assessed against the destination country's legal order; the TIA is the documented methodology through which this assessment is performed.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "TIA equivalent", "fit": "partial", "direction": "control-supports-requirement", "rationale": "The UK DUAA requires transfer risk assessments analogous to TIAs for transfers using ICARTs; DG-04's TIA process covers UK transfers with UK-specific legal landscape assessment.", "source_version": "2025 c.15", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_privacy", "requirement_id": "OpenAI DPA and security documentation — customer transfer assessment inputs", "rationale": "OpenAI's DPA incorporates SCCs and its security documentation describes the technical and organizational measures customers rely on when assessing third-country transfers; DG-04 uses such vendor documentation as input to transfer impact assessments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's DPA and security documentation are vendor inputs to the customer's transfer impact assessment, not the TIA itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft data transfer documentation — customer TIA support", "rationale": "Microsoft publishes data transfer and EU Data Boundary documentation describing the safeguards applied to third-country transfers; DG-04 incorporates this vendor documentation into UK and EU transfer risk assessments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Microsoft's transfer and EU Data Boundary documentation feed the customer's TIA as vendor-side inputs but do not perform the assessment.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS data transfer resources — customer TIA support", "rationale": "AWS publishes GDPR and data transfer resources describing supplementary measures and safeguards; DG-04 uses them as vendor-side inputs when assessing transfers of personal data processed by AI workloads on AWS.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS transfer resources describe supplementary measures used as vendor-side inputs to the TIA, not the completed transfer impact assessment.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Transfer Impact Assessments are not optional documentation — they are the required methodology through which an organization can legitimately rely on SCCs for international AI data transfers. Without a substantive TIA covering the destination country's legal order and implemented supplementary measures, SCC-based transfers to non-adequate countries are unlawful under post-Schrems II requirements.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-04", "validation_objective": "A Transfer Impact Assessment must be completed and documented for every personal data transfer to a non-adequate third country relying on SCCs, assessing the destination country's legal landscape, public authority access powers, and adequacy of supplementary technical measures before the transfer commences. No SCC-based transfer to a non-adequate country may proceed without a current, approved TIA.", "evidence_required": [ "tia_report for each SCC-based transfer to a non-adequate country, including destination country legal landscape analysis, identified public authority access risks, assessment of supplementary measures applied, and overall transfer risk verdict", "supplementary_measures_specification documenting technical and organisational measures (encryption, pseudonymisation, contractual commitments) applied to reduce identified risks to an acceptable level", "tia_approval_record with approver identity, approval date, and any conditions attached to transfer authorisation", "tia_review_log showing that TIAs are reviewed when destination country legal conditions change materially or at least annually", "transfer_suspension_or_termination_record for any TIA that concluded the transfer cannot be made lawfully, documenting the suspension action taken" ], "machine_tests": [ "Trigger a new SCC-based transfer configuration to a non-adequate country in the AI pipeline management system → assert the configuration gate checks for an approved TIA record for the destination country and blocks activation if none exists", "Query TIA records for all active non-adequate country transfers → assert every TIA record has an approval_date and a next_review_date not exceeding 12 months from approval", "Inject a simulated destination-country legal change event (e.g., new surveillance law enacted) → assert all TIA records for that country are flagged 'review-triggered' and review tasks are created within 48 hours" ], "human_review": [ "Review a sample of TIA reports for analytical rigour: verify the destination country legal landscape assessment references current laws and case law, the public authority access risk is assessed against specific statutory powers rather than generic country-risk ratings, and supplementary measures are technically capable of addressing the identified risk", "Assess any TIAs that concluded transfers are not feasible to verify that corresponding transfer suspension or termination actions were taken and are documented" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Completing a single TIA for all transfers to a country rather than per-processor or per-transfer-route TIAs, preventing accurate risk assessment when different processors face different legal exposure in the same jurisdiction", "Relying on a country-level risk score from a vendor database as a substitute for an actual TIA, without analysing the specific laws and public authority access powers applicable to the transfer", "Concluding a TIA is 'acceptable' based on general encryption commitments without assessing whether the destination country's laws can compel the processor to disclose decrypted data or provide access to encryption keys", "Treating the TIA as a one-time pre-transfer exercise without a review trigger mechanism, leaving TIAs stale when the destination country's legal landscape changes materially", "Not treating AI inference API calls to non-adequate country-based providers as transfers subject to TIA requirements because the data is transmitted rather than stored" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-05", "layer": "DG", "plane": "lifecycle", "name": "DPIA Lifecycle Management", "plain": "Data Protection Impact Assessments for high-risk AI systems are completed before deployment and updated whenever the processing changes materially; DPIA findings are tracked to resolution.", "threat": { "tags": [ "deployment-without-dpia", "stale-dpia", "dpia-findings-not-actioned" ], "desc": "GDPR Art 35 mandates a DPIA before high-risk AI processing begins. AI systems that model behavior, make automated decisions, or process special category data almost universally meet the high-risk threshold. Stale DPIAs that do not reflect current processing are equivalent to no DPIA for audit purposes." }, "standard": [ { "id": "gdpr", "section": "Art 35", "title": "Data protection impact assessment" }, { "id": "eu_ai_act", "section": "Art 27", "title": "Fundamental rights impact assessment for high-risk AI systems" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DG-05 DPIA Lifecycle Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Operate a DPIA lifecycle system that gates AI system deployment on DPIA completion, tracks open findings to resolution, and triggers DPIA updates on material processing changes through integration with the change management process.", "steps": [ "Apply the EDPB high-risk screening checklist to every new AI system and document the outcome; any system that scores positive on behavioral modeling, automated decision-making, special category data, or large-scale processing must have a DPIA completed before deployment.", "Conduct the DPIA using the EDPB WP248 methodology: describe the processing, assess necessity and proportionality, identify risks to rights and freedoms, and document measures to address those risks.", "Track all DPIA findings in the GRC system with assigned owners and target resolution dates; escalate unresolved findings that block deployment to the DPO for decision.", "Define material change triggers that require DPIA update: new data categories, new purposes, new automated decision logic, expansion to new user populations, or change of model provider.", "Review all active DPIAs on a defined schedule — annually for high-risk systems and upon any material change trigger — and document the review outcome." ], "anti_patterns": [ "Completing a DPIA after deployment to satisfy a compliance checkbox rather than using it as a pre-deployment risk assessment that can influence system design.", "Treating the DPIA as a point-in-time document that is archived after initial completion and never revisited, even as the AI system evolves in scope and capability." ] }, "validation": { "design_check": [ "Verify that every AI system in production that meets the high-risk threshold has a completed DPIA with a documented high-risk screening outcome [ref:gdpr_2016_679].", "Confirm that DPIA completion is a pre-deployment gate in the change management process and that no high-risk AI system has been deployed without a prior DPIA [ref:eu_ai_act_2024].", "Check that all open DPIA findings have assigned owners and resolution target dates, and that escalation paths exist for findings that block deployment [ref:edpb_opinion_28_2024]." ], "runtime_test": [ "Trigger a simulated new AI system deployment through the change management workflow and verify the DPIA gate is enforced — the deployment cannot proceed without a DPIA ID in approved status.", "Pull the list of open DPIA findings from the GRC system and verify each has an owner, target date, and that overdue findings have been escalated.", "Select three production AI systems and verify their DPIAs are current — that no material change has occurred since the last DPIA review without triggering an update." ], "evidence": [ "privacy:dpia-documents — Completed DPIA documents for all high-risk AI systems with high-risk screening outcomes and methodology [unverified]", "privacy:dpia-findings-register — GRC register of open and resolved DPIA findings with owner, status, and resolution dates [unverified]", "privacy:dpia-review-log — Records of periodic DPIA reviews and material-change-triggered updates with DPO sign-off [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The DPIA is the design-time privacy risk assessment for AI systems; engineering must treat open DPIA findings as defects that block deployment, not as legal documents to be archived.", "actions": [ "Integrate DPIA finding status into the deployment pipeline so that any open finding with 'blocks-deployment' severity prevents promotion to production.", "Build a DPIA material-change detector that monitors the AI system's configuration, data schema, and model card for changes that match defined material-change triggers.", "Emit structured events for DPIA status changes so the DPO queue is updated automatically when a finding is resolved or a new review is triggered." ], "failure_signals": [ "AI systems are promoted to production without a DPIA ID reference in the deployment configuration.", "DPIA material-change triggers are defined in policy but not implemented in any automated monitoring.", "DPIA findings that should block deployment are recorded in the GRC system but not enforced in the CI/CD pipeline." ] }, "dpo": { "summary": "The DPIA is the DPO's primary pre-deployment privacy risk gate; the DPO must personally review and approve DPIAs for high-risk AI systems and maintain visibility over open findings.", "actions": [ "Establish a DPIA review queue that routes all completed DPIA drafts to the DPO for review and sign-off before the deployment gate clears.", "Monitor the DPIA findings register weekly and escalate any finding that has passed its resolution target date without closure.", "Require consultation with the supervisory authority under Art 36 when a DPIA identifies a high residual risk that cannot be mitigated by available measures." ], "failure_signals": [ "DPIAs are completed by the project team without DPO review or sign-off.", "Residual risks identified in DPIAs are accepted without documented DPO approval.", "Art 36 prior consultation has not been triggered for systems with unmitigated high residual risk." ] }, "data_governance": { "summary": "DPIA scope is determined by governance data classification — governance must ensure that every high-risk data category triggers a DPIA screening and that data lineage accurately reflects the processing scope assessed in each DPIA.", "actions": [ "Link the DPIA high-risk screening process to the data catalog so that assets classified as special category, large-scale, or behavioral automatically trigger a DPIA screening for any new AI system referencing them.", "Ensure the data lineage graph for each AI system reflects the processing scope documented in its DPIA so that data catalog users can see the governance status of each flow.", "Define 'material change' in governance terms — new data asset, new classification, new downstream consumer — and wire these events to the DPIA material-change trigger." ], "failure_signals": [ "Data catalog does not surface DPIA status for AI systems processing high-risk data categories.", "Material changes to data assets used by AI systems do not trigger DPIA review.", "DPIA scope underrepresents the actual data flows documented in the data catalog." ] }, "grc_auditor": { "summary": "DPIA compliance is a mandatory GDPR Art 35 obligation with no de minimis exception for AI systems meeting the high-risk threshold; auditors must verify both existence and currency.", "actions": [ "Cross-reference the list of high-risk AI systems against the DPIA register to verify 100% coverage.", "Review DPIA documents for substantive content — verify they contain a necessity and proportionality assessment and a risk-to-rights analysis, not just a processing description.", "Audit the DPIA findings register for completeness — every finding should have an owner, status, and either a resolution record or an escalation record." ], "metrics": [ "DPIA coverage rate: percentage of high-risk AI systems with a current, DPO-approved DPIA (target 100%).", "Open findings age: percentage of DPIA findings resolved within their target date (target > 90%)." ], "failure_signals": [ "Any high-risk AI system without a completed DPIA is an immediate critical finding.", "DPIAs completed more than 12 months ago without a review record where the system has changed.", "DPIA findings register shows findings overdue by more than 30 days without escalation." ] }, "software_engineering": { "summary": "DPIA findings are engineering requirements — treat them as defects in the privacy design that must be resolved before the system ships, not as compliance paperwork to be handled separately.", "actions": [ "Add a DPIA findings check to the deployment gate that pulls open 'blocks-deployment' findings from the GRC API and fails the pipeline if any are unresolved.", "Include the DPIA document ID in the model card and deployment manifest so every artifact is traceable to its privacy assessment.", "When implementing DPIA-required measures — data minimization, access controls, deletion triggers — create automated tests that verify the measure is active in production." ], "failure_signals": [ "Deployment pipeline has no reference to DPIA status.", "Model cards do not include a DPIA reference.", "DPIA-required technical measures are undocumented in the codebase and untested." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI DPIA programs are typically ad hoc — DPIAs are completed for high-visibility systems but not systematically applied across all high-risk AI deployments, and finding tracking is rarely integrated with deployment gates." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 35", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-05 directly implements the Art 35 obligation to conduct DPIAs for high-risk AI processing before deployment, including the lifecycle management requirements for updates and finding resolution.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art 27", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art 27 requires deployers of certain high-risk AI systems to conduct a fundamental rights impact assessment and allows it to build on an existing DPIA (Art 27(4)); DG-05 covers the GDPR DPIA obligation while the Ethics domain HI layer covers the distinct FRIA.", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Core element — Contextualize AI system risks in surrounding business processes", "rationale": "SAIF's sixth core element directs organizations to contextualize AI system risks within surrounding business processes through structured pre-deployment risk assessment; DG-05's DPIA lifecycle is the privacy-specific instantiation of that assessment gate.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's contextual pre-deployment risk assessment is a related discipline but not the GDPR Art 35 DPIA lifecycle with DPO approval DG-05 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS GDPR compliance resources — customer DPIA support", "rationale": "AWS provides GDPR compliance resources and service documentation that customers use as inputs when conducting DPIAs for AI workloads on AWS; the DPIA obligation itself rests with the customer as controller.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS GDPR resources are inputs a customer uses when conducting a DPIA; the DPIA obligation and lifecycle remain the controller's under DG-05.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — Impact Assessment requirement", "rationale": "The Microsoft Responsible AI Standard v2 requires a Responsible AI Impact Assessment before AI systems proceed through development gates; DG-05 aligns this vendor practice with the GDPR Art 35 DPIA lifecycle.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Microsoft's RAI Impact Assessment is an analogous pre-deployment gate but a distinct AI-impact process, not the GDPR Art 35 DPIA lifecycle.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Responsible Scaling Policy — pre-deployment capability assessments", "rationale": "Anthropic's Responsible Scaling Policy defines structured capability-threshold assessments before model deployment; it is not privacy-specific, but DG-05 applies the same gated pre-deployment assessment discipline to the GDPR DPIA lifecycle.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic's RSP capability assessments share the gated pre-deployment discipline but are not privacy-specific and do not constitute a DPIA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "DPIA lifecycle management ensures that every high-risk AI system undergoes a structured pre-deployment privacy risk assessment and that the assessment remains current as the system evolves. A DPIA completed once and never revisited provides false assurance — only a living DPIA process with material-change triggers and tracked findings constitutes genuine Art 35 compliance for AI systems.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-05", "cross_domain": { "references": [ { "uri": "apeiris://ethics/controls/HI-01", "relationship": "related", "note": "DPIA (DG-05) is distinct from the Fundamental Rights Impact Assessment required by EU AI Act Art 27 — FRIA content and methodology are owned by the Ethics domain HI-layer." } ] }, "validation_objective": "A Data Protection Impact Assessment must be completed and approved by the DPO before any high-risk AI system is deployed, and the DPIA must be updated whenever the system's processing changes materially. No high-risk AI system may be deployed or have its scope materially changed without an approved, current DPIA on record.", "evidence_required": [ "dpia_report for each high-risk AI system including processing description, necessity and proportionality assessment, risk identification and evaluation, and risk mitigation measures with residual risk verdict", "dpo_consultation_record documenting DPO review of the DPIA, DPO advice provided, and controller response to any adverse DPO opinion", "dpia_approval_record with approver identity (controller representative), approval date, and any conditions attached to deployment authorisation", "dpia_change_trigger_log documenting all material processing changes evaluated against the DPIA update threshold, with decision records for changes that did and did not trigger a DPIA update", "supervisory_authority_prior_consultation_record for any DPIA that concluded residual risk remains high, documenting the consultation outcome before deployment proceeded" ], "machine_tests": [ "Trigger a new high-risk AI system deployment to the production gate → assert the gate checks for an approved DPIA record with a dpo_consultation_record and blocks deployment if no approved DPIA exists", "Submit a material processing change request (new data category added to an existing high-risk AI system) → assert the change management workflow creates a DPIA update evaluation task before the change is approved for implementation", "Query DPIA records for all active high-risk AI systems → assert every record has a last_reviewed_date within 24 months and that any system with a material change in the prior 12 months has a DPIA with an updated_date post-dating the change" ], "human_review": [ "Review a sample of DPIA reports for substantive quality: verify the risk assessment identifies AI-specific risks (model bias, automated decision-making impact, training data privacy), the mitigation measures are specific and implementable rather than generic, and the residual risk verdict is justified", "Assess the DPIA change trigger log to confirm that all material processing changes in the audit period were evaluated against the update threshold and that the organisation did not avoid DPIA updates by characterising material changes as non-material" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Completing the DPIA after the AI system has already been deployed, treating it as a documentation exercise rather than a pre-deployment risk management requirement", "Reusing a template DPIA across multiple high-risk AI systems without adapting the risk assessment to each system's specific processing activities, data categories, and automation impact", "Treating the DPO consultation as a formality where DPO advice is noted but not acted upon, without documenting the controller's response to adverse DPO opinions", "Failing to update the DPIA when the AI system's processing scope changes materially (new use case, new data source, new automated decision output), leaving a DPIA that no longer reflects actual processing", "Not triggering supervisory authority prior consultation when a DPIA concludes that residual risk remains high after mitigation, proceeding to deploy without the required regulatory engagement" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-06", "layer": "DG", "plane": "lifecycle", "name": "Data Breach Response", "plain": "A tested breach response process ensures supervisory authority notification within 72 hours under GDPR Art 33 and data subject notification where high risk exists under Art 34, including AI-specific breach scenarios.", "threat": { "tags": [ "notification-deadline-breach", "breach-scope-miscalculation", "no-documented-response-procedure" ], "desc": "AI systems create novel breach scenarios — model memorization exposing training data, inference logs exfiltrated, synthetic data re-identified. Standard breach response procedures that do not account for AI-specific vectors will miss scope and delay notification." }, "standard": [ { "id": "gdpr", "section": "Art 33/Art 34", "title": "Notification of personal data breaches" }, { "id": "iso_27701", "section": "6.13", "title": "Information security incident management (PII)" }, { "id": "ccpa", "section": "§1798.150", "title": "Private right of action for personal information breaches" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DG-06 Data Breach Response control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a documented and tested breach response playbook with AI-specific scenarios, automated breach detection integrated with the AI system event bus, and a defined notification workflow that meets the 72-hour GDPR deadline from first awareness.", "steps": [ "Document AI-specific breach scenarios in the breach response playbook: model weight exfiltration, inference log breach, training data exposure via memorization, re-identification of synthetic outputs, and prompt injection leading to data exfiltration.", "Implement breach detection instrumentation for AI systems: anomaly detection on inference request patterns, model weight access monitoring, training data egress alerts, and output content scanning for PII leakage signals.", "Define a breach response clock procedure — under EDPB Guidelines 9/2022, the 72-hour window starts when the controller has a reasonable degree of certainty that a security incident has compromised personal data; establish escalation rules so staff reports reach the controller function promptly, because a short triage period is permitted but slow internal escalation does not pause the clock.", "Build a breach assessment template that addresses AI-specific scope questions: are training data subjects affected? Is the model memorization a proximate cause? What is the re-identification risk of outputs?", "Conduct an AI-specific breach response tabletop exercise annually, simulating at least two AI-specific breach scenarios, and document lessons learned." ], "anti_patterns": [ "Allowing slow internal escalation to delay controller awareness — the 72-hour window starts once the controller has a reasonable degree of certainty that personal data was compromised (EDPB Guidelines 9/2022), and prolonged triage or formal DPO briefing rituals do not extend it.", "Scoping AI breaches only to directly-exfiltrated records without assessing whether model weights, inference logs, or synthetic outputs constitute personal data breaches affecting data subjects." ] }, "validation": { "design_check": [ "Verify the breach response playbook contains AI-specific scenarios and that the scope assessment template addresses model memorization, inference log exposure, and synthetic data re-identification [ref:gdpr_2016_679].", "Confirm the breach detection instrumentation covers AI system event types — model access, inference logs, training data egress — and that alerts route to the SOC and DPO with a defined escalation path [ref:iso_27701_2019].", "Check that the breach notification template is pre-formatted for the supervisory authority and meets Art 33(3) content requirements, and that a data subject notification template exists for Art 34 scenarios [ref:ccpa_cpra_2023]." ], "runtime_test": [ "Execute a breach response tabletop exercise using an AI-specific scenario — model weight exfiltration — and measure the time from simulated first awareness to simulated supervisory authority notification to verify the 72-hour target is achievable.", "Test the breach detection alerts by simulating a high-volume inference log export and confirming the anomaly detection fires within the defined detection window.", "Verify the DPO notification queue receives breach escalations within the internal SLA by conducting a fire drill from a non-DPO team member detecting a simulated incident." ], "evidence": [ "privacy:breach-response-playbook — Current breach response playbook with AI-specific scenarios, scope assessment template, and notification templates [unverified]", "privacy:breach-detection-alerts — Configuration and test results for AI system breach detection instrumentation [unverified]", "privacy:tabletop-exercise-record — Records of annual AI breach response tabletop exercises with lessons learned and remediation actions [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "AI systems create novel breach surfaces — model weights, inference logs, memorized training data — that standard breach detection does not cover; engineer detection specifically for these surfaces.", "actions": [ "Instrument model weight access with anomaly detection that alerts on unusual access patterns, bulk reads, or access from unexpected principals.", "Implement inference log access controls and PII scanning on log outputs to detect when model outputs contain unintended PII disclosures.", "Build a breach severity classifier into the AI system event pipeline that assesses whether a detected anomaly meets the personal data breach threshold before escalating to the DPO." ], "failure_signals": [ "Model weight storage has no access anomaly detection.", "Inference logs containing PII are accessible without auditing.", "AI system breach scenarios are absent from the security monitoring runbook." ] }, "dpo": { "summary": "The 72-hour clock starts when the controller reaches a reasonable degree of certainty that personal data has been compromised (EDPB Guidelines 9/2022); the DPO must ensure staff escalate suspected breaches immediately so triage begins without delay — escalation lag consumes the window.", "actions": [ "Conduct annual breach response awareness training for all staff involved in AI system operations, emphasizing the 72-hour clock and the immediate-escalation requirement.", "Maintain a pre-drafted supervisory authority notification template for each jurisdiction in which data subjects are located so notifications can be filed within the window without drafting from scratch under time pressure.", "Establish a DPO on-call rotation that guarantees the DPO can be reached at any hour to authorize supervisory authority notification." ], "failure_signals": [ "Staff involved in AI operations are unaware of the immediate-escalation requirement.", "No pre-drafted notification templates exist and drafting must start from zero when a breach occurs.", "Past breach events show DPO notification delays that consumed a significant portion of the 72-hour window." ] }, "data_governance": { "summary": "Breach scope assessment for AI systems requires understanding which data assets were affected; governance must maintain data lineage granular enough to determine which training data subjects and inference data subjects are affected by a given AI system breach.", "actions": [ "Maintain data lineage at the record-type level for AI training datasets so that a breach of the training pipeline can be scoped to specific data subject categories within hours.", "Tag inference log storage with the data subject identifiers it may contain so that an inference log breach can be scoped without full log review.", "Define the relationship between AI model identity and data subjects in the data catalog so breach scope can be determined by model ID reference." ], "failure_signals": [ "Training dataset lineage is insufficient to identify affected data subjects without a full forensic review that would exceed the 72-hour window.", "Inference logs are untagged and require manual content review to scope a breach.", "No mapping exists between AI model versions and the training data cohort they were trained on." ] }, "grc_auditor": { "summary": "Breach response adequacy is assessed against both process documentation and actual performance; auditors must review the playbook content, testing cadence, and any historical breach response timelines.", "actions": [ "Review the breach response playbook for AI-specific scenarios and confirm it covers the novel breach vectors that AI systems introduce.", "Examine the tabletop exercise record for the most recent AI-specific scenario and assess whether the simulated 72-hour window was met.", "If any actual breaches have occurred, audit the historical response timeline against the 72-hour notification requirement and identify any systemic delays." ], "metrics": [ "Time to supervisory authority notification: hours from first awareness to notification filing (target < 72 h).", "Tabletop exercise cadence: number of AI-specific breach scenarios tested in the past 12 months (target >= 2)." ], "failure_signals": [ "No documented AI-specific breach scenarios in the response playbook.", "No tabletop exercise conducted in the past 12 months.", "Historical breach notification timestamps show the 72-hour window was exceeded." ] }, "software_engineering": { "summary": "Breach detection for AI systems is an engineering deliverable — build detection into the AI system's monitoring stack so that anomalous events surface automatically to the security operations center without requiring manual log review.", "actions": [ "Add model weight access monitoring to the model registry and configure alerts for bulk reads or access from service accounts outside the ML platform.", "Implement PII scanning on a sample of inference outputs as a continuous monitoring job that alerts on unexpectedly high PII content rates.", "Build a breach triage endpoint on the AI system that returns the system's current data exposure surface — data categories, retention period, access log references — to accelerate breach scoping." ], "failure_signals": [ "Model weight storage has no access logging.", "Inference output PII scanning does not exist.", "No breach triage tooling exists for AI systems and scope assessment relies entirely on manual log review." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most breach response programs do not address AI-specific breach scenarios or the novel breach surfaces created by model weights, inference logs, and synthetic outputs, leaving organizations underdetected and underreporting." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Security Operations", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 33/Art 34", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-06 implements the Art 33 and Art 34 breach notification obligations, specifically extending the response process to AI-specific breach scenarios not addressed in standard breach response programs.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "6.13", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 6.13 extends ISO/IEC 27002 information security incident management to PII, including breach identification, response, and notification records; DG-06 implements that incident-management discipline for AI-specific breach scenarios.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "ccpa", "requirement_id": "§1798.150 (private right of action)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "The CCPA contains no breach-notification duty — California's general notification obligation is Civ. Code §1798.82, outside the CCPA — but §1798.150 creates a private right of action for breaches of nonencrypted, nonredacted personal information; DG-06's tested response process limits that liability exposure and feeds the §1798.82 notification workflow.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "regulation", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Core element — Extend detection and response to bring AI into the organization's threat universe", "rationale": "SAIF's second core element extends enterprise detection and response to AI-specific threats; DG-06 applies that discipline to personal data breach scenarios unique to AI systems, such as training data exfiltration and inference attacks.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF's extend-detection-and-response element covers the AI-breach detection component of DG-06 but not the 72-hour notification playbook and tabletop testing.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Security Incident Response Guide", "rationale": "AWS's Security Incident Response Guide covers shared responsibility for security incidents, and the AWS GDPR DPA commits AWS to notify customers of confirmed AWS-side incidents affecting their data — feeding the customer's Art 33 assessment clock.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS's incident guide and DPA breach notices feed the customer's Art 33 clock as processor inputs but do not constitute the breach-response process.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Products and Services DPA — security incident notification", "rationale": "Microsoft's Data Protection Addendum commits Microsoft to notify customers of personal data breaches without undue delay and to provide the information controllers need for Art 33/34 notifications; Microsoft Purview audit logs support post-breach scope assessment.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Microsoft's DPA breach notices and Purview logs feed the controller's Art 33/34 assessment as processor inputs, not the DG-06 response playbook itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum — security incident notification", "rationale": "Anthropic's DPA includes security incident notification obligations requiring notice to enterprise API customers without undue delay after a confirmed security incident involving customer data, feeding the controller's Art 33 assessment clock.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's DPA incident notices feed the controller's Art 33 clock as a processor input, not the tested breach-response process DG-06 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Data breach response for AI systems requires extending standard breach procedures to cover the novel breach surfaces that AI creates — model weights, inference logs, memorized training data, and synthetic outputs. Organizations that apply only traditional breach response frameworks to AI systems will systematically underdetect breaches, miscalculate scope, and miss the 72-hour notification deadline.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-06", "validation_objective": "The system must have a documented and tested breach response playbook covering AI-specific breach scenarios (model weight exfiltration, inference log breach, training data memorization, synthetic data re-identification), instrumented detection for AI breach surfaces routed to SOC and DPO, and a demonstrated ability to initiate supervisory authority notification within 72 hours from first employee awareness. Annual tabletop exercise results must confirm the 72-hour target is achievable.", "evidence_required": [ "breach_response_playbook with named AI-specific scenarios (model weight exfiltration, inference log breach, training data memorization exposure, synthetic data re-identification) including scope assessment template and notification workflow steps", "breach_detection_alert_configuration showing instrumented rules for model weight access anomalies, training data egress, and inference log volume spikes with confirmed routing to SOC and DPO escalation queue", "tabletop_exercise_record documenting the AI-specific breach scenario simulated, participants, simulated awareness-to-notification elapsed time, lessons learned, and remediation actions taken", "supervisory_authority_notification_template pre-populated with GDPR Art 33(3) required content fields for the relevant jurisdiction, stored in an accessible location", "breach_scope_assessment_template containing AI-specific scope questions for model memorization, inference log exposure, training data subject identification, and re-identification risk of synthetic outputs" ], "machine_tests": [ "Trigger a synthetic high-volume inference log export anomaly event → assert SOC alert fires within the defined detection window with breach classification flag set and DPO escalation queue entry created", "Simulate bulk model weight read from an out-of-scope service account → assert anomaly detection alert generates within 15 minutes of the event", "Inject a test breach record into the escalation queue → assert DPO on-call notification fires within the internal escalation SLA and acknowledgement is logged", "Query breach detection rule configuration → assert active alert rules exist for all AI event types: model-weight-access, inference-log-export, training-data-egress" ], "human_review": [ "Review breach response playbook to confirm AI-specific scenarios are present, each includes scope assessment steps addressing model memorization and inference log exposure, and the 72-hour clock procedure identifies first-awareness triggers at all employee levels not only DPO", "Assess tabletop exercise record to verify the simulated awareness-to-notification timeline was achievable within 72 hours and that lessons learned were actioned before the next exercise", "Verify that supervisory authority notification templates are pre-drafted and accessible during an incident, not requiring authorship from scratch under time pressure" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Treating prolonged internal investigation as pausing the 72-hour GDPR Art 33 clock — awareness begins when the controller has a reasonable degree of certainty that personal data was compromised (EDPB Guidelines 9/2022), and slow escalation or formal briefing rituals systematically under-report elapsed response time", "Scoping AI breach assessments only to directly exfiltrated records while excluding model weights, inference logs, and synthetic outputs from the breach scope calculation", "Maintaining a breach response playbook that covers only traditional IT breach vectors without AI-specific scenarios such as model memorization exposure and inference attack exfiltration", "Conducting breach response tabletop exercises using generic IT scenarios while excluding AI-specific vectors, leaving the AI breach response procedure untested", "Storing supervisory authority notification templates in a location that becomes inaccessible during a security incident, requiring drafting from scratch under the 72-hour constraint" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-07", "layer": "DG", "plane": "lifecycle", "name": "Data Retention and Deletion Schedule", "plain": "Retention periods for training data, inference inputs, model outputs, audit logs, and telemetry are defined and enforced, with automated deletion or anonymization at period expiry.", "threat": { "tags": [ "indefinite-retention", "no-deletion-process", "data-retained-beyond-consent-period" ], "desc": "Indefinite retention of personal data violates GDPR Art 5(1)(e) storage limitation. AI systems accumulate training data, prompt logs, and telemetry without defined deletion schedules, creating systematic storage limitation violations." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(e)/Art 17", "title": "Storage limitation principle and right to erasure" }, { "id": "iso_27701", "section": "7.4.7", "title": "Returning, transferring and disposal of PII" }, { "id": "ccpa", "section": "§1798.100(a)(3)", "title": "Retention period disclosure at collection" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DG-07 Data Retention and Deletion Schedule control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a retention schedule for each AI data category, implement automated deletion or anonymization jobs keyed to that schedule, and verify deletion completion through cryptographic erasure confirmation or anonymization validation.", "steps": [ "Enumerate all AI data categories and their storage locations: training datasets, fine-tuning corpora, inference request logs, model output logs, evaluation datasets, RLHF feedback data, and telemetry — and assign a retention period and data owner for each.", "For each data category, specify the deletion or anonymization method: secure deletion, cryptographic key destruction, k-anonymization, or differential privacy noise injection — and document why the chosen method is sufficient for the sensitivity of the data.", "Implement automated retention enforcement jobs that run on a defined schedule and delete or anonymize records past their retention period, with completion logging that can be audited.", "Define deletion cascade behavior for AI systems: when training data is deleted, what happens to models trained on it? Document the relationship between training data deletion and model retraction obligations.", "Conduct quarterly retention compliance audits — sample records from each data category and verify no records exist past the defined retention period." ], "anti_patterns": [ "Defining retention policies in a policy document without implementing automated deletion, resulting in policies that exist on paper but are systematically violated in practice as data accumulates.", "Setting identical retention periods for all AI data categories without distinguishing the different legal bases, purposes, and data subject rights that apply to training data versus inference logs versus audit logs." ] }, "validation": { "design_check": [ "Verify that a defined retention period exists for every AI data category in the data catalog and that each period is supported by a documented legal basis or legitimate purpose [ref:gdpr_2016_679].", "Confirm that automated deletion or anonymization jobs exist for each data category and that job completion is logged in a verifiable audit trail [ref:iso_27701_2019].", "Check that the deletion process responds to individual data subject deletion requests under Art 17/§1798.105 within the required timeframe, including requests that affect training data [ref:ccpa_cpra_2023]." ], "runtime_test": [ "Submit a test deletion request for a synthetic data subject identity and verify the deletion propagates to all AI data stores — training data, inference logs, model outputs, and feedback data — within the required response timeframe.", "Run a retention compliance spot-check by querying each AI data store for records older than the defined retention period and verifying the count is zero.", "Test the automated deletion job by artificially aging a test record past its retention period and confirming it is deleted or anonymized in the next scheduled job run." ], "evidence": [ "privacy:retention-schedule — Documented retention schedule for each AI data category with legal basis and deletion method [unverified]", "privacy:deletion-job-logs — Automated deletion job execution logs showing records processed, deleted, and completion status [unverified]", "privacy:deletion-request-log — Log of individual deletion requests with data subject identity, request date, and completion confirmation for each AI data store [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Retention enforcement is an infrastructure problem — every AI data store needs a deletion trigger, whether time-based, event-based, or request-driven, and the trigger must be tested to confirm it actually removes data rather than merely marking it deleted.", "actions": [ "Implement TTL configurations on every AI data store where the technology supports it, and implement scheduled deletion jobs for stores that do not support native TTL.", "Build a deletion cascade graph that maps training data to derived artifacts — fine-tuned models, evaluation results, feedback loops — so a training data deletion request can cascade to all derivatives.", "Implement deletion verification by sampling deleted records and confirming they are not recoverable from backups or replicas within the retention enforcement window." ], "failure_signals": [ "AI data stores have no TTL configuration and no scheduled deletion jobs.", "Deletion requests complete on the primary store but data remains in replicas or backups past the retention period.", "No deletion cascade logic exists — training data deletion does not affect derived model artifacts." ] }, "dpo": { "summary": "Storage limitation is a GDPR Art 5(1)(e) principle violation that accumulates invisibly — every day of retention past the defined period is a continuing violation; the DPO must ensure automated enforcement is operational, not merely policy-defined.", "actions": [ "Review the retention schedule for each AI data category annually and confirm the defined periods are still supported by the current legal basis and purpose.", "Obtain quarterly deletion job execution reports and review them for failures, gaps, or categories where deletion is delayed.", "Respond to individual deletion requests within the GDPR Art 17 and CCPA §1798.105 timeframes and confirm completion has been verified across all AI data stores." ], "failure_signals": [ "Retention schedule has not been reviewed in the past 12 months.", "Deletion job failure rates are above zero and failures are not remediated within 24 hours.", "Individual deletion requests are completed on the primary system but not verified against replicas and backups." ] }, "data_governance": { "summary": "The retention schedule is a governance catalog attribute — every AI data asset in the catalog must have a defined retention period, owner, and deletion method so governance can enforce storage limitation as a data management standard.", "actions": [ "Make retention period a mandatory attribute for every AI data asset registered in the data catalog, blocking asset registration until a retention period is set.", "Integrate the data catalog with the deletion job scheduler so that when a retention period changes in the catalog, the deletion schedule updates automatically.", "Define data steward accountability for retention compliance — each AI data category owner is responsible for the accuracy of the retention period and the operational status of the deletion job." ], "failure_signals": [ "AI data assets in the catalog have no retention period attribute.", "Retention period changes in the catalog are not reflected in the deletion job configuration.", "No named data steward is accountable for retention compliance for each AI data category." ] }, "grc_auditor": { "summary": "Storage limitation is a first-principle GDPR obligation; auditors must verify that retention periods are defined, deletion is automated, and deletion is verified — not merely that policies exist.", "actions": [ "Pull records from each AI data store and verify no records exceed the defined retention period for that category.", "Review deletion job execution logs for the past quarter and confirm jobs ran on schedule, completed without errors, and deletions were verified.", "Audit individual deletion request completions for a sample of requests and confirm they were completed within the required timeframe across all AI data stores." ], "metrics": [ "Retention compliance rate: percentage of AI data store records within the defined retention period (target 100%).", "Deletion request fulfillment time: average days from deletion request receipt to verified completion across all AI data stores (target <= legal requirement per jurisdiction)." ], "failure_signals": [ "Any records found past their defined retention period in any AI data store.", "Deletion job execution logs showing failures without remediation.", "Deletion requests completed on the primary store but not verified on replicas or backups." ] }, "software_engineering": { "summary": "Implement retention enforcement as infrastructure code, not manual process — every AI data store should have a declarative retention policy that the infrastructure enforces automatically without human intervention.", "actions": [ "Define retention periods as infrastructure-as-code configuration for every AI data store and enforce them through lifecycle rules, TTL settings, or scheduled deletion lambdas.", "Implement a deletion verification test that runs after each scheduled deletion job and asserts that no records past the retention period exist, failing CI if any are found.", "Build a deletion request API that accepts a data subject identifier and orchestrates deletion across all AI data stores, returning a completion receipt with per-store confirmation." ], "failure_signals": [ "Retention periods are defined in a policy document but not in infrastructure code.", "No automated test exists to verify retention compliance after deletion job execution.", "Individual deletion requests require manual intervention to propagate to all AI data stores." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI data retention is one of the most commonly violated storage limitation obligations — most organizations have not defined retention periods for AI-specific data categories such as inference logs and RLHF feedback data." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Data Governance", "Privacy Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(e)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-07 directly implements the GDPR Art 5(1)(e) storage limitation principle and Art 17 right to erasure, specifically for AI data categories that typically accumulate without defined retention enforcement.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.4.7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 7.4.7 addresses disposal of PII; DG-07 operationalizes this with a per-category retention schedule, automated deletion jobs, and deletion verification for AI-specific data stores.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "ccpa", "requirement_id": "§1798.100(a)(3)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CCPA §1798.100(a)(3) requires businesses to disclose at collection how long each category of personal information will be retained, or the criteria used to determine that period; DG-07's retention schedule is the operational source for that disclosure and for honoring §1798.105 deletion rights.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "regulation", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic API data retention controls", "rationale": "Anthropic reduced API log retention to 7 days by default as of September 2025, with automatic deletion after that period and no use for model training. The ZDR (Zero Data Retention) addendum provides immediate deletion after real-time abuse detection. Enterprise customers needing longer retention for audit can opt into a 30-day window via DPA. This explicit retention schedule must be incorporated into data retention inventories for AI processing activities.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Anthropic's 7-day/ZDR auto-deletion supplies a defined retention schedule with automated deletion for its API-log data category, one slice of DG-07's scope.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI API data retention policy — 30-day default", "rationale": "OpenAI retains API inputs and outputs for up to 30 days for abuse monitoring, after which data is deleted. API data is not used for model training by default. Customers can request deletion of stored data via the DSAR process. These retention parameters must be reflected in data retention schedules for AI processing activities using OpenAI APIs, including applicable downstream deletion cascade requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI's 30-day auto-deletion gives a defined retention period and automated deletion for its API data, covering that category but not all DG-07 data types.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_privacy", "requirement_id": "AWS data lifecycle management — S3 Lifecycle and RDS retention", "rationale": "AWS provides S3 Lifecycle policies, AWS Backup retention policies, and configurable RDS automated snapshot retention to implement automated data retention scheduling with policy-driven deletion. For AI workloads, these controls enable organizations to define retention schedules aligned with GDPR storage limitation requirements and automate deletion at retention expiry.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "S3 Lifecycle and RDS retention provide the automated policy-driven deletion mechanism DG-07 needs but not the defined periods or legal bases per category.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Data Lifecycle Management", "rationale": "Microsoft Purview Data Lifecycle Management provides retention labels, auto-apply policies, and disposition review for enterprise data including AI-generated content, inference logs, and model training datasets. Retention policies can be scoped to specific data classifications, enabling purpose-based retention schedules aligned with GDPR Art 5(1)(e) storage limitation requirements.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Purview Data Lifecycle Management supplies retention labels and auto-deletion scoped to classifications, the enforcement mechanism but not the periods.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "shortretain", "fit": "direct", "rationale": "DG-07 assigns every AI data category a legally-justified retention period with automated deletion and zero records past retention, directly enforcing shortest-necessary retention.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Defining and enforcing retention schedules for AI-specific data categories is the primary mechanism for compliance with the storage limitation principle in AI systems. Without automated deletion and verified erasure, retention policies exist only on paper while AI data stores accumulate personal data indefinitely, creating compounding storage limitation violations and growing data subject rights exposure.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-07", "validation_objective": "Every AI data category — training datasets, fine-tuning corpora, inference request logs, model output logs, evaluation datasets, RLHF feedback data, and telemetry — must have a documented retention period supported by a legal basis, automated deletion or anonymization enforcement, and verified deletion completion, with zero records discoverable past the defined retention period in any registered AI data store.", "evidence_required": [ "retention_schedule document listing every AI data category with assigned retention period, supporting legal basis, data owner, deletion method (secure deletion, cryptographic key destruction, k-anonymization, or differential privacy noise), and last review date", "deletion_job_execution_log showing job run timestamps, AI data category covered, records processed, records deleted or anonymized, completion status, and any failure events with remediation timestamps", "retention_compliance_spot_check_report querying each registered AI data store for records older than the defined retention period and confirming zero records found, with query timestamp and store identifier", "individual_deletion_request_log with data subject identifier, request date, per-store completion confirmation timestamp, and verified deletion status for each registered AI data store" ], "machine_tests": [ "Artificially age a synthetic test record past its defined retention period in a registered AI data store → assert the next scheduled deletion job removes the record and logs a completion confirmation entry", "Submit a synthetic data subject deletion request → assert deletion cascades to all registered AI data stores (training data, inference logs, model outputs, RLHF feedback) within the required response timeframe", "Query each registered AI data store for records with creation timestamp older than the category retention period → assert result count is zero across all stores", "Trigger a scheduled deletion job → assert completion log is created with record count, store identifier, and timestamp within 5 minutes of job execution" ], "human_review": [ "Review retention schedule to confirm every AI-specific data category (inference logs, RLHF feedback, evaluation datasets, telemetry) is explicitly listed with a retention period — not only operational database tables", "Assess deletion cascade graph to verify training data deletion is documented to propagate to derived artifacts (fine-tuned models, evaluation results, feedback datasets) with lineage mapping", "Verify deletion job failure remediation procedure confirms failures are investigated and remediated within 24 hours, with re-run documented before the next compliance cycle" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Defining retention periods in a policy document without implementing automated deletion jobs, producing storage limitation violations that accumulate invisibly while the policy appears compliant on paper", "Applying a single uniform retention period to all AI data categories without distinguishing the different legal bases and purposes for training data versus inference logs versus audit logs", "Confirming deletion on the primary database while leaving identical records in replicas, backups, or derived AI artifacts (embeddings, fine-tuned model weights) past the retention period", "Excluding AI-specific data categories — inference logs, RLHF feedback data, evaluation datasets — from the retention schedule on the grounds that they are system data rather than personal data", "Marking records as soft-deleted in the primary store without verifying the underlying data is not recoverable from backups or read replicas, generating false deletion confirmations" ], "update_status": "current", "layer_code": "DG" }, { "id": "DG-08", "layer": "DG", "plane": "lifecycle", "name": "Governance Evidence Archive", "plain": "All governance artifacts — DPIAs, consent records, LIAs, RoPAs, breach notifications, and TIAs — are stored in a tamper-evident archive with defined retention schedules and access controls.", "threat": { "tags": [ "evidence-lost-or-tampered", "inability-to-demonstrate-compliance", "regulatory-audit-failure" ], "desc": "Accountability under GDPR Art 5(2) requires affirmative proof that processing complies with GDPR principles. Organizations that cannot produce governance artifacts on demand during DPA examination fail the accountability obligation regardless of actual compliance." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)/Art 30", "title": "Accountability principle and records of processing" }, { "id": "iso_27701", "section": "7.2.1", "title": "Privacy information management records" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records determined, documented, implemented, and reviewed" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DG-08 Governance Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DG-08 Governance Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DG-08 Governance Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DG-08 Governance Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DG-08 Governance Evidence Archive control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Operate a centralized governance evidence archive with write-once storage, cryptographic integrity verification, defined retention schedules per artifact type, and role-based access controls that permit DPO and auditor read access without modification rights.", "steps": [ "Define the artifact taxonomy for the governance archive: DPIAs, RoPA revisions, DPA documents, TIA documents, LIA records, consent records, breach notification filings, supervisory authority correspondence, and audit reports.", "Implement write-once storage for the archive — object storage with object lock, or a GRC platform with immutable record capability — so that archived artifacts cannot be modified or deleted outside the defined retention period.", "Implement cryptographic integrity verification for each archived artifact: compute a SHA-256 hash at archive time, store the hash independently, and provide a verification endpoint that confirms hash integrity on demand.", "Define artifact-specific retention schedules: DPIAs for the life of the system plus three years, DPAs for the term plus five years, breach notification records for five years, consent records for the period of processing plus proof of consent duration.", "Implement role-based access controls that grant DPO and legal read-access to all artifact classes, grant auditors time-bounded read access during examination periods, and require dual authorization for any delete operation within the retention period." ], "anti_patterns": [ "Storing governance artifacts in a shared network drive or document management system without write-protection, allowing modification or deletion of records that should be immutable for accountability purposes.", "Applying a single retention period to all governance artifacts rather than tailoring retention to the legal and accountability purpose of each artifact class — leading to premature deletion of records still needed for ongoing accountability." ] }, "validation": { "design_check": [ "Verify the archive storage system has write-once or object-lock capability and that no administrative shortcut exists to modify or delete records within the retention period [ref:gdpr_2016_679].", "Confirm that cryptographic integrity verification is implemented for all artifact classes and that the verification endpoint returns a valid hash comparison result for a sample of archived artifacts [ref:iso_27701_2019].", "Check that role-based access controls are in place and that the DPO, legal, and auditor roles have defined access levels that cannot be self-granted [ref:nist_pf_1_0]." ], "runtime_test": [ "Attempt to modify an archived artifact using the highest-privilege account available and confirm the modification is rejected by the write-once storage layer.", "Request a hash verification report for five archived artifacts and confirm all hashes match the independently stored hash values.", "Simulate a supervisory authority examination by presenting the governance archive to an auditor and measuring the time-to-produce a complete DPIA, DPA, and breach notification for a specified AI system." ], "evidence": [ "privacy:archive-inventory — Complete inventory of governance artifacts in the archive with artifact type, hash value, and archive date [unverified]", "privacy:integrity-verification-report — Hash verification results for a sample of archived artifacts confirming tamper-evident status [unverified]", "privacy:access-control-report — Access control configuration and access log for the governance archive showing role-based access enforcement [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The governance archive is an infrastructure component, not a document management system — engineer it with write-once semantics, cryptographic integrity, and structured query capability so artifacts can be produced programmatically during regulatory examination.", "actions": [ "Implement the archive on object storage with object lock enabled and a retention mode that prevents deletion by any principal including storage administrators within the retention period.", "Compute SHA-256 hashes at archive time and store them in an independent database so integrity verification does not depend on the same storage system as the artifact.", "Expose a governance archive API that accepts artifact type and system ID parameters and returns the full artifact set for that system — enabling rapid production of all artifacts for a given AI system on demand." ], "failure_signals": [ "Archive storage does not have write-once or object-lock capability.", "Hash storage and artifact storage are co-located, meaning an attacker who can modify an artifact can also modify its hash.", "Artifact retrieval requires manual navigation — no programmatic query capability exists." ] }, "dpo": { "summary": "The governance archive is the primary instrument of accountability under Art 5(2) — the DPO must be able to produce any governance artifact for any AI system within two hours of a DPA examination request.", "actions": [ "Conduct a quarterly archive completeness review — pull the AI system inventory and verify that every active system has a complete artifact set in the archive.", "Test artifact production time annually by simulating a supervisory authority examination request and measuring end-to-end production time.", "Ensure supervisory authority correspondence is archived immediately upon receipt or sending, not retrospectively batched." ], "failure_signals": [ "Any AI system in production without a corresponding artifact set in the archive.", "Artifact production time in a simulated examination exceeds two hours.", "Supervisory authority correspondence is not archived or is archived with delays." ] }, "data_governance": { "summary": "The governance archive is the definitive record of privacy governance decisions — governance must ensure that every decision point in the AI lifecycle generates an artifact and that the artifact is archived at the point of decision, not retrospectively.", "actions": [ "Define archive triggers in the AI system governance workflow: each workflow step that produces a governance artifact must push the artifact to the archive immediately upon approval.", "Include archive status as a governance health indicator in the AI system catalog — each system should display its archive completeness score.", "Establish governance archive ownership for each AI system — a named steward accountable for ensuring the archive is complete and current." ], "failure_signals": [ "Governance artifacts are stored in the GRC system but not pushed to the tamper-evident archive.", "Archive completeness scores are not tracked or visible in the AI system catalog.", "No named owner is accountable for archive completeness for each AI system." ] }, "grc_auditor": { "summary": "The governance archive is the evidence foundation for the entire privacy program; its integrity, completeness, and accessibility determine whether the organization can demonstrate accountability under Art 5(2) in a real DPA examination.", "actions": [ "Audit archive completeness by cross-referencing the AI system inventory against the archive — every active system should have a complete artifact set.", "Test tamper-evidence by verifying hash integrity for a sample of artifacts and confirming the hash is stored independently of the artifact.", "Assess archive access controls by reviewing the access log for any modification or deletion events and verifying they were properly authorized." ], "metrics": [ "Archive completeness rate: percentage of active AI systems with a complete governance artifact set in the archive (target 100%).", "Integrity verification rate: percentage of sampled artifacts with confirmed hash integrity (target 100%)." ], "failure_signals": [ "Any active AI system without a complete artifact set in the archive.", "Any artifact with a hash mismatch indicating potential tampering.", "Any modification or deletion event in the archive access log without proper dual authorization." ] }, "software_engineering": { "summary": "Build archive writes into every governance workflow as an automated step, not a manual one — every approval event in the GRC system should emit an artifact to the tamper-evident archive without human intervention.", "actions": [ "Implement a GRC-to-archive webhook that fires on every approval event and pushes the approved artifact to the write-once archive with a cryptographic hash.", "Build a CI/CD check that verifies the archive contains artifacts for any AI system about to be deployed to production, failing the deployment if the archive is incomplete.", "Expose an archive completeness API that returns the artifact set status for any AI system by ID, so dashboards and auditors can query completeness programmatically." ], "failure_signals": [ "Governance artifact archiving is a manual step performed by a team member rather than an automated workflow output.", "Deployment pipeline does not check archive completeness before promoting AI systems to production.", "No archive completeness API exists — completeness must be verified by manual archive inspection." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations store governance artifacts in GRC platforms or document management systems without write-once semantics or cryptographic integrity verification, creating accountability risk when artifacts are needed for regulatory examination." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "GRC", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(2)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DG-08 directly implements the GDPR Art 5(2) accountability principle by providing a tamper-evident archive through which the controller can affirmatively demonstrate compliance with GDPR principles on demand.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.2.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 7.2.1 requires maintaining privacy information management records; DG-08 operationalizes this with a structured archive covering all governance artifact classes with defined retention and integrity verification.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "NIST Privacy Framework CT.DM-P8 requires audit/log records to be determined, documented, implemented, and reviewed in accordance with policy; DG-08 provides the tamper-evident archive that satisfies that requirement for governance artifacts.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS CloudTrail — immutable governance logging", "rationale": "AWS CloudTrail provides API-level audit logs for all AWS AI services, recording every data access, model invocation, and governance action. Combined with S3 Object Lock in WORM (Write Once Read Many) mode, CloudTrail creates an immutable evidence archive that supports GDPR accountability requirements and can be used as primary evidence in supervisory authority investigations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail with S3 Object Lock WORM gives the tamper-evident write-once substrate but not the governance-artifact set, hashing, and retrieval SLA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Compliance Manager — evidence archive", "rationale": "Microsoft Purview Compliance Manager provides structured evidence collection, archiving, and compliance reporting for privacy control assessments. The Unified Audit Log captures all data access and governance activities across Microsoft 365 and Azure AI services, with configurable retention and export capabilities supporting governance evidence archive requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Compliance Manager and the Unified Audit Log archive evidence but not the WORM SHA-256 integrity and two-hour retrieval guarantee DG-08 specifies.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "The governance evidence archive is the accountability infrastructure that makes the GDPR Art 5(2) obligation operational — without tamper-evident, queryable storage of all governance artifacts, an organization cannot demonstrate compliance regardless of how diligently it conducts DPIAs, TIAs, and breach assessments. Proof of compliance is as important as compliance itself.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DG-08", "validation_objective": "All governance artifacts for every active AI system — DPIAs, consent records, LIAs, RoPAs, breach notifications, and TIAs — must be stored in write-once tamper-evident storage with independently verified SHA-256 hash integrity, role-based access controls restricting modification rights, and artifact-specific retention schedules, demonstrable by producing a complete artifact set for any named AI system within two hours on demand.", "evidence_required": [ "archive_inventory listing every governance artifact by artifact type, AI system ID, SHA-256 hash value, archive timestamp, and retention expiry date", "integrity_verification_report confirming SHA-256 hash match for a sample of archived artifacts against hash values stored in a location independent of the artifact storage system", "write_once_storage_configuration showing object-lock or WORM mode enabled with retention period set to prevent deletion by any principal including storage administrators within the defined window", "archive_access_control_log showing role-based access enforcement with no unauthorized modification or deletion events and dual-authorization records for any permitted delete operations", "archive_completeness_report cross-referencing the active AI system inventory against the archive confirming every system has a complete artifact set for each applicable artifact class" ], "machine_tests": [ "Attempt to modify an archived artifact using the highest-privilege storage account available → assert modification is rejected by write-once storage layer with an immutability error code", "Request SHA-256 hash verification for 5 archived artifacts by computing hashes against independently stored values → assert 100% hash match rate with no discrepancies", "Initiate deployment of a test AI system with an incomplete archive artifact set → assert the deployment pipeline gate fails with an archive-completeness error before promoting to production", "Query the archive completeness API for a named AI system ID → assert response returns complete artifact set status with last-verified timestamp for each artifact class" ], "human_review": [ "Review archive completeness by cross-referencing the AI system inventory against the archive — verify every active system has applicable DPIAs, RoPA entries, DPA documents, TIAs, LIA records, and consent records", "Assess write-once storage configuration to confirm no administrative shortcut exists to modify or delete records within the retention period without dual authorization and audit logging", "Simulate a supervisory authority examination by requesting a complete artifact set for a specified AI system and measuring end-to-end production time against the two-hour target" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Storing governance artifacts in a shared drive or GRC platform without write-once protection, allowing modification or deletion of records that must be immutable for GDPR Art 5(2) accountability", "Co-locating artifact hash values in the same storage system as the artifacts, enabling modification of both the artifact and its hash without detection", "Applying a single retention period to all governance artifact classes rather than artifact-specific schedules, causing premature deletion of records still required for ongoing accountability obligations", "Archiving governance artifacts retrospectively in periodic batch operations rather than at the point of each governance decision, creating accountability gaps in the archive for the period between decision and archival", "Granting broad administrator access to the archive without requiring dual authorization for any deletion or modification operations within the retention period" ], "update_status": "current", "layer_code": "DG" }, { "id": "DS-01", "layer": "DS", "plane": "lifecycle", "name": "Rights Request Reception", "plain": "A governed intake channel receives and logs all data subject access requests, enforces statutory response deadlines (one month under GDPR Art 12(3), extendable by two months / 45 days CCPA), and creates an auditable receipt for every request.", "threat": { "tags": [ "requests-missed", "deadline-breach", "no-auditable-intake-record" ], "desc": "DSAR deadline breaches are among the most frequently enforced GDPR provisions. Without a governed intake channel, requests received via informal channels (email, social media) are missed or delayed, generating enforcement exposure." }, "standard": [ { "id": "gdpr", "section": "Art 12", "title": "Transparent information and communication" }, { "id": "ccpa", "section": "§1798.135", "title": "Consumer rights intake requirements" }, { "id": "dpdp", "section": "data principal rights ch. III", "title": "Rights of data principals" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-02" }, { "id": "india_dpdpa_2023", "title": "Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India)", "authority": "Parliament of India / Ministry of Electronics and Information Technology", "source_type": "binding-law", "normative_force": "binding-law", "version": "Act 2023; Rules 2025", "published_on": "2023-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.meity.gov.in/data-protection-framework", "license": "public-domain", "status": "current", "flagship": false, "source_id": "dpdp", "relationship": "normative_requirement", "rationale": "Establishes Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India) requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DS-01 Rights Request Reception control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy a dedicated DSAR portal with automated SLA tracking; all informal-channel requests (email, chat, phone) are routed through the same intake queue within 24 hours. Every request generates a unique receipt with timestamp, request type, and deadline date.", "steps": [ "Stand up a DSAR intake portal with authenticated submission, request-type classification, and auto-generated receipt emails.", "Configure SLA countdown timers for each jurisdiction (30-day GDPR, 45-day CCPA, 30-day DPDPA) with escalation alerts at 50% and 80% elapsed.", "Establish a triage procedure for informal-channel requests so front-line teams route them to the portal queue the same business day they are received.", "Integrate the portal queue with the rights-request evidence log (DS-08) so every intake event is recorded immutably from the moment of receipt." ], "anti_patterns": [ "Accepting DSAR submissions exclusively via free-text email with no structured logging or deadline tracking.", "Treating informal social-media or chat requests as non-binding without routing them through a formal intake queue." ] }, "validation": { "design_check": [ "Confirm intake portal captures request type, identity, timestamp, and jurisdiction at submission [ref:gdpr_2016_679]", "Verify SLA timers are configured per-jurisdiction and trigger escalation alerts before deadline [ref:ccpa_cpra_2023]", "Confirm all informal-channel intake procedures are documented and tested [ref:india_dpdpa_2023]" ], "runtime_test": [ "Submit a test DSAR via portal and confirm auto-receipt is generated within 5 minutes with correct deadline date.", "Submit a test request via email and verify it appears in the intake queue within one business day.", "Simulate a deadline breach for a test record and confirm escalation notification fires to the responsible team." ], "evidence": [ "privacy:intake-log — DSAR portal intake log with timestamps and receipt IDs [unverified]", "privacy:sla-report — SLA compliance report showing on-time response rates by jurisdiction [unverified]", "privacy:audit-trail — Immutable audit trail of all intake events linked to DS-08 evidence log [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and operate the intake portal and queue infrastructure; ensure every channel funnels to a single system of record.", "actions": [ "Build intake portal with structured request-type fields and jurisdiction detection.", "Implement SLA countdown logic with configurable deadlines per jurisdiction.", "Wire all informal-channel intake procedures into the same queue via API or manual triage runbook." ], "failure_signals": [ "DSAR requests found in unmonitored email inboxes with no portal ticket created.", "SLA timers not firing for requests submitted outside the portal.", "Receipt emails not generated for authenticated portal submissions." ] }, "dpo": { "summary": "Own the intake governance policy, escalation thresholds, and DPA reporting posture for missed deadlines.", "actions": [ "Publish and maintain a DSAR intake policy covering all channels and escalation paths.", "Review SLA breach reports monthly and investigate root causes for any missed deadline.", "Ensure intake procedures are communicated to all customer-facing teams." ], "failure_signals": [ "DPA complaint received citing no acknowledgement of a submitted DSAR.", "Monthly SLA breach rate exceeds 5% for any jurisdiction.", "Customer-facing teams unaware of DSAR triage responsibility." ] }, "data_governance": { "summary": "Ensure request intake is linked to the authoritative data map so fulfillment can locate relevant records efficiently.", "actions": [ "Map request-type classifications in the intake portal to data categories in the enterprise data inventory.", "Maintain a lookup from data subject identifier types to owning systems to accelerate fulfillment.", "Govern the intake portal configuration changes through the data governance change-control process." ], "failure_signals": [ "Intake requests cannot be routed to owning systems because no data map exists.", "Request classification options in the portal are out of sync with the data inventory taxonomy.", "Portal configuration changes made without governance review introducing SLA misconfiguration." ] }, "grc_auditor": { "summary": "Confirm intake controls are in place and test completeness of the audit trail against regulatory requirements.", "actions": [ "Review portal configuration against GDPR Art 12, CCPA §1798.135, and DPDPA ch. III intake requirements.", "Sample DSAR records quarterly to verify receipts were generated and deadlines met.", "Test informal-channel triage by submitting test requests via email and verifying queue entry." ], "metrics": [ "DSAR on-time response rate by jurisdiction (target: ≥95%)", "Percentage of informal-channel requests routed to portal within one business day (target: 100%)" ], "failure_signals": [ "Audit sample reveals DSARs with no receipt or intake timestamp.", "SLA compliance rate below 95% with no documented root-cause remediation.", "Informal-channel test requests not appearing in portal queue within SLA." ] }, "software_engineering": { "summary": "Implement the portal, queue, receipt generation, SLA timer, and escalation notification systems.", "actions": [ "Build or configure intake portal with required fields: full name, contact, request type, jurisdiction, date.", "Implement SLA timer service that calculates deadline from intake timestamp and triggers alerts.", "Integrate receipt email service with idempotent delivery and logged send status." ], "failure_signals": [ "Portal submissions failing silently without generating a queue ticket or receipt.", "SLA timer service not accounting for weekends or local holidays in deadline calculation.", "Receipt email service lacking retry logic, resulting in undelivered acknowledgements." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have informal intake but lack governed portals with per-jurisdiction SLA tracking." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 12", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 12 requires controllers to provide information on rights and to facilitate their exercise; a governed intake channel with receipt and SLA tracking directly satisfies this obligation.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.135", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CCPA §1798.135 mandates at least two designated methods for consumer rights submissions including a toll-free number and online form; this control implements the intake infrastructure for both.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "dpdp", "requirement_id": "data principal rights ch. III", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DPDPA Chapter III grants data principals the right to access and correction; the intake channel is necessary infrastructure but fulfillment controls (DS-03) complete the obligation.", "source_version": "Act 2023; Rules 2025", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "okta_iam", "requirement_id": "Okta + DataGrail integration — automated DSR intake", "rationale": "Okta's integration with DataGrail enables automated data subject request intake and routing without requiring Okta admin involvement. Identity records stored in Okta Universal Directory provide the authoritative subject identification data needed to route and process DSRs across connected systems, reducing DSR reception latency and improving compliance response times.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta+DataGrail automates DSR intake and routing from identity records, providing an intake mechanism but not the all-channel receipts and SLA timers.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI privacy request channels (privacy.openai.com / dsar@openai.com)", "rationale": "OpenAI provides a dedicated DSAR intake channel (dsar@openai.com) for data subject requests relating to OpenAI-controlled personal data. Enterprise API customers are responsible for receiving and routing DSRs from their own end-users, but must understand the split controller responsibilities to correctly identify when requests must be fulfilled by the enterprise versus escalated to OpenAI.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's dsar@ channel handles OpenAI-controlled requests; it is a downstream route, not the enterprise's governed all-channel intake DS-01 defines.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic privacy support channels", "rationale": "Anthropic's Privacy Center provides documented channels for EU-based users to exercise GDPR rights including access, erasure, restriction, and objection. Enterprise API customers acting as controllers for their end-users are responsible for their own DSR reception mechanisms; Anthropic handles requests concerning Anthropic-controlled personal data through the Privacy Center.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's Privacy Center receives requests for Anthropic-controlled data; the enterprise's own intake channel remains its responsibility under DS-01.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Rights requests received outside governed channels are systematically lost or delayed, producing enforcement exposure that no downstream process can remediate. DS-01 establishes the intake infrastructure — governed portal, deadline timers, and auditable receipt — that every downstream rights-fulfillment control depends on. Without it, DSAR compliance is a matter of luck rather than design.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-01", "validation_objective": "Every data subject rights request received through any channel — portal, email, phone, social media, or chat — must generate a unique intake record with timestamp, request type, and jurisdiction-specific deadline within one business day of receipt. The DSAR portal must enforce SLA countdown timers with escalation alerts at 50% and 80% elapsed per jurisdiction, and the audit trail must confirm zero requests are lost or without an auditable receipt.", "evidence_required": [ "dsar_portal_intake_log showing request ID, request type, submission channel, requestor identifier, jurisdiction classification, intake timestamp, and auto-generated deadline date for every request", "sla_compliance_report by jurisdiction showing on-time response rates, escalation trigger records at 50% and 80% elapsed, and any deadline extensions with documented justification", "informal_channel_routing_log showing requests received via email, chat, or phone with date received by front-line team and date entered into the portal queue — confirming same-business-day routing", "receipt_delivery_log confirming auto-generated receipt email delivery timestamp per request with idempotent delivery confirmation" ], "machine_tests": [ "Submit a test DSAR via the portal → assert auto-receipt email is generated and delivered within 5 minutes with correct jurisdiction-specific deadline date populated", "Submit a test DSAR and advance the internal clock to 50% of the jurisdiction SLA deadline → assert escalation notification fires to the responsible team with request ID and remaining time", "Attempt to submit a DSAR via portal without mandatory fields (request type, contact, jurisdiction) → assert portal rejects submission with validation error rather than creating a partial intake record", "Submit a test request via informal email channel → assert request appears as a portal intake queue entry within one business day with informal-channel source flag set" ], "human_review": [ "Review DSAR intake log quarterly sample to verify every request has an intake timestamp, auto-generated receipt, and correct jurisdiction-specific deadline — including requests originally received via informal channels", "Assess informal-channel triage procedure documentation and confirm all customer-facing teams are trained to route requests to the portal queue the same business day they are received", "Verify SLA breach rate by jurisdiction and investigate root causes for any missed deadlines — confirm remediation actions are documented and implemented" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Accepting DSAR submissions exclusively via unmonitored email inboxes without structured logging, SLA deadline tracking, or automatic receipt generation", "Treating requests received via social media, chat, or phone as non-binding and not routing them to the formal intake queue, systematically missing multi-channel submissions", "Configuring SLA countdown timers uniformly across jurisdictions without accounting for jurisdiction-specific deadline calculation rules, business days, and local holidays", "Generating intake receipts without jurisdiction-specific deadline dates, leaving requestors without the timeline transparency required by GDPR Art 12", "Running separate intake queues for different request types without a unified audit trail, making cross-request SLA compliance reporting and pattern detection impossible" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-02", "layer": "DS", "plane": "lifecycle", "name": "Identity Verification for Rights Requests", "plain": "Rights requestors are verified using proportionate methods that do not create excessive barriers; verification decisions are documented and reviewed for consistency.", "threat": { "tags": [ "unauthorized-data-access", "excessive-verification-barriers", "inconsistent-verification-standards" ], "desc": "Overly burdensome identity verification — requiring documents or steps disproportionate to the risk — constitutes a barrier to rights exercise under GDPR Art 12(6). Insufficient verification enables unauthorized access to another person's data." }, "standard": [ { "id": "gdpr", "section": "Art 12(6)", "title": "Transparent information and communication — proportionate verification" }, { "id": "ccpa", "section": "§1798.130(a)/§1798.140(ak)", "title": "Verifiable consumer request requirements" }, { "id": "nist_pf", "section": "PR.AC-P6", "title": "Individuals proofed and authenticated commensurate with risk" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-02 Identity Verification for Rights Requests control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-02 Identity Verification for Rights Requests control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DS-02 Identity Verification for Rights Requests control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DS-02 Identity Verification for Rights Requests control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-02 Identity Verification for Rights Requests control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Apply a tiered verification matrix that matches verification stringency to data sensitivity and request risk level; document every verification decision and outcome in the rights-request evidence log.", "steps": [ "Define a tiered verification matrix: low-risk requests (newsletter opt-out) may use email confirmation; high-risk requests (full access response, sensitive category data) require authenticated account login or two-factor confirmation.", "Document the verification method used for each request and the rationale when the standard tier is elevated or reduced.", "Implement a consistency review process (quarterly sample audit) to identify cases where similar requests received materially different verification treatment.", "Train all staff handling DSARs on the proportionality standard and document that training in the evidence log." ], "anti_patterns": [ "Requiring notarized identity documents for all DSAR types regardless of data sensitivity or risk.", "Applying no verification at all to access requests that would return sensitive personal data." ] }, "validation": { "design_check": [ "Confirm tiered verification matrix is documented and tied to data-sensitivity classifications [ref:gdpr_2016_679]", "Verify verification decisions are logged with method used and rationale for any deviation from the tier default [ref:ccpa_cpra_2023]", "Confirm consistency review process is scheduled and assigned to a responsible role [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit a low-risk test DSAR (email opt-out category) and verify verification tier applied matches policy.", "Submit a high-risk test DSAR (full access, sensitive data category) and verify elevated verification is applied and logged.", "Review last quarterly consistency audit report and confirm any identified discrepancies were investigated." ], "evidence": [ "privacy:verification-log — Verification method and outcome recorded per DSAR in intake system [unverified]", "privacy:tier-matrix — Published tiered verification policy document reviewed by DPO [unverified]", "privacy:consistency-audit — Quarterly sample audit report of verification decisions and findings [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Implement verification tier logic within the DSAR portal and ensure verification outcomes are captured in the evidence log.", "actions": [ "Build verification tier selection into the portal intake flow based on request type and data sensitivity flags.", "Log verification method used, timestamp of verification, and outcome for every request.", "Implement fallback prompts when requestor authentication fails, directing to alternative verification path." ], "failure_signals": [ "Portal allowing access-request fulfillment to proceed without a logged verification outcome.", "Verification tier logic hardcoded without configuration hooks for policy updates.", "Verification failures not triggering requestor notification or alternative path." ] }, "dpo": { "summary": "Own the proportionality policy governing verification tiers and review escalated cases where standard methods are not applicable.", "actions": [ "Approve the tiered verification matrix and review annually or when new data categories are added.", "Act as decision authority for edge cases where requestor cannot satisfy standard verification.", "Monitor consistency audit findings and direct remediation when disparate treatment is identified." ], "failure_signals": [ "DPA complaint citing excessive verification barriers preventing rights exercise.", "Consistency audit reveals systematic over- or under-verification for a specific data category.", "No process for edge-case escalation when requestor cannot complete standard verification." ] }, "data_governance": { "summary": "Ensure data sensitivity classifications are aligned with the verification tier matrix so tier selection is data-driven.", "actions": [ "Maintain data sensitivity taxonomy and publish it as an input to the verification tier matrix.", "Ensure new data categories receive a sensitivity classification before related DSARs can be processed.", "Include verification tier alignment in the data catalog governance review cycle." ], "failure_signals": [ "New data categories ingested without sensitivity classification, causing undetermined verification tier.", "Verification tier matrix referencing sensitivity labels not present in the active data catalog.", "Data governance taxonomy update not propagated to the DSAR verification configuration." ] }, "grc_auditor": { "summary": "Verify that the proportionality principle is operationally applied and that verification records are sufficient for regulatory defence.", "actions": [ "Review verification matrix against GDPR Art 12(6) proportionality requirement and CCPA §1798.130(3) verification rules.", "Sample 10% of completed DSARs to confirm verification method recorded and consistent with matrix tier.", "Test that high-risk request types cannot proceed to fulfillment without a logged verification pass." ], "metrics": [ "Percentage of completed DSARs with logged verification outcome (target: 100%)", "Consistency audit finding rate — cases where verification tier deviated from policy without documented rationale (target: <2%)" ], "failure_signals": [ "DSAR sample contains fulfilled requests with no logged verification record.", "Consistency audit finding rate above 2% with no remediation plan.", "High-risk requests fulfilled without elevated verification step." ] }, "software_engineering": { "summary": "Implement tier-based verification gating in the request fulfillment pipeline with audit log integration.", "actions": [ "Build verification-gate middleware in the fulfillment pipeline that blocks progress until verification status is logged as 'passed'.", "Implement per-tier verification UX flows (email OTP, account login, 2FA) with fallback paths.", "Expose verification audit log as a structured API endpoint for integration with DS-08." ], "failure_signals": [ "Fulfillment pipeline bypassing verification gate for certain request types or edge-case flows.", "Verification UX flows not handling authentication token expiry, causing silent verification failures.", "Audit log entries missing required fields (method, timestamp, outcome) for a subset of requests." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many organizations apply ad hoc verification without a documented matrix, creating inconsistency and proportionality risk." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 12(6)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 12(6) expressly permits controllers to request additional information to confirm identity where there are reasonable doubts, subject to a proportionality constraint; this control operationalizes that proportionality standard.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.130(a) / §1798.140(ak)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CCPA §1798.130(a) sets the procedural requirements for responding to verifiable consumer requests, and §1798.140(ak) defines a verifiable consumer request as one where the business can reasonably verify the consumer's identity; DS-02's tiered verification satisfies that definition while the proportionality standard is a GDPR overlay.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "PR.AC-P6", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "DS-02 implements NIST Privacy Framework PR.AC-P6 — individuals are proofed and bound to credentials, and authenticated commensurate with the risk of the transaction — by scaling identity verification strength to the sensitivity of the rights request.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta Universal Directory and authentication policies — identity assurance for rights requests", "rationale": "Okta Universal Directory maintains authoritative identity records that enable verification of requestor identity before DSR fulfillment. Stored profile attributes, multi-factor authentication history, and account metadata provide the verification basis for confirming that a DSR is submitted by or on behalf of the data subject, satisfying GDPR Art 12(6) identity verification requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta directory attributes and MFA history provide an identity-verification basis for DSRs but not the tiered, proportionate verification matrix DS-02 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_privacy", "requirement_id": "Amazon Cognito and AWS IAM — identity verification capabilities", "rationale": "AWS IAM and Amazon Cognito provide identity verification capabilities that can be integrated into DSR processing workflows. Cognito supports multi-factor authentication and identity federation, enabling organizations to implement verified identity confirmation gates in DSR reception workflows before granting access to personal data for rights fulfillment.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Cognito and IAM supply MFA and identity-verification capabilities that can gate DSR workflows but not the documented risk-tiered verification matrix.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Rights verification occupies a paradox: too little enables unauthorized data disclosure; too much constitutes an unlawful barrier that suppresses legitimate rights exercise. DS-02 resolves the paradox with a tiered, proportionality-calibrated matrix that varies verification stringency by data sensitivity and request risk, ensuring every decision is logged and reviewed for consistency. This prevents both the unauthorized disclosure and the regulatory exposure of rights suppression.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-02", "validation_objective": "Every rights request must have a documented verification method and outcome recorded before fulfillment proceeds, with verification stringency matched to a documented tiered matrix calibrated to data sensitivity and request risk level. No high-risk request — defined as a full access response or request involving sensitive category data — may proceed to fulfillment without an elevated verification step logged as passed.", "evidence_required": [ "tiered_verification_matrix document approved by DPO specifying verification method by request type and data sensitivity tier with documented proportionality rationale for each tier assignment", "verification_log per DSAR showing verification method applied, timestamp of verification completion, outcome (passed/failed/alternative-path), and any deviation from the matrix tier with documented rationale", "quarterly_consistency_audit_report sampling DSAR verification decisions and identifying cases where similar requests received materially different verification treatment with investigation and remediation records", "staff_training_record confirming DSAR-handling staff received training on the proportionality standard with training date, trainer identity, and staff sign-off" ], "machine_tests": [ "Submit a high-risk test DSAR (sensitive data category, full access request) without completing elevated verification → assert fulfillment pipeline blocks at the verification gate with an error code rather than proceeding to data retrieval", "Submit a low-risk test DSAR (email opt-out category) with email OTP verification completed → assert portal records verification method as 'email-otp' and outcome as 'passed' before advancing to fulfillment", "Attempt to bypass verification gate by calling the fulfillment API endpoint directly without a verification session token → assert request is rejected with HTTP 403 and verification-required error code", "Submit a test DSAR with failed authentication on the first attempt → assert fallback verification path prompt is presented to the requestor and the failure event is logged with timestamp" ], "human_review": [ "Review quarterly consistency audit findings to identify cases of systematic disparate verification treatment across similar request types, and verify findings were investigated and remediated before the next audit cycle", "Evaluate tiered verification matrix against GDPR Art 12(6) proportionality standard — confirm that verification requirements do not constitute an unreasonable barrier for low-risk request types", "Examine edge-case escalation log where requestors could not complete standard verification, and confirm DPO made a documented decision on an alternative path for each case within the SLA window" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Requiring notarized identity documents or in-person verification for all DSAR types regardless of data sensitivity or risk level, constituting an unreasonable barrier to rights exercise under GDPR Art 12(6)", "Applying no identity verification to access requests that would return sensitive personal data, enabling unauthorized data disclosure to any requestor claiming to be the data subject", "Logging verification completion as a checkbox without recording the specific method used, making consistency audits and regulatory defense of proportionality decisions impossible", "Applying inconsistent verification stringency across similar requests based on individual handler judgment rather than a documented policy matrix, creating disparate treatment exposure", "Using verification methods technically inaccessible to certain requestor populations (e.g., SMS OTP for users without mobile phones) without providing documented alternative verification paths" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-03", "layer": "DS", "plane": "lifecycle", "name": "Access Request Fulfillment", "plain": "Data subject access requests are fulfilled by providing a complete copy of all personal data — including training data contributions and inference inputs where technically feasible — in a readable format within the statutory deadline.", "threat": { "tags": [ "incomplete-access-response", "ai-outputs-excluded", "excessive-redaction" ], "desc": "Access responses that omit AI inference outputs, exclude inferred attributes, or over-redact on unclear grounds violate Art 15 and generate follow-up complaints. AI-generated profiles from data subject inputs are personal data and must be included." }, "standard": [ { "id": "gdpr", "section": "Art 15", "title": "Right of access by the data subject" }, { "id": "ccpa", "section": "§1798.110", "title": "Right to know personal information collected" }, { "id": "uk_duaa", "section": "access rights provisions", "title": "UK data subject access rights" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-02" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-02" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-03 Access Request Fulfillment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Build a fulfillment pipeline that queries all personal data stores — including AI training corpora, inference logs, and derived-attribute stores — compiles a complete response package, and routes it for redaction review before delivery within the SLA deadline.", "steps": [ "Maintain a fulfillment data-source registry mapping each personal data store (operational databases, AI training datasets, inference logs, derived-attribute tables) to the query procedure and responsible team.", "Implement an automated query orchestrator that triggers fulfillment data pulls from all registered sources when a verified DSAR enters the fulfillment stage.", "Route assembled response packages through a redaction review step where only lawfully protected third-party data or legal privilege is redacted — document all redactions with reason codes.", "Deliver the response to the requestor in machine-readable format (JSON or CSV) alongside a human-readable summary within the statutory deadline, logging delivery confirmation." ], "anti_patterns": [ "Excluding AI inference outputs or inferred attributes from access responses on the grounds that they are 'system-generated' rather than 'personal data'.", "Applying blanket redactions without documented reason codes, making redaction decisions non-auditable." ] }, "validation": { "design_check": [ "Confirm fulfillment data-source registry exists and includes AI training data stores and inference logs [ref:gdpr_2016_679]", "Verify redaction review step is documented with permitted reason codes and approval workflow [ref:ccpa_cpra_2023]", "Confirm machine-readable format option is available for all fulfillment responses [ref:uk_duaa_2025]" ], "runtime_test": [ "Submit a test DSAR for a user with known inference outputs and verify the response package includes inferred attributes.", "Submit a test DSAR and verify response is delivered within the SLA deadline with a logged delivery confirmation.", "Review a redacted test response and confirm every redaction has a documented reason code." ], "evidence": [ "privacy:fulfillment-package — Compiled access response package with source provenance metadata [unverified]", "privacy:redaction-log — Log of redactions applied per response with reason codes [unverified]", "privacy:delivery-receipt — Logged delivery confirmation timestamp and format used [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and maintain the fulfillment pipeline, data-source registry, and query orchestrator that produce complete access responses.", "actions": [ "Maintain the fulfillment data-source registry and ensure new personal data stores are onboarded before production traffic begins.", "Implement query orchestrator with per-source SLA sub-deadlines and failure alerts when a source does not respond in time.", "Build the response package assembler with provenance metadata tagging so each data item is traceable to its source system." ], "failure_signals": [ "New AI inference log store deployed without being added to the fulfillment data-source registry.", "Query orchestrator silently skipping a failed data-source query and producing an incomplete response.", "Response packages lacking provenance metadata, making completeness verification impossible." ] }, "dpo": { "summary": "Approve the redaction policy, govern AI-output inclusion standards, and own the regulatory position on completeness.", "actions": [ "Publish and maintain a redaction policy specifying permitted reason codes and approval authority.", "Own the organization's formal position on inclusion of AI inference outputs in access responses.", "Review follow-up complaints from data subjects citing incomplete access responses and investigate fulfillment failures." ], "failure_signals": [ "DPA complaint citing access response that excluded AI inference outputs or inferred attributes.", "Redaction policy absent or not communicated to the redaction review team.", "Follow-up complaints rate for access responses exceeding 5% of fulfilled DSARs." ] }, "data_governance": { "summary": "Ensure the data inventory is complete enough to drive the fulfillment data-source registry and that AI-derived data categories are catalogued.", "actions": [ "Require all AI-derived data categories (inference outputs, embeddings, profiles) to be catalogued in the data inventory before production deployment.", "Maintain linkage between the data inventory and the fulfillment data-source registry so registry updates are driven by inventory changes.", "Govern the process for declaring data sources as out-of-scope for access responses and require DPO sign-off." ], "failure_signals": [ "AI inference outputs in production but not registered in data inventory or fulfillment registry.", "Data inventory and fulfillment registry diverging because updates are managed independently.", "Data sources declared out-of-scope without DPO approval documentation." ] }, "grc_auditor": { "summary": "Test completeness of access responses against the data inventory and verify SLA compliance and redaction governance.", "actions": [ "Cross-reference a sample of access responses against the fulfillment data-source registry to detect missing sources.", "Confirm all redactions in sampled responses have documented reason codes and required approvals.", "Verify SLA compliance rate for access fulfillment responses." ], "metrics": [ "Access response completeness rate — responses covering all registered data sources (target: 100%)", "Redaction documentation rate — redactions with logged reason codes (target: 100%)" ], "failure_signals": [ "Sample audit reveals responses missing data from one or more registered sources.", "Redactions without reason codes found in sampled responses.", "SLA breach rate for access fulfillment above 5%." ] }, "software_engineering": { "summary": "Implement the query orchestrator, response assembler, redaction tooling, and delivery mechanisms for access fulfillment.", "actions": [ "Build query orchestrator as a configurable pipeline with per-source timeout, retry, and failure-alert logic.", "Implement response assembler that merges query results with provenance metadata and produces structured output (JSON/CSV).", "Build redaction tooling that supports reason-code tagging and generates a redaction manifest per response." ], "failure_signals": [ "Query orchestrator lacking retry logic, causing transient source failures to produce permanently incomplete responses.", "Response assembler not deduplicating records across sources, producing inflated or confusing output.", "Redaction tooling applying transformations without logging the original value hash for audit purposes." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organizations fulfill access requests from operational databases only, omitting AI training and inference data stores." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 15", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 15 grants data subjects the right to obtain a copy of their personal data and information about its processing; this control implements the fulfillment pipeline that satisfies that right including AI-derived data.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.110", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CCPA §1798.110 grants consumers the right to know the categories and specific pieces of personal information collected about them; this control produces the access response fulfilling that right across all personal data stores.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "access rights provisions", "fit": "partial", "direction": "control-supports-requirement", "rationale": "UK DUAA preserves UK GDPR Art 15 access rights with UK-specific modifications; this control supports those obligations but full compliance requires alignment with any UK-specific divergences from EU GDPR.", "source_version": "2025 c.15", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "okta_iam", "requirement_id": "Okta scoped administrator roles — least-privilege data export", "rationale": "Okta's scoped administrator roles allow controlled access to and export of individual user data stored in Universal Directory for DSAR fulfillment purposes. A dedicated DSR fulfillment role can be configured with read-only export permissions scoped to the requesting subject's records, enabling compliant Art 15 access request fulfillment without broad administrative access.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta scoped roles export a subject's identity records for DSAR, covering that slice but not AI training/inference contributions or derived attributes.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI privacy request fulfillment — personal data access", "rationale": "OpenAI provides access to personal data held about data subjects upon verified request. For enterprise API customers, split controller responsibilities mean the enterprise is responsible for Art 15 access fulfillment regarding their end-users' data, while OpenAI handles requests concerning Anthropic-controlled data such as API account information and usage metadata.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI provides access to data it holds; under split control the enterprise remains responsible for Art 15 fulfillment of its end-users' data.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Training Data Management — provenance and lineage", "rationale": "SAIF's Training Data Management control covers tracking the provenance and lifecycle of data used in model training; that lineage capability is what allows an access response to disclose AI-related processing of the requestor's personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF training-data provenance/lineage helps locate a subject's AI-processing data for inclusion in the access response, enabling but not completing fulfillment.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Access request fulfillment in AI-enabled organizations routinely fails at the boundary between operational data stores and AI inference outputs — the inferred profile is personal data but is excluded from the access response because no one mapped it to the fulfillment pipeline. DS-03 closes this gap by governing a comprehensive fulfillment data-source registry that includes AI training corpora and inference logs, ensuring the access response a data subject receives is actually complete.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-03", "validation_objective": "Every verified data subject access request must produce a response package that includes personal data from all sources registered in the fulfillment data-source registry — including AI training data contributions, inference inputs, and AI-derived attributes — with every redaction documented by reason code, delivered in machine-readable format within the statutory deadline, and with a logged delivery confirmation.", "evidence_required": [ "fulfillment_data_source_registry listing all personal data stores including AI training datasets, inference log stores, embedding stores, and derived-attribute tables with query procedure and responsible team for each", "access_response_package with provenance metadata tagging each data item to its source system, confirming all registered sources were queried and their response status recorded", "redaction_log per response showing every redaction applied with reason code (third-party-privacy, legal-privilege, trade-secret), approver identity, and original value hash for audit purposes", "delivery_receipt with delivery timestamp, format delivered (JSON/CSV plus human-readable summary), and channel confirmation for each fulfilled DSAR response", "query_orchestrator_execution_log showing per-source query status, response time, retry outcomes for failed queries, and final completeness status for each DSAR fulfillment run" ], "machine_tests": [ "Submit a test DSAR for a synthetic data subject with known inference outputs in the AI inference log store → assert response package includes inferred attributes with source provenance tagged as the inference-log store", "Remove one data store from the query orchestrator registry and submit a test DSAR → assert fulfillment pipeline raises an incomplete-response alert rather than silently delivering a partial package", "Apply a test redaction to a response package without a reason code → assert response assembler rejects the incomplete redaction record and requires a reason code before delivery proceeds", "Submit a test DSAR with a deadline of today → assert automated delivery occurs within the SLA window and a delivery confirmation timestamp is logged with format identifier" ], "human_review": [ "Review fulfillment data-source registry to confirm all AI training datasets, inference log stores, embedding stores, and derived-attribute tables are registered — cross-reference against the data inventory to detect unregistered AI data stores", "Audit a sample of completed access response packages to verify AI inference outputs and inferred attributes are included, and confirm all redactions carry documented reason codes with DPO-approved rationale", "Evaluate redaction policy for lawfulness — verify that only third-party personal data, legal privilege, or trade secrets are redacted and that blanket redactions of AI-derived attributes are not applied" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Excluding AI inference outputs, inferred attributes, and AI-derived profiles from access responses on the grounds that they are system-generated rather than personal data attributable to the data subject", "Querying only operational databases for access fulfillment while omitting AI training corpora, inference log stores, and derived-attribute tables that contain personal data about the requestor", "Applying blanket redactions of AI-generated content without documented reason codes, making redaction decisions non-auditable and indefensible in a regulatory complaint", "Delivering access response packages without provenance metadata, preventing the data subject from understanding which systems held their data and making completeness verification impossible", "Failing to register new AI inference log stores or derived-attribute tables in the fulfillment data-source registry when deployed, creating permanent blind spots in access fulfillment coverage" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-04", "layer": "DS", "plane": "lifecycle", "name": "Erasure and Anonymization", "plain": "Personal data deletion pipelines cover AI training data contributions, with a documented retraining threshold policy and suppression from future inference, implementing the right to erasure with audit evidence.", "threat": { "tags": [ "erasure-not-implemented", "training-data-not-purged", "re-identification-from-retained-data" ], "desc": "Machine unlearning remains technically challenging; organizations must define and document their erasure implementation position — including when a full retrain is triggered — to satisfy Art 17 without overpromising technical capabilities they do not have." }, "standard": [ { "id": "gdpr", "section": "Art 17", "title": "Right to erasure ('right to be forgotten')" }, { "id": "ccpa", "section": "§1798.105", "title": "Consumer right to delete personal information" }, { "id": "iso_27701", "section": "8.3", "title": "Privacy by design and erasure obligations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-02" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DS-04 Erasure and Anonymization control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement an erasure pipeline covering all personal data stores with a documented machine-unlearning policy that specifies retraining thresholds; suppression tokens prevent erased data subjects from reappearing in future inference outputs.", "steps": [ "Document the organization's machine-unlearning position: specify the threshold (e.g., number of affected records) that triggers a full model retrain versus applying a suppression token approach for smaller erasure volumes.", "Implement erasure pipelines across all operational data stores — including training datasets, embedding stores, and derived-attribute tables — with automated confirmation that records matching the requestor's identifier are deleted.", "Apply suppression tokens or exclusion filters to inference pipelines so erased data subjects are excluded from future model outputs pending any scheduled retrain.", "Generate an erasure confirmation record for each completed erasure request documenting scope, method, and any residual risk where technical limitations prevent full erasure." ], "anti_patterns": [ "Deleting records from operational databases while leaving the same data embedded in AI training corpora and inference logs.", "Claiming full erasure capability without a documented and tested machine-unlearning or suppression mechanism." ] }, "validation": { "design_check": [ "Confirm machine-unlearning policy is documented, approved by DPO, and includes retraining threshold criteria [ref:gdpr_2016_679]", "Verify erasure pipeline scope includes all personal data stores registered in the fulfillment data-source registry [ref:ccpa_cpra_2023]", "Confirm suppression token mechanism is implemented and tested for inference pipeline exclusion [ref:iso_27701_2019]" ], "runtime_test": [ "Submit a test erasure request and verify records are deleted from all in-scope data stores within the SLA deadline.", "Verify that after erasure, inference pipeline does not return data attributable to the erased subject in test queries.", "Review erasure confirmation record and confirm it documents scope, method, and residual risk where applicable." ], "evidence": [ "privacy:erasure-confirmation — Per-request erasure confirmation record with scope and method [unverified]", "privacy:suppression-log — Suppression token log showing active exclusions in inference pipeline [unverified]", "privacy:unlearning-policy — Documented machine-unlearning policy with retraining threshold criteria [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and operate erasure pipelines, suppression mechanisms, and erasure confirmation record generation across all data stores.", "actions": [ "Build erasure pipeline as a multi-store orchestrator aligned with the fulfillment data-source registry.", "Implement suppression token service that injects exclusion filters into inference pipeline calls for erased subjects.", "Generate structured erasure confirmation records with scope metadata and residual-risk flags." ], "failure_signals": [ "Erasure pipeline not covering AI training corpora or inference logs registered in the data-source registry.", "Suppression token service not integrated with all inference pipeline endpoints.", "Erasure confirmation records missing residual-risk documentation where technical limitations apply." ] }, "dpo": { "summary": "Approve the machine-unlearning policy and own the regulatory communication position for erasure requests where full technical erasure is not immediately achievable.", "actions": [ "Approve and annually review the machine-unlearning policy including retraining thresholds and suppression fallback.", "Draft and maintain a template response for erasure requests where residual risk must be disclosed.", "Monitor erasure SLA compliance and investigate any failure to confirm erasure within the statutory deadline." ], "failure_signals": [ "Erasure requests fulfilled without an erasure confirmation record issued to the requestor.", "Machine-unlearning policy not reviewed since initial AI system deployment despite new model versions.", "DPA complaint citing failure to erase data from AI inference outputs." ] }, "data_governance": { "summary": "Ensure all personal data stores are registered and classified so erasure pipelines can achieve complete scope coverage.", "actions": [ "Mandate registration of all AI training datasets and derived-attribute stores in the data inventory before production use.", "Include erasure-pipeline coverage status as a governance attribute for each registered data store.", "Govern exceptions where erasure is not technically feasible and require DPO approval and documentation." ], "failure_signals": [ "AI training datasets in production not registered in data inventory, leaving them outside erasure pipeline scope.", "Erasure-pipeline coverage status not tracked as a data governance attribute, creating unknown gaps.", "Technical erasure exceptions approved without DPO review or documentation." ] }, "grc_auditor": { "summary": "Verify erasure pipeline completeness, test suppression effectiveness, and confirm the machine-unlearning policy meets regulatory expectations.", "actions": [ "Review machine-unlearning policy against GDPR Art 17 requirements and CCPA §1798.105 deletion standards.", "Test erasure by querying all registered data stores for a test-erased subject identifier post-deletion.", "Verify that inference pipeline returns no data attributable to erased subjects in test scenarios." ], "metrics": [ "Erasure pipeline coverage rate — registered data stores with active erasure capability (target: 100%)", "Erasure SLA compliance rate (target: ≥95%)" ], "failure_signals": [ "Registered data stores without erasure pipeline coverage discovered during audit.", "Post-erasure query returning records attributable to the erased subject in any registered store.", "Erasure SLA breach rate above 5%." ] }, "software_engineering": { "summary": "Implement erasure pipeline orchestrator, suppression token service, and erasure confirmation record generator.", "actions": [ "Build erasure orchestrator that dispatches per-store delete jobs with idempotent retry and per-store confirmation callbacks.", "Implement suppression token service as an inference middleware layer with token expiry tied to retraining schedule.", "Build erasure confirmation record generator that aggregates per-store outcomes and flags residual risk." ], "failure_signals": [ "Erasure orchestrator lacking idempotent retry, causing partial deletions on transient failures.", "Suppression token service not covering all inference API endpoints, leaving some outputs unsuppressed.", "Erasure confirmation records not generated when one or more store deletion jobs fail." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Machine-unlearning policy is absent in most organizations; suppression mechanisms are rarely implemented for AI inference pipelines." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "ML Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 17", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 17 establishes the right to erasure; this control implements the erasure pipeline, machine-unlearning policy, and suppression mechanisms required to operationalize that right across AI data stores.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.105", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CCPA §1798.105 grants consumers the right to delete personal information; this control builds the deletion pipeline and confirmation record required to demonstrate compliance.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "8.3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 8.3 addresses privacy by design including data minimization and erasure; this control implements the erasure dimension but ISO 27701 certification requires broader PIMS implementation.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Google Cloud Sensitive Data Protection — de-identification API", "rationale": "Google Cloud's Sensitive Data Protection (formerly Cloud DLP) provides tokenization, masking, bucketing, format-preserving encryption, and pseudonymization for de-identifying personal data in AI training sets. The de-identification API can be applied to training datasets to replace personal data with synthetic or pseudonymized equivalents, supporting erasure obligations while preserving data utility for AI training.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Cloud DLP de-identification pseudonymizes training data, covering the anonymization half but not the erasure pipeline or retraining-threshold policy.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI data deletion controls", "rationale": "OpenAI supports deletion of customer-provided personal data via API data controls and the DSAR process. For API usage, data is automatically deleted after the 30-day retention period. Customers can request expedited deletion through the DSAR channel. OpenAI retains only an audit record of the deletion request to evidence compliance, not the underlying personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI deletes vendor-held personal data via API controls and DSAR, covering erasure at the vendor layer but not training-set purge or inference suppression.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic zero data retention option — non-retention by architecture", "rationale": "Anthropic's Zero Data Retention addendum ensures no data persistence beyond real-time abuse detection processing. Under ZDR, standard API logs are never created, eliminating the erasure fulfillment burden for API-layer personal data. The 7-day default retention for non-ZDR customers provides a short automatic deletion window that limits the scope of Art 17 erasure obligations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic ZDR's non-persistence removes API-layer data to erase, structurally limiting Art 17 scope but not providing the erasure pipeline DS-04 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Lifecycle Management — account deactivation and deletion workflows", "rationale": "Okta Lifecycle Management's delete lifecycle state automates downstream erasure across connected applications when a user's right to erasure is exercised. The delete event triggers deprovisioning workflows in all connected apps, removing the user's data footprint across the application stack in a coordinated, auditable manner aligned with GDPR Art 17 erasure requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta's delete lifecycle state propagates erasure across connected apps, covering identity-stack deletion but not training-data purge or suppression tokens.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Erasure in AI systems is a multi-layer problem: deleting an operational database record does not remove the data from the model weights that learned from it. DS-04 confronts this gap directly by requiring organizations to document their machine-unlearning position, implement suppression tokens as an interim measure, and define the retraining threshold that triggers full remediation — producing an auditable, honest erasure posture rather than one that silently fails at the AI layer.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-04", "validation_objective": "The system must implement an erasure pipeline covering all personal data stores registered in the fulfillment data-source registry — including AI training datasets, inference logs, embedding stores, and derived-attribute tables — backed by a DPO-approved machine-unlearning policy specifying the retraining threshold, a suppression token mechanism that excludes erased subjects from future inference outputs, and a per-request erasure confirmation record documenting scope, method, and residual risk from any technical limitations.", "evidence_required": [ "machine_unlearning_policy approved by DPO specifying the retraining threshold (by record count or proportion) that triggers full model retrain versus suppression token interim approach, with last annual review date", "erasure_pipeline_execution_log per request showing per-store deletion job status, records deleted or anonymized, completion timestamp, and confirmation callback for every registered data store", "suppression_token_log showing active tokens with data subject identifier hash, activation date, inference pipeline endpoints covered, and token expiry date tied to the retraining schedule", "erasure_confirmation_record per request documenting stores covered, deletion method used per store, completion status, and residual-risk disclosure where technical limitations prevent full immediate erasure", "post_erasure_verification_query_result showing zero records attributable to the erased subject in each registered AI data store after erasure pipeline completion" ], "machine_tests": [ "Submit a test erasure request for a synthetic data subject and query all registered AI data stores post-deletion → assert zero records match the subject identifier in every store within the SLA deadline", "Activate a suppression token for a test subject and submit inference queries that would normally include that subject's data → assert inference outputs contain no data attributable to the suppressed subject", "Submit a test erasure request and interrupt one store's deletion job mid-run → assert erasure orchestrator retries with idempotent logic and generates a completion callback rather than a silent partial deletion", "Query suppression token service for coverage of all inference pipeline endpoints → assert all registered inference APIs are covered by the suppression middleware layer with no unregistered endpoints" ], "human_review": [ "Review machine-unlearning policy to confirm the retraining threshold is technically achievable and legally defensible under GDPR Art 17, and that suppression tokens are documented as an interim measure pending retrain not as a permanent substitute", "Assess erasure pipeline coverage by cross-referencing registered AI data stores against the fulfillment data-source registry to identify any stores with active personal data but no erasure pipeline coverage", "Review erasure confirmation records for a sample of requests to verify residual-risk disclosures are accurate and that requestors were notified where full technical erasure was not immediately achievable" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Deleting personal data from operational databases while leaving identical data embedded in AI training corpora, fine-tuned model weights, and inference logs without any suppression mechanism", "Claiming full erasure capability in DSAR responses without a documented and tested machine-unlearning or suppression mechanism to substantiate that claim", "Treating full model retrain as the only valid erasure mechanism without implementing suppression tokens as an interim measure, causing indefinite erasure delays while the retrain threshold accumulates", "Generating erasure confirmation records asserting complete deletion without verifying erasure across all registered AI data stores including embedding stores and derived-attribute tables", "Failing to extend suppression tokens to all inference pipeline endpoints, leaving some outputs unsuppressed and allowing erased subject data to reappear through uncovered inference paths" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-05", "layer": "DS", "plane": "lifecycle", "name": "Automated Decision Explanation Rights", "plain": "The procedural obligation to provide an explanation of the logic, factors, and significance of AI-driven decisions with legal or similarly significant effects is fulfilled within the statutory response SLA.", "threat": { "tags": [ "no-explanation-process", "sla-breach", "explanation-provided-without-quality-check" ], "desc": "GDPR Art 22(3) guarantees safeguards for solely automated decisions — human intervention, the right to express a view, and the right to contest; an explicit right to explanation rests on Recital 71 and remains contested, while EU AI Act Art 86 provides one directly. CCPA ADMT regulations extend this to California. Absence of an explanation workflow creates direct regulatory exposure; explanation provided without quality checks fails the meaningful information standard." }, "standard": [ { "id": "gdpr", "section": "Art 22(3)", "title": "Automated individual decision-making, including profiling — safeguards (human intervention, contestation)" }, { "id": "ccpa", "section": "ADMT §1798.185", "title": "ADMT consumer explanation rights" }, { "id": "eu_ai_act", "section": "Art 86", "title": "Right to explanation for high-risk AI system decisions" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-02" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DS-05 Automated Decision Explanation Rights control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Implement a dedicated explanation-request workflow that routes to the model governance team for explanation generation, quality review, and delivery within the SLA; the DS layer owns the procedural SLA while XP-01 (Ethics domain) governs explanation quality and method.", "steps": [ "Define the explanation-request intake path within the DSAR portal with a specific request type for automated-decision explanations.", "Establish an explanation-generation procedure that routes requests to the model owner or governance team responsible for producing the logic, factors, and significance description.", "Implement an explanation quality gate that routes generated explanations to DPO review before delivery to confirm they meet the 'meaningful information' standard — flagging for Ethics domain XP-01 review for method adequacy.", "Deliver the approved explanation to the requestor within the statutory SLA and log the delivery with quality-gate outcome metadata." ], "anti_patterns": [ "Producing explanation responses without a quality gate, delivering technically accurate but meaningless outputs that fail the 'meaningful information' standard.", "Routing explanation requests through the general DSAR queue without a dedicated model-owner escalation path, causing delays that breach the SLA." ] }, "validation": { "design_check": [ "Confirm explanation-request type exists in the DSAR intake portal and routes to the model governance team [ref:gdpr_2016_679]", "Verify explanation quality gate procedure is documented with DPO review step and XP-01 referral path [ref:ccpa_cpra_2023]", "Confirm SLA timer for explanation requests is configured per applicable jurisdiction [ref:eu_ai_act_2024]" ], "runtime_test": [ "Submit a test automated-decision explanation request and verify it routes to model governance within one business day.", "Verify that generated explanation passes quality gate before delivery and that gate outcome is logged.", "Confirm delivery timestamp is within the SLA deadline and delivery receipt is recorded." ], "evidence": [ "privacy:explanation-log — Log of explanation requests, quality gate outcomes, and delivery timestamps [unverified]", "privacy:explanation-response — Approved explanation response package with DPO quality-gate sign-off [unverified]", "privacy:sla-compliance — SLA compliance record for explanation-type DSARs by jurisdiction [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Build the explanation-request intake path, routing logic, and SLA timer for automated-decision explanation requests.", "actions": [ "Add explanation request type to DSAR portal with routing rule to model governance team queue.", "Configure SLA timer for explanation-type requests with jurisdiction-specific deadlines.", "Build quality-gate workflow step that holds delivery pending DPO approval and logs gate outcome." ], "failure_signals": [ "Explanation requests entering general DSAR queue without model-governance routing.", "SLA timer not configured for explanation-type requests.", "Delivery occurring without quality-gate approval step in the workflow." ] }, "dpo": { "summary": "Own the explanation quality standard, conduct quality-gate reviews, and maintain the regulatory position on what constitutes 'meaningful information'.", "actions": [ "Define and publish the explanation quality standard (minimum required elements: logic, factors, significance, right to contest).", "Review and approve each explanation response before delivery as quality gatekeeper.", "Refer method-adequacy questions to Ethics domain XP-01 owners when explanation quality is unclear." ], "failure_signals": [ "Explanation responses delivered to requestors without DPO quality-gate sign-off.", "DPA complaint citing explanation that did not describe the logic or factors in meaningful terms.", "No documented referral process to Ethics domain for explanation method adequacy questions." ] }, "data_governance": { "summary": "Ensure AI decision models are catalogued with the responsible model-owner contact so explanation requests can be routed correctly.", "actions": [ "Require each automated decision model in production to have a registered model owner in the data/AI inventory.", "Maintain the model-owner routing table as a governed artifact updated on every model deployment.", "Include explanation-request routing coverage in the AI governance review cycle." ], "failure_signals": [ "Explanation request cannot be routed because the responsible model owner is not registered.", "Model-owner routing table out of date due to unreported model ownership changes.", "New automated decision models deployed without explanation-routing registration." ] }, "grc_auditor": { "summary": "Verify the explanation workflow is operable, quality-gate records exist, and SLA compliance rates are maintained.", "actions": [ "Review explanation-request workflow against GDPR Art 22(3), CCPA ADMT §1798.185, and EU AI Act Art 86 requirements.", "Sample explanation responses and confirm each has a quality-gate approval record and DPO sign-off.", "Test SLA compliance by submitting test explanation requests and measuring time to delivery." ], "metrics": [ "Explanation request SLA compliance rate (target: ≥95%)", "Quality-gate coverage rate — explanation responses with logged DPO approval (target: 100%)" ], "failure_signals": [ "Sampled explanation responses lacking quality-gate approval records.", "Explanation SLA compliance rate below 95%.", "Explanation responses omitting one or more required elements (logic, factors, significance)." ] }, "software_engineering": { "summary": "Implement the explanation-request routing, quality-gate workflow state machine, and delivery logging.", "actions": [ "Build routing rules in the DSAR workflow engine to direct explanation-type requests to the model governance queue.", "Implement quality-gate workflow state with required approval action before delivery is permitted.", "Log all explanation workflow state transitions with timestamps for SLA reporting." ], "failure_signals": [ "Routing rule not matching explanation-type requests, causing them to fall into general processing.", "Quality-gate state allowing bypass if approval timeout is reached rather than escalating.", "Workflow state transitions not logged with sufficient granularity for SLA calculation." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Explanation workflows are absent in most organizations; where they exist they lack quality gates and model-owner routing." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 22(3)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 22(3) requires controllers to provide meaningful information about automated decision logic when solely automated processing is used; this control implements the procedural workflow that delivers that explanation within the SLA.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "ADMT §1798.185", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CCPA ADMT regulations grant consumers the right to receive an explanation of automated decision logic; this control builds the intake and delivery workflow required to fulfill that right.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art 86", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art 86 provides a right to explanation for decisions made by high-risk AI systems; this control covers the procedural fulfillment obligation while explanation quality and method adequacy are governed by the Ethics domain XP controls.", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — Transparency goals", "rationale": "Microsoft's Responsible AI Standard requires transparency mechanisms including model cards, system cards, and explainability features for AI systems making consequential decisions. For Azure AI deployments, this provides a documented framework for implementing GDPR Art 22 meaningful information rights about automated decision logic, including the data inputs and algorithmic factors that determined outcomes.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Microsoft RAI model/system cards and explainability supply meaningful-information content for Art 22 but not the explanation workflow, quality gate, or SLA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI system cards — model behavior transparency", "rationale": "OpenAI provides model cards documenting model capabilities, limitations, and intended use cases for its foundation models. Enterprise customers building automated decision systems on OpenAI APIs must implement their own explainability layer, but model cards provide the factual basis for documenting the algorithmic components underlying automated decisions in GDPR Art 22 explanations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI system cards give factual basis for documenting algorithmic components but the enterprise must build the explanation workflow itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "google_saif", "requirement_id": "Agent Observability", "rationale": "SAIF's Agent Observability control requires that AI and agent actions, tool use, and outputs are logged and auditable; that trail lets organizations reconstruct decision inputs and logic to provide the meaningful information required by GDPR Arts 13-15 and the safeguards of Art 22(3).", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "SAIF Agent Observability logs actions and tool use, providing the trail to reconstruct decision logic but not the explanation-delivery workflow DS-05 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "explainability", "fit": "supporting", "rationale": "DS-05 routes automated-decision explanation requests through a reviewer and DPO 'meaningful information' quality gate, delivering explanations of model decisions.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "corrective", "cross_domain": { "references": [ { "uri": "apeiris://ethics/controls/XP-01", "relationship": "related", "note": "Privacy domain owns the procedural obligation to respond and the SLA; the Ethics domain XP-layer owns explanation quality, method selection, fidelity, and adequacy." } ] }, "matrix_thesis": "The right to explanation for automated decisions exists at the intersection of two distinct obligations: the procedural duty to respond within a deadline (Privacy domain) and the substantive duty to provide a meaningful, faithful account of decision logic (Ethics domain). DS-05 owns the procedural half — intake routing, SLA tracking, quality gating, and delivery — while delegating method adequacy to Ethics XP-01, preventing both deadline breaches and hollow explanations that satisfy process but not purpose.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-05", "validation_objective": "The automated-decision explanation workflow routes every explanation request to a qualified model governance reviewer, applies a DPO quality gate confirming the response meets the 'meaningful information' standard, and delivers the approved explanation to the requestor within the applicable statutory SLA, with every state transition recorded in the DS-08 evidence log.", "evidence_required": [ "explanation_request_log showing request_id, intake_timestamp, request_type='automated-decision-explanation', jurisdiction, and routed_to identity for each request", "explanation_package containing logic_description, factors, and significance narrative with DPO quality_gate_outcome='approved', reviewer_identity, and xp01_referral_flag", "delivery_record showing delivery_timestamp within the statutory SLA deadline and requestor delivery_confirmation", "sla_compliance_report showing elapsed time from intake to delivery for each explanation-type DSAR, segmented by jurisdiction" ], "machine_tests": [ "Submit a test automated-decision explanation request via the DSAR portal → assert request is categorized as type='automated-decision-explanation' and routed to the model governance queue within one business day", "Inject a generated explanation without DPO quality-gate approval into the delivery pipeline → assert delivery is blocked and quality_gate_outcome='rejected' is logged", "Configure a test explanation request with the SLA deadline set to now+1s → assert SLA breach alert fires before the deadline and the breach is recorded in the evidence log" ], "human_review": [ "Review the explanation-generation procedure to confirm it produces logic, factors, and significance that satisfy the 'meaningful information' standard under GDPR Art 22(3) — not merely raw model feature importance scores", "Verify the DPO quality-gate process is documented with an escalation path to Ethics domain XP-01 for explanation method adequacy concerns and that the gate cannot be bypassed", "Assess the SLA configuration per jurisdiction to confirm it reflects the strictest applicable statutory deadline and that breach alerting is active for each configured jurisdiction" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Auto-delivering technically accurate model outputs (e.g., feature importance arrays) without DPO review, failing the 'meaningful information' standard under Art 22(3)", "Routing explanation requests through the general DSAR queue without a dedicated model-owner escalation path, causing SLA breaches due to lack of specialized handling", "Applying a single SLA deadline across all jurisdictions without configuring per-jurisdiction statutory deadlines, causing compliance gaps in stricter regimes", "Generating explanations post-hoc from model metadata rather than from a documented and repeatable explanation procedure, producing inconsistent outputs across requests", "Logging only the final delivery confirmation without capturing quality-gate outcome, leaving accountability gaps for DPO review steps on audit" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-06", "layer": "DS", "plane": "lifecycle", "name": "Portability and Interoperability", "plain": "Data subjects receive structured, machine-readable exports of personal data produced or inferred by AI systems in a commonly used format; interoperable transfer mechanisms are implemented.", "threat": { "tags": [ "non-machine-readable-format", "portability-blocked", "inferred-data-excluded-from-export" ], "desc": "Art 20 portability applies to data processed by automated means, which encompasses AI-generated profiles and inferred attributes. Formats limited to PDF or human-readable text do not satisfy the machine-readable requirement." }, "standard": [ { "id": "gdpr", "section": "Art 20", "title": "Right to data portability" }, { "id": "ccpa", "section": "§1798.130(a)(3)(B)(iii)", "title": "Portable and readily useable format requirement" }, { "id": "nist_pf", "section": "CT.DM-P6", "title": "Data are transmitted using standardized formats" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-06 Portability and Interoperability control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-06 Portability and Interoperability control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DS-06 Portability and Interoperability control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-06 Portability and Interoperability control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-06 Portability and Interoperability control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Build portability export pipelines that produce structured JSON or CSV packages covering all personal data including AI-inferred attributes, with a self-describing schema and a download or API transfer mechanism.", "steps": [ "Define the portability export schema covering all personal data categories including AI-inferred attributes, embedding representations where interpretable, and model-generated profiles.", "Implement an export pipeline that assembles the portability package from all registered personal data stores in JSON or CSV format with a machine-readable schema descriptor.", "Build a secure download or direct-transfer API endpoint for the requestor to receive the export, with access protected by the verified identity token from DS-02.", "Log portability export requests, package contents (schema version, data categories included), delivery method, and delivery confirmation in the DS-08 evidence log." ], "anti_patterns": [ "Delivering portability exports as PDF documents or human-readable HTML without a machine-parseable structured format.", "Excluding AI-inferred attributes and model-generated profiles from portability exports on the grounds that they are 'derived' rather than 'provided' data." ] }, "validation": { "design_check": [ "Confirm portability export schema is defined and includes AI-inferred attribute categories [ref:gdpr_2016_679]", "Verify export pipeline produces valid JSON or CSV with a machine-readable schema descriptor [ref:ccpa_cpra_2023]", "Confirm secure transfer mechanism is implemented and linked to verified identity from DS-02 [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit a test portability request for a subject with known AI-inferred attributes and verify export includes them.", "Parse the export package programmatically to confirm machine-readable format and schema validity.", "Verify delivery method is functional and download link or API endpoint is protected by identity verification." ], "evidence": [ "privacy:portability-package — Structured export package with schema descriptor and data category manifest [unverified]", "privacy:transfer-log — Log of portability export deliveries with format, data categories, and delivery timestamp [unverified]", "privacy:schema-registry — Published portability export schema version registry [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and maintain the portability export schema, pipeline, and transfer mechanism for personal data including AI-inferred attributes.", "actions": [ "Define and version-control the portability export schema, updating it when new personal data categories are added.", "Build export pipeline aligned with the fulfillment data-source registry to ensure AI-inferred data categories are included.", "Implement secure transfer endpoint with identity verification gate from DS-02." ], "failure_signals": [ "Portability export schema not versioned, making it impossible to verify schema at time of export.", "Export pipeline not covering AI-inferred attribute stores registered in the data-source registry.", "Transfer endpoint accessible without identity verification gate." ] }, "dpo": { "summary": "Own the regulatory position on which data categories are in scope for portability — including AI-inferred attributes — and govern the transfer mechanism standards.", "actions": [ "Publish the organization's portability scope policy confirming AI-inferred attributes are included under Art 20.", "Approve the portability export schema and review updates when new AI-processed data categories are introduced.", "Respond to portability requests that request direct transfer to a third-party controller and govern the authentication of the receiving controller." ], "failure_signals": [ "DPA complaint citing portability export that excluded AI-inferred attributes.", "Portability scope policy absent or not communicated to the engineering team.", "Direct-transfer requests handled without a governed authentication process for the receiving controller." ] }, "data_governance": { "summary": "Ensure all AI-inferred data categories are catalogued and mapped to the portability export schema.", "actions": [ "Require portability schema mapping as a mandatory attribute for all AI-inferred data categories in the data inventory.", "Govern schema updates and ensure they are reflected in the export pipeline before new data categories enter production.", "Track portability export coverage as a data governance metric across all registered personal data stores." ], "failure_signals": [ "AI-inferred data categories in production without a portability schema mapping.", "Schema updates approved in governance but not propagated to the export pipeline.", "Portability coverage below 100% of registered personal data stores with no documented exception." ] }, "grc_auditor": { "summary": "Verify portability export completeness, format compliance, and SLA adherence.", "actions": [ "Review portability scope against GDPR Art 20 and CCPA §1798.100(d) to confirm AI-inferred attributes are included.", "Parse sampled portability exports to confirm machine-readable format and schema validity.", "Verify SLA compliance for portability requests." ], "metrics": [ "Portability export completeness rate — exports covering all in-scope data categories (target: 100%)", "Machine-readable format compliance rate (target: 100%)" ], "failure_signals": [ "Sampled portability exports in PDF or non-machine-readable format.", "AI-inferred attributes absent from portability exports for subjects with known inference records.", "Portability SLA breach rate above 5%." ] }, "software_engineering": { "summary": "Build the portability export pipeline, schema generator, and secure transfer endpoint.", "actions": [ "Implement export pipeline with per-source data fetcher, schema-aligned transformer, and structured output formatter.", "Build schema descriptor generator that produces a machine-readable manifest of data categories and field definitions for each export.", "Implement secure download endpoint with signed URL expiry and identity token validation from DS-02." ], "failure_signals": [ "Export pipeline producing inconsistent output structures across runs for the same subject.", "Schema descriptor not included in export package, making the format self-describing requirement unmet.", "Download endpoint not enforcing signed URL expiry, allowing unauthorized access after delivery." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Portability implementations typically cover only directly provided data; AI-inferred attributes are rarely included." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "automated-decisions" ], "implementers": [ "Software Engineering", "Privacy Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 20", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 20 grants data subjects the right to receive personal data processed by automated means in a structured, commonly used, machine-readable format; this control implements the export pipeline and transfer mechanism required to satisfy that right.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.130(a)(3)(B)(iii)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "CCPA §1798.130(a)(3)(B)(iii) requires that personal information provided in response to a request to know be in a portable and, to the extent technically feasible, readily useable format allowing transmission to another entity; this control implements that export mechanism, though CCPA lacks GDPR Art 20's direct controller-to-controller transfer obligation.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P6", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "DS-06 implements NIST Privacy Framework CT.DM-P6 — data are transmitted using standardized formats — the portability-enabling subcategory, for AI-processed personal data.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI API — customer data export", "rationale": "OpenAI API customers can retrieve all data they have provided to OpenAI via API data controls. For GDPR Art 20 data portability obligations, enterprise API customers are responsible for implementing portability for their end-users' personal data held in the enterprise's own systems; OpenAI provides the mechanisms to export data relating to the API account relationship itself.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI exports data it holds; under split control the enterprise remains responsible for Art 20 portability of its end-users' data.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta Universal Directory — profile export APIs", "rationale": "Okta Universal Directory supports export of user profile data in standard machine-readable formats, supporting identity data portability for platform migrations and GDPR Art 20 portability rights. Scoped admin roles can be configured to export individual user profiles on request, providing a structured portability mechanism for identity-linked personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta profile export APIs deliver machine-readable identity data for Art 20, covering that slice but not AI-inferred attributes or model-generated profiles.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Portability for AI-processed personal data fails at the format boundary and the inference boundary: exports produced as PDFs don't satisfy Art 20, and exports that exclude AI-inferred profiles misread the scope of 'data processed by automated means.' DS-06 corrects both failures by mandating structured machine-readable exports with explicit schema descriptors and requiring AI-inferred attributes to be included in portability scope, producing exports that are genuinely re-usable rather than ceremonially compliant.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-06", "validation_objective": "The personal data portability pipeline produces a complete, machine-readable export package covering all personal data categories including AI-inferred attributes and model-generated profiles, delivers it to the authenticated requestor via a secure identity-verified mechanism within the statutory SLA, and records the export event with schema version and data categories in the DS-08 evidence log.", "evidence_required": [ "portability_export_package with schema_version, data_categories[] (including AI-inferred attributes and model-generated profiles), machine_readable_format (JSON/CSV), and a schema descriptor validated against the package contents", "export_delivery_record showing delivery_method, delivery_timestamp within SLA, identity_verification_token from DS-02, and requestor delivery_confirmation", "export_pipeline_run_log showing all personal data stores queried, any stores returning no data, and assembly completion status for each portability run", "ds08_evidence_entry capturing portability_request_id, schema_version, data_categories_included, delivery_method, and SLA_compliance_status" ], "machine_tests": [ "Submit a test portability request for a subject with known AI-inferred attributes → assert the export package includes those attributes in the defined schema and format with zero missing fields", "Attempt to access a portability export download endpoint without a valid DS-02 identity verification token → assert 401 response with error_code=identity_verification_required", "Parse the exported package programmatically against the schema descriptor → assert zero schema validation errors and all mandatory data category fields are present" ], "human_review": [ "Review the portability export schema to confirm it covers all AI-inferred attributes, interpretable embedding representations, and model-generated profiles — not solely raw input data fields", "Verify the secure delivery mechanism enforces the DS-02 identity verification step and does not expose export packages to unauthenticated or unverified requestors", "Confirm DS-08 evidence log entries for portability requests capture sufficient detail (schema version, data categories, delivery method) to demonstrate Art 20 compliance on regulatory audit" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Exporting only raw input data without including AI-inferred attributes, embeddings, or model-generated profiles, violating the completeness requirement of GDPR Art 20", "Delivering portability packages via unprotected download links that do not enforce the identity verification established in the DS-02 step", "Omitting the machine-readable schema descriptor from the export package, making the data unusable or uninterpretable by a receiving controller", "Silently excluding data stores labeled 'AI system internal' from the export scope without assessing whether they contain personal data subject to the portability right", "Failing to log the data categories included in each export, making it impossible to demonstrate scope completeness on audit" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-07", "layer": "DS", "plane": "lifecycle", "name": "Objection and Restriction Processing", "plain": "Opt-out mechanisms for automated decisions and profiling are implemented; objections and restrictions are processed by routing to human review with documented authority and defined response timelines.", "threat": { "tags": [ "no-opt-out-path", "objections-ignored", "automated-decisions-continue-after-valid-objection" ], "desc": "Art 21 objections to profiling or direct marketing are absolute rights. AI systems that continue processing after a valid objection — due to absence of a stop-processing workflow — commit a clear GDPR violation with significant enforcement history." }, "standard": [ { "id": "gdpr", "section": "Art 21", "title": "Right to object" }, { "id": "ccpa", "section": "§1798.120", "title": "Consumer right to opt out of sale and sharing" }, { "id": "uk_duaa", "section": "automated decision rights", "title": "UK automated decision objection rights" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-02" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-02" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DS-07 Objection and Restriction Processing control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement persistent opt-out and objection flags that propagate to all processing pipelines; route restriction requests to a human reviewer with documented authority and a defined response SLA.", "steps": [ "Implement a persistent objection/opt-out flag store keyed by data-subject identifier that is checked by all processing pipelines — including AI model inference, profiling jobs, and direct marketing — before any operation is performed.", "Build an objection intake workflow within the DSAR portal that routes to a human reviewer with documented authority to accept or contest the objection and logs the review decision.", "Implement automatic processing suspension on receipt of an objection — cease the objected-to processing immediately pending human review unless compelling legitimate grounds are documented within the response SLA.", "Propagate objection and restriction flags to all downstream processing systems within one hour of intake and log propagation confirmation." ], "anti_patterns": [ "Processing continuing uninterrupted after a valid Art 21 objection because no stop-processing workflow exists.", "Objection flags stored in a single system that is not checked by AI inference or profiling pipelines." ] }, "validation": { "design_check": [ "Confirm persistent objection flag store exists and is checked by all processing pipelines before operations [ref:gdpr_2016_679]", "Verify human reviewer role with documented authority is assigned in the objection workflow [ref:ccpa_cpra_2023]", "Confirm propagation mechanism distributes flags to all downstream systems within one hour [ref:uk_duaa_2025]" ], "runtime_test": [ "Submit a test objection for a subject and verify all processing pipelines cease within one hour.", "Verify that the objection flag propagates to AI inference endpoints and that inference is blocked for the test subject.", "Confirm human reviewer receives the objection routing notification within one business day." ], "evidence": [ "privacy:objection-log — Log of objection intake, processing suspension, and human review decisions [unverified]", "privacy:flag-propagation-log — Log of flag propagation events to all processing systems with timestamps [unverified]", "privacy:restriction-register — Register of active restrictions and their scope [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and operate the objection flag store, propagation mechanism, and processing pipeline integration points.", "actions": [ "Build objection flag store with per-subject, per-processing-purpose granularity and a read API available to all processing pipelines.", "Implement flag propagation service that pushes updates to all registered processing endpoints within one hour with logged confirmation.", "Integrate processing-pipeline pre-checks to query the flag store before each operation involving a data subject." ], "failure_signals": [ "Processing pipelines not checking the flag store before operations involving data subjects.", "Flag propagation service lacking registered processing endpoint coverage for AI inference pipelines.", "Flag store not supporting per-purpose granularity, causing over-blocking or under-blocking." ] }, "dpo": { "summary": "Own the objection response policy, govern compelling-legitimate-grounds documentation, and act as the authority for contested objections.", "actions": [ "Publish objection response policy specifying the human reviewer role, response SLA, and criteria for invoking compelling legitimate grounds.", "Act as decision authority for cases where the organization contests an objection on compelling legitimate grounds.", "Monitor objection response SLA compliance and investigate breaches." ], "failure_signals": [ "Objection response policy absent or not communicated to the human reviewer team.", "Processing not suspended pending human review in cases where compelling grounds are invoked without documented basis.", "DPA complaint citing continued processing after a valid Art 21 objection." ] }, "data_governance": { "summary": "Ensure all processing purposes and pipelines are registered so the objection propagation mechanism achieves complete coverage.", "actions": [ "Require all AI inference and profiling pipelines to be registered in the processing inventory with a flag-check integration status.", "Maintain processing inventory currency through the governance change-control process so new pipelines are registered before going live.", "Track flag-propagation coverage as a governance metric across all registered processing purposes." ], "failure_signals": [ "New AI processing pipeline deployed without registration in processing inventory, escaping flag-check integration.", "Processing inventory out of date, causing unknown gaps in propagation coverage.", "Flag-propagation coverage below 100% of registered processing purposes with no documented exception." ] }, "grc_auditor": { "summary": "Test that objections immediately suspend processing and that human review is conducted within the documented SLA.", "actions": [ "Submit test objections and measure time to processing suspension across all registered pipelines.", "Review objection log samples to confirm human review decisions are documented with authority and rationale.", "Verify that compelling-legitimate-grounds invocations have documented basis and DPO approval." ], "metrics": [ "Processing suspension rate within one hour of valid objection (target: 100%)", "Human review completion rate within response SLA (target: ≥95%)" ], "failure_signals": [ "Processing not suspended within one hour for any pipeline following a test objection.", "Human review not completed within the response SLA for sampled objections.", "Compelling-legitimate-grounds invocations without documented basis or DPO approval." ] }, "software_engineering": { "summary": "Implement the flag store read API, propagation service, and processing pipeline pre-checks.", "actions": [ "Build flag store as a low-latency read API (target p99 < 10ms) to minimize processing pipeline overhead.", "Implement propagation service as an event-driven fanout triggered by flag-store writes.", "Add pre-check middleware to all processing pipeline entry points that blocks execution if a matching objection flag is found." ], "failure_signals": [ "Flag store read API with high latency causing processing pipelines to skip the check for performance reasons.", "Propagation service not event-driven, relying on polling that creates a window where processing continues after objection.", "Pre-check middleware only applied to some processing pipeline entry points." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations lack persistent opt-out flags that propagate to AI inference pipelines; objection workflows often exist only for direct marketing." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "automated-decisions" ], "implementers": [ "Privacy Engineering", "DPO Office", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 21", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 21 grants the absolute right to object to processing for direct marketing including profiling; this control implements the suspension workflow and flag propagation infrastructure required to honor that right across all AI processing pipelines.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.120", "fit": "direct", "direction": "control-supports-requirement", "rationale": "CCPA §1798.120 grants consumers the right to opt out of the sale and sharing of personal information; this control implements the opt-out flag and propagation mechanism required to honor that right.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "automated decision rights", "fit": "partial", "direction": "control-supports-requirement", "rationale": "UK DUAA provides objection rights to automated decision-making; this control implements the processing suspension and human-review routing required but full alignment requires mapping to UK-specific divergences from EU GDPR Art 21.", "source_version": "2025 c.15", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "okta_iam", "requirement_id": "Okta Lifecycle Management — account suspension states", "rationale": "Okta's suspend lifecycle state halts processing of a user's data while maintaining the account record, directly implementing the GDPR Art 18 right to restriction. Suspended accounts retain their data in Universal Directory but are prevented from active use, allowing organizations to honor restriction requests while preserving data for the duration of any dispute or legitimate processing claim.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta's suspend state halts processing while keeping the record, implementing restriction for identity-linked processing but not inference/profiling suspension.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI enterprise data controls — business data not used for training by default", "rationale": "OpenAI's default configuration for enterprise and API customers is opt-out from model training and capability improvement. This means objection requests by end-users to secondary processing (training) are honored by default architecture, without requiring individual objection processing. Explicit objection to primary processing must still be handled by the enterprise controller through their own mechanisms.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI's default training opt-out honors objection to that secondary use by architecture, not the objection-processing and human-review workflow DS-07 needs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic zero data retention option", "rationale": "Anthropic's Zero Data Retention addendum enables organizations to restrict all data retention for API-layer personal data, supporting Art 18 right to restriction requests. By configuring ZDR, organizations can ensure that any personal data transmitted through the API is not retained by Anthropic beyond the immediate transaction, providing a structural restriction on downstream processing.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic ZDR structurally restricts API-layer retention, supporting Art 18 restriction but not the objection intake, suspension, and human-review workflow.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Objection rights fail silently when there is no propagation mechanism: the organization records the objection but the AI profiling pipeline that processes the data never checks for it. DS-07 eliminates this failure mode by requiring a persistent flag store checked by every processing pipeline before each operation, an automatic suspension on objection receipt, and a human-review routing path for contested cases — converting the right to object from a paper acknowledgement into an enforceable stop signal.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-07", "validation_objective": "On receipt of an objection or processing restriction request, all AI inference, profiling, and direct marketing pipelines for the identified data subject are suspended and the objection flag is propagated to all downstream processing systems within one hour of intake; the suspension persists until a human reviewer with documented authority records an acceptance or a formal contestation based on compelling legitimate grounds within the statutory response SLA.", "evidence_required": [ "objection_flag_propagation_log showing subject_id, objection_intake_timestamp, flag_set_timestamp, and list of processing_pipelines_notified with their acknowledgment timestamps — all within 3600 seconds of intake", "processing_suspension_audit_record confirming AI inference endpoints and profiling jobs returned no results for the objected subject after flag propagation, with query timestamps", "human_review_routing_record showing reviewer_id, reviewer_authority_level, routing_timestamp, review_decision, and documented rationale (compelling legitimate grounds or acceptance)", "objection_intake_record from DSAR portal with subject_id, request_timestamp, processing_scope_objected_to, and jurisdiction" ], "machine_tests": [ "Submit a test objection for a known subject and trigger an inference request for that subject within one hour → assert the inference endpoint returns processing_suspended status and generates no output", "Verify objection flag is present in all registered processing pipeline flag stores within 3600 seconds of intake → assert flag_propagation_lag <= 3600s for every registered pipeline", "Attempt to clear the objection flag programmatically without a recorded human reviewer decision → assert the operation is rejected with error_code=review_decision_required" ], "human_review": [ "Verify the objection intake workflow routes to a named reviewer with documented authority to assess compelling legitimate grounds, and that the reviewer identity and written decision are captured in the evidence log", "Assess the processing suspension scope to confirm it covers all AI pipelines including batch inference, background profiling jobs, third-party processors, and AI sub-processors — not only real-time inference", "Review the objection processing SLA configuration per jurisdiction to confirm breach alerting is active and that no automatic flag clearance occurs on SLA expiry without a reviewer decision" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Suspending visible real-time inference pipelines while continuing background batch profiling or analytics jobs that are not registered in the propagation scope", "Allowing objection flag propagation to complete over hours or days through asynchronous queues, leaving active processing windows unchecked after intake", "Routing objection decisions to general support staff without documented authority to assess 'compelling legitimate grounds,' invalidating the human review step under Art 21", "Automatically clearing the objection flag after the review SLA elapses without a documented reviewer decision, treating SLA breach as implicit acceptance of continued processing", "Propagating the objection flag to internal processing pipelines but not to downstream third-party processors or AI sub-processors receiving the subject's data" ], "update_status": "current", "layer_code": "DS" }, { "id": "DS-08", "layer": "DS", "plane": "lifecycle", "name": "Rights Request Evidence Log", "plain": "A tamper-evident log of all data subject rights requests captures every stage from receipt through resolution, including identity verification, processing decisions, response content, and SLA compliance metrics.", "threat": { "tags": [ "no-audit-trail", "inability-to-demonstrate-compliance", "disputed-decisions-without-documentation" ], "desc": "DPA enforcement actions frequently hinge on whether the controller can demonstrate the steps taken to respond to a rights request. Absence of a request log makes dispute resolution and regulatory examination impossible." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)", "title": "Accountability principle — demonstrating GDPR compliance" }, { "id": "iso_27701", "section": "7.3.9", "title": "Records of processing activities and rights request evidence" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records for rights-request processing" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-02" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/DS-08 Rights Request Evidence Log control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement an append-only, cryptographically integrity-protected log that captures every state transition in the DSAR lifecycle — from intake through identity verification, processing, quality review, delivery, and any regulatory follow-up.", "steps": [ "Deploy an append-only log store with write-once semantics and periodic integrity verification (cryptographic chaining or hash anchoring) that captures every state transition in the DSAR workflow.", "Define the log schema to capture: request ID, intake timestamp, channel, request type, jurisdiction, verification method and outcome, processing decisions with rationale, response content hash, delivery timestamp, SLA compliance status, and reviewer identity.", "Integrate all DS-layer workflow components (DS-01 through DS-07) with the evidence log as a shared event bus so every action generates an immutable log entry.", "Implement log retention policy aligned with the longest applicable statute of limitations (minimum 3 years post-resolution) with access controls restricting log modification to the append operation only." ], "anti_patterns": [ "Using mutable database tables as the DSAR log, allowing records to be updated or deleted to conceal processing failures.", "Logging only final outcomes without capturing intermediate state transitions, making it impossible to reconstruct the decision chain." ] }, "validation": { "design_check": [ "Confirm log store uses append-only write semantics with cryptographic integrity protection [ref:gdpr_2016_679]", "Verify log schema captures all required fields including intermediate state transitions [ref:iso_27701_2019]", "Confirm retention policy is set to minimum 3 years post-resolution with access controls preventing deletion [ref:nist_pf_1_0]" ], "runtime_test": [ "Attempt a log record update or deletion and verify the operation is rejected by the write-once enforcement.", "Submit a test DSAR end-to-end and verify the complete lifecycle is captured in the evidence log with all required fields.", "Run an integrity verification check on the log and confirm no gaps or chain breaks are detected." ], "evidence": [ "privacy:evidence-log — Append-only DSAR lifecycle log with cryptographic integrity verification [unverified]", "privacy:integrity-report — Periodic log integrity verification report with hash chain validation outcome [unverified]", "privacy:retention-policy — Documented log retention policy with access-control configuration [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design and operate the append-only evidence log infrastructure, integrity verification, and event-bus integration for all DS-layer workflow components.", "actions": [ "Implement append-only log store with cryptographic integrity chaining and periodic verification job.", "Define and enforce the log schema across all DS-layer event sources through a shared event schema registry.", "Build event-bus integration so every DS-layer workflow state transition automatically generates a log entry without manual intervention." ], "failure_signals": [ "Log store allowing record updates or deletions when tested.", "DS-layer workflow components generating events that do not appear in the evidence log within 60 seconds.", "Log integrity verification job not scheduled or failing without alert." ] }, "dpo": { "summary": "Own the evidence log policy, retention standards, and the use of the log in regulatory defence and DPA examination responses.", "actions": [ "Approve log schema and retention policy and review annually.", "Use the evidence log as the primary evidentiary basis when responding to DPA examination requests or data subject complaints.", "Review log completeness reports quarterly and investigate any gaps in DS-layer lifecycle coverage." ], "failure_signals": [ "DPA examination request cannot be satisfied because the evidence log is incomplete or has gaps.", "Log retention period shorter than the applicable statute of limitations.", "Log completeness report not reviewed quarterly, leaving coverage gaps undetected." ] }, "data_governance": { "summary": "Govern the log schema as an authoritative record-of-processing artifact and ensure it satisfies Art 30 ROPA requirements for DSAR activity.", "actions": [ "Include the DSAR evidence log in the Records of Processing Activities (ROPA) as a processing activity with documented retention and access controls.", "Require schema changes to go through governance change control before deployment.", "Track log coverage — percentage of DS-layer workflows integrated with the event bus — as a governance metric." ], "failure_signals": [ "DSAR evidence log not included in ROPA, exposing an accountability gap.", "Log schema changed without governance review, potentially introducing gaps in required fields.", "Log coverage below 100% of DS-layer workflows with no documented exception." ] }, "grc_auditor": { "summary": "Verify log integrity, completeness, and retention compliance; use the log as the primary evidence source for DSAR compliance audits.", "actions": [ "Run integrity verification on sampled log segments to confirm no tampering or chain breaks.", "Cross-reference sampled DSARs end-to-end against the evidence log to confirm all lifecycle stages are captured.", "Verify log retention configuration meets the minimum 3-year post-resolution standard." ], "metrics": [ "Log integrity verification pass rate (target: 100%)", "Log lifecycle coverage rate — DSARs with complete lifecycle captured from intake to resolution (target: 100%)" ], "failure_signals": [ "Integrity verification detecting chain breaks or missing entries for any sampled period.", "DSARs with missing intermediate state transitions in the evidence log.", "Log retention period below minimum standard or deletion possible within the retention window." ] }, "software_engineering": { "summary": "Implement the append-only log store, cryptographic integrity chaining, event bus integrations, and retention enforcement.", "actions": [ "Build append-only log store using write-once object storage or an immutable log service with hash-chain integrity.", "Implement integrity verification job that runs daily, validates chain continuity, and alerts on failures.", "Expose event-bus subscription API for DS-layer components to publish lifecycle events with schema validation at ingestion." ], "failure_signals": [ "Log store implementation using a mutable database table without write-once enforcement.", "Integrity verification job not running on schedule or alerts not firing on detected gaps.", "Event-bus ingestion not validating schema, allowing malformed events to enter the log without detection." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "DSAR logs are typically implemented as mutable database records without integrity protection or complete lifecycle coverage." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(2)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "GDPR Art 5(2) requires controllers to be able to demonstrate compliance with the data protection principles; an append-only evidence log of all rights request activity is the primary instrument for satisfying this accountability obligation.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "binding-law", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.3.9", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701 clause 7.3.9 requires records supporting the handling of data subject requests; this control implements the append-only log that satisfies that requirement with integrity protection.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "high", "legal_status": "certification-standard", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "NIST Privacy Framework CT.DM-P8 requires audit/log records determined, documented, implemented, and reviewed per policy; the rights-request evidence log is that record for DSAR processing.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "mapping_confidence": "medium", "legal_status": "voluntary-standard", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI privacy request records", "rationale": "OpenAI retains an audit record of data deletion and erasure requests even after the underlying personal data is deleted, to demonstrate compliance with the erasure request. This erasure audit trail is a model for enterprise rights request evidence logging: organizations should retain evidence of DSR receipt, identity verification, actions taken, and completion date, separate from the personal data itself.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's retained deletion-request records model the evidence approach but are the vendor's own log, not the enterprise's tamper-evident DSAR evidence log.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "okta_iam", "requirement_id": "Okta System Log — real-time audit events", "rationale": "Okta provides a comprehensive real-time audit log of all administrative actions including DSR-related operations—account access, data exports, account suspension, and deletion. These logs can be exported to SIEM systems for long-term evidence preservation, providing a verifiable, tamper-evident record of rights request fulfillment activities for supervisory authority investigations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta's tamper-evident System Log captures DSR-related admin actions and exports to SIEM, covering event capture but not the full append-only DSAR lifecycle log.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_privacy", "requirement_id": "AWS CloudTrail — API event logging", "rationale": "AWS CloudTrail records all API calls including data access, modification, and deletion events triggered by DSR fulfillment processes. Combined with S3 Object Lock for immutable log storage, CloudTrail provides a verifiable evidence log of all actions taken in fulfillment of rights requests, supporting GDPR accountability requirements for demonstrating compliance with Art 12-22 obligations.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail with S3 Object Lock immutably records DSR-fulfillment API events, giving the log substrate but not the full DSAR state-transition record.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Every other DS-layer control generates events that must be captured to be enforceable: without DS-08, the evidence that DS-01 through DS-07 operated correctly exists only in mutable operational databases that can be altered or destroyed. DS-08 is the accountability infrastructure that makes the entire DS layer defensible — an append-only, integrity-verified record that transforms DSAR workflow state transitions into regulatory-grade evidence, enabling both internal oversight and external examination.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DS-08", "validation_objective": "Every DSAR workflow state transition across all DS-layer controls is captured as an immutable, append-only log entry containing request_id, intake_timestamp, request_type, jurisdiction, verification outcome, processing decisions with rationale, response content hash, delivery timestamp, SLA compliance status, and reviewer identity; the log store enforces write-once semantics, and integrity verification confirms no chain breaks or gaps exist across the full retention window.", "evidence_required": [ "append_only_log_integrity_report showing cryptographic chain verification outcome, hash_anchor_timestamps, and confirmation that zero chain breaks or gaps were detected for the audit period", "log_schema_completeness_audit confirming all required fields (request_id, intake_timestamp, channel, request_type, jurisdiction, verification_method, verification_outcome, processing_decisions, response_content_hash, delivery_timestamp, sla_compliance_status, reviewer_identity) are present in all log entries", "write_protection_test_record documenting that attempted log modification and deletion operations via all available write paths were rejected by the write-once enforcement mechanism", "retention_policy_documentation confirming minimum 3-year post-resolution retention with access controls restricting modification to append operations only and log of policy enforcement" ], "machine_tests": [ "Attempt to update and to delete an existing log entry via all available write paths (API, direct storage access, admin console) → assert all attempts are rejected with write-once enforcement error and the attempt itself is logged", "Submit a complete DSAR lifecycle end-to-end and inspect the evidence log → assert all state transitions (intake, verification, decision, response generation, delivery) are captured with all required schema fields and no missing entries", "Run the log integrity verification check over the full retention window → assert zero chain breaks and zero missing hash anchors across all log partitions" ], "human_review": [ "Review the log schema against GDPR Art 5(2) accountability obligations to confirm it captures sufficient detail to demonstrate compliance across all DSAR request types, channels, and jurisdictions", "Verify the access control configuration restricts log modification to the append operation only and that no service account, administrator, or break-glass role holds delete or update permissions on the log store", "Assess the retention policy to confirm it aligns with the longest applicable statute of limitations across all jurisdictions in which personal data is processed, not the general data retention period" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Using a mutable relational database table as the evidence log without write-once enforcement, allowing log records to be modified or deleted post-hoc", "Storing only final DSAR outcomes in the log without capturing intermediate state transitions, making it impossible to reconstruct the full processing timeline on regulatory audit", "Logging the full content of explanation or portability response bodies without hashing, causing unbounded log growth and potential personal data exposure in audit exports", "Setting log retention to match the general personal data retention period rather than the longer accountability obligation period (minimum 3 years post-resolution under GDPR Art 5(2))", "Omitting reviewer identity from log entries for human review steps, creating accountability gaps that prevent attribution of DS-layer processing decisions on audit" ], "update_status": "current", "layer_code": "DS" }, { "id": "DP-01", "layer": "DP", "plane": "data", "name": "Encryption at Rest and in Transit", "plain": "Personal data in AI systems — training stores, inference inputs, model outputs, and telemetry — is encrypted at rest and in transit per the personal data classification, with key management separated from data.", "threat": { "tags": [ "unencrypted-personal-data", "key-management-failure", "training-data-exposed" ], "desc": "Art 32(1)(a) mandates encryption as an appropriate technical measure. Unencrypted personal data in AI training stores or inference pipelines represents a direct Art 32 failure that amplifies breach impact and creates regulatory liability." }, "standard": [ { "id": "gdpr", "section": "Art 32(1)(a)", "title": "Security of processing" }, { "id": "iso_27701", "section": "6.7", "title": "Cryptography (PII protection)" }, { "id": "nist_pf", "section": "PR.DS-P1/PR.DS-P2", "title": "Data-at-rest and data-in-transit are protected" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-01 Encryption at Rest and in Transit control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Classify all personal data by sensitivity tier and apply AES-256 encryption at rest and TLS 1.3 in transit across all AI system components, with encryption keys managed in a dedicated KMS separated from data stores.", "steps": [ "Inventory all AI system components that store or transmit personal data — training corpora, feature stores, inference endpoints, output caches, and telemetry pipelines", "Apply AES-256 encryption at rest to all identified stores and TLS 1.3 to all transmission paths, enforcing minimum cipher suites via infrastructure policy", "Provision a dedicated key management service with access logging; bind encryption keys to data classification level and enforce automated key rotation on schedule" ], "anti_patterns": [ "Storing encryption keys as environment variables or configuration files co-located in the same environment as the data they protect", "Exempting internal AI inference endpoints from TLS on the assumption that private network traffic is inherently trusted" ] }, "validation": { "design_check": [ "Confirm all personal data stores are inventoried and mapped to encryption control coverage [ref:iso_27701_2019]", "Verify key management service is deployed in a separate security boundary from all AI data stores [ref:gdpr_2016_679]", "Confirm infrastructure policy enforces TLS 1.3 minimum across all inference and data transmission paths [ref:nist_pf_1_0]" ], "runtime_test": [ "Scan all AI system storage volumes and object stores with an encryption compliance tool and report any unencrypted volumes", "Run TLS protocol analysis against all inference endpoints and internal service-to-service paths to verify cipher suite compliance", "Review KMS access logs to confirm key access is recorded with actor identity and timestamp for audit trail coverage" ], "evidence": [ "privacy:encryption-scan — Encryption coverage report across all training and inference storage volumes [unverified]", "privacy:tls-assessment — TLS protocol compliance scan results for all AI data transmission paths [unverified]", "privacy:key-management-audit — KMS configuration documentation and key rotation schedule verification [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "DP-01 is a foundational baseline control: no personal data store or transmission path in the AI system may be exempt from encryption, and key management must be logically and physically separated from data stores.", "actions": [ "Maintain an inventory of all AI system data stores mapped to personal data classification and encryption coverage status", "Enforce AES-256 at rest and TLS 1.3 in transit as non-negotiable baseline requirements in AI system design reviews", "Implement automated encryption compliance checks in CI/CD pipelines before deployment to any environment" ], "failure_signals": [ "Training corpora stored on unencrypted cloud object storage volumes", "Internal AI inference APIs communicating over plain HTTP within the service mesh", "Encryption keys co-located with the data they protect in the same storage account" ] }, "dpo": { "summary": "Art 32(1)(a) names encryption as a technical measure within 'appropriate security'; failure to encrypt personal data in AI systems is a directly auditable Art 32 gap that supervisory authorities may cite without needing to demonstrate actual harm to individuals.", "actions": [ "Document encryption coverage in Records of Processing Activities for all AI processing operations involving personal data", "Include encryption status in the technical measures section of DPIAs for each AI system processing personal data", "Ensure data breach response procedures record whether breached data was encrypted when assessing Art 33/34 notification thresholds" ], "failure_signals": [ "RoPA entries for AI systems listing no encryption measure in the security section", "DPIAs asserting encryption controls are in place without referencing a scan result or audit finding", "Breach notifications that cannot confirm the encryption status of accessed data at the time of the incident" ] }, "data_governance": { "summary": "Data governance must ensure encryption policies are mapped to data classification tiers and verified against all AI system data stores in the enterprise catalog before systems are approved for production use.", "actions": [ "Maintain a catalog entry for each AI training corpus and inference store that records encryption status, key management owner, and last verification date", "Establish a data classification policy that defines required encryption strength for each personal data sensitivity tier used in AI systems", "Include encryption coverage as a required gate in AI system onboarding intake and governance approval processes" ], "failure_signals": [ "Data catalog entries for AI datasets that lack encryption status and key management ownership fields", "AI systems approved for production without encryption review in the governance intake process", "Key management responsibilities not assigned to a named owner in system documentation" ] }, "grc_auditor": { "summary": "DP-01 maps directly to Art 32(1)(a) GDPR and ISO 27701 section 8.4.2; audit evidence must demonstrate encryption coverage across all in-scope AI data stores and transmission paths, not merely the existence of an encryption policy.", "actions": [ "Request encryption scan reports for all AI system data stores within the audit scope period", "Test a representative sample of inference endpoints to confirm TLS 1.3 minimum is enforced and legacy cipher suites are rejected", "Review KMS access logs and verify key rotation has occurred on the documented schedule" ], "metrics": [ "Percentage of AI system data stores with verified encryption at rest confirmed by automated scan", "Percentage of AI data transmission paths confirmed to enforce TLS 1.3 minimum by protocol analysis" ], "failure_signals": [ "Only policy documents presented as Art 32 evidence with no scan results or technical verification", "Inference endpoints found to accept TLS 1.2 or lower cipher suites during protocol testing", "Key rotation not occurring on the documented schedule per KMS audit log review" ] }, "software_engineering": { "summary": "Encryption at rest and in transit must be implemented at the infrastructure layer rather than in application code to ensure consistent, auditable coverage across all AI system components.", "actions": [ "Use cloud-provider managed encryption (AWS KMS, Azure Key Vault, GCP Cloud KMS) for all AI training and inference storage; never implement bespoke encryption in application code", "Enforce TLS 1.3 minimum at the API gateway and service mesh layer; configure infrastructure to reject plaintext connections regardless of caller origin", "Add encryption compliance assertions to infrastructure-as-code pipelines to catch misconfigured storage and network resources before deployment" ], "failure_signals": [ "Application-level encryption with keys stored as environment variables or Kubernetes secrets co-located with data", "AI microservices communicating over plain HTTP within the cluster or VPC", "IaC templates provisioning storage accounts or S3 buckets without encryption-at-rest enforced" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations apply encryption ad hoc to AI systems without a classification-based policy covering all training stores, inference endpoints, and telemetry pipelines." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Security Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 32(1)(a)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 32(1)(a) names encryption as an appropriate technical measure for security of processing; DP-01 operationalizes this requirement for all personal data stores and transmission paths in AI systems.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "6.7", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 6.7 extends ISO/IEC 27002 cryptography guidance to PII protection; DP-01 implements encryption of personal data at rest and in transit under that control family.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "PR.DS-P1/PR.DS-P2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DP-01 implements NIST Privacy Framework PR.DS-P1 and PR.DS-P2 — data-at-rest and data-in-transit are protected — with classification-based encryption enforcement scoped to all AI system personal data components.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Core element — Expand strong security foundations to the AI ecosystem", "rationale": "SAIF's first core element extends proven infrastructure security — including default encryption of data at rest and in transit — to AI systems; DP-01 applies that foundation to personal data in AI pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's security-foundations element endorses default encryption as a principle but does not implement the AES-256/TLS and key-logging controls DP-01 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS KMS and S3 server-side encryption — AES-256 at rest, TLS in transit", "rationale": "AWS Key Management Service (KMS) and S3 server-side encryption provide AES-256 encryption at rest for all AI training datasets and model artifacts stored in AWS. AWS Certificate Manager enforces TLS in transit for all AI service communications. Customer Managed Keys (CMK) via KMS enable organizations to control encryption key lifecycle aligned with data classification requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "direct", "fit_rationale": "AWS KMS and S3 SSE give AES-256 at rest, TLS in transit, and CMK with key-access logging, directly meeting DP-01's encryption and key management.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI security practices — AES-256 at rest, TLS 1.2+ in transit", "rationale": "OpenAI uses AES-256 encryption for all customer data at rest and TLS 1.2+ for all data in transit. Enterprise Key Management (EKM) allows enterprise customers to bring their own encryption keys for customer content stored at rest, providing an additional layer of cryptographic control aligned with data classification-based encryption requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI provides AES-256 at rest and TLS 1.2+ with customer-managed keys, meeting most of DP-01 but short of TLS 1.3 and explicit key-access logging.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Azure encryption — at rest and in transit", "rationale": "Azure AI services encrypt data at rest using AES-256 and require TLS 1.2+ for all data in transit. Azure Key Vault with Customer Managed Keys (CMK) is available for organizations requiring control over encryption key management for AI processing data, supporting classification-based encryption policy enforcement for personal data in AI pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Azure supplies AES-256 at rest, TLS 1.2+, and Key Vault CMK, covering most encryption but not the TLS 1.3 and key-access-logging specifics of DP-01.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "cross_domain": { "references": [ { "uri": "apeiris://security/controls/EC-01", "relationship": "related", "note": "Privacy domain defines which personal data requires encryption based on classification; the Security domain EC-layer enforces encryption implementation and key management." } ] }, "thesis_type": "preventive", "matrix_thesis": "Unencrypted personal data in AI systems is the most directly auditable Art 32 gap available to regulators; this control prevents that gap by making encryption a mandatory baseline before any AI processing begins. Separating key management from data stores ensures that a storage compromise does not simultaneously expose decryption capability.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-01", "validation_objective": "All personal data stores, object stores, training corpora, feature stores, output caches, and telemetry pipelines in the AI system apply AES-256 encryption at rest and TLS 1.3 with approved cipher suites for all transmission paths; a key management service logs every key access event with actor identity and timestamp; and no unencrypted storage volumes or non-compliant transmission paths exist in the verified inventory.", "evidence_required": [ "encryption_compliance_scan_report listing all AI system storage volumes and object stores with encryption_status (encrypted/unencrypted), algorithm, and key_id — confirming zero unencrypted volumes in scope", "tls_protocol_analysis_report for all inference endpoints and service-to-service paths showing negotiated_protocol_version, cipher_suites, and compliance_verdict for each path", "kms_access_log_sample showing key_id, actor_identity, access_timestamp, and operation_type for all encryption key operations during the audit period", "key_rotation_schedule_record showing key_id, last_rotated, next_rotation_due, and rotation_enforcement_policy for all personal-data encryption keys" ], "machine_tests": [ "Query all registered AI system storage volumes and object stores via infrastructure inventory API → assert encryption_status='encrypted' and algorithm='AES-256' for every entry with zero exceptions", "Run a TLS protocol scanner against each AI inference endpoint and internal service path → assert negotiated_protocol='TLS 1.3' and cipher_suite in approved_suite_list, fail on any path returning TLS 1.2 or weaker", "Attempt to provision a new personal data storage resource with encryption disabled → assert the infrastructure policy rejects the request with error_code=encryption_required and the attempt is logged" ], "human_review": [ "Review the personal data inventory against the encryption scope to confirm all AI system components storing or transmitting personal data are included — specifically telemetry pipelines, output caches, and debug log stores that may be overlooked", "Verify the KMS access logging configuration captures individual actor identity (not just service role) for all key access events and assess whether the log coverage is sufficient for forensic accountability", "Confirm the key rotation schedule reflects current best practice for each data classification level and that automated rotation is enforced by infrastructure policy rather than manual process" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Encrypting primary training data storage volumes while leaving telemetry pipelines, output caches, or debug log stores unencrypted because they are classified as 'operational data' rather than personal data", "Permitting TLS 1.2 as a compatibility fallback for legacy clients, leaving protocol downgrade attack paths open on AI inference endpoints", "Implementing envelope encryption with the data encryption key stored in the same storage system as the encrypted data, making the encryption ineffective against storage-layer compromise", "Logging only key creation and deletion events in the KMS without logging every key access operation, creating forensic gaps for incident investigations", "Applying application-layer encryption while leaving the underlying cloud storage volume unencrypted, relying on a single encryption layer without defense in depth" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-02", "layer": "DP", "plane": "data", "name": "Pseudonymization Implementation", "plain": "Pseudonymization is applied to personal data in AI training pipelines; the pseudonym-to-identity mapping is held under strict access control and validated so that pseudonymized data cannot be readily re-identified.", "threat": { "tags": [ "pseudonymization-reversible-without-key", "key-management-failure", "re-identification-via-auxiliary-data" ], "desc": "Pseudonymization that is trivially reversible — due to weak tokenization, key exposure, or combination with auxiliary data — provides no meaningful protection and cannot be claimed as a risk reduction measure under Art 25." }, "standard": [ { "id": "gdpr", "section": "Art 4(5) / Art 25", "title": "Pseudonymisation as privacy-by-design measure" }, { "id": "iso_27701", "section": "7.4.4", "title": "PII minimization objectives (de-identification mechanisms)" }, { "id": "eu_ai_act", "section": "Art 10(5)", "title": "Use of personal data for testing with pseudonymisation" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-02 Pseudonymization Implementation control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Apply cryptographic pseudonymization to direct identifiers in training data at ingestion time, store the mapping table in a separate access-controlled vault, and validate re-identification resistance against known auxiliary datasets before training begins.", "steps": [ "Identify all direct identifiers in each training dataset (name, NIN, email, device ID, account number) and define pseudonymization scope per data source", "Apply HMAC-based or cryptographic tokenization to direct identifiers at ingestion; store the pseudonym-to-identity mapping table in a dedicated vault with access limited to named data stewards", "Run a re-identification resistance assessment against available auxiliary datasets before training begins, document the result, and re-run after each significant training data refresh" ], "anti_patterns": [ "Using sequential integer IDs or deterministic hashes without a secret key as pseudonyms, which are trivially reversible given the source data", "Storing the pseudonym mapping table in the same database or storage account as the pseudonymized training data itself" ] }, "validation": { "design_check": [ "Confirm pseudonymization scope document identifies all direct identifiers for each training dataset [ref:gdpr_2016_679]", "Verify pseudonym mapping vault is stored separately from all training data stores with access limited to named stewards [ref:iso_27701_2019]", "Confirm re-identification resistance assessment methodology is documented and scheduled to run before each training run [ref:eu_ai_act_2024]" ], "runtime_test": [ "Attempt re-identification of a pseudonymized training sample using available auxiliary datasets and record success rate", "Audit vault access logs to confirm that no unauthorized access to the pseudonym mapping table has occurred", "Verify that pseudonymization is applied at ingestion before data enters any AI pipeline component by tracing a sample record through the pipeline" ], "evidence": [ "privacy:pseudonymization-assessment — Re-identification resistance test results for each training dataset before training [unverified]", "privacy:vault-access-log — Access log for pseudonym mapping vault covering the training period [unverified]", "privacy:pipeline-audit — Data flow trace confirming pseudonymization applied at ingestion prior to downstream pipeline stages [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Pseudonymization must be implemented at ingestion, not as an afterthought, using cryptographic techniques with a secret key; the mapping table is a high-value asset requiring its own access control and audit trail.", "actions": [ "Define pseudonymization scope for each training dataset and document which direct identifiers are covered", "Implement HMAC-SHA256 or AES-SIV tokenization with a rotating secret key rather than deterministic hash-based approaches", "Schedule and document re-identification resistance assessments as a mandatory gate before each major training run" ], "failure_signals": [ "Pseudonymization implemented using MD5 or SHA-256 of raw identifiers without a secret key component", "Pseudonym mapping table stored in the same data warehouse as training data", "No documented re-identification resistance assessment in the model training record" ] }, "dpo": { "summary": "Art 25 cites pseudonymization as a privacy-by-design measure; however, weak pseudonymization that is readily reversible does not qualify as a risk reduction under Art 25 and cannot be cited in DPIAs as a control that reduces residual risk.", "actions": [ "Review DPIA technical measures sections to ensure pseudonymization claims reference a validated implementation, not merely a policy commitment", "Confirm that the data steward responsible for the pseudonym mapping vault is named in relevant DPIAs and RoPA entries", "Verify that AI Act Art 10(5) pseudonymization requirements are assessed for any high-risk AI training datasets" ], "failure_signals": [ "DPIAs claiming pseudonymization as a risk reduction measure without referencing a specific implementation or validation result", "No named data steward with access to the pseudonym mapping table identified in RoPA or DPIA documentation", "Art 10(5) EU AI Act pseudonymization requirements not assessed for high-risk AI system training data" ] }, "data_governance": { "summary": "Data governance must ensure pseudonymization scope is defined per dataset, mapping tables are catalogued as sensitive assets, and re-identification resistance results are recorded in the AI system's data provenance record.", "actions": [ "Catalog pseudonym mapping tables as high-sensitivity data assets with explicit ownership and access policy", "Require re-identification resistance assessment results to be submitted as part of the AI system data provenance record before production approval", "Track pseudonymization coverage per training dataset in the enterprise data catalog, noting which identifier types are and are not covered" ], "failure_signals": [ "Pseudonym mapping tables absent from the enterprise data catalog or not classified as high-sensitivity assets", "AI systems approved for production without a re-identification resistance result in their data provenance record", "Training datasets with partial pseudonymization coverage lacking documentation of uncovered identifiers and residual risk" ] }, "grc_auditor": { "summary": "Audit evidence for DP-02 must demonstrate that pseudonymization is technically robust — not just applied — including re-identification resistance results, vault access logs, and confirmation that the mapping table is access-controlled separately from training data.", "actions": [ "Request re-identification resistance assessment reports for all in-scope training datasets", "Review vault access logs to confirm the pseudonym mapping table is accessed only by authorized stewards", "Test a sample of pseudonymized records to confirm they cannot be reversed without vault access" ], "metrics": [ "Percentage of training datasets with a documented re-identification resistance assessment on file", "Number of unauthorized access attempts to pseudonym mapping vault detected in audit period" ], "failure_signals": [ "Re-identification resistance assessment absent for any production training dataset", "Pseudonym mapping table accessible to ML engineering teams with no access logging", "Sequential integer pseudonyms used in place of cryptographic tokenization" ] }, "software_engineering": { "summary": "Pseudonymization must be a pipeline stage — not an optional transform — implemented with a secret-keyed cryptographic primitive and integrated into the data ingestion path before any downstream AI components see direct identifiers.", "actions": [ "Implement pseudonymization as the first transform in the data ingestion pipeline using HMAC-SHA256 with a KMS-managed key", "Ensure the pseudonym mapping table is written only to the dedicated vault; no downstream pipeline component should receive or log direct identifiers", "Add an automated pre-training gate that verifies pseudonymization has been applied to all records in the training batch before the training job starts" ], "failure_signals": [ "Direct identifiers visible in feature store or model training logs", "Pseudonymization applied as a post-processing step rather than at ingestion", "No pipeline gate preventing training from proceeding with un-pseudonymized data" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Organizations frequently apply pseudonymization inconsistently across training datasets with no re-identification resistance validation, making Art 25 risk reduction claims unverifiable." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Security Engineering", "ML Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 25", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 25 identifies pseudonymization as a privacy-by-design measure; DP-02 operationalizes this with cryptographic tokenization and separated mapping table governance for AI training pipelines.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.4.4", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 7.4.4 requires defining PII minimization objectives and the mechanisms — such as de-identification and pseudonymization — used to meet them; DP-02 implements pseudonymization as that documented mechanism.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art 10(5)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art 10(5) permits use of personal data for bias testing under pseudonymization; DP-02 provides the governance framework to implement compliant pseudonymization for such use cases.", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Google Cloud Sensitive Data Protection — pseudonymization and de-identification", "rationale": "Google Cloud's Sensitive Data Protection provides format-preserving encryption (FPE), deterministic pseudonymization, tokenization, and masking for personal data in AI pipelines. These de-identification techniques can be applied programmatically to training datasets and inference inputs, creating pseudonymized data that retains analytical utility while reducing re-identification risk.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Cloud DLP provides tokenization and pseudonymization for training data, covering the transform but not the vaulted mapping control or re-identification test.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Glue DataBrew — PII masking and redaction transformations", "rationale": "AWS Glue DataBrew provides field-level data masking, substitution, and hashing operations that implement pseudonymization for AI training datasets. AWS documentation recommends pseudonymization as a privacy-by-design technique for reducing the risk of personal data exposure in AI training corpora, with DataBrew transformations applicable as pipeline preprocessing steps.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Glue DataBrew's field masking, substitution, and hashing implement the pseudonymization transform but not the vaulted mapping or re-identification test.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Information Protection — classification and protection of personal data", "rationale": "Microsoft Purview Information Protection classifies and labels personal data across the data estate and applies protection policies; DP-02 uses such classification hooks to route personal data through pseudonymization before AI processing.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Purview Information Protection classifies and labels personal data to route it, an upstream hook that enables but does not perform pseudonymization.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "obfuscatetrainingdata", "fit": "direct", "rationale": "DP-02 replaces all direct identifiers in training datasets with cryptographic tokens at the ingestion boundary and assesses re-identification resistance, directly obfuscating training data to protect privacy.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Pseudonymization is only a meaningful privacy-by-design measure when the pseudonym-to-identity mapping is cryptographically protected and access-controlled independently of training data; without re-identification resistance validation, pseudonymization claims cannot be asserted in DPIAs or Art 25 compliance records. This control makes that validation a required gate in the AI training lifecycle.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-02", "validation_objective": "All direct identifiers (name, national identity number, email address, device ID, account number) in AI training datasets are replaced with cryptographic tokens at the ingestion boundary before data enters any downstream pipeline component; the pseudonym-to-identity mapping table is stored in a dedicated vault accessible only to named data stewards; and a re-identification resistance assessment against available auxiliary datasets documents residual risk and is dated before each training run begins.", "evidence_required": [ "pseudonymization_pipeline_trace for a sample of records showing direct identifiers replaced with token_id at the ingestion timestamp, with confirmation that no downstream pipeline component received any direct identifier", "vault_access_log for the pseudonym mapping table covering the audit period, showing accessor_identity, access_timestamp, operation (read/write), and authorization_basis — with no entries for unauthorized principals", "reidentification_resistance_assessment_report showing auxiliary_datasets_tested, re-identification_success_rate, assessment_methodology, risk_verdict (acceptable/unacceptable), and assessment_date predating the training run", "pseudonymization_scope_definition per data source listing all direct_identifiers in scope, the tokenization_method applied, and the secret_key_reference" ], "machine_tests": [ "Trace a sample training record through the full ingestion pipeline and inspect the record state at each pipeline stage → assert no direct identifiers (name, email, NIN, device_id, account_number) are present in any post-ingestion pipeline component", "Attempt to access the pseudonym mapping vault as a service account not on the authorized data steward list → assert access is denied with error_code=unauthorized and the attempt is recorded in the vault access log", "Present a pseudonymized training sample to a re-identification test harness using all known auxiliary datasets → assert the re-identification success rate is below the documented acceptable threshold" ], "human_review": [ "Review the pseudonymization scope definition for each data source to confirm all direct identifiers are captured and that no quasi-identifier combinations are omitted that could enable re-identification in combination", "Assess the vault access control configuration to verify access is genuinely restricted to named data stewards and that no standing access exists for AI pipeline service accounts or general engineering roles", "Evaluate the re-identification resistance assessment methodology to confirm it tests against all realistic auxiliary datasets available to potential adversaries — not only internal benchmark sets" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Applying pseudonymization only to names and national identity numbers while leaving email addresses, device IDs, or account numbers as cleartext in training data", "Storing the pseudonym-to-identity mapping table in the same data store or repository as the pseudonymized training corpus, making re-identification trivial on storage compromise", "Running pseudonymization as a post-ingestion transform rather than at the ingestion boundary, leaving a window where direct identifiers exist inside pipeline components", "Using deterministic hashing without a secret key (e.g., SHA-256 of email address), allowing re-identification via rainbow table lookups against known identifier lists", "Skipping the re-identification resistance assessment for incremental training data refreshes, assuming the prior assessment remains valid when the auxiliary dataset landscape has changed" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-03", "layer": "DP", "plane": "data", "name": "Data Minimization Enforcement", "plain": "Technical controls reject collection of personal data beyond what is strictly necessary for the stated AI purpose and purge unnecessary personal data from training corpora at ingestion.", "threat": { "tags": [ "over-collection", "unnecessary-retention", "training-on-excess-personal-data" ], "desc": "AI models trained on maximally available data — without purpose-scope filtering — violate Art 5(1)(c) data minimization even where each individual field had a separate lawful basis. Collection excess at training time cannot be remedied after training." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(c) / Art 25(2)", "title": "Data minimisation by design and default" }, { "id": "nist_pf", "section": "CT.DP-P1", "title": "Data processed to limit observability and linkability" }, { "id": "iso_27701", "section": "7.4.1", "title": "Limit of collection of personal information" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DP-03 Data Minimization Enforcement control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a purpose specification for each AI training task that enumerates required features; implement schema-level validation at ingestion that rejects fields outside the specification, and run automated corpus scans to identify and purge unnecessary personal data fields before training.", "steps": [ "For each AI training task, produce a purpose specification that enumerates the personal data fields strictly required and excludes all others", "Implement ingestion-layer schema validation that rejects or strips personal data fields not listed in the purpose specification before data enters the training pipeline", "Run an automated corpus scan before each training run to detect personal data fields that were collected but are not in the active purpose specification, and purge them with a documented justification" ], "anti_patterns": [ "Ingesting full database exports into training pipelines and relying on feature selection during model training to avoid using unnecessary fields", "Treating 'we had a lawful basis for each field' as sufficient justification for including all available personal data in a training corpus" ] }, "validation": { "design_check": [ "Confirm a purpose specification exists for each AI training task enumerating required personal data fields [ref:gdpr_2016_679]", "Verify ingestion-layer schema validation is active and rejecting fields outside the purpose specification [ref:nist_pf_1_0]", "Confirm automated corpus scan is scheduled before each training run and produces a purge log [ref:iso_27701_2019]" ], "runtime_test": [ "Inject a test record containing a personal data field not in the purpose specification into the ingestion pipeline and confirm it is rejected or stripped", "Inspect the training corpus for the presence of personal data fields not listed in the current purpose specification using a data profiling tool", "Review the corpus scan purge log for the most recent training run and confirm all purged fields are documented with justification" ], "evidence": [ "privacy:purpose-specification — Purpose specification document enumerating required personal data fields per AI training task [unverified]", "privacy:ingestion-validation-log — Ingestion schema validation report showing rejected personal data fields for the training period [unverified]", "privacy:corpus-scan-report — Automated corpus scan and purge log from the most recent training run [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Data minimization must be enforced at the ingestion layer before personal data enters the training pipeline; purpose specifications must be authored by privacy engineers in collaboration with ML teams before data collection begins, not after.", "actions": [ "Author a purpose specification for every new AI training task before data collection is scoped or contracted", "Implement schema-level ingestion validation as a pipeline gate that treats excess personal data fields as an error, not a warning", "Maintain a corpus audit report for each training run documenting which personal data fields were present, used, and purged" ], "failure_signals": [ "No purpose specification on file for any production training dataset", "Ingestion pipelines that accept and store any field present in the source data without schema validation", "Training corpora containing personal data fields not referenced in any feature in the trained model" ] }, "dpo": { "summary": "Art 5(1)(c) and Art 25(2) require data minimization by default; this means the minimum personal data necessary for the AI purpose must be collected, and a DPO must confirm that purpose specifications are reviewed and approved before training data is sourced.", "actions": [ "Review and approve purpose specifications for AI training tasks as part of the DPIA process before data sourcing begins", "Include data minimization enforcement evidence in DPIA technical measures sections — not just policy commitments", "Track Art 25(2) compliance for each AI system in the RoPA, noting the personal data fields in scope and the enforcement mechanism" ], "failure_signals": [ "DPIAs for AI systems that do not include a purpose specification or field-level minimization analysis", "Training datasets sourced before a purpose specification was reviewed by the DPO", "RoPA entries for AI processing that list personal data categories at a generic level without field-level detail" ] }, "data_governance": { "summary": "Data governance owns the requirement that training datasets are sourced against a purpose specification; minimization is a data procurement constraint, not just a technical pipeline control.", "actions": [ "Require a signed purpose specification as a mandatory input to any data sourcing request for AI training datasets", "Track field-level personal data scope in the enterprise data catalog for all AI training datasets", "Implement a periodic catalog review to identify training datasets that contain personal data fields no longer referenced by any active model" ], "failure_signals": [ "Data sourcing requests approved without a purpose specification on file", "Training datasets catalogued at dataset level with no field-level personal data inventory", "No catalog review process to identify orphaned personal data fields in legacy training datasets" ] }, "grc_auditor": { "summary": "Audit evidence for DP-03 must demonstrate that personal data fields in training corpora are restricted to those with a documented purpose, with ingestion validation logs and corpus scan reports as primary evidence.", "actions": [ "Request purpose specifications and compare listed fields against the actual personal data fields present in training datasets", "Review ingestion validation logs to confirm schema enforcement is active and has rejected or stripped excess fields", "Inspect corpus scan purge logs for each training run in the audit period" ], "metrics": [ "Percentage of AI training tasks with an approved purpose specification on file before data sourcing", "Number of excess personal data fields detected and purged by corpus scans in the audit period" ], "failure_signals": [ "Training datasets containing personal data fields not in any purpose specification on file", "Ingestion validation logs absent or showing no rejections despite broad-scope source data", "Corpus scans not scheduled or not producing purge logs" ] }, "software_engineering": { "summary": "Data minimization must be enforced as a hard constraint in the ingestion pipeline — not a soft guideline — using schema validation that treats excess personal data fields as an error condition that blocks downstream processing.", "actions": [ "Implement ingestion pipeline schema validation using the purpose specification as the schema definition; treat extra fields as a pipeline error that triggers an alert and stops ingestion", "Integrate a data profiling tool into the pre-training pipeline stage that generates a field-level inventory and flags any personal data not in the purpose specification", "Build corpus purge automation that removes out-of-scope personal data fields and emits a structured purge log for each training run" ], "failure_signals": [ "Ingestion pipelines with no schema validation layer — any field in the source is accepted and stored", "Personal data profiling absent from the pre-training pipeline; no automated way to detect excess fields", "Purge operations performed manually with no structured log output" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI training pipelines rarely have purpose specifications or ingestion schema validation; data minimization is asserted in DPIAs but not enforced at the technical layer." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "ML Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(c)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 5(1)(c) requires personal data to be adequate, relevant, and limited to what is necessary; DP-03 enforces this at the ingestion layer through purpose specifications and schema validation.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DP-P1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "DP-03 aligns with NIST Privacy Framework CT.DP-P1 — data are processed to limit observability and linkability — the disassociated-processing category that operationalizes the data minimization principle for AI corpora.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27701", "requirement_id": "7.4.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO 27701 section 7.4.1 requires limiting collection of personal information to what is necessary; DP-03 extends this to AI training pipeline ingestion through purpose-specification-driven schema enforcement.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "User Data Management — mitigates Excessive Data Handling", "rationale": "SAIF's User Data Management control mitigates the Excessive Data Handling risk by requiring that user data is collected, used, and retained only as appropriate for the intended purpose; DP-03's ingestion controls and corpus scanning enforce the same minimization for AI training and inference.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF User Data Management curbs excessive data handling via purpose-scoped collection, aligning with minimization but not the ingestion gate and corpus purge.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Lake Formation §Column/Row-Level Security for Minimization", "rationale": "AWS Lake Formation enforces data minimization at query time through column masking and row-level filtering policies. These controls limit AI workload access to only the specific data attributes required for the documented processing purpose, implementing technical data minimization without requiring physical data separation or duplication of datasets.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Lake Formation column/row security minimizes AI access to needed fields at query time but does not reject over-collection or purge corpora at ingestion.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic API data retention defaults", "rationale": "Anthropic's default 7-day API log retention and ZDR option reflect a data minimization architecture: inference data is retained only for the minimum period required for operational purposes (abuse detection) and then automatically deleted. Enterprise customers should align their own data minimization policies with these upstream retention defaults when designing AI data flows.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic's short-retention defaults reflect retention minimization, a different facet than DP-03's collection-scope enforcement and ingestion purge.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — Privacy & Security goals", "rationale": "Microsoft's Responsible AI Standard includes data minimization as a core privacy engineering requirement. The standard mandates that Azure AI systems be designed to collect and process only data necessary for the stated purpose, with minimization requirements documented in privacy impact assessments and enforced through technical controls in the AI development lifecycle.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Microsoft RAI Standard mandates collecting only necessary data, stating the minimization requirement but not DP-03's ingestion validation and purge.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "dataminimize", "fit": "direct", "rationale": "DP-03 validates every training record against an approved purpose specification and purges undeclared personal-data fields before training, directly minimizing sensitive data used.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Collection excess at training time is irreversible — once a model is trained on unnecessary personal data, the privacy violation is baked in and cannot be remediated without retraining. This control enforces minimization as a pipeline gate before training begins, making Art 5(1)(c) compliance verifiable rather than asserted.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-03", "validation_objective": "For every AI training task, a purpose specification enumerating the personal data fields strictly required is documented and approved before training begins; the ingestion pipeline validates each incoming record against the active purpose specification and rejects or strips any personal data field not listed; and an automated corpus scan before each training run detects and purges all undeclared personal data fields with a documented justification for each purge action.", "evidence_required": [ "purpose_specification_document per training task listing approved_personal_data_fields[], purpose_statement, approver_identity, and approval_timestamp — with timestamp predating the training run start", "ingestion_pipeline_rejection_log showing rejected_or_stripped_records with field_name, reason='not-in-purpose-specification', and event_timestamp for each enforcement action", "corpus_scan_report for the most recent training run listing all personal data fields detected, their presence_status (in-specification/out-of-specification), and purge_records with justification for each out-of-specification field", "schema_validation_configuration_snapshot showing the active purpose specification schema version loaded in the ingestion pipeline at the time of the training run" ], "machine_tests": [ "Inject a test ingestion record containing a personal data field (e.g., 'date_of_birth') not listed in the active purpose specification → assert the field is rejected or stripped and the event is logged with reason='not-in-purpose-specification'", "Run the corpus profiling tool against a test dataset seeded with one undeclared personal data field → assert the tool detects the field and generates a purge recommendation with a justification requirement flag", "Attempt to start a training pipeline run without a signed, current purpose specification document loaded → assert the pipeline returns error_code=missing_purpose_specification and blocks ingestion from proceeding" ], "human_review": [ "Review each purpose specification to confirm the approved personal data field list is strictly limited to fields necessary for the stated training objective — not a broad default list carried over from prior tasks without reassessment", "Assess the corpus scan purge log for the most recent training run to verify all purged fields have documented justification and that no fields were silently dropped without a recorded rationale", "Verify the schema validation configuration is updated and reapproved before each new training task and that an outdated or prior-task purpose specification cannot be applied to a new training run without a formal reapproval step" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Producing a single broad purpose specification listing all available personal data fields 'for flexibility,' rather than a per-task specification strictly limited to necessary fields", "Running the corpus scan after the training pipeline has already ingested the data, rather than before ingestion begins, allowing undeclared fields to enter the training process before detection", "Treating ingestion schema validation as a warning rather than a hard rejection, logging violations but allowing the pipeline to continue processing with undeclared personal data fields", "Carrying forward the prior training task's purpose specification to a new training run without a formal reapproval step, enabling scope creep as new data sources are added", "Purging out-of-specification fields without generating a per-field justification record, creating accountability gaps that prevent demonstrating data minimization compliance under GDPR Art 5(2)" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-04", "layer": "DP", "plane": "data", "name": "Inference Scope Limitation", "plain": "The scope of inferences an AI system may draw about individuals is defined and enforced; derived personal data — including inferred sensitive attributes — is classified and governed with the same obligations as collected data.", "threat": { "tags": [ "unsanctioned-individual-inference", "special-category-inference-from-innocuous-data", "inference-creep" ], "desc": "AI systems can infer health status, political opinion, or financial situation from inputs that are not themselves special category data. EDPB Opinion 28/2024 clarifies that inferred personal data is personal data carrying the same obligations as collected data." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(b)", "title": "Purpose limitation applied to inferred data" }, { "id": "edpb_opinion_28_2024", "section": "inferred data §3", "title": "Inferred personal data legal status" }, { "id": "nist_pf", "section": "CT.DP-P3", "title": "Data processed to limit the formulation of inferences" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-04 Inference Scope Limitation control.", "reviewed_on": "2026-07-01" }, { "id": "edpb_opinion_28_2024", "title": "EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models", "authority": "European Data Protection Board", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "28/2024", "published_on": "2024-12-17", "retrieved_on": "2026-06-28", "canonical_url": "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "edpb_opinion_28_2024", "relationship": "supporting_guidance", "rationale": "Establishes EDPB Opinion 28/2024 — Data Protection Aspects Related to AI Models requirements informing the apeiris://privacy/controls/DP-04 Inference Scope Limitation control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-04 Inference Scope Limitation control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DP-04 Inference Scope Limitation control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-04 Inference Scope Limitation control.", "reviewed_on": "2026-07-01" } ], "implementation": { "pattern": "Define an inference scope specification for each AI system that enumerates permitted inferences about individuals; classify all derived outputs as personal data, apply Art 9 controls where inferred attributes are special-category, and enforce the scope at the model output layer.", "steps": [ "Produce an inference scope specification for each AI system that enumerates what the system is permitted to infer about individuals and what is explicitly out of scope", "Classify all inferred outputs as personal data and apply the same classification, access control, and retention rules as collected personal data of the same sensitivity tier", "Implement an output-layer classifier that detects inferences outside the permitted scope and either suppresses or flags them for review before the output is delivered to consumers" ], "anti_patterns": [ "Treating model outputs as non-personal data because the inputs were non-personal or anonymized, without validating that no individual-level inferences are produced", "Allowing inferred outputs to be used in downstream systems without classifying them and applying appropriate access controls" ] }, "validation": { "design_check": [ "Confirm an inference scope specification exists for each AI system and is reviewed before deployment [ref:gdpr_2016_679]", "Verify inferred outputs are classified as personal data and subject to access controls commensurate with their sensitivity [ref:edpb_opinion_28_2024]", "Confirm an output-layer scope enforcement mechanism is in place and tested against out-of-scope inference examples [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit adversarial inputs designed to elicit special-category inferences (health, political opinion) and confirm the output classifier suppresses or flags them", "Inspect inferred output data flows to confirm they are routed through the same access control and audit logging infrastructure as collected personal data", "Review inference scope specifications against the live model's output profile to detect inference scope creep since last specification review" ], "evidence": [ "privacy:inference-scope-spec — Inference scope specification document for each AI system in scope, reviewed before deployment [unverified]", "privacy:output-classifier-test — Results of adversarial output testing against the inference scope enforcement classifier [unverified]", "privacy:inferred-data-classification — Evidence that inferred outputs are classified and access-controlled as personal data [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Inference scope limitation requires upstream design work: privacy engineers must define what inferences are permitted before a model is trained, and must implement enforcement at the output layer so that scope creep is detected at runtime.", "actions": [ "Author an inference scope specification for every AI system at design time, in collaboration with the business owner and DPO", "Implement an output-layer classifier trained to detect inferences outside the permitted scope and alert or suppress accordingly", "Re-run the inference scope assessment after each model update to detect scope drift introduced by fine-tuning or architecture changes" ], "failure_signals": [ "AI systems deployed with no inference scope specification on file", "Inferred outputs flowing to downstream systems without personal data classification applied", "No output classifier or scope enforcement mechanism in place" ] }, "dpo": { "summary": "EDPB Opinion 28/2024 §3 confirms that inferred personal data is personal data subject to full GDPR obligations; DPOs must confirm that DPIAs cover inferred outputs and that Art 9 controls are applied where inferred attributes fall into special-category territory.", "actions": [ "Require inference scope specifications to be submitted as part of the DPIA process for every AI system that produces individual-level outputs", "Assess whether any permitted inferences produce outputs that qualify as Art 9 special-category data and apply appropriate controls", "Ensure the RoPA records inferred data categories separately from collected data categories for each AI processing operation" ], "failure_signals": [ "DPIAs that assess only collected data and do not address inferred outputs as personal data", "AI systems producing inferred health or political outputs without Art 9 lawful basis documented in the DPIA", "RoPA entries that list input data categories but not inferred output data categories" ] }, "data_governance": { "summary": "Data governance must ensure inferred outputs are catalogued as derived personal data, with lineage tracked back to the source data and inference scope specification, enabling downstream consumers to understand the data's provenance and obligations.", "actions": [ "Catalog all inferred output schemas as derived personal data assets with lineage linking to source datasets and inference scope specifications", "Require downstream data consumers to acknowledge inferred data classification and obligations before access is granted", "Implement periodic catalog reviews to identify inferred output data that is stored beyond its retention period" ], "failure_signals": [ "Inferred output datasets catalogued as non-personal data because inputs were anonymized or pseudonymized", "Downstream consumers of inferred personal data with no access control or data classification documentation", "No lineage records linking inferred output datasets to their source data and inference scope specification" ] }, "grc_auditor": { "summary": "Audit evidence for DP-04 must confirm that inference scope specifications exist and are current, that inferred outputs are classified as personal data, and that scope enforcement is tested and operating at the output layer.", "actions": [ "Request inference scope specifications for all AI systems in scope and compare against the actual output profile of each system", "Review inferred data classification records and confirm access controls are commensurate with sensitivity", "Request output classifier test results demonstrating scope enforcement is effective against adversarial inputs" ], "metrics": [ "Percentage of AI systems with a current inference scope specification reviewed in the last 12 months", "Number of out-of-scope inferences detected and suppressed by the output classifier in the audit period" ], "failure_signals": [ "AI systems in production with no inference scope specification on file", "Inferred outputs stored in systems that treat them as non-personal data", "No test results demonstrating the output classifier functions correctly" ] }, "software_engineering": { "summary": "Inference scope enforcement must be implemented at the output layer as a post-processing step that intercepts all model outputs before they reach downstream consumers, and must be tested with adversarial examples before deployment.", "actions": [ "Implement an output post-processor that classifies inferences against the permitted scope specification and suppresses or flags out-of-scope outputs before delivery to consumers", "Integrate adversarial inference scope test suites into the model evaluation pipeline to catch scope violations before deployment", "Ensure all inferred personal data is routed through the same audit logging infrastructure as collected personal data from the point of output generation" ], "failure_signals": [ "Model outputs delivered directly to consumers without passing through a scope enforcement layer", "No adversarial inference scope tests in the model evaluation suite", "Inferred outputs not captured by audit logging infrastructure" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations do not produce inference scope specifications or treat inferred outputs as personal data; EDPB Opinion 28/2024 makes this a compliance gap with direct regulatory authority backing." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "ML Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(b)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 5(1)(b) requires purpose limitation; DP-04 extends this to inferred outputs by requiring that permitted inference types are defined and enforced, preventing AI systems from drawing conclusions beyond their authorized scope.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "edpb_opinion_28_2024", "requirement_id": "inferred data §3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EDPB Opinion 28/2024 §3 confirms that inferred personal data carries the same GDPR obligations as collected personal data; DP-04 operationalizes this by classifying and governing inferred outputs accordingly.", "source_version": "28/2024", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DP-P3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DP-04 implements NIST Privacy Framework CT.DP-P3 — data are processed to limit the formulation of inferences about individuals' behavior or activities — through inference scope specification and output-layer enforcement.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Inferred Sensitive Data risk — Training Data Management / Output Validation and Sanitization", "rationale": "SAIF names Inferred Sensitive Data as a first-class risk — models deriving sensitive attributes beyond what was provided — mitigated by Training Data Management and Output Validation and Sanitization; DP-04 operationalizes those mitigations as an inference scope limit.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF's Inferred Sensitive Data risk and output validation align with DP-04's output classifier but not the inference-scope spec or derived-data classification.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "openai_privacy", "requirement_id": "OpenAI usage policies — restricted inference uses", "rationale": "OpenAI's enterprise usage policies require customers to implement safeguards preventing models from performing inference on personal data beyond the permitted scope defined in the data processing agreement. Customers must configure API usage—including system prompts, allowed topics, and output validation—to enforce inference scope limits consistent with the lawful basis for processing.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI usage policies require customers to limit inference scope but impose an obligation, not the runtime output classifier and scope spec DP-04 provides.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "sensitiveoutputhandling", "fit": "supporting", "rationale": "DP-04 uses an output-layer classifier to enforce an inference-scope specification and block prohibited individual-level inferences, handling sensitive inferred output.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The AI system has a documented inference scope specification defining permitted and…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (sensitiveoutputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "AI systems can produce special-category inferences from innocuous inputs without explicit design intent; EDPB Opinion 28/2024 makes those outputs personal data carrying Art 9 obligations regardless of input classification. This control requires inference scope to be defined before training and enforced at the output layer, converting a latent compliance gap into a managed and auditable boundary.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-04", "validation_objective": "The AI system has a documented inference scope specification defining permitted and prohibited individual-level inferences, an output-layer classifier enforces that scope at runtime, and all inferred outputs are classified and access-controlled as personal data with the same obligations as collected data of equivalent sensitivity.", "evidence_required": [ "inference_scope_specification per AI system listing permitted inference types, prohibited categories, and reviewed_on date within the last 12 months", "output_classifier_test_results showing adversarial inference attempts for special-category attributes (health, political opinion, financial situation) were detected and suppressed or flagged before delivery to callers", "inferred_data_classification_record confirming inferred outputs are tagged as personal data and have access controls commensurate with sensitivity tier", "DPIA_inference_section confirming inferred outputs were assessed under Art 9 where special-category attributes can be produced and that appropriate controls are documented" ], "machine_tests": [ "Submit prompt designed to elicit health-status inference from innocuous input (e.g., purchase history) → assert output classifier suppresses or flags the response before delivery to caller", "Inspect inferred output data store schema and access control policy → assert classification label matches the equivalent collected personal data sensitivity tier", "Submit 100 adversarial prompts targeting inference types listed as out-of-scope in the scope specification → assert classifier detection rate meets the defined threshold with zero undetected leakages returned to callers", "Trigger inference scope specification review gate in CI/CD pipeline for a model fine-tuning job → assert pipeline blocks deployment until reviewed_on date on scope spec is within 30 days of deployment date" ], "human_review": [ "Review inference scope specification against current model output profile to identify specification drift introduced by fine-tuning or architecture changes since last review", "Assess whether any permitted inference types produce outputs qualifying as Art 9 special-category data and verify appropriate controls are documented in the DPIA", "Verify inferred output data catalog entries include lineage linking to the source dataset and inference scope specification that authorized the inference" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Treating AI model outputs as non-personal data because input data was anonymized or pseudonymized, without validating that no individual-level inferences are produced", "Relying on system prompt instructions alone to limit inference scope without implementing a technical post-generation output classifier", "Defining inference scope specifications as one-time design artifacts without reassessing after model fine-tuning, architecture changes, or new use case additions", "Allowing inferred outputs to flow to downstream systems without applying the same personal data classification and access controls as collected data of equivalent sensitivity", "Describing permitted inferences in vague natural-language terms ('customer insights') that cannot be operationalized as classifier rules or test cases" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-05", "layer": "DP", "plane": "data", "name": "Output PII Scrubbing", "plain": "Personal data appearing verbatim or near-verbatim in model outputs is detected and removed post-generation, with scrubbing decisions logged for audit and quality monitoring.", "threat": { "tags": [ "model-memorization-pii-leakage", "art9-data-in-outputs", "belgian-dpa-enforcement" ], "desc": "Large language models memorize training data and reproduce it in outputs. EDPB Opinion 28/2024 and Belgian DPA 2025 enforcement action confirm that PII appearing in AI outputs constitutes a personal data breach when that data originated from training without an adequate lawful basis." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(c) / Art 32", "title": "Data minimisation and security of processing" }, { "id": "edpb_opinion_28_2024", "section": "Opinion §3.2", "title": "Personal data extraction and regurgitation from AI models" }, { "id": "nist_pf", "section": "PR.DS-P5", "title": "Protections against data leaks are implemented" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-01" }, { "id": "edpb_opinion_28_2024", "title": "EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models", "authority": "European Data Protection Board", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "28/2024", "published_on": "2024-12-17", "retrieved_on": "2026-06-28", "canonical_url": "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "edpb_opinion_28_2024", "relationship": "supporting_guidance", "rationale": "Establishes EDPB Opinion 28/2024 — Data Protection Aspects Related to AI Models requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-05 Output PII Scrubbing control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy a post-generation PII detection and scrubbing layer that intercepts all model outputs before delivery, identifies personal data using NER and pattern matching, redacts or suppresses it, and emits a structured scrubbing log for each request.", "steps": [ "Deploy a PII detection layer after model generation using named entity recognition (NER) and regex pattern matching for structured identifiers (SSN, IBAN, email, phone, NIN) tuned to the deployment jurisdictions", "Configure the scrubbing layer to redact detected PII before outputs are returned to callers; log each scrubbing event with the entity type, confidence, and request ID — but not the raw PII value", "Establish a monitoring pipeline over scrubbing logs to detect anomalous scrubbing rates (high rates may indicate memorization regression after fine-tuning) and trigger model review thresholds" ], "anti_patterns": [ "Relying solely on system prompt instructions to prevent PII disclosure without a technical post-generation detection and scrubbing layer", "Logging raw PII values in scrubbing event records, which creates a new personal data store requiring its own compliance controls" ] }, "validation": { "design_check": [ "Confirm a PII detection and scrubbing layer is deployed post-generation for all model output paths [ref:gdpr_2016_679]", "Verify scrubbing logs record entity type and request ID but not raw PII values [ref:edpb_opinion_28_2024]", "Confirm a monitoring pipeline over scrubbing rates is active and has defined alert thresholds [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit memorization probe inputs known to elicit training data reproduction and verify the scrubbing layer detects and redacts PII in the output", "Review scrubbing logs for a sample of requests to confirm PII entity type is recorded without raw value exposure", "Trigger the high-scrubbing-rate alert threshold and confirm the monitoring pipeline delivers an alert to the model review team" ], "evidence": [ "privacy:scrubbing-log — Structured output scrubbing event log covering the audit period, confirming PII redaction without raw value exposure [unverified]", "privacy:memorization-probe-results — Results of memorization probe testing confirming the scrubbing layer catches verbatim training data in outputs [unverified]", "privacy:scrubbing-rate-trend — Scrubbing rate trend report from the monitoring pipeline with alert threshold documentation [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Output PII scrubbing is a required technical safeguard for any AI system that produces natural language outputs; system prompt constraints are not a substitute for a post-generation detection and redaction layer.", "actions": [ "Deploy a NER-based PII scrubber tuned to the personal data categories and jurisdictions relevant to the deployment context", "Ensure scrubbing logs capture entity type and redaction metadata without storing raw PII values", "Establish scrubbing rate monitoring with defined thresholds that trigger model review after fine-tuning" ], "failure_signals": [ "Model outputs delivered to callers without passing through a post-generation PII detection layer", "Scrubbing logs containing raw PII values — creating a secondary personal data store", "No scrubbing rate monitoring in place after model fine-tuning events" ] }, "dpo": { "summary": "EDPB Opinion 28/2024 §4 and the Belgian DPA 2025 enforcement action confirm that PII in AI outputs is a personal data breach when training data lacked adequate lawful basis; DPOs must confirm this control is documented in DPIAs and that scrubbing logs are retained for breach investigation purposes.", "actions": [ "Document output PII scrubbing as a technical measure in DPIAs for all AI systems producing natural language outputs", "Ensure scrubbing logs are retained for a period sufficient to support breach investigation and supervisory authority requests", "Include scrubbing failure rates in the AI system's incident management process as a trigger for Art 33 breach notification assessment" ], "failure_signals": [ "DPIAs for AI systems with natural language outputs that do not reference output PII scrubbing as a technical measure", "Scrubbing logs not retained or purged before a retention period sufficient for breach investigation", "No process for escalating high scrubbing rates to a breach notification assessment" ] }, "data_governance": { "summary": "Data governance must ensure scrubbing log data is itself governed as a personal data adjacent asset, with a defined retention period, access controls, and inclusion in the data catalog.", "actions": [ "Catalog scrubbing logs as a sensitive operational data asset with defined retention and access controls", "Ensure scrubbing log retention periods are aligned with the organization's breach investigation and supervisory response SLAs", "Include scrubbing coverage in AI system data quality reporting to detect scrubber performance degradation over time" ], "failure_signals": [ "Scrubbing logs not catalogued as a data asset with defined retention and ownership", "Scrubbing logs retained indefinitely without a defined purge schedule", "No data quality monitoring over scrubber detection accuracy or coverage" ] }, "grc_auditor": { "summary": "Audit evidence for DP-05 must demonstrate that a post-generation scrubbing layer is deployed and effective, with scrubbing logs confirming redaction events and memorization probe test results confirming the scrubber catches verbatim training data.", "actions": [ "Request scrubbing log samples to confirm PII redaction events are recorded with entity type but not raw PII values", "Review memorization probe test results from model evaluation to confirm the scrubbing layer is effective", "Inspect scrubbing rate trend reports to identify periods of anomalously high scrubbing rates that may indicate model issues" ], "metrics": [ "Percentage of AI system output paths covered by post-generation PII scrubbing", "Number of scrubbing events per thousand requests, trended over model version history" ], "failure_signals": [ "No post-generation scrubbing layer deployed for AI systems producing natural language outputs", "Memorization probe tests absent from the model evaluation suite", "Scrubbing logs unavailable for the audit period or not retained" ] }, "software_engineering": { "summary": "Output PII scrubbing must be implemented as a mandatory pipeline stage between model generation and response delivery; it must be integrated at the API gateway or inference service layer, not as optional application-level logic.", "actions": [ "Integrate a PII detection library (e.g., Microsoft Presidio, AWS Comprehend PII detection) into the inference service response path as a mandatory pipeline stage", "Configure the scrubbing layer to block response delivery until detection completes; a scrubber timeout should return a safe fallback rather than passing through unscreened output", "Emit structured scrubbing events to a centralized logging system with request ID, timestamp, entity types detected, and redaction count — no raw PII values" ], "failure_signals": [ "PII scrubbing implemented as optional middleware that can be bypassed by callers or configuration flags", "Scrubber timeout results in unscreened output being returned to callers", "Scrubbing events not emitted to centralized logging infrastructure" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Output PII scrubbing is absent from most AI deployment architectures; EDPB Opinion 28/2024 and Belgian DPA enforcement have elevated this from best practice to a regulatory expectation." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "ML Engineering", "Software Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 32", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 32 requires appropriate technical measures for security of processing; DP-05 operationalizes this by preventing PII leakage in AI model outputs through post-generation detection and redaction.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "edpb_opinion_28_2024", "requirement_id": "Opinion §3.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EDPB Opinion 28/2024 §3.2 treats the likelihood of extracting or regurgitating personal data from a model as central to whether the model can be considered anonymous; DP-05's output scrubbing directly reduces that extraction surface.", "source_version": "28/2024", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "PR.DS-P5", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DP-05 implements NIST Privacy Framework PR.DS-P5 — protections against data leaks are implemented — by scrubbing personal data from AI model outputs before delivery to callers.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Google Cloud Sensitive Data Protection — output inspection and de-identification", "rationale": "Google Cloud's Sensitive Data Protection API can be applied to AI model outputs in real-time to inspect and de-identify PII before delivering results to end-users. The inspection API detects over 200 infoTypes in model-generated text, and the de-identification API removes or transforms identified personal data, implementing output PII scrubbing as a post-processing step in AI response pipelines.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Cloud DLP inspects and de-identifies PII in outputs pre-delivery, doing the core scrub but not the per-path enforcement, event logging, or rate monitoring.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon Comprehend — PII detection and redaction", "rationale": "AWS Amazon Comprehend provides DetectPiiEntities and ContainsPiiEntities APIs that enable real-time PII detection and redaction in AI model outputs. Comprehend supports 18+ PII entity types and can be integrated as a post-processing step in AI inference pipelines to scrub PII from generated responses before delivery, implementing output data minimization requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Amazon Comprehend's PII detection/redaction APIs scrub outputs as post-processing, covering redaction but not per-path enforcement or rate monitoring.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Data Loss Prevention — generative AI app coverage", "rationale": "Microsoft Purview DLP policies extend to generative AI applications, detecting and blocking sensitive information in prompts and responses; DP-05 applies the same output-side PII scrubbing discipline to enterprise AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview DLP blocks sensitive info in AI responses, providing output scrubbing but not the event logging or memorization-rate monitoring DP-05 adds.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "sensitiveoutputhandling", "fit": "direct", "rationale": "DP-05 intercepts every model output with a mandatory PII detection and scrubbing layer that redacts personal data before delivery, directly handling sensitive output to prevent leakage.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"Every AI model output path has a mandatory post-generation PII detection and scrubbing…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (sensitiveoutputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "cross_domain": { "references": [ { "uri": "apeiris://data/controls/DM-04", "relationship": "related", "note": "DP-05 governs PII output leakage from AI models. The Data domain DM-04 governs non-PII output leakage including trade secrets and proprietary data. Together they provide complete output leakage coverage." } ] }, "thesis_type": "detective", "matrix_thesis": "Model memorization is a distinct leakage vector separate from data breach — it operates silently at inference time and can expose training data to any caller without triggering conventional security controls. This control implements a post-generation detection layer that catches PII before it exits the system, converting a silent breach risk into a logged, monitored, and auditable event.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-05", "validation_objective": "Every AI model output path has a mandatory post-generation PII detection and scrubbing layer that intercepts all outputs before delivery to callers, redacts detected personal data, and logs each scrubbing event with entity type and request ID but without raw PII values; and a scrubbing rate monitoring pipeline is active and configured to alert when elevated rates indicate potential model memorization regression.", "evidence_required": [ "output_scrubbing_event_log for the audit period recording entity_type, request_id, redaction_count, and timestamp per scrubbing event without raw PII values", "memorization_probe_test_results confirming the scrubbing layer detects and redacts verbatim training data across at least three PII categories (names, contact details, financial identifiers)", "scrubbing_rate_trend_report from the monitoring pipeline covering the last 90 days with alert threshold documentation and any threshold-breach notifications sent", "scrubbing_layer_architecture_evidence confirming implementation as a mandatory pipeline stage between model generation and response delivery, not as optional application-level middleware" ], "machine_tests": [ "Submit 50 memorization probe inputs known to elicit structured PII (email, phone, IBAN) → assert 100% of probes return redacted output with no raw PII visible in the caller response", "Attempt to call inference endpoint with a request that bypasses scrubbing middleware via modified Accept header or content-type negotiation → assert scrubber fires regardless and response is not returned unscreened", "Inject synthetic PII-bearing outputs at a volume above the configured scrubbing rate alert threshold → assert monitoring pipeline fires alert to the model review team within the defined SLA" ], "human_review": [ "Review scrubbing layer implementation to confirm it cannot be bypassed by application-layer callers through configuration flags or request parameters", "Assess scrubbing log retention period against the organization's breach investigation and supervisory authority response SLAs to confirm logs are retained long enough to support Art 33 breach documentation", "Verify NER model and pattern matching rules are calibrated for the personal data categories and jurisdiction-specific identifiers relevant to the deployment context (e.g., national ID formats, IBAN, NHS numbers)" ], "blocking_effect": "blocks-runtime-action", "normative_status": "binding-law", "anti_patterns": [ "Implementing PII scrubbing as optional middleware that callers can disable via configuration flags or API parameters instead of as a mandatory, non-bypassable pipeline stage", "Logging raw PII values detected during scrubbing in scrubbing event records, creating a secondary personal data store with its own GDPR compliance obligations", "Relying solely on system prompt instructions ('do not repeat personal information') without a technical post-generation detection and redaction layer", "Allowing scrubber timeout or internal error to return unscreened output to callers rather than failing safe with a blocked or generic error response", "Treating scrubbing as a deployment-time configuration rather than a continuously monitored control, failing to detect memorization regressions introduced by model fine-tuning" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-06", "layer": "DP", "plane": "data", "name": "Synthetic Data Governance", "plain": "Synthetic training data is validated to confirm it cannot statistically re-identify individuals from the source dataset; generation methodology, privacy budget, and re-identification resistance results are documented.", "threat": { "tags": [ "synthetic-data-re-identification", "membership-inference-on-synthetic-data", "no-anonymization-validation" ], "desc": "Synthetic data that fails the GDPR anonymization standard (i.e., re-identification is reasonably possible) remains personal data subject to full GDPR obligations. Organizations claiming GDPR exemption based on synthetic data without formal re-identification testing face enforcement exposure." }, "standard": [ { "id": "gdpr", "section": "Art 4(1)", "title": "Anonymisation standard for personal data exemption" }, { "id": "nist_pf", "section": "CT.DP-P2", "title": "Data processed to limit identification of individuals" }, { "id": "eu_ai_act", "section": "Art 10", "title": "Data governance requirements for AI training data" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-06 Synthetic Data Governance control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-06 Synthetic Data Governance control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/DP-06 Synthetic Data Governance control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-06 Synthetic Data Governance control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-06 Synthetic Data Governance control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Document synthetic data generation methodology including the privacy-preserving technique used (differential privacy, generative models, agent-based simulation); measure re-identification risk against the source dataset using membership inference attack testing before the GDPR exemption claim is made.", "steps": [ "Document the synthetic data generation methodology for each dataset, specifying the technique (DP-SGD, CTGAN, VAE), the privacy budget (ε, δ) where differential privacy is used, and the source data scope", "Run membership inference attack tests and nearest-neighbor distance ratio analysis against the source dataset to quantify re-identification risk; set a rejection threshold above which the synthetic dataset is classified as personal data", "Record generation methodology, privacy budget, re-identification test results, and the GDPR classification conclusion in the synthetic dataset's provenance record; re-test after any change to the source dataset scope" ], "anti_patterns": [ "Claiming GDPR anonymization exemption for synthetic data based solely on the use of a generative model without conducting re-identification testing", "Using synthetic data generated from a small or unique source population without additional differential privacy guarantees, as population sparsity makes re-identification tractable" ] }, "validation": { "design_check": [ "Confirm generation methodology documentation exists for each synthetic dataset including technique and privacy budget [ref:gdpr_2016_679]", "Verify membership inference attack testing is scheduled before GDPR classification is applied to each synthetic dataset [ref:nist_pf_1_0]", "Confirm synthetic dataset provenance records include re-identification test results and GDPR classification conclusion [ref:eu_ai_act_2024]" ], "runtime_test": [ "Run a membership inference attack on a sample of each synthetic training dataset and record the true positive rate against a defined rejection threshold", "Apply nearest-neighbor distance ratio (NNDR) analysis between the synthetic and source datasets to quantify statistical proximity", "Verify that synthetic datasets above the re-identification risk threshold are classified as personal data and governed accordingly" ], "evidence": [ "privacy:synthetic-generation-methodology — Generation methodology documentation including technique, privacy budget, and source data scope per synthetic dataset [unverified]", "privacy:membership-inference-test — Membership inference attack test results with true positive rate and threshold decision [unverified]", "privacy:synthetic-classification-record — GDPR classification conclusion and re-identification risk quantification per synthetic dataset [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Synthetic data does not automatically qualify as anonymous under GDPR; a formal re-identification resistance assessment is required before a GDPR exemption can be claimed, and that assessment must be documented and repeated when source data changes.", "actions": [ "Define and document the re-identification risk threshold above which synthetic datasets must be classified as personal data", "Integrate membership inference attack testing into the synthetic data generation pipeline as a mandatory gate before the dataset is released for training use", "Maintain a provenance record for each synthetic dataset linking generation methodology, test results, and GDPR classification conclusion" ], "failure_signals": [ "Synthetic datasets in production with no re-identification test results on file", "GDPR exemption claimed for synthetic data based on generation technique alone without formal testing", "No re-test policy when source dataset scope changes after initial generation" ] }, "dpo": { "summary": "GDPR Recital 26 and the Art 4(1) definition of personal data require that anonymization is assessed against all means reasonably likely to be used for re-identification; DPOs must confirm that synthetic data GDPR exemption claims are backed by formal re-identification test results, not generation technique assertions.", "actions": [ "Review synthetic dataset GDPR classification conclusions before exemption is applied — confirm test results are on file", "Document synthetic data governance policy in the organization's privacy framework, defining the required testing methodology and classification thresholds", "Include synthetic dataset re-identification risk in DPIA technical measures sections where synthetic data is used in high-risk AI systems" ], "failure_signals": [ "GDPR exemption applied to synthetic datasets without DPO review of re-identification test results", "No organizational policy defining the synthetic data GDPR classification methodology and thresholds", "DPIAs for AI systems using synthetic training data that do not address re-identification risk" ] }, "data_governance": { "summary": "Synthetic datasets must be governed as first-class data assets with provenance records that capture generation methodology, privacy budget, and re-identification classification; the GDPR classification determines what downstream governance obligations apply.", "actions": [ "Catalog each synthetic dataset with full provenance including generation methodology, source data lineage, and re-identification classification", "Apply the same access controls and retention policies as the equivalent source personal data where synthetic datasets fail the re-identification threshold", "Implement a trigger to re-test and re-classify synthetic datasets when the underlying source dataset scope or generation methodology changes" ], "failure_signals": [ "Synthetic datasets in the data catalog without provenance records linking to generation methodology and re-identification test results", "Synthetic datasets that failed re-identification thresholds governed as non-personal data in downstream systems", "No catalog trigger or change management process to re-test synthetic datasets after source data changes" ] }, "grc_auditor": { "summary": "Audit evidence for DP-06 must confirm that GDPR classification claims for synthetic datasets are backed by formal re-identification test results with documented methodology and thresholds, not assertions based on generation technique alone.", "actions": [ "Request generation methodology documentation and re-identification test results for each synthetic dataset in scope", "Verify that datasets above the re-identification threshold are classified and governed as personal data", "Confirm re-testing was triggered for any synthetic datasets whose source data changed during the audit period" ], "metrics": [ "Percentage of synthetic training datasets with a re-identification test result on file before use in production training", "Percentage of synthetic datasets that failed re-identification threshold and were correctly reclassified as personal data" ], "failure_signals": [ "Synthetic datasets with GDPR exemption claimed but no re-identification test results on file", "Membership inference attack testing methodology not documented or reproducible", "Datasets that failed re-identification threshold not reclassified or governed as personal data" ] }, "software_engineering": { "summary": "Synthetic data generation pipelines must integrate re-identification testing as a pipeline gate that blocks dataset release when the re-identification risk threshold is exceeded, with results emitted to a provenance store.", "actions": [ "Integrate membership inference attack testing and NNDR analysis as automated pipeline stages after synthetic data generation", "Implement a pipeline gate that blocks synthetic dataset release when the measured re-identification risk exceeds the defined threshold", "Emit structured provenance records to a data catalog at each generation run, including technique parameters, privacy budget, and re-identification test results" ], "failure_signals": [ "Synthetic data generation pipeline with no automated re-identification testing stage", "Re-identification test failures logged but not blocking dataset release", "No structured provenance record emitted at generation time" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Organizations routinely claim GDPR exemption for synthetic data based on generation technique without conducting membership inference testing; regulators are beginning to challenge these claims." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "ML Engineering", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 4(1)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 4(1) defines personal data by reference to identifiability; DP-06 operationalizes the anonymization standard by requiring formal re-identification testing before a GDPR exemption is claimed for synthetic data.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DP-P2", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DP-06 aligns with NIST Privacy Framework CT.DP-P2 — data are processed to limit the identification of individuals, e.g. through de-identification techniques — by governing synthetic data generation, privacy budgets, and re-identification risk measurement.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art 10", "fit": "partial", "direction": "control-supports-requirement", "rationale": "EU AI Act Art 10 requires data governance for AI training datasets; DP-06 partially satisfies this for synthetic training data by requiring provenance documentation and re-identification risk assessment.", "source_version": "2024/1689", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Privacy Enhancing Technologies", "rationale": "SAIF's Privacy Enhancing Technologies control mitigates the Sensitive Data Disclosure risk through techniques that reduce exposure of real personal data in training; DP-06 governs synthetic data as one such technique, including validation that synthetic sets do not re-encode source personal data.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's Privacy Enhancing Technologies is a related PET category but not the synthetic-data re-identification validation and privacy-budget documentation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon SageMaker Ground Truth — synthetic data generation", "rationale": "Amazon SageMaker Ground Truth offers synthetic data generation for training datasets; DP-06's provenance documentation and re-identification risk assessment govern such vendor-generated synthetic data before use.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SageMaker Ground Truth generates synthetic data but DP-06 is the governance and re-identification validation applied to such data, not the generation itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "obfuscatetrainingdata", "fit": "supporting", "rationale": "DP-06 admits synthetic training datasets only after a membership-inference test confirms re-identification risk below threshold, using synthetic data as privacy-preserving training data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Synthetic data is not automatically anonymous under GDPR; the standard is whether re-identification is reasonably possible, not whether a generative model was used. This control closes the gap between generation-technique assertions and formal re-identification resistance, making GDPR exemption claims defensible against supervisory authority challenge.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-06", "validation_objective": "Every synthetic dataset used in AI training or claimed as GDPR-exempt has documented generation methodology including technique and privacy budget where applicable, and a membership inference attack test result confirming re-identification risk falls below the defined organizational threshold before the dataset is released for production training use.", "evidence_required": [ "synthetic_data_generation_methodology per dataset specifying technique (DP-SGD, CTGAN, VAE, etc.), privacy budget epsilon and delta where differential privacy is applied, and source dataset scope", "membership_inference_attack_test_results with true positive rate, sample size, and pass/fail decision against the defined rejection threshold, dated within 90 days of dataset release", "nearest_neighbor_distance_ratio (NNDR) analysis report comparing synthetic dataset to source dataset with quantified statistical proximity score", "synthetic_dataset_gdpr_classification_record showing the GDPR classification conclusion (anonymous or personal data), the test results it is based on, and reviewer sign-off identity and date" ], "machine_tests": [ "Run shadow-model membership inference attack against each synthetic dataset used in production training → assert true positive rate falls below the defined rejection threshold (e.g., no more than 0.15 above random baseline)", "Apply NNDR analysis between synthetic and source dataset → assert ratio distribution confirms synthetic records are not statistically proximate to source individuals above the defined distance threshold", "Attempt to use a synthetic dataset that failed re-identification threshold in the training pipeline → assert pipeline gate blocks the dataset from release and logs a blocked_release_event with dataset_id and test result" ], "human_review": [ "Review GDPR classification conclusion for each synthetic dataset to confirm it is based on formal test results rather than assertions about the generation technique used", "Assess whether the organizational re-identification threshold is calibrated to the source population size and sensitivity — small or demographically unique populations require stricter thresholds than large generic datasets", "Verify a re-test was triggered for any synthetic datasets whose source dataset scope or generation methodology changed since the last classification decision" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Claiming GDPR anonymization exemption for synthetic data based solely on the use of a generative model without conducting formal membership inference attack testing", "Setting a re-identification threshold without calibrating it to the sensitivity or population uniqueness of the source data — a threshold appropriate for large generic populations is insufficient for clinical or financial records", "Running membership inference tests once at initial dataset generation and not retesting when source dataset scope or generation parameters change", "Using NNDR visualizations or t-SNE plots as the sole evidence of re-identification resistance without running formal membership inference attacks", "Permitting synthetic datasets to enter the training pipeline while re-identification testing is still pending rather than requiring a completed pass result before release" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-07", "layer": "DP", "plane": "data", "name": "AI Telemetry Data Controls", "plain": "AI telemetry — prompt data, session records, inference logs, and usage patterns — is governed with the same lawful basis, purpose limitation, retention limits, and access controls applied to training data.", "threat": { "tags": [ "prompt-data-contains-pii", "session-records-enable-re-identification", "telemetry-retained-indefinitely" ], "desc": "AI telemetry frequently captures personal data — including verbatim user inputs containing health, financial, or identification information — that is logged without a lawful basis or retention schedule. EDPB Opinion 28/2024 addresses this directly for AI systems collecting prompt data." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(a)(b)(c)(e) / Art 13", "title": "Lawfulness and transparency obligations for telemetry" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records incorporating the principle of data minimization" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/DP-07 AI Telemetry Data Controls control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Classify AI telemetry as a personal data processing operation; establish a lawful basis, purpose specification, and retention schedule for each telemetry type; apply access controls commensurate with the personal data sensitivity present in telemetry records; and provide transparency to data subjects via the privacy notice.", "steps": [ "Inventory all AI telemetry types (prompt logs, session records, inference latency records, usage analytics) and classify each by the personal data categories it may contain based on system context", "For each telemetry type, establish a lawful basis, documented purpose, and maximum retention period; apply access controls limiting telemetry access to named roles with a documented need", "Update the privacy notice to disclose AI telemetry processing and include telemetry retention schedules in automated purge policies; add telemetry to the RoPA with field-level personal data detail" ], "anti_patterns": [ "Logging full prompt and response payloads indefinitely in production observability systems that are broadly accessible to engineering teams", "Treating AI telemetry as non-personal operational data by default without classifying based on what user inputs may contain" ] }, "validation": { "design_check": [ "Confirm all AI telemetry types are inventoried and classified with a documented lawful basis and retention period [ref:gdpr_2016_679]", "Verify AI telemetry access controls limit access to named roles with documented need [ref:edpb_opinion_28_2024]", "Confirm automated purge policies are active for all AI telemetry stores and aligned with documented retention periods [ref:nist_pf_1_0]" ], "runtime_test": [ "Audit access logs for AI telemetry stores to confirm only named authorized roles have accessed them in the review period", "Verify automated purge jobs have executed within the scheduled frequency by reviewing purge execution logs", "Submit a test prompt containing structured PII (email, phone) and confirm that telemetry logs capture the minimum required fields rather than full payload retention" ], "evidence": [ "privacy:telemetry-inventory — Telemetry type inventory with lawful basis, purpose, and retention period documented per telemetry type [unverified]", "privacy:telemetry-access-log — Access log audit confirming telemetry access limited to authorized roles in the review period [unverified]", "privacy:purge-execution-log — Automated purge job execution log confirming telemetry retention limits are enforced [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "AI telemetry is a personal data processing operation that requires the same GDPR discipline as any other processing activity; the default engineering posture of logging everything for observability is incompatible with Art 5(1)(c) and (e).", "actions": [ "Classify every AI telemetry type at design time and apply the minimum data collection principle to each — log what is necessary for the documented purpose, nothing more", "Implement field-level telemetry controls that can suppress or pseudonymize PII-containing fields before they reach the log store", "Include AI telemetry in privacy-by-design review for every new AI system capability, ensuring new telemetry types are classified before they are deployed" ], "failure_signals": [ "Full prompt and response payloads logged to production observability systems with no access controls or retention limits", "New AI system capabilities deployed with telemetry types that have not been classified or included in the RoPA", "Telemetry stores accessible to all engineering staff without role-based access controls" ] }, "dpo": { "summary": "AI telemetry — prompts, usage logs, and behavior records — is personal data within the scope of the GDPR; DPOs must confirm that AI telemetry is included in the RoPA, that a lawful basis exists for each telemetry type, and that transparency obligations under Art 13 extend to AI telemetry collection.", "actions": [ "Review and approve the AI telemetry inventory to confirm each type has a documented lawful basis and retention period", "Ensure privacy notices cover AI telemetry collection, including prompt data retention and the purposes for which it is processed", "Include AI telemetry in the RoPA with field-level personal data categories, lawful basis, and retention schedule" ], "failure_signals": [ "AI telemetry not included in the RoPA or privacy notice", "Prompt data retained beyond a documented retention period without a separate lawful basis for extended retention", "No lawful basis documented for AI telemetry processing operations that collect personal data" ] }, "data_governance": { "summary": "AI telemetry must be governed as a personal data asset category with defined classification, ownership, retention schedules, and automated purge policies; treating it as generic operational logging is a data governance failure with regulatory consequences.", "actions": [ "Catalog all AI telemetry stores as personal data assets with documented ownership, retention period, and access control policy", "Implement automated purge schedules for all AI telemetry stores and verify execution via purge logs", "Require new AI system telemetry types to go through a data governance classification review before production deployment" ], "failure_signals": [ "AI telemetry stores absent from the enterprise data catalog or catalogued as non-personal operational data", "No automated purge policies for AI telemetry stores — data accumulates indefinitely", "New AI system telemetry types deployed without data governance classification review" ] }, "grc_auditor": { "summary": "Audit evidence for DP-07 must confirm that each AI telemetry type has a documented lawful basis and retention period, that access is controlled and logged, and that automated purge policies are executing on schedule.", "actions": [ "Request the AI telemetry inventory and verify each type has a lawful basis, purpose, and retention period on file", "Review telemetry access logs to confirm access is limited to authorized roles and is logged with actor identity", "Verify purge execution logs confirm automated purge jobs are running within the scheduled frequency" ], "metrics": [ "Percentage of AI telemetry types with a documented lawful basis and retention period in the RoPA", "Percentage of AI telemetry stores with active automated purge policies confirmed by execution logs" ], "failure_signals": [ "AI telemetry types without a documented lawful basis or retention period in the RoPA", "Telemetry stores without access controls or access logging", "Purge execution logs absent or showing missed scheduled purge jobs" ] }, "software_engineering": { "summary": "AI telemetry must be instrumented with privacy controls at design time — not retrofitted — including field-level PII suppression, role-based access controls on log stores, and automated retention enforcement integrated into the observability infrastructure.", "actions": [ "Implement field-level telemetry controls in the AI inference service that can suppress, hash, or pseudonymize PII-containing fields based on telemetry type classification", "Configure role-based access controls on all AI telemetry log stores and enable access logging so that every access is recorded with actor identity and timestamp", "Integrate retention enforcement into the logging infrastructure using log store TTL or scheduled purge jobs; validate purge execution in CI/CD pipelines" ], "failure_signals": [ "AI inference services emitting full prompt and response payloads to observability platforms without field-level PII controls", "Log stores without role-based access controls or access logging", "Retention enforcement absent from observability infrastructure — log data accumulates until storage limits are hit" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "AI telemetry is routinely treated as operational log data exempt from GDPR obligations; EDPB Opinion 28/2024 has closed this interpretation gap and organizations must now classify and govern prompt data accordingly." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Software Engineering", "Data Governance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(e)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 5(1)(e) requires personal data not be kept longer than necessary; DP-07 applies this to AI telemetry by requiring documented retention periods and automated purge enforcement for all telemetry types.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "partial", "direction": "control-supports-requirement", "rationale": "DP-07 implements NIST Privacy Framework CT.DM-P8 — audit/log records are determined, documented, implemented, and reviewed in accordance with policy and incorporating the principle of data minimization — for AI telemetry, prompts, and usage logs.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "User Data Management — telemetry and log data", "rationale": "SAIF's User Data Management control requires appropriate handling and retention of user data, which for AI systems includes prompts, outputs, and behavior logs; DP-07 applies purpose limitation and retention controls to that telemetry as a personal data category.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF User Data Management endorses appropriate telemetry/log handling and retention, aligning with DP-07 but not its lawful-basis, purpose, and purge controls.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic API log retention controls", "rationale": "Anthropic retains API inference telemetry (inputs and outputs) for only 7 days by default, automatically deleting logs and never using them for model training. The ZDR option eliminates all telemetry persistence beyond real-time abuse detection. These retention constraints apply to telemetry data containing personal data, directly governing the AI telemetry data retention schedule.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Anthropic's 7-day/ZDR log retention governs its API telemetry with auto-deletion, covering retention for that category but not lawful-basis and access controls.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI API log retention — 30-day abuse monitoring window", "rationale": "OpenAI retains API usage logs for up to 30 days for safety monitoring purposes, after which telemetry is deleted. Logs are not used for model training by default. Enterprise customers can request reduced retention via data controls. This 30-day telemetry retention policy must be incorporated into AI telemetry data governance schedules for systems using OpenAI APIs.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI's 30-day log retention governs its API telemetry deletion, covering retention for that category but not the lawful-basis and access controls.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview DSPM for AI — AI interaction data governance", "rationale": "Microsoft Purview Data Security Posture Management (DSPM) for AI discovers and governs AI interaction data — prompts and responses — across Copilot and third-party AI applications; DP-07 applies equivalent governance to enterprise AI telemetry.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview DSPM for AI discovers and governs AI interaction data across apps, covering telemetry governance but not the lawful-basis and retention schedule.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "shortretain", "fit": "supporting", "rationale": "DP-07 sets a maximum retention period per AI telemetry type with active automated purge policies confirmed by execution logs, minimizing retention of prompt/inference logs.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "AI telemetry is an overlooked personal data processing operation that accumulates high-sensitivity individual data — including verbatim health and financial disclosures — in observability infrastructure that was never designed with GDPR controls. This control closes that gap by requiring telemetry to be classified, given a lawful basis, and governed with the same rigor as intentionally collected personal data.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-07", "validation_objective": "Every AI telemetry type (prompt logs, session records, inference logs, usage analytics) has a documented lawful basis, processing purpose, and maximum retention period in the RoPA; automated purge policies are active and confirmed by execution logs to be running within the required frequency; and access to all AI telemetry stores is restricted to named authorized roles with actor-attributed access logging enabled.", "evidence_required": [ "telemetry_type_inventory listing each telemetry type with lawful_basis, purpose, retention_period, access_control_policy, and RoPA entry reference", "telemetry_access_log for the audit period confirming all accesses to telemetry stores are attributed to named authorized roles with actor_id, accessed_resource, and timestamp", "purge_execution_log confirming automated purge jobs have run within the documented frequency for each telemetry store, with record counts deleted and confirmation of zero records beyond the retention window", "privacy_notice_extract confirming AI telemetry collection including prompt data and session records is disclosed to data subjects with purpose and retention period stated" ], "machine_tests": [ "Query telemetry store for records older than the documented maximum retention period → assert zero records exist beyond the retention window for each telemetry type", "Attempt to access AI telemetry store using a role not on the authorized access list → assert access is denied and the attempt is logged with actor_id and timestamp", "Submit test inference request containing structured PII in prompt → inspect the resulting telemetry log entry → assert full prompt payload is not persisted where field-level minimization controls are configured" ], "human_review": [ "Review RoPA entries for AI telemetry to confirm field-level personal data categories are documented per telemetry type, not just high-level labels such as 'usage data' or 'operational logs'", "Assess whether privacy notice language adequately discloses AI telemetry collection including prompt data in terms data subjects can reasonably understand, covering purpose and retention period", "Verify that new AI system capabilities introducing new telemetry types have undergone data governance classification review before production deployment, not as a retroactive exercise" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Treating AI telemetry including prompt logs and session records as generic operational data exempt from GDPR obligations because it is generated internally rather than collected from data subjects", "Logging full prompt and response payloads indefinitely in observability platforms with broad engineering team access and no retention limits or automated purge policies", "Classifying AI telemetry based on API field names declared by the system rather than the actual content users submit — users submit health information and financial details regardless of what a field is labeled", "Configuring field-level PII suppression as an opt-in observability setting that operators must actively enable, so personal data reaches log stores by default when suppression is omitted", "Deploying new AI capabilities — model integrations, agentic actions, voice features — without triggering a telemetry classification review gate before go-live" ], "update_status": "current", "layer_code": "DP" }, { "id": "DP-08", "layer": "DP", "plane": "data", "name": "Data Protection Evidence Log", "plain": "An evidence log demonstrates that encryption, pseudonymization, minimization, and output scrubbing controls are in place and operating effectively, with periodic verification results supporting Art 32 compliance claims.", "threat": { "tags": [ "no-evidence-of-technical-measures", "art32-compliance-undemonstrated", "controls-asserted-but-not-verified" ], "desc": "Art 32 does not require specific technical measures but requires appropriate ones that can be demonstrated. Organizations asserting that controls are in place without maintaining verification evidence cannot demonstrate compliance under Art 32(1)." }, "standard": [ { "id": "gdpr", "section": "Art 32 / Art 5(2)", "title": "Demonstrating appropriate technical measures" }, { "id": "iso_27701", "section": "6.9.4", "title": "Logging and monitoring (PII)" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records determined, documented, implemented, and reviewed" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/DP-08 Data Protection Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/DP-08 Data Protection Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/DP-08 Data Protection Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/DP-08 Data Protection Evidence Log control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/DP-08 Data Protection Evidence Log control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Establish a structured evidence log that captures periodic verification results for each DP-layer control (encryption scans, pseudonymization assessments, corpus scan reports, output scrubbing logs); index evidence to the control it verifies and the date of verification; retain for a period sufficient to support supervisory authority requests.", "steps": [ "Define an evidence schema for each DP-layer control that specifies what verification artifact is required, the frequency of verification, and the retention period", "Implement automated collection of verification artifacts where possible (encryption scan reports, purge logs, scrubbing event counts) and route them to the evidence log with control ID, verification date, and outcome", "Schedule quarterly evidence log reviews to confirm that all DP-layer controls have current verification evidence; flag controls with stale or absent evidence for remediation before the next audit cycle" ], "anti_patterns": [ "Maintaining policy documents and architecture diagrams as the only Art 32 evidence, with no verification artifacts demonstrating that controls are operating", "Collecting evidence only in response to supervisory authority requests or audit events rather than maintaining a continuous evidence log" ] }, "validation": { "design_check": [ "Confirm an evidence schema exists for each DP-layer control defining required artifact, verification frequency, and retention period [ref:gdpr_2016_679]", "Verify automated artifact collection is configured for controls that produce machine-readable outputs [ref:iso_27701_2019]", "Confirm a quarterly evidence log review is scheduled with a remediation process for controls with stale evidence [ref:nist_pf_1_0]" ], "runtime_test": [ "Query the evidence log for each DP-layer control and confirm a verification artifact is present dated within the required frequency", "Verify that automated artifact collection has run successfully for all eligible controls in the current quarter", "Confirm the evidence log access controls permit read access to auditors and DPO while restricting write access to authorized collection agents" ], "evidence": [ "privacy:evidence-log-index — Index of DP-layer control evidence entries with control ID, verification date, and artifact reference [unverified]", "privacy:evidence-completeness-report — Quarterly evidence log completeness report confirming all controls have current verification artifacts [unverified]", "privacy:evidence-access-log — Access log for the evidence log confirming access is controlled and every read/write is recorded [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The evidence log is the artifact that converts privacy engineering work into auditable compliance; without it, operational controls cannot be demonstrated to supervisory authorities or internal auditors.", "actions": [ "Define an evidence schema for each DP-layer control and implement automated collection pipelines for controls with machine-readable outputs", "Build a dashboard over the evidence log that shows coverage, artifact age, and stale-evidence alerts for each DP control", "Integrate evidence log completeness into the AI system's operational health metrics alongside latency and error rate" ], "failure_signals": [ "DP-layer controls with no verification artifact in the evidence log for the current quarter", "Evidence log containing only policy documents and architecture diagrams with no operational verification artifacts", "Evidence log not included in operational health monitoring — stale evidence goes undetected until an audit event" ] }, "dpo": { "summary": "Art 5(2) and Art 32 require the controller to demonstrate compliance; the evidence log is the primary instrument for that demonstration. DPOs must confirm that the evidence log covers all DP-layer controls, is maintained continuously, and is accessible for supervisory authority requests.", "actions": [ "Review the evidence log completeness report each quarter and sign off on coverage before the next audit cycle", "Ensure the evidence log retention period covers the statutory period for supervisory authority investigations in each jurisdiction", "Include evidence log status in the board privacy reporting pack as an indicator of Art 32 compliance posture" ], "failure_signals": [ "Evidence log completeness reports not reviewed or signed off by the DPO on a quarterly basis", "Evidence log retention period shorter than the statutory period for supervisory authority investigations", "No reference to evidence log status in board or senior management privacy reporting" ] }, "data_governance": { "summary": "The evidence log is itself a governed data asset; data governance must ensure it has defined ownership, access controls, retention policy, and a defined schema so that evidence can be consistently produced, stored, and retrieved.", "actions": [ "Catalog the evidence log as a compliance data asset with defined schema, ownership, access controls, and retention policy", "Include evidence log completeness in the AI system governance dashboard as a required metric for production approval and continued operation", "Establish a data quality check over the evidence log schema to detect malformed or incomplete artifact entries" ], "failure_signals": [ "Evidence log not catalogued as a data asset or without defined schema, ownership, or retention policy", "Evidence log completeness not included in AI system governance dashboard or production approval checklist", "No data quality checks over evidence log entries — malformed artifacts accepted without validation" ] }, "grc_auditor": { "summary": "DP-08 is the audit anchor for the entire DP layer; it provides the evidence record that demonstrates all other DP controls are operating. Audit procedure must verify that the evidence log is current, complete, and contains operational verification artifacts — not just policy documents.", "actions": [ "Request the evidence log index and verify current verification artifacts exist for each DP-layer control within the required verification frequency", "Sample three to five verification artifacts and confirm they represent operational evidence (scan results, test outputs, execution logs) rather than policy assertions", "Review evidence log access controls to confirm auditors have read access and write access is restricted to authorized collection agents" ], "metrics": [ "Percentage of DP-layer controls with a verification artifact dated within the required frequency in the evidence log", "Number of DP-layer controls with stale or absent evidence identified in the most recent quarterly completeness report" ], "failure_signals": [ "Evidence log entries for any DP-layer control dated more than two quarters ago", "Evidence log containing policy documents or procedure descriptions rather than operational verification artifacts", "No quarterly completeness report process in place — evidence gaps are not systematically identified" ] }, "software_engineering": { "summary": "Evidence collection must be automated where possible — manual artifact collection is unreliable at the verification frequencies required for continuous Art 32 compliance demonstration.", "actions": [ "Build automated evidence collection agents for each DP control that produces machine-readable outputs: encryption scanners, purge log collectors, scrubbing event aggregators", "Route all evidence artifacts to a centralized evidence store with immutable write semantics so that artifacts cannot be modified after collection", "Implement a scheduled completeness check that queries the evidence store for each control and alerts on stale or absent evidence" ], "failure_signals": [ "Evidence collection dependent on manual processes performed only before audit events", "Evidence log stored in a mutable system where artifacts could be modified or deleted after collection", "No automated completeness check — stale evidence detected only when auditors request artifacts" ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain privacy policies and procedure documents as Art 32 evidence without operational verification artifacts; DP-08 establishes the continuous evidence collection that converts controls into demonstrable compliance." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "GRC", "Security Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 32", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Art 32 requires appropriate technical measures and the ability to demonstrate them; DP-08 operationalizes the demonstration requirement through a structured evidence log with periodic verification results for each DP-layer control.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "6.9.4", "fit": "partial", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 6.9.4 extends ISO/IEC 27002 logging and monitoring guidance to PII processing; DP-08's evidence log implements that logging discipline with integrity controls suitable for audit.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "NIST Privacy Framework CT.DM-P8 requires audit/log records determined, documented, implemented, and reviewed per policy; DP-08 maintains the operational evidence log that links control verification artifacts to governance records.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS CloudTrail with S3 Object Lock — WORM evidence archive", "rationale": "AWS CloudTrail provides comprehensive API-level audit logs for all AWS AI services. Combined with S3 Object Lock in WORM (Write Once Read Many) compliance mode, organizations can create an immutable, tamper-evident data protection evidence log that satisfies regulatory requirements for audit evidence preservation and supports supervisory authority investigation requests.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail with S3 Object Lock WORM provides the immutable evidence-log substrate but not the DP-control-specific operational verification artifacts.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Compliance Manager — control evidence collection", "rationale": "Microsoft Purview Compliance Portal provides structured audit log export, evidence collection, and compliance reporting features for demonstrating data protection control effectiveness. The Unified Audit Log captures all data access and processing events across Azure AI services with searchable, exportable records suitable for regulatory submissions and evidence archive requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Compliance Manager and the Unified Audit Log collect control evidence but not the dated per-control operational verification artifacts DP-08 specifies.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Art 32 requires demonstrable appropriate technical measures — policy existence is not demonstration. The evidence log converts DP-layer control operations into an auditable record that can satisfy supervisory authority requests, support breach investigation, and confirm that controls are operating rather than merely specified. Without it, all other DP-layer controls exist only on paper.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/DP-08", "validation_objective": "A structured evidence log exists covering all DP-layer controls and each control has at least one operational verification artifact — not a policy document — dated within the required verification frequency, confirming that technical measures are operating rather than merely specified, and the log is retained long enough to support supervisory authority requests.", "evidence_required": [ "evidence_log_index listing each DP-layer control_id with the most recent verification_artifact_reference, verification_date, and artifact_type confirming it is operational evidence (scan result, test output, or execution log)", "quarterly_evidence_completeness_report confirming all DP-layer controls have current verification artifacts and documenting any controls with stale or absent evidence flagged for remediation", "evidence_log_access_control_record confirming write access is restricted to authorized collection agents and read access is available to auditors and DPO, with actor-attributed access log", "automated_collection_pipeline_status report confirming collection agents for machine-readable controls (encryption scanners, purge log collectors, scrubbing event aggregators) executed successfully within the current quarter" ], "machine_tests": [ "Query evidence log for each DP-layer control_id → assert at least one verification artifact exists with a verification_date within the required frequency window (e.g., within 90 days for quarterly controls)", "Attempt to write an evidence record using a non-authorized agent identity → assert write is rejected and the attempt is logged with actor_id and timestamp", "Query evidence log for entries where artifact_type is 'policy-document' or 'procedure-description' → assert zero such entries exist (schema enforces only operational artifact types)" ], "human_review": [ "Sample three to five verification artifacts from the evidence log and confirm they represent operational evidence (scan results, execution logs, test outputs) rather than policy assertions or architecture diagrams", "Review evidence log retention period against the statutory period for supervisory authority investigations in each relevant jurisdiction to confirm artifacts will be available when needed", "Assess whether the evidence schema for each DP-layer control is specific enough to distinguish operational verification from documentation — vague schemas allow non-compliance to masquerade as evidence" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Maintaining policy documents, procedure descriptions, or architecture diagrams as the primary Art 32 evidence without operational verification artifacts demonstrating controls are functioning", "Collecting evidence only in response to audit events or supervisory authority investigations rather than maintaining a continuous evidence log with defined verification frequency per control", "Storing the evidence log in a mutable system where verification artifacts can be modified or deleted after collection, undermining the integrity of the compliance record", "Failing to define an artifact type schema per control — accepting any document as 'evidence' without specifying what the artifact must demonstrate and how recently it must be dated", "Reporting evidence log completeness as the percentage of controls with any artifact present rather than controls with current artifacts within the defined verification frequency" ], "update_status": "current", "layer_code": "DP" }, { "id": "PM-01", "layer": "PM", "plane": "data", "name": "Privacy Incident Detection", "plain": "Personal data breaches involving AI systems — unauthorized access, exfiltration, PII-bearing model outputs, or inference attacks — are detected and the breach response workflow is triggered within the 72-hour notification window.", "threat": { "tags": [ "undetected-breach", "delayed-detection-exceeding-72h", "ai-specific-attack-vectors-missed" ], "desc": "AI-specific breach vectors — model memorization exposure, embedding inversion, membership inference — are not covered by traditional DLP and SIEM rules. Breaches missed by inadequate AI-aware detection miss the 72-hour supervisory notification window." }, "standard": [ { "id": "gdpr", "section": "Art 33/Art 32", "title": "Breach detection and notification obligations" }, { "id": "ccpa", "section": "§1798.150", "title": "Private right of action for personal information breaches" }, { "id": "nist_pf", "section": "PR.DS-P5", "title": "Protections against data leaks are implemented" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-01 Privacy Incident Detection control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Deploy AI-aware detection rules in SIEM that flag model memorization queries, embedding inversion attempts, and anomalous PII egress from inference endpoints. Integrate detection alerts into the breach response workflow with automated 72-hour countdown initiation.", "steps": [ "Extend existing DLP and SIEM policies with AI-specific detection signatures covering prompt injection exfiltration, high-cardinality PII outputs, and inference endpoint anomalies.", "Define a breach intake form that records detection time, estimated scope, data categories affected, and the identity of the discovering system or analyst.", "Automate the 72-hour notification clock by triggering a tracked workflow task at detection time, with escalation paths to the DPO and legal counsel.", "Conduct quarterly tabletop exercises simulating AI-specific breach scenarios to validate detection coverage and response time SLAs." ], "anti_patterns": [ "Relying solely on generic network DLP rules that have no coverage for inference API responses or model output channels.", "Treating all AI incidents as security incidents without a parallel privacy triage that assesses whether personal data was affected." ] }, "validation": { "design_check": [ "Confirm SIEM rules exist for AI inference endpoint anomalies [ref:gdpr_2016_679]", "Verify breach response workflow includes automatic 72-hour SLA timer [ref:gdpr_2016_679]", "Confirm PII egress monitoring covers model output channels [ref:nist_pf_1_0]" ], "runtime_test": [ "Simulate a synthetic membership inference pattern on a test model and verify SIEM alert fires within detection SLA.", "Trigger a canary PII token in a model input and confirm egress monitoring captures it in the output channel.", "Inject a test breach notification event and verify the 72-hour countdown task is created and assigned correctly." ], "evidence": [ "privacy:siem-alert — AI-specific detection rule inventory with coverage assessment [unverified]", "privacy:breach-workflow — Breach response workflow documentation showing 72-hour SLA tracking [unverified]", "privacy:tabletop-record — Quarterly AI breach simulation exercise records [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Implement AI-aware detection hooks at inference endpoints to catch both active attacks and passive data leakage through model outputs.", "actions": [ "Instrument inference APIs with PII detection middleware that checks outputs before logging.", "Build query pattern analysis to detect high-cardinality extraction probing.", "Integrate detection signals with the breach response workflow via event bus." ], "failure_signals": [ "SIEM has no rules specific to AI inference endpoints.", "Breach detection relies on user reports rather than automated monitoring.", "PII egress rules stop at the API gateway and do not cover model response bodies." ] }, "dpo": { "summary": "Ensure the breach detection program explicitly covers AI-specific attack vectors and that the 72-hour notification clock starts at detection, not at breach confirmation.", "actions": [ "Review detection coverage assessment for AI-specific breach scenarios annually.", "Confirm the breach intake procedure records detection timestamp for SLA calculation.", "Maintain documented evidence of breach exercises covering AI inference attack scenarios." ], "failure_signals": [ "No documented assessment of AI-specific detection coverage gaps.", "72-hour clock is started manually by the DPO rather than automatically at detection.", "Breach register contains no entries for AI-related incidents despite active AI processing." ] }, "data_governance": { "summary": "Align breach detection coverage with the AI processing activity register to ensure all active AI data flows have corresponding monitoring.", "actions": [ "Cross-reference the AI processing register with SIEM rule coverage to identify unmonitored flows.", "Require new AI processing activities to complete a detection readiness gate before go-live.", "Track detection coverage ratio as a governance KPI reported quarterly to leadership." ], "failure_signals": [ "Processing register lists AI activities with no corresponding detection rule.", "New model deployments go live without breach detection review.", "Governance reporting has no metrics on breach detection coverage or response time." ] }, "grc_auditor": { "summary": "Audit the completeness of AI breach detection coverage and verify that the notification clock mechanics meet the 72-hour GDPR requirement.", "actions": [ "Review SIEM rule inventory against AI processing activities for coverage gaps.", "Test breach notification workflow timing using a simulated incident.", "Examine breach register for completeness of detection-to-notification time recording." ], "metrics": [ "Mean time to detect AI privacy incident (target: < 4 hours)", "Percentage of AI processing activities with active SIEM coverage" ], "failure_signals": [ "Detection rule inventory cannot be mapped to specific AI processing activities.", "Breach notification workflow timing cannot be reconstructed from logs.", "Breach register entries lack detection timestamps." ] }, "software_engineering": { "summary": "Instrument inference endpoints and log pipelines to emit structured privacy-relevant signals that feed SIEM detection rules.", "actions": [ "Add structured logging to inference handlers that records input size, output PII score, and request metadata.", "Implement canary token injection in test data sets to validate egress monitoring end-to-end.", "Expose a health endpoint that reports current detection rule status for operational observability." ], "failure_signals": [ "Inference endpoints emit unstructured logs that cannot be parsed by SIEM rules.", "No automated test validates that PII in model outputs is captured by monitoring.", "Detection instrumentation is opt-in and not enforced by the deployment pipeline." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Detection coverage for AI-specific vectors is typically absent at initial maturity; defined maturity requires documented rules with gap analysis." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Security Operations", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 33", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 33 mandates notification to the supervisory authority within 72 hours of becoming aware of a breach; PM-01 detection controls directly enable this by minimising time-to-aware.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.150 (private right of action)", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Section 1798.150 creates a private right of action for breaches of unencrypted personal information; PM-01 detection reduces breach scope and supports documentation of the security measures in place.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "PR.DS-P5", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PM-01 implements NIST Privacy Framework PR.DS-P5 — protections against data leaks are implemented — extending leak detection to AI-specific vectors such as memorization probing and embedding inversion, and triggering the response lifecycle.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Core element — Extend detection and response to bring AI into the organization's threat universe", "rationale": "SAIF's second core element requires extending detection and response to AI-specific threats; PM-01 implements the privacy-facing detection rules — memorization probing, embedding inversion, anomalous PII egress — that bring AI incidents into the enterprise threat universe.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF's extend-detection-and-response element directs bringing AI incidents into the threat universe, aligning with PM-01 but not its specific privacy rules.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon Macie — sensitive data discovery and anomaly findings", "rationale": "Amazon Macie continuously monitors S3 data repositories for anomalous access patterns and generates security findings when sensitive personal data is accessed unexpectedly or exfiltrated. Macie integrates with AWS Security Hub for centralized incident alerting and with EventBridge for automated response workflows, providing automated privacy incident detection for AI data stores.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Macie detects anomalous access/exfiltration of sensitive S3 data with automated response, covering data-store vectors but not model-specific ones.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Insider Risk Management — risky data-handling detection", "rationale": "Microsoft Purview Insider Risk Management detects privacy-relevant risks including anomalous access to sensitive AI datasets, mass data downloads, and unauthorized data movement. Integration with Azure Sentinel SIEM enables automated privacy incident response workflows triggered by Purview risk signals, supporting the detection requirements of GDPR Art 32 appropriate technical measures.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Insider Risk Management detects anomalous access to sensitive AI data via Sentinel, covering data-handling vectors but not model-attack detection.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "PM-01 deploys SIEM rules detecting model-memorization probing, embedding inversion, and anomalous PII egress from inference endpoints, monitoring model use for abuse.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"The organization has deployed documented AI-specific SIEM detection rules covering model…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "AI systems introduce breach vectors that traditional DLP and SIEM tools cannot detect. PM-01 establishes AI-aware monitoring that closes the detection gap, ensuring the 72-hour notification window is preserved even for inference-layer attacks.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-01", "validation_objective": "The organization has deployed documented AI-specific SIEM detection rules covering model memorization probing, embedding inversion attempts, anomalous PII egress from inference endpoints, and high-cardinality extraction patterns; and the breach response workflow automatically initiates the Art 33 72-hour notification clock at the point of automated detection, not at manual human confirmation.", "evidence_required": [ "ai_specific_siem_rule_inventory listing each detection rule with the AI breach vector it covers, last validation date, and mapping to at least one AI processing activity in the processing register", "breach_response_workflow_documentation showing the 72-hour SLA timer is triggered automatically at detection_timestamp with a tracked task assigned to the DPO or privacy team", "ai_breach_simulation_tabletop_record for the most recent quarterly exercise including the AI-specific scenario tested, detection time measured, and response time against the SLA", "pii_egress_monitoring_coverage_report confirming inference API output channels are covered by PII detection rules, not only network-layer DLP rules that miss model response body content" ], "machine_tests": [ "Simulate synthetic membership inference probing pattern against a test model endpoint → assert the AI-specific SIEM detection rule fires within the documented detection SLA and creates a breach intake record with detection_timestamp", "Inject canary PII token (synthetic structured identifier not present in any real dataset) into model input → submit inference request → assert egress monitoring captures the canary in the output channel log within the alert latency SLA", "Trigger test breach notification event in the breach workflow system → assert a 72-hour countdown task is created, assigned to DPO, and cannot be closed without a documented disposition field" ], "human_review": [ "Review AI-specific SIEM rule inventory against the AI processing activity register to identify active AI data flows with no corresponding detection rule coverage", "Assess whether breach detection tabletop exercises cover AI-specific attack vectors beyond conventional data breach scenarios — including membership inference, model inversion, and prompt injection exfiltration", "Verify the breach intake procedure records the automated detection_timestamp as the Art 33 SLA start, not the time a human analyst manually confirms or classifies the incident" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Relying solely on network-layer DLP rules that operate at the API gateway and have no visibility into model response body content or inference endpoint output patterns", "Starting the 72-hour Art 33 notification clock from the time of human analyst confirmation rather than automated detection, systematically shrinking the available notification window", "Treating AI privacy incidents exclusively as security incidents without a parallel privacy triage layer assessing which data categories were exposed and whether Art 33 notification is required", "Operating breach detection exclusively through user-reported incidents for AI systems with no automated monitoring rules covering AI-specific attack vectors", "Failing to extend breach detection rule coverage to new AI processing activities before go-live, relying on post-deployment retroactive rule additions" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-02", "layer": "PM", "plane": "data", "name": "Cross-Context Inference Monitoring", "plain": "AI inferences that cross context boundaries — using data provided in one context to infer sensitive attributes relevant to another — are detected and assessed for compatibility with the original consent and purpose.", "threat": { "tags": [ "contextual-integrity-violation", "sensitive-attribute-inference-from-innocuous-data", "consent-scope-exceeded-by-inference" ], "desc": "Contextual integrity violations occur when AI systems use data provided in one social context (e.g., a social media profile) to make inferences appropriate only in another context (e.g., a credit decision). EDPB Opinion 28/2024 explicitly addresses cross-context inference as an AI-specific privacy risk." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(b)/Art 9", "title": "Purpose limitation and special category data" }, { "id": "edpb_opinion_28_2024", "section": "Opinion §3.3", "title": "Legitimate interest assessment for AI model processing" }, { "id": "nist_pf", "section": "CT.DP-P1", "title": "Data processed to limit observability and linkability" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "edpb_opinion_28_2024", "title": "EDPB Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models", "authority": "European Data Protection Board", "source_type": "supervisory-guidance", "normative_force": "supervisory-guidance", "version": "28/2024", "published_on": "2024-12-17", "retrieved_on": "2026-06-28", "canonical_url": "https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "edpb_opinion_28_2024", "relationship": "supporting_guidance", "rationale": "Establishes EDPB Opinion 28/2024 — Data Protection Aspects Related to AI Models requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-02 Cross-Context Inference Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Tag all data inputs with their originating context and consent scope, then instrument inference pipelines to flag outputs that combine signals from incompatible contexts or produce special-category attributes not covered by the original lawful basis.", "steps": [ "Establish a context taxonomy that categorises data by its originating social context, consent scope, and permitted downstream inference types.", "Tag data records at ingestion with context metadata and propagate those tags through the feature engineering and inference pipeline.", "Implement an inference output classifier that flags outputs involving special-category attributes (health, political opinion, religion, etc.) for compatibility review.", "Route flagged inferences to a privacy review queue where the DPO or privacy engineer confirms or blocks processing before results are used." ], "anti_patterns": [ "Treating all data from a single consented data source as uniformly shareable across inference contexts without compatibility assessment.", "Allowing model outputs to include sensitive attribute inferences without checking whether the input data context permitted that inference type." ] }, "validation": { "design_check": [ "Verify context taxonomy document exists and covers all active data sources [ref:gdpr_2016_679]", "Confirm inference pipeline has output classification for special-category attribute detection [ref:edpb_opinion_28_2024]", "Review privacy review queue routing logic for cross-context inference flags [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit a synthetic cross-context inference request combining social context data with a financial decision endpoint and verify the flag fires.", "Inject a test input designed to elicit a health-related inference and confirm the output classifier captures it.", "Verify that a flagged inference correctly routes to the privacy review queue and cannot be consumed by downstream services until reviewed." ], "evidence": [ "privacy:context-taxonomy — Data context taxonomy document with consent scope mappings [unverified]", "privacy:inference-flags — Cross-context inference flag log with review disposition records [unverified]", "privacy:output-classifier — Special-category attribute classifier validation report [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Instrument the inference pipeline with context propagation and output classification to detect when inferences cross the boundaries established by original consent.", "actions": [ "Build a context propagation layer that carries source context metadata through feature extraction and into the inference call.", "Train or configure an output classifier to identify special-category attributes in model responses.", "Expose a review API that queues flagged inferences for DPO disposition before result consumption." ], "failure_signals": [ "Feature engineering merges data from multiple contexts without context tag preservation.", "Model outputs are consumed by downstream services before privacy review of special-category flags.", "Context taxonomy does not cover all active model input sources." ] }, "dpo": { "summary": "Maintain the context taxonomy as a living document and ensure that cross-context inference flags receive timely review with documented disposition.", "actions": [ "Review and approve context taxonomy updates when new data sources or model use cases are introduced.", "Set and enforce SLAs for privacy review queue disposition (e.g., 48 hours for special-category flags).", "Maintain a register of cross-context inference decisions including approval rationale or blocking grounds." ], "failure_signals": [ "Context taxonomy has not been updated to reflect current AI use cases.", "Privacy review queue has a backlog exceeding the defined SLA.", "Cross-context inference decisions are not documented with rationale." ] }, "data_governance": { "summary": "Govern the context taxonomy and ensure inference pipeline changes are assessed for cross-context compatibility before deployment.", "actions": [ "Include cross-context inference assessment in the AI change management gate.", "Maintain a data lineage record that maps each model feature to its originating context.", "Report cross-context inference flag rates and review outcomes in governance dashboards." ], "failure_signals": [ "Model retraining or feature addition bypasses cross-context compatibility assessment.", "Data lineage records cannot be traced back to originating consent context.", "Governance reporting has no visibility into cross-context inference volumes." ] }, "grc_auditor": { "summary": "Audit whether the cross-context inference monitoring program aligns with EDPB Opinion 28/2024 expectations and covers all active AI inference use cases.", "actions": [ "Review the context taxonomy against the AI processing register to confirm coverage.", "Sample cross-context inference flag records and verify disposition was documented and timely.", "Assess whether the output classifier has been validated on representative test cases." ], "metrics": [ "Percentage of AI inference use cases covered by context taxonomy", "Mean time to disposition for cross-context inference flags (target: < 48 hours)" ], "failure_signals": [ "AI processing activities exist that are not mapped to any context taxonomy entry.", "Flag disposition records are incomplete or lack rationale.", "Output classifier validation has never been performed or is undocumented." ] }, "software_engineering": { "summary": "Implement context tag propagation as a first-class concern in the inference stack so that cross-context signals cannot be silently merged.", "actions": [ "Add context metadata to the inference request schema and enforce its presence at the API layer.", "Implement a middleware layer that validates context compatibility before allowing feature merges.", "Write unit tests that confirm context tags are preserved through all transformation stages." ], "failure_signals": [ "Context metadata is an optional field that is frequently omitted in production requests.", "Feature merges are performed without context compatibility validation.", "No automated tests confirm context tag propagation through the pipeline." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most organisations have no context tagging infrastructure; reaching managed maturity requires automated context propagation and classifier-driven review queues." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "ML Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 9", "fit": "partial", "direction": "control-supports-requirement", "rationale": "Article 9 prohibits processing of special-category data without an explicit basis; PM-02 detects when inferences produce special-category outputs that may exceed the original lawful basis.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "edpb_opinion_28_2024", "requirement_id": "Opinion §3.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "EDPB Opinion 28/2024 §3.3 makes the legitimate-interest basis for AI processing turn in part on data subjects' reasonable expectations; cross-context inference beyond the original collection context undermines those expectations, and PM-02 provides the monitoring evidence to detect it.", "source_version": "28/2024", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "supervisory-guidance", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "supervisory-guidance", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DP-P1", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "PM-02 monitors for violations of NIST Privacy Framework CT.DP-P1 — data are processed to limit observability and linkability — by detecting when model outputs link or infer across contexts beyond the authorized processing scope.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Inferred Sensitive Data risk — Output Validation and Sanitization", "rationale": "SAIF's Inferred Sensitive Data risk covers models deriving sensitive attributes not provided to them, mitigated by Output Validation and Sanitization; PM-02's cross-context monitoring detects exactly this class of output.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF's Inferred Sensitive Data output validation detects the sensitive-attribute inferences PM-02 targets, though without its context taxonomy and review queue.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview DSPM for AI — AI interaction monitoring", "rationale": "Microsoft Purview Data Security Posture Management (DSPM) for AI monitors AI interaction data for sensitive information exposure across Copilot and third-party AI applications; PM-02 applies the same monitoring posture to cross-context inference signals.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Purview DSPM for AI monitors general sensitive-info exposure in AI interactions but not the context-boundary inference detection central to PM-02.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon SageMaker Model Monitor — data and model quality drift detection", "rationale": "AWS SageMaker Model Monitor continuously monitors deployed ML models for data quality drift, model quality drift, and bias metric changes that may indicate cross-context inference issues. Scheduled monitoring jobs compare current model behavior against baseline distributions, alerting when outputs deviate in ways that may signal unauthorized use of personal data from unintended contexts.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SageMaker Model Monitor detects data/model drift as a loose proxy that may hint at cross-context use but does not detect cross-context inference directly.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "sensitiveoutputhandling", "fit": "supporting", "rationale": "PM-02 uses a runtime output classifier to detect special-category attribute inferences and holds them in a review queue before returning results, handling sensitive inferred output.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0020", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"All active AI inference use cases are mapped in a context taxonomy defining the…\" enacts ATLAS mitigation AML.M0020 Generative AI Guardrails; OpenCRE crosswalks this control’s OWASP AI Exchange concept (sensitiveoutputhandling) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Cross-context inference is the defining AI-specific privacy risk identified by the EDPB. PM-02 introduces the monitoring infrastructure — context tagging, output classification, and review queuing — that makes contextual integrity a verifiable property of inference pipelines rather than an aspirational design intent.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-02", "validation_objective": "All active AI inference use cases are mapped in a context taxonomy defining the originating data context and permitted downstream inference types; an output classifier detects special-category attribute inferences at runtime; and flagged cross-context inferences are held in a privacy review queue that must be dispositioned before the inference result is returned to downstream consuming services.", "evidence_required": [ "context_taxonomy_document mapping each active AI data source to its originating social context, consent scope, and permitted downstream inference types, with coverage confirmed against the AI processing register", "output_classifier_validation_report demonstrating the special-category attribute classifier (health, political opinion, religion, sexual orientation, financial situation) achieves acceptable precision and recall on a representative labeled test dataset", "cross_context_inference_flag_log for the audit period recording flagged inferences with source_context, output_attribute_type, disposition, reviewer_identity, and disposition_timestamp", "privacy_review_queue_disposition_records showing each flagged inference was reviewed within the defined SLA with documented approval rationale or blocking grounds — not bulk approvals" ], "machine_tests": [ "Submit synthetic cross-context inference request combining social media context data with a financial decision endpoint → assert context incompatibility flag fires and inference result is withheld from the downstream caller pending review", "Inject test input designed to elicit health-related inference from a non-healthcare context → assert output classifier captures the flag and routes to privacy review queue rather than returning result to caller", "Attempt to consume a flagged inference result from a downstream service API before it is dispositioned in the privacy review queue → assert downstream API returns an error indicating the inference is pending privacy review" ], "human_review": [ "Review context taxonomy to confirm it covers all active AI inference use cases and has been updated to reflect model capability changes or new data source integrations since the last review", "Assess whether the output classifier has been validated on representative test cases covering all nine Art 9 special-category attribute types and verified for an acceptable false-negative rate", "Review a sample of privacy review queue disposition records to confirm approvals include documented compatibility rationale and blockings include documented grounds — not blanket approvals without per-inference assessment" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Treating all data from a single consented data source as uniformly shareable across inference contexts without assessing whether the downstream inference type falls within the original consent scope", "Allowing flagged cross-context inferences to be consumed by downstream services before privacy review queue disposition, treating the flag as informational rather than blocking", "Defining context taxonomy entries at a level of abstraction that cannot be operationalized as classifier rules — 'marketing context' does not specify which inference types are compatible versus incompatible with the original consent", "Operating context tagging as an optional field in the inference request schema that is frequently omitted in production, creating systematic monitoring blind spots", "Reviewing cross-context inference flags in bulk with blanket approvals rather than assessing each flagged inference type against the specific consent scope of the originating data source" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-03", "layer": "PM", "plane": "data", "name": "Purpose Creep Detection", "plain": "Automated monitoring detects when AI processing expands beyond documented collection purposes and triggers a compatibility assessment or processing suspension before the drift becomes a violation.", "threat": { "tags": [ "purpose-creep-undetected", "processing-beyond-valid-lawful-basis", "regulatory-non-compliance" ], "desc": "Purpose creep in AI systems is subtle: a model retrained on a broader data slice, a new feature using existing inference data, or an API integration expanding the downstream use. Without monitoring against the purpose register, violations accumulate undetected until DPA inquiry." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(b)/Art 6(4)", "title": "Purpose limitation and compatibility assessment" }, { "id": "iso_27701", "section": "7.2.2", "title": "Monitoring of processing purposes" }, { "id": "nist_pf", "section": "GV.MT-P1", "title": "Privacy risk re-evaluated on an ongoing basis" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-03 Purpose Creep Detection control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a machine-readable purpose register and automatically compare active AI processing operations against registered purposes; flag and suspend any processing that cannot be matched to a documented, lawful purpose.", "steps": [ "Build or adopt a machine-readable purpose register that records each processing activity with its lawful basis, data categories, and permitted downstream uses.", "Instrument AI pipeline deployments to emit processing metadata tags that can be matched against the purpose register at runtime.", "Implement a reconciliation job that runs on a defined schedule (e.g., daily) to detect processing operations not present in or inconsistent with the register.", "Route purpose-creep alerts to the DPO for compatibility assessment under Art 6(4) criteria before the affected processing is allowed to continue." ], "anti_patterns": [ "Maintaining a purpose register as a static document that is updated only when a DPIA is triggered, rather than as a live record compared against actual processing.", "Allowing model retraining or feature additions to proceed without a purpose compatibility check gate in the CI/CD pipeline." ] }, "validation": { "design_check": [ "Verify purpose register is machine-readable and actively maintained [ref:gdpr_2016_679]", "Confirm AI pipeline deployments emit purpose metadata tags [ref:iso_27701_2019]", "Check that reconciliation job schedule and alert routing are configured [ref:nist_pf_1_0]" ], "runtime_test": [ "Deploy a synthetic AI processing activity with no corresponding purpose register entry and verify an alert is generated within one reconciliation cycle.", "Modify a test processing activity to exceed its registered data category scope and confirm the mismatch is flagged.", "Verify that a flagged purpose-creep alert correctly suspends processing until DPO disposition is recorded." ], "evidence": [ "privacy:purpose-register — Machine-readable purpose register with version history [unverified]", "privacy:reconciliation-log — Purpose reconciliation job run logs with alert disposition records [unverified]", "privacy:compatibility-assessment — Art 6(4) compatibility assessment records for flagged activities [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design the purpose register as a queryable API and instrument pipelines to self-declare their processing purpose at deployment time for automated reconciliation.", "actions": [ "Define a purpose declaration schema and enforce its submission as part of the pipeline deployment manifest.", "Build a reconciliation service that compares declared purposes against the register and emits structured alerts for mismatches.", "Implement a circuit-breaker pattern that suspends processing when purpose status is unknown or contested." ], "failure_signals": [ "Purpose register is maintained in a spreadsheet with no API interface.", "Pipeline deployments do not include purpose declarations.", "No mechanism exists to suspend processing pending purpose review." ] }, "dpo": { "summary": "Own the purpose register and ensure that all purpose-creep alerts receive a documented compatibility assessment before processing resumes.", "actions": [ "Review and approve all new purpose register entries before they are activated.", "Respond to purpose-creep alerts with a documented Art 6(4) compatibility assessment within a defined SLA.", "Maintain an audit trail of purpose register changes, compatibility assessments, and suspension decisions." ], "failure_signals": [ "Purpose register entries are added by engineering teams without DPO review.", "Purpose-creep alerts are acknowledged but not followed by documented compatibility assessments.", "Register change history is not maintained, preventing reconstruction of processing history." ] }, "data_governance": { "summary": "Integrate purpose compliance into the AI change management lifecycle so that purpose creep is caught before deployment rather than after.", "actions": [ "Require purpose compatibility sign-off as a blocking gate in the AI deployment approval workflow.", "Include purpose register coverage in quarterly data governance health metrics.", "Establish a cross-functional purpose review committee for processing activities involving sensitive categories." ], "failure_signals": [ "AI deployments proceed without purpose compatibility review.", "Data governance metrics do not track purpose register coverage or alert volumes.", "No formal escalation path exists for cross-context purpose disputes." ] }, "grc_auditor": { "summary": "Audit whether the purpose register is current, whether processing activities can be matched to register entries, and whether purpose-creep alerts are resolved within policy.", "actions": [ "Sample active AI processing activities and verify each has a matching purpose register entry.", "Review purpose-creep alert records for timeliness and documentation quality.", "Assess compatibility assessment quality against the Art 6(4) criteria checklist." ], "metrics": [ "Percentage of active AI processing activities matched to a purpose register entry (target: 100%)", "Mean time to resolve purpose-creep alert (target: < 5 business days)" ], "failure_signals": [ "Active AI processing activities cannot be matched to register entries.", "Purpose-creep alerts are closed without documented assessments.", "Purpose register has not been reviewed or updated in the past quarter." ] }, "software_engineering": { "summary": "Treat the purpose declaration as a required deployment artifact and integrate purpose compliance checks into the CI/CD pipeline.", "actions": [ "Add purpose declaration validation to the deployment pipeline as a blocking lint step.", "Version purpose declarations alongside code so that register and implementation stay in sync.", "Write integration tests that simulate purpose-creep scenarios and assert that the circuit-breaker fires." ], "failure_signals": [ "Purpose declarations are optional in the deployment pipeline.", "Code changes that expand data usage do not trigger purpose declaration review.", "No integration tests exist for purpose-creep detection logic." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Initial maturity typically has a static purpose register; defined maturity requires automated reconciliation with documented alert handling." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Data Governance", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(1)(b)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 5(1)(b) codifies the purpose limitation principle; PM-03 provides the operational monitoring mechanism that makes purpose limitation enforceable in AI processing environments.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.2.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO 27701 clause 7.2.2 requires monitoring of processing purposes against documented policies; PM-03 directly implements this requirement with automated reconciliation.", "source_version": "2019", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "certification-standard", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "GV.MT-P1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PM-03 implements NIST Privacy Framework GV.MT-P1 — privacy risk is re-evaluated on an ongoing basis as data processing and systems change — through automated reconciliation of live AI processing against the registered purpose baseline.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Unauthorized Training Data risk — Training Data Management", "rationale": "SAIF's Unauthorized Training Data risk covers use of data that is not authorized for training; PM-03's purpose-creep detection identifies when AI processing drifts beyond its authorized purpose — the privacy-side expression of the same risk, mitigated through Training Data Management.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's Unauthorized Training Data risk is conceptually related but not PM-03's ongoing purpose-register reconciliation and drift-suspension mechanism.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Config custom rules — configuration compliance checks", "rationale": "AWS Config can be configured with custom compliance rules that detect when AI services are accessing or processing data beyond their defined processing scope. Config rules can monitor data access patterns against the registered purpose baseline and trigger notifications when AI workloads access data categories not included in their documented processing purpose.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Config custom rules can detect AI access beyond a registered purpose baseline and notify, providing a drift-detection mechanism aligned with PM-03.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — accountability and ongoing review", "rationale": "The Microsoft Responsible AI Standard v2 accountability goals require defined oversight of AI systems against their intended uses; PM-03 operationalizes that review for processing-purpose drift.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Microsoft RAI's accountability and ongoing-review goal calls for oversight against intended use but not the automated purpose-drift detection PM-03 needs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "PM-03 detects any AI processing activity not matching a registered purpose and suspends it pending Art 6(4) assessment, keeping processing within allowed purposes.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Purpose creep in AI systems is systematic and cumulative, driven by incremental model changes and pipeline integrations that each appear innocuous in isolation. PM-03 makes purpose compliance a continuously monitored property by treating the purpose register as a live operational constraint rather than a DPIA artefact.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-03", "validation_objective": "The purpose register is machine-readable, actively maintained, and every active AI processing activity matches a registered purpose entry; any processing operation not present in or inconsistent with the register is detected within one reconciliation cycle and suspended pending DPO compatibility assessment under Art 6(4).", "evidence_required": [ "machine_readable_purpose_register with version history, each entry containing lawful_basis, data_categories, permitted_downstream_uses, and DPO_approved_at timestamp", "AI pipeline deployment manifests containing purpose_declaration_tag fields that resolve to valid purpose register entries at deployment time", "purpose_reconciliation_job_run_logs showing comparison results, alert records with alert_id and triggered_at, and DPO disposition record (assessed/suspended/resumed) for each flagged mismatch", "art_6_4_compatibility_assessment records for each purpose-creep alert, documenting assessment criteria, outcome, and processing resume or permanent suspension decision", "CI/CD pipeline gate records showing purpose compatibility sign-off as a blocking step for each AI pipeline deployment" ], "machine_tests": [ "Deploy a test AI pipeline with no matching purpose register entry → assert reconciliation job generates a purpose-mismatch alert within one scheduled cycle and processing is suspended", "Modify a registered test processing activity to expand its data_categories beyond its register entry → assert the mismatch is detected and flagged within the next reconciliation window", "Submit a deployment manifest with a purpose_declaration_tag referencing a non-existent register entry → assert the CI/CD gate holds the pipeline for DPO review before deployment", "Restore the test pipeline to a valid purpose declaration after suspension → assert the resume event is recorded in the reconciliation log with DPO sign-off reference" ], "human_review": [ "Review the purpose register for currency and completeness, confirming every active AI processing activity has a corresponding entry with DPO sign-off and no processing operates under an unapproved purpose", "Assess a sample of Art 6(4) compatibility assessment records against the GDPR criteria checklist (link to original purpose, context of collection, nature of data, consequences, safeguards) to verify reasoning quality and consistency", "Inspect CI/CD pipeline configuration to confirm purpose declaration validation is a non-bypassable blocking gate and that engineering teams cannot self-approve purpose expansions" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Maintaining the purpose register as a static PDF or spreadsheet updated only when a DPIA is triggered, making it impossible to automate reconciliation against running AI processing activities", "Allowing model retraining or feature additions to proceed without a purpose compatibility gate in the CI/CD pipeline, discovering purpose drift only during DPA examination", "Configuring the reconciliation job to emit alerts only without a circuit-breaker that suspends processing pending DPO disposition, resulting in detected violations that continue unabated", "Characterising a broad purpose statement such as 'improving AI services' as satisfying all downstream uses without mapping specific data categories and volumes to specific registered purposes", "Closing purpose-creep alerts as 'acknowledged' without a documented Art 6(4) compatibility assessment, creating an evidence trail that shows awareness of violations but not resolution" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-04", "layer": "PM", "plane": "data", "name": "Consent State Consistency Monitoring", "plain": "Continuous monitoring checks for inconsistencies between the consent registry and actual processing activity, detecting processing occurring after withdrawal or without a valid consent signal.", "threat": { "tags": [ "processing-after-withdrawal", "consent-state-desynchronization", "stale-consent-relied-upon" ], "desc": "Distributed AI systems — with multiple microservices, external processors, and regional deployments — frequently operate with stale consent state due to propagation delays or failures. Monitoring that detects the gap between registry state and actual processing is the only mechanism to catch this before a DPA does." }, "standard": [ { "id": "gdpr", "section": "Art 7(1)/Art 6(1)(a)", "title": "Validity of consent" }, { "id": "iso_27701", "section": "7.2.4", "title": "Obtaining and recording consent" }, { "id": "nist_pf", "section": "CT.PO-P1", "title": "Authorizing, revoking, and maintaining data processing authorizations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "okta_nhi_agent_identity_2025", "title": "Secure and Govern Non-Human Identities (NHIs) at Scale", "authority": "Okta, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2025", "published_on": "2025-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.okta.com/solutions/protect-non-human-identities/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "okta_nhi_agent_identity_2025", "relationship": "informative_reference", "rationale": "Establishes Secure and Govern Non-Human Identities (NHIs) at Scale requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PM-04 Consent State Consistency Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Implement a consent state synchronisation layer that broadcasts withdrawal events to all consuming services in near-real-time, combined with a periodic consistency check that validates that no processing has occurred against withdrawn consent records.", "steps": [ "Publish consent withdrawal events to an event bus with guaranteed delivery semantics and a maximum propagation SLA (e.g., 15 minutes to all consumers).", "Implement consumer-side consent state caches that subscribe to the withdrawal event stream and invalidate locally cached consent immediately upon receipt.", "Run a nightly reconciliation query that compares processing logs against the consent registry to identify any processing that occurred after a withdrawal timestamp.", "Alert the DPO and Privacy Engineering on any confirmed post-withdrawal processing, with automated suspension of the affected processing activity pending investigation." ], "anti_patterns": [ "Maintaining consent state as a per-service local cache with no event-driven invalidation, relying instead on TTL-based expiry.", "Treating consent withdrawal as a batch process that takes 24-72 hours to propagate, creating a structural window for unlawful processing." ] }, "validation": { "design_check": [ "Confirm consent withdrawal events are published with guaranteed delivery and defined propagation SLA [ref:gdpr_2016_679]", "Verify all AI processing services subscribe to consent withdrawal event stream [ref:iso_27701_2019]", "Confirm nightly reconciliation job compares processing logs against consent registry [ref:nist_pf_1_0]" ], "runtime_test": [ "Withdraw consent for a synthetic test subject and measure the time for all processing services to reflect the withdrawal.", "Verify that the reconciliation job detects a simulated post-withdrawal processing record and generates an alert.", "Confirm that automated suspension activates correctly when post-withdrawal processing is detected." ], "evidence": [ "privacy:event-bus-config — Consent withdrawal event bus configuration with delivery guarantee documentation [unverified]", "privacy:reconciliation-results — Consent consistency reconciliation job results with anomaly records [unverified]", "privacy:suspension-log — Automated processing suspension log showing response to consent inconsistencies [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design consent state as an event-driven system with guaranteed propagation so that withdrawal is treated as a first-class operational event rather than a database update.", "actions": [ "Implement consent withdrawal as an outbox pattern with at-least-once delivery guarantees.", "Build a consent state service that exposes a low-latency check API for consuming services to validate before processing.", "Create a reconciliation pipeline that compares event log timestamps against processing logs to detect propagation gaps." ], "failure_signals": [ "Consent state is replicated via batch ETL with no event-driven invalidation.", "Processing services check consent state at request time but do not subscribe to withdrawal events.", "No mechanism exists to detect or remediate post-withdrawal processing in batch workloads." ] }, "dpo": { "summary": "Ensure the consent system architecture is documented and that consent state propagation SLAs are defined, monitored, and enforced.", "actions": [ "Define and document acceptable consent propagation SLAs in the RoPA and data processing agreements.", "Review reconciliation reports monthly and investigate any confirmed post-withdrawal processing incidents.", "Maintain a register of post-withdrawal processing incidents with root cause analysis and remediation actions." ], "failure_signals": [ "No documented SLA exists for consent withdrawal propagation.", "Reconciliation reports are not reviewed or escalated.", "Post-withdrawal processing incidents are not tracked or reported." ] }, "data_governance": { "summary": "Govern consent propagation SLAs across the processor chain and require downstream processors to demonstrate equivalent propagation controls.", "actions": [ "Include consent propagation SLA requirements in data processing agreements with all AI service providers.", "Require processors to provide periodic evidence of consent consistency monitoring.", "Track consent propagation SLA compliance as a data governance KPI." ], "failure_signals": [ "DPAs with AI processors do not specify consent propagation SLAs.", "Processors cannot demonstrate consent consistency monitoring.", "Governance reporting has no visibility into cross-system consent state lag." ] }, "grc_auditor": { "summary": "Audit whether consent state propagation meets defined SLAs and whether post-withdrawal processing incidents are identified and remediated.", "actions": [ "Review event bus delivery guarantees and test propagation timing for consent withdrawal events.", "Examine reconciliation job results over the audit period for post-withdrawal processing incidents.", "Assess whether post-withdrawal incidents were remediated and whether root causes were addressed." ], "metrics": [ "Maximum consent withdrawal propagation time across all consuming services (target: < 15 minutes)", "Number of confirmed post-withdrawal processing incidents per quarter (target: 0)" ], "failure_signals": [ "Propagation SLA cannot be measured due to absent event logging.", "Post-withdrawal processing incidents in the reconciliation log have no remediation records.", "Processing services cannot demonstrate they receive withdrawal events in real-time." ] }, "software_engineering": { "summary": "Implement the consent withdrawal event pipeline with the reliability guarantees required for compliance — guaranteed delivery, ordered processing, and idempotent consumers.", "actions": [ "Use a transactional outbox pattern to ensure consent withdrawal events are published even under database write failures.", "Implement idempotent consent state consumers so that duplicate event delivery does not cause spurious reprocessing.", "Add circuit-breaker logic that defaults to deny when consent state cannot be resolved within a timeout threshold." ], "failure_signals": [ "Consent events are published without transactional guarantees, creating loss risk under failures.", "Consumer services do not handle duplicate events idempotently.", "Services default to permit when the consent check service is unavailable." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Initial maturity relies on batch consent sync; defined maturity requires event-driven propagation with reconciliation monitoring." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Software Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 7(1)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 7(1) requires controllers to demonstrate valid consent; PM-04 provides the operational monitoring that makes consent validity verifiable in real-time across distributed AI systems.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.2.4", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 7.2.4 requires obtaining and recording consent such that the record demonstrates what was consented to; PM-04's consistency monitoring verifies that downstream processing state matches that consent record.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "certification-standard", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.PO-P1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PM-04 monitors conformance with NIST Privacy Framework CT.PO-P1 — authorizing data processing, revoking authorizations, and maintaining authorizations — by continuously reconciling consent state across distributed processing systems.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "okta_iam", "requirement_id": "Okta real-time directory synchronization — consent state propagation", "rationale": "Okta provides real-time event hooks that propagate consent state changes from Universal Directory to connected applications. Organizations can monitor consent propagation events to verify that consent state changes reach all downstream systems within defined SLAs, detecting inconsistencies where some systems still process data under withdrawn or expired consent records.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Okta real-time event hooks propagate consent changes and let orgs monitor propagation to detect systems still processing under withdrawn consent.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic API data controls — configuration verification", "rationale": "Enterprise customers using the Anthropic API must monitor API usage against consent grants to verify that data processing remains within the scope of current, valid consent. ZDR customers can verify no-retention compliance through absence of stored artifacts; standard customers should audit consent state against API usage logs to detect processing under expired or withdrawn consent.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic advises monitoring API usage against consent grants and verifying ZDR non-retention, guidance that supports but does not perform reconciliation.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI API usage monitoring — data control configuration audit", "rationale": "OpenAI provides API usage monitoring and data control dashboards that allow enterprise customers to audit data processing activity against configured consent and retention settings. Organizations should periodically verify that API data processing configurations remain aligned with current consent state records in their consent registries.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "OpenAI usage dashboards audit processing config against retention/consent settings, not the per-subject post-withdrawal reconciliation PM-04 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "alloweddata", "fit": "supporting", "rationale": "PM-04 detects post-withdrawal processing via a reconciliation job and triggers automated suspension, ensuring no AI processing runs on no-longer-permitted data.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Distributed AI architectures create structural consent propagation delays that can result in unlawful processing after withdrawal. PM-04 addresses this by making consent state an event-driven, monitored property with automated reconciliation that detects gaps before they become reportable violations.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-04", "validation_objective": "No AI processing activity executes against personal data after the associated data subject's consent has been withdrawn; consent withdrawal events are propagated to all consuming services within the defined SLA, and any post-withdrawal processing detected by the reconciliation job triggers automated suspension and DPO notification within one business day.", "evidence_required": [ "consent_withdrawal_event_bus_configuration records showing delivery_guarantee setting (at-least-once), maximum_propagation_SLA, and subscriber_list covering all AI processing services", "nightly_reconciliation_job_run_logs comparing processing activity timestamps against consent withdrawal timestamps, with alert records for any detected post-withdrawal processing and DPO notification evidence", "consent_state_cache_invalidation_logs from each consuming service confirming withdrawal events are received and local state is invalidated within the propagation SLA", "automated_processing_suspension_log showing suspension events triggered by confirmed post-withdrawal processing detections, with investigation outcomes and resumed_at or permanently_halted records", "consent_propagation_SLA_measurement_reports showing maximum propagation time per withdrawal event across all consuming services over the past 90 days" ], "machine_tests": [ "Withdraw consent for a synthetic test subject and measure propagation time to all consuming services → assert all services reflect withdrawal within the defined SLA (e.g., 15 minutes) with timestamped confirmation", "Inject a synthetic post-withdrawal processing record into the audit log for a test subject and run the reconciliation job → assert the mismatch is detected and a DPO alert is generated within the same reconciliation cycle", "Disconnect a consuming service from the withdrawal event stream and attempt processing for a subject with withdrawn consent → assert the circuit-breaker defaults to deny when consent state cannot be resolved", "Publish a duplicate withdrawal event for the same test subject → assert consuming services handle it idempotently without spurious state changes or re-triggering of suspension workflows" ], "human_review": [ "Review the consent withdrawal event bus delivery guarantee configuration and propagation SLA for adequacy, assessing whether the architecture eliminates structural windows of post-withdrawal processing in batch and streaming workloads", "Examine reconciliation job results from the past quarter for confirmed post-withdrawal processing incidents and verify each has a documented root cause analysis and remediation record", "Verify that data processing agreements with all AI processors specify consent propagation SLAs equivalent to or stricter than the controller's internal SLA, ensuring the obligation extends through the processor chain" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Implementing consent state as a TTL-cached value with no event-driven invalidation, creating a structural post-withdrawal processing window between withdrawal and cache expiry that is invisible to monitoring", "Running consent consistency reconciliation only monthly or on-demand rather than on a nightly or more frequent schedule that catches withdrawal violations within the regulatory exposure window", "Treating consent withdrawal propagation as a batch process with 24-72 hour SLAs, institutionalising an architectural assumption that some post-withdrawal processing is operationally acceptable", "Designing the consent check to default to permit when the consent state service is unavailable, reversing the burden of proof from demonstrated valid consent to assumed consent", "Publishing consent withdrawal events without transactional outbox guarantees, allowing loss of withdrawal signals under database write failures or network partitions that create silent violations" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-05", "layer": "PM", "plane": "data", "name": "Inference Log Monitoring", "plain": "AI inference logs are monitored for PII leakage in outputs, unusual query patterns suggesting membership inference or data extraction, and anomalies indicating model memorization exploitation.", "threat": { "tags": [ "pii-in-inference-logs", "membership-inference-via-log-analysis", "unusual-extraction-patterns" ], "desc": "Inference logs are a high-value target: they contain both input prompts (potentially PII-rich) and outputs (potentially memorized training data). An adversary with log access can conduct passive membership inference without active model queries." }, "standard": [ { "id": "gdpr", "section": "Art 5(1)(a)(c)/Art 32", "title": "Lawfulness, minimisation and security of inference processing" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records reviewed in accordance with policy" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-05 Inference Log Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-05 Inference Log Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-05 Inference Log Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-05 Inference Log Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-05 Inference Log Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Apply PII detection and anomaly analysis to inference logs at write time, redacting or pseudonymising personal data before log persistence, and running pattern analysis to detect extraction probing behaviours.", "steps": [ "Deploy a PII detection layer at the log ingestion point that classifies and redacts or pseudonymises personal data from inference inputs and outputs before writing to persistent log storage.", "Implement query pattern analysis that detects high-frequency, systematically varied queries characteristic of membership inference or model extraction attacks.", "Set retention policies for inference logs that align with the minimum necessary period for operational debugging, with automatic deletion beyond that window.", "Alert the Security Operations and Privacy Engineering teams when extraction patterns or PII-volume anomalies are detected, triggering an investigation workflow." ], "anti_patterns": [ "Logging raw inference inputs and outputs verbatim to centralised log aggregators with no PII redaction, creating a persistent PII store as a side effect of debugging infrastructure.", "Treating inference logs as having the same security posture as application logs, without recognising their elevated sensitivity as a potential source of model memorisation exposure." ] }, "validation": { "design_check": [ "Verify PII detection middleware is deployed at log ingestion and redacts before persistence [ref:gdpr_2016_679]", "Confirm extraction pattern detection rules are active on inference log streams [ref:edpb_opinion_28_2024]", "Review inference log retention policy alignment with minimum necessary principle [ref:nist_pf_1_0]" ], "runtime_test": [ "Submit a test inference request containing synthetic PII and verify the log entry is redacted or pseudonymised.", "Simulate a membership inference probe pattern (high-cardinality systematic queries) and verify an alert is generated.", "Verify that log entries older than the retention policy window are automatically deleted." ], "evidence": [ "privacy:log-redaction-config — PII detection and redaction middleware configuration for inference logs [unverified]", "privacy:extraction-alerts — Extraction pattern detection alert log with investigation records [unverified]", "privacy:retention-policy — Inference log retention policy document with enforcement evidence [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Treat inference logs as high-sensitivity data requiring active PII management at write time, not as low-priority debug artefacts.", "actions": [ "Integrate a NER-based PII redaction pipeline at the log sink before data reaches any aggregator.", "Build a statistical anomaly detector on query patterns to surface extraction probing above baseline.", "Define log schemas that separate operational metadata from content fields, minimising PII exposure in operational telemetry." ], "failure_signals": [ "Raw inference inputs and outputs are written to log aggregators with no redaction.", "Log schema mixes PII-containing content with operational metadata in a single unstructured field.", "No anomaly detection is applied to inference log query patterns." ] }, "dpo": { "summary": "Ensure inference logs are governed as a personal data store with defined retention, access controls, and monitoring, not treated as transient debugging infrastructure.", "actions": [ "Include inference log stores in the RoPA as a distinct processing activity with defined purpose, retention, and security measures.", "Review and approve the inference log retention policy to confirm alignment with data minimisation and storage limitation principles.", "Require notification of extraction pattern alerts as part of the privacy incident escalation procedure." ], "failure_signals": [ "Inference logs are not included in the RoPA or DPIA scope.", "No defined retention period exists for inference log data.", "Extraction pattern alerts do not trigger a privacy incident assessment." ] }, "data_governance": { "summary": "Govern inference log data as a distinct data asset with classification, retention, and access control requirements commensurate with its sensitivity.", "actions": [ "Classify inference log stores at an appropriate sensitivity level and apply access control requirements accordingly.", "Include inference log retention in the data retention schedule with automated enforcement.", "Require data quality and minimisation review as part of the log schema design process for new AI systems." ], "failure_signals": [ "Inference logs are classified as application logs without elevated sensitivity designation.", "Log retention is not governed by the data retention schedule.", "Log schemas are designed by engineering teams without data governance review." ] }, "grc_auditor": { "summary": "Audit whether inference log stores are governed as personal data assets and whether PII redaction and extraction monitoring controls are operating effectively.", "actions": [ "Sample inference log entries to verify PII redaction is applied and effective.", "Review extraction pattern alert records and confirm investigation workflows are followed.", "Verify inference log stores are included in the RoPA and that retention policy is enforced." ], "metrics": [ "Percentage of inference log entries with PII redaction applied (target: 100%)", "Mean time to investigate extraction pattern alerts (target: < 24 hours)" ], "failure_signals": [ "Sampled log entries contain unredacted personal data.", "Extraction pattern alerts exist with no investigation records.", "Inference log stores are absent from the RoPA." ] }, "software_engineering": { "summary": "Build PII minimisation into the log pipeline as a default, not an optional feature, and design log schemas that limit PII exposure by construction.", "actions": [ "Implement structured log schemas that separate content from metadata, and apply redaction only to content fields.", "Use field-level encryption for any content fields that must retain identifiable information for debugging purposes.", "Integrate log schema PII risk assessment into the code review checklist for inference-related code changes." ], "failure_signals": [ "Log schemas concatenate all inference data into a single unstructured string field.", "Field-level encryption or redaction is applied inconsistently depending on which engineer wrote the logging code.", "Code review does not include assessment of log PII exposure for inference-related changes." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Initial maturity typically has raw inference logs with no PII management; defined requires redaction at write time and pattern-based anomaly detection." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "Privacy Engineering", "Security Operations", "ML Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 32", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 32 requires appropriate technical measures to ensure data security; PM-05 directly implements inference log security through PII redaction and extraction pattern monitoring.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PM-05 implements NIST Privacy Framework CT.DM-P8 — audit/log records are determined, documented, implemented, and reviewed in accordance with policy — by applying continuous privacy-focused review and anomaly detection to AI inference logs.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Sensitive Data Disclosure risk — Output Validation and Sanitization", "rationale": "SAIF names Sensitive Data Disclosure as a core risk of model outputs, mitigated by Output Validation and Sanitization; PM-05 monitors production inference logs for exactly those disclosure signals.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "SAIF's Sensitive Data Disclosure output validation covers the PII-in-output signals PM-05 watches but not membership-inference or extraction-pattern detection.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "Amazon SageMaker Model Monitor — inference quality monitoring", "rationale": "AWS SageMaker Model Monitor continuously monitors deployed ML models and inference endpoints for data drift, model quality changes, and bias metrics that may indicate privacy-violating behaviors. Model Monitor integrates with CloudWatch for real-time alerting and produces monitoring reports suitable for inclusion in privacy monitoring evidence archives.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SageMaker Model Monitor tracks drift and quality as an indirect proxy, not the PII-leakage or membership-inference pattern detection PM-05 needs on logs.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview DSPM for AI — AI interaction monitoring", "rationale": "Microsoft Purview Data Security Posture Management (DSPM) for AI (successor to the Purview AI Hub) monitors AI interaction data for sensitive information exposure; PM-05 applies the same discipline to privacy monitoring of inference logs.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview DSPM for AI monitors AI interaction data for sensitive-info exposure, covering PII-leakage but not extraction-pattern or membership-inference detection.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "owasp_ai_exchange", "requirement_id": "monitoruse", "fit": "supporting", "rationale": "PM-05 runs an extraction-pattern detector on inference log streams that alerts on membership-inference and model-extraction query patterns, monitoring model use for abuse.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0024", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"All inference log entries have personal data redacted or pseudonymised at write time…\" enacts ATLAS mitigation AML.M0024 AI Telemetry Logging; OpenCRE crosswalks this control’s OWASP AI Exchange concept (monitoruse) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Inference logs are among the highest-risk personal data stores in an AI deployment — they aggregate PII from user interactions and may contain memorised training data. PM-05 treats log monitoring as a primary privacy control, applying PII redaction at write time and extraction-pattern detection to close the attack surface that raw log stores create.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-05", "validation_objective": "All inference log entries have personal data redacted or pseudonymised at write time before persistence in any log aggregation system; the extraction pattern detector is active on inference log streams and generates alerts within 24 hours of detecting query patterns characteristic of membership inference or model extraction attacks.", "evidence_required": [ "PII_detection_redaction_middleware_configuration showing NER model or rule set version, log fields in scope, and confirmed deployment status at each active inference endpoint", "sampled_inference_log_entries with PII redaction verification — at least 100 entries per log source annotated with original_field_classification and redaction_applied, confirming no raw personal data persists in content fields", "extraction_pattern_detection_ruleset_documentation and alert_records from the past 90 days with triggered_at, pattern_type, investigation_outcome, and resolved_at for each alert", "inference_log_retention_policy document with automated enforcement evidence (scheduled deletion job run logs or lifecycle policy configuration) confirming entries beyond the retention window are deleted", "inference_log_RoPA_entry confirming the processing is registered as a distinct activity with documented purpose, retention_period, access_controls, and security_measures" ], "machine_tests": [ "Submit a test inference request containing synthetic PII (name, email, national ID in user prompt and system prompt) → assert log entry shows redacted or pseudonymised values in all content fields with no raw identifiers", "Simulate a membership inference probe pattern (500 systematically varied queries targeting the same subject class within one hour) → assert an extraction alert is generated within 24 hours with pattern_type=membership_inference_probe", "Inject a log entry with a created_at timestamp older than the configured retention window → assert the automated deletion job removes it within one scheduled deletion cycle", "Submit an inference request with PII embedded only in the system prompt field → assert PII detection applies to all log fields including system prompt, not only the user-turn field" ], "human_review": [ "Review a stratified sample of redacted inference log entries to assess PII detection efficacy — confirm no residual identifiable data remains in any content field and that pseudonymisation keys are stored separately from the log store", "Assess extraction pattern detection alert thresholds against current threat research on membership inference and model extraction techniques, verifying thresholds detect sophisticated low-and-slow patterns, not only high-volume synthetic test attacks", "Verify that inference log stores are included in the formal DPIA scope and that security measures documented in the DPIA (redaction, access controls, retention) match the deployed configuration" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Logging raw inference inputs and outputs as a single unstructured string field in a general-purpose log aggregator, making field-level PII redaction impractical and exposing all inference content as a persistent PII store", "Applying PII detection only at query time for access control and not at log write time, creating a window where raw PII enters log buffers and may be written to disk before redaction middleware engages", "Setting extraction pattern detection thresholds so high to avoid false positives that only obviously malicious high-volume probing triggers alerts, missing sophisticated low-and-slow extraction patterns that stay below naive rate limits", "Applying the same retention period to inference logs as to general application logs without recognising that inference logs may contain memorised training data that makes them high-value exfiltration targets requiring stricter minimisation", "Granting engineering teams broad access to raw inference logs as debugging infrastructure without recognising them as a high-sensitivity personal data store requiring access controls commensurate with the sensitivity of their content" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-06", "layer": "PM", "plane": "data", "name": "Privacy Breach Notification Management", "plain": "The complete breach notification lifecycle — 72-hour supervisory authority notification, data subject notification where high risk, and documented decisions not to notify — is managed with SLA tracking and evidence capture.", "threat": { "tags": [ "notification-deadline-breach", "incomplete-breach-assessment", "notification-scope-error" ], "desc": "Breach notification failures arise from three sources: missed detection, incorrect scope assessment (under- or over-estimating affected individuals), and administrative deadline mismanagement. A structured notification management process closes all three gaps." }, "standard": [ { "id": "gdpr", "section": "Art 33/Art 34", "title": "72-hour supervisory notification and data subject notification" }, { "id": "ccpa", "section": "§1798.150", "title": "Private right of action for personal information breaches" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-06 Privacy Breach Notification Management control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/PM-06 Privacy Breach Notification Management control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-06 Privacy Breach Notification Management control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-06 Privacy Breach Notification Management control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-06 Privacy Breach Notification Management control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Operate a centralised breach notification case management system with mandatory SLA fields, structured assessment workflows for supervisory and data-subject notification decisions, and tamper-evident evidence capture for each decision point.", "steps": [ "Deploy a breach notification case management system with mandatory fields for detection timestamp, scope assessment, data categories, and affected individual count.", "Implement automated SLA tracking that computes the notification deadline from detection timestamp and escalates to the DPO and legal counsel as the deadline approaches.", "Build a structured notification decision workflow that records the assessed risk to data subjects, the notification decision (notify/not notify), and the rationale for each decision.", "Capture all notification correspondence — supervisory authority submissions, data subject communications, and internal decision memos — as tamper-evident attachments to the breach case record." ], "anti_patterns": [ "Managing breach notification through ad-hoc email chains that do not create a durable, auditable record of decisions and timelines.", "Treating the 72-hour clock as starting from breach confirmation rather than from awareness, creating systematic deadline risk." ] }, "validation": { "design_check": [ "Verify breach notification case management system records detection timestamp and computes SLA deadline automatically [ref:gdpr_2016_679]", "Confirm notification decision workflow captures rationale for notify/not-notify decisions [ref:ccpa_cpra_2023]", "Check that supervisory authority and data subject notification correspondence is captured as tamper-evident records [ref:uk_duaa_2025]" ], "runtime_test": [ "Create a test breach case and verify the 72-hour SLA countdown begins at detection timestamp.", "Simulate approaching the 72-hour deadline and confirm escalation notifications reach the DPO and legal counsel.", "Verify that a completed breach case contains all required evidence artefacts and cannot be retroactively modified." ], "evidence": [ "privacy:breach-cases — Breach notification case records with complete timeline and decision documentation [unverified]", "privacy:sla-tracking — Breach notification SLA tracking log showing deadline compliance [unverified]", "privacy:notification-correspondence — Supervisory authority and data subject notification correspondence records [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Build the breach notification system with the reliability and auditability properties that regulatory scrutiny demands — immutable records, automated SLA tracking, and structured evidence capture.", "actions": [ "Implement breach case records with append-only semantics and audit logging to prevent retroactive modification.", "Build automated SLA calculations that account for time-zone and jurisdiction differences for multi-jurisdictional breach notifications.", "Integrate breach case notifications with the incident response platform to prevent parallel tracking in disconnected systems." ], "failure_signals": [ "Breach cases are tracked in mutable spreadsheets or email threads rather than an append-only system.", "SLA deadlines are calculated manually rather than automatically from detection timestamps.", "Breach cases in the privacy system are not linked to corresponding incident records." ] }, "dpo": { "summary": "Own the breach notification lifecycle from initial triage through supervisory and data-subject notification, using the case management system as the single authoritative record.", "actions": [ "Lead all supervisory authority notification submissions with documented risk assessment and scope statements.", "Make and record the notification decision for data subjects within the case management system for each breach.", "Conduct a post-notification review for each breach to identify process improvements and update procedures." ], "failure_signals": [ "Supervisory authority notifications are submitted without prior documented risk assessment.", "Data-subject notification decisions are not recorded in the case management system.", "No post-notification review process exists to improve breach handling over time." ] }, "data_governance": { "summary": "Ensure breach notification procedures are documented, tested, and aligned with multi-jurisdictional requirements across all active processing regions.", "actions": [ "Maintain a jurisdiction matrix that maps each supervisory authority to the applicable notification deadline and format requirements.", "Include breach notification procedure testing in the annual privacy programme review.", "Require breach notification procedure documentation to be updated when new jurisdictions are added to the processing map." ], "failure_signals": [ "Breach notification procedures are single-jurisdiction and do not address multi-regulator scenarios.", "Procedures have not been tested against a simulated breach scenario in the past year.", "New processing jurisdictions are added without breach notification procedure updates." ] }, "grc_auditor": { "summary": "Audit whether breach notification cases are managed within the legal deadline requirements and whether case records demonstrate full compliance with notification obligations.", "actions": [ "Review all breach cases in the audit period for completeness of required fields and SLA compliance.", "Sample notification correspondence to verify it meets the content requirements of Art 33(3) and Art 34(2).", "Assess whether not-notify decisions are supported by documented risk assessments meeting the Art 34(1) threshold test." ], "metrics": [ "Percentage of breach notifications submitted within the 72-hour GDPR deadline (target: 100%)", "Percentage of breach cases with complete required documentation (target: 100%)" ], "failure_signals": [ "Breach cases lack detection timestamps preventing SLA compliance verification.", "Notification correspondence does not include all Art 33(3) required content.", "Not-notify decisions lack documented risk assessment supporting the decision." ] }, "software_engineering": { "summary": "Implement the breach case management system with the auditability and integration properties needed to serve as the authoritative legal record of breach handling.", "actions": [ "Use append-only storage for breach case records with cryptographic hash chaining for tamper evidence.", "Build an API integration between the breach management system and the incident response platform to prevent dual-tracking.", "Implement multi-factor authentication and role-based access control for breach case records to prevent unauthorised access." ], "failure_signals": [ "Breach case records can be edited or deleted without audit trail.", "Breach management and incident response systems are not integrated, creating divergent records.", "Breach case records are accessible to engineering teams without need-to-know access controls." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Initial maturity manages breach notifications ad-hoc; managed maturity requires a purpose-built case management system with automated SLA tracking and immutable records." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Legal/Compliance", "Security Operations" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 33/Art 34", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Articles 33 and 34 define the full breach notification obligation including the 72-hour supervisory deadline and data-subject notification threshold; PM-06 directly manages this lifecycle.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.150 (private right of action)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "The CCPA itself contains no breach-notification duty; California's notification obligation is Civ. Code §1798.82, outside the CCPA. Section 1798.150's private right of action for breaches of nonencrypted, nonredacted personal information makes the timely notification and evidence preservation that PM-06 manages directly liability-relevant.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Core element — Extend detection and response to bring AI into the organization's threat universe", "rationale": "SAIF's second core element extends enterprise incident response to AI systems; PM-06 applies that discipline to the breach notification lifecycle, while statutory timelines remain governed by GDPR Arts 33-34.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's extend-detection-and-response element is a related D&R discipline but not the 72-hour notification lifecycle and case management PM-06 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Security Hub — findings aggregation and automated response", "rationale": "AWS Security Hub aggregates findings from Macie, GuardDuty, and Inspector and can trigger SNS- and Lambda-based escalation workflows; the notification decision and statutory clock remain customer responsibilities that PM-06 manages.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS Security Hub aggregates findings and triggers escalation, feeding PM-06 but leaving the notification decision, statutory clock, and case record to it.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Products and Services DPA — security incident notification", "rationale": "Microsoft's Data Protection Addendum commits Microsoft to notify customers of personal data breaches without undue delay with the details controllers need for Art 33/34 notifications; PM-06 consumes such processor notices as triggers in the notification lifecycle.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Microsoft's DPA breach notices provide Art 33/34 details PM-06 consumes as triggers, not the notification-lifecycle management and case system itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "corrective", "matrix_thesis": "Breach notification failures are primarily administrative — missed deadlines, incomplete scope assessments, and undocumented decisions — rather than substantive privacy harms. PM-06 addresses these failure modes by imposing structured case management, automated SLA tracking, and tamper-evident evidence capture across the full notification lifecycle.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-06", "validation_objective": "Every personal data breach is assessed and results in a supervisory authority notification within 72 hours of the controller's awareness, or a documented not-notify decision supported by a risk assessment meeting the Art 34(1) threshold; all breach cases are recorded in an append-only case management system with tamper-evident audit trail from initial detection through closure.", "evidence_required": [ "breach_notification_case_records showing detection_timestamp, scope_assessment, data_categories_affected, estimated_affected_count, notification_decision, notification_rationale, and supervisory_authority_notified_at for each case", "automated_SLA_tracking_system_records showing the 72-hour countdown from detection_timestamp for each breach, with escalation_event_log entries at T+48h and T+70h confirming DPO and legal counsel were reached", "supervisory_authority_notification_correspondence as immutable attachments to each breach case, including DPA submission copy and transmission receipt confirming timely delivery", "data_subject_notification_records or documented_not_notify_risk_assessments for each case where the Art 34(1) high-risk threshold was assessed, confirming the decision is supported by a written risk analysis", "breach_case_management_system_audit_trail confirming append-only storage semantics and absence of retroactive modification events across all cases in the review period" ], "machine_tests": [ "Create a test breach case with detection_timestamp=T0 → assert 72-hour SLA countdown begins at T0 and escalation notifications are dispatched to DPO and legal counsel at T0+48h and again at T0+70h", "Attempt to modify the scope_assessment field on a submitted breach case → assert the system rejects the modification and records an attempted_modification event in the audit trail without altering the original value", "Simulate a breach case reaching the 72-hour deadline with no notification decision recorded → assert an escalation alert is triggered to DPO within 1 hour of deadline breach with urgency flag", "Create a test breach case and close it without attaching supervisory authority correspondence → assert the system blocks case closure until all required evidence fields are populated" ], "human_review": [ "Review a sample of breach cases from the past 12 months to assess documentation quality — confirm each case has a detection_timestamp, complete scope assessment, notification decision with written rationale, and all required correspondence attached as immutable records", "Assess not-notify risk assessments against the Art 34(1) threshold (unlikely to result in high risk to the rights and freedoms of natural persons) to verify the reasoning is legally sound and not a blanket practice of avoiding data subject notification", "Conduct a breach notification procedure simulation using a tabletop scenario to test whether the 72-hour SLA is achievable end-to-end given the current detection, triage, and case management workflow" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Starting the 72-hour clock from breach confirmation rather than from the moment the controller first becomes aware, systematically compressing the available time for assessment and creating structural deadline risk in complex incidents", "Managing breach notification through ad-hoc email chains that do not create a durable, tamper-evident record — email can be modified or deleted, destroying the evidence trail needed for regulatory examination", "Applying a single notification decision rule regardless of breach type and affected data categories, failing to distinguish between breaches unlikely to result in risk and those requiring urgent data subject notification", "Closing breach cases before all required correspondence is attached as immutable records, creating gaps in the evidence trail that may be discovered only during DPA examination of historical cases", "Treating breach notification as a DPO-only process without contractual processor notification obligations, missing the Art 33(2) processor-to-controller notification requirement that starts the 72-hour clock" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-07", "layer": "PM", "plane": "data", "name": "Third-Party Privacy Monitoring", "plain": "Third-party model providers, data processors, and AI infrastructure suppliers are monitored for ongoing privacy compliance through contractual audit rights, periodic assessments, and incident notification SLAs.", "threat": { "tags": [ "processor-non-compliance-undetected", "third-party-breach-without-notification", "sub-processor-chain-invisible" ], "desc": "Art 28(3)(h) requires controllers to maintain audit rights over processors. AI supply chains — involving base model providers, fine-tuning services, vector database providers, and inference infrastructure — create deep processor chains where compliance visibility typically degrades at each tier." }, "standard": [ { "id": "gdpr", "section": "Art 28(3)(h)", "title": "Audit rights obligation in data processing agreements" }, { "id": "iso_27701", "section": "8.5.6-8.5.8", "title": "Subcontractor disclosure, engagement, and change" }, { "id": "nist_pf", "section": "ID.DE-P5", "title": "Ecosystem parties routinely assessed via audits and evaluations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-02" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-01" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PM-07 Third-Party Privacy Monitoring control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a third-party AI supplier register with tiered assessment requirements based on data sensitivity and processing role, and enforce contractual audit rights through annual assessments and event-triggered reviews.", "steps": [ "Establish a third-party AI supplier register that classifies each processor by tier (critical, significant, standard) based on data categories processed, processing volume, and sub-processor chain depth.", "Require all critical and significant tier processors to provide annual privacy compliance evidence including relevant certifications, audit reports, and DPIA-relevant technical documentation.", "Exercise contractual audit rights for critical processors through annual assessments, which may include questionnaire-based assessments, third-party audit reviews, or on-site inspections.", "Define incident notification SLAs in all DPAs (e.g., 24 hours for processor awareness of a breach affecting controller data) and monitor for SLA compliance." ], "anti_patterns": [ "Treating DPA signature as the endpoint of third-party privacy governance rather than the starting point of an ongoing monitoring programme.", "Accepting self-certification from critical AI processors without independent evidence validation or contractual audit rights exercise." ] }, "validation": { "design_check": [ "Verify third-party AI supplier register exists with tiered classification criteria [ref:gdpr_2016_679]", "Confirm DPAs include incident notification SLAs and audit rights clauses [ref:iso_27701_2019]", "Review annual assessment schedule for critical tier processors [ref:nist_pf_1_0]" ], "runtime_test": [ "Request privacy compliance evidence from a critical tier processor and verify it is received and reviewed within the assessment cycle.", "Simulate a processor-side breach notification and verify it is received within the contractual SLA and triggers the correct internal response.", "Verify the supplier register is updated when a processor adds a sub-processor." ], "evidence": [ "privacy:supplier-register — Third-party AI supplier register with tiered classification and assessment history [unverified]", "privacy:processor-assessments — Annual privacy compliance assessment records for critical and significant tier processors [unverified]", "privacy:dpa-sla-log — Incident notification SLA compliance log for processor-reported incidents [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Build technical mechanisms to validate processor privacy claims rather than relying solely on contractual representations — especially for AI infrastructure where technical controls are verifiable.", "actions": [ "Instrument API integrations with processor services to monitor for unexpected data transmission patterns.", "Request and review technical documentation for processors' data isolation and deletion mechanisms.", "Build automated checks that verify processor-provided data retention and deletion SLAs are met using test marker data." ], "failure_signals": [ "Processor privacy compliance relies entirely on contractual representations with no technical verification.", "Processor API integrations have no monitoring for unexpected data flows.", "Deletion SLAs cannot be verified because no test data mechanism exists." ] }, "dpo": { "summary": "Ensure the third-party monitoring programme covers all AI processors and that audit rights are exercised at a frequency commensurate with risk.", "actions": [ "Review and approve the third-party supplier register classification criteria annually.", "Lead or commission annual privacy assessments for critical tier AI processors.", "Maintain a register of processor sub-processors and ensure DPA coverage extends through the chain." ], "failure_signals": [ "Critical AI processors have not been assessed in the past 12 months.", "Sub-processor chains are not mapped or covered by DPAs.", "Processor incidents are not reported to the DPO within contractual SLAs." ] }, "data_governance": { "summary": "Govern the AI supplier onboarding lifecycle to ensure privacy requirements are embedded before commercial engagement rather than retrofitted post-contract.", "actions": [ "Require privacy tier classification and DPA review as a gate in the AI supplier procurement process.", "Maintain a sub-processor change notification log to track when processors change their sub-processor chains.", "Include third-party privacy compliance rates in quarterly governance reporting." ], "failure_signals": [ "AI suppliers are onboarded without privacy tier classification or DPA review.", "Sub-processor changes are not notified to the data governance function.", "Governance reporting has no visibility into third-party privacy compliance status." ] }, "grc_auditor": { "summary": "Audit whether the third-party AI processor monitoring programme satisfies Art 28(3)(h) and whether audit rights are exercised with sufficient rigour and frequency.", "actions": [ "Review the supplier register for completeness against the list of active AI processors.", "Examine assessment records for critical tier processors to verify audit rights are exercised.", "Test incident notification SLA compliance by reviewing processor-reported incident records." ], "metrics": [ "Percentage of critical tier processors with current (< 12 months) privacy assessment (target: 100%)", "Percentage of processor-reported incidents received within contractual SLA (target: > 95%)" ], "failure_signals": [ "Supplier register is incomplete — active AI processors are missing.", "Critical processor assessments are overdue or based solely on self-certification.", "No records exist of processor incident notifications or SLA tracking." ] }, "software_engineering": { "summary": "Instrument processor API integrations to generate the monitoring signals needed to verify processor compliance claims technically rather than relying only on documentation.", "actions": [ "Add request/response logging to all processor API integrations with PII-redacted payloads for anomaly analysis.", "Implement test marker data injection to verify processor deletion timelines against contractual SLAs.", "Build a processor integration health dashboard that surfaces data volume anomalies and error rates as compliance signals." ], "failure_signals": [ "Processor API integrations have no logging or monitoring.", "Processor deletion SLAs cannot be verified due to absence of test mechanisms.", "Data volume anomalies in processor integrations do not trigger alerts." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Initial maturity has DPAs with minimal ongoing monitoring; defined maturity requires tiered assessment programmes with evidence-based audit rights exercise." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Procurement", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 28(3)(h)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 28(3)(h) mandates that data processing agreements include a controller's right to audit processors; PM-07 operationalises this right through a structured, tiered assessment programme.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "8.5.6-8.5.8", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clauses 8.5.6-8.5.8 require disclosure of subcontractors engaged to process PII, prior authorization before engaging them, and notice of subcontractor changes; PM-07's third-party monitoring verifies processors' ongoing conformance with those obligations.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "certification-standard", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "ID.DE-P5", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "PM-07 implements NIST Privacy Framework ID.DE-P5 — data processing ecosystem parties are routinely assessed using audits, test results, or other evaluations to confirm they are meeting their obligations — through the tiered third-party assessment and evidence review programme.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Insecure Integrated Component risk", "rationale": "SAIF's Insecure Integrated Component risk covers third-party components, models, and services integrated into AI systems; PM-07 extends that supply-chain vigilance to the privacy posture of third-party processors and AI vendors.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's Insecure Integrated Component risk addresses third-party security posture, adjacent to PM-07's ongoing privacy-compliance monitoring of processors.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Marketplace Vendor Insights — third-party security and compliance profiles", "rationale": "AWS Marketplace Vendor Insights provides vendor security and compliance posture data for AWS Marketplace software, supporting third-party AI vendor risk assessment. For AI vendors assessed through Vendor Insights, organizations can monitor for changes in security posture and compliance certifications without requiring direct vendor audit access.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Marketplace Vendor Insights supplies third-party security/compliance posture data to monitor Marketplace AI vendors, covering part of PM-07's monitoring.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI sub-processor list — DPA notification rights", "rationale": "OpenAI maintains and publishes a sub-processor list under its DPA, disclosing all third-party processors involved in delivering the OpenAI API service. Enterprise customers have contractual notification rights when sub-processors are added or changed, enabling ongoing monitoring of the third-party privacy chain for API-dependent AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "OpenAI's published sub-processor list and DPA change-notification rights enable monitoring of that vendor's third-party chain, part of PM-07's oversight.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum — subprocessor disclosure and objection rights", "rationale": "Anthropic's DPA discloses sub-processors used for Anthropic API service delivery and provides enterprise customers with contractual rights to object to new sub-processor additions. This ongoing disclosure mechanism enables third-party privacy monitoring for the Anthropic API supply chain, supporting GDPR Art 28 requirements for processor sub-contracting oversight.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Anthropic's DPA sub-processor disclosure and objection rights enable ongoing monitoring of its supply chain, covering part of PM-07's Art 28 oversight.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "supplychainmanage", "fit": "supporting", "rationale": "PM-07 maintains tiered processor assessments and monitored DPA notification SLAs for all active AI processors, managing privacy risk across the data supply chain.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "mitre", "requirement_id": "AML.M0023", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"All active AI processors are listed in the supplier register with a current tier…\" enacts ATLAS mitigation AML.M0023 AI Bill of Materials; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "mitre", "requirement_id": "AML.M0014", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "Control \"All active AI processors are listed in the supplier register with a current tier…\" enacts ATLAS mitigation AML.M0014 Verify AI Artifacts; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this mitigation.", "source_version": "v2026.06", "reviewed_on": "2026-07-08", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "not-applicable", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "industry-framework", "basis": "asserted", "relation": "equivalent_to", "correction": "ap38-opencre-enhancement 2026-07-08" }, { "framework": "nist_ai_100_2", "requirement_id": "NISTAML.05", "fit": "supporting", "rationale": "Control \"All active AI processors are listed in the supplier register with a current tier…\" defends against NIST AI 100-2 attack class NISTAML.05 \"Supply Chain Attacks\"; OpenCRE crosswalks this control’s OWASP AI Exchange concept (supplychainmanage) to this NIST class. (Anchor captures the attack taxonomy, so we cite the threat class as defends_against, not the NIST mitigation named by OpenCRE.)", "normative_force": "informative-reference", "source_version": "100-2e2025", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "defends_against", "mapping_confidence": "medium", "correction": "ap38-opencre-enhancement 2026-07-08" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "AI supply chains extend the controller's privacy obligations through processor chains that are often opaque beyond the first tier. PM-07 makes third-party privacy compliance an actively monitored programme rather than a contractual assumption, exercising audit rights with sufficient rigour to detect processor non-compliance before it becomes a controller liability.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-07", "validation_objective": "All active AI processors are listed in the supplier register with a current tier classification; critical-tier processors have a current (less than 12 months old) privacy compliance assessment evidencing exercise of Art 28(3)(h) audit rights; and all DPAs include incident notification SLAs with documented evidence that SLA compliance is actively monitored.", "evidence_required": [ "third_party_AI_supplier_register with tier_classification (critical/significant/standard), sub_processor_chain_depth, DPA_signed_date, and last_assessed_date for each active processor", "annual_privacy_compliance_assessment_records for all critical-tier processors including assessment_method (questionnaire/third-party audit/on-site inspection), findings_summary, and assessor_identity", "DPA_copies for all active processors confirming Art 28-compliant terms, incident_notification_SLA clauses (e.g., notify controller within 24 hours of processor awareness), and sub-processor authorisation mechanism", "incident_notification_SLA_compliance_log showing processor-reported incidents with reported_at, received_at, and SLA_met field for each, covering the past 12 months", "sub_processor_change_notification_log documenting processor-initiated sub-processor additions or removals and the controller's review and response action for each change" ], "machine_tests": [ "Submit a test incident notification through the designated processor notification channel and measure time from submission to DPO receipt → assert receipt occurs within the contractual SLA (e.g., 24 hours)", "Attempt to onboard a new AI supplier through the procurement workflow without a completed tier classification and DPA review sign-off → assert the workflow blocks onboarding approval until both fields are completed", "Add a simulated sub-processor to a critical-tier processor's disclosed list and notify the controller → assert the supplier register is updated and a review task is created within the defined change notification window", "Request current privacy compliance evidence from a critical-tier processor and verify the received evidence is logged in the assessment record with received_at timestamp and review completion" ], "human_review": [ "Review annual assessment records for critical-tier AI processors to evaluate assessment rigour — confirm assessments go beyond self-certification to include review of certification documents, audit reports, or technical documentation for data isolation and deletion mechanisms specific to the controller's use case", "Assess sub-processor chain depth for critical-tier processors and verify DPA terms extend Art 28 obligations through each tier of the chain, not only to the first-tier processor in the disclosed sub-processor list", "Cross-reference the supplier register against the organization's active AI integration inventory and RoPA to identify any processors receiving personal data that are absent from the register or lack current assessments" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Treating DPA signature as the endpoint of third-party privacy governance, relying entirely on contractual representations without exercising audit rights through periodic evidence review or assessment of the processor's actual controls", "Applying a single undifferentiated assessment process to all AI processors regardless of processing role and data sensitivity, failing to direct assessment effort toward critical-tier processors that handle the most sensitive data at the greatest volume", "Accepting AI processor SOC 2 Type II or ISO 27001 certifications as full substitutes for privacy-specific assessment without verifying that the certification scope covers the specific data categories and processing activities relevant to the controller's use case", "Failing to map processor sub-processor chains beyond the first disclosed tier, creating invisible liability exposure where sub-processors process personal data under terms not reviewed or approved by the controller", "Defining incident notification SLAs contractually in DPAs without monitoring whether processors actually meet those SLAs in practice, making the obligation unenforceable and unverified without an active compliance log" ], "update_status": "current", "layer_code": "PM" }, { "id": "PM-08", "layer": "PM", "plane": "data", "name": "Privacy Monitoring Evidence Archive", "plain": "An archive of all privacy monitoring outputs — incident detections, purpose creep alerts, consent consistency checks, inference monitoring summaries, and breach notification records — is maintained for governance and audit.", "threat": { "tags": [ "monitoring-evidence-lost", "monitoring-program-effectiveness-undemonstrable", "audit-trail-gaps" ], "desc": "Art 5(2) accountability requires that the controller demonstrate that monitoring programs are operating. Monitoring that generates no durable evidence record cannot be invoked to satisfy accountability obligations during DPA examination." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)/Art 30", "title": "Accountability through monitoring evidence" }, { "id": "iso_27701", "section": "7.2.8", "title": "Records related to processing of PII" }, { "id": "nist_pf", "section": "CT.DM-P8", "title": "Audit/log records determined, documented, implemented, and reviewed" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PM-08 Privacy Monitoring Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PM-08 Privacy Monitoring Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PM-08 Privacy Monitoring Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PM-08 Privacy Monitoring Evidence Archive control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PM-08 Privacy Monitoring Evidence Archive control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Centralise all privacy monitoring outputs into a structured evidence archive with defined retention periods, access controls, and integrity verification, enabling on-demand production of monitoring evidence for DPA enquiries or internal audits.", "steps": [ "Define an evidence taxonomy that categorises monitoring outputs by control (PM-01 through PM-07) and evidence type, with corresponding retention periods aligned to regulatory requirements.", "Implement automated ingestion of monitoring outputs from each PM control into the centralised archive, preserving original timestamps and source system references.", "Apply write-once storage with integrity hashing to archive entries to prevent retroactive modification of monitoring records.", "Implement a DPA-enquiry response procedure that can produce a complete monitoring evidence package for any specified time period within a defined SLA (e.g., 72 hours)." ], "anti_patterns": [ "Storing monitoring outputs in the operational systems that generated them (SIEM, log aggregators) without a dedicated archive — these systems are subject to rotation policies that may destroy evidence before it is needed.", "Maintaining monitoring outputs without integrity controls, making the evidence potentially inadmissible or challengeable during regulatory examination." ] }, "validation": { "design_check": [ "Verify evidence taxonomy covers all PM control outputs with defined retention periods [ref:gdpr_2016_679]", "Confirm automated ingestion pipeline captures outputs from all PM controls [ref:iso_27701_2019]", "Check write-once storage and integrity hashing are applied to all archive entries [ref:nist_pf_1_0]" ], "runtime_test": [ "Request a monitoring evidence package for a 30-day historical period and verify all PM control outputs are present and complete.", "Attempt to modify a historical archive entry and verify the integrity check detects and rejects the modification.", "Verify that archive ingestion runs are logged and that gaps in expected monitoring output are flagged." ], "evidence": [ "privacy:evidence-taxonomy — Privacy monitoring evidence taxonomy with retention period schedule [unverified]", "privacy:archive-ingestion-log — Automated ingestion pipeline run logs confirming coverage of all PM controls [unverified]", "privacy:integrity-verification — Archive integrity verification reports confirming no tampering detected [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Design the evidence archive as a purpose-built compliance data store with write-once semantics, integrity verification, and an evidence production API.", "actions": [ "Implement an evidence ingestion API that all PM control systems use to write monitoring outputs, ensuring consistent formatting and mandatory metadata.", "Use content-addressed storage or cryptographic hash chaining to provide write-once integrity guarantees.", "Build an evidence query API that supports time-range queries and control-type filtering for DPA-enquiry response." ], "failure_signals": [ "PM control outputs are stored in each control's operational system with no centralised archive.", "Archive entries lack integrity controls and can be modified without detection.", "Producing a monitoring evidence package for a historical period requires manual extraction from multiple systems." ] }, "dpo": { "summary": "Own the evidence archive as the primary instrument for demonstrating accountability to supervisory authorities and ensure it can support a DPA enquiry response within defined timescales.", "actions": [ "Approve the evidence taxonomy and retention schedule, ensuring all regulatory requirements are reflected.", "Conduct annual evidence archive readiness exercises that simulate DPA enquiry production requests.", "Review archive completeness quarterly, verifying all PM controls are contributing expected monitoring outputs." ], "failure_signals": [ "Evidence taxonomy has not been reviewed or approved by the DPO.", "No DPA enquiry response exercise has been conducted in the past year.", "Quarterly archive completeness reviews have not been performed or documented." ] }, "data_governance": { "summary": "Govern the evidence archive as a strategic compliance asset with defined retention, access controls, and lifecycle management requirements.", "actions": [ "Include the evidence archive in the data asset inventory with appropriate sensitivity classification.", "Require all new PM controls to demonstrate archive integration before deployment.", "Maintain a retention policy that satisfies the maximum applicable regulatory requirement across all jurisdictions." ], "failure_signals": [ "Evidence archive is not included in the data asset inventory.", "New PM controls are deployed without archive integration.", "Retention policy is not aligned to the maximum regulatory requirement across active jurisdictions." ] }, "grc_auditor": { "summary": "Audit whether the evidence archive is complete, integrity-protected, and capable of supporting the Art 5(2) accountability demonstration required by GDPR.", "actions": [ "Verify archive completeness by cross-referencing expected monitoring outputs against actual archive entries for the audit period.", "Perform integrity verification sampling to confirm hash values match stored records.", "Test the DPA-enquiry response procedure by requesting a complete evidence package and assessing completeness and timeliness." ], "metrics": [ "Percentage of expected PM control monitoring outputs present in the archive (target: 100%)", "Time to produce a complete monitoring evidence package in response to DPA enquiry simulation (target: < 72 hours)" ], "failure_signals": [ "Archive contains gaps for one or more PM controls during the audit period.", "Integrity verification reveals hash mismatches indicating possible tampering.", "DPA enquiry response exercise exceeded the 72-hour SLA target." ] }, "software_engineering": { "summary": "Build the evidence archive as a hardened, write-once data store with an ingestion API that all PM control systems call, and provide production-readiness guarantees for regulatory use.", "actions": [ "Implement the ingestion API with schema validation that enforces mandatory metadata fields for all evidence entries.", "Use WORM (write-once read-many) storage or equivalent append-only semantics with cryptographic hash chaining.", "Add automated alerting when expected ingestion signals from PM controls are absent, catching monitoring gaps before they compound." ], "failure_signals": [ "Ingestion API does not validate schema, resulting in inconsistently formatted evidence entries.", "Storage layer allows modification of historical entries without detection.", "Absent monitoring signals from PM controls do not trigger alerts, allowing evidence gaps to accumulate silently." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Initial maturity has fragmented monitoring outputs with no centralised archive; managed maturity requires a purpose-built, integrity-protected archive with DPA-enquiry response capability." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Privacy Engineering", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(2)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "Article 5(2) establishes the accountability principle requiring the controller to demonstrate compliance; PM-08 provides the evidence archive that makes this demonstration possible.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "7.2.8", "fit": "direct", "direction": "control-supports-requirement", "rationale": "ISO/IEC 27701:2019 clause 7.2.8 requires maintaining the records necessary to demonstrate compliance with PII processing obligations; PM-08's monitoring evidence archive implements that record-keeping with the integrity controls required for audit use.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "certification-standard", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "CT.DM-P8", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "NIST Privacy Framework CT.DM-P8 requires audit/log records determined, documented, implemented, and reviewed per policy; PM-08 maintains the monitoring archive that makes the privacy governance programme legible and auditable.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS CloudTrail with S3 Object Lock — WORM evidence archive", "rationale": "AWS CloudTrail provides a comprehensive, queryable archive of all privacy-relevant API events across AWS AI services. S3 Object Lock in compliance mode creates a WORM-compliant immutable evidence store for privacy monitoring records, ensuring that monitoring artifacts cannot be altered or deleted before their retention period expires, supporting regulatory evidence preservation requirements.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "CloudTrail with S3 Object Lock WORM provides an immutable archive substrate for monitoring records but not the 24-hour ingest, SHA-256, and retrieval SLA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Compliance Manager — evidence collection and archiving", "rationale": "Microsoft Purview Compliance Manager provides structured evidence collection and archiving for privacy control assessments, including monitoring evidence. The compliance portal supports evidence upload, assessment documentation, and automated evidence collection from Microsoft services, creating a centralized evidence archive for privacy monitoring activities across Microsoft 365 and Azure AI services.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Compliance Manager structures evidence collection and archiving but not PM-08's 24-hour ingest, monthly SHA-256, and 72-hour package retrieval.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "The Art 5(2) accountability principle requires that the controller be able to demonstrate compliance — not merely claim it. PM-08 closes the evidence gap by centralising all PM layer monitoring outputs into an integrity-protected archive that can support DPA examination, internal audit, and continuous governance review.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PM-08", "validation_objective": "All monitoring outputs from PM-layer controls (PM-01 through PM-07) are ingested into the centralised evidence archive within 24 hours of generation; each archive entry carries a SHA-256 integrity hash verified at least monthly; and a complete monitoring evidence package for any 30-day historical period can be produced within 72 hours to support DPA examination.", "evidence_required": [ "evidence_taxonomy_document mapping each PM control to expected output types, archive identifiers, and defined retention periods aligned to the maximum applicable regulatory requirement across all jurisdictions", "automated_ingestion_pipeline_run_logs showing successful ingestion of monitoring outputs from each PM control (PM-01 through PM-07), with timestamps, record_counts per run, and absence_alerts where expected signals were missing", "archive_integrity_verification_reports confirming SHA-256 hash values match stored entries for a statistically representative sample, run at least monthly with no tampering detected", "DPA_enquiry_response_exercise_records from the most recent annual test showing time_to_produce_evidence_package, percentage_of_expected_records_present, and assessor findings", "write_once_storage_configuration_evidence (e.g., S3 Object Lock COMPLIANCE mode policy, Azure Immutable Blob Storage configuration) confirming archive entries cannot be modified or deleted before retention period expiry" ], "machine_tests": [ "Trigger a monitoring output from each active PM control and verify archive ingestion captures and stores each output within 24 hours with correct source_control, generated_at, and sha256_hash fields populated", "Attempt to overwrite or delete a historical archive entry → assert the storage layer rejects the operation and records an attempted_modification event in the archive audit log", "Deliberately suppress one PM control's monitoring run for one cycle → assert an absence alert is generated within the expected ingestion window before the gap accumulates beyond one cycle", "Request a complete monitoring evidence package for a 30-day historical period → assert all expected PM control outputs are present and SHA-256 hash verification passes for every retrieved entry" ], "human_review": [ "Review the evidence taxonomy for completeness — confirm every PM-layer control's monitoring output type is listed with an unambiguous archive identifier, retention period, and assigned owner responsible for ensuring ingestion continuity", "Conduct a DPA-enquiry simulation exercise by requesting a full monitoring evidence package for a representative historical period, assessing completeness against the taxonomy, integrity verification results, and whether the package would satisfy a regulatory examination", "Assess archive access controls to confirm monitoring evidence is accessible only to authorised personnel (DPO, GRC, legal) and that engineering teams cannot modify or delete historical entries, eliminating self-certifying evidence risk" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Storing PM-layer monitoring outputs only in the operational systems that generated them (SIEM, log aggregators, alert platforms) without a dedicated archive, exposing evidence to rotation policies and log purges that may destroy records before they are needed", "Ingesting monitoring outputs into the archive without integrity hashing, making the evidence challengeable during DPA examination as potentially modified after collection", "Treating the archive as a passive storage system with no alerting on ingestion gaps, allowing evidence gaps to accumulate silently when a PM control monitoring run fails or is delayed", "Applying a single uniform retention period across all PM control outputs without accounting for different regulatory requirements — breach notification records typically require longer retention than routine purpose reconciliation outputs", "Granting engineering teams write access to the evidence archive on the basis that they maintain the monitoring systems, creating a self-certifying evidence model where the monitored party controls the historical record" ], "update_status": "current", "layer_code": "PM" }, { "id": "PC-01", "layer": "PC", "plane": "lifecycle", "name": "Regulatory Obligation Mapping", "plain": "A matrix of applicable privacy laws per jurisdiction of AI operation and data subject location is maintained with tracked divergences and jurisdiction-specific requirements, covering GDPR, UK DUAA, CCPA/CPRA, India DPDPA, and others.", "threat": { "tags": [ "missing-jurisdiction-obligations", "applying-wrong-framework", "multi-jurisdictional-coverage-gap" ], "desc": "AI systems deployed globally serve data subjects under multiple concurrent privacy regimes with diverging requirements. Failure to map which law applies in which scenario — particularly for edge cases such as EU data subjects using a US-based AI service — creates systematic compliance gaps." }, "standard": [ { "id": "gdpr", "section": "Art 3", "title": "Territorial scope" }, { "id": "ccpa", "section": "§1798.140", "title": "Definitions and applicability thresholds" }, { "id": "dpdp", "section": "s. 3", "title": "Application and territorial scope" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-02" }, { "id": "india_dpdpa_2023", "title": "Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India)", "authority": "Parliament of India / Ministry of Electronics and Information Technology", "source_type": "binding-law", "normative_force": "binding-law", "version": "Act 2023; Rules 2025", "published_on": "2023-08-11", "retrieved_on": "2026-06-28", "canonical_url": "https://www.meity.gov.in/data-protection-framework", "license": "public-domain", "status": "current", "flagship": false, "source_id": "dpdp", "relationship": "normative_requirement", "rationale": "Establishes Digital Personal Data Protection Act 2023 + DPDP Rules 2025 (India) requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-02" }, { "id": "cnil_ai_guidance_2023", "title": "CNIL AI Recommendations — Use of Artificial Intelligence and Protection of Personal Data", "authority": "Commission Nationale de l'Informatique et des Libertés (CNIL)", "source_type": "guidance", "normative_force": "supervisory-guidance", "version": "2023", "published_on": "2023-06-01", "retrieved_on": "2026-06-29", "canonical_url": "https://www.cnil.fr/en/topics/artificial-intelligence-ai", "license": "open-access", "status": "current", "flagship": false, "source_id": "cnil_ai_guidance_2023", "relationship": "supporting_guidance", "rationale": "Establishes CNIL AI Recommendations — Use of Artificial Intelligence and Protection of Personal Data requirements informing the apeiris://privacy/controls/PC-01 Regulatory Obligation Mapping control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain a living jurisdiction matrix that maps each AI product offering to applicable privacy laws based on data subject location, processing location, and controller establishment, with per-jurisdiction requirement deltas tracked and owner-assigned.", "steps": [ "Enumerate all AI product offerings and their data subject populations by geography, identifying every jurisdiction in which the product is offered or where data subjects are located.", "For each identified jurisdiction, map the applicable privacy law(s), key obligations (consent model, purpose limitation, DSAR timelines, breach notification), and record divergences where requirements conflict with other applicable regimes.", "Assign jurisdiction obligation owners, establish a quarterly review cadence for regulatory updates, and integrate the matrix into the DPIA and product launch checklists as a mandatory sign-off gate." ], "anti_patterns": [ "Assuming GDPR compliance covers all jurisdictions — CCPA opt-out obligations, India DPDPA consent renewal requirements, and UK DUAA derogations each require jurisdiction-specific treatment that GDPR compliance alone does not satisfy.", "Treating the obligation matrix as a one-time legal exercise rather than a living document updated when laws change, new markets are entered, or products are modified." ] }, "validation": { "design_check": [ "Verify the jurisdiction matrix covers all geographies where the AI product is offered or where data subjects are located [ref:gdpr_2016_679]", "Confirm each jurisdiction entry has mapped obligations, divergences, and an assigned owner with a defined review cadence [ref:ccpa_cpra_2023]", "Check that the matrix review date is current (within 90 days) and that regulatory changes in the past 12 months are reflected [ref:india_dpdpa_2023]" ], "runtime_test": [ "Introduce a simulated regulatory update (e.g., a new DPDP Rule) and verify it is captured in the matrix within the defined review window.", "Test that the product launch checklist includes jurisdiction matrix sign-off as a gate for any new geographic rollout.", "Verify that DSAR handling procedures reference jurisdiction-specific timelines drawn from the matrix rather than a single hardcoded value." ], "evidence": [ "privacy:jurisdiction-matrix — Current multi-jurisdictional obligation matrix with owner assignments, requirement deltas, and last-reviewed date [unverified]", "privacy:regulatory-update-log — Record of regulatory changes assessed against the matrix in the past 12 months, with update evidence [unverified]", "privacy:launch-checklist — Product launch checklist confirming jurisdiction matrix sign-off for each new geography rollout [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "The jurisdiction matrix is the upstream input for privacy-by-design decisions — consent flows, feature toggles, and data retention rules must be parameterized per jurisdiction based on matrix outputs.", "actions": [ "Expose jurisdiction metadata in the product data processing pipeline so feature behavior can be conditioned on the applicable law for the data subject's location.", "Build automated checks that flag new geographies appearing in telemetry against the jurisdiction matrix to prompt obligation review before those users accumulate.", "Instrument consent and rights-handling flows to enforce jurisdiction-specific timelines and consent models derived from the matrix." ], "failure_signals": [ "A single consent implementation is used for all geographies without jurisdiction-specific branching for opt-in vs opt-out models.", "DSAR response timelines are hardcoded to GDPR's one-month window regardless of the data subject's jurisdiction.", "New geographic markets are launched without triggering a matrix review or jurisdiction obligation assessment." ] }, "dpo": { "summary": "The DPO owns the jurisdiction obligation matrix and must ensure it drives concrete operational requirements rather than serving only as a legal awareness document.", "actions": [ "Sponsor a quarterly regulatory horizon scan to update the matrix for new laws, amendments, and DPA enforcement decisions that affect product obligations.", "Review the divergence tracker to identify where product teams are applying incorrect frameworks — particularly where GDPR logic is used in CCPA contexts.", "Ensure the matrix is formally referenced in DPIAs, privacy notices, and processing records so that jurisdiction applicability is traceable." ], "failure_signals": [ "The DPO is unaware that the India DPDPA now applies to a product serving Indian users following the enactment of the DPDP Rules 2025.", "The compliance team applies GDPR opt-in consent to a CCPA-scoped product, missing the opt-out right-to-know requirement.", "The matrix has not been updated following a new state privacy law enactment or a significant DPA enforcement decision." ] }, "data_governance": { "summary": "Data governance must ensure data classification and retention schedules are parameterized by jurisdiction, not applied globally at the most restrictive setting.", "actions": [ "Tag data assets with the jurisdiction of origin and applicable law, enabling jurisdiction-aware retention and deletion scheduling.", "Integrate the jurisdiction matrix with the data catalog so data stewards can identify applicable obligations for each dataset they manage.", "Review data lineage for cross-border transfers and flag each for the appropriate jurisdiction-specific transfer mechanism documented in the matrix." ], "failure_signals": [ "Data assets lack jurisdiction tags, preventing enforcement of jurisdiction-aware retention schedules.", "Retention schedules are applied globally at the most restrictive setting without jurisdiction-specific calibration, creating unnecessary data minimization burdens.", "Cross-border transfer documentation does not reference the jurisdiction matrix for applicable transfer mechanisms." ] }, "grc_auditor": { "summary": "The jurisdiction matrix is an accountability artifact that DPAs will review during examinations to evidence that the controller understands the scope of its obligations.", "actions": [ "Verify the matrix covers all geographies identified in the data flow inventory and that no processing locations are absent.", "Test that matrix updates triggered by regulatory changes are evidenced with dated review records linked to the specific regulatory change.", "Sample DPIAs and processing records to confirm they reference the matrix version current at their creation date." ], "metrics": [ "Percentage of jurisdictions with assigned obligation owners (target: 100%)", "Days since last jurisdiction matrix review (target: <90 days)" ], "failure_signals": [ "The matrix is missing one or more jurisdictions identified in the data flow inventory.", "No evidence of matrix updates following known regulatory changes in the past 12 months.", "DPIAs reference an outdated matrix version that predates material regulatory changes." ] }, "software_engineering": { "summary": "Software engineers must implement jurisdiction-aware feature toggles and consent flows that consume the obligation matrix as configuration, not hardcoded conditional logic.", "actions": [ "Implement a jurisdiction configuration service that exposes applicable law, consent model, and rights timelines as runtime parameters consumed by product features.", "Add automated CI checks that reject hardcoded jurisdiction assumptions such as fixed DSAR response windows or single-model consent implementations.", "Document jurisdiction configuration parameters in API contracts so downstream services can consume them for jurisdiction-appropriate behavior." ], "failure_signals": [ "Jurisdiction-specific behavior is implemented as hardcoded conditionals rather than driven by a configuration service fed from the obligation matrix.", "No automated test coverage for jurisdiction-specific consent or rights handling edge cases.", "New geography rollouts do not trigger a configuration review against the jurisdiction service." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations have a legal memo on applicable jurisdictions but lack the living matrix with tracked divergences and owner assignments required for defined maturity." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "Legal/Compliance", "DPO Office", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-01 directly implements the GDPR Art 3 territorial scope determination, ensuring the organization can demonstrate it has assessed whether GDPR applies to each processing context based on controller establishment and data subject location.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.140", "fit": "partial", "direction": "control-supports-requirement", "rationale": "The obligation matrix partially addresses CCPA/CPRA applicability thresholds by tracking which products meet the definitions triggering CCPA obligations, though the full CCPA compliance program extends beyond jurisdictional mapping.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "dpdp", "requirement_id": "s. 3", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-01 captures India DPDPA territorial scope as one of the jurisdictions in the matrix, though full DPDPA compliance requires additional controls covering consent, data fiduciary obligations, and data localisation.", "source_version": "Act 2023; Rules 2025", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Core element — Contextualize AI system risks in surrounding business processes", "rationale": "SAIF's sixth core element directs organizations to contextualize AI risks within the surrounding business processes, which includes understanding the regulatory obligations attached to each deployment context; PC-01 provides that obligation mapping for privacy law.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's contextualize-risks element implies understanding deployment obligations but does not provide the multi-jurisdiction obligation matrix PC-01 maintains.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Customer Compliance Center — regulatory resources", "rationale": "AWS Customer Compliance Center provides pre-built compliance documentation mapping AWS controls to GDPR, CCPA, India DPDPA, LGPD, and other major privacy regulations. For AI workloads, AWS provides jurisdiction-specific guidance on applying these regulatory mappings to AI-specific processing activities, supporting enterprise regulatory obligation mapping programs.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Customer Compliance Center maps controls to GDPR, CCPA, DPDPA, and LGPD, supplying content but not the enterprise's owned jurisdiction matrix and gate.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI trust and compliance documentation", "rationale": "OpenAI provides compliance documentation covering GDPR, CCPA, HIPAA, and FERPA, with DPA and BAA available for applicable regulatory frameworks. For enterprise customers, OpenAI's compliance documentation informs the regulatory obligation mapping for AI systems using OpenAI APIs, identifying which obligations are satisfied by OpenAI as processor and which remain with the enterprise as controller.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's compliance documentation informs which obligations it satisfies versus the controller, an input to the mapping rather than the obligation matrix.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Compliance Manager — regulatory assessment templates", "rationale": "Microsoft Purview Compliance Manager provides regulatory obligation mapping with pre-built assessment templates for GDPR, CCPA, India PDPA, UK GDPR, and other major privacy laws. Each template includes improvement action recommendations and maps Microsoft controls to specific regulatory articles, supporting enterprise regulatory obligation mapping for Azure AI-based systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Compliance Manager's regulatory templates map controls to specific GDPR/CCPA/UK-GDPR articles, providing obligation-mapping tooling aligned with PC-01.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "cnil_ai", "requirement_id": "How-to sheet 2 — Defining a purpose", "fit": "direct", "rationale": "CNIL's AI how-to sheets require defining a determined, explicit, and legitimate purpose for AI system development and use (sheet 2); PC-01's obligation mapping must reflect CNIL's interpretation of GDPR purpose requirements for AI systems in France.", "normative_force": "supervisory-guidance", "source_version": "2023", "reviewed_on": "2026-07-02", "basis": "asserted", "relation": "satisfies" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "supporting", "rationale": "PC-01 maintains a multi-jurisdictional obligation matrix as a mandatory launch sign-off gate, checking AI data processing against applicable privacy laws before rollout.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Regulatory obligation mapping prevents the systematic compliance gap that occurs when AI systems are deployed globally without a formal determination of which privacy law applies to which processing context. By maintaining a living jurisdiction matrix, the organization ensures that product decisions — consent flows, retention schedules, rights timelines — are grounded in the correct legal framework for each data subject population, and that divergences across regimes are tracked and resolved rather than silently collapsed into a single framework.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-01", "validation_objective": "A current (reviewed within 90 days) multi-jurisdictional obligation matrix exists covering every geography where the AI product is offered or where data subjects are located; each jurisdiction entry documents applicable law, consent model, DSAR timeline, breach notification deadline, and GDPR divergences with an assigned owner; and the matrix is a mandatory sign-off gate in the product launch checklist before any new geographic rollout may proceed.", "evidence_required": [ "jurisdiction_obligation_matrix with columns for jurisdiction, applicable_law, consent_model, DSAR_response_timeline, breach_notification_deadline, GDPR_divergences, assigned_owner, and last_reviewed_date for each jurisdiction entry", "regulatory_update_log recording each assessment of legislative changes and DPA enforcement decisions in the past 12 months against the matrix, with dated review records and matrix_updated_at evidence for each assessed change", "product_launch_checklist_records showing jurisdiction_matrix_sign_off was completed for each new geographic rollout before launch, with sign-off authority identity and date", "jurisdiction_coverage_verification showing every geography identified in the RoPA and data flow inventory has a corresponding matrix entry with a last_reviewed_date within 90 days", "quarterly_matrix_review_records showing scheduled and completed reviews, reviewer identity, sign-off, and change summary for each quarterly cycle" ], "machine_tests": [ "Introduce a simulated new geography in product telemetry (e.g., user access from a country with no current matrix entry) → assert an automated coverage alert prompts a matrix review before user count exceeds a defined threshold", "Attempt to complete a product launch checklist for a new geographic rollout without jurisdiction matrix sign-off for the target geography → assert the checklist workflow blocks launch approval until the sign-off field is populated", "Query the jurisdiction configuration service for DSAR response timeline for a test user located in India → assert it returns the DPDPA-specified timeline (30 days) rather than the GDPR default (one month), confirming jurisdiction-aware configuration", "Update the matrix entry for a covered jurisdiction to reflect a simulated legislative change → assert the dependent configuration service is updated within the defined propagation window without requiring a code deployment" ], "human_review": [ "Cross-reference all geographies in the RoPA and data flow inventory against matrix entries to identify unregistered jurisdictions where personal data of data subjects is being processed without a current obligation mapping", "Assess the accuracy of obligation mapping for a sample of two to three jurisdictions by verifying consent_model, DSAR_timeline, and breach_notification_deadline entries against the current text of the applicable law and recent DPA enforcement decisions or guidance", "Evaluate the divergence tracking mechanism to confirm that conflicts between applicable regimes (e.g., GDPR opt-in vs CCPA opt-out, GDPR retention limits vs India DPDPA consent renewal requirements) are explicitly documented with a resolution approach recorded for each conflict" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Assuming GDPR compliance automatically satisfies all applicable privacy obligations globally, missing jurisdiction-specific requirements such as CCPA opt-out rights, India DPDPA consent renewal timelines, and Brazil LGPD consent formalities that require distinct product implementations", "Treating the obligation matrix as a one-time legal memo produced at product launch rather than a living document updated when laws change, new markets are entered, or DPA enforcement decisions materially alter the interpretation of existing obligations", "Hardcoding jurisdiction-specific parameters (DSAR timelines, consent models, breach notification deadlines) in product code rather than consuming them from a jurisdiction configuration service, making updates a code deployment rather than a configuration change", "Applying the most restrictive requirement globally across all jurisdictions without jurisdiction-specific calibration, creating unnecessary compliance burden and missing the right to process under more permissive local frameworks where applicable", "Omitting newly operational jurisdictions from the matrix because no user complaints or regulatory inquiries have been received, relying on reactive discovery of obligations rather than proactive territorial scope assessment before users in that jurisdiction accumulate" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-02", "layer": "PC", "plane": "lifecycle", "name": "Privacy Certification Program", "plain": "The organization implements or aligns with a recognized privacy certification such as ISO/IEC 27701 or a GDPR Art 42 mechanism to provide structured, independently verified evidence of systematic privacy management.", "threat": { "tags": [ "no-formal-certification", "privacy-program-not-third-party-validated", "customer-trust-gap" ], "desc": "Privacy certifications provide external validation that internal controls meet an established standard. In the AI sector, customers, regulators, and enterprise procurement increasingly require evidence of independent privacy validation. Self-assertion without certification is insufficient." }, "standard": [ { "id": "gdpr", "section": "Art 42/Art 43", "title": "Certification mechanisms for data protection compliance" }, { "id": "iso_27701", "section": "PIMS certification", "title": "ISO/IEC 27701:2019 PIMS certification (standard as a whole)" }, { "id": "nist_pf", "section": "GV.MT-P3", "title": "Compliance assessment policies, processes, and procedures" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PC-02 Privacy Certification Program control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Pursue ISO/IEC 27701 certification for the privacy information management system with GDPR Art 42 alignment, and publish certification scope and expiry dates to internal and external stakeholders on the trust portal.", "steps": [ "Define the certification scope — the AI products, processing activities, and organizational units to be included — and select a certification body accredited under GDPR Art 43 or IAF-recognized for ISO 27701.", "Conduct a gap assessment against the ISO 27701 control set, remediate identified gaps, and complete a Stage 1 readiness review followed by a Stage 2 certification audit.", "Maintain certification currency through annual surveillance audits, resolve corrective actions before the next audit cycle, and publish the certificate scope and expiry on the trust portal." ], "anti_patterns": [ "Pursuing certification as a one-time badge rather than as evidence of a functioning management system — the annual surveillance audit will fail if controls lapsed post-initial-certification.", "Defining a narrow certification scope that excludes the highest-risk processing activities, producing a certificate that provides little assurance for the activities customers and regulators actually care about." ] }, "validation": { "design_check": [ "Verify a certification body has been selected and a gap assessment against ISO 27701 or equivalent is documented with a remediation plan [ref:iso_27701_2019]", "Confirm the certification scope includes the AI products and processing activities representing the highest privacy risk [ref:gdpr_2016_679]", "Check that certificate expiry dates are tracked in a governance register and renewal timelines are managed with at least 90-day lead time [ref:nist_pf_1_0]" ], "runtime_test": [ "Request the most recent audit report from the certification body and verify that all corrective actions from the previous cycle are closed with evidence.", "Test that the trust portal or privacy centre publishes the current certificate scope, expiry date, and certifying body name.", "Verify that enterprise procurement responses reference the certification with current certificate number and scope." ], "evidence": [ "privacy:certification-certificate — Current ISO 27701 or equivalent certificate with scope, expiry date, and certifying body [unverified]", "privacy:audit-report — Most recent surveillance or certification audit report with findings and corrective action closure status [unverified]", "privacy:gap-assessment — Pre-certification gap assessment documenting control coverage and remediation plan with completion evidence [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Certification requires technical controls to be documented, consistently implemented, and auditable — privacy engineers must ensure controls are not just deployed but demonstrably operational with retrievable evidence.", "actions": [ "Maintain a control evidence library with automated evidence collection for technical controls in scope for certification, mapped to ISO 27701 control identifiers.", "Flag any technical control change that affects certification scope to the DPO before implementation to prevent unintended scope violations.", "Build technical privacy control documentation in a form auditors can consume directly, without requiring engineering interpretation during the audit." ], "failure_signals": [ "Technical privacy controls lack documentation traceable to ISO 27701 control requirements.", "Evidence collection for certification is manual and ad hoc rather than automated from source systems.", "Control changes are made without assessing their impact on the certification scope." ] }, "dpo": { "summary": "The DPO is accountable for the privacy certification program, must sponsor the certification effort, and serves as the primary interface with the certification body throughout the audit cycle.", "actions": [ "Define the certification scope in consultation with product, legal, and engineering teams to ensure it covers the highest-risk AI processing activities.", "Sponsor corrective action resolution between audit cycles and verify closure evidence is available before the next surveillance audit.", "Report certification status, surveillance audit outcomes, and corrective action progress to senior leadership at least quarterly." ], "failure_signals": [ "The DPO is not the primary contact for the certification body, creating accountability gaps in audit coordination.", "Corrective actions from the last audit remain open at the commencement of the next surveillance cycle.", "Senior leadership is unaware of certification status or upcoming renewal deadlines." ] }, "data_governance": { "summary": "Data governance artifacts — inventories, processing records, retention schedules — are primary audit evidence for certification and must be maintained at the level of rigor the audit requires.", "actions": [ "Ensure the data inventory and processing records are complete, current, and accessible to auditors within the certification scope boundary.", "Align data classification and handling procedures with ISO 27701 PII handling requirements for the in-scope processing activities.", "Verify that data retention and deletion processes are documented with evidence of execution, not just policy statements." ], "failure_signals": [ "Processing records are incomplete or do not cover all in-scope processing activities identified in the certification boundary.", "Data retention policies lack evidence of enforcement such as deletion execution logs.", "Data classification does not align with ISO 27701 PII definitions for the in-scope data categories." ] }, "grc_auditor": { "summary": "An active ISO 27701 or equivalent certification is the strongest privacy program assurance artifact available; verify it is current, the scope is appropriate, and corrective actions are tracked to closure.", "actions": [ "Verify certificate currency, scope completeness, and certifying body accreditation status.", "Review the last audit report for open findings and verify closure evidence for each corrective action.", "Confirm that the certification scope covers the highest-risk processing activities identified in the privacy risk register." ], "metrics": [ "Days until certificate expiry (target: >90 days before renewal trigger)", "Percentage of prior-cycle corrective actions closed before next audit (target: 100%)" ], "failure_signals": [ "Certificate has lapsed or is within 30 days of expiry without renewal in progress.", "Open corrective actions from the last audit have no assigned owners or target closure dates.", "Certification scope excludes the organization's highest-risk AI processing activities." ] }, "software_engineering": { "summary": "Software engineers must implement technical privacy controls that are auditable and mapped to certification requirements, with sufficient logging to produce evidence for the audit cycle.", "actions": [ "Implement audit logging for all data subject rights request processing and consent management operations within the certification scope, retained for the required audit evidence period.", "Ensure cryptographic controls, access controls, and pseudonymisation implementations are documented in a form auditors can review without requiring source code inspection.", "Tag technical control implementations with their ISO 27701 control references in internal documentation to support the certification evidence library." ], "failure_signals": [ "Technical control implementations lack documentation linking them to certification requirements.", "Audit logs for rights request handling are not retained for the required evidence period.", "Access control configurations are not captured in configuration management, making them unverifiable by auditors." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most AI organizations have not yet pursued ISO 27701 certification; achieving defined maturity requires a completed gap assessment and an active certification engagement with a scheduled Stage 1 audit." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "GRC", "Legal/Compliance" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 42", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-02 partially addresses the GDPR Art 42 certification mechanism by implementing a certification program, though full Art 42 compliance requires DPA-accredited certification body involvement and approved certification criteria under Art 43.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "PIMS certification (standard as a whole)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-02 directly implements the ISO/IEC 27701:2019 certification objective — the standard as a whole rather than any single clause — requiring the organization to scope, audit, and maintain a PIMS conformant with the standard through a recognized certification body.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "nist_pf", "requirement_id": "GV.MT-P3", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "PC-02 supports NIST Privacy Framework GV.MT-P3 — policies, processes, and procedures for assessing compliance with legal requirements and privacy policies — by using external certification as a recurring, independent compliance assessment mechanism.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic compliance artifacts — SOC 2 Type II, GDPR DPA, HIPAA BAA", "rationale": "Anthropic maintains SOC 2 Type II certification, GDPR Data Processing Addendum, and HIPAA Business Associate Agreement for eligible healthcare enterprise customers. These certifications constitute the vendor-side privacy certification artifacts that enterprise customers must include when scoping their own privacy certification programs for AI systems built on the Anthropic API.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's SOC 2/DPA/BAA are vendor-side certification artifacts to reference, not the organization's own ISO 27701 or Art 42 certification PC-02 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI compliance certifications — SOC 2, ISO 27001, ISO 42001, CSA STAR", "rationale": "OpenAI holds SOC 2 Type II, ISO 27001, ISO 42001 (AI management system), and CSA STAR Level 1 certifications, and offers GDPR DPA and HIPAA BAA for qualifying customers. ISO 42001 is particularly relevant as the AI-specific management system certification, providing assurance of responsible AI governance practices applicable to privacy program certification.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's SOC 2/ISO 27001/ISO 42001 certs are vendor-side assurance to cite, not the organization's own privacy certification PC-02 requires it to hold.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "aws_privacy", "requirement_id": "AWS ISO/IEC 42001 accredited certification — AI services", "rationale": "AWS is the first major cloud service provider to achieve ISO/IEC 42001 accredited certification for AI services, covering Amazon Bedrock, Amazon Q Business, Amazon Textract, and Amazon Transcribe. This AI-specific management system certification is directly relevant to privacy certification programs for AI systems built on these AWS services, providing third-party assurance of AWS's AI governance practices.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS's ISO 42001 cert is vendor-side AI-governance assurance to cite, not the organization's own privacy certification that PC-02 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Azure AI compliance certifications — ISO 27001, SOC 2, ISO 42001", "rationale": "Microsoft Azure AI services maintain ISO 27001, SOC 2 Type II, and ISO 42001 certifications. Microsoft Purview Compliance Portal provides unified compliance posture reporting across certifications, enabling organizations building privacy certification programs for Azure AI-based systems to leverage Microsoft's certification artifacts as evidence of foundational privacy controls.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Azure's ISO 27001/SOC 2/ISO 42001 certs are vendor-side assurance artifacts, not the organization's own privacy certification PC-02 requires it to hold.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "A formal privacy certification program prevents the customer trust gap and regulatory credibility deficit that results from self-asserted privacy compliance. ISO 27701 certification provides independently verified evidence that the organization's privacy management system meets an internationally recognized standard, satisfying enterprise procurement requirements and demonstrating accountability to supervisory authorities through a structured, auditable program rather than assertions alone.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-02", "validation_objective": "The organization holds a current, valid ISO/IEC 27701 or equivalent GDPR Art 42 certification issued by an accredited certification body, with the certification scope covering the AI products and processing activities that carry the highest privacy risk. No corrective actions from prior audit cycles may remain open at the time of assessment, and the certificate expiry must be at least 90 days in the future.", "evidence_required": [ "certification_certificate with certification_body_name, scope_statement, issue_date, and expiry_date showing expiry > today + 90 days", "surveillance_or_stage2_audit_report from the most recent audit cycle listing all findings, corrective action status, and auditor sign-off", "pre_certification_gap_assessment documenting each ISO 27701 control gap, assigned remediation owner, and dated closure evidence", "certification_scope_definition identifying which AI products, processing activities, and organizational units are included and explicitly excluded", "control_evidence_register mapping each in-scope technical and organizational control to its ISO 27701 control identifier with evidence artifact references" ], "machine_tests": [ "Fetch trust_portal certification endpoint → assert certificate_number, scope, expiry_date present and expiry_date > today + 90 days", "Query corrective_action_register filtered to last_audit_cycle → assert count_open_items == 0", "Look up certification_body_name against IAF-recognized or GDPR Art 43 accredited body registry → assert is_accredited == true", "Verify certificate status in certification_body public registry by certificate_number → assert status == 'active'" ], "human_review": [ "Review certification scope boundary against the privacy risk register to confirm the highest-risk AI training pipelines, inference endpoints, and personal data stores are within scope — not excluded to simplify the audit", "Assess corrective action closure evidence for each finding from the last audit cycle to verify remediation was substantive and not superficially marked complete", "Verify the certification body's accreditation status and independence from the organization, confirming no conflict of interest exists in the audit relationship" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Defining a narrow certification scope that excludes high-risk AI training pipelines or inference endpoints to make the audit easier to pass, producing a certificate that provides negligible assurance for the activities regulators and customers care about", "Treating the initial certification as a permanent badge rather than a living management system, allowing controls to decay between annual surveillance cycles", "Using a self-assessment or unaccredited third-party review as a proxy for a formal certification body audit to claim Art 42 compliance without a DPA-accredited body", "Publishing a certificate on the trust portal after it has lapsed, misrepresenting current certification status to enterprise customers and supervisory authorities", "Allowing corrective actions from prior audit cycles to carry forward into subsequent audits rather than resolving them with closure evidence before the next surveillance date" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-03", "layer": "PC", "plane": "lifecycle", "name": "Jurisdiction-Specific Compliance Package", "plain": "Jurisdiction-specific compliance evidence packages are produced and maintained for each major regulatory scope, enabling rapid response to DPA inquiries and regulatory examinations without ad-hoc document assembly.", "threat": { "tags": [ "regulatory-inquiry-cannot-be-answered", "jurisdiction-obligations-not-documented", "audit-failure" ], "desc": "DPA investigations and regulatory examinations require production of jurisdiction-specific evidence within short timeframes. Organizations that assemble compliance dossiers on-demand — rather than maintaining current packages — systematically fail examinations due to document gaps and inconsistencies." }, "standard": [ { "id": "gdpr", "section": "Art 30/Art 37(6)", "title": "Records of processing and DPO reporting obligations" }, { "id": "uk_duaa", "section": "complaints procedure", "title": "Statutory data protection complaints procedure" }, { "id": "ccpa", "section": "§1798.135", "title": "Compliance verification obligations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-01" }, { "id": "uk_duaa_2025", "title": "Data (Use and Access) Act 2025 (UK DUAA)", "authority": "UK Parliament", "source_type": "binding-law", "normative_force": "binding-law", "version": "2025 c. 18", "published_on": "2025-06-19", "retrieved_on": "2026-06-28", "canonical_url": "https://www.legislation.gov.uk/ukpga/2025/18", "license": "open-government-licence-v3", "status": "current", "flagship": false, "source_id": "uk_duaa_2025", "relationship": "normative_requirement", "rationale": "Establishes Data (Use and Access) Act 2025 (UK DUAA) requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-02" }, { "id": "ccpa_cpra_2023", "title": "California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations", "authority": "California Privacy Protection Agency / California Legislature", "source_type": "regulation", "normative_force": "binding-law", "version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "published_on": "2023-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5.", "license": "public-domain", "status": "current", "flagship": false, "source_id": "ccpa_cpra_2023", "relationship": "normative_requirement", "rationale": "Establishes California Consumer Privacy Act (CPRA) + CPPA ADMT Regulations requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-02" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PC-03 Jurisdiction-Specific Compliance Package control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Maintain pre-assembled compliance packages for each major jurisdiction — GDPR (EU), UK DUAA, CCPA/CPRA, India DPDPA — each containing the processing records, DPIA summaries, consent evidence, breach logs, and rights request statistics relevant to that jurisdiction's examination requirements.", "steps": [ "Identify the set of documents required for each jurisdiction's regulatory examination — GDPR Art 30 records, CCPA verification obligations, UK DUAA documentation requirements — and create a package template for each jurisdiction.", "Automate or semi-automate population of each package from source systems (privacy management platform, DSAR tracker, DPIA register) so packages are always current rather than assembled on demand after an inquiry arrives.", "Conduct an annual mock regulatory examination for each jurisdiction using the current compliance package to identify gaps before a real inquiry triggers the same findings." ], "anti_patterns": [ "Treating the compliance package as a project deliverable assembled during an actual investigation — the time pressure of a DPA inquiry is the worst possible moment to discover document gaps or inconsistencies.", "Maintaining a single combined compliance document rather than jurisdiction-specific packages, causing confusion during examination about which sections satisfy which DPA's requirements." ] }, "validation": { "design_check": [ "Verify compliance packages exist for all jurisdictions identified in the PC-01 obligation matrix [ref:gdpr_2016_679]", "Confirm each package contains the document types required for that jurisdiction's examination standard, validated against a published DPA examination framework [ref:uk_duaa_2025]", "Check that packages have a defined refresh cadence and the last-updated date is within 90 days [ref:ccpa_cpra_2023]" ], "runtime_test": [ "Simulate a GDPR Art 58 supervisory authority information request and measure the time required to produce a complete response package from the pre-assembled document store.", "Verify that the CCPA compliance package contains current opt-out implementation evidence for all California-facing AI products.", "Test package completeness against a published DPA examination checklist such as the ICO or CNIL audit questionnaire." ], "evidence": [ "privacy:gdpr-compliance-package — Current GDPR compliance package with Art 30 records, DPIA register, and DPO appointment evidence [unverified]", "privacy:uk-duaa-compliance-package — Current UK DUAA compliance package with UK GDPR-aligned documentation and DUAA-specific requirements [unverified]", "privacy:ccpa-compliance-package — Current CCPA/CPRA compliance package with opt-out evidence and ADMT regulation documentation [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers must ensure that source systems — DSAR trackers, consent logs, processing activity logs — produce exportable, jurisdiction-tagged artifacts that feed compliance packages without manual extraction.", "actions": [ "Build jurisdiction-tagged evidence exports from the privacy management platform that automatically populate compliance package templates on a defined schedule.", "Ensure consent and opt-out event logs are queryable by jurisdiction and product, enabling package population without bespoke data pulls for each examination.", "Instrument the DSAR handling system to produce jurisdiction-specific response statistics in a format directly usable in compliance packages." ], "failure_signals": [ "Compliance packages must be manually assembled from disparate systems rather than generated from a unified privacy data store.", "Consent evidence cannot be filtered by jurisdiction, requiring manual extraction to build jurisdiction-specific packages.", "DSAR response statistics are not available in a format suitable for regulatory reporting." ] }, "dpo": { "summary": "The DPO must ensure compliance packages are maintained at the level of completeness and currency that would satisfy a DPA examination on the day it arrives, not the day preparation begins.", "actions": [ "Own the compliance package templates for each jurisdiction and review them against updated regulatory guidance at least annually.", "Conduct an annual mock DPA examination using current packages to identify gaps before a real inquiry.", "Establish an escalation process for urgent document requests that can produce a package within 72 hours of DPA first contact." ], "failure_signals": [ "No mock examination has been conducted for any jurisdiction in the past 12 months.", "A compliance package template has not been updated following a material regulatory guidance update.", "The organization cannot produce an Art 30 processing record within 24 hours of a DPA information request." ] }, "data_governance": { "summary": "Data governance is the primary source for processing records, data inventories, and retention documentation that constitute the core of each compliance package.", "actions": [ "Ensure the data inventory produces jurisdiction-specific views of processing activities for direct inclusion in compliance packages.", "Maintain processing records in a jurisdiction-specific format exportable to each compliance package template without restructuring.", "Track data subject rights request outcomes at the granularity required for regulatory reporting in each jurisdiction." ], "failure_signals": [ "Processing records are maintained in a single global format requiring restructuring for each jurisdiction's examination.", "Data inventory does not produce exportable reports suitable for compliance package inclusion.", "Rights request outcomes are tracked at insufficient granularity for jurisdiction-specific regulatory reporting." ] }, "grc_auditor": { "summary": "Compliance packages are the primary evidence artifacts for privacy program assurance; verify they are current, complete against each jurisdiction's examination standard, and have been tested through mock examinations.", "actions": [ "Review compliance packages against the document requirements for each jurisdiction's regulatory examination standard.", "Verify that mock examination records exist for each major jurisdiction in the past 12 months with identified gaps and closure evidence.", "Test package production time by simulating an urgent DPA information request and measuring response time." ], "metrics": [ "Time to produce a complete compliance package from DPA inquiry receipt (target: <72 hours)", "Percentage of jurisdictions with compliance packages reviewed in past 90 days (target: 100%)" ], "failure_signals": [ "One or more major jurisdictions lack a pre-assembled compliance package.", "Compliance packages have not been updated in more than 90 days.", "No mock examination records exist for any jurisdiction in the past 12 months." ] }, "software_engineering": { "summary": "Software engineers support compliance package production by ensuring system-generated evidence artifacts are exportable, timestamped, and jurisdiction-tagged.", "actions": [ "Implement export APIs for privacy-relevant system data — consent logs, DSAR events, breach notifications — that support compliance package automation with jurisdiction filtering.", "Ensure all privacy event logs include jurisdiction tags and are retained for the maximum applicable regulatory evidence period.", "Build compliance package generation tooling that pulls from source system APIs rather than requiring manual document assembly." ], "failure_signals": [ "Privacy system event logs cannot be exported in a format directly usable in compliance packages.", "Logs lack jurisdiction tags, preventing jurisdictionally accurate reporting.", "Compliance package generation requires manual steps that introduce error and delay under examination time pressure." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations maintain GDPR Art 30 records but have not assembled jurisdiction-specific packages for CCPA, India DPDPA, and UK DUAA ready for examination on demand." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Legal/Compliance", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 30", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-03 directly implements the GDPR Art 30 records of processing activities requirement as the core artifact of the GDPR compliance package, ensuring records are maintained at a level of completeness suitable for supervisory authority examination.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "uk_duaa", "requirement_id": "Data protection complaints procedure", "fit": "partial", "direction": "control-supports-requirement", "rationale": "The Data (Use and Access) Act 2025 introduces a statutory requirement for controllers to facilitate and respond to data protection complaints from data subjects; PC-03's UK package must include the complaint-handling documentation demonstrating that procedure.", "source_version": "2025 c.15", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "ccpa", "requirement_id": "§1798.135", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-03 partially addresses CCPA/CPRA §1798.135 verification obligations by maintaining a California-specific compliance package with opt-out evidence, though full CCPA compliance requires additional consumer rights and ADMT-specific documentation.", "source_version": "CPRA eff. 2023-01-01; ADMT Regs adopted 2025-07-24", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "openai_privacy", "requirement_id": "OpenAI data residency — regional offerings", "rationale": "OpenAI offers data residency and region-specific compliance packages for enterprise and API customers in the US, EU, UK, Japan, Canada, South Korea, Singapore, Australia, India, and UAE. Region-specific DPA terms are available for jurisdictions with distinct legal requirements. These packages form the OpenAI-layer component of jurisdiction-specific privacy compliance documentation for AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's region-specific offerings form the vendor-layer component of jurisdiction documentation, not the enterprise's pre-assembled compliance package.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft EU Data Boundary and Jurisdiction-Specific DPAs", "rationale": "Microsoft's EU Data Boundary commitment covers Azure AI services with contractual data residency for EU/EFTA personal data. Jurisdiction-specific DPA annexes are available for UK GDPR, Swiss FADP, and other major privacy laws. Microsoft Purview provides jurisdiction-tagged compliance assessments enabling organizations to maintain separate compliance packages per jurisdiction.", "normative_force": "best-practice", "fit": "partial", "fit_rationale": "Microsoft's jurisdiction-specific DPA annexes and Purview jurisdiction-tagged assessments help assemble separate per-jurisdiction packages aligned with PC-03.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Artifact — jurisdiction-organized compliance reports and agreements", "rationale": "AWS Artifact provides downloadable compliance reports and agreements (including the AWS GDPR DPA), and AWS Region selection supports data residency for personal data; PC-03 assembles these into jurisdiction-specific compliance packages.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS Artifact's jurisdiction-organized reports and DPA are inputs assembled into the compliance package, not the pre-assembled package PC-03 maintains.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Data Processing Addendum and compliance documentation", "rationale": "Anthropic's DPA covers EU GDPR compliance with incorporated SCCs for third-country transfers. HIPAA BAA is available for US healthcare customers. Enterprise customers with jurisdiction-specific requirements can request tailored DPA terms. Anthropic's Privacy Center documents GDPR rights for EU-based users, forming part of the jurisdiction-specific compliance documentation for European AI deployments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's DPA, SCCs, BAA, and Privacy Center docs form part of jurisdiction-specific documentation but not the enterprise's assembled compliance package.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "owasp_ai_exchange", "requirement_id": "checkcompliance", "fit": "supporting", "rationale": "PC-03 maintains per-jurisdiction compliance evidence packages mapping each regulatory obligation to a controlling control and artifact, evidencing compliance with applicable law.", "normative_force": "industry-framework", "source_version": "continuously-updated", "reviewed_on": "2026-07-08", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Pre-assembled jurisdiction-specific compliance packages prevent the examination failure that results from attempting to assemble evidence under the time pressure of an active DPA inquiry. By maintaining current packages for each major regulatory scope, the organization can respond to supervisory authority requests within required timeframes with complete, consistent, and auditable evidence — turning regulatory readiness from a reactive scramble into a maintained operational state.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-03", "validation_objective": "For each regulatory jurisdiction in which the organization processes personal data, a pre-assembled compliance evidence package exists that is version-controlled, reviewed within the past 12 months, and maps each applicable regulatory obligation to the controlling Apeiris privacy control and its evidence artifact. The package must be deliverable to a supervisory authority within the organization's defined DPA inquiry response SLA.", "evidence_required": [ "jurisdiction_registry listing all active data-processing jurisdictions with applicable regulatory framework identifiers, DPA contact details, and most recent package review date", "obligation_to_control_mapping for each jurisdiction linking each regulatory obligation to the Apeiris privacy canonical_id addressing it, with evidence artifact references for each mapping", "compliance_package_artifact_manifest for each jurisdiction with document titles, versions, storage location references, and last-updated timestamps", "dpa_response_playbook specifying package assembly procedure, authorized sender identities, and target delivery SLA for each jurisdiction's regulatory authority" ], "machine_tests": [ "Query jurisdiction_registry for all active processing jurisdictions → assert each entry has a corresponding package entry with last_reviewed_date within 365 days of today", "Trigger simulated package assembly for each jurisdiction → assert all artifact_manifest entries resolve to accessible documents within the defined SLA window", "Query package version history for each jurisdiction → assert current_version > 0 and last_updated within 12 months", "Verify obligation_to_control_mapping completeness → assert no GDPR, UK DUAA, or CCPA statutory obligation appears as unmapped in any active jurisdiction" ], "human_review": [ "Review the obligation-to-control mapping for the highest-risk jurisdiction to verify completeness and that no binding statutory obligations are left without a corresponding control and evidence reference", "Assess whether the package assembly procedure can realistically meet the defined DPA inquiry response SLA given the current evidence retrieval and approval workflow", "Verify that jurisdiction packages are updated within a defined window when regulatory changes occur and that a change notification process exists to trigger updates" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Maintaining a single undifferentiated compliance evidence repository rather than pre-assembled jurisdiction-specific packages, requiring ad-hoc assembly under time pressure during an active DPA investigation", "Marking jurisdiction packages as 'current' without a structured periodic review, resulting in packages that reference superseded regulatory obligations or expired control evidence", "Omitting jurisdictions where the organization has limited but nonzero data processing activity on the assumption that regulators in those jurisdictions are unlikely to inquire", "Creating obligation mappings at the regulation level rather than at the obligation level, making it impossible to demonstrate point-by-point compliance when a DPA requests evidence for a specific article" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-04", "layer": "PC", "plane": "lifecycle", "name": "Privacy Program Effectiveness Assessment", "plain": "Periodic assessments measure privacy program effectiveness against defined metrics — DSAR response rates, DPIA completion rates, breach detection times, consent compliance rates — and produce management reporting.", "threat": { "tags": [ "privacy-program-performance-unmeasured", "systemic-issues-undetected", "regulatory-examination-reveals-failures" ], "desc": "Privacy programs that are not measured cannot be managed. Systemic failures — such as persistent DSAR deadline misses or DPIA backlogs — become enforcement findings precisely because management had no metrics to detect and remediate them." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)/Art 24", "title": "Accountability and responsibility of the controller" }, { "id": "nist_pf", "section": "GV.MT-P3", "title": "Compliance assessment policies, processes, and procedures" }, { "id": "iso_27701", "section": "5.7.1", "title": "Monitoring, measurement, analysis and evaluation" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-04 Privacy Program Effectiveness Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Define a privacy program effectiveness metrics set with numerical targets, measure against those targets quarterly with automated collection from source systems, and produce management reports that escalate out-of-threshold metrics for remediation.", "steps": [ "Define a privacy metrics baseline covering DSAR on-time completion rate, DPIA initiation rate for qualifying processing activities, breach detection-to-notification time, consent validity rates, and privacy training completion rates, with numerical targets for each.", "Implement automated metric collection from the DSAR tracker, DPIA register, incident management system, and consent platform; produce quarterly effectiveness reports with trend analysis and explicit threshold breach flags.", "Establish a metrics review governance process where the DPO presents effectiveness reports to senior leadership with specific remediation requests for any metric outside defined thresholds, and document management decisions." ], "anti_patterns": [ "Tracking activity metrics (number of DPIAs completed) rather than outcome metrics (percentage of qualifying projects with DPIA initiated before processing began), which masks systematic failures in the process.", "Producing metrics reports without defined numerical targets or threshold triggers, rendering them incapable of driving management attention and remediation action." ] }, "validation": { "design_check": [ "Verify a defined privacy metrics set with numerical targets is documented and approved by the DPO [ref:gdpr_2016_679]", "Confirm metric collection is automated from source systems with a defined quarterly reporting cadence and a defined escalation trigger for out-of-threshold results [ref:nist_pf_1_0]", "Check that management reporting includes trend analysis, threshold status, and documented management decisions for escalated metrics [ref:iso_27701_2019]" ], "runtime_test": [ "Review the last four quarters of effectiveness reports and verify that metrics are measured against defined targets with explicit threshold status.", "Test that a simulated DSAR deadline miss triggers an alert in the metrics system within the defined detection window.", "Verify that at least one management escalation based on an out-of-threshold metric is evidenced with a management decision record in the past 12 months." ], "evidence": [ "privacy:effectiveness-reports — Last four quarters of privacy program effectiveness reports with metrics, targets, trend analysis, and threshold status [unverified]", "privacy:metrics-dashboard — Automated privacy metrics dashboard with defined targets and current status for all key indicators [unverified]", "privacy:management-escalation-log — Record of management escalations triggered by out-of-threshold privacy metrics with documented management decisions [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers build the instrumentation that feeds the effectiveness metrics — DSAR tracking, consent rate measurement, DPIA trigger detection — and must ensure data quality is sufficient for reliable reporting.", "actions": [ "Instrument the DSAR management system to automatically track intake-to-resolution timelines and flag approaching deadlines before they breach.", "Build consent rate dashboards that break down by product, jurisdiction, and consent type to identify specific compliance gaps rather than aggregate averages.", "Implement automated DPIA trigger detection in the product development pipeline to measure the rate of qualifying projects with timely DPIA initiation." ], "failure_signals": [ "DSAR timelines are tracked in spreadsheets rather than an automated system, producing unreliable and unauditable metrics.", "Consent rate metrics are not available at the product and jurisdiction level of granularity required to identify specific compliance gaps.", "DPIA initiation rate cannot be measured because no automated trigger exists in the development pipeline." ] }, "dpo": { "summary": "The DPO must define what good looks like — setting numerical targets for each metric — and own the governance process that escalates failures and drives documented management remediation.", "actions": [ "Define numerical targets for each privacy metric and publish them to the organization so all stakeholders understand the performance standard.", "Present the quarterly effectiveness report to senior leadership with specific remediation requests for any out-of-threshold metric.", "Use effectiveness metrics as input to the annual privacy risk assessment and certification audit preparation." ], "failure_signals": [ "Metrics targets are not defined, making it impossible to determine whether any metric value represents a performance problem.", "The DPO does not present effectiveness metrics to senior leadership — metrics are internal-only without the management visibility required for Art 24 accountability.", "Persistent out-of-threshold metrics do not trigger documented remediation actions with owners and target dates." ] }, "data_governance": { "summary": "Data governance metrics — processing record completeness, retention compliance, data quality — are inputs to the privacy effectiveness assessment and must be measured alongside privacy-specific metrics.", "actions": [ "Include data quality and processing record completeness metrics in the effectiveness assessment alongside DSAR and DPIA metrics.", "Track data retention compliance rates as an effectiveness metric to identify systematic failures in deletion execution.", "Contribute data governance metrics to the quarterly effectiveness report for unified management review." ], "failure_signals": [ "Data quality metrics are not included in the privacy effectiveness assessment, creating a blind spot for governance-driven privacy failures.", "Retention compliance rates are not measured, obscuring systematic deletion failures.", "Data governance and privacy teams produce separate reports rather than a unified effectiveness view for management." ] }, "grc_auditor": { "summary": "Privacy program effectiveness metrics are the Art 5(2) accountability evidence demonstrating that the controller's privacy measures are actually working; verify targets are defined, metrics are current, and out-of-threshold issues are escalated with management responses.", "actions": [ "Review the effectiveness metrics set against recognized benchmarks such as IAPP privacy metrics guidance to assess whether the right indicators are measured.", "Verify that each metric has a documented target and that the quarterly reporting cadence has been maintained without gaps.", "Trace out-of-threshold metrics to documented management escalations and remediation evidence demonstrating the issue was addressed." ], "metrics": [ "DSAR on-time completion rate (target: >98%)", "Percentage of qualifying projects with DPIA initiated before processing (target: >95%)" ], "failure_signals": [ "Effectiveness reports are produced less frequently than quarterly.", "One or more key metrics have been persistently out of threshold for two or more consecutive quarters without documented remediation.", "Management has not received or acknowledged any effectiveness report in the past 12 months." ] }, "software_engineering": { "summary": "Software engineers support effectiveness measurement by building reliable instrumentation, ensuring source data quality, and maintaining the systems that feed privacy metrics dashboards.", "actions": [ "Implement reliable event logging for all DSAR, consent, and breach-related events with timestamps accurate to the minute for SLA compliance tracking.", "Build API endpoints for the privacy metrics dashboard to consume from source systems with live data rather than scheduled manual exports.", "Ensure privacy instrumentation failures are included in engineering on-call runbooks so data quality issues are detected and remediated within the SLA of the next reporting cycle." ], "failure_signals": [ "Privacy event logs have gaps or inconsistent timestamps that degrade metrics accuracy and undermine SLA tracking.", "Metrics dashboard requires manual data entry from system exports rather than live API feeds.", "Privacy instrumentation failures are not monitored and may go undetected for multiple days." ] } }, "maturity": { "current": "initial", "target": "managed", "notes": "Most privacy programs track activities but lack defined numerical metric targets, automated collection, and a formal management reporting cadence required for managed maturity." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "GRC", "Privacy Engineering" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 24", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-04 partially implements the GDPR Art 24 accountability obligation by providing measurable evidence that technical and organisational measures are effective, though full Art 24 compliance encompasses the entire privacy program rather than metrics measurement alone.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "GV.MT-P3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-04 directly implements NIST Privacy Framework GV.MT-P3 — policies, processes, and procedures for assessing compliance with legal requirements and privacy policies are established and in place — as a scheduled, metric-driven effectiveness assessment.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "iso_27701", "requirement_id": "5.7.1", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-04 directly implements ISO/IEC 27701:2019 clause 5.7.1 (extending ISO/IEC 27001 clause 9.1), which requires monitoring, measurement, analysis, and evaluation of the privacy information management system at planned intervals.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Core element — Adapt controls to adjust mitigations and create faster feedback loops for AI deployment", "rationale": "SAIF's fifth core element calls for continuously adapting controls and shortening feedback loops as AI deployments evolve; PC-04's recurring effectiveness assessment provides the privacy-program feedback loop that drives those adjustments.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's adapt-controls/feedback-loop element is a related governance principle but not the privacy-program effectiveness metrics and reporting PC-04 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Audit Manager — framework-based assessments", "rationale": "AWS Audit Manager provides pre-built assessment frameworks for GDPR, CCPA, and other privacy laws with automated evidence collection from AWS services. For AI-specific privacy controls, Audit Manager supports custom framework creation, enabling organizations to conduct structured, evidence-backed privacy program effectiveness assessments with quantifiable control coverage metrics.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Audit Manager runs framework-based assessments with automated evidence and coverage metrics, providing an assessment mechanism aligned with PC-04's review.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Purview Compliance Manager — compliance score and tracking", "rationale": "Microsoft Purview Compliance Manager provides a quantified compliance score and improvement action tracking for ongoing privacy program effectiveness measurement. The compliance score benchmarks organizational privacy posture against regulatory requirements and best practices, with trend tracking across assessment cycles enabling measurement of privacy program improvement over time.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview Compliance Manager's compliance score and trend tracking measure privacy posture over cycles, providing effectiveness measurement aligned with PC-04.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "detective", "matrix_thesis": "Privacy program effectiveness assessment detects the systemic failures that would otherwise become enforcement findings — DSAR backlogs, DPIA initiation gaps, and consent compliance failures that persist undetected without measurement. By producing quantified, management-visible effectiveness metrics on a defined cadence, the organization creates the accountability loop that drives remediation before regulators identify the same deficiencies during examination.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-04", "validation_objective": "The privacy program produces effectiveness assessments on the documented cadence (at minimum annually, quarterly for high-risk programs) measuring DSAR response rate, DPIA completion rate, breach notification SLA compliance, and consent compliance rate against defined targets. Assessment findings are reported to senior leadership with remediation actions tracked to closure.", "evidence_required": [ "privacy_effectiveness_assessment_report for each assessment period with period dates, methodology, metric results against defined targets, variance explanations, and management sign-off", "metric_baseline_register defining target thresholds for DSAR on-time response rate, DPIA completion rate, breach notification SLA compliance, and consent compliance rate", "remediation_action_log for assessment findings with owner, target closure date, and dated closure evidence for each item", "management_presentation_record or board_reporting_evidence confirming privacy effectiveness metrics were presented to senior leadership within each reporting period" ], "machine_tests": [ "Query DSAR_tracker for all requests in the past 12 months → compute on_time_response_rate = closed_on_time / total; assert on_time_response_rate >= configured_dsar_target", "Query DPIA_register for all in-scope processing activities → compute completion_rate = approved_dpias / required_dpias; assert completion_rate >= 0.95", "Query incident_log for reportable breach events in past 12 months → compute notification_sla_rate = notified_within_72h / total_reportable_breaches; assert notification_sla_rate >= configured_target", "Query effectiveness_assessment_schedule → assert last_assessment_completed_date is within the configured assessment cadence window (e.g., <= 365 days for annual programs)" ], "human_review": [ "Assess whether the selected metrics actually surface privacy program weaknesses or are vanity metrics designed to consistently show favorable results without revealing systemic gaps", "Review the remediation action log for prior assessment findings to verify actions are substantive and formally closed rather than superficially marked complete without evidence", "Evaluate whether assessment findings are escalated to drive real program investment or are consistently deprioritized, with the same gaps recurring across successive assessment cycles" ], "blocking_effect": "requires-review", "normative_status": "binding-law", "anti_patterns": [ "Selecting metrics that are easy to achieve rather than metrics that reveal real privacy risk — for example, measuring the number of DSARs submitted rather than the on-time response rate or rights fulfillment accuracy", "Producing assessment reports that highlight favorable metrics prominently while omitting or footnoting metrics that underperformed targets", "Treating the assessment as an annual documentation exercise that produces a report rather than a continuous measurement process that drives program improvement between cycles", "Not connecting assessment findings to budget or resourcing decisions, allowing the same identified gaps to persist across multiple consecutive assessment cycles without resolution" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-05", "layer": "PC", "plane": "lifecycle", "name": "Privacy-by-Design Certification", "plain": "Evidence is produced demonstrating that privacy was designed into AI systems from inception — including threat models, privacy-enhancing technology selections, and design-phase privacy decisions at each development stage.", "threat": { "tags": [ "privacy-retrofit-failures", "no-design-phase-documentation", "art25-non-compliance" ], "desc": "Art 25 requires that technical and organisational measures implement data protection principles at design time. AI systems where privacy is retrofitted after development — adding scrubbing or minimization as afterthoughts — fail Art 25 and produce weaker controls than privacy-by-design would achieve." }, "standard": [ { "id": "gdpr", "section": "Art 25", "title": "Data protection by design and by default" }, { "id": "nist_pf", "section": "GV.PO-P2", "title": "Processes to instill privacy values in development and operations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-05 Privacy-by-Design Certification control.", "reviewed_on": "2026-07-01" }, { "id": "nist_pf_1_0", "title": "NIST Privacy Framework 1.0", "authority": "National Institute of Standards and Technology (NIST)", "source_type": "voluntary-standard", "normative_force": "voluntary-standard", "version": "1.0", "published_on": "2020-01-16", "retrieved_on": "2026-06-28", "canonical_url": "https://doi.org/10.6028/NIST.CSWP.01162020", "license": "public-domain", "status": "current", "flagship": true, "source_id": "nist_pf", "relationship": "implementation_pattern", "rationale": "Establishes NIST Privacy Framework 1.0 requirements informing the apeiris://privacy/controls/PC-05 Privacy-by-Design Certification control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-05 Privacy-by-Design Certification control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PC-05 Privacy-by-Design Certification control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-05 Privacy-by-Design Certification control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Integrate privacy-by-design checkpoints into the AI system development lifecycle — from architecture review through model design, training pipeline, and deployment — with documented evidence of privacy decisions at each stage and a DPO-signed attestation document produced at launch.", "steps": [ "Establish a privacy design gate at the architecture phase requiring a privacy threat model, data minimization analysis, and PET selection rationale before engineering begins on any AI system processing personal data.", "At the model design phase, document training data minimization decisions, pseudonymisation and anonymisation techniques applied, and differential privacy parameters where applicable.", "At deployment, produce a privacy-by-design attestation document capturing all design-phase privacy decisions, the privacy engineer sign-off, and the DPO review, to serve as the Art 25 evidence artifact." ], "anti_patterns": [ "Adding a privacy label to an existing engineering decision after the fact — labelling a pre-existing data minimization decision as privacy-by-design without evidence it was a deliberate design choice made before implementation.", "Conflating privacy-by-design documentation with the DPIA — the DPIA assesses risk; privacy-by-design documentation evidences design decisions. Both are required and neither substitutes for the other." ] }, "validation": { "design_check": [ "Verify a privacy design gate exists in the AI development process with documented requirements for a threat model and PET selection rationale [ref:gdpr_2016_679]", "Confirm privacy-by-design attestation documents are produced for each AI system and retained in the product evidence library [ref:eu_ai_act_2024]", "Check that privacy-by-design decisions are documented at architecture, model design, and deployment phases for at least three current AI systems in production [ref:nist_pf_1_0]" ], "runtime_test": [ "Pull a sample AI system and verify a privacy-by-design attestation document exists covering architecture, model design, and deployment phases with privacy engineer and DPO sign-offs.", "Test that the engineering change management process blocks deployment of a major AI system change without a privacy design gate sign-off.", "Review a privacy threat model from the most recent AI system launch and verify it addresses AI-specific threats including training data exposure and inference attacks." ], "evidence": [ "privacy:pbd-attestation — Privacy-by-design attestation document for at least one AI system with architecture, model design, and deployment phase sign-offs [unverified]", "privacy:privacy-threat-model — Privacy threat model for an AI system demonstrating AI-specific risk identification at the design phase [unverified]", "privacy:pet-selection-rationale — Documentation of privacy-enhancing technology selection decisions for at least one AI model training pipeline [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers own the privacy-by-design process — producing threat models, recommending PETs, and signing attestation documents — and must integrate these checkpoints into the engineering workflow without creating unsustainable bottlenecks.", "actions": [ "Develop a lightweight AI-specific privacy threat model template covering training data exposure, inference attacks, membership inference, and output privacy risks, for use at the architecture phase.", "Create a PET selection decision tree that guides engineering teams through anonymisation, pseudonymisation, differential privacy, and federated learning options based on the data sensitivity and processing context.", "Build the privacy design gate into the CI/CD pipeline as an enforced check that cannot be bypassed without an explicit privacy engineer override with documented justification." ], "failure_signals": [ "Privacy design gates are advisory only with no enforcement mechanism, resulting in AI systems launched without privacy engineer sign-off.", "Privacy threat models use generic templates not tailored for AI-specific risks such as memorization and embedding inversion.", "PET selection is not documented, making it impossible to evidence the Art 25 by-design requirement." ] }, "dpo": { "summary": "The DPO must define the organizational policy requiring privacy-by-design, review attestation documents for high-risk AI systems, and use these as Art 25 accountability demonstrations to supervisory authorities.", "actions": [ "Issue a privacy-by-design policy defining mandatory checkpoints and documentation requirements for all AI systems processing personal data.", "Review and approve privacy-by-design attestation documents for high-risk AI systems before deployment sign-off.", "Present privacy-by-design attestation artifacts to supervisory authorities as Art 25 evidence during examination or investigation." ], "failure_signals": [ "No formal privacy-by-design policy exists that mandates checkpoints and documentation requirements.", "The DPO has not reviewed privacy-by-design attestation documents for any AI system in the past 12 months.", "The organization cannot produce Art 25 evidence for any deployed AI system processing personal data." ] }, "data_governance": { "summary": "Data governance must ensure that data minimization and retention decisions made during the privacy-by-design process are operationalized in the data catalog and enforced at runtime.", "actions": [ "Register privacy-by-design decisions — data minimization scope, PET applications, pseudonymisation boundaries — in the data catalog so they inform ongoing data governance.", "Verify that training datasets used for AI models have documented data minimization decisions from the design phase.", "Track compliance with design-phase data minimization decisions through runtime data governance controls." ], "failure_signals": [ "Design-phase data minimization decisions are not reflected in the data catalog, allowing runtime usage to drift from design intent.", "Training datasets include personal data beyond what the design-phase minimization decision permitted.", "No mechanism exists to verify that runtime data usage complies with design-phase PET commitments." ] }, "grc_auditor": { "summary": "Privacy-by-design attestation documents are the Art 25 evidence artifacts; verify they are produced for all qualifying AI systems, contain substantive privacy decisions rather than boilerplate, and are updated on system changes.", "actions": [ "Sample deployed AI systems processing personal data and verify a privacy-by-design attestation document exists for each.", "Review the content of attestation documents to verify they contain system-specific privacy decisions rather than generic assertions.", "Verify that attestation documents are updated when the AI system is materially modified." ], "metrics": [ "Percentage of AI systems processing personal data with a current privacy-by-design attestation (target: 100%)", "Percentage of AI system launches with documented privacy design gate sign-off (target: 100%)" ], "failure_signals": [ "One or more deployed AI systems processing personal data have no privacy-by-design attestation.", "Attestation documents contain generic assertions without system-specific privacy decisions.", "Attestation documents have not been updated following material system modifications." ] }, "software_engineering": { "summary": "Software engineers are the implementers of privacy-by-design decisions — they must understand documented privacy decisions and implement them faithfully, flagging divergence back to the privacy engineer rather than silently deviating.", "actions": [ "Review the privacy-by-design attestation document for the system before beginning implementation to understand required PETs, data minimization constraints, and pseudonymisation requirements.", "Flag to the privacy engineer any technical constraint that prevents implementing a documented privacy decision, rather than silently deviating and leaving the attestation inaccurate.", "Include privacy-by-design implementation verification in the definition of done for all features touching personal data." ], "failure_signals": [ "Engineering teams are unaware of the privacy-by-design attestation document for their system.", "Technical deviations from documented privacy decisions are not flagged to the privacy engineer.", "Privacy-by-design implementation verification is not part of the standard engineering definition of done." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most AI organizations conduct some privacy review but lack the structured design-phase checkpoints and attestation documentation required for Art 25 compliance evidence at supervisory authority examination." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "Privacy Engineering", "Software Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 25", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-05 directly implements GDPR Art 25 by producing the design-phase evidence — threat models, PET selection rationale, and attestation documents — that demonstrates data protection was implemented by design and by default at each stage of the AI development lifecycle.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "nist_pf", "requirement_id": "GV.PO-P2", "fit": "supporting", "direction": "control-supports-requirement", "rationale": "PC-05 implements NIST Privacy Framework GV.PO-P2 — processes to instill organizational privacy values within system, product, and service development and operations — as a structured, evidence-producing privacy-by-design gate.", "source_version": "1.0", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "voluntary-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "google_saif", "requirement_id": "Secure-by-Default ML Tooling", "rationale": "SAIF's Secure-by-Default ML Tooling control embeds protection into the frameworks and pipelines used to build models rather than bolting it on afterward; PC-05 certifies the equivalent by-design posture for privacy in AI system development.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF Secure-by-Default ML Tooling embeds security into pipelines, an analogous by-design posture but not the privacy-by-design evidence trail PC-05 certifies.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Standard v2 — Privacy & Security goals", "rationale": "The Microsoft Responsible AI Standard v2 Privacy & Security goals require AI systems to comply with Microsoft's privacy standard and security policies from design onward; PC-05 produces the equivalent documented privacy-by-design trail aligned with GDPR Art 25(1).", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Microsoft RAI's Privacy & Security goals require privacy from design onward, aligning with Art 25 but not producing PC-05's documented by-design evidence trail.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Well-Architected Machine Learning Lens — security and privacy best practices", "rationale": "The AWS Well-Architected Machine Learning Lens includes privacy design principles for AI/ML workloads as a structured review checklist. The ML Lens privacy assessment covers data minimization, encryption, access control, and purpose limitation for AI system architecture, providing a certifiable privacy-by-design review methodology for AWS-hosted AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "The AWS Well-Architected ML Lens gives a privacy-by-design review checklist covering minimization, encryption, and purpose, a methodology aligned with PC-05.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Privacy-by-design certification prevents the Art 25 non-compliance finding that results from retrofitting privacy controls onto deployed AI systems. By establishing design-phase checkpoints with documented evidence of privacy decisions, the organization produces the attestation artifacts that demonstrate to supervisory authorities that privacy was a deliberate design consideration from inception — not a post-deployment addition applied under enforcement pressure.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-05", "validation_objective": "For every AI system released to production, documented evidence demonstrates that privacy was considered at each development lifecycle phase: a privacy threat model exists from the design phase predating any personal data processing, privacy-enhancing technology selection decisions are recorded with implementation evidence, and a design-phase privacy review was signed off by the DPO or designated privacy engineer before deployment.", "evidence_required": [ "privacy_threat_model produced during the system design phase listing AI-specific threat categories (model memorization, inference attack, training data exposure, re-identification), mitigations adopted, and residual risks accepted, with a timestamp predating first personal data processing", "PET_selection_record documenting privacy-enhancing technologies considered, selection rationale, and implementation evidence (e.g., differential privacy epsilon budget, k-anonymity threshold, pseudonymisation key management scheme)", "privacy_by_design_checklist_completion_record mapping each SDLC phase to the privacy decisions made and the reviewer who approved them at each stage", "design_phase_privacy_review_sign_off from the DPO or designated privacy engineer with reviewer identity, date, and any conditions attached before deployment authorization" ], "machine_tests": [ "Query system_registry for all AI systems in production → assert each system_id has a linked privacy_threat_model with status=approved and produced_date < system_first_data_processing_date", "Query PBD_checklist_records for each system → assert all required lifecycle phases are marked complete with sign-off timestamps before production_cutover_date", "Query PET_implementation_records for systems with personal_data_access=true → assert at least one PET technique has a documented implementation_evidence_reference, not just a selection decision", "Verify design_phase_sign_off record exists for each AI system → assert reviewer_role in ['DPO', 'Privacy-Engineer'] and sign_off_date < deployment_date" ], "human_review": [ "Review privacy threat models for a sample of deployed AI systems to assess whether identified threats are specific to the system's actual data flows and model capabilities, rather than populated from a generic template", "Assess PET selection records to verify that implementation evidence confirms the selected technique was actually deployed — not just documented as selected and then not implemented", "Verify that DPO sign-off records reflect genuine review engagement evidenced by follow-up questions, conditions, or iteration — not rubber-stamp approval of document existence" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Completing the privacy-by-design checklist retrospectively after the system is already built and in production, treating it as a compliance documentation exercise rather than a design-phase gate", "Producing a generic privacy threat model template with only the system name substituted, rather than modeling the actual data flows, model architecture, and inference capabilities of the specific AI system", "Documenting differential privacy or pseudonymisation as the selected PET in the selection record without producing implementation evidence that the technique was actually deployed in the production system", "Granting DPO design-phase sign-off based on the existence of a document package without reviewing the threat model content or PET implementation evidence, approving form rather than substance", "Treating privacy-by-design as applicable only to new systems, not applying the same design-phase documentation requirement to material changes in data processing scope for existing AI systems" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-06", "layer": "PC", "plane": "lifecycle", "name": "AI Privacy Impact Assessment", "plain": "AI-specific privacy impact assessments address model memorization, inference attacks, training data exposure, and automated decision effects — complementing the standard DPIA (DG-05) with AI-specific risk dimensions.", "threat": { "tags": [ "ai-specific-risks-not-captured-in-dpia", "deployment-without-ai-pia", "fria-and-dpia-conflated" ], "desc": "Standard DPIA templates were designed for conventional data processing and do not address AI-specific risks such as membership inference, training data reconstruction, embedding inversion, or emergent behavior. AI systems deployed on standard DPIA alone have systematic blind spots." }, "standard": [ { "id": "gdpr", "section": "Art 35", "title": "Data protection impact assessment for high-risk processing" }, { "id": "eu_ai_act", "section": "Art 27", "title": "Fundamental rights impact assessment requirement" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "google_saif_2023", "title": "Google Secure AI Framework (SAIF)", "authority": "Google LLC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "1.0", "published_on": "2023-06-08", "retrieved_on": "2026-06-28", "canonical_url": "https://saif.google/secure-ai-framework", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "google_saif_2023", "relationship": "informative_reference", "rationale": "Establishes Google Secure AI Framework (SAIF) requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PC-06 AI Privacy Impact Assessment control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Extend the standard DPIA process with an AI-specific annex covering model memorization risk, inference attack surface, training data exposure analysis, and automated decision impact assessment, conducted by privacy engineers with ML expertise alongside the legal DPIA process.", "steps": [ "Conduct a standard DPIA per GDPR Art 35 requirements, then apply the AI-PIA annex covering: (a) training data privacy risks including memorization and reconstruction, (b) inference attack surface assessment, (c) embedding and output privacy risks, and (d) automated decision effect analysis for any model outputs affecting data subjects.", "Engage privacy engineers with ML expertise to assess membership inference risk, apply empirical memorization tests to models trained on personal data, and document differential privacy epsilon values and their effect on memorization risk reduction.", "Produce an integrated AI-DPIA report combining the standard DPIA with the AI-specific annex, obtain DPO sign-off, and update the report when the model is retrained on new data or the model architecture changes materially." ], "anti_patterns": [ "Using a standard DPIA template with an AI checkbox added — this does not address memorization, inference attack surface, or output privacy risks that are unique to AI systems and absent from conventional processing risk frameworks.", "Conflating the FRIA required by EU AI Act Art 27 with the DPIA — while related, they have different scopes and methodologies, and both must be produced separately for high-risk AI systems in scope for both regulations." ] }, "validation": { "design_check": [ "Verify an AI-PIA template exists that covers memorization risk, inference attack surface, training data exposure, and automated decision effects [ref:gdpr_2016_679]", "Confirm AI-PIAs are initiated for all AI systems processing personal data before deployment, per EDPB Opinion 28/2024 guidance [ref:edpb_opinion_28_2024]", "Check that a FRIA is produced separately from the AI-DPIA for high-risk AI systems in EU AI Act scope, with cross-references between the two documents [ref:eu_ai_act_2024]" ], "runtime_test": [ "Pull the AI-PIA for a deployed model and verify it includes a memorization risk assessment with empirical evidence such as canary token test results or differential privacy parameter documentation.", "Verify that the AI-PIA was updated within 30 days following the last model retraining event.", "Test that the FRIA for a high-risk AI system is distinct from and cross-referenced with the AI-DPIA." ], "evidence": [ "privacy:ai-pia-report — AI-specific privacy impact assessment for at least one deployed model with memorization risk analysis and inference attack surface documentation [unverified]", "privacy:memorization-test-results — Empirical memorization risk test results (canary tokens, membership inference test outputs) for models trained on personal data [unverified]", "privacy:fria-report — Fundamental rights impact assessment for high-risk AI systems in EU AI Act scope, cross-referenced with the AI-DPIA [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers lead the AI-PIA technical annex — designing and executing memorization tests, quantifying inference attack surface, and translating ML risk into compliance-relevant findings the DPO can act on.", "actions": [ "Design and execute canary token memorization tests and membership inference attack simulations for models trained on personal data, documenting results in the AI-PIA technical annex.", "Quantify differential privacy epsilon values where applied and assess whether they provide sufficient memorization protection relative to the data sensitivity level.", "Document embedding inversion risk for any model exposing embedding outputs through an API and recommend appropriate output perturbation or access controls." ], "failure_signals": [ "No empirical memorization risk testing has been conducted for any model trained on personal data.", "Differential privacy parameters are not documented in the AI-PIA, or their memorization protection effectiveness is not assessed.", "AI-PIAs are produced by privacy compliance staff without ML technical input, missing quantitative risk assessment for AI-specific risks." ] }, "dpo": { "summary": "The DPO must ensure AI-PIAs are triggered for all qualifying AI systems, review the necessity and proportionality conclusions, and make the Art 35 determination required for each high-risk processing activity.", "actions": [ "Establish an AI-PIA trigger in the product development process for any AI system processing personal data, with DPO notification at initiation.", "Review AI-PIA reports for high-risk AI systems and document the necessity and proportionality determination, including any consultation with the supervisory authority.", "Maintain the AI-PIA register as a living document, tracking AI system changes that trigger reassessment." ], "failure_signals": [ "AI systems have been deployed without AI-PIAs being initiated.", "The DPO has not reviewed AI-PIA reports for high-risk AI systems, leaving the necessity and proportionality determination undocumented.", "AI-PIAs have not been updated following model retraining or architectural changes." ] }, "data_governance": { "summary": "Data governance must ensure training data lineage is available to support AI-PIA analysis — specifically, identifying what personal data was in the training set and any data quality or provenance issues affecting privacy risk.", "actions": [ "Provide training data lineage documentation to the AI-PIA process, including data source, collection method, subject population, and any prior anonymisation applied.", "Flag training datasets with high-sensitivity personal data such as health, financial, or biometric data for mandatory AI-PIA initiation before training begins.", "Maintain training data retention records so that data subject deletion requests can be assessed against training set inclusion." ], "failure_signals": [ "Training data lineage is not available to inform the AI-PIA, preventing accurate memorization risk assessment.", "High-sensitivity training datasets are not flagged to trigger AI-PIA before training.", "Training data retention records do not support assessment of data subject deletion impact on model training." ] }, "grc_auditor": { "summary": "AI-PIAs are a regulatory requirement for high-risk AI processing under both GDPR Art 35 and EU AI Act; verify they are current, technically substantive, and cover AI-specific risks absent from standard DPIA templates.", "actions": [ "Review AI-PIA reports for substantive AI-specific risk content and verify they are not standard DPIA templates with minimal AI adaptation.", "Verify that AI-PIAs have been updated following model changes, retraining, or changes in the processing context.", "Confirm that FRIAs are produced separately for high-risk AI systems in EU AI Act scope and are cross-referenced with the AI-DPIA." ], "metrics": [ "Percentage of deployed AI systems processing personal data with a current AI-PIA (target: 100%)", "Age of AI-PIA relative to last model retraining event (target: updated within 30 days of retraining)" ], "failure_signals": [ "AI systems are deployed without AI-PIAs or with standard DPIA templates not adapted for AI-specific risks.", "AI-PIAs are not updated when models are retrained or materially modified.", "FRIA and AI-DPIA are conflated into a single document that satisfies neither requirement fully." ] }, "software_engineering": { "summary": "Software engineers support AI-PIA by providing model architecture documentation and training pipeline details, and by implementing recommended mitigations from the AI-PIA technical annex.", "actions": [ "Provide model cards and training pipeline documentation to the privacy engineer conducting the AI-PIA technical annex.", "Implement canary token injection in the training pipeline to support ongoing memorization risk monitoring beyond the initial AI-PIA.", "Implement output filtering, differential privacy, or embedding perturbation as directed by AI-PIA technical recommendations." ], "failure_signals": [ "Model cards and training pipeline documentation are not available to support AI-PIA technical analysis.", "No canary token or memorization testing mechanism exists in the training pipeline.", "AI-PIA technical recommendations for mitigations are not tracked in the engineering backlog." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations conduct standard DPIAs but lack the AI-specific annex, ML technical expertise in the assessment team, and empirical memorization testing required for a substantive AI-PIA." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "healthcare-ai", "automated-decisions" ], "implementers": [ "Privacy Engineering", "ML Engineering", "DPO Office" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 35", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-06 partially implements GDPR Art 35 by extending the standard DPIA with an AI-specific annex covering risks not addressed by standard templates, though the full Art 35 process also encompasses necessity and proportionality determination and supervisory authority consultation.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "eu_ai_act", "requirement_id": "Art 27", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-06 partially addresses EU AI Act Art 27 by producing a fundamental rights impact assessment as a distinct document for high-risk AI systems; Art 27(4) allows the FRIA to build on the GDPR Art 35 DPIA that PC-06 extends to AI-specific privacy risks.", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "google_saif", "requirement_id": "Core element — Contextualize AI system risks in surrounding business processes", "rationale": "SAIF's sixth core element requires assessing AI system risks in the context of the business processes they touch; PC-06's AI privacy impact assessment is the privacy-law instantiation of that contextual risk assessment.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "SAIF's contextualize-risks element is general risk assessment, not the AI-specific privacy impact assessment on memorization and inference PC-06 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS ISO/IEC 42001 certification — AI management system impact assessment practices", "rationale": "AWS's ISO/IEC 42001 accredited certification for services such as Amazon Bedrock attests to an AI management system that includes AI impact assessment processes; PC-06 uses such vendor artifacts as processor-side inputs to the enterprise AI privacy impact assessment.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS's ISO 42001 cert attests to AI-management impact-assessment practices, a processor-side input to the enterprise AI PIA, not the PIA itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Responsible AI Impact Assessment template and guide", "rationale": "Microsoft publishes a Responsible AI Impact Assessment template and guide used as a development gate under the Responsible AI Standard v2; PC-06 aligns that assessment practice with the GDPR Art 35 DPIA for AI systems.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Microsoft's RAI Impact Assessment template is an actual AI-impact assessment overlapping PC-06, though framed to RAI rather than Art 35 privacy risks.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic Responsible Scaling Policy — pre-deployment risk assessment discipline", "rationale": "Anthropic's Responsible Scaling Policy defines capability-threshold assessments gating model deployment; the RSP does not address privacy directly, but PC-06 applies the same gated pre-deployment assessment discipline to AI privacy impact assessment.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "adjacent", "fit_rationale": "Anthropic's RSP capability assessments share the gated pre-deployment discipline but are not privacy-specific, so they don't constitute an AI PIA.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "AI-specific privacy impact assessments prevent the systematic risk blind spots that standard DPIAs create when applied to AI systems without adaptation. By extending the DPIA process with AI-specific risk dimensions — memorization, inference attacks, and automated decision effects — the organization identifies and mitigates risks that would otherwise manifest as data breaches or enforcement findings post-deployment, when remediation is more costly and visibility to regulators is unavoidable.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-06", "validation_objective": "For every AI system that processes personal data, a completed AI-specific Privacy Impact Assessment exists, produced before deployment, explicitly addressing model memorization risk with empirical test results, inference attack exposure, training data leakage scenarios, and automated decision effects. The assessment must carry DPO review sign-off and documented risk acceptance by the business owner for any residual risk above threshold.", "evidence_required": [ "AI_PIA_report with system identifier, assessment date, scope of personal data processed, model architecture summary, assessor identity, and completion timestamp predating deployment_date", "memorization_risk_test_results showing membership inference attack test outcomes (e.g., canary token insertion and recovery rates, membership inference AUC) and mitigations applied with effectiveness evidence", "training_data_exposure_analysis documenting data lineage, anonymization or pseudonymisation techniques applied, and residual re-identification risk score with methodology", "automated_decision_effect_analysis listing each decision type the AI makes with documented human review trigger conditions, appeal mechanism reference, and explanation capability status", "DPO_review_record and business_owner_risk_acceptance for any residual risks above the acceptable threshold, with acceptance date and accepted_risk_items listed" ], "machine_tests": [ "Query AI_system_registry for all systems with personal_data_access=true → assert each system_id has a linked AI_PIA_record with status=approved and completed_date < deployment_date", "Run membership inference test suite against model inference endpoint → assert inference_success_rate < configured_threshold (e.g., <= 0.05 above random baseline for the model's task class)", "Query AI_PIA_records for systems with automated_decision_output=true → assert each has documented human_review_trigger_conditions and an appeal_mechanism_reference", "Verify DPO_review_record exists for each AI_PIA → assert reviewer_role == 'DPO' and review_date < deployment_date" ], "human_review": [ "Review a sample of AI PIAs to assess whether the memorization risk analysis reflects understanding of the specific model architecture — verify the assessor identified realistic exposure vectors rather than applying a generic risk level", "Assess training data exposure analysis for each reviewed system to verify it is grounded in actual data lineage documentation rather than high-level assertions about anonymization that are not supported by applied technique evidence", "Evaluate automated decision effect analyses to verify that human review triggers, appeal mechanisms, and explanation capabilities are specific and traceable to implemented system features, not policy statements" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Reusing a standard DPIA template for AI systems without adding AI-specific sections on model memorization, inference attacks, and training data exposure — producing a privacy impact assessment blind to the AI-specific risk surface", "Claiming negligible memorization risk without running empirical membership inference tests or citing specific technical model properties (e.g., training data size, deduplication, differential privacy parameters) that substantiate the claim", "Asserting that training data is 'anonymized' as a binary determination without assessing residual re-identification risk using realistic adversarial re-identification models applied to the actual dataset", "Describing automated decision effects in generic terms without specifying decision frequency, affected population size, or a concrete appeal pathway — making the safeguard documentation unverifiable", "Routing AI PIAs through a standard DPIA approval workflow without a DPO reviewer who has AI-specific assessment expertise, causing AI-specific risk sections to pass review without substantive scrutiny" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-07", "layer": "PC", "plane": "lifecycle", "name": "Privacy Governance Reporting", "plain": "Periodic privacy governance reports are produced for the DPO, privacy board, senior leadership, and (where required) supervisory authorities, covering privacy program status, metrics, incidents, and recommendations.", "threat": { "tags": [ "leadership-unaware-of-privacy-risk", "dpo-isolated-from-business-decisions", "regulatory-reporting-gaps" ], "desc": "Art 38 requires that the DPO have direct access to senior management. DPOs who cannot produce structured governance reports to escalate privacy risks are institutionally isolated, and their recommendations will lack the management visibility required to drive remediation." }, "standard": [ { "id": "gdpr", "section": "Art 37(6)/Art 38", "title": "DPO designation and position obligations" }, { "id": "iso_27701", "section": "5.7.3", "title": "Management review" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-07 Privacy Governance Reporting control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PC-07 Privacy Governance Reporting control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-07 Privacy Governance Reporting control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-07 Privacy Governance Reporting control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Produce quarterly privacy governance reports for senior leadership and an annual report for the privacy board, covering program effectiveness metrics, incidents, regulatory developments, open risk items, and DPO recommendations requiring management decision, with formal management review meeting records.", "steps": [ "Define a governance report template covering: privacy program effectiveness metrics (from PC-04), incidents and near-misses in the period, regulatory developments affecting the organization, open DPIAs and risk items, and DPO recommendations requiring management decision.", "Produce the report quarterly for senior leadership with management-level summaries and escalations, and annually as a comprehensive privacy board report covering full-year program performance and strategic recommendations.", "Establish a formal management review meeting cadence where the DPO presents the governance report, management acknowledges risks and makes decisions, and outcomes are recorded in the ISO 27701 clause 9.3 management review record." ], "anti_patterns": [ "Producing governance reports for internal DPO reference only without presenting them to senior leadership — this violates the Art 38(3) direct access requirement and eliminates the governance escalation function.", "Governance reports that are information-only dashboards without specific decision requests — management review records must evidence that management considered risks and made decisions, not merely received information." ] }, "validation": { "design_check": [ "Verify a governance report template exists with sections for metrics, incidents, regulatory developments, risks, and DPO recommendations [ref:gdpr_2016_679]", "Confirm quarterly reporting cadence is documented and the last report was presented to senior leadership within the past 90 days [ref:iso_27701_2019]", "Check that management review meeting records document management's acknowledgment of reported risks and specific decisions made [ref:uk_duaa_2025]" ], "runtime_test": [ "Pull the last four quarterly governance reports and verify they cover all required content areas with specific data rather than generic statements.", "Verify that management review meeting minutes exist for each governance report presentation, documenting decisions and action items with owners.", "Test that a significant incident from the past year is reflected in the governance reporting chain with evidence of management notification and decision." ], "evidence": [ "privacy:governance-reports — Last four quarterly privacy governance reports presented to senior leadership [unverified]", "privacy:management-review-records — ISO 27701 clause 9.3 management review records documenting decisions and action items from governance report presentations [unverified]", "privacy:dpo-recommendations-log — Record of DPO recommendations to management and documented management response in the past 12 months [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers contribute technical sections of governance reports — providing metrics data, technical incident analysis, and PET effectiveness assessments — and must ensure this data is available in management-readable form.", "actions": [ "Produce technical annexes for governance reports covering privacy-by-design adoption rates, PET implementation status, and technical control effectiveness metrics.", "Provide incident technical analysis for the governance report incident section, translating technical findings into business-impact terms for senior leadership.", "Track technical recommendations from governance reports through the engineering backlog with priority and status visible to the DPO." ], "failure_signals": [ "Governance reports lack technical privacy control effectiveness data because privacy engineers do not contribute to the report production cycle.", "Incident technical analysis is not translated into business-impact terms, limiting senior leadership's ability to assess significance.", "Technical recommendations from governance reports are not tracked in the engineering backlog." ] }, "dpo": { "summary": "The DPO authors and presents governance reports and is accountable for ensuring management has the information needed to make privacy risk decisions — this is the primary mechanism for fulfilling Art 38(3) direct access.", "actions": [ "Author the quarterly governance report and present it in person to the senior leadership team or executive committee with a dedicated agenda slot.", "Include specific management decision requests in each governance report to drive accountability rather than passive information receipt.", "Document the outcome of each management review in a decision register referenced in subsequent reports to track follow-through." ], "failure_signals": [ "The DPO sends governance reports by email without a dedicated presentation slot with senior leadership, failing the Art 38(3) direct access requirement.", "Governance reports do not include specific decision requests, resulting in no management decisions being made or recorded.", "No decision register exists, making it impossible to track management's response to DPO recommendations over time." ] }, "data_governance": { "summary": "Data governance metrics and incident data are primary inputs to governance reports; data governance teams must ensure these inputs are available, accurate, and timed to the reporting cadence.", "actions": [ "Contribute data quality, retention compliance, and processing record completeness metrics to the governance report on the quarterly cadence.", "Report data governance incidents — unauthorized data access, retention failures, classification errors — in the governance incident section.", "Track data governance remediation commitments from governance reports through to completion and report closure status in subsequent reports." ], "failure_signals": [ "Data governance metrics are not available in time for the governance report production cycle.", "Data governance incidents are not reported in governance reports, creating an incomplete incident picture for senior management.", "Data governance remediation commitments from previous reports are not tracked for closure." ] }, "grc_auditor": { "summary": "Governance reports and management review records are the accountability chain that evidences Art 38(3) direct access and ISO 27701 clause 9.3 management review; verify they are produced, presented, and followed through.", "actions": [ "Verify the existence and content quality of governance reports for the past 12 months, confirming all required content areas are covered with specific data.", "Review management review meeting records to confirm they document management decisions rather than only information receipt.", "Trace DPO recommendations from governance reports to management decisions and follow-up evidence." ], "metrics": [ "Number of governance reports presented to senior leadership in the past 12 months (target: at least 4)", "Percentage of DPO recommendations with documented management response (target: 100%)" ], "failure_signals": [ "Fewer than four governance reports have been produced in the past 12 months.", "Management review records document only information receipt without any decisions or action items.", "DPO recommendations have no documented management response." ] }, "software_engineering": { "summary": "Software engineers are stakeholders of governance reporting outputs — they receive technical action items from governance decisions and must ensure engineering work driven by governance reports is tracked and completed.", "actions": [ "Review governance report sections relevant to engineering and capture technical action items in the engineering backlog with priority aligned to governance decisions.", "Provide completion evidence for engineering action items from previous governance reports to the DPO before the next report is produced.", "Escalate to the DPO any engineering constraint that prevents delivery of a governance-committed technical control on the committed schedule." ], "failure_signals": [ "Engineering action items from governance reports are not captured in the engineering backlog.", "Engineering teams are not informed of governance report outcomes relevant to their systems.", "Technical controls committed in governance decisions are delayed without DPO notification." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Many organizations have a DPO who produces ad-hoc reports on request but lack the structured quarterly cadence with formal management review records required for defined maturity." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general" ], "implementers": [ "DPO Office", "Legal/Compliance", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 38", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-07 directly implements GDPR Art 38(3) by establishing a structured governance reporting process that provides the DPO with direct access to senior management, evidenced by formal governance report presentations and management review records.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "5.7.3", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-07 directly implements ISO/IEC 27701:2019 clause 5.7.3 (extending ISO/IEC 27001 clause 9.3), which requires management review of the privacy information management system at planned intervals to ensure continuing suitability, adequacy, and effectiveness.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "aws_privacy", "requirement_id": "AWS Artifact — on-demand compliance reports", "rationale": "AWS Artifact provides downloadable compliance reports, audit findings, and certification documentation supporting privacy governance reporting to senior leadership and boards. AWS Audit Manager generates customizable privacy governance reports with quantified compliance metrics, improvement trends, and outstanding remediation actions for periodic privacy governance review cycles.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "AWS Artifact reports and Audit Manager metrics supply content for governance reporting but not the cadence, audience, and receipt evidence PC-07 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Microsoft Privacy Report — periodic privacy governance disclosure", "rationale": "Microsoft publishes an annual Privacy Report documenting privacy governance activities, compliance certifications, data subject request statistics, and privacy program improvements. Microsoft Purview provides real-time privacy governance dashboards for internal reporting, with exportable compliance reports suitable for board-level privacy governance reporting and regulatory submissions.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "partial", "fit_rationale": "Purview's governance dashboards and exportable reports support producing board-level privacy reports, providing the reporting mechanism aligned with PC-07.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "thesis_type": "preventive", "matrix_thesis": "Structured privacy governance reporting prevents the institutional isolation of the DPO function that results when privacy risks are not visible to senior leadership. By establishing a formal cadence of governance reports with management review records, the organization creates the accountability chain that satisfies Art 38(3) direct access requirements and drives management action on privacy risks before they become enforcement findings or data protection failures.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-07", "validation_objective": "Privacy governance reports are produced and delivered to the DPO, the privacy board or equivalent senior governance body, and senior leadership on a documented cadence (at minimum quarterly), covering privacy program health metrics, open incidents, DSAR status, DPIA pipeline, and forward-looking risk items. Evidence of receipt, presentation, and governance body discussion is retained for each reporting cycle.", "evidence_required": [ "privacy_governance_reports for the past four reporting periods, each with distribution list, delivery date, DPO sign-off, and a structured coverage checklist confirming metrics, incidents, DSAR status, DPIA pipeline, and risk items were included", "governance_body_meeting_minutes for each reporting period referencing privacy agenda items, material discussed, and decisions or actions taken on risk items raised", "privacy_metrics_snapshot for each reporting period showing the state of key program indicators at the report date, retained as an auditable baseline for trend analysis", "report_delivery_evidence confirming senior leadership recipients received and acknowledged each governance report (e.g., meeting attendance records, signed receipt, or tracked email delivery confirmation)" ], "machine_tests": [ "Query governance_report_schedule → assert a report record with status=delivered exists for each required period in the past 12 months, with no missed periods", "Query report_distribution_log for each governance report → assert DPO and at least one C-suite or board-level recipient appear on each report's distribution list", "Query governance_body_meeting_minutes repository → assert a privacy agenda item appears in board or executive committee minutes at least once per quarter over the past 12 months", "Query privacy_metrics_archive for each reporting period → assert a metrics snapshot with key indicators was captured and timestamped before each report's delivery date" ], "human_review": [ "Review a sample of governance reports for substantive risk content — verify that open incidents, DPIA pipeline delays, and threshold breaches are described with specificity, not sanitized into generic 'under control' status summaries", "Assess governance body meeting minutes for evidence of meaningful engagement with privacy risk items — distinguish between minutes reflecting genuine board discussion and minutes treating privacy as a standing rubber-stamp agenda item", "Evaluate whether the reporting cadence and escalation path are appropriate for the organization's current privacy risk profile and regulatory footprint, and whether the report format enables senior leadership to make informed decisions" ], "blocking_effect": "advisory", "normative_status": "binding-law", "anti_patterns": [ "Producing privacy governance reports that surface only favorable metrics while omitting open incidents under investigation, overdue DSARs, DPIA pipeline delays, or corrective actions from prior reporting periods", "Distributing reports to a distribution list without confirming receipt or board discussion, creating a paper trail of report production without evidence of governance engagement", "Treating privacy governance reporting as a DPO-only document distribution activity rather than a structured input to senior leadership and board risk governance", "Reporting privacy metrics without defined targets or historical baselines, making it structurally impossible for governance bodies to assess whether performance is acceptable, improving, or deteriorating" ], "update_status": "current", "layer_code": "PC" }, { "id": "PC-08", "layer": "PC", "plane": "lifecycle", "name": "PrivacyAttestation [BASELINE]", "plain": "The signed PrivacyAttestation artifact is produced, attesting to lawful basis, data subject rights coverage, and technical data protection controls, and is consumed by downstream compliance and agentic domain attestations.", "threat": { "tags": [ "attestation-not-produced", "downstream-consumers-cannot-verify-privacy-posture", "agentic-systems-without-privacy-attestation" ], "desc": "The PrivacyAttestation is the machine-readable privacy evidence artifact consumed by downstream compliance dossiers and agentic system authorization flows. Absence of a current attestation means agentic systems cannot verify privacy posture before acting on personal data." }, "standard": [ { "id": "gdpr", "section": "Art 5(2)", "title": "Accountability principle — demonstrating GDPR compliance" }, { "id": "iso_27701", "section": "5.8.2", "title": "Continual improvement" }, { "id": "eu_ai_act", "section": "Art 47", "title": "EU Declaration of Conformity documentation obligations" } ], "sources": [ { "id": "gdpr_2016_679", "title": "Regulation (EU) 2016/679 — General Data Protection Regulation", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2016/679", "published_on": "2016-04-27", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679", "license": "open-eu-law", "status": "current", "flagship": true, "source_id": "gdpr", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2016/679 — General Data Protection Regulation requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-01" }, { "id": "iso_27701_2019", "title": "ISO/IEC 27701:2019 — Privacy Information Management System", "authority": "ISO/IEC JTC 1/SC 27", "source_type": "certification-standard", "normative_force": "certification-standard", "version": "2019", "published_on": "2019-08-06", "retrieved_on": "2026-06-28", "canonical_url": "https://www.iso.org/standard/71670.html", "license": "proprietary-paid", "status": "current", "flagship": false, "source_id": "iso_27701", "relationship": "normative_requirement", "rationale": "Establishes ISO/IEC 27701:2019 — Privacy Information Management System requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-01" }, { "id": "eu_ai_act_2024", "title": "Regulation (EU) 2024/1689 — EU Artificial Intelligence Act", "authority": "European Parliament and Council of the EU", "source_type": "binding-law", "normative_force": "binding-law", "version": "2024/1689", "published_on": "2024-07-12", "retrieved_on": "2026-06-28", "canonical_url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689", "license": "open-eu-law", "status": "current", "flagship": false, "source_id": "eu_ai_act", "relationship": "normative_requirement", "rationale": "Establishes Regulation (EU) 2024/1689 — EU Artificial Intelligence Act requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-01" }, { "id": "microsoft_rai_standard_v2_2022", "title": "Microsoft Responsible AI Standard v2", "authority": "Microsoft Corporation", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2", "published_on": "2022-06-21", "retrieved_on": "2026-06-28", "canonical_url": "https://www.microsoft.com/en-us/ai/responsible-ai", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "microsoft_rai_standard_v2_2022", "relationship": "informative_reference", "rationale": "Establishes Microsoft Responsible AI Standard v2 requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-01" }, { "id": "openai_privacy_dpa_2024", "title": "OpenAI Privacy Policy & Data Processing Addendum", "authority": "OpenAI, L.L.C.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-03-01", "retrieved_on": "2026-06-28", "canonical_url": "https://openai.com/policies/privacy-policy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "openai_privacy_dpa_2024", "relationship": "informative_reference", "rationale": "Establishes OpenAI Privacy Policy & Data Processing Addendum requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-01" }, { "id": "aws_privacy_data_governance_2024", "title": "AWS Data Privacy (Data Privacy Center)", "authority": "Amazon Web Services, Inc.", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-01-01", "retrieved_on": "2026-06-28", "canonical_url": "https://aws.amazon.com/compliance/data-privacy/", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "aws_privacy_data_governance_2024", "relationship": "informative_reference", "rationale": "Establishes AWS Data Privacy (Data Privacy Center) requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-02" }, { "id": "anthropic_privacy_policy_2024", "title": "Anthropic Privacy Policy & Zero Data Retention Addendum", "authority": "Anthropic, PBC", "source_type": "vendor-guidance", "normative_force": "best-practice", "version": "2024", "published_on": "2024-09-01", "retrieved_on": "2026-06-28", "canonical_url": "https://www.anthropic.com/legal/privacy", "license": "proprietary-free", "status": "current", "flagship": false, "source_id": "anthropic_privacy_policy_2024", "relationship": "informative_reference", "rationale": "Establishes Anthropic Privacy Policy & Zero Data Retention Addendum requirements informing the apeiris://privacy/controls/PC-08 PrivacyAttestation [BASELINE] control.", "reviewed_on": "2026-07-02" } ], "implementation": { "pattern": "Produce a signed PrivacyAttestation artifact on a defined cadence — at minimum quarterly — by aggregating evidence from all PC-layer controls, signing with an organizational Ed25519 key, and registering the attestation in the evidence registry for consumption by downstream domains.", "steps": [ "Aggregate evidence from PC-01 through PC-07 controls — jurisdiction matrix status, certification currency, compliance package completeness, effectiveness metrics, privacy-by-design attestations, AI-PIA status, and governance report recency — into a structured attestation payload using the canonical PrivacyAttestation schema.", "Sign the attestation payload using the organization's Ed25519 attestation key and include SHA-256 integrity hash, valid_from/valid_until dates set to the next scheduled production cycle plus a buffer, and evidence completeness status reflecting the actual coverage of contributing controls.", "Register the signed PrivacyAttestation in the evidence registry under the canonical URI apeiris://privacy/controls/PC-08, publish the public signing key to the trust portal, and notify downstream consumers in the compliance domain and agentic domain that a new attestation is available." ], "anti_patterns": [ "Producing the PrivacyAttestation as a narrative PDF document rather than a structured, machine-readable, signed artifact — downstream agentic systems cannot parse PDF documents for authorization decisions.", "Signing the attestation with a software key lacking a published verification path — downstream consumers cannot verify attestation authenticity without a trust anchor for the signing key." ] }, "validation": { "design_check": [ "Verify a PrivacyAttestation schema is defined that includes all required fields: lawful_basis, data_subject_rights_coverage, technical_controls, valid_until, integrity.hash, integrity.signature [ref:gdpr_2016_679]", "Confirm the attestation production pipeline is automated and produces a new attestation within the defined quarterly cadence without manual intervention [ref:iso_27701_2019]", "Check that the signing key has a published verification path on the trust portal with expiry and revocation status visible [ref:eu_ai_act_2024]" ], "runtime_test": [ "Pull the current PrivacyAttestation from the evidence registry and verify the Ed25519 signature validates against the published public key.", "Verify that the attestation valid_until date is in the future and the evidence completeness status accurately reflects the current maturity of PC-layer controls.", "Test downstream consumption by verifying that the compliance domain (AU-08) and agentic domain (AG-08) can retrieve and cryptographically verify the current attestation." ], "evidence": [ "privacy:attestation-artifact — Current signed PrivacyAttestation artifact with valid signature, current valid_until, and evidence completeness status [unverified]", "privacy:signing-key-registry — Trust portal entry for the attestation signing public key with expiry and revocation status [unverified]", "privacy:attestation-consumption-log — Log entries from downstream domain consumers (AU-08, AG-08) successfully retrieving and verifying the PrivacyAttestation [unverified]" ] }, "lenses": { "privacy_engineer": { "summary": "Privacy engineers build and maintain the PrivacyAttestation production pipeline — aggregating evidence from PC-layer controls, formatting the attestation payload, and integrating with signing infrastructure.", "actions": [ "Build the attestation payload aggregation pipeline that pulls evidence status from each PC-layer control and formats it into the canonical PrivacyAttestation schema with all required fields.", "Integrate the pipeline with the organization's key management infrastructure to sign each attestation payload with the current Ed25519 key via an HSM or equivalent.", "Implement attestation validity monitoring that alerts when the current attestation valid_until is within 7 days of expiry and no renewal pipeline run is in progress." ], "failure_signals": [ "The PrivacyAttestation is produced manually rather than through an automated pipeline, creating reliability and cadence risks.", "The attestation payload does not include evidence from all PC-layer controls, producing an incomplete attestation.", "No validity monitoring exists, allowing attestations to expire without downstream consumers being notified." ] }, "dpo": { "summary": "The DPO authorizes the PrivacyAttestation and is accountable for the accuracy of the attestation claims — specifically the lawful basis coverage and data subject rights completeness assertions.", "actions": [ "Review and authorize each PrivacyAttestation before signing, verifying that lawful basis, data subject rights coverage, and technical control assertions are accurate relative to the current program state.", "Ensure the attestation's evidence completeness status honestly reflects the maturity of the underlying PC-layer controls rather than projecting target state.", "Maintain a PrivacyAttestation issuance log with DPO authorization records for each attestation produced." ], "failure_signals": [ "PrivacyAttestations are signed without DPO review, creating accountability exposure for inaccurate claims.", "The attestation claims full control coverage when underlying PC-layer controls are at initial maturity — the evidence completeness status should reflect actual maturity.", "No issuance log exists, making it impossible to evidence DPO authorization during regulatory examination." ] }, "data_governance": { "summary": "Data governance is a primary contributor to PrivacyAttestation evidence — specifically the processing records, data classification status, and retention compliance that underpin technical data protection control claims.", "actions": [ "Provide current processing record status, data classification completeness, and retention compliance rates as structured evidence inputs to the attestation pipeline.", "Verify that data governance evidence inputs are updated before each attestation production cycle rather than carrying forward stale data.", "Review the attestation's technical_controls section to confirm it accurately reflects the current data governance control state." ], "failure_signals": [ "Data governance evidence inputs to the attestation are stale — not updated since the previous attestation cycle.", "Processing record completeness in the attestation does not match the current data governance state.", "Data governance does not have visibility into what evidence it is contributing to the attestation." ] }, "grc_auditor": { "summary": "The PrivacyAttestation is the machine-readable accountability artifact; verify it is current, accurately reflects control status, has a valid signature, and is being consumed by downstream domains.", "actions": [ "Verify the PrivacyAttestation is current with valid_until in the future and the Ed25519 signature validates against the published public key.", "Review the attestation's evidence completeness status against the actual maturity of underlying PC-layer controls — flag over-optimistic completeness claims.", "Confirm that downstream consumers (compliance domain AU-08, agentic domain AG-08) have current attestation consumption logs evidencing active use." ], "metrics": [ "Days since last PrivacyAttestation production (target: <90 days)", "Attestation evidence completeness coverage of PC-layer controls (target: >85%)" ], "failure_signals": [ "The PrivacyAttestation has expired with valid_until in the past and no renewal in progress.", "The attestation's evidence completeness status claims higher coverage than the actual control maturity supports.", "Downstream domain consumers have no attestation consumption logs, suggesting the attestation is not being verified." ] }, "software_engineering": { "summary": "Software engineers build the attestation production pipeline, signing infrastructure integration, and downstream consumption APIs that make the PrivacyAttestation operationally useful for agentic authorization flows.", "actions": [ "Implement the PrivacyAttestation schema as a versioned, machine-readable JSON document with all required fields and a canonical URI registered in the evidence registry.", "Integrate the attestation production pipeline with the organization's HSM or key management service for Ed25519 signing rather than software-key signing.", "Build downstream consumption client libraries for use by the compliance domain and agentic domain to retrieve, verify, and act on the current PrivacyAttestation consistently." ], "failure_signals": [ "The attestation schema is not versioned, creating forward-compatibility risks when the schema evolves.", "Signing is implemented with a software key rather than HSM, reducing attestation integrity assurance.", "Downstream domains implement custom attestation retrieval logic rather than using a shared client library, creating maintenance and consistency risks." ] } }, "maturity": { "current": "initial", "target": "defined", "notes": "Most organizations do not produce machine-readable signed privacy attestations; achieving defined maturity requires a complete attestation schema, automated production pipeline, and at least one downstream consumer integration." }, "capability_risk": { "capability_level": "none", "access_mode": "data-processing", "autonomy": "supervised", "external_reach": false, "irreversibility": "moderate", "data_sensitivity": "personal", "deployment_scale": "enterprise", "affected_party_impact": "high" }, "tiers": [ "eu-gdpr", "uk-duaa", "us-state-privacy", "healthcare-ai", "enterprise-general", "automated-decisions" ], "implementers": [ "DPO Office", "Privacy Engineering", "GRC" ], "frameworks": [ { "framework": "gdpr", "requirement_id": "Art 5(2)", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-08 directly implements the GDPR Art 5(2) accountability principle by producing a signed, machine-readable PrivacyAttestation that provides verifiable evidence of compliance with Art 5(1) data protection principles across the PC-layer control set.", "source_version": "2016/679", "reviewed_on": "2026-06-28", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "iso_27701", "requirement_id": "5.8.2", "fit": "direct", "direction": "control-supports-requirement", "rationale": "PC-08 aligns with ISO/IEC 27701:2019 clause 5.8.2 (extending ISO/IEC 27001 clause 10.2) by producing an attestation artifact that evidences continual improvement of the privacy information management system, suitable as certification audit evidence.", "source_version": "2019", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "high", "legal_status": "voluntary", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "certification-standard", "basis": "anchored", "relation": "equivalent_to" }, { "framework": "eu_ai_act", "requirement_id": "Art 47", "fit": "partial", "direction": "control-supports-requirement", "rationale": "PC-08 partially addresses EU AI Act Art 47 by producing a declaration-of-conformity-equivalent artifact for privacy posture; a full Art 47 EU declaration of conformity must address all applicable AI Act obligations, not privacy controls alone.", "source_version": "2024/1689", "reviewed_on": "2026-07-02", "source_status": "authoritative", "mapping_confidence": "medium", "legal_status": "binding-law", "control_readiness": "approved", "implementation_maturity": "developing", "assurance_result": "not-assessed", "evidence_status": "no-evidence", "normative_force": "binding-law", "basis": "anchored", "relation": "satisfies" }, { "framework": "aws_privacy", "requirement_id": "AWS ISO/IEC 42001 certification and SOC 2 — vendor assurance artifacts", "rationale": "AWS's ISO 42001 accredited certification for AI services provides independent third-party assurance of AWS's AI privacy governance. Enterprise customers can incorporate AWS's ISO 42001 certification and SOC 2 Type II reports as vendor-side attestation artifacts in their PrivacyAttestation evidence chain, demonstrating that infrastructure-layer privacy controls have been independently validated.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "AWS's ISO 42001 and SOC 2 reports are vendor assurance artifacts incorporated into the attestation evidence chain, not the signed PrivacyAttestation itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "anthropic_privacy", "requirement_id": "Anthropic SOC 2 Type II and GDPR DPA — vendor assurance artifacts", "rationale": "Anthropic's SOC 2 Type II report, GDPR DPA, and HIPAA BAA constitute the vendor-side privacy attestation artifacts for Anthropic API usage. Enterprise customers building a PrivacyAttestation for AI systems using the Claude API should incorporate Anthropic's current SOC 2 report and DPA as evidence of processor-layer privacy control assurance in the attestation artifact.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Anthropic's SOC 2 and DPA are processor-layer assurance artifacts feeding the attestation evidence chain, not the signed PrivacyAttestation itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "openai_privacy", "requirement_id": "OpenAI certifications — SOC 2, ISO 27001, ISO 42001", "rationale": "OpenAI's SOC 2 Type II, ISO 27001, and ISO 42001 certifications provide vendor assurance artifacts for API-based AI systems. Enterprise customers incorporating OpenAI APIs in AI systems subject to PrivacyAttestation should include OpenAI's current certification reports as processor-side evidence, covering security, information management, and AI governance controls respectively.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "OpenAI's SOC 2/ISO 27001/ISO 42001 certs are processor-side evidence for the attestation chain, not the signed PrivacyAttestation PC-08 requires.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "informs" }, { "framework": "microsoft_rai", "requirement_id": "Azure AI certifications — ISO 27001, SOC 2, ISO 42001", "rationale": "Azure AI services' ISO 27001, SOC 2 Type II, and ISO 42001 certifications, combined with Microsoft Purview compliance posture data and EU Data Boundary commitments, provide comprehensive enterprise-grade attestation artifacts for organizations building PrivacyAttestation for Azure AI-based systems, covering infrastructure security, information management, and AI governance assurance.", "normative_force": "best-practice", "reviewed_on": "2026-07-02", "fit": "supporting", "fit_rationale": "Azure's ISO 27001/SOC 2/ISO 42001 certs and Purview posture are vendor assurance artifacts for the attestation chain, not the signed PrivacyAttestation itself.", "fit_assessed_on": "2026-07-03", "basis": "anchored", "relation": "equivalent_to" } ], "readiness": "approved", "cross_domain": { "references": [ { "uri": "apeiris://data/controls/DV-08", "relationship": "related", "note": "PC-08 PrivacyAttestation attests to lawful basis and data subject rights; complementary to the Data domain DV-08 DataGovernanceAttestation which attests to data classification and integrity. Both must be current for a fully-evidenced compliance dossier." }, { "uri": "apeiris://compliance/controls/AU-08", "relationship": "consumed-by", "note": "PC-08 PrivacyAttestation is consumed by the Compliance domain AU-08 attestation as evidence of privacy posture in compliance dossiers." }, { "uri": "apeiris://agentic/controls/AG-08", "relationship": "consumed-by", "note": "PC-08 PrivacyAttestation is consumed by the Agentic domain AG-08 BehavioralAttestation to verify privacy posture before agentic systems act on personal data." } ], "feeds": [ "apeiris://ethics/controls/EG-08", "apeiris://agentic/controls/AG-08", "apeiris://compliance/controls/AU-08" ] }, "thesis_type": "preventive", "matrix_thesis": "The PrivacyAttestation is the machine-readable trust anchor for the privacy domain — it converts the evidence produced by PC-01 through PC-07 controls into a signed, verifiable artifact that downstream systems can consume to authorize actions on personal data. Without a current PrivacyAttestation, agentic systems have no mechanized way to verify that privacy posture is sufficient before acting, and compliance dossiers lack the privacy evidence anchor required for a complete regulatory picture.", "meta": { "authored_on": "2026-06-28", "schema_version": "1.0.0" }, "canonical_id": "apeiris://privacy/controls/PC-08", "validation_objective": "A signed PrivacyAttestation artifact exists, is current (valid_until in the future), carries a verified Ed25519 signature from the registered producer_verifier identity, and a matching sha256 integrity hash. The attestation asserts a 'pass' verdict covering lawful basis documentation, data subject rights operational readiness, and technical data protection controls, and references the canonical_ids of the Apeiris privacy controls contributing to the verdict.", "evidence_required": [ "PrivacyAttestation artifact containing all required evidence ontology fields: 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 (sha256), integrity.signature (Ed25519)", "lawful_basis_registry_extract referenced in the attestation confirming documented lawful basis for all in-scope processing activities contributing to the verdict", "data_subject_rights_readiness_record confirming all six GDPR rights (access, rectification, erasure, restriction, portability, objection) are operationally active and tested", "technical_data_protection_control_evidence_summary listing encryption-at-rest, encryption-in-transit, pseudonymisation, and access control implementations with canonical_id references to contributing privacy controls", "attestation_signing_key_record confirming the Ed25519 producer_verifier key is current, not expired, not revoked, and registered in the trust portal key registry" ], "machine_tests": [ "Fetch PrivacyAttestation artifact from attestation endpoint → assert verdict == 'pass' and valid_until > now()", "Verify Ed25519 signature on attestation body using the registered producer_verifier public key from the trust portal → assert cryptographic_signature_valid == true", "Recompute sha256 hash of canonical attestation fields serialization → assert computed_hash == integrity.hash in the artifact", "Query downstream Compliance (AU-08) and Agentic (AG-08) domain attestation pipelines → assert each references a PrivacyAttestation with valid_until > now() before issuing its own attestation" ], "human_review": [ "Review the set of Apeiris privacy control canonical_ids cited in the attestation to verify the contributing control set is complete and that no high-risk controls (e.g., DC-01, DS-01, DP-01) are excluded from the verdict basis", "Assess the confidence_basis and residual_risk fields for specificity — verify they reference actual assessment evidence artifacts rather than contain placeholder or boilerplate text", "Verify the producer_verifier identity is authorized to issue PrivacyAttestations and that the signing key in the attestation matches the registered key in the trust portal key registry, confirming signing accountability" ], "blocking_effect": "blocks-deployment", "normative_status": "binding-law", "anti_patterns": [ "Issuing a PrivacyAttestation with verdict=pass without completing the contributing control assessments referenced by the canonical_ids, generating a signed artifact that overstates privacy assurance", "Allowing the attestation to expire (valid_until < now()) without triggering re-attestation, causing downstream Compliance and Agentic domain attestations to reference stale privacy evidence without detection", "Signing the attestation with a shared service key or an unregistered key rather than the designated producer_verifier Ed25519 key, breaking the chain of signing accountability", "Omitting the data_subject_rights_readiness_record from the contributing evidence set and attesting to rights coverage based solely on policy documentation rather than operational capability verification", "Including canonical_id references to contributing privacy controls without linking each reference to a specific evidence artifact, making the attestation unverifiable at the individual control level" ], "update_status": "current", "layer_code": "PC" } ], "profiles": [ { "profile_id": "eu-gdpr", "name": "EU GDPR Scope", "description": "Processing personal data of EU/EEA data subjects under GDPR. Full GDPR compliance obligations apply.", "required_controls": [ "DC-01", "DC-02", "DC-03", "DC-04", "DC-05", "DC-06", "DC-07", "DC-08", "DG-01", "DG-02", "DG-03", "DG-04", "DG-05", "DG-06", "DG-07", "DG-08", "DS-01", "DS-02", "DS-03", "DS-04", "DS-05", "DS-06", "DS-07", "DS-08", "DP-01", "DP-03", "DP-05", "PM-01", "PM-02", "PM-03", "PM-04", "PM-05", "PM-06", "PM-07", "PM-08", "PC-01", "PC-02", "PC-03", "PC-04", "PC-05", "PC-06", "PC-07", "PC-08" ], "recommended_controls": [ "DP-02", "DP-04", "DP-06", "DP-07", "DP-08" ] }, { "profile_id": "uk-duaa", "name": "UK DUAA 2025 Scope", "description": "Processing personal data of UK data subjects under the Data (Use and Access) Act 2025.", "required_controls": [ "DC-01", "DC-02", "DC-03", "DC-05", "DC-06", "DC-07", "DG-01", "DG-02", "DG-05", "DG-06", "DG-07", "DS-01", "DS-02", "DS-03", "DS-04", "DS-05", "DS-07", "DS-08", "DP-01", "DP-05", "PM-01", "PM-04", "PM-06", "PC-01", "PC-02", "PC-03", "PC-08" ], "recommended_controls": [ "DC-04", "DC-08", "DG-03", "DG-04", "DG-08", "DS-06", "DP-02", "DP-03", "DP-07", "PM-02", "PM-03", "PM-05", "PM-07", "PM-08", "PC-04", "PC-05", "PC-06", "PC-07" ] }, { "profile_id": "us-state-privacy", "name": "US State Privacy Law Scope", "description": "Processing personal data of California residents (CCPA/CPRA + CPPA ADMT Regs) or residents of other US states with privacy laws.", "required_controls": [ "DC-01", "DC-03", "DC-05", "DC-06", "DC-07", "DG-01", "DG-05", "DG-07", "DS-01", "DS-02", "DS-03", "DS-04", "DS-05", "DS-06", "DS-07", "DS-08", "DP-01", "DP-05", "PM-01", "PM-04", "PM-06", "PC-01", "PC-02", "PC-03", "PC-08" ], "recommended_controls": [ "DC-02", "DC-04", "DC-08", "DG-02", "DG-06", "DG-08", "DP-02", "DP-03", "DP-07", "PM-02", "PM-03", "PM-05", "PM-07", "PM-08", "PC-04", "PC-05", "PC-07" ] }, { "profile_id": "healthcare-ai", "name": "Healthcare AI / Health Data", "description": "AI systems processing health data, medical records, or special category health information. Heightened controls apply.", "required_controls": [ "DC-01", "DC-02", "DC-03", "DC-07", "DG-01", "DG-02", "DG-05", "DG-06", "DG-07", "DS-01", "DS-02", "DS-04", "DP-01", "DP-02", "DP-03", "DP-04", "DP-05", "DP-07", "PM-01", "PM-04", "PM-05", "PM-06", "PC-01", "PC-02", "PC-06", "PC-07", "PC-08" ], "recommended_controls": [ "DC-04", "DC-05", "DC-06", "DC-08", "DG-03", "DG-04", "DG-08", "DS-03", "DS-05", "DS-06", "DS-08", "DP-06", "DP-08", "PM-02", "PM-03", "PM-07", "PM-08", "PC-03", "PC-04", "PC-05" ] }, { "profile_id": "enterprise-general", "name": "General Enterprise AI", "description": "Enterprise AI systems processing personal data without a specific regulatory profile.", "required_controls": [ "DC-01", "DC-03", "DG-01", "DG-05", "DG-07", "DS-01", "DP-01", "DP-05", "PM-01", "PM-04", "PC-01", "PC-02", "PC-08" ], "recommended_controls": [ "DC-02", "DC-04", "DC-05", "DC-06", "DC-07", "DC-08", "DG-02", "DG-06", "DG-08", "DS-02", "DS-03", "DS-04", "DS-07", "DP-02", "DP-03", "DP-07", "PM-02", "PM-06", "PM-07", "PC-03", "PC-04", "PC-07" ] }, { "profile_id": "automated-decisions", "name": "Automated Decisions with Legal Effects", "description": "AI systems making solely automated decisions with legal or similarly significant effects under GDPR Art 22, CCPA ADMT regulations, or UK DUAA.", "required_controls": [ "DC-01", "DC-02", "DC-03", "DG-01", "DG-05", "DS-01", "DS-02", "DS-03", "DS-04", "DS-05", "DS-06", "DS-07", "DS-08", "DP-01", "DP-04", "DP-05", "PM-01", "PM-02", "PM-03", "PM-06", "PC-01", "PC-06", "PC-07", "PC-08" ], "recommended_controls": [ "DC-04", "DC-07", "DC-08", "DG-02", "DG-06", "DG-07", "DP-02", "DP-03", "DP-07", "PM-04", "PM-05", "PM-07", "PM-08", "PC-02", "PC-03", "PC-04", "PC-05" ] } ] } }