HAIAMM v3.0, Data Domain Handbook

AI/HAI Data Assurance, security of the data flowing into and out of the AI systems the organization governs

Version: 3.0 Domain: Data Audience: Security, Data Governance, Privacy/Legal, AI/ML Engineering, Data Platform / MLOps, Compliance Use: Conduct a maturity assessment of the AI/HAI Data Assurance program, and build the practices that move it from Foundational to Industry-Leading.

Preface

This handbook is a self-contained, practitioner-facing document. Read it end to end to understand the Data domain of HAIAMM, or jump to Part IV to perform an assessment.

The handbook makes three commitments to the reader:

1. Fundamentals first. It teaches the load-bearing practices an organization must have to claim mastery of the security of the data its AI systems consume and produce, not a catalog of everything one could do.
2. Measurable by default. Every activity prescribed in these pages is paired with at least one outcome metric (with a baseline, a target, and a source). Activity counts are not metrics; outcomes are.
3. Self-contained. The document does not require the reader to follow links, open companion files, or chase references. Every concept used in the assessment is defined inside these pages.

If a statement in this handbook treats AI as a tool performing security rather than the data being secured as the subject, that statement is wrong. Flag it.

Table of Contents

Part I, Domain Overview

1. About this handbook
2. The Data domain in v3.0 terms
3. Why a domain-specific handbook
4. The seven AI/HAI data archetypes
5. Domain boundary rules
6. Stakeholders and roles
7. How to use this handbook

Part II, Foundations

1. The four Business Functions in this domain
2. The three maturity levels
3. HAI-specific threat tactics (EA, AGH, TM, RA)
4. The priority compliance map
5. Shadow AI in the Data domain (ungoverned data flows to AI)
6. Metrics taxonomy

Part III, The Twelve Practices in the Data Domain

1. Strategy & Metrics (SM)
2. Policy & Compliance (PC)
3. Education & Guidance (EG)
4. Threat Assessment (TA)
5. Security Requirements (SR)
6. Secure Architecture (SA)
7. Design Review (DR)
8. Implementation Review (IR)
9. Security Testing (ST)
10. Environment Hardening (EH)
11. Issue Management (IM)
12. Monitoring & Logging (ML)

Part IV, Maturity Assessment Workbook

1. How the assessment works
2. Scoring methodology
3. The questionnaire (108 questions)
4. Practice-level rollup
5. Domain-level rollup
6. Improvement roadmap template

Part V, Reference

1. Glossary
2. Reference frameworks
3. Change log

Part I, Domain Overview

1. About this handbook

HAIAMM is the Human-Assisted Intelligence Assurance Maturity Model. It is an AI assurance maturity model, structured after OWASP SAMM and BSIMM in shape, and scoped to AI/HAI in content. HAIAMM has six domains, Software, Data, Endpoints, Infrastructure, Vendors, Processes, and twelve practices that apply across all six.

This handbook covers the Data domain. It contains:

• A definition of what the Data domain is and is not.
• The twelve practices, each described in Data-domain terms with three maturity levels (Foundational, Comprehensive, Industry-Leading).
• A complete maturity assessment workbook with 108 yes/no questions and a scoring methodology.
• A reference section with a glossary and the major frameworks HAIAMM aligns with.

This is one of six domain handbooks. Data-specific assessment questions live only in this handbook; the Software handbook contains only Software questions, the Vendors handbook only Vendors questions, and so on.

2. The Data domain in v3.0 terms

The Data domain governs the data flowing into and out of AI systems, the fuel AI systems consume and the exhaust they produce. Data is special: it is the one domain that touches every other domain, because every AI system the organization builds, consumes, hosts, embeds, or exposes is fed by data and emits data.

In scope:

• Training corpora and training datasets, the data assembled to train or pre-train models the organization owns.
• Inference input streams, the live data flowing into deployed AI systems at request time (user prompts, API payloads, sensor streams, document uploads).
• Retrieval stores, the corpora, document collections, and indexed knowledge bases that retrieval-augmented-generation pipelines query.
• Prompt/completion log corpora, the captured record of what was sent to and returned from AI systems, retained for debugging, evaluation, audit, and compliance.
• Embedding stores, the vector representations derived from org data, held in vector databases and feature stores.
• Fine-tuning datasets, the curated, often regulated data assembled to adapt a base model to a specific task.
• Evaluation and test sets, the held-out data used to measure model quality, safety, and regression.

Out of scope of the Data domain:

• The AI software that consumes and produces the data, that is the Software domain (a fine-tuning workload is a Software artifact; the dataset it consumes is a Data artifact; cross-references are expected).
• The infrastructure that physically stores and serves the data, that is the Infrastructure domain (a vector-store cluster is an Infrastructure artifact; the embeddings inside it are a Data artifact).
• AI tools and services consumed from third parties, that is the Vendors domain (data shared with a vendor AI service is a Data concern at the data-flow level and a Vendors concern at the service level).
• Business workflows that embed AI, that is the Processes domain.
• AI-enabled endpoints and user interfaces, that is the Endpoints domain.

The subject of every cell in this handbook is the data the organization's AI systems consume and produce. The data is what is being secured.

3. Why a domain-specific handbook

Securing the data that feeds and flows from AI systems is not the same as classic data security. Five reasons motivate the standalone handbook:

• AI changes the data risk surface. Training-data poisoning, membership inference, embedding inversion, retrieval-store poisoning, prompt/completion-log leakage, and evaluation-set contamination are failure modes that classic data-loss-prevention and data-governance programs were never designed to catch.
• Data is HAI's fuel and exhaust. Every prompt is data leaving a governed boundary; every completion is data entering a log store; every fine-tune consumes a corpus; every RAG query touches a retrieval index. The volume and velocity of AI data flows outstrip manual governance.
• Regulators address AI data specifically. EU AI Act Article 10 imposes data-governance obligations on high-risk AI systems. GDPR Article 5 purpose-limitation, Article 30 records-of-processing, and Articles 15/17 subject-access and erasure rights all apply when personal data is used in training, retrieval, or inference. The program must produce evidence on demand.
• Shadow data flows to AI are the program's primary L1 outcome. Datasets leaving governed stores into ungoverned AI pipelines, prompt/completion logs accumulating regulated data without classification, embeddings derived from data the model should never have seen, these ungoverned flows are the central problem the L1 program exists to solve.
• Seven archetypes, one program. The seven AI/HAI data archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set) behave differently enough that threats, requirements, reference architectures, and tests are archetype-keyed throughout the handbook.

4. The seven AI/HAI data archetypes

Most of the practices in this handbook key their content to seven archetypes. Knowing the archetypes well is a prerequisite for using the handbook.

1. Training corpus / training dataset. The data assembled to train or pre-train a model the organization owns. Risk shape: data poisoning, supply-chain compromise of upstream datasets, consent and lawful-basis gaps, regulated data entering the corpus without authorization, provenance loss.

2. Inference input stream. The live data flowing into a deployed AI system at request time. Risk shape: prompt injection arriving in the input stream, sensitive data entering the model unintentionally, input-stream tampering, classification-label loss at the boundary.

3. Retrieval store. The corpora and indexed knowledge bases a RAG pipeline queries. Risk shape: retrieval-store poisoning (indirect prompt injection via planted content), cross-tenant retrieval bleed, stale or mis-classified content served as authoritative, provenance gaps.

4. Prompt/completion log corpus. The captured record of inputs to and outputs from AI systems. Risk shape: regulated data accumulating in logs without classification or redaction, over-retention, leakage through under-controlled log access, logs becoming an unmanaged shadow dataset.

5. Embedding store. The vector representations derived from org data, held in vector databases. Risk shape: embedding inversion (reconstruction of source text from vectors), cross-tenant vector bleed, embeddings derived from data the model should not have seen, retention beyond the source data's lawful basis.

6. Fine-tuning dataset. The curated data assembled to adapt a base model. Risk shape: memorization leading to extraction of regulated records, label-flipping and poisoning, consent and lawful-basis gaps, no-train obligations on data sourced from vendor APIs.

7. Evaluation / test set. The held-out data used to measure model quality and safety. Risk shape: eval-set contamination (test data leaking into training), metric gaming, stale eval sets giving a false sense of safety, regulated data in eval sets without controls.

A single data asset can be more than one archetype at once, a corpus used both for fine-tuning and as a retrieval store, a prompt/completion log corpus reused as a training set. Threat libraries, requirements packs, reference architectures, and tests in this handbook accommodate that.

5. Domain boundary rules

When in doubt about whether something belongs in the Data domain, ask: is the concern about the data itself, its provenance, classification, lawful basis, integrity, retention, and the flows it travels, or about the thing that processes or stores it?

• If the concern is the data itself: it is a Data artifact.
• If the concern is the AI software that processes it: Software. If the concern is the infrastructure that stores it: Infrastructure. If the concern is a vendor service it is shared with: Vendors.

Common boundary cases:

• A fine-tuning workload is a Software artifact; the dataset it consumes is a Data artifact; the GPU fleet it runs on is an Infrastructure artifact.
• A vector-store cluster is an Infrastructure artifact; the embeddings stored inside it are a Data artifact; the RAG pipeline that queries it is a Software artifact.
• A prompt/completion log corpus is a Data artifact even though the log pipeline that captures it is instrumented by the Software domain's ML practice, the corpus, its classification, retention, and access controls are Data concerns.
• Data shared with a third-party AI service is a Data concern at the data-flow level (what class of data, under what lawful basis, with what residency) and a Vendors concern at the service level. Cross-references are expected.

6. Stakeholders and roles

The AI/HAI Data Assurance program is cross-functional by design. The following roles appear throughout this handbook:

• Executive sponsor. Typically the CISO co-sponsored by the Chief Data Officer; co-signed by Privacy/Legal where personal data is in scope. Owns budget, scope, and decision rights for the program.
• Program lead. Operationally accountable for the program day-to-day. Often the Data Governance lead or a data-security lead. Maintains the AI/HAI data inventory, runs the working group, owns the metrics.
• Cross-functional working group. Security, Data Governance, Privacy/Legal, AI/ML Engineering, Data Platform / MLOps, and a business-unit data owner. Meets at least monthly.
• Data stewards. Named owners for each data domain or data class, accountable for classification, lawful basis, and retention of the data assets in scope.
• Intake reviewers. A small population trained to assess AI/HAI data assets against the threat library, the requirements pack, and the priority compliance map.
• Privacy officer. Reviews lawful basis, subject-rights exposure, cross-border flows, and EU AI Act Article 10 data-governance obligations for regulated data.
• AI/ML engineering and Data Platform. Own the technical pipelines that move data into training, retrieval, embedding, and inference, and the controls that govern those flows.
• Integration owners. The owner of each AI/HAI data asset in the inventory, named and accountable for maintaining its posture.

7. How to use this handbook

Three modes of use are supported:

• Read it linearly. Parts I and II ground the reader in the domain and foundations. Part III walks the twelve practices in the Data-domain context. Part IV provides the assessment instrument. Part V is reference.
• Run an assessment. Skim Parts I and II for context (one to two hours), then go directly to Part IV. The 108 questions are organized by practice and by maturity level, with explicit evidence prompts. Scoring methodology and rollup tables follow.
• Build a program from scratch. Read Part II carefully, then implement the twelve practices' Level 1 in the order described in Part II's dependency text. Use the Level 1 questions in Part IV as a self-check for completeness.

The questions in Part IV are duplicated as a per-practice "Practice Maturity Questions" section at the end of each practice in Part III. They are the same questions; the duplication is deliberate so the practice-by-practice reader sees the assessment instrument inline.

Part II, Foundations

8. The four Business Functions in this domain

The twelve practices group into four Business Functions. Each function exists for a distinct intent. Every practice belongs to exactly one function.

Governance, Strategy & Metrics (SM), Policy & Compliance (PC), Education & Guidance (EG). Establish why, what, who, and how: the program's strategic frame, its enforceable rules, and the workforce literacy that makes everything downstream possible. In this domain, Governance answers: who owns AI/HAI data risk, what policies govern data use in AI, what training every data steward and reviewer must complete, and how data enters AI pipelines through a sanction gate.

Building, Threat Assessment (TA), Security Requirements (SR), Secure Architecture (SA). Decide what could go wrong with the data, what the data asset must do about it, and how data stores and flows are shaped to do it, before a corpus is assembled or a pipeline is wired. In this domain, Building answers: what threats AI/HAI data archetypes carry, what requirements every data asset must meet, what reference patterns govern data flows.

Verification, Design Review (DR), Implementation Review (IR), Security Testing (ST). Prove that the designed data store, the implemented data store, and the running data flow actually meet the Building-function outputs. In this domain, Verification answers: did the design follow the reference pattern, do the live classification labels and retention settings match the design, and does the data asset actually resist adversarial probes.

Operations, Environment Hardening (EH), Issue Management (IM), Monitoring & Logging (ML). Run the program safely in production, harden the data stores and pipelines, manage the issues, and watch what is actually happening to the data. In this domain, Operations answers: which controls keep governed data flows frictionless and ungoverned flows observable, where data issues go, and what telemetry produces records-of-processing evidence on demand.

Cross-function rule: progress in one function without the others is unstable. The handbook is balanced across the four by design. L1 build order follows the dependency graph: SM precedes everything; PC and EG follow SM; TA, SR, and SA follow Governance; DR and ST run after SA L1 exists; IR follows DR; EH, IM, and ML form the Operations layer that depends on SM inventory, SA patterns, and PC policies all being in place.

9. The three maturity levels

Every cell in this handbook is one of three maturity levels. The levels are cumulative, Level 2 assumes Level 1 is in place; Level 3 assumes Level 2 is in place.

Level 1, Foundational. Stand up the minimum viable capability. Discover what AI/HAI data the organization holds and flows, publish the core policies, run the first version of the controls, baseline the metrics. Typical outputs: an inventory of data assets across all seven archetypes, short published policies (AI Data Use, Data Acceptable Use, Data Intake/Sanction Gate), per-archetype threat models, per-archetype requirements packs, per-archetype reference patterns, first detections, first logging baselines. Reality check: if the program cannot answer "what data flows into and out of our AI systems, what rules apply to it, and who is accountable" within a week, it is not at Level 1.

Level 2, Comprehensive. Calibrate the program's intensity by risk tier. Move from one-size-fits-all to differentiated depth. Replace point-in-time activities with continuous validation. Typical outputs: a published risk-tier rubric, a tier-treatment matrix, per-tier calibrated activities, per-asset deep threat models for Critical-tier data, quantitative requirements packs, continuous lineage and classification validation, post-incident learning loops. Reality check: if the same governance effort goes to a Low-tier public-data evaluation set and to a Critical-tier fine-tuning dataset full of regulated personal data, the program is not at Level 2.

Level 3, Industry-Leading. Automate the substrate. Benchmark externally against peers. Contribute back to the AI-assurance ecosystem. Typical outputs: signal-driven inventory and lineage automation, machine-readable data-classification and provenance enforcement, continuous attestation, external benchmarking briefs, contributions to MITRE ATLAS, OWASP, NIST AI RMF Playbook, AI Vulnerability Database, OpenSSF AI, and sector ISACs. Reality check: if all activity is still internally generated, no external contributions, no benchmarking deltas, no automation replacing routine governance work, the program is mature for its own purposes but is not industry-leading.

10. HAI-specific threat tactics (EA, AGH, TM, RA)

Four AI-specific threat-tactic categories appear throughout this handbook. In the Data domain they manifest through the data the AI consumes and produces.

EA, Excessive Agency. An AI or agent with broader capability than its use case requires reaches data it should never touch, a retrieval store wider than the task, a fine-tuning corpus pulling regulated classes the model never needed. In Data terms, EA is the over-broad data grant.

AGH, Agent Goal Hijack. The agent's benign goal is redirected via content injected along a trusted-looking path. In the Data domain the trusted path is the retrieval store or the prompt/completion history, poisoned content planted in a corpus the agent treats as authoritative. AGH is the central reason retrieval-store integrity is a first-class Data concern.

TM, Tool Misuse. Tools available to the AI are invoked for attacker purposes. In Data terms, a data-access tool or a query interface is used to exfiltrate beyond intended scope, argument smuggling against a retrieval API, crafted queries against an embedding store.

RA, Rogue Agents. Autonomous agents drift from intended behavior. In Data terms, drifting agents accumulate, retain, or propagate data outside policy, a long-running agent that builds up an unmanaged memory store of regulated data.

The four categories sit alongside the data-native failure modes that dominate this domain, training-data poisoning, membership inference, embedding inversion, data exfiltration via inference, evaluation-set contamination, and are tagged where the threat libraries, requirements, and tests reference them.

11. The priority compliance map

Every Data-domain Policy & Compliance practice at Level 1 publishes (and downstream practices reference) a one-page priority compliance map. The set below is the priority set for the Data domain. Sector-specific items are added as applicable.

The map's purpose is traceability: an auditor or regulator asking "how is GDPR Article 30 addressed for our AI data?" should reach a single cell in the map and from there one policy and from there one evidence artifact.

12. Shadow AI in the Data domain (ungoverned data flows to AI)

Shadow AI, AI/HAI adopted outside the program's visibility, attribution, and governance, takes a data-specific shape in this domain:

• Shadow AI in Data is the ungoverned data flow. Datasets copied out of governed stores into ungoverned AI pipelines. Prompt/completion logs accumulating regulated data with no classification, redaction, or retention policy. Embeddings derived from data the model should never have been allowed to see. Fine-tuning corpora assembled from production data without a lawful-basis review. Evaluation sets sourced from customer records without controls.
• Shadow data flows compound. Every month of ungoverned flow increases the regulated-data footprint inside model weights, retrieval indexes, embedding stores, and log corpora, places from which data is far harder to erase than from a database. Subject-erasure obligations under GDPR Article 17 become progressively more expensive to honor.
• Shadow data flows are observable today. The signals already exist, data-access logs on governed stores, egress to AI provider endpoints, pipeline job metadata, classification-label coverage gaps, canary-tagged dataset tracking. No new tooling is required at L1.
• Shadow data flows manifest through more than one practice. The handbook treats them primarily in SM and EG, but they appear in TA (shadow-data threat view), PC (sanction gate and amnesty path), EH (DLP tuned for bulk dataset and embedding exfiltration, canary tagging), IM (ungoverned-flow containment), and ML (egress and lineage detections).

Every Level 1 activity in this handbook contributes to making ungoverned data flows to AI visible, attributable, and trending down. The Level 1 outcome metric "ungoverned-AI-data-flow ratio" appears in Strategy & Metrics, Policy & Compliance, Education & Guidance, Threat Assessment, Environment Hardening, and Monitoring & Logging, six of the twelve practices. That is intentional.

13. Metrics taxonomy

Every level block in this handbook carries three metric types. The taxonomy is the canonical vocabulary; examples and targets are practice-specific.

• Outcome metrics (lagging). Directly measure whether the level's goal was achieved. Reported monthly or quarterly. Stated in a four-column table: Metric · Baseline · Target · Source.
• Process metrics (leading). Predict outcome metrics by measuring execution. Reported weekly or at the cadence of the underlying activity.
• Effectiveness metrics (business value). Measure what the outcome means to the business. Reported quarterly, often qualitative supported by quantitative.

Metric selection follows two rules: SMART (specific, measurable, achievable, relevant, time-bound) and outcome over output (results are preferred to activity counts). If a metric does not have a baseline column, the baseline is the value the program records on first measurement. The first cycle of measurement is itself an L1 activity.

Part III, The Twelve Practices in the Data Domain

Each practice section follows the same shape:

• Practice Overview. Objective, description, context.
• Maturity Level 1. Objective, activities (A, B, C), outcome metrics, success criteria.
• Maturity Level 2. Same structure.
• Maturity Level 3. Same structure.
• Common Pitfalls. Three to four per level.
• Practice Maturity Questions. Three yes/no questions per level, the same questions also appear in the Part IV assessment workbook.

14. Strategy & Metrics (SM)

Practice Overview

Objective: Stand up an AI/HAI Data Assurance program that discovers, inventories, and strategically governs all data flowing into and out of the AI/HAI systems the organization operates, with shadow-data-in-AI prevention as the primary L1 outcome and a defensible risk-tier rubric as the primary L2 deliverable.

Description: SM-Data establishes the program charter, the authoritative inventory of the data assets that AI/HAI systems consume and produce, and the practice-maturity metrics that prove the program is working. The Data domain governs HAI's fuel and exhaust across seven archetypes: training corpora and training datasets, inference input streams, retrieval stores, prompt/completion log corpora, embedding stores, fine-tuning datasets, and evaluation/test sets. SM-Data L2 produces the risk-tier rubric every other Data-domain L2 practice depends on per the v3.0 dependency graph; every downstream Data-domain practice (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) inherits its tier-calibration from the rubric authored here.

Context: Data moves into AI systems through many uncontrolled paths. A researcher uploads a fine-tuning dataset from a personal drive; an engineer wires a new retrieval store to a production RAG pipeline; prompt/completion logs from a customer-facing feature accumulate in an object-store bucket with no retention policy; an ML team trains on a corpus that includes PII without privacy-officer sign-off. None of this is necessarily malicious, it is the normal pace of AI-enabled development operating faster than data governance. But it creates data-class exposure at inference, training-data leakage risk (TM), retrieval-source poisoning vectors (AGH), embedding-store inversion risk, and unmet EU AI Act Art. 10 data-governance obligations. The AI/HAI Data Assurance program makes the data surface visible, attaches accountable ownership per asset, and ensures that data flowing to AI systems is known, classified, governed, and compliant, so sanctioned data sources onboard faster and ungoverned ones cannot quietly accumulate.

Maturity Level 1

Objective: Stand up the AI/HAI Data Assurance program, build an inventory of data assets serving AI/HAI systems, and establish baseline metrics that prove shadow data in AI is decreasing.

Activities.

A) Charter the AI/HAI Data Assurance program. Publish a short program charter that names the problem (shadow data in AI, ungoverned training corpora, inference inputs containing PII without a consent basis, retrieval stores populated without classification review), defines scope, and assigns accountable ownership. The program does not require a new team, it requires a named owner, a cross-functional working group, and a clear intake gate for new data sources feeding AI systems. Charter elements include a problem statement grounded in why data flowing into AI is a distinct governance category (data becomes training signal subject to poisoning and leakage, retrieval context subject to retrieval-poisoning and AGH, prompt input subject to injection vectors, or logged exhaust carrying privacy obligations; EU AI Act Art. 10 places data-governance duties on deployers; GDPR Arts. 5/6/9 require lawful basis before personal data reaches an inference endpoint); the seven in-scope data archetypes (training corpus / training dataset, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set); an executive sponsor, typically the CISO co-sponsored by the DPO/CPO and the Head of Data or Head of Engineering, co-signed by Privacy/Legal; a working group spanning Security, Engineering/ML Platform, Data/Analytics, Privacy/Legal, Product, and one application-architect reviewer; decision rights for approving, blocking, and granting exceptions on new data sources, and for approving cross-border data flows; and a numerical year-one success target tied to the L1 outcome metrics.

B) Build the AI/HAI data inventory and discover shadow data in AI. Establish a single AI/HAI data inventory as the program's source of truth, seeded from authoritative data signals and then actively reconciled against discovery. Minimum inventory fields are asset name, owning team, archetype, data classification (regulated PII / PHI / PCI / source code / customer confidential is Critical-class; org confidential is High; internal is Medium; public is Low), lineage and provenance (known consented source, licensed corpus, scraped or unknown, internally generated), volume and criticality (size in tokens/records/bytes, production-load-bearing flag, system-of-record or derivative), cross-border flows (countries of origin and processing, GDPR Art. 44–49 transfer flag), use context (training vs. inference vs. eval), decision-affecting use (feeds an Annex III or GDPR Art. 22 system), subject-access-rights exposure (data subjects covered by GDPR Arts. 15–21 are present), retention policy status (defined / enforced / undefined), approval status (Sanctioned / Provisional / Under review / Prohibited / Awaiting Intake), risk tier (populated at L2), and linked artifacts (TA snapshot, SR REM, latest IR finding, ML logging-baseline status). Discovery at L1 uses signals platform and data teams already have: data catalogs (Atlan, Collibra, DataHub, Unity Catalog, AWS Glue) searched for datasets named or tagged training, embedding, eval, fine-tune, inference, rag, or vector; model-registry lineage (MLflow, Weights & Biases, SageMaker, Vertex AI) revealing which corpora were consumed; ETL/ELT pipeline metadata (Airflow DAGs, dbt models, Fivetran connectors) whose destination is a training or retrieval store; object-store inventories (S3 / GCS / Azure Blob) filtered for training, embeddings, eval, logs, and prompt paths; vector-store namespace and collection listings (Pinecone, Weaviate, Qdrant, Chroma, pgvector); prompt/completion log volumes from observability backends revealing active inference input streams and log corpora; classification scanners (Amazon Macie, BigID, Microsoft Purview) run against object stores and databases to surface regulated data flowing to AI; and a short self-attestation form publicized to engineering and data-science teams with an amnesty window for previously undisclosed assets already in use.

C) Establish foundational metrics that measure practice maturity and shadow-data-in-AI reduction. Baseline and track a small, automatable set of outcome, process, and effectiveness metrics tied to the L1 outcome (shadow-data reduction and inventory coverage of what AI systems actually consume). Publish a quarterly shadow-data-in-AI scoreboard to the executive sponsor that reports total inventory by approval status broken out by archetype, new data assets discovered this quarter with their intake status, the shadow-data-in-AI ratio trend across the last four quarters, AI Data AUP attestation coverage across engineers and data scientists handling AI data, and the top five unmitigated data risks (TA-flagged, classification-scanner-flagged, or external-advisory-flagged) with owners and remediation status. Keep activity counts (scans run, datasets tagged) out of the outcome view, they belong to process metrics.

Outcome Metrics (L1).

Success Criteria.

• Program charter published and sponsored by an accountable executive (CISO co-sponsored by DPO/CPO and Head of Data or Engineering) with a cross-functional working group.
• AI/HAI data inventory exists as a single source of truth with ≥90% coverage of discovered data assets within 12 months, broken out by archetype.
• Shadow-data-in-AI ratio baselined and trending down for two consecutive quarters.
• ≥95% of engineers and data scientists handling AI data have acknowledged the AI Data AUP.
• Quarterly shadow-data-in-AI scoreboard delivered to the executive sponsor with archetype-level breakdown.

Maturity Level 2

Objective: Risk-tier every AI/HAI data asset using the canonical rubric, calibrate the program's intensity per tier, and measure practice maturity and shadow-data reduction per tier, establishing the rubric every other Data-domain L2 practice depends on.

Activities.

A) Define the AI/HAI data risk-tier rubric. Four tiers, Critical / High / Medium / Low, assigned from a small set of auditable dimensions specific to AI/HAI data assets. Data classification: regulated PII / PHI / PCI / source code / customer confidential elevates to Critical or High depending on volume and use; org confidential is High; internal is Medium; public is Low. Lineage and provenance: unknown origin or data scraped without explicit license or consent verification elevates tier; a known consented source with documented legal basis does not elevate; a licensed corpus without data-subject consent is treated per applicable sector rules and GDPR Art. 5(1)(b) compatibility. Volume and criticality: system-of-record data or data production-load-bearing for a revenue-critical AI system elevates; derivative or experimental data is neutral. Cross-border flows: transfer of personal data to a third country triggers a GDPR Art. 44–49 assessment and elevates to at least High, or Critical where no adequacy decision or SCC is in place; sector-specific cross-border restrictions (HIPAA PHI outside the US, ITAR, financial-sector localization) are Critical. Use in training vs. inference vs. eval: data used in training or fine-tuning elevates posture relative to the same data used only at inference, making training use a Critical dimension; an eval/test set used in red-team exercises for a Critical-tier model is at least High. Decision-affecting use: data feeding an EU AI Act Annex III high-risk system or a GDPR Art. 22 automated-decisioning system is Critical. Subject-access-rights exposure: where data subjects covered by GDPR Arts. 15–21 are present, the asset requires clear retention boundaries and deletion capability and elevates if retention control is absent. Tier derivation is deterministic from the rubric inputs; human overrides are allowed but recorded with rationale and reviewed by the working group.

B) Calibrate program intensity per tier. Publish a tier-treatment matrix specifying what each tier receives from the Data-domain program, intake depth, encryption at rest, lineage and provenance depth, classification-label propagation, retention-policy enforcement, EU AI Act Art. 10 evidence, subject-access-rights capability, TA depth, IR cadence and re-review triggers, and IM SLAs by severity. Critical assets receive the full program: full classification review plus a DPIA gate with privacy-officer and executive sign-off, HSM-rooted key-per-asset encryption (BYOK or customer-managed), full source-to-model lineage, label propagation to all downstream derivatives, retention policy defined-enforced-and-audited with deletion confirmed, a full Art. 10 data-governance evidence package, tested deletion and access-response capability, a per-asset deep threat model covering AGH/TM/retrieval-poisoning/embedding-inversion, go-live plus semi-annual plus on-material-change IR, and Critical-finding SLAs (acknowledge ≤4h, mitigate ≤48h). Low assets use the fast-track: a lineage record only, managed encryption, archetype-level threat model, go-live IR, and relaxed SLAs (acknowledge ≤5 BD, mitigate ≤30d). Each downstream Data-domain L2 practice inherits this calibration; the rubric and the matrix are authored here in SM L2 and changes flow through the SM working group.

C) Per-tier scoreboard and governance. The L1 shadow-data-in-AI scoreboard becomes tier-aware. Inventory state is reported by tier and by archetype, a Critical-tier regulated training corpus is its own row, the count of Low-tier public eval sets is one line. The shadow-data-in-AI ratio is reported per tier, a Critical-tier unclassified training corpus is a headline, a Low-tier one is a line item. Per-tier SLA adherence across intake, IR, ML, and IM is reported monthly. The tier-movement log records upgrades (an asset that gained regulated content, a cross-border flow, or a training use) and downgrades with rationale, reviewed by the program sponsor. Quarterly executive review explicitly discusses tier-balance: is the program's effort matching the program's risk profile?

Outcome Metrics (L2).

Success Criteria.

• Risk-tier rubric published and applied; tier assigned to 100% of inventory from auditable dimensions.
• Tier-treatment matrix published; downstream practices (PC, TA, SR, SA, DR, IR, ST, EH, ML, IM) calibrated to it.
• Per-tier shadow-data-in-AI ratio reported quarterly; Critical-tier unclassified or ungoverned data assets in production = 0.
• Per-tier SLA adherence ≥90% across practices.
• Tier-movement governance active, changes logged with rationale and reviewed by the sponsor.

Maturity Level 3

Objective: Automate inventory and tier maintenance from catalog, lineage, classifier, and pipeline telemetry; benchmark the program against external data-governance peers; and contribute to industry data-governance and AI-risk-management standards.

Activities.

A) Continuous inventory and tier automation from catalog, lineage, classifier, and pipeline signals. Inventory auto-updates from data-catalog metadata events (new dataset registered, schema change, classification-label update), model-registry lineage events (new training-data source linked to a model version), ETL/ELT pipeline runs (a new destination is a training or retrieval store), classification-scanner findings (a new regulated data class detected in an existing asset), object-store inventory diffs (new buckets or paths matching AI data patterns), vector-store collection changes, prompt/completion log volume spikes (a new asset emitting logs is a discovery signal), self-attestation, and the intake queue. Tier assignments are rule-based on the L2 rubric inputs; rule changes are versioned and replayable; tier changes auto-trigger downstream practice obligations (a Medium-to-Critical upgrade triggers the DPIA gate, an encryption upgrade, and IR reconfiguration). Human curation handles new archetypes, ambiguous classification-scanner findings, and dimensional-input conflicts. A data-quality SLO is published: ≥99% of active AI/HAI data assets correctly tiered within 48 hours of a material change; ≥95% inventory completeness against discovery-source reconciliation.

B) External benchmarking. Program metrics are compared against peer benchmarks through CDMC (Cloud Data Management Capabilities) maturity assessments, the EDM Council Data Management Capability Assessment Model (DCAM) for AI data-governance components, DAMA DMBOK practitioner communities, ISO/IEC 23894 AI risk-management working groups, sector ISACs with AI data-governance tracks (FS-ISAC, H-ISAC, IT-ISAC), and formal peer roundtables of CISO/DPO communities and AI safety practitioner circles. A semi-annual "how we compare" brief covers inventory coverage, shadow-data-in-AI ratio, per-tier SLA adherence, automation level, classification accuracy, retention-enforcement rate, and time from "new data source proposed" to "provisional approval issued." Benchmark deltas inform program investment, the board-level narrative, and next-year L2 / L3 work priorities.

C) Contribute to industry data-governance and AI-risk-management standards. Contribute to DAMA DMBOK and AI data-management community working groups, the EDM Council AI Risk and Data Governance Principles, the ISO/IEC 23894 AI risk-management standard (data-domain implementation guidance), the NIST AI RMF Playbook Data chapter and successor editions, the CSA AI Safety Initiative AI data-governance controls matrix, OpenSSF AI (training-data supply-chain advisories, embedding-store security guidance), and sector ISACs where AI data-governance working groups accept practitioner input. Target a minimum of four substantive contributions per year; quality over volume; every contribution anonymized and legally vetted.

Outcome Metrics (L3).

Success Criteria.

• Inventory auto-update SLO published and met; tier-rule change-log versioned and replayable.
• Tier-assignment automation operational with exception-based human review; tier changes auto-trigger downstream obligations within 24 hours.
• Semi-annual external-benchmarking brief published to the sponsor with ≥5 peer-comparable metrics.
• ≥4 substantive industry contributions per year, anonymized and cited.
• Executive / board ROI narrative refreshed at least annually with external benchmarks and avoided-loss examples.

Common Pitfalls

Level 1. - Inventory seeded only from "data the ML team told us about", misses retrieval stores added by engineering, prompt/completion log corpora accumulating in object storage, and fine-tuning datasets uploaded by researchers from personal drives. - Treating data flowing through org-built AI services as a Software-domain concern only, data classification, lineage, and retention at the corpus, log, and embedding level are Data-domain responsibilities; the two cross-reference but do not duplicate. - Program positioned as a blocker, the intake SLA is unpublished and data teams route around the program by using unreviewed data sources. - Metrics count activity (scans run, datasets tagged) instead of outcomes (shadow-data-in-AI ratio down, regulated-data exposure events trending down).

Level 2. - Tier-rubric inputs are subjective ("important," "sensitive"), reviewers tier differently, auditors do not trust it, and tier movements feel political. - Tier-treatment matrix published but not enforced, Critical training corpora lack DPIA coverage and HSM-rooted encryption because enforcement never happened. - Scoreboard still reported in aggregate, hiding Critical-tier shadow data because overall averages look fine. - Downstream practices treat tier as advisory, not operational, DR / IR / ST / ML do not differentiate scope by data tier, defeating the purpose of L2.

Level 3. - Automation runs without a data-quality SLO, signal-driven inventory silently drifts and privacy and data teams stop trusting it. - Benchmarking chooses peers that flatter the program instead of stretching it (startup benchmarks while operating at enterprise scale and regulatory exposure). - Industry contributions are presentations and conference talks, not technical artifacts that land in DAMA / EDM Council / ISO / NIST / CSA working groups. - Tier-change downstream triggers fire on every schema edit, data teams disable the signal-source rather than fix rule sensitivity.

Practice Maturity Questions

Level 1. 1. Is there a published AI/HAI Data Assurance program charter with a named executive sponsor (CISO co-sponsored by DPO/CPO and Head of Data or Engineering), a cross-functional working group, and clear decision rights for approval, block, exception, and cross-border-flow approval across all seven data-domain archetypes? Evidence: charter document with sponsor signatures and working-group roster. 2. Does a single AI/HAI data inventory exist, seeded from data catalogs, model-registry lineage, ETL/ELT pipeline metadata, object-store inventories, vector-store listings, classification-scanner findings, and prompt/completion log volumes, covering all seven archetypes with ≥90% coverage of discovered assets within 12 months? Evidence: inventory export reconciled against discovery-source query results. 3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow-data-in-AI ratio (≤15% trending down), AI Data AUP attestation (≥95% of engineers and data scientists), named-owner coverage (100%), and regulated-data-in-AI exposure events? Evidence: most recent quarterly shadow-data-in-AI scoreboard deck.

Level 2. 1. Is every AI/HAI data asset in the inventory assigned a risk tier based on the seven auditable dimensions, data classification, lineage and provenance, volume and criticality, cross-border flows, use in training vs. inference vs. eval, decision-affecting use (EU AI Act Annex III / GDPR Art. 22), and subject-access-rights exposure? Evidence: rubric document plus inventory column showing tier and derivation inputs per asset. 2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier data assets receiving full-scope treatment (HSM-rooted encryption, full lineage, DPIA closure, retention enforcement, EU AI Act Art. 10 evidence) in the last 12 months? Evidence: tier-treatment matrix plus cross-practice adherence report for Critical assets. 3. Does the quarterly shadow-data-in-AI scoreboard report per tier and per archetype (with Critical-tier unclassified or ungoverned data assets in production tracked at zero), and is tier-movement logged and reviewed by the sponsor? Evidence: tier-aware scoreboard and tier-movement log for the prior two quarters.

Level 3. 1. Do inventory and tier assignment auto-update from live catalog, lineage, classifier, and pipeline telemetry with a published data-quality SLO, and is ≥80% of curation handled automatically with exception-based human review? Evidence: pipeline diagram, SLO dashboard, curation-source breakdown. 2. Do you publish a semi-annual external-benchmarking brief comparing the program against ≥5 peer-comparable metrics via CDMC / EDM Council / DAMA / sector ISACs / ISO/IEC 23894, and does it drive program investment decisions? Evidence: most recent brief and a budget or staffing decision traceable to a benchmark delta. 3. Does the program contribute ≥4 substantive, anonymized artifacts per year to AI data-governance standards (DAMA, EDM Council, ISO/IEC 23894, NIST AI RMF, CSA AI Safety Initiative, OpenSSF AI, sector ISACs), and does the executive/board ROI narrative cite external benchmarks? Evidence: contribution log with acceptance confirmations and the most recent ROI narrative.

15. Policy & Compliance (PC)

Practice Overview

Objective: Publish the priority policies and compliance map that make the AI/HAI Data Assurance program enforceable, so every data asset flowing into or out of AI/HAI systems is governed by documented rules, reviewed before it enters production AI use, and defensible to auditors and regulators.

Description: PC-Data codifies three priority policies specific to data flowing through AI/HAI systems, an AI Data Use Policy governing what data classes may be used for training, inference, and eval and under what consent basis; a Data Acceptable Use Policy (AI) governing what engineers and data scientists may do with AI data assets; and a Data Intake / Sanction Gate policy defining what every new data source feeding AI must produce before it is admitted. It maps those policies to the compliance regimes that directly apply: EU AI Act Art. 10 data governance and Annex IV technical documentation; GDPR Arts. 5/6/9/22/30/32/35/44–49 covering lawful basis, special-category data, automated decisioning, records of processing, security, DPIA, and international transfers; ISO/IEC 42001 AIMS data-governance controls; SOC 2 CC6/CC7; and sector-specific rules where applicable (HIPAA PHI, PCI-DSS 3.4, FINRA/SEC model-input retention).

Context: Most organizations inherit data-governance policies written for classic data warehouses and application databases. None of those policies answer the questions AI/HAI data raises: which data classes may be used as fine-tuning input without privacy-officer sign-off, who may authorize a new retrieval source for a production RAG pipeline, what consent basis is required before inference inputs containing personal data are logged into a prompt/completion corpus, or how the GDPR Art. 9 special-category prohibition applies to a medical training corpus. Without AI-specific data policies and an explicit compliance map, regulated data flows into training datasets, retrieval stores are populated from unclassified sources, and prompt/completion logs accumulate personal data past retention limits, all before anyone realizes the obligation exists. PC-Data closes that gap by governing what the organization feeds into AI/HAI systems, in contrast to PC-Software, which governs what the organization builds.

Maturity Level 1

Objective: Publish the three priority AI/HAI data policies, map them to the priority compliance requirements, and operate the Data Intake / Sanction Gate that prevents ungoverned data from entering AI/HAI production use.

Activities.

A) Publish the three priority AI/HAI data policies. Ship each in its smallest useful form, short, readable, and specific enough to be enforceable against data-handling decisions. The AI Data Use Policy governs what data may be used for what AI purposes: permitted use per archetype by data class (regulated PII / PHI / PCI / customer confidential as a fine-tuning input requires explicit privacy-officer approval and documented legal basis; the same data at inference requires DPA coverage of the inference provider; the same data in a prompt/completion log corpus requires a retention-limit policy and deletion capability); consent-basis requirements (personal data used in training requires a documented lawful basis under GDPR Art. 6, and Art. 9 for special-category data, recorded in the asset's inventory record before the training run begins; scraped data without a verified consent basis is prohibited for training on personal data without Legal sign-off); cross-border restrictions (personal data transferred to a third country for training, inference, or storage triggers GDPR Art. 44–49 and is not permitted without an adequacy decision, SCC, IDTA, or BCR on file, with stricter sector localization rules overriding); use-change notification (data collected for one purpose may not be repurposed for AI training without a GDPR Art. 5(1)(b) compatibility assessment and Legal sign-off); and the GDPR Art. 9 special-category prohibition on health, biometric, political, religious, sexual-orientation, racial/ethnic-origin, and criminal-record data in training or fine-tuning without an explicit Art. 9(2) basis reviewed by the DPO. The Data Acceptable Use Policy (AI) enumerates permitted actions (use of sanctioned data sources, vector-store clients, embedding models, and DPA-covered inference providers; logging to sanctioned stores with defined retention), actions requiring approval (adding a new data source to a training corpus or fine-tuning dataset, adding a new collection to a production retrieval store, changing the inference provider receiving personal data, exporting embeddings or fine-tuning datasets outside the governed environment, repurposing a prompt/completion log corpus), actions prohibited without named sign-off (training on Art. 9 special-category data without DPO approval, sending regulated data to an inference endpoint not covered by a current DPA, retaining prompt/completion logs past the defined limit, transferring embeddings or fine-tuning datasets to a country without an Art. 44–49 mechanism), a disclosure obligation to the SM-Data inventory, and attestation at hire and annually. The Data Intake / Sanction Gate policy makes the gate mandatory before any new data asset enters production AI use for any archetype, lists the required gate artifacts by archetype, exposes an amnesty path for previously ungated production assets (routed as open IM findings), and names the program sponsor (or delegated DPO / data-governance lead) as the gate-decision authority.

B) Map the three policies to the priority compliance requirements. Build a one-page priority compliance map an auditor can read in 60 seconds, tying each requirement to the single policy that carries it. EU AI Act Art. 10 data governance maps to the AI Data Use Policy (training data-class restrictions, consent basis, special-category prohibition) plus the Sanction Gate (lineage and legal-basis artifact at go-live); Annex IV technical documentation maps to the Sanction Gate (the lineage and provenance record constitutes the Annex IV data section) plus the Data AUP (provenance disclosure obligation); Art. 9 risk management maps to the Sanction Gate (gate artifacts include the TA snapshot noting data-quality risk and a required classification label). GDPR Art. 5 data principles map to the AI Data Use Policy (purpose limitation, use-change notification, cross-border restrictions) plus the Data AUP (prohibited flows); Art. 6 lawful basis maps to the AI Data Use Policy (consent-basis requirements) plus the Sanction Gate (legal-basis artifact); Art. 9 special-category data maps to the AI Data Use Policy plus the Sanction Gate (DPO approval artifact); Art. 22 automated decision-making maps to the AI Data Use Policy (decision-affecting-use flag) plus the Sanction Gate (Art. 22 safeguards checklist); Art. 30 records of processing maps to the Sanction Gate (lineage record plus named data steward constitutes the Art. 30 entry); Art. 32 security maps to the AI Data Use Policy (DPA coverage required) plus the Sanction Gate (classification label triggers tier-appropriate encryption and access controls from the SM-Data L2 tier-treatment matrix); Art. 35 DPIA maps to the Sanction Gate (DPIA gate for Critical-tier training corpora and fine-tuning datasets); Art. 44–49 international transfers map to the AI Data Use Policy and Data AUP plus the Sanction Gate (transfer-mechanism artifact). ISO/IEC 42001 AIMS traces to the program charter (from SM) plus all three L1 policies; SOC 2 CC6/CC7 traces to the Sanction Gate (access-controls documentation) plus the Data AUP. Sector-specific rules flow into the archetype controls or the gate's required-artifacts checklist: HIPAA (PHI in AI training or inference requires a Business Associate Agreement and minimum-necessary handling), PCI-DSS 3.4 (cardholder data in model-input data must meet storage and encryption controls), and FINRA/SEC model-input retention (model input data and inference logs subject to 17a-4 / FINRA 4370 record-retention obligations).

C) Operate the sanction gate and track foundational compliance outcomes. Policies without an enforced gate do not reduce shadow data in AI. Run a single intake ticket queue with a published SLA (triage within 5 business days; fast-track provisional approval within 10 business days for Low-tier data assets, public domain, no personal data, no cross-border transfer). The artifacts checklist is archetype-keyed, the engineer or data scientist submitting intake receives the checklist for their archetype, and missing artifacts block production AI use. Gate approval creates or updates the SM-Data inventory record with artifact links. The amnesty path is visibly linked from the Data AUP, the intake form, and the engineering and data-science team channels. Exceptions are logged with owner, rationale, and review date; no exception may remain open longer than 90 days without re-review. Inference-provider DPA status, training-on-data posture, and named subprocessor lists are confirmed at the gate rather than trusted from a vendor privacy page.

Outcome Metrics (L1).

Success Criteria.

• Three priority policies (AI Data Use Policy, Data Acceptable Use Policy (AI), Data Intake / Sanction Gate) published, approved by Legal/Privacy/DPO and Security, and communicated to all engineers and data scientists handling AI data.
• One-page priority compliance map published, covering EU AI Act Art. 10 / Annex IV / Art. 9, GDPR Arts. 5/6/9/22/30/32/35/44–49, ISO/IEC 42001, SOC 2 CC6/CC7, and applicable sector-specific obligations; linked from each policy.
• Sanction gate operational with a per-archetype artifacts checklist, a published SLA, and a visible amnesty path.
• ≥95% of engineers and data scientists handling AI data have acknowledged the AI Data AUP in the current year.
• ≥85% of new data sources entering AI production use in the last 12 months passed the gate (100% for Critical/High-tier); every regulated data asset has a named data steward.

Maturity Level 2

Objective: Deepen policy controls and compliance evidence per AI/HAI data risk tier, implement the DPIA gate for Critical training data, and produce audit-ready evidence trails continuously.

Activities.

A) Tier-calibrated policy depth and sign-off requirements. Extend the three L1 policies with tier-specific addenda using the SM-Data L2 tier rubric. Critical assets require full classification review plus a DPIA gate (the GDPR Art. 35 trigger assessed, and the DPIA conducted and closed or accepted-with-residual-risk before gate passage), DPO and privacy-officer sign-off at the gate, legal-basis documentation reviewed by Legal, a confirmed cross-border transfer mechanism on file, HSM-rooted encryption at rest confirmed before the data is used, a retention policy defined-enforced-and-tested, and mandatory re-review within 14 days on every material change (new data class, new consumer, changed cross-border flow, use change from inference to training). High assets require full classification review plus a DPIA where an Art. 35 trigger is present, DPO-delegated data-steward sign-off, legal-basis documentation, a confirmed transfer mechanism, managed encryption with key audit, and re-review within 30 days on material change. Medium assets use base classification review plus a lineage record, fast-track gating where no personal data and no cross-border transfer is present, and re-review annually or within 60 days on material change. Low assets use a lineage record and a self-attested checklist, re-reviewed at annual review. Policy exceptions require a named owner, a compensating-control description, Legal/DPO reviewer acknowledgment, and an expiry date (max 12 months); Critical-tier assets have no amnesty for missing gate artifacts after L2 is established, missing artifacts become blocking findings routed through IM.

B) Continuous compliance evidence assembly. For every Critical and High AI/HAI data asset, maintain a live compliance evidence bundle that auto-assembles the current classification label and last-updated date, the lineage and provenance record (source, consent/license basis, collection method, date), the legal-basis document (Art. 6 or Art. 9 basis or sector equivalent with DPO review date), the DPIA status (complete / accepted-residual-risk / not-triggered with last-review date), the retention policy status (defined / enforced / last-tested with a deletion log for assets past retention), the GDPR Art. 30 record entry, the cross-border transfer mechanism (adequacy decision / SCC / IDTA / BCR or not-applicable with last-validated date), the access-controls attestation, the data steward and owning team with a subject-access-right response contact, and the inference- or storage-provider DPA status. Staleness rules trigger PC-Data findings routed to IM: Critical classification label 90 days, DPIA reviewed on risk-profile change, retention test 90 days, legal-basis document reviewed on regulatory update, provider DPA status 90 days. The evidence bundle is the primary artifact a regulator or auditor receives when asking about a specific AI/HAI data asset.

C) DPIA gate and sector-specific evidence bundles. The DPIA gate is a mandatory step in the sanction gate for all Critical-tier training corpora and fine-tuning datasets, and for any High-tier asset meeting a GDPR Art. 35 trigger (large-scale processing of personal data, special-category data, or systematic evaluation of data subjects); the DPIA must be conducted before the data enters any training run or production retrieval store. Sector-specific evidence bundles are generated from the compliance evidence bundle for applicable assets: a HIPAA PHI bundle (BAA, minimum-necessary assessment, de-identification confirmation if used), a PCI-DSS 3.4 bundle (scope assessment, encryption evidence, cardholder-data handling record), and a FINRA/SEC model-input retention bundle (retention schedule, access log, disposal certification); completeness is tracked. The exception register is integrated with the gate, no exception is approved without a tier-appropriate compensating control and expiry, and a monthly exception aging review escalates exceptions past expiry to the program sponsor.

Outcome Metrics (L2).

Success Criteria.

• Three priority policies extended with tier-specific addenda; tier-appropriate sign-off in place for 100% of Critical assets in the last 12 months.
• Compliance evidence bundle live for every Critical/High asset; staleness inside tier-specific targets.
• DPIA gate operational; 100% of Critical training corpora have a closed or accepted DPIA before production training use.
• Exception register comprehensive and reviewed monthly; zero exceptions past expiry un-escalated; Critical-tier missing gate artifacts treated as blocking findings.
• Sector-specific evidence bundles (HIPAA / PCI-DSS 3.4 / FINRA/SEC as applicable) complete for in-scope assets; regulatory or auditor inquiry evidence SLA (≤5 BD) met in the last 12 months.

Maturity Level 3

Objective: Automate compliance attestation from catalog, lineage, and classifier signals; drive policy updates from monitoring signals and external regulatory motion; and contribute to AI data-governance standards development.

Activities.

A) Continuous compliance attestation from catalog, lineage, and classifier signals. Evidence bundles auto-update from data-catalog metadata events (new dataset, schema change, classification-label update), model-registry lineage events (new training-data source linked to a model version), ETL/ELT pipeline events (a new destination is a retrieval or training store), classification-scanner findings (a new regulated data class detected in an existing asset), retention-enforcement events (a deletion log created when a prompt/completion corpus hits its retention limit), and cross-border transfer changes (a new inference provider in a different jurisdiction auto-opens a PC-Data finding). The attestation-generation pipeline produces a provenance-complete evidence pack for any data asset on regulatory or auditor request, regulation-keyed (EU AI Act Art. 10 evidence pack, GDPR processing-record pack, ISO 42001 AIMS data-governance set) or asset-keyed, within 3 business days. The currency SLO is ≤24 hours latency after a triggering event; completeness is ≥99% of active Critical/High data assets.

B) Telemetry-driven policy refresh and regulatory-motion tracking. Operate a quarterly policy-refresh cycle driven by ML-Data detection trends (which data-class violations are rising in classification-scanner findings), IM-Data incident learnings (which policy gaps created the incident conditions), DPIA outcome patterns (which asset types consistently generate high-residual-risk DPIAs), and external regulatory and standards updates (EU AI Act implementing acts on data, EDPB AI data-processing opinions, NIST AI RMF Playbook updates, US state privacy laws, GDPR enforcement decisions by lead supervisory authorities, sector-specific guidance from FDA/FINRA/OCC/HHS). Refresh output is a versioned changelog for each of the three policies approved by Legal/Privacy/DPO and Security; EG-Data training content updates within 30 days of any policy change. A regulatory-motion tracker maintains a log of open regulatory instruments with expected effective dates, mapped to the policy each will affect; the working group reviews it quarterly.

C) Standards contribution and external engagement. Participate in AI data-governance standards and regulatory forums: EU AI Act Art. 10 implementing-act consultations, EDPB AI data-processing guideline rounds, the ISO/IEC 42001 community, DAMA DMBOK AI data-management chapters, NIST AI RMF Playbook Data working groups, and sector regulators (FDA AI/SaMD data-governance requirements, FINRA model-input data obligations, HHS HIPAA AI guidance). Contribute AI-data-specific artifacts to public standards, sanction-gate schemas, DPIA templates for AI training data, compliance evidence bundle templates, cross-border-transfer checklists for AI inference providers, Art. 30 record templates for AI data assets, through the CSA AI Safety Initiative, the IAPP AI data-governance track, DAMA, the EDM Council, and OpenSSF AI. Target at least two substantive public comments or standards contributions per year on AI/HAI data policy and compliance topics.

Outcome Metrics (L3).

Success Criteria.

• On-demand attestation pack generation inside 3 business days for any active AI/HAI data asset; SLA met in the last 12 months.
• Continuous attestation pipeline operational with ≤24h currency SLO; completeness ≥99% of Critical/High data assets.
• Quarterly telemetry-driven policy-refresh cycle operating with a versioned, externally-auditable changelog.
• ≥2 substantive public regulatory or standards contributions per year on AI/HAI data policy; external recognition documented.
• Zero material audit findings on AI/HAI data-governance controls in the last 12 months.

Common Pitfalls

Level 1. - Reusing the generic data-governance policy without AI-specific clauses, no rule on training-data consent basis, no archetype-specific controls, no cross-border restriction for inference providers; auditors cannot trace GDPR Art. 6 to a training corpus. - Sanction gate applies only to data sources formally proposed through data engineering, misses training datasets uploaded by researchers, retrieval stores added by engineering teams, and prompt/completion log corpora accumulating in object storage without review. - Compliance map lists frameworks but does not say which policy carries which regulation, auditors trace coverage themselves and typically conclude it is untraceable. - Gate checklist is archetype-agnostic, a training corpus and a retrieval store receive the same list, so training-corpus-specific controls (DPIA trigger assessment, Art. 6 basis, retention plan) are never actually required.

Level 2. - DPIA gate exists on paper but the DPIA is conducted after the training run begins, the finding arrives too late to influence data-minimization decisions. - Compliance evidence bundle is a folder of PDFs that only the DPO can navigate, a second reviewer cannot assemble the regulator pack without them. - Evidence staleness thresholds exist but no alert fires when they are exceeded, a Critical training corpus's legal-basis document ages past its review window and nobody notices until an audit. - Sector-specific bundles treated as "covered by the general DPA", HIPAA BAA specifics or PCI-DSS 3.4 evidence are not operationalized for the training-data assets in scope.

Level 3. - Attestation pipeline generates evidence that is technically complete but narratively thin, a regulator still needs a human to explain what the artifacts mean; the 3 BD SLO is met but a follow-up is needed. - Policy refresh is cadence-only, a quarterly ritual without real telemetry input; the changelog reads like formatting updates and Legal cannot explain which DPIA finding prompted which change. - External regulatory contributions are deadline-only comment letters rather than technical artifacts that implementing bodies use in guidance. - Contributed DPIA templates and Art. 30 schemas are published once and then go stale, external practitioners find outdated versions and stop trusting the program.

Practice Maturity Questions

Level 1. 1. Have you published and formally approved the three priority AI/HAI data policies (AI Data Use Policy, Data Acceptable Use Policy (AI), Data Intake / Sanction Gate) with archetype-specific controls, consent-basis requirements, cross-border-transfer restrictions, and a named-data-steward requirement, and is there a one-page compliance map tying each priority requirement (EU AI Act Art. 10 / Annex IV / Art. 9, GDPR Arts. 5/6/9/22/30/32/35/44–49, ISO/IEC 42001, SOC 2 CC6/CC7, sector-specific) to the specific policy that carries it? Evidence: published policy set, approval signatures, and one-page compliance map. 2. Is the sanction gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and does ≥85% of new data sources entering AI production use in the last 12 months have a gate record (100% for Critical/High)? Evidence: intake queue export reconciled against SM-Data inventory. 3. Are ≥95% of engineers and data scientists handling AI data covered by a current-year AI Data AUP acknowledgment, and does every regulated data asset in AI production use have a named data steward logged in the SM-Data inventory? Evidence: LMS attestation report and inventory column showing data stewards for regulated assets.

Level 2. 1. Have the three priority policies been extended with tier-specific addenda (per the SM-Data L2 rubric), and do Critical data assets carry DPIA gate closure, DPO and privacy-officer sign-off, HSM-rooted encryption confirmation, and legal-basis documentation before production training use, with a live compliance evidence bundle covering classification label, lineage record, legal-basis document, DPIA status, retention policy, Art. 30 record, transfer mechanism, access-controls attestation, and provider DPA status? Evidence: tier addenda, gate records showing dual sign-off, and a sample evidence bundle for a Critical asset. 2. Is the DPIA gate operational for all Critical training corpora and applicable High assets (meeting GDPR Art. 35 triggers), with 100% of Critical training corpora having a closed or accepted DPIA before production training use, and can a regulatory or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? Evidence: DPIA register and last inquiry-response log. 3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing gate artifacts treated as blocking findings, and sector-specific evidence bundles (HIPAA / PCI-DSS 3.4 / FINRA/SEC as applicable) complete for in-scope assets? Evidence: exception register, monthly review minutes, and sector-bundle completeness report.

Level 3. 1. Does a continuous attestation pipeline auto-update evidence bundles from catalog events, lineage API updates, classification-scanner findings, retention-enforcement events, and cross-border-transfer changes, with an attestation currency SLO of ≤24 hours latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High data assets continuously attested? Evidence: pipeline architecture, SLO dashboard, currency and completeness metrics. 2. Does the program operate a quarterly, telemetry-driven policy-refresh cycle (ML-Data classification trends + IM-Data incident learnings + DPIA outcome patterns + regulatory-motion tracker) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? Evidence: most recent policy changelog with rationale entries citing telemetry or regulatory source. 3. Does the program contribute ≥2 substantive public comments or standards artifacts per year on AI/HAI data-governance topics (EU AI Act Art. 10 implementing guidance, EDPB AI data-processing opinions, NIST AI RMF, ISO/IEC 42001, DAMA, sector regulators) with documented external recognition? Evidence: contribution log with publication links and recognition citations.

16. Education & Guidance (EG)

Practice Overview

Objective: Build the AI-assurance data-handler literacy every engineer and data scientist touching AI/HAI data assets needs, and the practitioner skills the smaller population performing lineage verification, classification review, DPIA composition, and data-flow security review must have, with shadow-data-in-AI awareness as the primary L1 cultural outcome.

Description: EG-Data covers two audiences. The first is the entire data-handler workforce, engineers, data scientists, ML platform engineers, and analysts who touch any of the seven AI/HAI data archetypes (training corpora, inference input streams, retrieval stores, prompt/completion log corpora, embedding stores, fine-tuning datasets, evaluation/test sets); they need data-assurance literacy covering the AI data lifecycle, how the HAI TTPs manifest in data, what the AI Data Use Policy requires, and what a correct Data Intake / Sanction Gate submission looks like. The second is the practitioner population, data stewards, DPOs and their delegates, and AppSec/AI safety reviewers performing data-flow security reviews, who need deep skills covering lineage verification, classification scanning and label propagation, consent-basis verification (GDPR Arts. 6/9), DPIA composition (Art. 35), opt-out and deletion enforcement, training-data canary insertion, embedding-store retention and inversion defense, and retrieval-source classification propagation.

Context: AI-specific data vulnerabilities are not covered by classic data-governance curricula. A data engineer who has taken a GDPR awareness course knows about lawful basis for classical database processing but will not recognize that fine-tuning a model on customer-support transcripts requires an Art. 6 compatibility assessment, a DPIA, and a no-train confirmation with the inference provider. An ML engineer pulling records into a training corpus does not know they may be creating an embedding store where user data is invertible (TM), exposing it to GDPR Art. 15/16/17 subject-access obligations the organization is not prepared to meet. A retrieval store populated from unclassified content can be the injection vector for an AGH attack against a production RAG pipeline. These risks require AI-data-specific education targeted at the people who handle the seven archetypes. Without it, shadow data in AI accumulates through routine engineering decisions, regulated data flows into training without consent review, and retrieval stores introduce data-class exposure nobody intended.

Maturity Level 1

Objective: Deliver foundational data-assurance literacy to ≥95% of the data-handler workforce and role-based practitioner training to 100% of the reviewer population, with an active shadow-data-in-AI awareness campaign.

Activities.

A) Ship data-handler workforce AI-data-assurance literacy training. A single short course (≤20 minutes) every engineer, data scientist, ML platform engineer, and analyst takes on hire and refreshes annually, tied to the AI Data AUP attestation from PC-Data L1. This is not a comprehensive data-governance course, it is the minimum AI-data-assurance literacy needed to participate in the program without creating compliance exposure. Content covers the seven AI/HAI data archetypes with concrete examples from the organization's own inventory; the AI data lifecycle, showing how data flows from source to training corpus to model to inference input to prompt/completion log to eval set, where each HAI TTP can enter, and what governance gate applies at each transition; the HAI TTPs as they apply to data, in plain language, training-data poisoning (TM, where corrupted data in a corpus corrupts model behavior), training-data leakage (TM, where corpus content surfaces in model outputs), retrieval-poisoning (AGH, where a malicious document in a retrieval store is returned as context and hijacks the model's goal), embedding inversion (TM, where embeddings are invertible to recover approximate original text including PII), and prompt injection via retrieved documents (AGH), with one concrete data-handling example per TTP matched to the relevant archetype; the AI Data Use Policy in five rules (permitted data classes per archetype, prohibited flows without named approval, consent-basis requirement before personal data enters training, cross-border-transfer restriction, disclosure obligation to the inventory); how the sanction gate works (how to submit intake, what the per-archetype artifacts checklist requires, what provisional approval means, how the amnesty path works); and a before-you-use decision aid checking whether the data source is in the inventory, whether the data class is permitted for the archetype, and whether the use requires gate approval before connecting or starting a training run. Delivery is an LMS module plus a one-page reference card pinned in engineering and data-science Slack/Teams channels plus a brief at all-hands when the program launches; no role gating.

B) Deliver role-based practitioner training for the reviewer population. A deeper module (approximately 2.5 hours) for the practitioner population only, data stewards performing classification and lineage review, DPOs and their delegates performing DPIA composition and consent-basis verification, and AppSec/AI safety reviewers performing data-flow security reviews for DR and IR. Completion is a prerequisite to approving sanction-gate intakes, not optional. Content covers lineage verification in depth (tracing a data asset from source to AI consumption, distinguishing a verifiable provenance record from a claimed one, identifying gaps, hands-on with data-catalog and lineage-API query patterns); classification scanning and label propagation (how scanners such as Macie, BigID, and Purview work and what they miss, reading a scanner report, and propagation rules so a Critical label on a source document carries to the embedding, the retrieval index, and the fine-tuning dataset derived from it); consent-basis verification under GDPR Arts. 6 and 9 (the six Art. 6 lawful bases applied to AI training and inference, and the Art. 9 special-category prohibition default with practical verification that an Art. 9(2) exception applies before approving a training-corpus intake containing health, biometric, or political-opinion data); DPIA composition under GDPR Art. 35 (when a DPIA is mandatory, how to scope one for a training corpus or retrieval store, the six DPIA sections, and how to recognize when a finding requires architectural change versus accepted residual risk); opt-out and deletion enforcement (right-to-erasure for data subjects whose data is in a training corpus, retrieval store, or embedding store, how deletion propagates or fails to propagate to a derived embedding, and when re-training or re-indexing is required); training-data canary insertion (inserting a unique fictitious record into a training corpus or fine-tuning dataset so that if it appears in model output it reveals training-data leakage, and tracking canary status in the inventory record); embedding-store retention and inversion defense (why embeddings are not anonymous, which embedding models carry documented inversion risk, retention-limit enforcement, and access-control patterns for embedding stores containing regulated data); retrieval-source classification propagation (why an unclassified retrieval store serving a Critical-tier RAG pipeline is itself a Critical-tier data asset, and how retrieval-poisoning enters through an inadequately reviewed source); the priority compliance map in practice (given an archetype and a data class, which requirements apply and where the evidence lives); and a calibration exercise scoring three sample data-asset intakes, a fine-tuning dataset from customer-support transcripts, a retrieval store indexed from internal SharePoint, and a prompt/completion log corpus from a customer-facing chatbot, independently, with an instructor-facilitated debrief on classification label, DPIA trigger determination, and SR gap list. Delivery is an instructor-led or recorded workshop plus role-specific reference job aids (one per archetype) plus a quarterly calibration session; completion is gated on sanction-gate-approval permissions.

C) Run the shadow-data-in-AI awareness campaign. An always-on communications program that makes it visible when data flows to AI without governance and easy to surface it for intake. Elements include a launch moment with the executive sponsor naming shadow data in AI, announcing the amnesty window, and publishing the sanctioned-archetype catalog with explicit framing that the program is an enabler (fast-track for Low-tier public data) not a blocker; recurring monthly short content (a new data source approved and available in the inventory, a fast-track win such as intake-to-provisional in 3 BD for a Low-tier retrieval store, an anonymized example of a data-specific TTP caught during intake review such as a training-data leakage canary trigger or a retrieval store with unclassified customer data caught before RAG deployment, an external incident reframed as "what would we find if we checked our own inventory?"); an "Is this AI data?" series calling out AI data assets silently accumulating without governance, prompt/completion log corpora growing in object storage, fine-tuning datasets assembled from ad-hoc notebooks, retrieval-store indexes built from unclassified exports; an amnesty path visibly linked from the Data AUP, the intake form, and engineering and data-science channel pins; a feedback channel for data handlers to nominate new data sources or archetype patterns for the sanctioned catalog (triaged and acknowledged within 5 BD); and DPO and data-steward micro-content for teams creating training corpora or retrieval stores covering what Art. 10 data-governance evidence the organization must maintain, what the DPIA trigger assessment requires, and what deletion capability the asset must demonstrate. Campaign channel links are tagged so attribution of intake submissions and amnesty disclosures to campaign touchpoints is tracked.

Outcome Metrics (L1).

Success Criteria.

• Workforce AI-data-assurance literacy module launched; ≥95% current-year completion sustained.
• Practitioner training launched, completion gated on gate-approval permissions, and reviewer calibration drift inside target for two consecutive quarters.
• Shadow-data-in-AI awareness campaign running with at least monthly content cadence and measurable attribution.
• DPO and data-steward micro-content deployed for every Critical or High AI data archetype active in the inventory.
• Training content owner named; content updated within 30 days of any change to policies, the archetype list, or the compliance map.

Maturity Level 2

Objective: Deepen practitioner skill through scenario-based training from real intake cases, deliver product-line-specific data-handler tracks calibrated to SM-Data L2 risk tiers, and run seasonal shadow-data-in-AI campaigns tied to model-release and data-refresh cycles.

Activities.

A) Scenario-based reviewer training from real intakes. Build a scenario library from anonymized real intakes from the organization's own queue; each scenario includes the as-submitted data-asset description, the original reviewer decisions (classification label, DPIA trigger determination, SR gaps), any reviewer disagreement, and the resolved outcome after calibration or post-launch review. Organize scenarios per archetype (training-corpus, retrieval-store, fine-tuning-dataset, embedding-store, and prompt/completion-log-corpus scenarios) and per TTP cluster (training-data poisoning, training-data leakage, retrieval-poisoning, embedding inversion, prompt injection via retrieved documents). Run paired calibration exercises in which two reviewers independently score the same scenario, with an instructor-facilitated debrief on classification-label delta, DPIA-trigger-determination delta, and SR gap list differences. Weight the curriculum to tier: Critical-tier training-corpus and fine-tuning-dataset scenarios (PII-bearing, cross-border, special-category) dominate the advanced modules; Medium/Low scenarios streamline fast-track calibration. Practitioners graduate the advanced module by running three live intakes end-to-end with a senior-reviewer shadow and producing a passing classification record, lineage review, and DPIA scoping note.

B) Product-line-specific data-handler tracks. Deliver distinct training tracks for data-handler teams in specific product lines, built on the SM-Data L2 tier rubric. The clinical AI track covers training corpora containing PHI, HIPAA minimum-necessary assessment, the GDPR Art. 9 health-data basis, DPIA composition for clinical training data, BAA verification, de-identification standards and re-identification risk, retrieval stores containing clinical notes (retrieval-poisoning risk in a clinical RAG pipeline), and embedding-store inversion risk for medical records. The fintech AI track covers training corpora containing PCI cardholder data, PCI-DSS 3.4 controls for model-input data, FINRA/SEC model-input retention obligations, the Art. 6 lawful basis for financial data at inference, retrieval stores containing customer financial data, and prompt/completion log retention for regulatory record-keeping. The developer-tool AI track covers training corpora containing source code (customer IP, trade secrets), fine-tuning datasets from code repositories (lineage verification, license compatibility), retrieval stores indexed from internal codebases (code-leakage risk via retrieval-poisoning AGH), embedding stores of code (inversion and IP-exposure risk), and prompt/completion log corpora from coding-assistant sessions. The consumer AI track covers inference input streams with end-user personal data, consent-basis verification for logged interactions, opt-out enforcement and right-to-erasure in prompt/completion log corpora, GDPR Art. 22 automated-decisioning safeguards for consumer-facing inference, and cross-border transfer risk for global user bases. Each track is paired with the SA reference pattern for the relevant archetype. Tracks are required for any team owning a Critical or High-tier data asset in the applicable product line; target ≥1 trained practitioner per data asset.

C) Seasonal, behavior-driven shadow-data-in-AI campaigns. Tie campaigns to observed shadow-data-in-AI risk windows: model-release windows (sprint-to-ship pressure leads to ad-hoc training-data pulls without gate passage), data-refresh cycles (quarterly training updates that bypass lineage review), post-external-incident moments (a public training-data leakage or retrieval-poisoning incident creates a teachable window), and hiring surges (new engineers and data scientists arrive with pre-existing habits). Each campaign carries a pre-measured behavior target (for example, "reduce ungated fine-tuning dataset uploads by 50% in Q3" or "increase retrieval-store intake submissions before model deployment by 30%") and a post-campaign measurement. Amnesty windows run alongside campaigns; disclosure volume and source are attributed to campaign channels. Campaign effectiveness is reviewed by the program sponsor, and campaigns missing behavior targets by more than 20% are redesigned.

Outcome Metrics (L2).

Success Criteria.

• Scenario library of ≥30 real-sourced scenarios across archetypes; reviewer calibration drift inside target for two consecutive quarters.
• Product-line training tracks (clinical AI, fintech AI, developer-tool AI, consumer AI) delivered; ≥1 trained practitioner per Critical/High-tier data asset.
• ≥2 behavior-driven campaigns run in the last 12 months with measured outcomes; ≥70% of campaigns hit behavior target.
• Training content refresh cadence met; ≥80% of content updated in the last 90 days.

Maturity Level 3

Objective: Operate continuous calibration at scale, externalize the AI-data-assurance curriculum and reviewer rubric as industry-shared artifacts, and contribute to emerging AI-data-handler certification pathways.

Activities.

A) Externalize the curriculum, scenario library, and reviewer rubric. Publish the workforce AI-data-assurance literacy module (learning objectives, assessment questions, reference-card template covering the seven archetypes and five data-specific TTPs), the practitioner role-based training curriculum (module outlines, per-archetype reviewer job aids, DPIA composition guide for AI training data, lineage-verification checklist, embedding-inversion risk-assessment guide), the anonymized scenario library (scenario format, per-archetype examples including the clinical, fintech, developer-tool, and consumer AI tracks, calibration debrief format), and the reviewer rubric (classification-label criteria, DPIA-trigger determination scoring, lineage-verification scoring, SR-gap-list completeness scoring) under a permissive license or as a consortium deliverable through the CSA AI Safety Initiative, the IAPP AI data-governance track, OpenSSF AI, DAMA, or an applicable sector ISAC (FS-ISAC, H-ISAC, IT-ISAC). Accept community contributions; flow changes back into internal content within 30 days. Track adoption via citations in external publications, forks, downloads, and direct adoption acknowledgment from other organizations.

B) Continuous live calibration. Run monthly calibration rounds: a current anonymized intake sampled from the program's live queue is shared with the reviewer cohort; each reviewer independently scores classification label, DPIA trigger determination, the top three SR gaps, and the primary TTP; drift is reported to the program sponsor. Individual reviewer drift is a development signal, not a performance metric, reviewers with persistent drift on specific archetype types receive targeted coaching and additional scenario exposure. Calibration results feed the scenario library directly; new scenarios drawn from intakes where calibration revealed drift are added within 30 days.

C) AI-data-handler certification contribution. Contribute to AI-data-handler and AI-assurance certification pathways as they emerge: CSA AI Safety, ISACA AI Audit / AI Risk certificates, IAPP AI data-governance certification, sector-specific ISAC credentials, the DAMA AI data-management practitioner path, and CIPP/E extensions for AI data processing. Align the organization's practitioner capstone with certification-grade rubrics where credentials exist; support reviewers pursuing external credentials. Contribute MITRE ATLAS new-technique candidates and confirmed-technique instances for data-domain observations (training-data poisoning, retrieval-poisoning, embedding inversion), a minimum of one per year where novel observations exist. Target ≥2 substantive contributions per year to industry curriculum or certification working groups on AI data-handler competency.

Outcome Metrics (L3).

Success Criteria.

• Curriculum, scenario library, and reviewer rubric published externally with documented adoption.
• Monthly live calibration operating; drift inside target for two consecutive quarters; calibration results feeding the scenario library continuously.
• ≥50% of Critical-tier data reviewers credentialed where credentials exist.
• ≥2 substantive contributions to industry certification or curriculum per year.
• ≥1 MITRE ATLAS data-domain TTP contribution or confirmation per year where novel observations exist.

Common Pitfalls

Level 1. - Workforce training covers classic GDPR data-protection awareness but not the data-specific HAI TTPs (training-data poisoning, training-data leakage, retrieval-poisoning, embedding inversion, prompt injection via retrieved documents), data handlers know about lawful basis but not how retrieval-poisoning enters through an unclassified document in a RAG index. - Practitioner training is a one-hour "intro to data governance for AI" rather than a hands-on module covering lineage verification, DPIA composition for training data, and TTP-recognition exercises against real archetype examples. - Reviewer training is optional, gate-approval permissions are granted without training completion, calibration drift is never measured, and two reviewers regularly arrive at different classification labels for the same training corpus. - Shadow-data-in-AI campaign launches once with an exec message, then goes silent, no monthly content, no amnesty attribution, no feedback channel.

Level 2. - Scenario library is built from invented examples rather than anonymized real intakes, reviewers learn the shape of a "good" intake but not the actual edge cases that surface in the organization's queue, such as an embedding store with no retention policy or a fine-tuning dataset with an unchecked Art. 9 special-category field. - Product-line tracks are optional, clinical AI teams skip the PHI/DPIA track and then produce training-corpus designs in DR that do not account for Art. 35 triggers; DR catches the gap late and at high cost. - Campaigns are launched without a pre-measured behavior target, "shadow data in AI awareness" is claimed as success without data on whether ungated fine-tuning uploads decreased or amnesty disclosures increased. - Calibration drift is measured but not acted on, reviewers with persistent drift on DPIA trigger determination never receive coaching, and the calibration exercise becomes a box-check rather than a development signal.

Level 3. - External publication without ongoing maintenance, other organizations find a stale DPIA template or outdated lineage-verification checklist and stop trusting the program; citations dry up. - Credentialing becomes performative, reviewers pursue credentials that do not map to the organization's actual tier-treatment rubric; credential acquisition is celebrated but calibration drift stays unchanged. - Live calibration becomes a gotcha rather than a development signal, reviewers learn to game the monthly exercise and improve calibration scores without improving actual gate-review quality. - Contributions to industry working groups do not loop back, what is published externally drifts from what reviewers use internally, and practitioners cite the external artifact and contradict the internal rubric.

Practice Maturity Questions

Level 1. 1. Have all engineers, data scientists, ML platform engineers, and analysts handling AI/HAI data completed a current-year AI-data-assurance literacy course covering the seven data archetypes, the five data-specific HAI TTPs (training-data poisoning, training-data leakage, retrieval-poisoning, embedding inversion, prompt injection via retrieved documents), the AI Data Use Policy rules, and the sanction-gate intake process, with ≥95% completion and content updated within 30 days of any policy or archetype change? Evidence: LMS completion report, content change-log, and the most recent literacy module. 2. Has the practitioner population (data stewards, DPOs/delegates, AppSec/AI safety reviewers) completed role-based training covering lineage verification, classification scanning and label propagation, consent-basis verification (GDPR Arts. 6/9), DPIA composition (Art. 35), opt-out and deletion enforcement, training-data canary insertion, embedding-store retention and inversion defense, and retrieval-source classification propagation, with completion gated on gate-approval permissions and calibration drift ≤1 classification-tier step and ≤1 DPIA trigger disagreement per sample for two consecutive quarters? Evidence: practitioner curriculum, permission-gating record, and calibration-exercise results. 3. Is a shadow-data-in-AI awareness campaign running with at least monthly content, a visible amnesty path linked from the Data AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels, with disclosures rising in Q1–Q2 after launch then declining as the sanctioned-archetype catalog grows? Evidence: campaign content calendar, channel-attribution report, and amnesty disclosure trend.

Level 2. 1. Is there a scenario library of ≥30 anonymized real intake cases powering practitioner training across the organization's in-scope data archetypes, with paired calibration exercises showing Critical-tier drift ≤1 classification-tier step and ≤0 DPIA trigger disagreements per sample for two consecutive quarters? Evidence: scenario library index and quarterly Critical-tier calibration drift report. 2. Have product-line-specific data-handler tracks (clinical AI, fintech AI, developer-tool AI, consumer AI, or equivalent for the organization's product mix) been delivered to ≥1 practitioner per Critical/High-tier data asset, with team-level training coverage tracked in the SM-Data inventory? Evidence: track rosters reconciled against the inventory's Critical/High asset list. 3. Are shadow-data-in-AI campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days? Evidence: campaign plans with pre/post measurements and content-refresh changelog.

Level 3. 1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CSA AI Safety Initiative, IAPP AI data-governance track, OpenSSF AI, DAMA, or sector ISAC) with documented adoption, citations, forks, or direct acknowledgment, and do contributions loop back into internal content within 30 days? Evidence: external publication links, adoption telemetry, and internal update changelog. 2. Is a monthly live calibration cadence operating (anonymized intake from the live queue, independent reviewer scoring, drift reported to the sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier data reviewers hold an external AI-assurance or AI-data-governance credential where one exists? Evidence: calibration log, scenario-library update trail, and credential registry. 3. Does the program contribute ≥2 substantive artifacts per year to industry AI-data-handler certification or curriculum working groups, and ≥1 MITRE ATLAS data-domain TTP contribution or confirmation per year (training-data poisoning, retrieval-poisoning, or embedding inversion) where novel observations exist? Evidence: contribution log with acceptance confirmations and the ATLAS submission record.

17. Threat Assessment (TA)

Practice Overview

Objective: Build and maintain a reusable threat library for the data flowing into and out of the AI/HAI systems the organization governs, one archetype-level threat model per data-asset type, so every data asset entering or produced by an AI system carries a documented threat view before it is ingested, routed, logged, or published.

Description: TA-Data catalogs the threats specific to AI/HAI data assets the organization ingests, processes, stores, or emits, not generic database or data-lake threats, but the failure modes specific to AI's fuel and exhaust. At L1 the library covers one threat model per data archetype, training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set, mapped to HAIAMM's HAI-specific TTPs (EA, AGH, TM, RA), to MITRE ATLAS tactics (TA0001–TA0014) and data-specific techniques (AML.T0010 ML Supply Chain Compromise, AML.T0019 Publish Poisoned Datasets, AML.T0020 Poison Training Data, AML.T0024 Exfiltration via ML Inference API, AML.T0025 Exfiltration via Cyber Means, AML.T0048, AML.T0051 LLM Prompt Injection), and to the OWASP LLM Top 10. Each data asset registered in the SM inventory generates a threat snapshot by pulling the archetype model and adding asset-specific deltas. L2 layers per-asset deep models for Critical-tier data assets and red-teams the library quarterly. L3 automates library maintenance from telemetry and external feeds, and contributes discovered TTPs back to MITRE ATLAS, AVID, and OWASP.

Context: Classic data-security threat modeling was not designed to enumerate AI-specific data failure modes, training-data poisoning that degrades model behavior, embedding inversion that reconstructs source text from vector representations, indirect prompt injection delivered through a retrieved document, evaluation-set contamination that invalidates safety benchmarks, prompt/completion-log leakage that exposes accumulated user personal data. These are first-party data risks owned by the teams that ingest, curate, and serve the data that feeds AI systems. TA-Data closes the gap by making data-asset-specific threats a first-class library that threat modelers pull from at every intake, and by tying every archetype threat to a specific ATLAS technique so the walk from attacker capability to data-asset exposure is concrete rather than narrative.

Maturity Level 1

Objective: Build the AI/HAI data archetype threat library, integrate a threat snapshot into every data-asset intake, and ensure every data asset's threat surface is documented before it enters an AI pipeline.

Activities.

A) Build the AI/HAI data archetype threat library. Author one threat model per AI/HAI data archetype. Each is concise (target two pages), explicitly scoped to data assets that flow into or out of AI/HAI systems, and maps threats to HAI TTPs, ATLAS tactic and technique IDs, OWASP LLM Top 10 references, and the PC-Data priority compliance map. Archetypes to cover: training corpus / training dataset, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, and evaluation/test set. The training-corpus and fine-tuning-dataset models cover training-data poisoning that degrades accuracy or backdoors the model (AML.T0020 Poison Training Data, HAI-TTP RA), poisoned upstream public datasets (AML.T0019 Publish Poisoned Datasets, ATLAS TA0002 Resource Development), pipeline supply-chain compromise of ingestion scripts and labeling vendors (AML.T0010 ML Supply Chain Compromise, ATLAS TA0003 Initial Access), unconsented data inclusion outside the original GDPR Art. 6 lawful basis, regulated-data memorization extractable via targeted generation (ATLAS TA0011 Exfiltration; OWASP LLM06), label-flip attacks on safety-critical classes, and backdoor-trigger insertion. The inference-input-stream model covers direct prompt injection overriding system instructions (AML.T0051 LLM Prompt Injection, HAI-TTP AGH, OWASP LLM01), abuse and denial-of-inference (ATLAS TA0014 Impact, OWASP LLM10), regulated-data leakage to vendor LLMs via prompts crossing an organizational boundary without a documented transfer mechanism (GDPR Arts. 28, 44–49), and sensitive-information disclosure including system-prompt extraction (OWASP LLM07). The retrieval-store model covers retrieval poisoning (AML.T0020, HAI-TTP AGH), corpus exfiltration via crafted queries (AML.T0024 Exfiltration via ML Inference API), classification-label bypass returning regulated content to lower-privilege consumers, and indirect prompt injection via retrieved content (AML.T0051, HAI-TTP AGH). The prompt/completion-log-corpus model covers retention-policy violation (GDPR Art. 5(1)(e)), regulated-data persistence in unredacted logs (GDPR Arts. 32, 35), unauthorized log export (AML.T0025 Exfiltration via Cyber Means), and log-mining for training without a renewed consent basis. The embedding-store model covers embedding inversion reconstructing source text (AML.T0024), nearest-neighbor extraction enumerating the corpus item by item (HAI-TTP TM), and retrieval poisoning at the embedding layer (AML.T0020, HAI-TTP AGH). The evaluation/test-set model covers eval contamination that invalidates benchmarks (AML.T0048), eval gaming that inflates scores against the specific test set (HAI-TTP RA, ATLAS TA0008 Defense Evasion), and eval suppression that promotes models without safety evidence. Each archetype model documents the full ATLAS tactic walk (TA0001 Reconnaissance through TA0014 Impact) with techniques selected or excluded with rationale, cross-references the OWASP LLM Top 10, and tags each threat to the PC-Data priority compliance item it activates (GDPR Arts. 6, 9, 17, 22, 28, 32, 35, 44–49; EU AI Act Arts. 10, 26; ISO/IEC 42001 AIMS data controls). Owner: named TA-Data library steward; cadence: reviewed quarterly; versioned in a single location linked from every SM inventory record.

B) Produce a per-intake threat snapshot for every SM data-asset registration. Bind TA into the SM intake flow, every new data-asset registration emits a threat snapshot before the asset is approved for use in an AI pipeline. Snapshot contents (designed to fit one screen): which archetype(s) apply, an asset may be composite, for example prompt/completion logs repurposed as fine-tuning data are both a prompt/completion log corpus and a fine-tuning dataset; asset-specific deltas over the archetype model covering data classification tier, lineage and provenance status, volume and criticality, cross-border flows and applicable transfer mechanisms, decision-affecting use, and subject-access-rights exposure; top-five threats for this asset each with HAI TTP tag, ATLAS tactic and technique ID where applicable, OWASP reference, and compliance linkage; controls already evident from the existing pipeline or architecture vs. gaps for SR/SA follow-up; reviewer name, date, and expiry, re-snapshot on a new data source, a classification change, a pipeline scope change, or a material volume change. Time target: one business day per intake with the library available. Most threat content comes pre-written in the archetype model; the reviewer adapts rather than invents.

C) Author the shadow-data-for-AI threat view. Unsanctioned data-sharing with AI services, developers pasting production data into consumer GenAI tools, automated pipelines routing regulated data to vendor LLMs without a DPA, canary-tagged datasets flowing to unapproved retrieval stores, has its own threat surface distinct from sanctioned data assets. The shadow-data-for-AI threat document covers entry vectors (developers submitting production PII to consumer GenAI, automated pipelines calling LLM APIs without no-train verification, canary-tagged datasets flowing to unapproved stores, prompt/completion logs exported for analysis without consent review); elevated threats for shadow data (no threat snapshot, no SR requirements pack, no documented transfer mechanism, no data processor agreement in place, GDPR Art. 28 obligations unmet); specific failure modes (regulated PII reaching a vendor LLM with training enabled, health data submitted without an Art. 9 special-category condition documented, customer data flowing cross-border without an adequacy decision or SCC in place); and detections available at L1 from SM discovery sources (DLP signals on outbound calls to AI provider domains, egress telemetry for LLM API calls from data-pipeline infrastructure, canary-document detection in external AI completions). Output: a "Shadow Data for AI, Threat View" one-pager reviewed by the program sponsor and feeding the ML-Data detection backlog and the IM-Data triage playbook.

Outcome Metrics (L1).

Success Criteria.

• Seven archetype threat models published (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), each tagged to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs and data-specific technique IDs (AML.T0010, T0019, T0020, T0024, T0025, T0048, T0051 where applicable), OWASP LLM Top 10 references, and the PC-Data priority compliance map.
• Threat snapshot gate live in the SM intake flow, 100% of newly approved AI/HAI data assets in the last 90 days have a snapshot attached before pipeline approval is issued.
• Shadow-data-for-AI threat view published, reviewed by the program sponsor, and feeding the ML-Data detection backlog and IM-Data triage playbook.
• Named library steward and quarterly refresh cadence operating.
• ≥90% of active AI/HAI data assets in the inventory carry a current-year snapshot.

Maturity Level 2

Objective: Layer per-asset deep threat models on top of archetype snapshots for Critical-tier data assets, integrate external AI-data-attack threat intelligence, and red-team the threat library quarterly against real data pipelines.

Activities.

A) Per-asset deep threat modeling for Critical-tier data assets. For every Critical-tier data asset in the SM inventory, produce a full per-asset threat model that goes beyond the archetype snapshot. Coverage: attack trees beyond the archetype snapshot, asset-specific lineage and provenance chain with each link's compromise surface, specific regulatory data classes present with exposure-consequence analysis, specific cross-border flows with transfer-mechanism gaps, and the specific downstream AI systems that consume the asset with the blast radius of each threat; an abuse-case catalog with named adversary archetypes (external attacker, malicious insider, compromised data vendor, compromised annotation/labeling platform, upstream supply-chain compromise) and concrete attack narratives for this specific data asset; a compliance-duty mapping covering GDPR Art. 32 security requirements, Art. 35 DPIA triggers, EU AI Act Art. 10 training-data requirements, and sector obligations mapped to the threat-control chain specific to this asset; and a full ATLAS tactic walk for the asset with technique-level specificity across all 14 tactics, exclusions explicit with rationale. High-tier data assets receive archetype snapshot plus asset-specific deltas and an ATLAS full tactic walk; no High-tier asset remains on archetype-only. Refresh cadence: Critical semi-annual plus change-driven on a new data source, classification change, pipeline scope change, or material volume change; High annual plus change-driven.

B) External AI-data-attack threat intelligence integration. Subscribe to and operationalize MITRE ATLAS updates, new technique additions, especially data-attack techniques (AML.T0010, T0019, T0020, T0024, T0025, and any new data-specific entries); AVID new entries for data-attack techniques relevant to the org's data archetypes; OWASP LLM Top 10 and Agentic Top 10 revisions addressing data handling, prompt leakage, and training-data risks; academic adversarial-ML venues (IEEE S&P, USENIX Security, NeurIPS ML Safety) for early signal on novel embedding inversion, membership inference, and corpus poisoning attack classes; and sector ISAC AI working groups for operationally-observed data-attack patterns. A quarterly triage cadence determines which new items change the archetype library, change per-asset models, or require updates to dependent SR or ST artifacts. Changes are change-logged and reviewed by the library steward and the IM backlog owner. Intel-to-library update lead time targets 30 days on Critical-impact items.

C) Red-team the threat library itself. Each quarter, ST-Data runs an adversarial probe against an in-scope AI/HAI data pipeline using only the threat scenarios documented in the library for that archetype. Threats the exercise identifies that are not in the library are library gaps, not passing findings. Gap closure is a governance activity: every gap becomes a ticket with a named owner and an expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days. The gap rate per quarter trends down as the library matures. Gaps are also reviewed for SR and ST update implications, a threat absent from the library is also likely absent from a requirement and a test.

Outcome Metrics (L2).

Success Criteria.

• Per-asset deep threat models live for 100% of Critical-tier and ≥90% of High-tier data assets, with refresh cadences (Critical semi-annual, High annual) met.
• External threat intel integrated with quarterly triage and a documented change-log; intel-to-library update ≤30 days on Critical-impact items.
• Quarterly red-team-the-library exercise operating; every gap carries a named owner and expiry date; Critical-tier gaps close within 30 days, High-tier within 60 days.

Maturity Level 3

Objective: Automate threat-library maintenance from telemetry and external feeds, and contribute discovered AI/HAI data-attack TTPs back to MITRE ATLAS, AVID, and OWASP.

Activities.

A) Telemetry-driven library updates. Wire ML-Data detection alerts, IM-Data post-incident review records, external feeds (ATLAS technique additions, AVID new entries, OWASP LLM/Agentic Top 10 revision drafts, sector-ISAC AI advisories), and weekly academic publication scanning into an auto-proposal pipeline. ML-Data alert patterns that do not map to any existing library entry are surfaced as candidate new threats; an IM-Data incident's ATLAS tactic walk is auto-ingested into a structured threat update. Human curators approve, reject, or defer each auto-proposal. The change-log is machine-readable; downstream SR and ST artifacts subscribe to the change feed and receive update-required notifications when a threat they reference changes. Target: ≥60% of library changes auto-proposed; lead time from signal to update ≤14 days.

B) Industry contribution. Contribute emerging first-party-observed TTPs, data-attack patterns discovered in own-operated AI data pipelines, including novel corpus poisoning mechanics, new embedding inversion approaches, and supply-chain compromise patterns specific to dataset-curation tooling, to MITRE ATLAS following ATLAS evidence-and-provenance requirements; to OWASP LLM Top 10 and Agentic Top 10 revision cycles with real-world telemetry evidence focused on data-handling, training-data, and retrieval-store entries; to AVID via structured disclosure submissions (coordinated disclosure where third-party components are involved); and to NIST AI RMF Playbook successor editions with practitioner input. Target: at least four substantive contributions per year, quality-graded and legally vetted before submission, every contribution anonymized.

C) Shared threat-model artifacts. Publish anonymized data archetype threat models (scrubbed of org-specific data-source names and classification details) under a permissive license for peer-org adoption. Host or co-host at least one industry tabletop per year tied to the library, an ATLAS practitioner table, an OWASP AI chapter, or a sector ISAC AI working group.

Outcome Metrics (L3).

Success Criteria.

• Library auto-update pipeline operating with ≤14-day lead time from signal to update; ≥60% of changes auto-proposed; change-log machine-readable and consumed by downstream SR and ST practices.
• ≥4 industry contributions per year; ≥2 recognized in external artifacts (ATLAS merge, AVID entry, OWASP revision).
• Anonymized archetype threat models published under a permissive license with tracked peer-org adoption.
• Industry tabletop hosted or co-hosted in the last 12 months.

Common Pitfalls

Level 1. - Threat models catalog generic data-security risks (SQL injection, misconfigured object storage) rather than AI/HAI-specific data failure modes, the library covers what any data-security program addresses rather than what is unique to AI data assets. - Archetype library covers training corpora and fine-tuning datasets but omits retrieval stores, embedding stores, and prompt/completion log corpora, the three archetypes most directly exposed to indirect prompt injection and embedding inversion remain without threat models. - Threat snapshot is completed at ingestion time and never refreshed, a training corpus that gains new regulated-data classes or a retrieval store that adds indexed sources does not trigger a re-snapshot, and the snapshot drifts from the actual asset within weeks. - ATLAS tactic walk is performed for narrative completeness but no technique IDs (AML.T0019, T0020, T0024, T0025, T0010) are assigned, the walk produces prose, not structured references that ST and IR can act on.

Level 2. - "Per-asset deep model" is the archetype snapshot with the asset name swapped in, no asset-specific lineage analysis, no data-class exposure-consequence analysis, no cross-border flow gap enumeration; the depth is cosmetic. - External intel is subscribed but never triaged, ATLAS update notifications accumulate unread; the library is frozen at L1 publication while new data-attack techniques are published. - Red-team-the-library exercise is a threat-hunting session that adds entries to a finding log but never cross-checks findings against the library, gaps are never surfaced because the comparison was never made. - Deep modeling stops at Critical tier; High-tier data assets remain on archetype-only snapshots despite carrying regulated personal data or feeding decision-affecting models.

Level 3. - Auto-proposal pipeline accepts signals without curation, false-positive ML-Data detections pollute the library with phantom threats; downstream SR and ST artifacts generate incorrect requirements and tests. - Contributions to MITRE/AVID/OWASP are observer submissions, comments, conference talks, rather than technical artifacts with evidence that produce substantive change. - Published anonymized archetype models are not maintained after release, external adopters build on a stale version while the internal library has advanced; the divergence becomes visible when discrepancies are cited publicly. - Telemetry-driven update loop fires on every minor pipeline configuration change; data engineering teams disable the telemetry feed to stop the noise rather than tune signal sensitivity.

Practice Maturity Questions

Level 1. 1. Are there published, versioned threat models for all seven AI/HAI data archetypes, training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set, each mapping archetype threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs and data-specific technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable), OWASP LLM Top 10 references, and PC-Data compliance items, with a named library steward and a documented quarterly refresh cadence? Evidence: TA library with seven versioned archetype documents and a named owner record. 2. Does every AI/HAI data asset entering the SM inventory receive a threat snapshot (delivered within one business day of intake) that documents the applicable archetype(s), asset-specific deltas (classification, lineage, cross-border flows, decision-affecting use, subject-access-rights exposure), top-5 threats with HAI TTP tags and ATLAS tactic/technique IDs, and gaps for SR/SA follow-up, with 100% of newly approved assets carrying a snapshot in the last 90 days? Evidence: SM intake tickets with snapshot attachments dated within intake SLA. 3. Is there a published shadow-data-for-AI threat view, reviewed by the program sponsor in the last 12 months, that documents entry vectors, elevated threat scenarios for unsanctioned data-sharing with AI services, and the specific detections used to surface them? Evidence: Dated threat view document with program-sponsor review record and links to ML-Data and IM-Data backlogs.

Level 2. 1. Does every Critical-tier AI/HAI data asset have a current-year per-asset deep threat model covering asset-specific attack trees, an abuse-case catalog by adversary archetype, compliance-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates on new data sources, classification changes, or pipeline scope changes? Evidence: Per-asset threat model documents dated within cycle, with change-driven update records. 2. Is external AI-data-attack threat intel (MITRE ATLAS updates including AML.T0019/T0020/T0024/T0025/T0010, AVID, OWASP LLM Top 10 revisions, sector ISACs, academic adversarial-ML venues) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? Evidence: Quarterly triage meeting records and change-log entries with signal-to-update timestamps. 3. Do you run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI data pipeline using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and expiry date, and Critical gaps closing within 30 days? Evidence: Quarterly exercise artifacts with gap register showing owner assignments and closure dates.

Level 3. 1. Does the threat library auto-update from telemetry (ML-Data detections, IM-Data incidents) and external feeds (ATLAS, AVID, OWASP, academic) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? Evidence: Pipeline telemetry showing proposal rate and lead-time distribution; SR/ST subscription confirmation. 2. Does the program contribute at least four substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / OWASP LLM/Agentic Top 10, with at least two externally recognized in published advisory or standard revisions? Evidence: Contribution log with external recognition citations. 3. Are anonymized data archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year tied to the library? Evidence: License artifact, adoption tracking data, tabletop event record.

18. Security Requirements (SR)

Practice Overview

Objective: Translate the threats from TA-Data and the policies from PC-Data into a reusable Requirements Pack for the AI/HAI data assets the organization governs, a base set plus per-archetype deltas, so every data asset entering or produced by an AI pipeline carries a testable Requirements-Evidence Map rather than a blank slate.

Description: SR-Data authors a small, archetype-keyed AI/HAI Data Requirements Pack: one base requirement set that applies to every data asset, plus per-archetype deltas for training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, and evaluation/test set. Each requirement is stated as a testable condition, either a measurable SLA or a binary evidence condition, not a narrative aspiration. Every data asset reaching SM intake carries a Requirements-Evidence Map (REM) linking each applicable pack requirement to current evidence, accepted gaps (with a named owner and expiry date), and compensating controls. Downstream practices, SA, DR, IR, ST, inherit the REM rather than re-deriving requirements per asset.

Context: Without a shared requirements pack, each data-asset intake, pipeline design review, and implementation review invents the acceptance bar from scratch. A training corpus and a retrieval store receive inconsistent review. GDPR Art. 6 lawful basis, Art. 28 processor obligations, Art. 35 DPIA triggers, EU AI Act Art. 10 training-data quality requirements, and cross-border transfer mechanisms under Arts. 44–49 are not consistently verified because there is no shared traceability from regulation to requirement to evidence artifact. SR-Data closes that gap with the minimum viable pack, not a checklist of 60 items, but the requirements that matter for every AI/HAI data asset the org uses, plus archetype-specific additions for training corpora, retrieval stores, embedding stores, fine-tuning datasets, and prompt/completion logs.

Maturity Level 1

Objective: Publish the AI/HAI Data Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every data asset entering an AI pipeline.

Activities.

A) Author the base AI/HAI Data Requirements Pack. The base pack applies to every AI/HAI data asset the org uses in an AI system, regardless of archetype. Keep it to 20 or fewer base requirements at L1. Each requirement has an ID, a statement, a rationale (threat tag from TA-Data and compliance tag from PC-Data), an evidence source, a test method, and an acceptance criterion. Minimum base categories: classification and labeling, every data asset has a documented Critical/High/Medium/Low classification label before it is approved for use in any AI system, labels propagate through pipelines, and downstream consumers honor them and do not process the asset beyond its classification scope; consent and lawful basis, a documented GDPR Art. 6 lawful basis, an Art. 9 special-category condition documented where applicable (health, biometric, ethnic-origin data), consent verification before personal data is included in training or fine-tuning, and a new lawful-basis assessment for any re-use of data for a secondary AI purpose such as using inference logs as fine-tuning data; lineage and provenance, a documented source and chain-of-custody from origin to AI-system entry, lineage metadata stored with the asset record, and every transformation or curation step recorded; retention, a retention policy defined per archetype and per classification, enforced by automated policy rather than manual cleanup, with assets past retention purged or anonymized and DSAR deletion obligations fulfillable within the statutory period; cross-border flows, a GDPR Arts. 44–49 transfer mechanism (adequacy decision, SCC, BCR, or Art. 49 derogation) documented for every cross-border flow involving personal data and recorded in the asset's REM; encryption, encryption at rest with documented key management, encryption in transit (TLS 1.2+), and a documented and enforced key-rotation schedule; access control, RBAC plus classification-aware authorization scoped to the minimum required for the stated AI use case, a service-principal model for pipeline access, an audit log of every read/write/export/delete event, and no unauthenticated access to any AI data asset; no-train assertions, for inference inputs or prompt/completion logs sent to vendor LLM APIs, the no-train setting confirmed at the admin-console level and not trusted from contract text alone, re-verified on a documented cadence, with a failed re-verification routing to IM as a Critical finding; and Data Subject Access Rights, the capability to locate a specific subject's personal data within training datasets and prompt/completion logs, to respond within GDPR Arts. 15–21 statutory timelines, and to execute Art. 17 deletion requests with documented propagation to downstream model-training teams. Every base requirement is tagged to at least one TA-Data archetype threat and at least one item from the PC-Data priority compliance map.

B) Author per-archetype requirement deltas. Each archetype carries a short delta (typically three to eight additional requirements) reflecting the threat-specific and regulatory obligations from TA-Data's archetype threat models. The training-corpus delta requires a data-class pre-flight check (no regulated PII, PHI, or customer-confidential data enters training without a documented Art. 6 lawful basis and, where applicable, an Art. 9 condition), a DPIA where large-scale processing of personal data triggers Art. 35, a poisoned-data detection scan at ingest, and opt-out enforcement excluding subjects who have exercised Art. 21 or Art. 17 rights with documented propagation to downstream training jobs. The inference-input-stream delta requires PII redaction at the input edge unless the DPA explicitly covers the data class, classification-gated routing keeping Art. 9 special-category data away from endpoints whose no-train status is unverified, and per-tenant context isolation. The retrieval-store delta requires a classification label on every document at index time, per-tenant retrieval isolation, treatment of retrieved content as untrusted, provenance metadata on every retrieved chunk, and access control on the underlying vector index. The prompt/completion-log-corpus delta requires PII redaction at log-write time, a retention schedule aligned to the GDPR Art. 5(1)(e) storage-limitation principle, controlled DSAR-capable export, per-tenant partitioning, and a bar on using logs as fine-tuning data without a new lawful-basis assessment. The embedding-store delta requires classification-aware RBAC on raw embeddings, inversion-defense controls (clipping or noise) for sensitive content, a retrieval-only access model, and per-tenant namespace partitioning. The fine-tuning-dataset delta requires DPIA-gated curation, consent-tracked subject inclusion, opt-out enforcement before fine-tuning commences, and recorded lineage from dataset version to training-job event. The evaluation/test-set delta requires isolation from training pipelines, a contamination-prevention deduplication gate confirming no overlap with the training corpus, reproducibility metadata, and access restricted to named evaluation personnel.

C) Wire the pack into the SM intake gate and produce a REM per asset. Every data asset approved for use in an AI pipeline carries a REM. Each applicable pack requirement (base plus archetype delta) is marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable with justification. Each Met row cites specific evidence: a classification label in the data catalog, a consent-basis record, a lineage record, a DPA clause citation, an admin-console screenshot, an audit-log sample, a DPIA reference, or a test result reference. Each Gap-accepted row names a compensating control, a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor. The REM is stored with the SM inventory record for the data asset and linked from the intake ticket. Material changes, a new data source added to a corpus, a classification change, a new cross-border flow, a new downstream AI use, trigger a REM re-review before the change is approved.

Outcome Metrics (L1).

Success Criteria.

• Base pack plus seven archetype deltas published, tagged to TA-Data threats and the PC-Data priority compliance map.
• 100% of new AI/HAI data assets approved for AI pipeline use in the last 90 days have a REM on file.
• ≥90% of active AI/HAI data assets in the SM inventory carry a current-year REM.
• Named pack owner and quarterly refresh cadence operating.
• Accepted-gap backlog tracked with every gap carrying a named owner and re-review date; median age inside ≤90 days.

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; and validate REM evidence continuously for Critical and High-tier data assets.

Activities.

A) Quantitative and binary requirement pack. For every requirement in the base pack and each archetype delta, replace qualitative language with measurable or binary conditions. Encryption at rest: binary, classification-tier-appropriate encryption confirmed; key rotation ≤365 days for Critical-tier and ≤730 days for High-tier; last rotation date on file with zero overdue keys. No-train assertion: binary, the vendor API admin-console setting "Training on your data" confirmed OFF with a dated screenshot on file, re-verification scheduled quarterly, and the last re-verification result on file. DSAR deletion capability: SLA, data-subject deletion requests fulfilled within 30 calendar days for standard requests and 60 days for complex training-corpus cases, with the last DSAR test result on file and zero requests past the statutory deadline in the last 12 months. Retention enforcement: binary, automated retention policy applied, assets past retention date confirmed purged or anonymized, last enforcement-run date and record count on file, zero overdue assets. Cross-border transfer mechanism: binary, an SCC, adequacy decision, or BCR documented for each cross-border personal-data flow, mechanism currency re-confirmed within the last 12 months, zero flows without a documented mechanism. DPIA completion for Critical-tier personal-data assets: binary, a DPIA completed and signed by the DPO before the asset was approved, reviewed within the last 12 months or on material change, with no Critical-tier personal-data asset active without a current DPIA. Access-control audit log: SLA, audit log retained ≥24 months for Critical-tier and ≥12 months for High-tier, exportable within 5 business days of a regulator or DSAR request, with no unauthenticated access events in the last 90 days.

B) Per-tier requirement depth. Publish a per-tier pack overlay aligned to the SM L2 tier-treatment matrix for data assets, calibrated to the SM L2 risk-tier rubric (classification, lineage/provenance, volume/criticality, cross-border flows, training-vs-inference use, decision-affecting use, subject-access-rights exposure). Critical tier: full base pack and all applicable archetype deltas; a DPIA mandatory as a binary gate; executive sign-off by a named DPO or Privacy Officer on the completed REM before pipeline approval is issued; a full REM with no rows left blank; an accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; re-validation of all Critical-tier REM evidence quarterly; and an SR-Software cross-reference required for every Software-domain artifact that consumes the asset. High tier: full base pack and applicable archetype deltas; a DPIA where Art. 35 triggers apply; an accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually. Medium tier: base pack and applicable archetype deltas; a DPIA recommended unless Art. 35 triggers apply; an accepted-gap aging SLA of 120 days; re-validation annually. Low tier: base pack only; a fast-track process with abbreviated evidence citations acceptable; re-validation at annual review.

C) Continuous REM-evidence validation and cross-domain linkage. Critical-tier REMs are re-validated quarterly; High-tier semi-annually. Validation method: select a stratified sample of REM rows per asset, at least one row per base category, and verify each cited evidence artifact against current observable reality: the classification label confirmed against the current data-catalog entry, the no-train setting re-confirmed against admin-console state and contract currency, retention re-run with zero overdue assets confirmed, RBAC assignments confirmed against stated scope with no unauthenticated access events in the audit log, DPIA currency confirmed within the last 12 months or since the last material change, and the cross-border flow mechanism confirmed current with no new flows added without a mechanism. SR-Software cross-reference: for every Software-domain artifact (LLM-integrated app, agent, RAG pipeline, fine-tuning/training workload) that consumes a data asset, the SR-Software REM for that artifact references the SR-Data REM for the data asset, and a change in the data asset's classification or compliance status triggers a flag on the consuming Software artifact's REM. Validation deltas, a row claimed Met but failing re-validation, are routed to IM-Data as findings with severity tags and remediation SLAs matching the asset's tier. Accepted-gap aging is reviewed monthly; gaps approaching the escalation threshold notify the named owner before the deadline.

Outcome Metrics (L2).

Success Criteria.

• 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative language removed.
• ≥95% of Critical-tier REMs re-validated against observed reality in the last 90 days; validation deltas routed to IM-Data.
• No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor.
• 100% of Critical-tier personal-data assets carry a completed and current DPIA.
• Per-tier pack overlay published and enforced; SR-Software cross-reference operating for Critical/High Software artifacts.

Maturity Level 3

Objective: Express the AI/HAI Data Requirements Pack as a machine-readable artifact, automate REM-evidence validation from pipeline attestation and runtime signals, and contribute to industry-standard AI data security requirements bodies.

Activities.

A) Machine-readable pack and pipeline attestation. Express the Requirements Pack (base plus archetype deltas) in a structured schema, JSON or YAML, where each requirement has an ID, a machine-readable evidence type (data-catalog query, config-check, audit-log query, test-result-reference, or manual-attestation), an acceptance predicate, and a tier applicability field. At pipeline-deploy time for Critical and High-tier data assets: automated checks run against the asset's REM, classification label confirmed in the data catalog, encryption-at-rest confirmed for the target storage, no-train setting confirmed via vendor admin-console API, access-control RBAC confirmed against stated scope, retention policy confirmed active, and cross-border flow mechanism confirmed current; checks that pass write a signed attestation to the REM record; checks that fail block the pipeline deploy for Critical-tier assets and emit a warning with auto-routing of a finding to IM-Data for High-tier; manual-attestation rows (DPIA sign-off, consent-basis narrative) are prompted for re-confirmation at deploy time if the asset has changed since the last manual review.

B) Automated REM-evidence validation from runtime signals. Subscribe the REM validation pipeline to ML-Data monitoring (access-audit log completeness signal, no-train re-verification output, retention-enforcement run results), IM-Data incident records (post-incident reviews that touch a pack requirement auto-flag the relevant REM rows for re-validation), SM inventory change events (a tier upgrade auto-triggers a full REM re-validation run under the new tier's requirements depth), and GDPR supervisory authority guidance updates and adequacy-decision status changes (auto-flagging cross-border-flow REM rows when an adequacy decision is suspended or a new SCC version is published). Human review is reserved for novel requirement types not yet in the structured schema, accepted-gap escalations, DPIA sign-off, and complex DSAR cases.

C) Standards contribution. Contribute the machine-readable requirement schema and the REM schema to the OpenSSF AI working group; submit practitioner input on data-handling, training-data, and retrieval-store requirement categories and evidence conditions to OWASP LLM and Agentic Top 10 revision cycles; contribute the data-archetype REM schema as a referenceable AI data governance artifact to DAMA International and EDM Council AI Data Governance working groups; and submit practitioner commentary grounded in REM experience on MEASURE and MANAGE function requirement language for the data domain to NIST AI RMF Playbook successor editions. Target: at least two substantive contributions per year, legally vetted and anonymized.

Outcome Metrics (L3).

Success Criteria.

• Machine-readable pack schema published; ≥80% of Critical-tier REM requirements have pipeline attestation at deploy time.
• ≥70% of REM evidence rows auto-validated; human review reserved for exceptions and novel clauses.
• Zero Critical-tier data assets entering AI pipelines with a failing REM check; pipeline telemetry confirms enforcement.
• Pack and REM schema published under a permissive license with tracked external adoption.
• ≥2 substantive industry-standard contributions per year.

Common Pitfalls

Level 1. - The base pack is authored with 40+ requirements at L1, reviewers cannot complete a REM in three business days and begin skipping rows, producing REMs that are structurally complete but evidentially hollow. - Per-archetype deltas are written but never wired into the intake process, every data asset gets the base pack only; fine-tuning-dataset DPIA requirements and retrieval-store injection-defense requirements are missed on every intake for those archetypes. - Pack requirements reference GDPR articles on paper but cite no actual evidence artifact, REM rows reference "GDPR Art. 6 lawful basis" but no consent record, DPA clause, or legitimate-interest assessment is cited; the traceability is nominal. - Material-change trigger is not defined, new data sources added to training corpora, new cross-border flows, and new downstream AI uses proceed without triggering a REM re-review; the REM drifts from the actual asset within weeks of approval.

Level 2. - Quantitative conditions are set but never verified against actual system state, retention is specified as "12 months" in the pack but is never confirmed against actual storage retention settings; the SLA exists on paper only. - REM re-validation is scheduled quarterly for Critical-tier but samples only what data engineers self-report, data-catalog state, audit-log entries, admin-console no-train settings, and DPIA currency are never cross-referenced. - The Critical-tier DPIA gate exists in policy but no DPIA has ever blocked a pipeline approval, the requirement is written but the social and tooling mechanism to enforce the gate is absent. - Per-tier differentiation is documented in the pack overlay but not enforced at intake, Low-tier assets receive the same review depth as Critical-tier because the intake routing logic was never built.

Level 3. - The machine-readable pack schema is published but the organization stops maintaining the public version, the external artifact becomes stale while the internal version evolves; external adopters build on outdated requirements. - Pipeline attestation covers deploy-time config checks but not post-deploy drift, a no-train setting that passes at deploy time is re-enabled six weeks later with no detection, and the pipeline still shows "passed." - Standards contributions are submitted to working groups with no active AI data governance track, they appear in the contribution log but have no path to adoption. - Automated REM validation reports pass/fail counts to the program dashboard but never feeds failures back to the pack, repeatedly failing checks stay in the pack, generating noise and eroding trust in the gate.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned AI/HAI Data Requirements Pack containing a base set of 20 or fewer requirements plus seven per-archetype deltas, with every requirement tagged to at least one TA-Data archetype threat and one PC-Data priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per asset at intake? Evidence: Pack document with ID-tagged requirements, quarterly refresh record, and named pack owner. 2. Do 100% of new AI/HAI data assets approved for AI pipeline use in the last 90 days have a completed REM on file, with every applicable requirement marked Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, each Met row citing specific verifiable evidence (consent record, DPA clause, DPIA reference, admin-console state, lineage record), each Gap-accepted row naming a compensating control, owner, and re-review date, and material-change triggers defined? Evidence: SM intake tickets with attached REM artifacts; gap register with owner and expiry fields populated. 3. Is the pack on a quarterly refresh cadence with a named owner, and are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements from scratch? Evidence: Quarterly refresh records; cross-references from DR, IR, and ST artifacts back to REM row IDs.

Level 2. 1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (retention days, DSAR response time, key-rotation interval, audit-log retention period) and every binary state (no-train toggle confirmed, DPIA current, SCC mechanism documented) specified, and has all qualitative "reasonable" and "appropriate" language been removed? Evidence: Pack document with no instances of qualitative acceptance language. 2. Are ≥95% of Critical-tier REMs re-validated against observed reality (data-catalog, admin-console, audit log, IR findings, ML monitoring) in the last 90 days, with validation deltas routed to IM-Data and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor? Evidence: Validation log with timestamps; gap register with escalation records. 3. Do 100% of Critical-tier personal-data assets carry a completed and current DPIA with DPO sign-off, and does the SR-Software cross-reference operate for Critical/High Software artifacts that consume these assets, with SR-Software REMs linked to the corresponding SR-Data REMs? Evidence: Critical-tier REM appendices with DPIA references; cross-domain traceability log showing SR-Software-to-SR-Data linkage.

Level 3. 1. Is the AI/HAI Data Requirements Pack expressed in a machine-readable schema and enforced via pipeline attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier assets entering AI pipelines with a failing REM check, and the schema published under a permissive license with tracked external adoption? Evidence: Pipeline attestation log; zero-failure production deploy record; external adoption tracking. 2. Are ≥70% of REM evidence rows auto-validated via pipeline signals, runtime monitoring (ML-Data), and admin-console API ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations? Evidence: Validation telemetry showing auto-vs-manual split; false-positive and false-negative rate tracking. 3. Does the program contribute at least two substantive artifacts per year (machine-readable requirement schema, REM schema, data-domain requirement clauses) to recognized standards bodies (OpenSSF AI, OWASP LLM, DAMA / EDM Council, NIST AI RMF Playbook), with contributions publicly documented and traceable to adoption? Evidence: Contribution log with public links to accepted or in-progress submissions.

19. Secure Architecture (SA)

Practice Overview

Objective: Publish the reference architectures for safely ingesting, storing, routing, and retiring each AI/HAI data archetype the organization governs, so data engineering and MLOps teams have a vetted green path that already implements SR-Data requirements and contains the threats identified by TA-Data.

Description: SA-Data ships a catalog of reference patterns, one per AI/HAI data archetype, showing how to classify, gate, isolate, log, and expire the data that flows into and out of AI systems. Each pattern covers scope, data boundary and classification flow, the consent and lawful-basis check point, lineage and provenance hooks, the access-control model, the logging specification, controls mapped to SR-Data requirements, and threats mitigated, tagged to HAI TTPs (EA/AGH/TM/RA) and MITRE ATLAS technique and mitigation IDs. The catalog is accompanied by an anti-pattern list derived from real incidents and first-party post-incident reviews. Teams use the reference pattern as the starting point; deviations require design review. At L2, patterns are extended with multi-region and cross-border data-residency variants and tier-conditional controls encoded as IaC, calibrated to SM L2's tier-treatment matrix. At L3, patterns are published as open artifacts adopted by the industry and MITRE ATLAS mitigation-library entries are proposed from pattern controls.

Context: Without reference patterns, every data engineering team building a training pipeline, a retrieval store, or a logging subsystem makes the same architectural missteps, regulated PII flowing into training without consent verification, retrieval stores indexed without per-source classification, prompt/completion logs retained indefinitely without PII redaction, embedding stores world-readable without access control, fine-tuning datasets built from inference logs without a re-use assessment. The downstream cost is threat models that discover problems too late, design reviews that repeat the same finding set, and GDPR enforcement actions that replay avoidable anti-patterns. SA-Data makes the secure path the default path for every AI data archetype, not by blocking data engineering, but by publishing a pre-vetted architecture that teams reach for first.

Maturity Level 1

Objective: Publish reference architectures per AI/HAI data archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Data requirements and TA-Data threats.

Activities.

A) Publish reference architectures per AI/HAI data archetype. Publish one pattern per archetype the org actually uses. Each pattern is concise (target three pages), includes a labeled data-flow diagram, and covers a consistent skeleton: scope (what the pattern covers and explicitly does not); data boundary and classification flow (where data enters the AI pipeline, where the classification label is applied or verified, how the label propagates through transforms, where regulated data is gated or blocked); the consent and lawful-basis check point (where consent verification or a lawful-basis record is confirmed before the data proceeds and what blocks progress on failure); lineage and provenance hooks (where lineage metadata is attached, which pipeline steps record their transformations, where the lineage record is stored); the access-control model (RBAC roles for read/write/export/delete, a service-principal model for pipeline service accounts, audit-log coverage); the logging specification (events logged, retention period, export mechanism for DSAR and regulator requests); controls mapped row-by-row to SR-Data requirements with gaps acknowledged; and threats mitigated (which TA-Data archetype threats the pattern addresses, which remain residual, HAI TTP tags, and MITRE ATLAS technique IDs, AML.T0019, T0020, T0024, T0025, T0010 where applicable, and mitigation IDs where available). The training-corpus pattern routes raw source data through a classification-gating staging area before promotion to the curated training lake, blocks regulated data lacking a documented lawful basis at the staging gate, confirms a consent-basis record at ingest, applies lineage tagging at ingest, restricts pipeline service accounts to the curated lake, runs a poisoned-data detection scan at ingest, and enforces automated retention and expiry; threats mitigated include AML.T0020 training-data poisoning, AML.T0010 supply-chain compromise, unconsented data inclusion, and regulated-data leakage at training time (HAI-TTP RA; ATLAS TA0005 Persistence mitigated by lineage tagging). The inference-input-stream pattern applies PII redaction at the input edge, routes Art. 9 special-category data only to inference endpoints with confirmed no-train status, enforces per-tenant context isolation, adds a rate-limit and abuse-detection layer, and logs prompt events with tenant identifier and classification tag rather than full content absent a lawful basis; threats mitigated include direct prompt injection (AML.T0051), regulated-data leakage to vendor LLMs (AML.T0024), and sensitive-information disclosure (HAI-TTP AGH; ATLAS TA0003 Initial Access mitigated by input validation). The retrieval-store pattern requires a classification label on every document at index time, per-tenant retrieval isolation, structural separation of system instructions from untrusted retrieved content, provenance metadata on every chunk, access control on the vector index, and full retrieval logging; threats mitigated include retrieval poisoning (AML.T0020), corpus exfiltration (AML.T0024), indirect prompt injection (HAI-TTP AGH), and classification-label bypass. The prompt/completion-log-corpus pattern applies PII redaction at log-write time, attaches a retention tag aligned to GDPR Art. 5(1)(e), exports only through a controlled DSAR-capable interface, partitions log records per tenant, and links each record to the SM inventory record of the producing artifact; threats mitigated include retention-policy violation, regulated-data persistence in logs, and unauthorized log export (AML.T0025; ATLAS TA0011 Exfiltration mitigated by export access control). The embedding-store pattern enforces classification-aware RBAC on raw embeddings, applies inversion-defense noise or clipping for sensitive content, enforces a retrieval-only access model, partitions namespaces per tenant, rate-limits nearest-neighbor queries, and audit-logs every query; threats mitigated include embedding inversion and nearest-neighbor extraction (AML.T0024) and retrieval poisoning at the embedding layer (HAI-TTP TM). The fine-tuning-dataset pattern requires DPIA-gated curation, consent-tracked subject inclusion, opt-out enforcement before fine-tuning commences, recorded lineage from dataset version to training-job event, and dataset isolation with no production network access; threats mitigated include unconsented data inclusion, training-data poisoning (AML.T0020), and label-flip attacks (HAI-TTP RA). The evaluation/test-set pattern enforces isolation from training pipelines, a bidirectional deduplication contamination-prevention gate, reproducibility metadata, signed eval attestation stored in the model registry as a prerequisite for model promotion, and access restricted to named evaluation personnel; threats mitigated include eval contamination, eval gaming (AML.T0048), and eval suppression (ATLAS TA0008 Defense Evasion mitigated by signed attestation).

B) Publish the anti-pattern catalog. Name, describe, and prohibit AI/HAI data architectural patterns that reliably produce incidents. Each entry includes a description, why it is dangerous, real-incident flavor (industry or first-party), and the reference pattern element that replaces it. The L1 set covers: regulated PII in training without a DPIA or lawful basis (replaced by the training-corpus classification-gating staging area and consent-basis check point); PII in prompt/completion logs unredacted and exported without access control (replaced by the prompt/completion-log-corpus PII redaction at logging and controlled export interface); embedding stores world-readable (replaced by the embedding-store classification-aware RBAC and retrieval-only access); eval set leaked to training (replaced by the evaluation/test-set contamination-prevention gate and signed attestation); a no-train assertion trusted from contract text while the admin-console toggle stays enabled (replaced by the inference-input-stream admin-console-level no-train verification with recurrent re-verification); a fine-tuning dataset built from inference logs without a re-use assessment (replaced by the fine-tuning-dataset DPIA-gated curation and lineage to training-job event); a retrieval store over an unclassified corpus that bleeds confidential content across classification boundaries (replaced by the retrieval-store classification-labeled documents and per-tenant isolation); a cross-border data flow without a transfer mechanism (replaced by the base-pack cross-border-flows requirement and the L2 multi-region pattern); DSAR deletion ignored for training data (replaced by the training-corpus and fine-tuning-dataset opt-out enforcement and lineage for deletion propagation); and lineage absent from pipeline transforms (replaced by the training-corpus lineage tagging and lineage hooks at every transform step).

C) Integrate patterns into the intake/inventory flow and establish the deviation-review path. SM inventory records link to the applicable reference pattern(s) at intake. Teams choosing an archetype see the reference pattern and declare "using pattern" or "deviating from pattern." Deviations require a lightweight design review (DR-Data L1) with a named architect reviewer and a documented rationale stored with the asset's inventory record. Patterns are reviewed and change-logged quarterly; repeat deviations in the same direction signal the need to update the pattern rather than continue approving exceptions. New archetypes that do not fit an existing pattern trigger a pattern-authoring sprint within 30 days of the first intake.

Outcome Metrics (L1).

Success Criteria.

• Seven reference patterns published, one per archetype, each with a labeled data-flow diagram, scope declaration, data-boundary and classification flow, consent/lawful-basis check point, lineage and provenance hooks, access-control model, logging spec, and row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags and applicable MITRE ATLAS technique IDs.
• Anti-pattern catalog published with at least 10 entries, linked from the AI Data Policy, the SM intake gate, and EG-Data training.
• Deviation-review path operational with a named architect-reviewer population and ≤5 business day SLA.
• ≥85% of active AI/HAI data assets in the SM inventory classified as "on pattern" or "deviation with review"; no silent deviations.
• 100% of training-corpus and fine-tuning-dataset assets with a classification-gating check on file before entering any AI training pipeline.

Maturity Level 2

Objective: Extend reference patterns to multi-region, cross-border, multi-tenant, and tier-conditional variants calibrated to SM L2's tier-treatment matrix; encode patterns as IaC with conformance test suites; update the anti-pattern catalog from IM-Data incidents.

Activities.

A) Tier-conditional pattern extensions. Publish extended pattern variants calibrated to SM L2's tier-treatment matrix for data assets. The Critical-tier overlay (applying to any archetype at Critical tier) adds per-tenant isolation enforced at the data boundary, the retrieval store, and the embedding namespace; data-residency-aware routing keeping EU personal data within the EU region or an adequacy-decision region with residency preserved on cross-region failover; automated transfer-mechanism verification in which an IaC module queries the DPA registry at deploy time and blocks deployment if a documented transfer mechanism is not on file for a cross-border flow; EU AI Act Art. 10 training-data quality controls explicitly mapped in the pattern; and a GDPR Art. 35 DPIA evidence template auto-populated from the IaC module. The High-tier overlay includes monitoring and logging IaC modules pre-wired with an access-audit log pipeline, a retention-enforcement trigger, a no-train re-verification scheduler, and SIEM alert routing, with standard ML-Data L2 detections pre-wired. The multi-region/cross-border pattern covers region pinning at the ingestion layer, cross-region failover with residency preservation, automated SCC currency verification, and a GDPR international-transfer mechanism selection step as a required decision gate in the IaC module. The multi-tenant pattern for shared data infrastructure covers per-tenant namespace isolation at every pipeline stage (ingest, transform, store, retrieve, log), per-tenant classification-policy enforcement, per-tenant DSAR response isolation, and a tenant-isolation conformance test wired into CI.

B) Patterns-as-IaC with conformance test suites. Encode all Critical and High-tier pattern variants as forkable IaC modules, Terraform, Pulumi, CloudFormation, or equivalent, so teams fork rather than handcraft; deviations surface at plan or apply time. Each IaC module ships with a conformance test suite: automated checks that the deployed pipeline matches the pattern's controls (classification gate active, PII redaction enabled at logging, per-tenant isolation enforced, transfer mechanism verified, retention policy enforced, access-control RBAC applied, audit log active). IaC modules are version-pinned; module updates trigger a drift-detection pass against all deployed instances. A module change log is maintained; teams consuming a module are notified of updates requiring remediation.

C) Incident-informed anti-pattern catalog refresh. Every IM-Data incident is classified to an anti-pattern (existing or new); the classification is recorded in the IM finding. The catalog is refreshed monthly from IM-Data findings; new anti-patterns are surfaced to teams at intake time rather than stored only in a reference document. Quarterly review: if three or more assets have deviated from a pattern in the same direction, the pattern is queued for update rather than continued exception approval. Anti-patterns originating from Critical-tier incidents are escalated to the SM working group for a pattern-update sprint within 30 days.

Outcome Metrics (L2).

Success Criteria.

• Four tier-conditional extended patterns published (Critical overlay, High overlay, multi-region/cross-border, multi-tenant), each encoded as a forkable IaC module with a conformance test suite.
• ≥80% of Critical and High-tier AI/HAI data assets running on IaC-encoded patterns with plan-time deviation flagging.
• Anti-pattern catalog updated from ≥3 real IM-Data incidents in the last 12 months; new entries surfaced at intake time.
• Conformance test coverage at 100% of IaC-encoded data-pipeline deployments.
• 100% of Critical-tier data assets with automated transfer-mechanism verification in the IaC module.

Maturity Level 3

Objective: Publish reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage regulators and standards bodies on data-pipeline architecture norms for AI/HAI data.

Activities.

A) Publish reference patterns as open artifacts. Publish patterns under Apache 2.0 or equivalent via OWASP LLM/Agentic, OpenSSF AI, DAMA / EDM Council, or an equivalent body; publish sector-specific variants through relevant sector bodies (FS-ISAC, H-ISAC, sector AI working groups). Maintain the public repository as the upstream source; internal use aligns with the external version; internal deviations are documented with rationale and fed back as upstream proposed changes rather than silent forks. Track pattern adoption telemetry, GitHub forks, citations in published work, documented adopters. New archetypes or overlays developed internally are proposed for inclusion in the external catalog within 90 days of internal publication.

B) Contribute to the MITRE ATLAS mitigation library. For each control in the reference patterns that corresponds to a threat technique in the ATLAS taxonomy, propose or validate a mitigation entry in the ATLAS mitigation library (AML.M00xx). Priority contributions align to SA-Data's primary data-attack techniques: AML.T0019 Publish Poisoned Datasets (mitigated by classification-gating staging and provenance verification), AML.T0020 Poison Training Data (mitigated by anomaly detection at ingest and lineage tracking), AML.T0024 Exfiltration via ML Inference API (mitigated by retrieval-only access, embedding inversion defense, and per-tenant isolation), AML.T0025 Exfiltration via Cyber Means (mitigated by the access-controlled log export interface), and AML.T0010 ML Supply Chain Compromise (mitigated by source-lineage verification and supply-chain gating at staging). Target at least two AML.M00xx entries proposed or validated per year, traceable to specific SA-Data pattern controls. Participate in the ATLAS practitioner community to align SA-Data control vocabulary with ATLAS technique taxonomy.

C) Engage regulators and standards bodies on data-pipeline architecture norms. Participate actively in EU AI Act implementing-act consultations where training-data quality and data-pipeline architecture standards (Art. 10) are under discussion; submit SA-Data patterns as evidence of state-of-the-art data-pipeline practice. Contribute to GDPR supervisory authority guidance on AI training data, consent-tracking at scale, DPIA requirements for large-scale personal-data training, and Art. 17 deletion-propagation obligations. Engage NIST AI RMF Playbook successor editions with SA-Data pattern mappings to GOVERN, MAP, MEASURE, and MANAGE. Contribute the data-archetype pattern schema, classification-gating framework, and lineage-and-provenance standard as referenceable open artifacts to DAMA International and EDM Council AI Data Governance working groups.

Outcome Metrics (L3).

Success Criteria.

• ≥5 reference patterns published as open artifacts under a recognized open license via at least one industry body (OWASP, OpenSSF AI, DAMA, or equivalent).
• ≥2 patterns externally cited or forked by recognized industry or sector bodies.
• ≥2 MITRE ATLAS AML.M00xx mitigation entries proposed or validated, traceable to SA-Data pattern controls, aligned to the primary data-attack techniques (AML.T0019, T0020, T0024, T0025, T0010).
• Internal practice 100% aligned to the published external version; all deviations proposed as upstream contributions, none silently forked.
• At least one documented regulatory or standards-body reference to SA-Data patterns in implementing-act, guidance, or standards text.

Common Pitfalls

Level 1. - Patterns are written but not linked from the SM inventory record or the intake gate, teams skip them because they are hard to find, not because they disagree with them. - The training-corpus pattern omits the classification-gating staging area, regulated PII flows directly to the curated training lake without a blocking gate; the gate exists in the document but not in the deployed pipeline. - Anti-patterns remain theoretical and not tied to real incidents or to the specific pattern element that replaces them, data engineers do not recognize the hazard when they encounter it. - The prompt/completion-log-corpus pattern specifies PII redaction at logging but no redaction service is deployed, plaintext prompt content containing PII is written to log storage from day one, and the pattern is aspirational.

Level 2. - IaC patterns are forked once and then hand-edited at each deployment, drift is immediate and the IaC substrate provides no baseline enforcement; conformance tests are skipped because they block the fastest path to production. - The multi-region/cross-border pattern covers data-residency in the diagram but omits the GDPR international-transfer mechanism selection step, teams deploy cross-border data flows without a documented legal basis. - The Critical-tier overlay exists on paper but the IaC module does not enforce per-tenant isolation, data from tenant A and tenant B co-mingles in the retrieval store and the embedding namespace. - Transfer-mechanism verification is in the IaC module spec but fails silently when the DPA registry is unavailable, the pipeline deploys without a mechanism on file.

Level 3. - Externally contributed patterns diverge from internal practice, what is published reflects what the org once did; external adopters discover the discrepancy during implementation and trust erodes. - ATLAS contribution targets are treated as a compliance checkbox, entries are proposed but never followed through to publication because internal legal or security review creates indefinite delay. - Regulatory engagement is declaratory ("we participated in the Art. 10 consultation") rather than substantive ("our pattern text was incorporated into the guidance"), the program cannot demonstrate that engagement produced outcomes. - Industry contributions are conference presentations and blog posts; no technical artifacts actually land in MITRE, OWASP, NIST, OpenSSF, or DAMA, external recognition is aspirational.

Practice Maturity Questions

Level 1. 1. Are seven reference patterns published, one per archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), each with a labeled data-flow diagram, classification flow, consent/lawful-basis check point, lineage/provenance hooks, access-control model, logging spec, and explicit row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags and applicable MITRE ATLAS technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable), accessible within one click of the SM inventory record? Evidence: Pattern catalog with seven versioned documents; SM inventory record containing direct links. 2. Are 100% of training-corpus and fine-tuning-dataset assets verified via data-catalog audit (not only policy declaration) to have passed through a classification-gating check and to have a documented consent/lawful-basis record on file before entering any AI training pipeline, and is the anti-pattern catalog linked from the AI Data Policy, the SM intake gate, and EG-Data training, with each entry tied to a real or representative incident? Evidence: Data-catalog audit showing classification-gating completion; anti-pattern catalog linked from the AI Data Policy, intake gate, and EG-Data training curriculum. 3. Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are ≥85% of active AI/HAI data assets in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations? Evidence: Pattern metadata showing on-pattern or deviation-with-review status; deviation aggregation report from the last quarter.

Level 2. 1. Are the four tier-conditional extended patterns (Critical overlay, High overlay, multi-region/cross-border, multi-tenant) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier AI/HAI data assets running on IaC-encoded patterns as confirmed by the IaC and SM inventory registries? Evidence: IaC module repository with four variant directories; conformance test run history; SM inventory showing tier-to-pattern alignment. 2. Has the anti-pattern catalog been updated from ≥3 real IM-Data incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and does conformance testing cover 100% of IaC-encoded data-pipeline deployments with findings tracked to resolution? Evidence: Anti-pattern change log with IM incident references; intake gate showing current anti-pattern catalog version; CI/CD conformance test coverage report. 3. Are 100% of Critical-tier data assets using the Critical-tier overlay IaC module with automated transfer-mechanism verification, and does the SM L2 tier-treatment matrix drive pattern-variant selection, Critical assets on the Critical overlay, High assets on the High overlay, Medium/Low on the base pattern? Evidence: Critical-tier IaC module metadata showing transfer-mechanism verification; SM intake routing log showing tier-differentiated pattern assignment.

Level 3. 1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? Evidence: External repository with license file; citation or fork count; internal-vs-external pattern diff audit with no unexplained deviations. 2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Data pattern controls aligned to the primary data-attack ATLAS techniques (AML.T0019 Publish Poisoned Datasets, AML.T0020 Poison Training Data, AML.T0024 Exfiltration via ML Inference API, AML.T0025 Exfiltration via Cyber Means, AML.T0010 ML Supply Chain Compromise), and is there an active ATLAS practitioner engagement cadence? Evidence: ATLAS contribution log with PR or submission references; meeting records from the ATLAS practitioner community. 3. Is there at least one documented reference to SA-Data patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive participation? Evidence: Regulatory engagement log with document references and citation extracts; engagement calendar with active items.

20. Design Review (DR)

Practice Overview

Objective: Operate the design checkpoint between intake approval and build-out for every new data flow feeding AI/HAI systems, confirming the proposed flow follows the applicable SA-Data reference pattern, covers the SR-Data requirements pack, and documents residual risks before pipeline engineering begins.

Description: DR-Data is the single moment where data architecture (SA-Data), requirements (SR-Data), and threats (TA-Data) meet a specific planned data flow. The review runs before the data-pipeline team begins build-out, catching deviations when they cost hours to correct, not sprints. A two-lane model routes Low / Medium-tier data flows to an async fast-lane (target ≤2 business days) and High / Critical-tier or deviation cases to a full-lane architect review (target ≤5 business days) that includes DPO and data-steward participation. Every review produces a written decision (approve / approve-with-conditions / send-back) stored against the SM-Data inventory record. Loop-back signals ensure the review process improves SA-Data patterns and SR-Data packs over time rather than accumulating silent compliance debt.

Context: Without a data-flow design checkpoint, AI/HAI data pipelines ship without a verified consent basis, without a documented cross-border transfer mechanism, without poison-detection scans on training corpora, and without DSAR-surface mapping. SA reference patterns and SR requirements packs exist, but teams skip them under delivery pressure, deviate without recording rationale, or simply build before the archetype pattern is consulted. DR-Data enforces the handoff between "data intake approved" and "pipeline build begins," making deviations visible and deliberate. GDPR Art. 35 requires a DPIA for high-risk processing of personal data; the DR decision record is the documented pre-build decision that DPIA evidence references. EU AI Act Art. 10 requires data-governance practices for training data used in high-risk AI; the DR record is that traceability artifact.

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every new AI/HAI data flow before pipeline build-out, producing a written decision traceable to the SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot.

Activities.

A) Publish the per-archetype AI/HAI Data Design Checklist. One checklist per SM-Data data archetype, derived from the applicable SA-Data reference pattern and keyed to the SR-Data base pack and archetype delta. Each item is a yes/no with an evidence pointer. The seven checklists share a common spine, classification labeling (the flow's classification label declared, consistent with the SM-Data taxonomy, and propagated through the pipeline design), lineage / provenance (every dataset with a documented origin, last-verified date, and trust classification, traceable from source to consumer), consent basis (the lawful basis under GDPR Art. 6, or Art. 9 for special-category data, documented with consent or lawful-basis evidence linked from the DR record), retention policy (retention period declared and technically enforceable, deletion mechanism specified), cross-border transfer mechanism (where the flow crosses a GDPR Chapter V boundary, the named mechanism, SCCs, adequacy decision, BCRs, on file), encryption at rest and in transit (algorithm, key management, and vault storage declared, no keys in code or environment variables), access-control model (access at rest and in motion restricted to declared principals with a documented service-account model), DSAR surface (the flow's contribution to the organization's DSAR response surface mapped, subject-level queryability confirmed or documented as a gap with a compensating control), and classification-label propagation (labels applied at ingestion propagate to downstream consumers and are not silently stripped by transformation steps), plus archetype-specific additions. The training-corpus and fine-tuning-dataset checklists add a DPIA trigger assessment (high-risk processing per GDPR Art. 35), a poison-detection scan scheduled pre-training, a data-minimization scope review, and opt-out-path design (a mechanism for data subjects to exclude their data from training). The inference-input-stream checklist adds PII-redaction-edge design (where in the pipeline PII is redacted before the payload reaches the LLM provider), a no-train probe target (the no-train flag confirmed as a design requirement, not an assumption), and classification-gated routing design (regulated input must not route to a vendor where no-train has not been verified). The retrieval-store checklist adds per-tenant isolation design, injection-defense scope (retrieved content treated as untrusted and structurally separated from instructions), and a declared corpus-source allow-list. The prompt/completion-log-corpus checklist adds redaction-at-logging design, a retention-by-archetype policy (shorter than training data), and export-control design (logs not bulk-exportable without DSAR authorization). The embedding-store checklist adds inversion-defense design and per-tenant partitioning design. The evaluation/test-set checklist adds isolation-from-training design (an explicit isolation boundary in the architecture diagram), reproducibility design (pinned dataset versions), and access control restricted to named personnel.

B) Triage and route reviews by risk tier and deviation status. The two-lane model is driven by the SM-Data tier assignment and the deviation flag. Fast-lane (Low / Medium tier, on-pattern, no cross-border, no DPIA trigger): async checklist review by the designated reviewer, target SLA ≤2 business days; output is one structured decision record stored against the SM-Data inventory record. Full-lane (High / Critical tier, or any cross-border flow, regulated data class, DPIA trigger, or pattern deviation): architect review with the data-pipeline team, DPO, and data-steward walking the SA-Data reference pattern section-by-section, target SLA ≤5 business days; output is a written decision record with the residual-risk list reviewed by a named architect and signed by the DPO for personal-data flows. Before SM-Data L2 tiers are established, training corpora, fine-tuning datasets, and inference-input streams processing regulated data (PII, PHI, PCI) default to full-lane; prompt/completion log corpora and embedding stores default to full-lane if multi-tenant; all others default to fast-lane with override available on reviewer judgment. Every decision record, both lanes, carries: decision (approve / approve-with-conditions / send-back), checklist completed with evidence pointers, deviations listed with rationale, residual risks with named owner and expiry, reviewer name and date, DPO acknowledgment for personal-data flows, and links to the SM-Data inventory record, TA-Data threat snapshot, SR-Data REM, and DPIA if triggered.

C) Close the loop with SA-Data, SR-Data, and IM-Data. Design review is a learning surface for the data-domain program. Three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Data ownership, recurring deviations signal the pattern is miscalibrated, not that pipeline teams are wrong. An SR-Data requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review. Every IM-Data incident re-examines the DR decision record that approved the affected data flow: was the issue visible at design time, and which checklist item would have caught it? The answer updates the checklist. Completed DPIAs are linked back to the DR record; DPIA findings that require design changes route back through the checklist before build-out.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype data design checklists published, versioned, and traceable to the applicable SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot, covering all seven Data-domain archetypes.
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype trained on EG-Data L1.
• ≥95% of AI/HAI data flows going to production in the last 90 days carry a completed DR decision record before pipeline build-out begins.
• DPIA trigger identification wired into the checklist; DPO acknowledgment required for all personal-data full-lane reviews.
• SA-Data pattern-update and SR-Data pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Data incident re-examines the DR record that approved the affected data flow.

Maturity Level 2

Objective: Upgrade Critical-tier data-flow reviews to scenario-based walkthroughs driven by TA-Data per-flow threat models, detect design drift for High and Critical data flows on a published cadence, and run joint DR-Data / DR-Software reviews for Critical-tier data flows feeding first-party AI artifacts.

Activities.

A) Scenario-based reviews for Critical and High-tier data flows. For every Critical-tier data flow, the full-lane checklist walkthrough is replaced by a scenario walkthrough. The reviewer sources 3–5 specific threat scenarios from the TA-Data per-flow deep threat model and the TA-Data archetype library. Scenarios must be specific to this flow's data classes, cross-border routing, consumer AI artifacts, and processing context, not generic archetype scenarios. Each scenario is walked as: "If an adversary does X, does the proposed design have a control that prevents or detects it? Where? What is the residual risk?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry. Scenario sources include the TA-Data per-flow deep threat model, anonymized IM-Data incidents from the same archetype, MITRE ATLAS data-attack technique candidates (AML.T0018 Backdoor ML Model, AML.T0019 Poison Training Data, AML.T0025 Model Inversion via ML Inference API, AML.T0037 Data from Information Repositories), and OWASP LLM entries relevant to the archetype's position in the inference chain. For High-tier data flows, the standard full-lane review is augmented with at least one scenario from the TA-Data archetype library rather than a full scenario walkthrough.

B) Cross-domain joint reviews for Critical-tier data flows feeding first-party AI artifacts. When a Critical-tier data flow feeds a first-party AI software artifact, a training corpus flowing to a fine-tune workload, an inference-input stream flowing to an LLM-integrated app, a retrieval store serving a RAG pipeline, DR-Data coordinates a joint review with DR-Software. The DR-Data reviewer and DR-Software reviewer attend the same session; the handoff boundary (which controls are the data-pipeline team's responsibility vs. the AI-software team's) is explicitly documented in both DR records. DR-Data covers the data-flow design; DR-Software covers the AI artifact's consumption design; residual risks spanning both are noted in both records with shared ownership. Where the first-party AI artifact is new and no DR-Software record exists, DR-Data flags the gap and holds the data flow's Sanctioned status until DR-Software completes.

C) Design-drift detection. The live production data flow is compared against its approved DR design at a published cadence. Critical-tier: quarterly drift check, examining data-catalog change webhooks (Atlan / Collibra / DataHub / Unity Catalog), pipeline-metadata changes (Airflow / dbt / Fivetran), lineage-graph changes, classification-label-scan deltas (Macie / BigID / Purview baseline vs. current), and cross-border-flow routing changes. High-tier: annual drift check using the same sources. Material drift, a new data source added, a classification scheme changed, cross-border routing changed, a new consumer added, a retention policy changed, the DSAR surface changed, automatically re-opens the DR record and routes back through the appropriate lane. Each drift check produces a written artifact: the diff between approved design and live configuration, each delta classified as material or non-material, with material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• Design-drift detection operating quarterly for Critical and annually for High data flows; 100% of material drifts re-routed to DR.
• Joint DR-Data / DR-Software review records on file for 100% of Critical-tier data flows feeding first-party AI artifacts.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

Objective: Operate continuous design attestation via automated SA-Data-pattern-compliance scans, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to OpenSSF AI Data, DAMA, EDM Council, and CSA.

Activities.

A) Continuous design attestation via automated SA-Data-pattern-compliance scans. Critical-tier data flows produce a daily attestation signal covering: a catalog-metadata scan (classification labels current and consistent with the SM-Data taxonomy), a lineage-graph check (lineage as approved, no new sources or consumers added without DR review), a consent-basis currency check (GDPR Art. 6/9 lawful-basis records still active and not expired), a retention-enforcement check (deletion jobs running and on schedule), an encryption-configuration check (keys in vault, encryption algorithms unchanged), and a cross-border-routing check (transfer mechanisms current, no new jurisdictions in the pipeline). Deviations from the approved design automatically open a DR-exception ticket in IM-Data, triaged within 3 business days. Attestation artifacts are machine-readable and regulator-consumable, GDPR Art. 35 DPIA evidence, EU AI Act Art. 10 data-governance records, and ISO/IEC 42001 AIMS operational records are produced without manual assembly. Human reviewers handle novel flow architectures that do not fit existing attestation rules, accepted exceptions with documented rationale, and escalations from the IM-Data backlog.

B) Contribute review rubrics and scenario templates to industry. Publish under Apache 2.0 or equivalent through the OpenSSF AI Data working group, DAMA International AI Data Governance, EDM Council AI Data Risk, or CSA AI Safety Initiative: per-archetype AI/HAI data design review rubrics (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS data-attack tactics), scenario template libraries (scenario format, per-archetype examples keyed to AML.T techniques, debrief rubric for calibration exercises), and a pattern-evolution framework (how external signals, ATLAS updates, GDPR enforcement actions, ISAC advisories, IM-Data incidents, feed DR checklist and scenario updates on a quarterly cadence). Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked. Adoption is tracked by citations, forks, and direct acknowledgment from peer organizations or standards bodies.

C) Pattern evolution driven by external and internal signals. A quarterly pattern-evolution review combines external signals (MITRE ATLAS data-attack technique additions and refinements, AML.T0018 Backdoor ML Model, AML.T0019 Poison Training Data, AML.T0025 Model Inversion via ML Inference API, AML.T0037 Data from Information Repositories; GDPR enforcement decisions affecting training-data governance; sector ISAC AI-data advisories; OWASP LLM entries relevant to retrieval and inference inputs) with internal signals (IM-Data incident patterns by archetype, ST-Data test findings, ML-Data telemetry anomalies) to produce structured checklist and scenario library updates. Updates are change-logged with signal provenance; downstream DR records for in-flight reviews are notified of pattern changes affecting their archetype. Where a new ATLAS technique or IM-Data incident reveals a checklist gap, the gap is propagated to SA-Data and SR-Data to maintain the full traceability chain from threat to requirement to design review.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier data flows; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year, per-archetype rubrics, scenario templates, or pattern-evolution frameworks, with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the routine review volume.
• Quarterly pattern-evolution cadence traceable to external (MITRE ATLAS AML.T data techniques, GDPR enforcement, sector ISACs) and internal (IM-Data, ST-Data, ML-Data) signals with a versioned change log.

Common Pitfalls

Level 1. - Design review runs after the data pipeline has already been built, the checkpoint loses leverage because rework cost is already sunk; the review becomes a retrospective, not a gate. - Checklists are identical across archetypes, the fine-tuning-dataset checklist does not include DPIA trigger assessment, consent-tracking design, or opt-out-path design because it was copied from the retrieval-store checklist. - Fast-lane becomes the default for everything, training corpora and inference-input streams processing PII slip through with a 15-minute async check rather than the full-lane architect session they require. - DPIA triggers are not assessed at DR, teams discover the DPIA requirement post-deployment during an audit or a subject-access request, and cross-border transfer mechanisms are assumed rather than named.

Level 2. - "Scenario-based" review is the same checklist read aloud in a meeting, same items, different format; the scenario-to-design-control mapping is never actually performed. - Scenario library is not refreshed quarterly, scenarios pulled from a 12-month-old TA-Data snapshot do not reflect the current per-flow deep model or recent IM-Data incidents. - Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live flow has diverged. - Joint DR-Data / DR-Software reviews never happen because the coordination channel with DR-Software was never established, Critical-tier training corpora flowing to fine-tune workloads have no handoff boundary documentation on file.

Level 3. - Attestation signals show green across all Critical data flows but underlying checks cover only retention-job run status, classification-label currency, consent-basis expiry, cross-border routing, and encryption-key-vault binding are not checked; attestation is cosmetic. - Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed data flows 18 months ago; peer adopters find inconsistencies when comparing the rubric to actual DR records. - Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every minor pipeline configuration change opens a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - Industry contributions are conference talks describing the program, no technical artifacts (rubrics, scenario templates, pattern-evolution frameworks) land in OpenSSF AI Data / DAMA / EDM Council with documented adoption.

Practice Maturity Questions

Level 1. 1. Is there a published, versioned per-archetype AI/HAI Data Design Checklist, one per SM-Data archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), traceable to the applicable SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot, with training-corpus and fine-tuning-dataset checklists covering DPIA trigger assessment, poison-detection scan scheduling, and opt-out-path design, and the inference-input-stream checklist covering PII-redaction-edge design and a no-train probe target? Evidence: Checklist documents with version history; traceability matrix linking each item to an SA-Data pattern control and an SR-Data requirement; training-corpus and fine-tuning-dataset checklist sections signed off by the named lead reviewer. 2. Do ≥95% of AI/HAI data flows going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before pipeline build-out begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Data L1, DPO acknowledgment for personal-data full-lane reviews, and a residual-risk list with named owner and expiry in every record? Evidence: SM-Data inventory query showing last-90-days production entries with DR decision record IDs linked; review SLA telemetry report; sample of 5 decision records showing the residual-risk section and DPO acknowledgment populated. 3. Are recurring pattern deviations and repeatedly-waived SR-Data requirements automatically queuing SA-Data pattern-update and SR-Data pack-update reviews, and does every IM-Data incident trigger a re-examination of the DR record that approved the affected data flow? Evidence: SA-Data pattern-update queue entries with triggering deviation counts; SR-Data pack-update tickets linked to waiver patterns; IM-Data incident post-mortems with a DR-record re-examination section completed.

Level 2. 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Data per-flow deep models and anonymized IM-Data incidents, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? Evidence: Critical-tier DR decision records from the last 90 days, each showing a scenario-to-design-control mapping table and a decision statement tied to scenario outcomes. 2. Is design-drift detection running quarterly for Critical-tier and annually for High-tier data flows, using data-catalog change webhooks, pipeline-metadata changes, lineage-graph changes, classification-label-scan deltas, and cross-border-routing changes, with 100% of material drifts automatically re-routed to DR for a new review? Evidence: Drift-detection run log with cadence dates; material-drift classification report showing re-routed data flows; DR queue entries with a drift-triggered source tag. 3. Are joint DR-Data / DR-Software review records on file for 100% of Critical-tier data flows feeding first-party AI software artifacts, with an explicit handoff boundary and shared residual-risk ownership documented in both DR records? Evidence: Cross-reference report of Critical-tier data flows feeding first-party AI artifacts; matching DR-Data and DR-Software decision records; handoff-boundary section in each record.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI data flows producing a daily automated SA-Data-pattern-compliance attestation signal, checking classification-label currency, lineage-graph bounds, consent-basis expiry, retention-enforcement status, encryption-key-vault binding, and cross-border routing, with deviations auto-opening DR-exception tickets triaged within 3 business days? Evidence: Attestation telemetry dashboard showing a daily signal per Critical data flow; DR-exception ticket queue with open/triage timestamps; sample attestation artifact in machine-readable format. 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to OpenSSF AI Data, DAMA, EDM Council, or CSA AI Safety Initiative, with documented adoption and internal practice aligned to the published versions? Evidence: Contribution log with external publication links and adoption indicators; comparison document showing the internal checklist aligned to the published version. 3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS data-attack techniques, GDPR enforcement decisions, sector ISAC advisories) and internal signals (IM-Data incidents, ST-Data findings, ML-Data telemetry), with a versioned change log and notification to in-flight DR reviews affected by pattern changes? Evidence: Quarterly pattern-evolution review minutes with signal-source citations; versioned checklist change log; in-flight DR review notification records for the most recent pattern update.

21. Implementation Review (IR)

Practice Overview

Objective: Verify, at go-live and on a recurring cadence, that the actually-deployed data flows feeding AI/HAI systems match the design approved at DR-Data, and that they stay there as pipelines, classification schemes, and consumer AI artifacts evolve.

Description: IR-Data is the configuration and state check for Data-domain assets, the moment a reviewer opens the data catalog, the pipeline metadata, the lineage graph, the encryption configuration, and the vendor admin APIs and confirms that what is deployed matches the DR-Data decision record. At L1 the review runs at go-live, at least annually, and on material change (a new data source added, a classification scheme change, a region change, a retention change, a new consumer added). At L2, IR-Data consumes catalog-change webhooks, pipeline-metadata events, lineage-graph signals, classification-label-scan deltas, and vendor admin API recurrent probes to detect configuration drift continuously for High and Critical-tier data flows. Findings are severity-tagged and SLA-bound per the SM-Data L2 tier-treatment matrix; they feed IM-Data for tracking and resolution. No-train flags on outbound LLM calls, retention settings, and classification-label propagation are probed recurrently, not trusted from design text alone.

Context: The gap between the approved data-flow design and the running pipeline is the primary source of silent compliance and security exposure in Data-domain AI/HAI programs. A training corpus's classification label is correct in the DR record but a pipeline transformation strips it downstream. An inference-input stream's PII-redaction step is documented in the SA pattern but was bypassed by a hotfix deploy. A vendor LLM's no-train setting is confirmed in the DR record but was reset by the vendor's platform update. A GDPR Art. 17 deletion job is in the design but was disabled when the cron schedule was migrated. IR-Data closes these gaps by making the implementation check systematic, evidence-based, and recurring, not a one-time pre-launch checkbox or a scramble when an incident or a supervisory authority audit reveals a drift.

Maturity Level 1

Objective: Run per-archetype implementation reviews at go-live, annually, and on material change, verifying deployed data flows match the SA-Data pattern, configuration matches the DR-Data decision, and SR-Data REM evidence is current.

Activities.

A) Publish the per-archetype data implementation review checklist. One checklist per SM-Data data archetype, focused on the configuration and pipeline state points where production reality most commonly drifts from the approved design. Each item is a yes/no with a required evidence artifact (catalog screenshot, pipeline config export, vendor admin API response, scan result, log sample). The common spine across all seven archetypes covers: classification labels propagating correctly (pull a sample of records at each pipeline stage and verify labels match the approved taxonomy and are not silently stripped by transformation steps); lineage as designed (the data-catalog lineage graph matches the approved flow design, with no new sources or consumers added since the last DR); consent-basis evidence current (the GDPR Art. 6 or Art. 9 lawful-basis record cited in the SR-Data REM is still active, not expired or withdrawn, with a sample of consent records verified for consent-based processing); retention enforcement actually running (the deletion job or retention policy is active and has executed within the expected window, evidenced by a job execution log with a last-successful-run timestamp); encryption keys in vault, not in code (key references point to the declared vault, not to environment variables, code, or config files, confirmed via a secrets scan of the deployed pipeline artifact); access-control matches design (service accounts verified against declared principals, no additional human or system principals granted access since the last DR); and DSAR queries actually return correct subjects (execute a test DSAR query for a canary subject record and verify the response includes all expected data from this archetype and no unexpected subjects). The training-corpus and fine-tuning-dataset checklists add poison-detection scan currency (a scan run within 90 days), data-minimization scope (no new data classes not approved at DR), and opt-out enforcement (subjects on the opt-out list verified absent via a subject-ID intersection check). The inference-input-stream checklist adds a PII-redaction canary test (inject a canary PII record into the test path and verify the payload reaching the LLM API has the PII redacted), a no-train vendor admin API probe (see Activity B), and classification-gated routing verification. The retrieval-store checklist adds per-tenant retrieval-isolation verification (a query from Tenant A matching a Tenant B document returns zero results or a namespacing error) and corpus-source allow-list verification. The prompt/completion-log-corpus checklist adds redaction-at-logging verification, retention-expiry verification, and bulk-export-control verification. The embedding-store checklist adds inversion-defense verification (an unauthenticated probe is rejected) and per-tenant partitioning verification. The evaluation/test-set checklist adds isolation-from-training verification via data-catalog lineage and access-control verification against current IAM assignments.

B) Verify no-train flags via vendor admin API probes. No-train settings on outbound LLM API calls are probed via vendor admin APIs for all archetypes that route data to external LLM providers, inference input stream, retrieval store, prompt/completion log corpus, not trusted from DPA text or one-time admin-console screenshots. OpenAI: the Organization Settings API confirming data_controls.training_data_sharing is false for all applicable API keys. Anthropic: the Organization admin settings API confirming model training usage terms reflect the no-train commitment. Amazon Bedrock: AWS Service Control Policy and Bedrock model invocation logging config confirming no model fine-tuning on customer data paths. Google Vertex AI / Gemini: Google Cloud Organization Policy constraints confirming no training-data usage opt-in is active. Other vendors: an equivalent admin API or authenticated endpoint where available, with UI-based verification and screenshot evidence as fallback. Probing cadence at L1 is at go-live, at each annual review, and on material change; a delta from the previous probe opens an IR finding, and probing evidence is stored with the IR record.

C) Perform reviews at the right moments and track findings to closure. Three triggers at L1: go-live (before the data flow enters production, or before a new version goes live, verify the as-deployed pipeline and configuration against the DR-Data-approved design; no production cutover with a blocker finding open); annual (every active AI/HAI data flow reviewed at least annually, scheduled from the SM-Data inventory with a last-IR-date field linked to a review-due alert); material-change (any of the following triggers an ad-hoc review before the change ships, a new data source added, a classification scheme changed, cross-border routing changed or a new region added, a retention policy changed, a new consumer AI artifact added, a vendor LLM provider changed, the DSAR surface changed). The material-change trigger is wired to the same signal sources as SM-Data inventory material-change events. Every review produces zero or more findings. Each finding carries a severity (Critical / High / Medium / Low, calibrated to the SM-Data L2 tier-treatment matrix's IM SLA column; at L1 use a consistent judgment rubric pending SM-Data L2 formalization), a named owner (a named data-pipeline engineer or data-steward, not "the data team"), an SLA (Critical blocker resolved before production cutover or rollback required; High ≤7 days; Medium ≤30 days; Low ≤90 days or accepted residual), and an after-fix evidence artifact linked before closure. Findings feed IM-Data as issues for tracking and aging, and loop back to SR-Data where a finding reveals that an REM row's cited evidence was inaccurate, the REM row is updated before the finding is closed.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype IR checklists published, owned, and linked from the SM-Data inventory record and the DR-Data decision record, one per SM-Data archetype.
• Go-live, annual, and material-change review triggers wired to the SM-Data inventory; 100% of new AI/HAI data flows in the last 90 days have a go-live IR record.
• ≥90% of active AI/HAI data flows carry a current-year IR record.
• All Critical / blocker findings resolved before production cutover; High findings closed within 7 days with evidence linked.
• No-train flags verified via vendor admin API for ≥80% of flows with outbound LLM calls.

Maturity Level 2

Objective: Detect data-flow drift continuously for Critical and High-tier flows via catalog webhooks, pipeline-metadata events, lineage-graph signals, classification-scan deltas, and vendor admin API recurrent probes; calibrate IR cadence per SM-Data risk tier.

Activities.

A) Continuous drift detection from catalog, pipeline, lineage, classification-scan, and vendor admin APIs. Wire the following signal sources to an automated drift-detection pipeline for Critical and High-tier data flows. Catalog drift (Atlan / Collibra / DataHub / Unity Catalog change webhooks): classification-label changes, ownership changes, policy-tag changes, and new downstream consumers each trigger an automated diff against the DR-Data-approved baseline, with material deviations opening an IR finding automatically. Pipeline drift (Airflow / dbt / Fivetran metadata changes): DAG changes, transformation changes, new source additions, schedule changes, and connector-version changes are compared against the DR-Data-approved pipeline specification, with deviations flagged. Lineage drift: new upstream sources or downstream consumers appearing in the lineage graph since the last IR, any lineage edge not present in the approved flow design opens an IR finding. Classification drift (Macie / BigID / Purview scan deltas vs. baseline): newly discovered PII or regulated data classes in an archetype not approved for that class open Critical or High findings depending on the data class. Vendor admin API recurrent probes: monthly (Critical-tier) and quarterly (High-tier) probes via vendor admin APIs (OpenAI / Anthropic / Bedrock / Vertex equivalents) confirming no-train, retention, and model-training settings, any delta from the previous probe (a setting changed, a permission widened, a retention period extended) opens an IR finding with severity matching the data-class impact. Cross-border flow drift: routing metadata compared against the approved cross-border transfer map, with new jurisdictions or changed transfer mechanisms opening IR findings. Detection latency targets: Critical-tier ≤7 days from change event to finding opened; High-tier ≤30 days.

B) Tier-calibrated IR cadence. Publish and enforce per the SM-Data L2 tier-treatment matrix: Critical (go-live + semi-annual + material-change-triggered + continuous drift detection), High (go-live + annual + material-change-triggered), Medium (go-live + annual), Low (go-live + re-review on material change). Every data flow in the SM-Data inventory carries a last-IR-date and next-IR-due field; Critical-tier flows with no IR in the last 180 days are escalated to the program sponsor. Drift findings are severity-tagged and SLA-bound per the SM-Data L2 tier-treatment matrix: Critical-tier drift finding ≤7 days to resolve or accepted residual with a named owner; High-tier ≤14 days; Medium ≤30 days; Low ≤90 days or accepted residual. All drift findings feed IM-Data automatically.

C) DSAR-query accuracy recurrent verification. For Critical and High-tier data flows contributing to the DSAR surface, execute recurrent DSAR-query accuracy tests: insert a canary subject record with known attributes into the data flow's storage; execute a subject-access query via the DSAR fulfillment system; verify the canary record is returned with correct attributes and that no other subjects' records are co-mingled; and verify the canary record is correctly excluded from the DSAR response after a deletion request is processed. Cadence: Critical-tier quarterly, High-tier semi-annual. Failures are High findings (DSAR-surface exposure risk).

Outcome Metrics (L2).

Success Criteria.

• ≥90% of Critical-tier data flows under continuous drift detection; median detection latency ≤7 days.
• No-train flags verified via vendor admin APIs for ≥80% of Critical/High-tier flows with outbound LLM calls on a monthly (Critical) and quarterly (High) probing cadence.
• 100% of Critical/High-tier flows contributing to the DSAR surface with DSAR-query accuracy tests on record in the current IR cycle.
• Tier-cadence adherence ≥95%; Critical-tier findings aged per the SM-Data L2 tier-treatment matrix SLAs.

Maturity Level 3

Objective: Operate daily attestation per Critical-tier data flow, classification labels current, retention SLA met, encryption-key-rotation healthy, no-train probe results green, with drift auto-opening IM-Data tickets and configuration baseline schemas contributed to OpenSSF AI Data, DAMA, and OWASP SAMM AI.

Activities.

A) Daily attestation signal for Critical-tier data flows. Each Critical-tier AI/HAI data flow produces a daily composite attestation signal covering four dimensions: classification labels current (an automated catalog scan confirms classification labels match the approved SM-Data taxonomy and have not been silently modified or stripped by pipeline transformations in the last 24 hours); retention SLA met (deletion-job execution logs confirm the retention-enforcement job ran within the expected window and that no records past the retention date remain, with an evidence freshness window of ≤24 hours); encryption-key-rotation healthy (the key-management system confirms the encryption key is within its declared rotation schedule and has not been exported or replicated outside the vault); and no-train probe results green (the most recent vendor admin API probe confirms the no-train setting is active for all LLM providers handling data from this flow, with an evidence freshness window of ≤30 days for Critical-tier). Deviations in any dimension automatically open an IM-Data ticket carrying the drift dimension, the specific control that failed tolerance, and a link to the DR-Data decision record. Attestation artifacts are machine-readable, signed, and stored in the SM-Data inventory record; they are regulator-consumable for GDPR Art. 35 DPIA evidence continuity, EU AI Act Art. 10 data-governance records, and ISO/IEC 42001 AIMS operational records, without manual assembly.

B) Contribute per-archetype data-flow configuration baseline schemas. Publish per-archetype IR configuration baseline schemas, defining what correct implementation looks like for each AI/HAI data archetype at each SM-Data tier, to the OpenSSF AI Data working group (a reference attestation schema for AI data-flow implementations in machine-readable format), DAMA International AI Data Governance (per-archetype configuration controls with evidence-type definitions), OWASP SAMM AI extensions (Verification function, Implementation Review stream, with practitioner-level checklist items), and the CSA AI Safety Initiative AI Controls Matrix (per-archetype configuration controls mapped to CSA control categories). Internal practice remains aligned to the published external versions; internal-only deviations are proposed as upstream changes.

C) Automated drift-to-IM escalation and SLA enforcement. All IR findings, whether from daily attestation or periodic reviews, flow into IM-Data automatically with severity and SLA pre-populated from the SM-Data L2 tier-treatment matrix. The IM-Data SLA clock starts when the finding is opened; overdue Critical findings escalate to the program sponsor automatically at 50% and 100% of the SLA window. Post-incident reviews in IM-Data that touch a data-flow configuration or classification control automatically re-examine the IR record for the affected data flow, was the drift detectable earlier, and what attestation rule would have caught it? The answer updates the attestation rule and the IR checklist.

Outcome Metrics (L3).

Success Criteria.

• Daily attestation operating for ≥90% of Critical-tier data flows across all four dimensions (classification labels, retention SLA, encryption-key-rotation health, no-train probe results); deviations auto-opening IM-Data tickets within 1 hour.
• Zero stale-evidence violations for Critical-tier REMs; High-tier stale-evidence rate trending down.
• Per-archetype data-flow configuration baseline schemas published to OpenSSF AI Data, DAMA, OWASP SAMM AI, or CSA with documented external adoption.
• IR reviewer-hours per Critical data flow per year trending down over two consecutive quarters as attestation absorbs routine checks.

Common Pitfalls

Level 1. - IR treated as a one-time go-live formality, no annual re-review and no material-change trigger; classification drift, new data sources, and retention-policy changes accumulate silently for quarters until an audit or a subject-access complaint surfaces them. - Reviewers take the DR-Data decision record at face value without checking the data catalog or pipeline config, the classification label is declared in the checklist but never verified in the live catalog after a transformation step stripped it. - No-train and retention settings verified from DPA text or one-time admin-console screenshots without opening the vendor admin API, the setting can be reset by a vendor product update and the team does not know. - DSAR-query accuracy never tested, the IR checklist has a "DSAR surface mapped: yes" box that is checked without executing a canary subject query and verifying the response.

Level 2. - Drift-detection pipeline ingests catalog-change events but generates no findings on deltas, the pipeline exists but automated finding creation was never configured; drift detection is manual in practice. - Vendor admin API probing is configured once at onboarding and never re-run, a no-train setting reset by a vendor product update is undetected for months. - Classification-scan deltas are generated but never compared to the DR-Data-approved baseline, the Macie / BigID / Purview scan runs, but the output is never diffed against the approved classification scope; new data classes in the corpus are not flagged. - Drift findings from automated detection dead-end in an alert dashboard rather than auto-opening IM-Data tickets, findings age without owners, and Critical and Low-tier flows sit in the same review queue with no prioritization.

Level 3. - Daily attestation signals show green across all Critical data flows but underlying checks cover only retention-job run status, classification-label propagation, consent-basis expiry, cross-border routing, and encryption-key-vault binding are not checked; attestation is cosmetic. - Configuration baseline schemas published externally diverge from internal practice, what is published reflects the L1 checklist while internal practice has advanced to L2 tooling and L3 vendor API probing; external adopters build on a stale baseline. - Attestation-exception queue overwhelms the team because configuration tolerance thresholds are too tight, every pipeline dependency version bump triggers a deviation; reviewers suppress the signal source rather than tune the tolerance rules. - Post-incident IR feedback loop exists in policy but never fires in practice, IM-Data post-incident reviews do not include the IR-record re-examination step; attestation rules never update from incident learning.

Practice Maturity Questions

Level 1. 1. Is there a published, per-archetype IR checklist, one per SM-Data archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), covering classification-label propagation verification, lineage-as-designed verification, consent-basis currency check, retention-enforcement verification, encryption-key-vault binding check, access-control verification, and DSAR-query accuracy test, with the inference-input-stream checklist including a PII-redaction canary test and a no-train vendor admin API probe? Evidence: Published checklists with version history; inference-input-stream checklist section showing the PII-redaction canary test step distinct from DR checklist conformance; sample IR record with scan-output and config-export evidence attached. 2. Do 100% of new AI/HAI data flows going to production in the last 90 days carry a go-live IR record, and do ≥90% of all active data flows carry a current-year IR record, with material-change triggers wired to SM-Data inventory events, Critical / blocker findings resolved before production, and High findings closed within 7 days with evidence linked? Evidence: SM-Data inventory query for last-90-days production entries with IR record IDs; annual review calendar with last-IR dates; findings backlog report showing zero open blockers at go-live and High-finding closure times. 3. Are findings severity-tagged and tracked in IM-Data with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Data REM row update before the finding is closed? Evidence: IM-Data backlog export showing severity tags and SLA fields populated; SR-Data REM update log showing IR-triggered row updates; findings-aging dashboard reviewed by the program sponsor within the last 30 days.

Level 2. 1. Are ≥90% of Critical-tier AI/HAI data flows under continuous drift detection, via data-catalog change webhooks, pipeline-metadata events, lineage-graph signals, classification-label-scan deltas, vendor admin API recurrent probes, and cross-border-flow routing monitoring, with median detection latency ≤7 days and automated finding creation on material deviations? Evidence: Drift-detection telemetry report showing per-flow signal coverage; detection-latency histogram for Critical-tier; sample auto-generated IR finding linked to a catalog-change webhook event. 2. Are no-train flags and retention settings verified via vendor admin APIs (OpenAI / Anthropic / Bedrock / Vertex / equivalent) on a monthly (Critical) and quarterly (High) probing cadence, not from DPA text alone, covering ≥80% of Critical/High-tier flows with outbound LLM calls, with deltas from the previous probe opening IR findings with severity matching the data-class impact? Evidence: Vendor API probe log with cadence dates per flow; delta-detection finding showing an admin-setting change detected between probes; coverage report showing the percentage of Critical/High flows covered. 3. Are 100% of Critical/High-tier data flows contributing to the DSAR surface covered by DSAR-query accuracy tests in the current IR cycle, confirming canary-subject inclusion, correct attribute return, and post-deletion exclusion, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Data L2 tier-treatment matrix SLAs? Evidence: DSAR-query accuracy test records per Critical/High flow (canary insertion, query result, post-deletion exclusion); tier-cadence adherence report from the IR schedule; findings backlog showing Critical-tier SLA aging.

Level 3. 1. Are ≥90% of Critical-tier AI/HAI data flows producing a daily attestation signal across all four dimensions (classification-label currency, retention SLA, encryption-key-rotation health, no-train probe results green), with deviations auto-opening IM-Data tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs? Evidence: Attestation telemetry dashboard showing a daily signal per Critical data flow for the last 30 days; IM-Data ticket creation log with timestamps within 1 hour of attestation findings; Critical-tier REM evidence freshness report with zero stale entries. 2. Has the program published per-archetype data-flow configuration baseline schemas to OpenSSF AI Data, DAMA, OWASP SAMM AI, or CSA AI Safety Initiative, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical data flow per year trending down over two consecutive quarters? Evidence: External publication links with adoption indicators (forks, citations, inclusion in external tooling); comparison document showing the internal checklist aligned to the published baseline schema; reviewer time tracking report showing a QoQ decline. 3. Is the post-incident IR feedback loop operational, IM-Data post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident, ensuring incident learning continuously improves attestation coverage? Evidence: Sample post-incident review showing the IR-record re-examination section completed; attestation rule change log entries linked to incident review IDs; trend showing attestation rule count increasing with incident volume.

22. Security Testing (ST)

Practice Overview

Objective: Prove that every AI/HAI data flow the organization operates behaves correctly under adversarial conditions, by running a foundational per-archetype test battery in CI, maintaining versioned regression corpora, and escalating to scheduled red-team and continuous adversarial testing at higher maturity levels.

Description: ST-Data exercises the data flowing into and out of AI/HAI systems, training corpora, inference inputs, retrieval stores, prompt/completion logs, embeddings, fine-tuning datasets, and evaluation/test sets, against a battery of AI-specific test classes tied directly to the threats in the TA-Data library and the requirements in the SR-Data pack. At L1, every archetype has a published test battery (poison-detection scans, PII-redaction-edge canaries, retrieval-extraction probes, retrieval-poisoning probes, per-tenant-isolation tests, embedding-inversion probes, opt-out enforcement tests, eval-isolation tests) plus six versioned regression corpora (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) running in CI on every PR. L2 adds per-tier scheduled red-team exercises using TA-Data L2 per-flow deep threat models and cross-archetype composition tests. L3 operates continuous automated adversarial testing and contributes findings to MITRE ATLAS, AVID, OWASP LLM, and NIST AI RMF Data.

Context: Classic data-pipeline test suites exercise the happy path and leave the adversarial path untested. A training corpus passes all validation checks and then contains a poisoned subset that degrades model behavior (ATLAS TA0012 ML Attack Staging, AML.T0019 Poison Training Data). An inference-input stream passes integration tests and then forwards PII to an LLM provider with no-train not verified (ATLAS TA0013 Exfiltration). A retrieval store passes unit tests and then yields a neighboring tenant's documents under a crafted query (ATLAS TA0004 ML Model Access). An embedding store returns raw vectors to an unauthenticated caller who reconstructs training records (ATLAS TA0013). These failures are invisible to classic testing because classic testing was not designed for data-specific AI attack surfaces. ST-Data closes this gap by making data-specific adversarial tests a first-class CI citizen, connecting them directly to the TA-Data threat library and ATLAS data-attack tactics (TA0001 Reconnaissance, TA0004 ML Model Access, TA0012 ML Attack Staging, TA0013 Exfiltration), so test coverage tracks threat coverage, not just schema coverage.

Maturity Level 1

Objective: Establish a foundational per-archetype test battery and regression corpora that run in CI on every PR, and verify that every AI/HAI data flow reaches production with a passed go-live battery on record.

Activities.

A) Publish the foundational per-archetype test battery. One test battery per AI/HAI data archetype targeting the top archetype threats from TA-Data and the archetype-specific SR requirements. Each test class specifies inputs, expected output, pass/fail criteria, an evidence artifact (log snippet, scan output, CI run link), and the TA-Data threat plus SR-Data requirement it maps to. The training-corpus / training-dataset battery covers: a poison-detection scan in regression CI (run against a versioned poison-detection corpus of known-hostile record patterns, label-flipping signatures, backdoor-trigger phrases, systematic mislabeling artifacts, asserting zero poison-pattern matches above threshold, with failure blocking promotion, ATLAS TA0012 / AML.T0019); a classification-completeness scan (a sample of corpus records scanned against the SM-Data classification taxonomy, asserting correct labels and no data classes not approved in the DR-Data record); a consent-basis sample-verify (for a random sample of records, the link to the GDPR Art. 6 or Art. 9 lawful-basis record present and active, with failure a Critical finding); and a DPIA evidence check (if the DR-Data record flagged a DPIA trigger, the DPIA completion artifact linked and current before the corpus enters any training pipeline). The inference-input-stream battery covers a PII-redaction-edge canary test in regression CI (a canary PII record, synthetic SSN-format, synthetic card-number-format, injected into the inference-input test path, with the payload reaching the LLM provider API verified to have the PII redacted and the canary value absent from the outbound request log, run on every PR, ATLAS TA0013 / AML.T0025), a no-train probe (the vendor admin API queried, the no-train setting asserted active, with failure a Critical finding), and a classification-gated routing test (a test record classified as a regulated data class asserted not forwarded to a vendor where no-train has not been confirmed). The retrieval-store battery covers a retrieval-extraction probe corpus in regression CI (prefix-completion, empty-string, and wildcard queries asserting no query returns more than the declared per-query result cap, ATLAS TA0004 / TA0013), a retrieval-poisoning probe (a hostile document containing prompt-injection instructions inserted into a test index, with the injection-defense structure asserted to block the injected instructions, and the test document cleaned up after the run, ATLAS TA0012 / AML.T0019), a per-tenant retrieval-isolation test (a query from Tenant A matching a Tenant B document asserted to return zero results or a namespacing error, EA), and a classification-label-respecting test. The prompt/completion-log-corpus battery covers a redaction-at-logging test, a retention-expiry test, an export-control test, and an audit-log-completeness test. The embedding-store battery covers an inversion probe corpus in regression CI (nearest-neighbor queries asserting results do not reveal attributes beyond the declared query scope, ATLAS TA0013 / AML.T0025), a nearest-neighbor extraction probe, and a per-tenant partitioning test. The fine-tuning-dataset battery covers an opt-out enforcement test (a synthetic opted-out subject's records asserted excluded from the dataset presented to the fine-tune job), a consent-basis verify test, and a DPIA evidence check. The evaluation/test-set battery covers an isolation test (eval-set record IDs asserted to have zero overlap with training-pipeline record IDs via data-catalog lineage), a reproducibility test, and a corpus-completeness test.

B) Build and maintain regression corpora in CI. Six versioned regression corpora in source control, running in CI. Each corpus entry is a structured test fixture: input, expected safe outcome, threat tag (HAI TTP + ATLAS tactic/technique ID), OWASP reference, source, and date added. The poison-detection corpus carries poison-pattern fixtures targeting label-flipping signatures, backdoor-trigger phrases, and systematic mislabeling artifacts, run against training-corpus and fine-tuning-dataset archetypes, with failure blocking promotion for Critical/High-tier. The retrieval-extraction corpus carries query fixtures designed to attempt broad-corpus extraction via prefix-completion, wildcard, and empty-string patterns, run against retrieval-store and embedding-store archetypes. The retrieval-poisoning corpus carries hostile-document fixtures containing prompt-injection instruction payloads, seeded into test indexes, run against retrieval-store archetypes to verify injection-defense. The embedding-inversion corpus carries nearest-neighbor query fixtures designed to recover training-record attributes, run against embedding-store archetypes. The PII-redaction-edge corpus carries canary PII fixtures in diverse formats (synthetic SSN, card number, email, IBAN) injected into inference-input test paths. The DSAR-query corpus carries canary subject fixtures with known attributes, used to verify DSAR-surface accuracy (inclusion before deletion, exclusion after deletion) across all archetypes contributing to the DSAR surface. Corpora are versioned in source control; changes go through PR review with a named corpus owner. Refresh cadence is monthly minimum from three sources, internal observations (IR-Data findings, IM-Data incidents, red-team results), external public corpora (OWASP LLM Top 10 examples, ATLAS technique examples, academic poison-attack datasets), and community vulnerability disclosures. CI runs are budget-capped; failing runs are a blocking CI check for Critical/High-tier.

C) Operate the go-live battery and wire test failures to IM-Data. Every AI/HAI data flow must pass its archetype battery before receiving Sanctioned status in the SM-Data inventory. Go-live triggers: pre-production (all applicable archetype tests must pass before the flow enters production); post-corpus-update (any new data source added, classification scheme changed, or vendor LLM provider changed triggers a re-run of the applicable battery within 14 days, Critical-tier within 7 days); post-incident (any IM-Data incident involving the data flow triggers a re-run of the relevant battery subset before the incident is closed); quarterly (all active AI/HAI data flows re-run their battery, with results reviewed by the named test-battery owner). All test failures route to IM-Data within one business day with a severity tag derived from the ST severity rubric. Named battery owner per archetype is a named role, not a shared-team responsibility.

Outcome Metrics (L1).

Success Criteria.

• Per-archetype foundational test battery published for all seven archetypes, linked from the SM-Data inventory record and the DR-Data / IR-Data artifacts.
• Six regression corpora published in source control, running in CI on every PR for Critical/High-tier data flows, with a named corpus owner and a monthly refresh cadence.
• 100% of AI/HAI data flows reaching production in the last 90 days have a passed go-live battery on record.
• All test failures routed to IM-Data with a 1-day handoff SLA and named owner.
• Named battery owner per archetype; CI automation covers ≥60% of battery items; TA-Data archetype threat coverage ≥80%.

Maturity Level 2

Objective: Calibrate test depth per risk tier using the SM-Data L2 tier-treatment matrix, run per-tier red-team exercises using TA-Data L2 deep threat models, and test cross-archetype compositions for Critical-tier data flows.

Activities.

A) Tier-calibrated test battery and CI corpus depth. Publish a per-tier test treatment aligned to the SM-Data L2 tier-treatment matrix. Critical tier: the full archetype battery at go-live with all test classes; all six corpora on every PR with a Critical corpus separately tuned; a full-battery re-run within 7 days of any corpus or pipeline change; DSAR-query accuracy verified quarterly with failures routing to IM-Data within 1 business day; a vendor admin API no-train probe monthly. High tier: the full archetype battery in CI; all six corpora on merge; a full-battery re-run within 14 days; DSAR-query accuracy verified semi-annually; a no-train probe quarterly. Medium tier: a subset battery (top-4 threat classes) in CI; the poison-detection and PII-redaction-edge corpora on merge; a subset-battery re-run within 30 days; DSAR-query accuracy verified annually; a no-train probe semi-annually. Low tier: a spot-check (3 test classes) at go-live; the poison-detection corpus on merge; a battery re-run at the next quarterly; DSAR-query accuracy and no-train probe verified at go-live.

B) Scheduled per-tier red-team exercises using TA-Data L2 threat models. Red-team cadence by tier: Critical (quarterly, 4 per year, scope derived from the TA-Data L2 per-flow deep threat model, covering poison-injection attempts, retrieval-extraction probes beyond the CI corpus, cross-tenant isolation probes, embedding-inversion attacks, DSAR-surface enumeration, opt-out bypass attempts, and eval-training contamination probes); High (semi-annual, 2 per year, scope from TA-Data L2 flow deltas, covering the top-5 threats from the per-flow model); Medium/Low (ad-hoc before major corpus updates or consumer AI artifacts added, with the archetype snapshot driving scope). Each exercise follows the AI Security Testing Methodology: written rules of engagement, a test plan reviewed with the data-flow owner, an execution log, a structured findings report (severity, root cause, ATLAS tactic + technique ID, SR-Data requirement traced, remediation pairing). Cross-archetype composition tests for Critical-tier: training corpus + evaluation/test set (a contamination-prevention probe verifying no eval-set record IDs appear in the training corpus after a refresh); embedding store + retrieval store (an inversion-via-retrieval probe applying embedding-inversion techniques to vectors obtained through retrieval queries, asserting source-text reconstruction does not exceed the declared similarity threshold); inference input stream + prompt/completion log corpus (a PII-pass-through probe verifying a PII canary entering the inference-input stream does not appear unredacted in the log corpus); fine-tuning dataset + training corpus (a data-lineage cross-contamination probe verifying that a record removed from the training corpus via opt-out or deletion is also absent from the derived fine-tuning dataset).

C) Red-team findings to corpus pipeline. Every Critical or High-severity red-team finding produces: a new corpus entry (input, expected safe outcome, threat tag, ATLAS tactic/technique ID, date, source reference) committed to the relevant regression corpus within 30 days; an IM-Data finding with severity tag and the named data-flow owner as assignee; and a TA-Data library-gap ticket if the finding was not in the archetype library, tracked with a named owner and a 30-day close SLA for Critical-tier gaps. This pipeline ensures every quarterly red-team exercise produces durable CI coverage for the findings it surfaces.

Outcome Metrics (L2).

Success Criteria.

• Quarterly red-team for 100% of Critical-tier data flows; semi-annual for 100% of High-tier; scope tied to TA-Data L2 per-flow deep threat models.
• All six regression corpora running on every PR for Critical-tier data flows; per-tier calibration enforced.
• ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days.
• Cross-archetype composition tests documented and run for all Critical-tier data flows with composite archetype interactions.
• Per-tier SLA adherence for testing activities ≥90%.

Maturity Level 3

Objective: Operate continuous automated adversarial testing for Critical-tier data flows, publish regression corpora and test patterns as open artifacts, and contribute discovered data-attack techniques to MITRE ATLAS, AVID, OWASP LLM, and NIST AI RMF Data.

Activities.

A) Continuous automated adversarial testing harness. Deploy an automated adversarial testing harness that runs daily against all Critical-tier AI/HAI data flows. A poison-pattern generator produces novel poison-pattern variants by mutating the regression corpus (label-flip pattern variants, backdoor-trigger phrase mutations, template-based variation), run against training-corpus and fine-tuning-dataset archetypes. A retrieval-extraction ladder generator produces novel retrieval-extraction query sequences (prefix ladders, semantic near-duplicates, query-rate staircase patterns) to probe per-query cap enforcement, run against retrieval-store archetypes. An embedding-inversion probe generator produces nearest-neighbor query sequences designed to recover source-text attributes from embedding space, probing the inversion-defense boundary, run against embedding-store archetypes. A PII-redaction-edge mutator produces canary PII variants in novel formats and encoding patterns to probe redaction-edge completeness, run against inference-input-stream archetypes. Findings are triaged by a named ST-Data owner at least weekly. Novel data-attack techniques, patterns not in the TA-Data library, are fed into the TA-Data L3 auto-proposal pipeline within 14 days. High-severity automated findings route to IM-Data within 24 hours.

B) Contribute findings to industry. Contribute anonymized, legally-vetted findings to MITRE ATLAS (new data-attack technique observations, novel poison-pattern mechanics, new retrieval-extraction sequences, embedding-inversion variants not covered by AML.T0019 / AML.T0025 / AML.T0018, following ATLAS evidence-and-provenance requirements; target ≥2 contributions per year), the AI Vulnerability Database (AVID) (structured disclosure submissions for novel vulnerabilities in own-operated AI data flows or upstream pipeline dependencies, with coordinated disclosure where third-party components are involved), OWASP LLM Top 10 / NIST AI RMF Data (real-world telemetry evidence during revision cycles; target ≥2 substantive submissions per revision cycle), and external benchmarks (AISI Inspect evaluation benchmarks and sector ISAC AI data-security working groups, with anonymized findings).

C) Publish regression corpora and test patterns as open artifacts. Publish anonymized versions of all six regression corpora (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) under an open license, scrubbed of org-specific data classes, flow identifiers, and vendor names. The internal corpora are a superset of the published versions with org-specific entries not shared externally. Maintain the published versions upstream; internal updates that belong upstream are proposed as contributions, not silently retained. Host or co-host at least one industry data-security benchmark per year (an OWASP AI chapter, an ATLAS practitioner table, or a sector ISAC AI data working group); collect cross-org detection-benchmark improvement data from participants.

Outcome Metrics (L3).

Success Criteria.

• ≥80% of Critical-tier AI/HAI data flows under continuous automated adversarial testing with daily probe execution; novel data-attack techniques triaged into the TA-Data library within 14 days; high-severity findings routed to IM-Data within 24 hours.
• ≥4 industry contributions per year to MITRE ATLAS, AVID, OWASP LLM, or NIST AI RMF Data.
• ≥4 open regression corpora published under a permissive license and maintained upstream.
• ≥1 industry-shared exercise hosted per year plus ≥2 participated; cross-org detection-benchmark improvement documented.

Common Pitfalls

Level 1. - Test battery reduced to a schema-validation check and a classification-accuracy assertion, no behavioral adversarial probes (poison-detection scan, PII-redaction-edge canary, per-tenant retrieval isolation, embedding-inversion probe) are actually exercised. - Regression corpora committed to source control but not wired into CI, they exist but run only when a reviewer manually triggers them; coverage erodes after every sprint. - Go-live battery runs once pre-production but is never re-run after corpus updates, pipeline changes, or vendor LLM provider changes, test coverage erodes as the data flow evolves. - Test failures logged in a spreadsheet separate from IM-Data, no SLA enforcement, no aging visibility, no named owner; the same failure recurs across multiple deployments undetected.

Level 2. - Red-team scope defined as "injection probes" but retrieval-extraction ladders, cross-tenant isolation probes, embedding-inversion attacks, and DSAR-surface enumeration are excluded, the top threat classes for retrieval and embedding archetypes go untested. - Per-tier calibration documented in the tier-treatment matrix but the CI pipeline applies the same corpus to all tiers, Critical data flows run the same tests as Low; differentiation exists on paper only. - Red-team findings route to IM-Data but the finding-to-corpus pipeline is never executed, 12 months of Critical/High findings sit in IM-Data as closed tickets with no corpus entries; the same vulnerabilities are re-discovered at the next exercise. - Cross-archetype composition tests scoped but not executed because no engineer owns training-corpus-plus-eval-set testing, contamination-prevention failure modes are in the threat model but not in any test.

Level 3. - Continuous harness runs poison-pattern probes that the pipeline's pre-flight scan trivially blocks, the coverage metric looks good but the probes do not exercise the real threat surface; novel poison-pattern variants from recent research are not generated. - Industry contributions are legally-vetted case-study summaries rather than actionable, reproducible data-attack technique descriptions, ATLAS reviewers cannot map them to a technique ID; AVID submissions lack reproducibility notes. - Open corpora published once and then not maintained, external organizations build on a stale version while the internal corpus has 60 new entries; discrepancies surface at community exercises. - New data-attack technique ingestion from automated probes to the TA-Data library is manual and quarterly, by the time a novel technique reaches SR-Data and SA-Data updates and is reflected in controls, the technique is already being exploited in the wild.

Practice Maturity Questions

Level 1. 1. Is a per-archetype foundational test battery published for all seven AI/HAI data archetypes, with each test class tied to a TA-Data archetype threat (HAI TTP + ATLAS tactic/technique ID) and an SR-Data requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI data flows required to pass the battery before production Sanctioned status is issued? Evidence: Published battery documents per archetype with a TA-threat and SR-requirement traceability table; SM-Data inventory showing Sanctioned entries with a passed go-live battery record linked; sample test run with an evidence artifact attached. 2. Are six regression corpora (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) versioned in source control, running in CI on every PR for Critical/High-tier data flows, with a named corpus owner, a monthly refresh cadence from internal and external sources, and a CI compute-budget cap, and are ≥95% of Critical/High-tier PR merges verified to have run and passed the applicable corpus? Evidence: Source-control repository showing six corpus directories with version history and corpus owner in CODEOWNERS; CI telemetry report showing corpus run results per PR for the last 30 days; monthly corpus refresh commit log. 3. Are all test failures routed to IM-Data within 1 business day with a severity tag and named owner, and does TA-Data archetype threat coverage by the test battery and corpus reach ≥80% by end of year one? Evidence: IM-Data query for ST-originated issues with creation timestamps within 24 hours of test failure; threat-coverage matrix mapping TA-Data archetype threats to battery test classes and corpus entries showing a ≥80% coverage ratio.

Level 2. 1. Are 100% of Critical-tier AI/HAI data flows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Data L2 per-flow deep threat models, covering poison-injection attempts, retrieval-extraction probes beyond the CI corpus, cross-tenant isolation probes, embedding-inversion attacks, DSAR-surface enumeration, opt-out bypass attempts, and eval-training contamination probes, with findings routed to IM-Data and remediation tracked? Evidence: ST-Data records showing red-team exercise dates per Critical and High-tier data flow for the last 12 months; red-team report for the most recent Critical-tier exercise showing scope sourced from the TA-Data L2 per-flow model; IM-Data findings linked from the report. 2. Is per-tier corpus calibration enforced in CI (Critical-tier: all six corpora on every PR plus a monthly no-train probe and a quarterly DSAR-query accuracy test; Low-tier: the poison-detection corpus on merge), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? Evidence: CI pipeline configuration showing per-tier corpus routing; CI telemetry confirming corpus depth per tier; finding-to-corpus pipeline telemetry showing the conversion rate and lead times. 3. Are cross-archetype composition tests (training-plus-eval contamination, embedding-plus-retrieval inversion, PII-input-plus-log-corpus pass-through, fine-tuning-plus-training lineage propagation) documented and executed for all Critical-tier data flows with composite archetype interactions, and is per-tier SLA adherence for testing activities ≥90%? Evidence: Composition test plans per Critical-tier composite data flow; execution logs with pass/fail results; per-tier SLA adherence report from program telemetry for the last two quarters.

Level 3. 1. Are ≥80% of Critical-tier AI/HAI data flows under continuous automated adversarial testing with daily probe execution, using poison-pattern generators, retrieval-extraction ladder generators, embedding-inversion probe generators, and PII-redaction-edge mutators, with novel data-attack techniques triaged into the TA-Data library within 14 days and high-severity automated findings routed to IM-Data within 24 hours? Evidence: ST harness telemetry showing daily probe execution per Critical data flow; harness-to-TA-Data-library pipeline log with lead time per novel technique; IM-Data high-severity finding creation timestamps within 24 hours of automated detection. 2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, OWASP LLM, or NIST AI RMF Data, with at least one accepted as a new or refined data-attack technique, and are ≥4 open regression corpora published under a permissive license and maintained upstream? Evidence: Contribution log with external submission links and acceptance confirmation from ATLAS, AVID, or OWASP; open-source repository links for the published corpora with commit history showing active maintenance; legal review records for each submission. 3. Has the program hosted at least 1 industry-shared data-security exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data from participants? Evidence: Exercise log with hosted and participated entries for the last 12 months; post-exercise report showing detection-benchmark data collected from participants; co-published results or testimonials from at least one cross-org partner.

23. Environment Hardening (EH)

Practice Overview

Objective: Harden the storage, pipeline, access, cross-border, and egress envelopes that surround the data flowing into and out of AI/HAI systems, training corpora, inference inputs, retrieval stores, prompt/completion logs, embeddings, fine-tuning datasets, and evaluation/test sets, so each data asset rests, moves, and leaves the boundary under controls calibrated to its classification tier.

Description: EH-Data tunes the organization's existing storage, identity, network, and DLP controls for the specific surfaces AI/HAI data assets create. Five envelope dimensions are in scope: the storage envelope (encryption at rest with HSM-rooted keys, key separation per tenant, per-classification-tier storage backends, replication and backup policy aligned to retention, deletion verification on expiry); the pipeline envelope (encryption in transit via mTLS, pipeline service-account least-privilege, CI/CD secrets management for data-pipeline credentials, signed dataset artifacts, SLSA-style provenance for training datasets and embedding artifacts, deny-listing of known-poisoned upstream datasets); the access envelope (SSO + MFA on data catalogs, model registries, prompt-log stores, and vector stores, RBAC with classification-aware authorization, a service-principal model for pipeline access, audit logging on every access, just-in-time access for sensitive datasets); the cross-border envelope (data-residency enforcement via region pinning, transfer-mechanism gates for SCC / adequacy / BCR, cross-region replication policy aligned to GDPR Arts. 44–49); and the egress envelope (DLP tuned for AI-specific exfiltration, bulk-embedding exports, prompt/completion-log bulk exports, training-dataset exports, model-weight exfiltration where regulated content crosses the boundary without explicit approval).

Context: AI/HAI data assets accumulate risks that classic data-governance controls were not designed to address. A training corpus containing withdrawn-consent subjects sits in an object-storage bucket with no retention enforcement. A retrieval store holds confidential documents ingested without classification labels, queryable by any service account with read access. Prompt/completion logs accumulate PII in clear-text because the logging pipeline was wired before Privacy reviewed it. Fine-tuning datasets cross a data-residency boundary during a cloud migration that nobody mapped to GDPR Art. 44. Embedding files are exported in bulk to a contractor environment without DLP triggering because the rules match credit-card numbers, not high-dimensional float arrays. EH-Data closes these gaps not by adding new tooling but by tuning controls the organization already operates, storage encryption policies, IAM, secrets vaults, DLP, egress allowlists, data catalogs, for the specific surfaces the seven AI/HAI data archetypes create. The HAI TTPs EA and TM are mitigated here at the perimeter level: EA via least-privilege pipeline service accounts, classification-aware authorization, and egress allowlists; TM via DLP tuned to AI-specific bulk-export patterns and storage-layer access controls that constrain how data stores can be queried and exfiltrated.

Maturity Level 1

Objective: Harden the storage, pipeline, access, cross-border, and egress envelopes for all seven AI/HAI data archetypes so each data asset rests and moves under baseline controls aligned to its classification tier.

Activities.

A) Harden the storage and pipeline envelopes. For every AI/HAI data asset registered in the SM-Data inventory, training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set, establish and enforce a minimum storage and pipeline hardening baseline. All seven archetypes are encrypted at rest using the platform's default AES-256 (or equivalent) backend; assets classified Confidential or higher use a dedicated KMS or HSM-rooted key rather than a shared platform default. Where a storage backend serves multiple tenants, a shared vector store, a shared prompt-log store, each tenant's data is encrypted under a separate key or in a separate storage partition with an access-control boundary; shared-key architectures for Confidential-or-higher assets are a blocking finding. Regulated data classes (PII, PHI, PCI) are stored in backends certified for the applicable compliance regime; mixed-tier storage of regulated and public data in the same bucket or table without access-control partitioning is a blocking finding. Replication and backup policies are aligned to each asset's retention and regulatory requirements, with regulated-data backups encrypted under separate keys and access-gated identically to the primary store. For assets with a defined retention expiry, deletion verification runs at the expiry date; cryptographic deletion is the target for Confidential-or-higher assets and soft-delete with a 30-day hold is acceptable for Low-classification assets. Every data-pipeline connection uses TLS 1.2 minimum, with mTLS required for connections crossing trust boundaries; plaintext pipeline connections are blocking findings. Training corpora and fine-tuning datasets promoted through the pipeline carry a provenance attestation, source, classification, consent basis, lineage, processing-job identity, and any promotion without a signed attestation is blocked at the pipeline gate. A deny-list of known-poisoned dataset sources, cross-referenced from ATLAS advisories, AVID, and internal ST-Data findings, is checked at ingestion for training corpora and fine-tuning datasets. Each pipeline component runs under a named service account with access only to the specific asset paths it requires; wildcard IAM policies and shared credentials across pipeline stages are prohibited.

B) Harden the access envelope. The data catalog, model registry, prompt-log store console, vector store console, embedding store console, and evaluation harness console all require SSO/SAML/OIDC with MFA; local-account access is disabled for org-domain identities. Access to each AI/HAI data asset is governed by a role that maps to the asset's classification tier, a role granting read access to Public data does not grant read access to Confidential data in the same catalog, and classification-aware authorization is enforced at the data-catalog or storage layer, not only at the application layer. Data pipelines access AI/HAI data assets exclusively through named service principals; no pipeline uses interactive user credentials or shared static keys; service-principal credentials live in a secrets vault with a rotation cadence of ≤90 days. Every read, write, export, and delete event on AI/HAI data assets is logged to an append-only audit log, and audit-log access is separated from the data-asset access role so a pipeline service account that writes to the training corpus cannot delete or modify the corpus audit log. For training corpora, fine-tuning datasets, and evaluation/test sets classified Confidential or higher, interactive human access is granted just-in-time, scoped, time-limited to ≤8 hours, approval-gated, rather than via standing permissions; standing interactive access to sensitive dataset stores is a blocking finding. All data-pipeline credentials (storage access keys, database connection strings, embedding and evaluation API keys) are managed in the secrets vault; plaintext credentials in pipeline scripts, configuration files, or CI/CD environment variables are blocking findings, and CI secrets-scanning is enforced on every PR touching data-pipeline code.

C) Harden the cross-border and egress envelopes. For AI/HAI data assets subject to data-residency requirements (PII, PHI, regulated financial data), storage and processing are pinned to the approved region; cross-region replication requires an explicit transfer-mechanism gate, SCC, adequacy decision, or BCR, documented before replication activates, and unapproved cross-region replication is a blocking finding. For every cross-border flow involving regulated data assets, the applicable GDPR transfer mechanism is documented in the data-asset record, and flows without documentation are blocked at the pipeline gate until the record is on file. Existing cross-region replication configurations for all seven archetypes are audited against the transfer-mechanism registry, and any configuration without a matching record is flagged as an open IM-Data finding. The DLP system's egress rules are extended to cover AI-specific exfiltration patterns: bulk-embedding exports (large float-array files or batch embedding API exports to external destinations), prompt/completion-log bulk exports, training-dataset exports to unmanaged storage, and bulk exports of inference request payloads, with DLP rules alerting or blocking based on the classification of the data being exported. Regulated data cannot leave the approved storage boundary without an explicit approval gate; egress of regulated data to an unapproved destination is a blocking finding, and a shadow-AI data-flow alert fires when a pipeline service account initiates a bulk export to a destination not in the declared data-flow map.

Outcome Metrics (L1).

Success Criteria.

• 100% of AI/HAI data assets in production have a classification label, a named owner, and a baseline hardening status in the SM-Data inventory; no unclassified asset is accessible by any pipeline service account.
• 100% of training corpora and fine-tuning datasets carry signed SLSA-style provenance attestations at promotion; promotion without provenance is blocked by the pipeline gate.
• 100% of data-facing consoles require SSO + MFA; all pipeline service accounts use named, vault-managed credentials; CI secrets-scanning is enforced with zero current hardcoded-credential findings.
• Cross-border replication for regulated data assets is documented with transfer mechanisms; all existing replication configurations are reconciled against the transfer-mechanism registry.
• DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) are deployed and active.

Maturity Level 2

Objective: Calibrate hardening depth per the SM-Data L2 tier-treatment matrix, Critical-tier data assets receive HSM-rooted per-tenant key management, content-inspection DLP, zero-trust just-in-time access, and storage-layer residency enforcement; Low-tier assets stay on baseline L1 controls.

Activities.

A) Tier-conditional hardening calibration. Publish and enforce a hardening tier-treatment matrix aligned to the SM-Data L2 risk-tier rubric. Critical-tier data assets receive HSM-rooted keys with per-tenant separation and ≤30-day rotation, a dedicated compliance-certified storage backend with no multi-tier mixing, per-component pipeline service accounts with mTLS and ephemeral credentials, zero-trust just-in-time console access (≤4-hour time-limited, approval-gated, full session audit), audit logs retained for the longest regulatory window with separate access control, content-inspection DLP on all egress paths with bulk-export blocking, transfer-mechanism gating enforced at the storage layer, and cryptographic deletion at expiry. High-tier assets receive KMS-managed per-asset keys with ≤90-day rotation, a partitioned compliance-certified backend, per-component service accounts with mTLS preferred, SSO + MFA with JIT preferred and standing access reviewed quarterly, enhanced DLP with bulk-export alerting, and documented transfer mechanisms with monitored residency. Medium-tier assets receive KMS-managed keys with ≤180-day rotation, a standard secure backend, named service accounts, standard AI-specific DLP, and documented transfer mechanisms. Low-tier assets stay on baseline L1 controls. Each AI/HAI data asset record in the SM-Data inventory carries its tier's hardening status, and gaps between required and actual controls become open IM-Data findings with an SLA matching the asset's tier.

B) HSM-rooted key management and zero-trust data access for Critical-tier. For all Critical-tier AI/HAI data assets, key material is generated and stored in an HSM (AWS CloudHSM, GCP Cloud HSM, Azure Dedicated HSM, or on-premise HSM); no Critical-tier key resides in software-only KMS, per-tenant key separation is enforced at the HSM level where a shared backend serves multiple tenants, and key rotation runs ≤30 days. For Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets there is no standing interactive read or write access, access is just-in-time, scoped to the specific dataset path, time-limited to ≤4 hours, and approval-gated; approval-gate records (requestor, purpose, approver, grant time, expiry) are written to the audit log at grant time and session activity during the JIT window is logged at the storage layer. JIT access tooling is integrated with the secrets vault and the data catalog's access-control plane; manual credential sharing as a workaround is a blocking IM-Data finding. Critical-tier data pipelines use ephemeral credentials, short-lived IAM tokens rather than long-lived service-account keys, with token lifetime ≤1 hour and token revocation on pipeline completion logged to the audit trail.

C) Enhanced DLP and cross-border residency enforcement. For Critical-tier data asset egress paths, extend DLP from pattern matching to content inspection: prompt/completion-log bulk exports are inspected for PII patterns before export to any destination outside the approved boundary; training-dataset exports are inspected for regulated data classes and blocked when regulated data is detected without an explicit approval gate; bulk exports of embedding vectors from Critical-tier embedding stores are alerted on and blocked above size thresholds without explicit approval. Each of the seven data archetypes carries at least one custom DLP pattern tuned to its exfiltration surface, archive-file exports with dataset metadata headers for training corpora and fine-tuning datasets, bulk batch-inference request exports for inference input streams, bulk vector-file exports for retrieval and embedding stores, structured log exports for prompt/completion log corpora, and labeled-dataset-format exports for evaluation/test sets. For Critical-tier and High-tier residency-controlled assets, residency enforcement is implemented at the storage layer, region-locked S3 bucket policies, GCP Organization Policy constraints, Azure policy locks on storage accounts, rather than relying solely on application-layer controls, and any storage-layer policy change that would permit cross-region replication for a residency-controlled Critical-tier asset triggers an IM-Data finding.

Outcome Metrics (L2).

Success Criteria.

• 100% of Critical-tier data assets are under HSM-rooted key management with per-tenant key separation and ≤30-day key rotation.
• 100% of Critical-tier data assets have zero-trust JIT access; no standing interactive credentials exist for Critical-tier training corpora, fine-tuning datasets, or evaluation/test sets.
• ≥90% of Critical-tier data asset egress paths have content-inspection DLP active; the false-positive rate is monitored and trending down.
• The tier-hardening matrix is published and enforced at provisioning; SM-Data inventory records show hardening status per tier; gaps are open IM-Data findings.
• Storage-layer residency enforcement is active for 100% of Critical-tier and High-tier residency-controlled data assets.

Maturity Level 3

Objective: Express all EH-Data controls as IaC, drive adaptive policy tightening from ML-Data detections and IM-Data incidents, auto-provision tier-appropriate hardening for new data assets, and contribute AI/HAI data hardening baselines to OpenSSF AI, DAMA, EDM Council, and sector ISACs.

Activities.

A) Hardening-as-code. Express every EH-Data control as a version-controlled, parameterized IaC module: a storage-envelope module for backend provisioning (encryption configuration, key-management policy attachment, compliance-tier selection, bucket/table access policy, cross-region replication policy with transfer-mechanism gate, deletion and lifecycle-rule configuration); a pipeline-envelope module for service-account creation (named identity, least-privilege IAM, mTLS configuration, secrets-vault path provisioning, ephemeral-credential rotation schedule) plus reusable CI/CD components for provenance-attestation enforcement and the poisoned-source deny-list check; an access-envelope module for data-catalog and vector-store console controls (SSO enforcement, JIT access for Critical/High-tier, audit-log destination, RBAC policy); a cross-border module for residency enforcement (region-lock storage policy, transfer-mechanism registry reference, replication gating, policy-change alerting on residency-controlled assets); and an egress module expressing AI-specific DLP rules, content-inspection policies, archetype-specific custom patterns, and pipeline egress allowlists as configuration-as-code for DLP and CASB platforms. Modules are version-pinned and updates notify consuming data-engineering teams with a required-remediation flag. A drift-detection pipeline runs hourly against all deployed data-asset configurations; low-risk drift is auto-remediated, while high-risk drift, key-management downgrade, access-control loosening, egress-allowlist expansion for regulated assets, raises a human-review alert within 2 business days and opens an IM-Data finding.

B) Adaptive policy tightening from ML-Data and IM-Data signals. Wire ML-Data detection signals and IM-Data incident patterns to a human-approved adaptive-tightening pipeline. A retrieval extraction attempt produces an egress-narrowing proposal for the affected retrieval store's service account; an embedding inversion attempt produces an embedding-store access-lockdown proposal and an enhanced egress DLP tightening proposal; a cross-border flow violation produces a residency-enforcement tightening proposal and a transfer-mechanism registry update trigger; a bulk egress anomaly from a data-pipeline service account produces an egress-allowlist review proposal and a DLP sensitivity-increase proposal. IM-Data post-incident review records that identify a hardening gap produce a hardening-baseline update proposal, and a Critical-tier incident involving a misconfigured storage access policy produces a zero-trust access upgrade proposal for the affected tier. Proposals are human-reviewed by a security platform engineer before deploy, the change log is machine-readable, and downstream data-engineering teams are notified within 24 hours of a tightening change affecting their asset's hardening profile. Hardening changes that reflect a new threat pattern are fed back to the TA-Data threat library and the SR-Data requirements pack as candidate new entries, the adaptive loop is bidirectional.

C) Contribute hardening baselines to industry. Contribute anonymized EH-Data hardening baseline modules to OpenSSF AI (dataset provenance attestation standards, pipeline service-account least-privilege patterns, signed-artifact verification for training datasets), to DAMA (AI/HAI data asset classification schemes, key-management tier treatment, retention and deletion-verification standards), to the EDM Council (financial-sector AI data governance hardening patterns), and to sector ISACs, FS-ISAC, H-ISAC, IT-ISAC AI working groups, for sector-relevant hardening patterns in regulated environments. Target ≥2 substantive contributions per year, maintained upstream, with internal practice aligned to the published external version. Auto-provisioning fires on SM-Data inventory registration: when a new AI/HAI data asset is registered, the IaC automation provisions its tier-appropriate hardening profile within 24 hours, and a tier-change signal triggers a hardening-profile upgrade rather than a retroactive IR-Data or IM-Data finding.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of EH-Data controls are expressed as authoritative IaC; drift is detected continuously, ≥70% of low-risk drift is auto-remediated, and high-risk drift is human-reviewed within 2 business days.
• The adaptive-policy pipeline is operational with ML-Data and IM-Data signal sources; every change is traceable to a source signal and downstream teams are notified within 24 hours.
• New AI/HAI data assets are auto-provisioned with tier-appropriate hardening within 24 hours of SM-Data inventory registration.
• ≥2 industry hardening baseline contributions per year (OpenSSF AI, DAMA, EDM Council, sector ISACs) with documented adoption.

Common Pitfalls

Level 1. - Classification labels are added to the data catalog but not enforced at the storage or pipeline layer, a service account with an "internal" role reads a "regulated" dataset because the storage access policy was never updated to reflect the classification. - Provenance attestations are required by policy but not enforced at the pipeline gate, training jobs consume unsigned datasets because the gate check is an informational warning rather than a blocking step. - SSO is enforced on the data-catalog console but the underlying storage backend still accepts direct access via long-lived storage-account keys held by pipeline team members, the SSO enforcement is a UI control, not a storage-layer policy. - DLP rules are tuned for credit-card numbers and SSNs but not for AI-specific egress patterns, bulk embedding exports to a contractor bucket go undetected because the engine does not recognize high-dimensional float arrays as sensitive.

Level 2. - HSM-rooted key management is declared for Critical-tier assets but the HSM integration sits only at the KMS level, the storage backend encrypts with a software-KMS-wrapped key and never calls the HSM directly, so an HSM compromise does not actually protect the data at rest. - JIT access for Critical-tier datasets is implemented via a ticketing workflow but the underlying IAM still grants standing read permissions to the approver role, the JIT process is a ceremonial approval step and the underlying access control is unchanged. - Content-inspection DLP is scoped to browser-based download traffic but the training-dataset bulk-export vector is a CI/CD pipeline step running as a background service, the DLP controls the human-facing surface and misses the programmatic exfiltration path entirely. - The tier-hardening matrix exists but is evaluated only during DR review and never at provisioning, a new High-tier data asset goes live with Medium-tier baseline controls because the provisioning template was copied from an older asset and the tier field was not updated.

Level 3. - IaC coverage is declared at ≥90% but the registry counts data assets that have an IaC stub rather than assets whose IaC is the authoritative deployed source, drift accumulates between the stub and the live configuration. - The adaptive-policy pipeline is wired to ML-Data detections but not to IM-Data incidents, post-incident hardening opportunities surfaced by IR-Data reviews never convert to tightening proposals. - Industry hardening baselines are contributed once and not maintained upstream, internal practice advances while the published DAMA or OpenSSF contribution reflects a 12-month-old state and external adopters find the public version conflicts with the program's current guidance. - The auto-provisioning trigger fires but reads a cached tier field, a Medium-to-Critical tier upgrade is reflected in the SM-Data inventory within hours but the hardening profile is not upgraded.

Practice Maturity Questions

Level 1. 1. Does every AI/HAI data asset in the SM-Data inventory (across all seven archetypes: training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set) carry a classification label, a named owner, and a baseline hardening status, and are all training corpora and fine-tuning datasets gated at promotion by a signed SLSA-style provenance attestation that blocks unsigned datasets? Evidence: SM-Data inventory audit; data-pipeline gate telemetry showing 100% signed-provenance coverage on the last 30 days of promotions. 2. Do all data-facing consoles (data catalog, model registry, prompt-log store, vector store, embedding store) require SSO + MFA, with all pipeline service accounts running under named vault-managed credentials confirmed by CI secrets-scanning with zero hardcoded-credential findings, and is every read, write, export, and delete event written to an append-only audit log with access-control separation between pipeline teams and log administrators? Evidence: IdP configuration audit; secrets vault audit; CI secrets-scan telemetry; audit-log configuration export. 3. Are cross-border flows for regulated data assets documented with a transfer mechanism (SCC / adequacy / BCR) on file before replication activates, with all existing replication configurations reconciled against the transfer-mechanism registry, and are DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and actively monitored? Evidence: transfer-mechanism registry; cross-region replication reconciliation report; DLP management console policy export.

Level 2. 1. Are 100% of Critical-tier AI/HAI data assets under HSM-rooted key management with per-tenant key separation at the storage layer and ≤30-day rotation, and is zero-trust JIT access (≤4-hour time-limited, approval-gated) enforced for all interactive access to Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets, with standing interactive credentials deprecated for Critical-tier? Evidence: KMS / HSM audit; IAM audit telemetry showing zero standing interactive grants on Critical-tier; JIT-access approval log. 2. Are ≥90% of Critical-tier data asset egress paths subject to content-inspection DLP, with false-positive rates monitored monthly and trending down, and is a tier-hardening matrix published and enforced at provisioning with gaps tracked as open IM-Data findings? Evidence: DLP management console policy export; FP rate trend across the last 6 months; published tier-hardening matrix and provisioning-gate configuration. 3. Is storage-layer residency enforcement (region-locked storage policies, not application-layer only) active for 100% of Critical-tier and High-tier residency-controlled data assets, confirmed by a quarterly storage-policy audit, and are archetype-specific custom DLP patterns deployed for each of the seven AI/HAI data archetypes? Evidence: storage policy audit; quarterly residency-enforcement audit records; DLP custom-pattern registry mapped to the seven archetypes.

Level 3. 1. Are ≥90% of EH-Data controls expressed as authoritative IaC (not stubs) in a version-controlled registry, with drift detected continuously, ≥70% of low-risk drift auto-remediated, a machine-readable change log visible to downstream data-engineering teams, and high-risk drift human-reviewed within 2 business days? Evidence: IaC registry inventory; drift-detection telemetry; auto-remediation rate; change-log export. 2. Is the adaptive-policy pipeline operational, with ML-Data detections and IM-Data incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream data-engineering teams notified within 24 hours of a tightening change affecting their asset's hardening profile? Evidence: adaptive-policy change log with ML-Data / IM-Data source references; human-approval records; downstream-team notification log. 3. Does the program contribute ≥2 AI/HAI data hardening baselines per year to industry bodies (OpenSSF AI, DAMA, EDM Council, sector ISACs) with documented adoption, and are new AI/HAI data assets auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Data inventory registration? Evidence: contribution log with upstream adoption references; auto-provisioning telemetry tied to SM-Data registration events.

24. Issue Management (IM)

Practice Overview

Objective: Run a single unified backlog and a single tier-calibrated incident playbook for every AI/HAI data issue the organization governs, findings from TA-Data snapshots, SR-Data REM gaps, DR-Data conditions, IR-Data drifts, ST-Data failures, ML-Data detections, and external advisories, with named owners, tier-aware SLAs, AI-specific data containment plays, and regulatory SLA tracking that never misses a notification window because of organizational diffusion.

Description: IM-Data is the clearinghouse for everything the other Data-domain practices produce. Every TA-Data threat-snapshot row that carries residual risk, every SR-Data REM accepted gap with an owner and expiry, every DR-Data approve-with-conditions item, every IR-Data drift finding, every ST-Data CI corpus failure or red-team finding, every ML-Data detection that fires, and every external advisory, ATLAS data-attack technique updates, AVID submissions, GDPR enforcement decisions, DPA enforcement actions, sector-regulator AI advisories, flows into a single, prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous playbook. The playbook contains AI-specific data containment plays: training-corpus poisoning containment, retrieval-store extraction containment, embedding-inversion containment, prompt/completion-log breach containment, cross-border-flow violation containment, consent-withdrawal non-propagation remediation, and DSAR fulfillment failure escalation. Every Critical/blocker data incident receives a post-incident review whose outputs feed back to SA-Data (pattern update), SR-Data (requirements-pack update), EG-Data (training content), and ML-Data (detection update). The regulatory SLA tracker ensures the GDPR Art. 33 72-hour clock, GDPR Art. 34 high-risk-to-data-subject notification, EU AI Act Art. 73 serious-incident reporting, HIPAA breach notification, NYDFS Part 500, and state privacy-law notification windows are never missed.

Context: Without a unified backlog, AI/HAI data issues scatter across privacy dashboards, data-engineering Jira projects, compliance trackers, and ML-platform alert channels. TA-Data residual risks from a training-corpus poison threat age without remediation owners. SR-Data REM gaps renew silently past their expiry dates. An ML-Data canary-leakage detection fires on a Friday and routes to the data-platform alert channel with no named on-call owner. A consent-withdrawal event is recorded in the consent-management system but never propagates to the training pipeline because no IM-Data backlog entry tracks propagation SLAs. The GDPR Art. 33 72-hour clock starts the moment the organization becomes aware of a personal-data breach, not when the responsible team processes the notification. IM-Data closes these gaps with a single backlog, one triage rubric, a named on-call path for every severity class, and a regulatory SLA tracker that begins counting from the first internal awareness event rather than from when a ticket is eventually filed.

Maturity Level 1

Objective: Operate a single unified AI/HAI data issue backlog with a standard triage rubric, an AI-specific data incident playbook covering the seven primary data incident classes, and regulatory SLA tracking for GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, and state privacy-law obligations.

Activities.

A) Stand up the AI/HAI data issue backlog and triage rubric. One backlog with standardized metadata per issue: source (TA-Data threat-snapshot residual risk / SR-Data REM accepted gap / DR-Data approve-with-conditions item / IR-Data drift finding / ST-Data CI corpus failure or red-team finding / ML-Data detection alert / external advisory); affected data asset(s) linked to the SM-Data inventory with archetype, classification tier, and owning team; severity anchored to AI-specific data axes; named owner from the SM-Data inventory with an escalation path to the program sponsor; an SLA target; an evidence link to the originating artifact; and a regulatory flag indicating whether the issue carries a notification obligation (GDPR Art. 33 clock started, GDPR Art. 34 high-risk-to-data-subject notification triggered, EU AI Act Art. 73 clock started, HIPAA breach notification triggered, NYDFS Part 500 triggered, state privacy-law notification triggered). The AI-specific data severity rubric: Critical means confirmed regulated-data exfiltration from any AI/HAI data asset, confirmed training-corpus poisoning, a DSAR that cannot be fulfilled because the required data cannot be located or exported within the statutory window, a confirmed cross-border flow of regulated data without a legal transfer mechanism, or a personal-data breach in an AI/HAI data asset triggering GDPR Art. 33; High means a confirmed control failure in a production data asset with potential for harm if not contained (a retrieval-extraction attempt detected without confirmed exfiltration, an embedding-inversion attempt detected, a no-train flag changed without IM-Data review approval, a consent-withdrawal propagation failure past the 30-day SLA); Medium covers confirmed gaps in non-production data assets or compensating-control-protected production assets, SR-Data REM accepted gaps past expiry without renewal, IR-Data drift findings on Medium-tier assets, and retention-policy violations on Low or Medium-tier assets; Low captures informational items, unassessed external recommendations, Low-tier logging gaps, and minor classification-label discrepancies without an active data-flow impact. Published SLAs: Critical acknowledge ≤4h / contain ≤48h / root-cause ≤30d; High ack ≤24h / contain ≤7d / root-cause ≤45d; Medium ack ≤48h / remediate ≤14d; Low ack ≤5 business days / remediate ≤30d. Triage cadence: daily for Critical and new High; weekly for Medium; monthly aging review for the full backlog.

B) Publish the AI-specific data incident playbook. Publish playbook entries for the seven primary AI/HAI data incident classes; each entry names trigger conditions, pre-assigned roles (data-asset owner, Privacy/Legal contact, executive sponsor escalation path), step-by-step containment, artifacts to collect, evidence-capture instructions for the deployer-duty record, closure criteria, and SLA targets. Training-corpus poisoning containment (ATLAS TA0014 Impact / TM TTP) quarantines the affected dataset by revoking the pipeline service account's access to the quarantined path, rolls back affected model versions trained on the poisoned corpus, replays the eval harness to confirm the poisoning effect is absent, conducts a lineage audit to identify all derived training jobs and model versions, assesses GDPR Art. 33 exposure if the poisoned data included personal data, and updates the dataset deny-list. Retrieval-store extraction containment (ATLAS TA0013 Exfiltration / TM TTP) disables the retrieval store for the affected principal or query path, implements a classification-gated query allowlist, assesses which documents were accessed and whether they included personal data, and re-enables the store under per-principal rate limits. Embedding-inversion containment (ATLAS TA0013 / TM TTP) locks down bulk-export access on the embedding store, tightens the inversion-defense configuration per the SA-Data reference pattern, assesses whether accessed embeddings correspond to recoverable personal data, and evaluates GDPR Arts. 33/34. Prompt/completion-log corpus breach containment (ATLAS TA0013 / EA TTP) disables export access for non-essential principals, scopes the breach, engages Privacy/Legal for the GDPR Art. 33 clock evaluation, assesses Art. 34 direct-notification obligations, and re-enables the log store under enhanced controls. Cross-border-flow violation containment (ATLAS TA0013 / EA TTP) disables the cross-border replication, assesses which regulated assets were transferred and to which region, engages Privacy/Legal to determine the appropriate transfer mechanism before re-enabling, and notifies the supervisory authority where the transfer constitutes a reportable breach. Consent-withdrawal-not-propagated remediation (ATLAS TA0014 / EA TTP) audits the training set using the lineage registry, generates deletion/exclusion events for affected records, evaluates whether dependent model versions must be rolled back or retrained, confirms fulfillment to the data subject, and updates the ML-Data consent-propagation SLA monitoring. DSAR fulfillment failure escalation (GDPR Art. 15 / Art. 12 / EA TTP) escalates to Privacy/Legal, activates the manual-fulfillment path by querying the SM-Data inventory for in-scope assets, notifies the data subject of any delay within the 30-day window, and opens a Critical IM-Data finding where the failure reflects a systemic gap in the ML-Data export path.

C) Track regulatory SLAs and run post-incident reviews. The regulatory SLA tracker is live with named obligations and automated escalation as deadlines approach. GDPR Art. 33: a 72-hour supervisory-authority notification window starting on the first internal alert that constitutes awareness, an ML-Data detection fire, an IR-Data finding, an external notification, or a data-subject complaint; named owner Privacy/Legal; once a clock starts from an AI/HAI data incident, a daily-at-minimum status update is required until the notification is filed or the clock expires. GDPR Art. 34: direct notification to data subjects for high-risk breaches, without undue delay; named owner Privacy/Legal; flagged immediately on any Art. 33-triggering data incident for high-risk assessment. EU AI Act Art. 73: serious-incident reporting for Annex III high-risk systems on the timeline set by the implementing act; named owner Privacy/Legal plus executive sponsor; escalation immediate on any Annex III-classified data asset incident. HIPAA: a 60-day discovery-to-notification ceiling for covered entities and business associates, with HHS Secretary notification within 60 days; named owner Privacy/Legal; flag any AI/HAI data incident involving PHI immediately. NYDFS Part 500: 72-hour notification to the Superintendent for material cybersecurity events; named owner CISO plus Privacy/Legal. PCI-DSS cardholder-data breach obligations and CCPA/CPRA and US state breach-notification laws carry named owners per the organization's compliance program. Every Critical or blocker data incident receives a post-incident review within 14 days of containment covering what happened (root cause, initiation path, controls that failed or were absent), what caught it (which ML-Data detection or IM-Data source surfaced it first, and whether this was the expected detection path or a gap), what did not catch it, and update outputs to SA-Data (pattern-update request if an architectural gap was exploited), SR-Data (requirements-pack update if a missing or vague data-handling requirement was exploited), EG-Data (training-content update if the incident indicates a literacy gap in the data-engineering or privacy-compliance population), and ML-Data (detection-update request, new detection, tuned query, or evidence that an existing detection can be sharpened). Post-incident review outputs are tracked as IM-Data issues of type "improvement" and age against the same process metric cadence as other issues.

Outcome Metrics (L1).

Success Criteria.

• A single AI/HAI data issue backlog is operational with standardized metadata; an AI-specific data severity rubric is published.
• Seven AI-specific data incident playbook entries (training-corpus poisoning, retrieval-store extraction, embedding inversion, prompt/completion-log breach, cross-border-flow violation, consent-withdrawal not propagated, DSAR fulfillment failure) are published with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets; each is exercised in at least one tabletop in the last 12 months.
• The regulatory SLA tracker is live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, and applicable state privacy laws; 100% adherence in the last 90 days.
• The post-incident review loop is wired to SA-Data, SR-Data, EG-Data, and ML-Data; every Critical/blocker data incident produces a review within 14 days with named update outputs per downstream practice.
• A program-sponsor dashboard is refreshed monthly showing backlog aging, SLA adherence, and post-incident learning outputs.

Maturity Level 2

Objective: Calibrate incident response depth per the SM-Data L2 risk tier; operate dedicated 24/7 on-call coverage and pre-staged escalation for Critical-tier data assets; auto-flow post-incident review outputs to SA/SR/EG/ML-Data practice backlogs; and activate cross-domain coordination when a Data-domain incident implicates Software, Infrastructure, or Processes.

Activities.

A) Tier-calibrated data incident playbook and on-call. Extend L1 playbook entries with tier-specific activation criteria and on-call coverage. Critical tier: full IM-Data activation, CISO or delegate plus Privacy/Legal plus data-asset owner plus executive sponsor notification; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named data-security incident responder in each rotation; pre-staged communication templates (internal, customer-facing, supervisory-authority notification draft) loaded and reviewed quarterly. High tier: scoped response team, Privacy/Legal plus data-asset owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with a defined after-hours escalation path. Medium tier: standard response; ≤1 business day acknowledgement; queue-based triage. Low tier: tracked in queue with aggregated weekly handling. The Critical-tier on-call rotation is documented per week with named individuals, a coverage hand-off protocol, and an on-call briefing that includes the current Critical-tier data asset list, their active detection set, and the containment playbook paths specific to those archetypes.

B) Post-incident review auto-flow integration. Wire IM-Data post-incident review outputs to downstream practice backlogs via a defined integration. SA-Data pattern-update requests auto-create architecture-backlog tickets with the IM-Data incident reference linked. SR-Data requirements-pack update requests auto-create pack-backlog tickets with the requirements-pack version and failing requirement row linked. EG-Data training-content update requests auto-create training-backlog tickets with the affected population segment and data-incident summary linked. ML-Data detection-update requests auto-create detection-registry update tickets with the detection name, current query, and proposed change linked. SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days, and accepted updates are treated as High-severity issues in the receiving practice's backlog. The program sponsor reviews post-incident review quality quarterly, are update outputs substantive (a concrete change to a data architecture pattern, requirements pack, curriculum, or detection) or nominal (a note saying "consider reviewing")?

C) Cross-domain coordination protocol. Publish a cross-domain coordination protocol that activates when a Data-domain AI/HAI data incident implicates another domain. Data → Software: a training-corpus poisoning or breach affects model versions currently in production; activates the Software-domain IM-Software model-rollback play alongside the Data-domain corpus-quarantine and lineage-audit play, with a named Software-domain IM contact on file. Data → Infrastructure: a storage misconfiguration exposes a training corpus or prompt/completion-log corpus via a direct storage-API path; activates Infrastructure-domain EH and IM alongside Data-domain containment, with a named Infrastructure-domain IM contact on file. Data → Processes: a DSAR fulfillment failure reveals that business-process data flows feeding AI/HAI data assets are unmapped in the SM-Data or Processes inventory; activates the Processes-domain privacy coordinator alongside the Data-domain DSAR escalation play, with a named Processes-domain contact on file. Cross-domain activations share a single status board, a single IC from the primary impacted domain, coordinated remediation tracking, and a joint post-incident review spanning all affected domains. Tier-movement in the SM-Data inventory auto-triggers IM-Data configuration updates: a re-tier to Critical updates the on-call path, playbook variant, and SLA targets within 14 days; other tier changes within 30 days.

Outcome Metrics (L2).

Success Criteria.

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation including a current Critical-tier data asset briefing.
• The post-incident review auto-flow integration is live; 100% of Critical-tier review outputs are auto-routed to SA-Data/SR-Data/EG-Data/ML-Data backlogs; ≥90% of downstream practice owners respond within 14 days.
• The cross-domain coordination protocol is published and used for 100% of multi-domain AI/HAI data incidents; named cross-domain contacts are verified quarterly.
• Tier-movement in the SM-Data inventory auto-triggers IM-Data configuration updates within 14 days for Critical re-tiers and within 30 days for other tiers.

Maturity Level 3

Objective: Contribute data incident patterns and playbook templates to MITRE ATLAS, AVID, DAMA, and sector ISACs; execute pre-authorized automated containment for defined low-severity high-confidence data detections; and benchmark MTTR against industry peers, linking deltas to investment proposals.

Activities.

A) Industry-coordinated data incident sharing and contribution. Participate in sector-ISAC AI data incident-sharing programs (FS-ISAC AI working group, H-ISAC, IT-ISAC, sector-specific). Consume ISAC AI data incident feeds and integrate applicable advisories into the IM-Data external-advisory source. Contribute anonymized data incident classification, incident type, ATLAS tactic tag, HAI-TTP tag, data archetype affected, containment play used, regulatory SLA outcome, MTTR achieved, on a per-incident-class basis; target ≥4 ISAC contributions per year. Contribute to AI data incident taxonomy standards: MITRE ATLAS TA0014 Impact (incident-derived technique observations or mitigation entries for Impact-tactic techniques relevant to data assets, training-data poisoning, data exfiltration, consent manipulation; target ≥1 per year), AVID (AI/HAI data vulnerability entries for novel data incident classes discovered in production, training-corpus poisoning methods, embedding-inversion methods, consent-withdrawal propagation failures; target ≥2 per year), DAMA (AI/HAI data incident response patterns, data-archetype severity definitions, and DSAR fulfillment escalation playbook templates for the DAMA AI data governance guidance), and the CSA AI Safety Initiative (AI data incident severity-anchor definitions and playbook template schemas for the data domain).

B) Pre-authorized automated runbook decisioning for data incidents. Define and publish a pre-authorization policy for automated containment actions on AI/HAI data assets, the set of actions that may execute without human approval when a detection fires at a defined confidence threshold. Pre-authorized actions include a retrieval-store bulk-query path disable for a Low or Medium-tier retrieval store when a retrieval-extraction-attempt detection fires above 90% confidence, pipeline service-account access revocation for a quarantined training dataset when a poison-detection scan fires above 95% confidence and the affected dataset is not at Critical tier, cross-border replication disable for a storage replication configuration when a cross-border-flow violation detection fires, and an embedding-store bulk-export access disable for a Low or Medium-tier embedding store when an embedding-inversion-attempt detection fires above 90% confidence. Pre-authorized actions for Critical-tier data assets require human confirmation within 15 minutes; the action fires after that window if no confirmation arrives (timer-based fallback) with immediate executive notification at fire time. All pre-authorized actions produce a full audit-log entry in the IM-Data backlog, a human-review ticket auto-created at execution, and notification to the data asset's named owner. The pre-authorization policy is reviewed quarterly by Privacy/Legal and the executive sponsor; any automated action that produces an unexpected outcome triggers an out-of-cycle review.

C) MTTR benchmarking for data incidents. Establish MTTR benchmarks from ISAC AI data incident exchanges, BSIMM-style observational data on AI/HAI data incident response at comparable organizations, MITRE ATLAS practitioner-community data on data-domain incident response, and peer roundtables (Privacy Officer and AI data-security practitioner communities). Publish a quarterly MTTR benchmark brief to the program sponsor: MTTR per data incident class vs. benchmark (training-corpus poisoning, retrieval-store extraction, embedding inversion, prompt/completion-log breach, cross-border-flow violation, consent-withdrawal non-propagation, DSAR fulfillment failure); MTTR per tier vs. benchmark; delta trend (improving, stable, degrading); and an investment driver, where MTTR is above benchmark, root-cause mapped to a specific practice gap (missing detection, unclear playbook, on-call latency, DSAR infrastructure gap) with a budget-linked improvement proposal.

Outcome Metrics (L3).

Success Criteria.

• ≥4 ISAC AI data incident contributions per year; ≥2 AVID data vulnerability entries per year; ≥1 ATLAS TA0014 Impact contribution per year; all contributions anonymized, legally vetted, and maintained.
• ≥3 pre-authorized automated containment actions are live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution.
• A quarterly MTTR benchmark brief is published to the sponsor; Critical-tier MTTR is at or below benchmark for ≥4 of 7 data incident classes; deltas above benchmark are linked to investment proposals.
• The pre-authorization policy is reviewed quarterly; no unauthorized automated action executes; all unexpected automation outcomes are reviewed within 5 business days.

Common Pitfalls

Level 1. - A "single backlog" is created but source practices continue filing into separate queues, ST-Data failures stay in the CI pipeline dashboard, ML-Data alerts route to a data-platform Slack channel, and TA-Data residual risks live in a spreadsheet; the backlog reaches only ~40% of issues and the ≥95% coverage target is never met. - Severity rubric anchors are generic (probability × impact without AI-specific data axes), a consent-withdrawal non-propagation event is triaged Low because the rubric does not capture GDPR Art. 33 exposure from continued processing of a withdrawn-consent subject's data in a training corpus. - Playbook entries are published but roles are not pre-assigned, on the first live training-corpus poisoning incident the team spends the first hour determining who has authority to quarantine the dataset and revoke the pipeline service account's access rather than executing the quarantine. - The DSAR fulfillment path is never tested, the first DSAR arrives for a data subject whose data appears in a training corpus and the export takes four weeks because no one has tested the DSAR-capable export path and the ML-Data export SLA was never drilled.

Level 2. - Critical-tier activation criteria are vague, a confirmed retrieval-store extraction attempt that qualifies for full-team plus executive activation stays in the standard queue until the data-asset owner escalates, and the ≤1-hour acknowledgement SLA is already missed by the time the right people engage. - The post-incident review auto-flow integration is wired but downstream practice backlogs never treat the auto-created tickets as actionable, the SR-Data team closes the ticket as "acknowledged" without updating the requirements pack and the feedback loop produces no change. - The cross-domain coordination protocol exists on paper but no IC is pre-designated for cross-domain data incidents, the first incident where a training-corpus breach affects Software-domain model versions produces ownership confusion as both Data-domain IM and Software-domain IM wait for the other to take the IC role. - 24/7 on-call coverage is implemented but the on-call briefing is stale, the rotation briefing carries a Critical-tier data asset list accurate 60 days ago, a newly tiered Critical-tier training corpus is absent, and the on-call responder does not know the quarantine path for the affected dataset.

Level 3. - ISAC participation is limited to consuming feeds, contributions are absent, the org is labeled a free-rider, and influence over AI data incident taxonomy standards diminishes. - Pre-authorized automated containment fires on a Critical-tier data asset because the confidence threshold was set without a Critical-tier exception check, a false positive disables a retrieval store backing a production customer-facing AI feature. - The MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI data portfolio scale or regulatory exposure, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch the program. - AVID data vulnerability entries are submitted once and never updated, novel data incident classes evolve while the org's AVID entries reflect vulnerabilities from 18 months ago that have since been mitigated.

Practice Maturity Questions

Level 1. 1. Is there a single AI/HAI data issue backlog with standardized metadata (source, affected data asset linked to the SM-Data inventory, archetype, a severity rubric anchored to AI-specific data axes, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices, TA-Data, SR-Data, DR-Data, IR-Data, ST-Data, ML-Data, and external? Evidence: backlog audit reconciled against each source-practice queue; severity rubric document with AI-specific data anchors. 2. Is the AI/HAI data incident playbook published with seven named AI-specific data incident classes (training-corpus poisoning, retrieval-store extraction, embedding inversion, prompt/completion-log breach, cross-border-flow violation, consent-withdrawal not propagated, DSAR fulfillment failure), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months? Evidence: published playbook; tabletop exercise records covering all seven classes. 3. Is the regulatory SLA tracker live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), and applicable state privacy laws with 100% adherence in the last 90 days, and does every Critical/blocker data incident produce a post-incident review within 14 days with named update outputs flowing to SA-Data, SR-Data, EG-Data, and ML-Data? Evidence: SLA tracker showing zero missed windows; post-incident review records with downstream update outputs.

Level 2. 1. Is a tier-calibrated data incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier data asset briefing with archetype-specific containment paths, and tier-movement in the SM-Data inventory automatically triggering IM-Data configuration updates within 14 days for Critical re-tiers? Evidence: IM-Data telemetry on MTTA/MTTC; on-call registry with briefing content; tier-change-to-configuration-update audit trail. 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA-Data/SR-Data/EG-Data/ML-Data practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements? Evidence: integration telemetry; downstream backlog aging; quarterly post-incident review quality assessment. 3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI data incidents, with named cross-domain contacts for Software, Infrastructure, and Processes verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains? Evidence: published protocol; incident coordination records; quarterly cross-domain contact verification log.

Level 3. 1. Does the program contribute ≥4 anonymized AI data incident-classification entries per year to sector ISACs, ≥2 data vulnerability entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS TA0014 Impact tactic documentation, all maintained current, legally vetted, and tracked for external adoption? Evidence: contribution log with upstream references; ATLAS contribution log; legal-vetting records. 2. Are ≥3 pre-authorized automated containment actions live (retrieval-store bulk-query disable, pipeline service-account access revocation for quarantined datasets, cross-border replication disable, embedding-store bulk-export disable), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? Evidence: pre-authorization policy; automation log with audit records and human-review tickets; quarterly policy-review records. 3. Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per data incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes and deltas above benchmark linked to specific practice gaps and investment proposals? Evidence: quarterly MTTR benchmark briefs; benchmark source documentation; investment-proposal records linked to above-benchmark deltas.

25. Monitoring & Logging (ML)

Practice Overview

Objective: Establish the logging baseline per AI/HAI data archetype, operate a small high-signal detection set targeted at the top TA-Data threats, and produce the evidence trail that proves EU AI Act Art. 12 deployer duties, GDPR Art. 30 records-of-processing obligations, and ISO/IEC 42001 AIMS requirements, on demand, inside a published SLA.

Description: ML-Data captures the signals produced by every AI/HAI data asset the organization operates, training corpora, inference input streams, retrieval stores, prompt/completion log corpora, embedding stores, fine-tuning datasets, and evaluation/test sets. For each archetype it specifies the exact events to capture (ingestion, access, classification routing, PII-redaction decisions, retention-expiry, export, poison-detection scan, and admin-audit events), the retention window required to satisfy the longest applicable regulation, and the export path that supports DSAR fulfillment and auditor review within a published SLA. On top of the logging baseline it operates a bounded, purposeful detection set, each detection tied to a TA-Data archetype threat, with a named owner, a defined query, and an active tuning record. The corpus ML-Data produces is the primary evidence artifact for PC-Data's compliance map: EU AI Act Art. 12 deployer-duty logs, GDPR Art. 30 records of processing, and ISO/IEC 42001 AIMS operational evidence.

Context: Logging AI/HAI data assets is not the same as logging classic database access. A retrieval event must carry the retrieved document IDs, classification labels, tenant-isolation check result, and query principal, not only an HTTP status code. A training-job event must capture the dataset reference and version, the consent basis for all subjects in the training corpus, the poison-detection scan result, and the eval-gate outcome to support model-promotion audit. A prompt/completion-log write event must record what was redacted, by which rule, before writing, not after. None of this exists by default in standard data-warehouse or SIEM tooling unless the archetype's event schema has been explicitly defined and instrumented. ML-Data makes that schema explicit, per archetype, from day one, so the organization produces deployer-duty evidence on demand rather than reconstructing an incomplete telemetry trail at the moment a regulator, DSAR, or incident demands it. ML-Data detections are the primary runtime input to the IM-Data backlog, and the ML-Data log corpus is the evidence source PC-Data's priority compliance map depends on.

Maturity Level 1

Objective: Establish the per-archetype logging baseline, operate a small high-signal detection set targeting the top TA-Data threats, and produce an on-demand evidence trail that satisfies EU AI Act Art. 12, GDPR Art. 30, and ISO/IEC 42001 AIMS requirements within a published SLA.

Activities.

A) Establish the per-archetype logging baseline. Define and instrument the minimum event schema for each AI/HAI data archetype in the SM-Data inventory. Every event record includes an event-id/correlation-id, the principal (user or service account), a timestamp, an archetype tag, and an asset-id linked to the SM-Data inventory, plus the archetype-specific fields; PII scrubbing is applied per SR-Data data-boundary requirements before logging where logging the raw field would itself create a regulated-data exposure. For training corpora and fine-tuning datasets capture ingestion events (source identifier, classification label, consent basis, lineage reference, processing-job identity), poison-detection scan events (scan tool, result, flagged-item count, scan-job-id), training-job events (job-id, dataset reference and version, consent-basis summary, model-output identifier), eval-result-as-gate events (eval-job-id, pass/fail, criteria applied, gate outcome), and model-promotion events linked to the dataset. For inference input streams capture PII-redaction-decision events (data class detected by category, redaction rule applied, action taken), classification-routing-decision events, and no-train-flag check events with an alert when the flag is absent where required. For retrieval stores capture retrieval events (document IDs retrieved, classification labels, query principal, tenant-id, query-id), retrieval-poisoning detection events, per-tenant isolation check events, and ingestion events. For prompt/completion log corpora capture log-write events (fields written, what was redacted, retention policy applied), retention-expiry events, and export events. For embedding stores capture access events (principal, operation, embedding-id or query-id), inversion-defense decision events, and per-tenant partition check events. For evaluation/test sets capture access events and eval-data-in-training isolation-check events. Admin-audit events span all archetypes: classification-scheme changes, retention-policy changes, lineage changes, consent-basis changes, key-rotation events, access-policy changes, and transfer-mechanism changes. Identity events span archetypes: SSO sign-ins to data-facing consoles, service-principal token use against storage APIs, and JIT access grant and expiry events. Retention meets or exceeds the longest applicable requirement across the active regulatory set, GDPR Art. 30 records-of-processing (5 years typical for the record itself), EU AI Act Art. 12 deployer-duty logs ≥6 months for high-risk systems, HIPAA access logs for PHI ≥6 years, and where multiple windows apply the longest governs. A structured JSON or CSV export path from the log store is tested at least annually per archetype, with an on-demand pull SLA ≤24 hours for auditor, regulator, or legal-hold requests and a DSAR-capable export SLA ≤72 hours. Admin-audit and deployer-duty evidence tiers use write-once or append-only storage with access-control separation between data-engineering teams and log-store administrators, and Critical-tier asset audit logs carry cryptographic integrity verification.

B) Operate a small high-signal detection set. The L1 target is ≤12 detections, each tied to a TA-Data archetype threat and to at least one HAI TTP tag (EA / AGH / TM / RA) or ATLAS tactic, each with a named owner, a detection query, an SLA (time-to-IM-Data-ticket), and a last-tuned date; false-positive rate is tracked per detection with a monthly tuning review. The core detection set: classification-label drift detection, a data-pipeline event shows a dataset or document with a classification label that is absent, empty, or lower than its parent corpus (ATLAS TA0010 Discovery / EA TTP); unclassified-data-flow detection, a pipeline service account reads from a dataset with no classification label on file in the SM-Data inventory (ATLAS TA0010 / EA TTP); retrieval-extraction-attempt detection, a single principal issues retrieval queries ≥3 standard deviations above its baseline within a rolling window (ATLAS TA0013 Exfiltration / TM TTP); embedding-inversion-attempt detection, a principal issues a bulk-read or bulk-export operation on an embedding store exceeding its declared operational profile (ATLAS TA0013 / TM TTP); training-data canary leakage detection, a canary string injected into a training corpus at a known position is emitted verbatim in a model completion, correlated back to the training-job event (ATLAS TA0013 / TM TTP); cross-border-flow violation detection, a regulated data asset crosses a regional storage boundary without a documented transfer mechanism on file (ATLAS TA0013 / EA TTP); retention-policy violation detection, a data asset persists past its documented retention expiry without a deletion event or a documented extension approval (ATLAS TA0014 Impact / EA TTP); no-train-flag flipped without IM-Data review, a no-train flag is changed from "set" to "unset" without a corresponding IM-Data review approval event (ATLAS TA0008 Defense Evasion / AGH TTP); and consent-withdrawal-not-propagated detection, a consent withdrawal is recorded in the consent-management system but the affected training corpus still contains records linked to that subject beyond the 30-day propagation SLA (ATLAS TA0014 / EA TTP). Each detection routes to the IM-Data backlog on fire, with a median detection-to-ticket time target ≤1 hour for Critical-tier data assets.

C) Produce and drill the deployer-duty evidence trail. ML-Data is the primary evidence source for PC-Data's priority compliance map. Wire the log store to the compliance requirements. For EU AI Act Art. 12 (high-risk-system logging for deployer duties), confirm for every data asset associated with an Annex III high-risk AI system or a customer-facing decision-affecting output that ingestion, access, classification-routing, and admin-audit events are captured and retained at ≥6 months, and produce a deployer-duty evidence view, log record plus retention attestation plus export test result, for each such asset. For GDPR Art. 30 (records of processing), the access, PII-redaction-decision, and consent-basis events constitute the records-of-processing operational entries; link the log-store retention policy to the Art. 30 record for each data asset processing personal data and confirm the DSAR-capable export path is operational and tested. For ISO/IEC 42001 AIMS (operational evidence for the AI Management System), training-job events, model-promotion events linked to dataset versions, eval-run events, consent-basis-change events, and admin-audit events constitute the AIMS operational records for the data domain; identify gaps and open IM-Data findings for any archetype not yet emitting these events. Run a quarterly deployer-duty drill: pull the deployer-duty evidence package for one randomly selected production AI/HAI data asset per archetype within the published SLA (≤24 hours from request to assembled package; ≤72 hours for the DSAR-path drill); record drill results and route gaps to IM-Data.

Outcome Metrics (L1).

Success Criteria.

• The per-archetype logging baseline is published and instrumented for ≥90% of production AI/HAI data assets across all seven archetypes.
• A ≤12-detection high-signal set is live, each with an owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, and monthly tuning record; false-positive rate is tracked per detection.
• Retention meets the longest applicable regulatory window for every production data asset; the export path is tested at least annually and the DSAR-capable export path at least semi-annually.
• EU AI Act Art. 12, GDPR Art. 30, and ISO/IEC 42001 AIMS evidence-trail wiring is documented; the quarterly deployer-duty drill is executed inside the ≤24-hour (≤72-hour DSAR) SLA.

Maturity Level 2

Objective: Calibrate logging depth and the detection set to the SM-Data L2 risk-tier rubric, integrate with the SIEM for cross-archetype correlation, and feed incident-driven and ST-Data-driven detection updates into a continuous tuning loop.

Activities.

A) Tier-calibrated logging depth. Apply the SM-Data L2 tier-treatment matrix to logging configuration. Critical-tier data assets receive full event logging retained for the longest regulatory window, all admin-audit and identity events at maximum fidelity, all detections tuned to the asset, per-asset log isolation with a separate access-control boundary, and audit-log cryptographic integrity verification. High-tier assets receive full event logging retained at the regulatory minimum, admin-audit and identity events at standard fidelity, and the core detection set active. Medium-tier assets receive event hashes or structured summaries retained for the regulatory minimum, standard admin-audit, and the classification-drift and baseline detections. Low-tier assets receive the baseline logging schema only and classification-drift detection only. For every Critical-tier data asset the ML-Data log store is the primary source for PC-Data's compliance evidence bundle, with ML-Data logging-baseline validation kept ≤30 days fresh for Critical-tier per PC-Data L2 staleness thresholds.

B) SIEM integration and cross-archetype correlation. Ingest all tier-appropriate ML-Data log feeds into the SIEM and author and maintain at least three cross-archetype correlation rules. The retrieval-to-embedding exfiltration chain: the same principal issues anomalous retrieval queries on a retrieval store and a bulk embedding export from the associated embedding store within the same session window, fires a unified high-severity detection. Training-data canary plus consent-withdrawal non-propagation: a canary-leakage detection on a model completion correlates to a consent-withdrawal record for a subject whose data appears in the training-corpus version linked to the affected training-job event, escalates to Critical regardless of asset tier and triggers a GDPR Art. 33 evaluation. Cross-border flow plus classification escalation: a cross-border-flow violation detection on a regulated data asset correlates with a classification-label change on that asset within the same 24-hour window, a combined signal indicating potential deliberate mis-labeling to enable cross-border exfiltration, escalates to Critical. Cross-archetype correlation alerts route to IM-Data at the tier of the highest-tier asset involved.

C) Detection tuning loop from IM-Data post-incident and ST-Data feedback. Operate a quarterly detection review cycle. IM-Data post-incident reviews that touch a logging or detection gap generate a detection-update request, a new detection, a tuned query, or a retired false-positive rule. ST-Data CI corpus failures (canary detection test, retrieval-poisoning test, embedding-isolation test) not caught by the current detection set generate a detection-gap finding routed to ML-Data. External advisory updates, MITRE ATLAS new techniques, AVID advisories, GDPR enforcement decisions from DPAs revealing data-processing violations in AI systems, sector-regulator AI advisories, are assessed quarterly, each applicable update either adding a new detection candidate or updating an existing query. Anomaly-baseline refresh runs monthly for Critical and High-tier data assets: the normal-behavior baseline (retrieval query volume per principal, embedding access patterns, ingestion event rates, consent-withdrawal propagation latency) is refreshed from the previous 30-day window and the anomaly threshold auto-tunes to maintain the target false-positive rate. Each detection carries a last-tuned date and a false-positive rate; detections that have not fired a true positive in 90 days or that exceed a 20% false-positive rate are reviewed for retirement at the quarterly cycle.

Outcome Metrics (L2).

Success Criteria.

• Tier-calibrated logging depth is applied to 100% of the SM-Data inventory with current tier assignments; Critical-tier full event corpus retention is confirmed.
• SIEM integration is live with ≥3 cross-archetype correlation rules active.
• The quarterly detection tuning loop operates with IM-Data and ST-Data feedback; ≥1 net detection change per cycle (new, updated, or retired).
• ≥90% of Critical/High-tier data assets have anomaly-detection baselines; false-positive rate is tracked and trending down.
• The ML-Data logging-baseline validation element is fresh (≤30 days) for all Critical-tier data assets in PC-Data compliance evidence bundles.

Maturity Level 3

Objective: Express detections as code with automated deployment, apply anomaly detection to retrieval, embedding-access, and training-pipeline event corpora, and contribute anonymized detection signatures and telemetry schemas to OWASP LLM data-detection patterns, sector ISACs, MITRE ATLAS, and DAMA.

Activities.

A) Detection-as-code. Every detection in the set is expressed as a versioned, tested artifact in source control, the detection query plus metadata (owner, SLA, ATLAS-tactic tag, HAI-TTP tag, false-positive threshold, last-test-result, archetype tags). A detection CI/CD pipeline runs a test suite, unit tests over synthetic log data representing realistic data-asset event patterns and integration tests against a log-replay environment populated with anonymized historical events, before production deployment. Detections are deployed through the same change-management pipeline as data-pipeline code, reviewed and deployed rather than applied ad hoc in the SIEM console. Detection coverage is automatically checked on SM-Data inventory change events: when a new data asset is registered or an existing asset is re-tiered to Critical, the automation verifies that the required detection set is active for that archetype and tier and opens a gap finding within 24 hours if it is not.

B) Anomaly detection on AI/HAI data corpora. Apply unsupervised and semi-supervised anomaly models to the event corpora for Critical and High-tier data assets. Retrieval query pattern anomaly surfaces retrieval event sequences from a principal that are statistical outliers from normal query patterns, attacker-probing signatures, bulk retrieval across document classes, and multi-session high-volume extraction patterns that individually fall below the rule-based threshold but collectively exceed baseline. Embedding access corpus anomaly surfaces embedding-store access patterns whose distribution shifts from baseline on a rolling window, bulk-export preparation sequences, unusual access to partitions outside the principal's declared operational scope, and novel argument patterns in embedding API calls. Training-pipeline event stream anomaly surfaces training-job events whose dataset composition, consent-basis distribution, or provenance lineage differs statistically from prior approved training runs for the same model family, indicating potential unauthorized data inclusion or consent-basis manipulation. Consent-withdrawal propagation latency anomaly models the delay between consent-withdrawal events and the appearance of deletion/exclusion events in the training-dataset audit log, triggering early warning before the rule-based retention-violation detection fires. Anomaly model outputs feed the same detection-to-IM-Data-ticket pipeline as rule-based detections; anomaly models are retrained monthly, and each retraining produces a new version tracked in the model registry with the same lineage attestation required for production AI/HAI software.

C) Contribute detection signatures and telemetry schemas. Contribute data-domain detection pattern examples, retrieval extraction, embedding inversion, training-data canary leakage, consent-withdrawal non-propagation, to the OWASP LLM Top 10 or Agentic Top 10 community, targeting at least one data-domain detection pattern contribution per release cycle. For each detection corresponding to an ATLAS tactic/technique, propose or validate an AML.M00xx mitigation entry of the detection-based mitigation type, prioritizing TA0013 Exfiltration (retrieval extraction, embedding inversion, canary leakage) and TA0014 Impact (consent-withdrawal, retention violation, no-train-flag bypass). Contribute data-security logging schema standards to DAMA, event schema definitions for training-corpus ingestion events, retrieval-store access events, embedding-store access events, and consent-propagation events suitable for the DAMA DMBOK AI data governance chapter. Share anonymized, generalized detection signatures for AI data-domain threats with sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), implementable by partner organizations without significant reconstruction. Target ≥2 telemetry-standard contributions per year and ≥12 ISAC detection signatures per year; all contributions are anonymized, legally vetted, and maintained, not point-in-time submissions.

Outcome Metrics (L3).

Success Criteria.

• ≥90% of the detection set is expressed as version-controlled, CI/CD-deployed artifacts; detection changes are reviewed and deployed through the same change pipeline as data-pipeline code.
• Detection coverage is auto-verified for 100% of new or re-tiered SM-Data inventory entries within 24 hours.
• ≥90% of Critical/High-tier data assets have anomaly detection active across retrieval query, embedding access, and training-pipeline event dimensions; anomaly models are retrained monthly on schedule.
• ≥2 telemetry-standard contributions per year to OWASP LLM, DAMA, or equivalent; ≥12 anonymized detection signatures per year to sector ISACs; ≥2 ATLAS AML.M00xx mitigation entries proposed or validated.

Common Pitfalls

Level 1. - The logging baseline is defined at the archetype level but actual production data assets are never audited against it, gaps accumulate in the SM-Data inventory without appearing in any backlog, and the quarterly deployer-duty drill is skipped because "we know the logs exist." - Retrieval-store access is logged at the service-account level but not at the document-ID level, retrieval-extraction-attempt detections are architecturally impossible because the query content and retrieved document IDs are absent from the event. - Consent-withdrawal events are recorded in the consent-management system but never linked to the training-corpus lineage events in the ML-Data log store, consent-withdrawal non-propagation detection cannot fire because the two event streams sit in separate, unlinked systems. - The DSAR-capable export path is documented in the compliance map but never tested, when the first DSAR arrives for a data subject whose data appears in a training corpus, the export takes three weeks because no one has tested the path.

Level 2. - Tier-calibrated logging is configured at asset registration but not maintained, when a data asset is re-tiered from Medium to Critical, logging depth is not updated and full event corpora are absent when the first Critical-tier data incident fires. - SIEM correlation rules are built once and never validated, a correlation rule silent for 90 days may be broken (event schema changed, query syntax stale) rather than evidence that no correlatable events occurred. - Anomaly baselines are established at onboarding and never refreshed, behavioral drift in normal data-pipeline usage makes the baseline stale and false-positive rates spike over subsequent quarters. - The detection tuning loop exists on paper but IM-Data and ST-Data feedback never feeds the review cycle, the same false-positive detections persist for years because the quarterly process has no dedicated owner.

Level 3. - The detection-as-code pipeline is deployed but tests use synthetic data that does not resemble realistic data-asset event patterns, tests pass in CI and detections fail silently in production because the synthetic events lack the field combinations present in real retrieval-extraction attempts. - Anomaly models are retrained on the full event corpus including labeled attacker-session logs from past incidents, a poisoned baseline that learns to treat past retrieval-extraction patterns as normal. - Contributed DAMA or OWASP data-detection schemas are published as point-in-time artifacts and then diverge from internal practice, external adopters build against v1.0 while the org operates v1.4 internally, eroding trust and reusability. - ISAC detection signatures are generalized to the point of uselessness, partner organizations cannot implement them without reconstructing the context removed for anonymization.

Practice Maturity Questions

Level 1. 1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI data archetype in the SM-Data inventory (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), and has compliance of each production data asset been measured against it within the last quarter? Evidence: published logging baseline; logging configuration audit reconciled against the SM-Data inventory. 2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, and last-tuned date, including classification-label drift, unclassified-data-flow, retrieval extraction attempt, embedding inversion attempt, training-data canary leakage, cross-border-flow violation, retention-policy violation, no-train-flag flip, and consent-withdrawal non-propagation, with false-positive rates tracked per detection and monthly tuning reviews occurring? Evidence: detection registry; per-detection false-positive trend; monthly tuning-review records. 3. Has the evidence trail for EU AI Act Art. 12, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Data log store, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production data asset can be assembled within the ≤24-hour SLA, and has a DSAR-capable export path test been executed within the last 6 months confirming the ≤72-hour DSAR SLA? Evidence: compliance evidence-trail wiring documentation; quarterly drill records; DSAR-path test records.

Level 2. 1. Is tier-calibrated logging depth applied per the SM-Data L2 tier-treatment matrix, Critical-tier data assets retaining full event corpora at the longest regulatory window, Low-tier assets receiving baseline only, and is this calibration automatically updated when a data asset is re-tiered, with re-tier-to-Critical updates completing within 14 days? Evidence: log-store retention audit reconciled against current SM-Data tier assignments; tier-change-to-logging-update audit trail. 2. Is the SIEM ingesting ML-Data log feeds with ≥3 cross-archetype correlation rules active (covering at minimum the retrieval-to-embedding exfiltration chain, training-data canary plus consent-withdrawal correlation, and cross-border flow plus classification escalation), and is a quarterly detection tuning cycle operating from IM-Data post-incident and ST-Data finding inputs, with DPA enforcement advisory review included in the quarterly cycle? Evidence: SIEM rule registry; detection change log showing quarterly cycles; quarterly advisory-review records. 3. Are ≥90% of Critical/High-tier data assets running anomaly-detection baselines across retrieval query, embedding access, and training-pipeline event dimensions, with behavioral profiles refreshed monthly and false-positive rates tracked and trending down, and is the ML-Data logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier data assets in PC-Data compliance evidence bundles? Evidence: detection telemetry; monthly anomaly-baseline refresh records; PC-Data evidence registry freshness report.

Level 3. 1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic data-asset event patterns, and is detection coverage auto-verified for 100% of new or re-tiered SM-Data inventory entries within 24 hours of the inventory change event? Evidence: detection registry cross-referenced with source control; detection CI/CD test results; automation telemetry on inventory-change coverage checks. 2. Are ≥90% of Critical/High-tier data assets running anomaly detection on retrieval query, embedding access, and training-pipeline event corpora, with anomaly models retrained monthly on production event data, model versions tracked in the model registry with SLSA-style provenance, and anomaly-model alerts feeding the IM-Data incident backlog through the same detection-to-ticket pipeline as rule-based detections? Evidence: anomaly model registry with retraining cadence and lineage attestations; detection-to-ticket telemetry covering anomaly-model alerts. 3. Has the program contributed ≥2 telemetry-standard artifacts per year to OWASP LLM data-detection patterns, DAMA, or equivalent, and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked? Evidence: contribution log with upstream references; ATLAS contribution log; external-adoption tracking records.

Part IV, Maturity Assessment Workbook

This part turns the twelve Data-domain practices into a working assessment instrument. Section 26 explains how the assessment is run; section 27 defines the scoring methodology; section 28 is the 108-question questionnaire; sections 29 and 30 roll the answers up to practice-level and domain-level scores; section 31 is the improvement-roadmap template that converts the gaps into a dated plan.

The workbook is self-contained. An assessor who has read Parts I–III can run a full Data-domain assessment from sections 26–31 alone.

26. How the assessment works

What is assessed. The subject of this assessment is the data flowing into and out of the AI/HAI systems the organization governs, training corpora, inference input streams, retrieval stores, prompt/completion log corpora, embedding stores, fine-tuning datasets, and evaluation/test sets. It is not an assessment of AI used to perform data security, and it is not a general data-governance audit. Every question asks whether the organization secures and governs the data that AI consumes and produces. The §12.1 subject rule holds throughout: a question is in scope only if it asks about protecting a data asset that feeds or is produced by an AI/HAI system.

Cumulative levels. Each practice has three maturity levels. The levels are cumulative: a practice is at Level 2 only if Level 1 is also satisfied, and at Level 3 only if Levels 1 and 2 are also satisfied. The questionnaire enforces this with a gate (section 27), Level 2 questions do not count toward a score until all three Level 1 questions for that practice are answered Yes, and Level 3 questions do not count until all three Level 2 questions are Yes.

Yes / Partial / No answers. Every question is written to be answered Yes, Partial, or No. Yes means the condition described is fully met and evidenced. Partial means the condition is genuinely underway, the artifact exists but is incomplete, or the activity runs but not at the stated coverage or cadence. No means the condition is not met, or the assessor cannot find evidence. "We intend to" is No. "It exists but nobody uses it" is No.

Evidence. Every answer requires an evidence pointer. The evidence is the named artifact, system, or record that substantiates the answer: an inventory export, a published policy, a tier-treatment matrix, a REM, a DR decision record, a CI run, a detection registry, a regulatory SLA tracker entry. An answer with no evidence pointer is scored as No regardless of the stated answer. Evidence prompts are printed inline with each question.

Cadence. A full Data-domain assessment runs at least annually. A lighter quarterly re-score of the practices targeted by the current improvement roadmap (section 31) keeps the roadmap honest between full assessments. A re-assessment is also triggered when the organization stands up a new data archetype, after a Critical-tier data incident, or when a regulation in the priority compliance map materially changes.

Roles. The assessment is co-sponsored by the CISO and the Chief Data Officer (or Head of Data), Data-domain risk is data-governance risk and security risk at once, and a single-sponsor assessment lacks authority over one half of it. The Data Governance lead runs the assessment day-to-day. Privacy/Legal (DPO/CPO) supplies the compliance and DPIA evidence. AI/ML engineering and the Data Platform team supply the inventory, lineage, pipeline, and tooling evidence. Each practice should be answered with the named practice owner present; the assessor does not answer on the owner's behalf.

Scope boundary. Cross-domain artifacts, an LLM-integrated app, an AI agent, a RAG pipeline as a built artifact, are assessed in the Software domain. The Data domain assesses the corpus, the index, the log store, the embedding store as data assets: their classification, lineage, consent basis, retention, cross-border posture, and the controls around them. The two domains cross-reference (an SR-Data REM is referenced by the SR-Software REM of a consuming artifact) but they do not duplicate. When in doubt, ask: is the question about the data, or about the thing that consumes the data? If the former, it belongs here.

27. Scoring methodology

The questionnaire contains 108 questions: 12 practices × 9 questions, with 3 questions per maturity level. Scoring converts the Yes/Partial/No answers into a practice level, a domain maturity figure, and a gap list. Two scoring methods are provided, a simplified method for a fast read and a precise method for the formal score. Both use the same answers.

27.1 Simplified scoring

For a quick read, score each practice level as Pass or Not yet:

• A practice level is Pass when all three of its questions are answered Yes.
• A practice level is Not yet when any question at that level is Partial or No.

A practice's maturity level is the highest consecutive level that Passes. If Level 1 is Not yet, the practice is at Level 0 (no maturity level achieved) regardless of how Levels 2 and 3 score, the cumulative gate forbids crediting a higher level when a lower level is unmet.

27.2 Precise scoring

For the formal score, assign each answer a numeric value:

• Yes = 1.0
• Partial = 0.5
• No = 0.0

Question score. Each question scores 0.0, 0.5, or 1.0.

Level score. A level score is the sum of its three question scores, range 0.0–3.0.

Cumulative gate. Before a level score is credited, the gate is applied:

• A practice's Level 1 score always counts.
• A practice's Level 2 score counts only if Level 1 scored a full 3.0 (all three Level 1 questions Yes). If Level 1 is below 3.0, Level 2 is recorded for information but scored 0.0 toward the practice level.
• A practice's Level 3 score counts only if both Level 1 and Level 2 scored a full 3.0. Otherwise Level 3 is scored 0.0 toward the practice level.

The gate prevents an organization from claiming advanced maturity on a foundation that is not laid. A practice that has automated its tier-rule pipeline (Level 3) but has not published its risk-tier rubric (Level 2) is not Level 3, it is at the level its foundation supports.

Practice maturity score. With the gate applied, a practice's maturity score is the count of fully-passed consecutive levels, expressed as a decimal that includes partial progress on the next level:

• Practice level = (number of consecutive levels scoring a full 3.0) + (the score of the next level ÷ 3.0, if that next level's predecessor passed).

A practice with Level 1 = 3.0, Level 2 = 1.5, Level 3 ungated scores 1.5 (Level 1 complete, Level 2 half-done). A practice with Level 1 = 3.0, Level 2 = 3.0, Level 3 = 2.0 scores 2.67.

27.3 Maturity bands

Practice and domain scores map to four maturity bands:

27.4 Worked example, scoring one practice

Consider PC-Data (Policy & Compliance) for an organization roughly 18 months into its Data program.

Level 1 answers: - Q-PC-L1-1 (three priority policies + compliance map): Yes, 1.0 - Q-PC-L1-2 (sanction gate operational, ≥85% gate coverage): Yes, 1.0 - Q-PC-L1-3 (≥95% AUP attestation, named data steward per regulated asset): Yes, 1.0 - Level 1 score: 3.0, Level 1 passes the gate.

Level 2 answers: - Q-PC-L2-1 (tier-specific policy addenda, live compliance evidence bundle): Yes, 1.0 - Q-PC-L2-2 (DPIA gate operational, 100% Critical training corpora, ≤5 BD inquiry SLA): Partial, 0.5 (DPIA gate runs, but two Critical-tier fine-tuning datasets entered a training run before DPIA closure) - Q-PC-L2-3 (exception register with owners/expiry/monthly review, sector bundles complete): Yes, 1.0 - Level 2 score: 2.5, below 3.0.

Level 3 answers are recorded but, because Level 2 did not reach 3.0, the cumulative gate scores Level 3 at 0.0 toward the practice level.

Practice maturity score: Level 1 complete (one full level) + Level 2 progress (2.5 ÷ 3.0 = 0.83) = 1.83. PC-Data is in the Foundational band, with Level 2 most of the way done. The single Partial on Q-PC-L2-2 is the precise gap that the improvement roadmap (section 31) will name: close DPIA on the two outstanding fine-tuning datasets before any further training use.

28. The questionnaire

The 108 questions follow. Each practice has a subsection (28.1–28.12), and each subsection has nine questions, three per level. For every question, mark the answer, record the evidence pointer, and note anything the next assessor needs.

Answer key for every question:

Answer: ☐ Yes ☐ Partial ☐ No

28.1 Strategy & Metrics (SM)

Q-SM-L1-1. Is there a published AI/HAI Data Assurance program charter with a named executive sponsor (CISO + DPO/CPO + Head of Data or Engineering), a cross-functional working group, and unambiguous decision rights for approval, block, exception, and cross-border-flow approval across all seven data archetypes? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L1-2. Does a single AI/HAI data inventory exist, seeded from data catalogs, model-registry lineage, ETL/ELT pipeline metadata, object-store inventories, vector-store listings, classification-scanner findings, and prompt/completion log volumes, covering all seven archetypes with ≥90% coverage of discovered assets? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L1-3. Are the L1 outcome metrics baselined and reported quarterly to the sponsor, inventory coverage, shadow-data-in-AI ratio (≤15% and trending down), AI Data AUP attestation (≥95%), named-owning-team coverage (100%), and known regulated-data-in-AI exposure events? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L2-1. Is every data asset in the inventory assigned a risk tier from the seven auditable dimensions, data classification, lineage and provenance, volume and criticality, cross-border flows, use in training vs. inference vs. eval, decision-affecting use, and subject-access-rights exposure, with 100% of inventory carrying a current tier? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L2-2. Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML, and IM, with ≥95% of Critical-tier data assets receiving full-scope treatment (HSM-rooted encryption, full lineage, DPIA closure, retention enforcement, EU AI Act Art. 10 evidence) in the last 12 months? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L2-3. Does the quarterly shadow-data-in-AI scoreboard report per tier and per archetype, with Critical-tier unclassified or ungoverned data assets in production explicitly tracked at zero, and is tier-movement logged with rationale and reviewed by the program sponsor? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L3-1. Does inventory and tier assignment auto-update from live catalog, lineage, classifier, and pipeline telemetry against a published data-quality SLO (≥99% completeness; ≤48h tier latency on material change), with ≥80% of curation handled automatically and exception-based human review? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L3-2. Does the program publish a semi-annual external-benchmarking brief comparing itself against ≥5 peer-comparable metrics via CDMC, EDM Council, DAMA, sector ISACs, or ISO/IEC 23894, and does the brief drive program investment decisions? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SM-L3-3. Does the program contribute ≥4 substantive, anonymized artifacts per year to AI data-governance standards (DAMA, EDM Council, ISO/IEC 23894, NIST AI RMF Data, CSA AI Safety Initiative, OpenSSF AI, sector ISACs), and does the executive/board ROI narrative cite external benchmarks? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.2 Policy & Compliance (PC)

Q-PC-L1-1. Have the three priority AI/HAI data policies, AI Data Use Policy, Data Acceptable Use Policy (AI), and Data Intake / Sanction Gate, been published and formally approved with archetype-specific controls, consent-basis requirements, cross-border-transfer restrictions, and a named-data-steward requirement, accompanied by a one-page compliance map tracing each priority requirement (EU AI Act Art. 10/Annex IV/Art. 9, GDPR Arts. 5/6/9/22/30/32/35/44–49, ISO/IEC 42001, SOC 2 CC6/CC7, sector-specific) to the policy that carries it? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L1-2. Is the sanction gate operational with a per-archetype artifacts checklist, a published intake SLA (triage ≤5 BD; provisional approval ≤10 BD for Low-tier), and an amnesty path, and did ≥85% of new data sources entering AI production use in the last 12 months pass the gate (100% for Critical/High)? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L1-3. Have ≥95% of engineers and data scientists handling AI data acknowledged the AI Data AUP in the current year, and does every regulated data asset in AI production use have a named data steward logged in the SM-Data inventory? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L2-1. Have the three priority policies been extended with tier-specific addenda per the SM-Data L2 rubric, and do Critical data assets carry DPIA gate closure, DPO sign-off, HSM-rooted encryption confirmation, and reviewed legal-basis documentation before production training use, with a live compliance evidence bundle covering classification label, lineage record, legal-basis document, DPIA status, retention policy, Art. 30 record, transfer mechanism, access-controls attestation, and provider DPA status? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L2-2. Is the DPIA gate operational for all Critical training corpora and applicable High-tier assets (Art. 35 triggers), with 100% of Critical training corpora carrying a closed or accepted DPIA before production training use, and can a regulator or auditor inquiry be satisfied with provenance-complete artifacts within 5 business days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L2-3. Is an exception register operated with named owners, compensating controls, and expiry dates, reviewed monthly, with Critical-tier missing gate artifacts treated as blocking findings, and sector-specific evidence bundles (HIPAA / PCI-DSS 3.4 / FINRA-SEC as applicable) complete for in-scope assets? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L3-1. Does a continuous attestation pipeline auto-update evidence bundles from catalog events, lineage API updates, classification-scanner findings, retention-enforcement events, and cross-border-transfer changes, with an attestation currency SLO of ≤24h latency and ≤3 BD on-demand pack generation, and is ≥99% of Critical/High data assets continuously attested? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L3-2. Does the program run a quarterly, telemetry-driven policy-refresh cycle (ML-Data classification trends + IM-Data incident learnings + DPIA outcome patterns + a regulatory-motion tracker) with a versioned changelog where 100% of changes are traceable to a named signal or regulatory update? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-PC-L3-3. Does the program contribute ≥2 substantive public comments or standards artifacts per year on AI/HAI data-governance topics (EU AI Act Art. 10 implementing guidance, EDPB AI data-processing opinions, NIST AI RMF, ISO/IEC 42001, DAMA, sector regulators), with documented external recognition and zero material audit findings on AI/HAI data-governance controls in the last 12 months? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.3 Education & Guidance (EG)

Q-EG-L1-1. Have all engineers, data scientists, ML platform engineers, and analysts handling AI/HAI data completed a current-year AI-data-assurance literacy course covering the seven data archetypes, the five data-specific HAI TTPs (training-data poisoning, training-data leakage, retrieval-poisoning, embedding inversion, prompt injection via retrieved documents), the AI Data Use Policy rules, and the sanction-gate intake process, with ≥95% completion and content updated within 30 days of any policy or archetype change? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L1-2. Has the practitioner population (data stewards, DPOs/delegates, AppSec/AI safety reviewers) completed role-based training covering lineage verification, classification scanning and label propagation, consent-basis verification (GDPR Arts. 6/9), DPIA composition (Art. 35), opt-out and deletion enforcement, training-data canary insertion, embedding-store retention and inversion defense, and retrieval-source classification propagation, with completion gated on gate-approval permissions and calibration drift ≤1 classification-tier step and ≤1 DPIA-trigger disagreement per sample for two consecutive quarters? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L1-3. Is a shadow-data-in-AI awareness campaign running with at least monthly content, a visible amnesty path linked from the Data AUP and intake form, and measurable attribution of intake submissions and amnesty disclosures to campaign channels? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L2-1. Is there a scenario library of ≥30 anonymized real intake cases powering practitioner training across the org's in-scope data archetypes, with paired calibration exercises showing Critical-tier drift ≤1 classification-tier step and ≤0 DPIA-trigger disagreements per sample for two consecutive quarters? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L2-2. Have product-line-specific data-handler tracks (clinical AI, fintech AI, developer-tool AI, consumer AI, or equivalent for the org's product mix) been delivered to ≥1 practitioner per Critical/High-tier data asset, with team-level training coverage tracked in the SM-Data inventory? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L2-3. Are shadow-data-in-AI campaigns running on a seasonal, behavior-driven cadence with pre-set behavior targets and post-campaign measurement, with ≥70% of campaigns hitting their target, and is ≥80% of training content updated in the last 90 days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L3-1. Has the practitioner curriculum, anonymized scenario library, and reviewer rubric been published externally (CSA AI Safety Initiative, IAPP AI data-governance track, OpenSSF AI, DAMA, or sector ISAC) with documented adoption, citations, forks, or direct acknowledgment, and do external contributions loop back into internal content within 30 days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L3-2. Is a monthly live calibration cadence operating (anonymized intake from the live queue, independent reviewer scoring, drift reported to sponsor), with calibration results feeding the scenario library within 30 days, and do ≥50% of Critical-tier data reviewers hold an external AI-assurance or AI-data-governance credential where one exists? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EG-L3-3. Does the program contribute ≥2 substantive artifacts per year to industry AI-data-handler certification or curriculum working groups, and ≥1 MITRE ATLAS data-domain TTP contribution or confirmation per year (training-data poisoning, retrieval-poisoning, or embedding inversion) where novel observations exist? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.4 Threat Assessment (TA)

Q-TA-L1-1. Are there published, versioned threat models for all seven AI/HAI data archetypes, each mapping archetype-specific threats to HAI TTPs (EA/AGH/TM/RA), ATLAS tactic IDs and data-specific technique IDs (AML.T0019, T0020, T0024, T0025, T0010 where applicable), OWASP LLM Top 10 references, and PC-Data compliance items, with a named library steward and a documented quarterly refresh cadence? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L1-2. Does every AI/HAI data asset entering the SM-Data inventory receive a threat snapshot, delivered within one business day of intake, documenting the applicable archetype(s), asset-specific deltas (classification, lineage, cross-border flows, decision-affecting use, subject-access-rights exposure), top-5 threats with HAI TTP tags and ATLAS tactic/technique IDs, and gaps for SR/SA follow-up, with 100% of newly approved assets carrying a snapshot in the last 90 days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L1-3. Is there a published shadow-data-for-AI threat view, reviewed by the program sponsor in the last 12 months, documenting entry vectors, elevated threat scenarios for unsanctioned data-sharing with AI services, and the specific detections used to surface them? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L2-1. Does every Critical-tier data asset have a current-year per-asset deep threat model (not an archetype snapshot) covering asset-specific attack trees, an abuse-case catalog by adversary archetype, compliance-duty mapping, and a full ATLAS tactic walk with technique-level specificity, with a semi-annual refresh cadence and change-driven updates? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L2-2. Is external AI-data-attack threat intel (MITRE ATLAS updates including AML.T0019/T0020/T0024/T0025/T0010, AVID, OWASP LLM Top 10 revisions, sector ISACs, academic adversarial-ML venues) integrated with a quarterly triage cadence and a documented change-log, with intel-to-library update ≤30 days on Critical-impact items? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L2-3. Does the program run a quarterly red-team-the-library exercise that probes an in-scope AI/HAI data pipeline using only library threats and surfaces misses as library gaps, with every gap carrying a named owner and expiry date, Critical gaps closing within 30 days, and the gap rate trending down quarter over quarter? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L3-1. Does the threat library auto-update from telemetry (ML-Data detections, IM-Data incidents) and external feeds (ATLAS, AVID, OWASP, academic) via a human-curated auto-proposal pipeline, with ≥60% of changes auto-proposed, a ≤14-day lead time from signal to update, and a machine-readable change-log consumed by downstream SR and ST practices? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L3-2. Does the program contribute ≥4 substantive, evidence-backed technical artifacts per year to MITRE ATLAS / AVID / OWASP LLM/Agentic Top 10, with ≥2 externally recognized in published advisory or standard revisions? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-TA-L3-3. Are anonymized data archetype threat models published under a permissive license with tracked peer-org adoption, and does the program host or co-host at least one industry tabletop per year (ATLAS practitioner table, OWASP AI chapter, or sector ISAC AI working group) tied to the library? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.5 Security Requirements (SR)

Q-SR-L1-1. Is there a published, versioned AI/HAI Data Requirements Pack containing a base set (≤20 requirements) plus seven per-archetype deltas, with every requirement tagged to at least one TA-Data archetype threat and one PC-Data priority-compliance item, and are reviewers selecting from the pack rather than drafting requirements per asset at intake? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L1-2. Do 100% of new AI/HAI data assets approved for AI pipeline use in the last 90 days have a completed Requirements-Evidence Map (REM), with every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific verifiable evidence (consent record, DPA clause, DPIA reference, admin-console state, lineage record), each Gap-accepted row naming a compensating control, owner, and re-review date, and are material-change triggers defined? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L1-3. Is the pack on a quarterly refresh cadence with a named owner, are ≥90% of active data assets carrying a current-year REM with accepted-gap median age ≤90 days, and are SA, DR, IR, and ST practices citing REM rows rather than independently re-deriving requirements? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L2-1. Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (retention days, DSAR response time, key rotation interval, audit-log retention period) and binary state (no-train toggle confirmed, DPIA current, SCC mechanism documented, cross-border flow covered) specified, and has all qualitative "reasonable" and "appropriate" language been removed? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L2-2. Are ≥95% of Critical-tier REMs re-validated against observed reality (data-catalog, admin-console, audit log, IR findings, ML monitoring) in the last 90 days, with validation deltas routed to IM-Data and no Critical-tier accepted gap aging beyond 60 days without documented escalation to the program sponsor? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L2-3. Do 100% of Critical-tier personal-data assets carry a completed and current DPIA with DPO sign-off, and does the SR-Software cross-reference operate for Critical/High Software artifacts that consume these assets, with SR-Software REMs linked to the corresponding SR-Data REMs? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L3-1. Is the AI/HAI Data Requirements Pack expressed in a machine-readable schema and enforced via pipeline attestation at deploy time, with ≥80% of Critical-tier requirements having automated checks, zero Critical-tier assets entering AI pipelines with a failing REM check, and the schema published under a permissive license with tracked external adoption? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L3-2. Are ≥70% of REM evidence rows auto-validated via pipeline signals, runtime monitoring (ML-Data), and admin-console API ingestion, with automation error-rate monitored and human review reserved for exceptions, novel clauses, and accepted-gap escalations? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SR-L3-3. Does the program contribute ≥2 substantive artifacts per year (machine-readable requirement schema, REM schema, data-domain requirement clauses) to recognized standards bodies (OpenSSF AI, OWASP LLM, DAMA / EDM Council, NIST AI RMF Playbook), with contributions publicly documented and traceable to adoption? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.6 Secure Architecture (SA)

Q-SA-L1-1. Are seven reference patterns published, one per archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), each with a labeled data-flow diagram, classification flow, consent/lawful-basis check point, lineage/provenance hooks, access control model, logging spec, and explicit row-by-row mapping to SR-Data requirements and TA-Data threats with HAI TTP tags and applicable MITRE ATLAS technique IDs, accessible within one click of the SM-Data inventory record? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L1-2. Are 100% of training-corpus and fine-tuning-dataset assets verified (via data-catalog audit, not policy declaration) to have passed a classification-gating check and to carry a documented consent/lawful-basis record before entering any AI training pipeline, and is the anti-pattern catalog (minimum 10 entries) published and linked from the AI Data Policy, the SM intake gate, and EG-Data training, each entry tied to the incident that generated it? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L1-3. Is a repeat-deviation signal operational, three deviations in the same direction for the same archetype automatically queuing a pattern-update review with SA ownership, and are ≥85% of active AI/HAI data assets in the SM-Data inventory classified as "on pattern" or "deviation with review" with no silent deviations? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L2-1. Are the four tier-conditional extended patterns (Critical overlay, High overlay, multi-region/cross-border, multi-tenant) published as forkable IaC modules with conformance test suites, and are ≥80% of Critical and High-tier data assets running on IaC-encoded patterns as confirmed by the IaC and SM-Data inventory registries? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L2-2. Has the anti-pattern catalog been updated from ≥3 real IM-Data incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance testing covering 100% of IaC-encoded data-pipeline deployments with findings tracked to resolution? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L2-3. Are 100% of Critical-tier data assets using the Critical-tier overlay IaC module with automated transfer-mechanism verification, and does the SM-Data L2 tier-treatment matrix drive pattern-variant selection (Critical on Critical overlay, High on High overlay, Medium/Low on base pattern)? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L3-1. Have ≥5 reference patterns been published as open artifacts under a recognized open license via at least one industry body, and have ≥2 of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L3-2. Have ≥2 MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Data pattern controls aligned to primary data-attack ATLAS techniques (AML.T0019, T0020, T0024, T0025, T0010), with an active ATLAS practitioner engagement cadence? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-SA-L3-3. Is there at least one documented reference to SA-Data patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.7 Design Review (DR)

Q-DR-L1-1. Is there a published, versioned per-archetype AI/HAI Data Design Checklist, one per SM-Data archetype, traceable to the applicable SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot, with training-corpus and fine-tuning-dataset checklists covering DPIA trigger assessment, poison-detection scan scheduling, and opt-out-path design, and inference-input-stream checklists covering PII-redaction-edge design and no-train probe target? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L1-2. Do ≥95% of AI/HAI data flows going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before pipeline build-out begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Data L1, DPO acknowledgment for personal-data full-lane reviews, and a residual-risk list with named owner and expiry in every record? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L1-3. Are recurring pattern deviations and repeatedly-waived SR-Data requirements automatically queuing SA-Data pattern-update and SR-Data pack-update reviews, and does every IM-Data incident trigger a re-examination of the DR record that approved the affected data flow? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L2-1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Data per-flow deep models and anonymized IM-Data incidents, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L2-2. Is design-drift detection running quarterly for Critical-tier and annually for High-tier data flows, using data-catalog change webhooks, pipeline-metadata changes, lineage-graph changes, classification-label-scan deltas, and cross-border-routing changes, with 100% of material drifts automatically re-routed to DR for a new review? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L2-3. Are joint DR-Data / DR-Software review records on file for 100% of Critical-tier data flows feeding first-party AI software artifacts, with an explicit handoff boundary and shared residual-risk ownership documented in both DR records? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L3-1. Are ≥90% of Critical-tier AI/HAI data flows producing a daily automated SA-Data-pattern-compliance attestation signal, checking classification-label currency, lineage-graph bounds, consent-basis expiry, retention-enforcement status, encryption-key-vault binding, and cross-border routing, with deviations auto-opening DR-exception tickets triaged within 3 business days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L3-2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to OpenSSF AI Data, DAMA, EDM Council, or CSA AI Safety Initiative, with documented adoption and internal practice aligned to the published versions? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-DR-L3-3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS data-attack techniques, GDPR enforcement decisions, sector ISAC advisories) and internal signals (IM-Data incidents, ST-Data findings, ML-Data telemetry), with a versioned change log and notification to in-flight DR reviews affected by pattern changes? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.8 Implementation Review (IR)

Q-IR-L1-1. Is there a published, per-archetype IR checklist, one per SM-Data archetype, covering classification-label propagation verification, lineage-as-designed verification, consent-basis currency check, retention-enforcement verification, encryption-key-vault binding check, access-control verification, and DSAR-query accuracy test, with the inference-input-stream checklist including a PII-redaction canary test and a no-train vendor admin API probe? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L1-2. Do 100% of new AI/HAI data flows going to production in the last 90 days carry a go-live IR record, do ≥90% of all active data flows carry a current-year IR record, are material-change triggers wired to SM-Data inventory events, and are Critical/blocker findings resolved before production cutover and High findings closed within 7 days with evidence linked? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L1-3. Are findings severity-tagged and tracked in IM-Data with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Data REM row update before the finding is closed? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L2-1. Are ≥90% of Critical-tier AI/HAI data flows under continuous drift detection, via data-catalog change webhooks, pipeline-metadata events, lineage-graph signals, classification-label-scan deltas, vendor admin API recurrent probes, and cross-border-flow routing monitoring, with median detection latency ≤7 days and automated finding creation on material deviations? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L2-2. Are no-train flags and retention settings verified via vendor admin APIs (OpenAI / Anthropic / Bedrock / Vertex / equivalent) on a monthly (Critical) and quarterly (High) probing cadence, not from DPA text alone, covering ≥80% of Critical/High-tier flows with outbound LLM calls, with deltas from the previous probe opening IR findings with severity matching the data-class impact? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L2-3. Are 100% of Critical/High-tier data flows contributing to the DSAR surface covered by DSAR-query accuracy tests in the current IR cycle, confirming canary-subject inclusion, correct attribute return, and post-deletion exclusion, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Data L2 tier-treatment matrix SLAs? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L3-1. Are ≥90% of Critical-tier AI/HAI data flows producing a daily attestation signal across all four dimensions (classification-label currency, retention SLA, encryption-key-rotation health, no-train probe results green), with deviations auto-opening IM-Data tickets within 1 hour and zero stale-evidence violations for Critical-tier REMs? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L3-2. Has the program published per-archetype data-flow configuration baseline schemas to OpenSSF AI Data, DAMA, OWASP SAMM AI, or CSA AI Safety Initiative, with documented adoption and internal practice aligned to the published versions, and is IR reviewer-hours per Critical data flow per year trending down over two consecutive quarters? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IR-L3-3. Is the post-incident IR feedback loop operational, IM-Data post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident, ensuring incident learning continuously improves attestation coverage? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.9 Security Testing (ST)

Q-ST-L1-1. Is a per-archetype foundational test battery published for all seven AI/HAI data archetypes, with each test class tied to a TA-Data archetype threat (HAI TTP + ATLAS tactic/technique ID) and an SR-Data requirement, defined inputs/outputs/pass-fail criteria, and an evidence artifact, and are 100% of new AI/HAI data flows required to pass the battery before production Sanctioned status is issued? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L1-2. Are six regression corpora (poison-detection, retrieval-extraction, retrieval-poisoning, embedding-inversion, PII-redaction-edge, DSAR-query) versioned in source control, running in CI on every PR for Critical/High-tier data flows, with a named corpus owner, a monthly refresh cadence from internal and external sources, and a CI compute budget cap, and are ≥95% of Critical/High-tier PR merges verified to have run and passed the applicable corpus? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L1-3. Are all test failures routed to IM-Data within 1 business day with a severity tag and named owner, and does TA-Data archetype threat coverage by the test battery and corpus reach ≥80% by end of year one? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L2-1. Are 100% of Critical-tier AI/HAI data flows red-teamed at least quarterly, and 100% of High-tier semi-annually, with scope derived from TA-Data L2 per-flow deep threat models, covering poison-injection attempts, retrieval-extraction probes beyond the CI corpus, cross-tenant isolation probes, embedding-inversion attacks, DSAR-surface enumeration, opt-out bypass attempts, and eval-training contamination probes, with findings routed to IM-Data and remediation tracked? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L2-2. Is per-tier corpus calibration enforced in CI (Critical-tier: all 6 corpora on every PR + monthly no-train probe + quarterly DSAR-query accuracy; Low-tier: poison-detection corpus on merge), and are ≥90% of Critical/High-severity red-team findings converted to corpus entries within 30 days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L2-3. Are cross-archetype composition tests (training+eval contamination, embedding+retrieval inversion via retrieval, PII-input+log-corpus pass-through, fine-tuning+training lineage propagation) documented and executed for all Critical-tier data flows with composite archetype interactions, and is per-tier SLA adherence for testing activities ≥90%? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L3-1. Are ≥80% of Critical-tier AI/HAI data flows under continuous automated adversarial testing with daily probe execution, using poison-pattern generators, retrieval-extraction ladder generators, embedding-inversion probe generators, and PII-redaction-edge mutators, with novel data-attack techniques triaged into the TA-Data library within 14 days and high-severity automated findings routed to IM-Data within 24 hours? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L3-2. Has the program contributed ≥4 anonymized, legally-vetted findings per year to MITRE ATLAS, AVID, OWASP LLM, or NIST AI RMF Data, with at least one accepted as a new or refined data-attack technique, and are ≥4 open regression corpora published under a permissive license and maintained upstream? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ST-L3-3. Has the program hosted at least 1 industry-shared data-security exercise per year and participated in ≥2 additional cross-org exercises, with documented cross-org detection-benchmark improvement data from participants? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.10 Environment Hardening (EH)

Q-EH-L1-1. Does every AI/HAI data asset in the SM-Data inventory (across all seven archetypes) carry a classification label, a named owner, and a baseline hardening status, and are all training corpora and fine-tuning datasets gated at promotion by a signed SLSA-style provenance attestation that blocks unsigned datasets from entering the training pipeline? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L1-2. Do all data-facing consoles (data catalog, model registry, prompt-log store, vector store, embedding store) require SSO + MFA, with all pipeline service accounts running under named, vault-managed credentials confirmed by CI secrets-scanning with zero hardcoded-credential findings, and is every read, write, export, and delete event on AI/HAI data assets written to an append-only audit log with access-control separation between pipeline teams and log administrators? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L1-3. Are cross-border flows for regulated data assets documented with a transfer mechanism (SCC / adequacy / BCR) on file before replication activates, with all existing replication configurations reconciled against the transfer-mechanism registry, and are DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and actively monitored? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L2-1. Are 100% of Critical-tier AI/HAI data assets under HSM-rooted key management with per-tenant key separation at the storage layer and key rotation ≤30 days, and is zero-trust JIT access (≤4-hour time-limited, approval-gated) enforced for all interactive access to Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets, with standing interactive credentials deprecated for Critical-tier? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L2-2. Are ≥90% of Critical-tier data asset egress paths subject to content-inspection DLP, with false-positive rates actively monitored and trending down through monthly review cadences, and is a tier-hardening matrix published and enforced at provisioning with gaps tracked as open IM-Data findings? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L2-3. Is storage-layer residency enforcement (region-locked storage policies, not application-layer only) active for 100% of Critical-tier and High-tier residency-controlled data assets, confirmed by a quarterly storage-policy audit, and are archetype-specific custom DLP patterns deployed for each of the seven AI/HAI data archetypes? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L3-1. Are ≥90% of EH-Data controls expressed as authoritative IaC (not stubs) in a version-controlled IaC registry, with drift detected continuously and ≥70% of low-risk drift auto-remediated, with a machine-readable change log visible to downstream data-engineering teams and high-risk drift human-reviewed within 2 business days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L3-2. Is the adaptive-policy pipeline operational, with ML-Data detections and IM-Data incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream data-engineering teams notified within 24 hours of a tightening change affecting their asset's hardening profile? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-EH-L3-3. Does the program contribute ≥2 AI/HAI data hardening baselines per year to industry bodies (OpenSSF, DAMA, EDM Council, sector ISACs) with documented adoption, and are new AI/HAI data assets auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Data inventory registration? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.11 Issue Management (IM)

Q-IM-L1-1. Is there a single AI/HAI data issue backlog with standardized metadata (source, affected data asset linked to SM-Data inventory, archetype, severity rubric anchored to AI-specific data axes, owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA-Data, SR-Data, DR-Data, IR-Data, ST-Data, ML-Data, external)? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L1-2. Is the AI-specific data incident playbook published with seven named incident classes (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log breach, cross-border flow violation, consent-withdrawal not propagated, DSAR fulfillment failure), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L1-3. Is the regulatory SLA tracker live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), PCI-DSS, and applicable state privacy laws, with 100% adherence in the last 90 days, and does every Critical/blocker data incident produce a post-incident review within 14 days with named update outputs flowing to SA-Data, SR-Data, EG-Data, and ML-Data? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L2-1. Is a tier-calibrated data incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier data asset briefing with archetype-specific containment playbook paths, and tier-movement in the SM-Data inventory automatically triggering IM-Data configuration updates within 14 days (Critical re-tier)? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L2-2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA-Data/SR-Data/EG-Data/ML-Data practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L2-3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI data incidents, with named cross-domain contacts for Software, Infrastructure, and Processes domains verified quarterly, a single Incident Commander from the primary impacted domain, and joint post-incident reviews spanning all affected domains? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L3-1. Does the program contribute ≥4 anonymized AI data incident-classification entries per year to sector ISACs, ≥2 data vulnerability entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS TA0014 Impact tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L3-2. Are ≥3 pre-authorized automated containment actions live (retrieval store bulk-query disable, pipeline service-account access revocation for quarantined datasets, cross-border replication disable, embedding store bulk-export disable), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-IM-L3-3. Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per data incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes and deltas above benchmark linked to specific practice gaps and investment proposals? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

28.12 Monitoring & Logging (ML)

Q-ML-L1-1. Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI data archetype in the SM-Data inventory, and has compliance of each production data asset been measured against it within the last quarter (≥90% meeting the baseline)? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L1-2. Is a high-signal detection set of ≤12 detections active, each with a named owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, and last-tuned date, including classification-label drift, unclassified-data-flow, retrieval extraction attempt, embedding inversion attempt, training-data canary leakage, cross-border flow violation, retention-policy violation, no-train-flag flip, and consent-withdrawal non-propagation, with false-positive rates tracked per detection and monthly tuning reviews occurring? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L1-3. Has the evidence trail for EU AI Act Art. 12, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Data log store, with retention meeting the longest applicable regulatory window, and has a quarterly deployer-duty drill confirmed evidence-package assembly within the ≤24-hour SLA and a DSAR-capable export within ≤72 hours? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L2-1. Is tier-calibrated logging depth applied per the SM-Data L2 tier-treatment matrix, Critical-tier data assets retaining full event corpora at the longest regulatory window, Low-tier assets receiving baseline only, and is this calibration automatically updated when a data asset is re-tiered, with re-tier-to-Critical updates completing within 14 days? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L2-2. Is the SIEM ingesting ML-Data log feeds with ≥3 cross-archetype correlation rules active (covering the retrieval-to-embedding exfiltration chain, training-data canary plus consent-withdrawal correlation, and cross-border flow plus classification-escalation), and is a quarterly detection tuning cycle operating from IM-Data post-incident and ST-Data finding inputs, with DPA enforcement advisory review included? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L2-3. Are ≥90% of Critical/High-tier data assets running anomaly-detection baselines across retrieval query, embedding access, and training-pipeline event dimensions, with behavioral profiles refreshed monthly and false-positive rates tracked and trending down, and is the ML-Data logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier data assets in PC-Data compliance evidence bundles? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L3-1. Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic data-asset event patterns, and is detection coverage auto-verified for 100% of new or re-tiered SM-Data inventory entries within 24 hours of the inventory change event? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L3-2. Are ≥90% of Critical/High-tier data assets running anomaly detection on retrieval query, embedding access, and training-pipeline event corpora, with anomaly models retrained monthly on production event data, model versions tracked in the model registry with SLSA-style provenance, and anomaly-model alerts feeding the IM-Data backlog through the same detection-to-ticket pipeline as rule-based detections? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

Q-ML-L3-3. Has the program contributed ≥2 telemetry-standard artifacts per year to OWASP LLM data-detection patterns, DAMA, or equivalent, and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked? Answer: ☐ Yes ☐ Partial ☐ No Evidence: ___ Notes: ___

29. Practice-level rollup

Once all 108 questions are answered, each practice is rolled up to a maturity score using the precise method from section 27. Transcribe the level scores into the table below, apply the cumulative gate, and record the resulting practice maturity score and band.

Gate-applied column. Record what the cumulative gate did: "none" if L1 = 3.0 and L2 = 3.0 (all scores count), "L3 zeroed" if L2 < 3.0, "L2+L3 zeroed" if L1 < 3.0.

Practice score. Apply the section 27.2 formula: (consecutive full levels) + (next-level score ÷ 3.0, where the predecessor passed).

29.1 Worked example, practice-level rollup

An organization roughly 18 months into its Data program scores its twelve practices:

The pattern is typical: the Governance practices (SM, PC) lead, the Verification practices (DR, IR, ST) trail. DR, IR, and ST sit in the Ad-hoc band because their Level 1 is not fully closed, each has one Partial Level 1 question dragging the practice below 1.0. The cumulative gate has zeroed L2 for those three regardless of the Partial L2 progress, because Level 1 is not yet a foundation. The improvement roadmap (section 31) will treat closing DR-L1, IR-L1, and ST-L1 as the priority, there is no value in Level 2 work on a practice whose Level 1 is incomplete.

30. Domain-level rollup

The domain maturity figure is a single number that summarizes the twelve practice scores. It is used for board reporting and year-over-year tracking; it never replaces the practice-level table, which is where the actionable detail lives.

30.1 Domain maturity formula

Domain maturity = the arithmetic mean of the twelve practice scores.

Each practice contributes equally, the Data domain has no weighting that privileges one practice over another, because the practices form a dependency chain in which a weak link anywhere undermines the rest. The domain figure carries the same band labels as the practice scores: 0.0–0.9 Ad-hoc, 1.0–1.9 Foundational, 2.0–2.9 Comprehensive, 3.0 Industry-Leading.

A second figure, the domain floor, is reported alongside the mean: the lowest practice score in the domain. The floor catches the case the mean hides, a domain averaging 1.8 with one practice at 0.5 is not a healthy 1.8 domain; it has a Critical-tier exposure the mean is averaging away. A mature program reports both and manages the floor up before celebrating the mean.

30.2 Per-Business-Function rollup

The twelve practices map to the four HAIAMM business functions. Reporting the mean of each function's practices shows where the domain is strong and where it is thin:

The function rollup almost always shows Governance ahead and Verification behind in a young program, the policies, inventory, and threat library are authored before the design reviews, implementation reviews, and security tests that consume them mature into routine operation. A function score gap of more than one full band between Governance and Verification is a signal that the program has authored faster than it has operationalized.

30.3 Domain rollup table

30.4 Worked example, domain rollup for an org ~18 months in

Using the twelve practice scores from the section 29.1 worked example:

Practice scores: SM 1.83, PC 1.83, EG 1.67, TA 1.67, SR 1.50, SA 1.50, DR 0.83, IR 0.83, ST 0.67, EH 1.50, IM 1.33, ML 1.50.

• Domain maturity (mean): (1.83 + 1.83 + 1.67 + 1.67 + 1.50 + 1.50 + 0.83 + 0.83 + 0.67 + 1.50 + 1.33 + 1.50) ÷ 12 = 16.66 ÷ 12 = 1.39, Foundational band.
• Domain floor: 0.67 (ST), Ad-hoc. The floor is more than a full band below the mean; ST is the practice that most threatens the domain's stated maturity.
• Governance function score: (1.83 + 1.83 + 1.67) ÷ 3 = 1.78, Foundational, near the top of the band.
• Building function score: (1.67 + 1.50 + 1.50) ÷ 3 = 1.56, Foundational.
• Verification function score: (0.83 + 0.83 + 0.67) ÷ 3 = 0.78, Ad-hoc.
• Operations function score: (1.50 + 1.33 + 1.50) ÷ 3 = 1.44, Foundational.

The reading: the organization is a genuine Foundational-band Data program, the inventory exists, the policies are published, the tier rubric is mostly applied, the threat library and requirements pack are in use, and the operational practices (EH, IM, ML) are running. But the Verification function sits a full band behind the rest. DR, IR, and ST have not closed Level 1: data flows are reaching production without consistent design review, implementation verification, and test coverage. The domain maturity of 1.39 is real, but the floor of 0.67 says the honest summary is "Foundational, with a Verification gap that must close before the program can claim it governs data end to end." That sentence is what the board hears; the section 31 roadmap is how it gets closed.

31. Improvement roadmap template

The assessment produces a gap list, every question scored Partial or No, with its evidence note. The roadmap converts that list into a dated, owned, four-quarter plan. The sequencing rule is fixed: close Level 1 gaps before Level 2 gaps, and close Level 2 gaps before Level 3 gaps, for any given practice, the cumulative gate means Level 2 and Level 3 work scores nothing until the level beneath it is complete. Within a level, sequence by dependency: SM and PC unblock the rest of the domain, so their gaps lead; the SM-Data L2 risk-tier rubric is the prerequisite for every other practice's Level 2, so it is scheduled first among Level 2 work.

For each quarter, fill one table. Each row is one gap from the questionnaire.

Roadmap, Q1

Roadmap, Q2

Roadmap, Q3

Roadmap, Q4

Column guidance.

• Gap (question ID): the questionnaire ID of the gap, e.g. Q-ST-L1-2. One row per gap; do not bundle.
• Current answer: Partial or No, transcribed from section 28, with the evidence note that explains why.
• Target practice level: the practice maturity score the gap's closure unlocks, e.g. "ST → 1.0" (closing the last ST Level 1 gap moves ST out of the Ad-hoc band).
• Owner: a named individual, not a team. Data Governance lead, a named data steward, a named DPO delegate, a named ML platform engineer.
• Success metric: the observable, quantitative condition that proves the gap is closed, the same condition the questionnaire asks for. "≥95% of Critical/High-tier PR merges run and pass the applicable regression corpus" not "improve testing."
• Due: a calendar date inside the quarter.

31.1 Worked example, Q1 roadmap for the org from section 30.4

The section 30.4 organization has its floor at ST (0.67) and a Verification function a full band behind the rest. Its Q1 roadmap targets the Level 1 gaps that the cumulative gate makes most valuable to close, the DR, IR, and ST Level 1 gaps that, once closed, move three Ad-hoc practices into the Foundational band and unlock all the L2 work currently scoring zero.

The Q1 plan closes the three Verification Level 1 gaps first, that is where the cumulative gate is destroying the most value, and closing them moves DR, IR, and ST from Ad-hoc to Foundational in one quarter. One Level 2 row (Q-SM-L2-2) is included because SM has already closed Level 1, the gap is narrow (three named assets), and closing it lifts SM into the Comprehensive band while strengthening the tier-treatment substrate every other practice's Level 2 depends on. Q2–Q4 then take the remaining Level 2 gaps in dependency order, SM-Data L2 and PC-Data L2 first because they unblock the rest, and Level 3 work is not scheduled until every practice has reached a full Level 2.

Part V, Reference

32. Glossary

AI Data Use Policy. The first of the three priority AI/HAI data policies. Governs what data classes may be used for training, inference, and evaluation and under what consent basis; sets the cross-border-transfer restrictions, the use-change-notification rule, and the GDPR Art. 9 special-category prohibition default.

Data Acceptable Use Policy (AI). The second priority policy. Enumerates permitted, approval-required, and prohibited actions for engineers and data scientists handling AI/HAI data assets, plus the disclosure obligation to the SM-Data inventory and the attestation requirement.

Data Intake / Sanction Gate Policy. The third priority policy. Makes intake mandatory before any new data source enters production AI use, lists the required per-archetype gate artifacts, exposes an amnesty path for previously ungated assets, and names the gate-decision authority.

AGH, Agent Goal Hijack. One of the four HAI-specific TTPs. In the Data domain the trusted path is the retrieval store or prompt/completion history, poisoned content planted in a corpus the agent treats as authoritative.

AI/HAI data archetype. One of seven categories of data flowing into or out of AI/HAI systems: training corpus/dataset, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set. Threat libraries, requirements, reference patterns, and tests are archetype-keyed.

AI/HAI data inventory. The single source of truth for all data assets feeding or produced by AI/HAI systems, owned by the program lead. Seeded from data catalogs, model-registry lineage, ETL/ELT metadata, object-store inventories, vector-store listings, classification-scanner findings, and prompt/completion log volumes.

Classification label. A documented Critical/High/Medium/Low sensitivity label attached to a data asset, propagated through every pipeline transform and honored by downstream consumers.

Consent basis / lawful basis. The documented GDPR Article 6 ground (and Article 9 condition for special-category data) under which personal data may be processed in training, inference, or evaluation.

Cross-border transfer mechanism. An adequacy decision, Standard Contractual Clauses (SCC), International Data Transfer Agreement (IDTA), Binding Corporate Rules (BCR), or Art. 49 derogation documented for a personal-data flow crossing a GDPR Chapter V boundary.

Critical / High / Medium / Low. The four risk tiers introduced at SM-Data L2. Driven by data classification, lineage and provenance, volume and criticality, cross-border flows, training-vs-inference use, decision-affecting use, and subject-access-rights exposure.

DPIA, Data Protection Impact Assessment. The GDPR Article 35 assessment required for high-risk processing of personal data. The DPIA gate is a mandatory step in the sanction gate for Critical-tier training corpora and fine-tuning datasets.

DSAR, Data Subject Access Request. A data subject's exercise of GDPR Articles 15–22 rights (access, rectification, erasure, etc.). The DSAR surface is the set of AI/HAI data assets that must be queryable and, for erasure, deletable per subject.

EA, Excessive Agency. One of the four HAI-specific TTPs. In Data terms, the over-broad data grant, a retrieval store or fine-tuning corpus reaching data classes the use case never required.

Embedding inversion. Reconstruction of approximate source text, including PII, from the high-dimensional vector representations held in an embedding store. The reason embeddings are not anonymous and embedding stores are a first-class Data concern.

HAI TTPs (EA, AGH, TM, RA). The four AI-specific threat-tactic categories carried throughout HAIAMM v3.0: Excessive Agency, Agent Goal Hijack, Tool Misuse, Rogue Agents.

No-train assertion. Confirmation, at the vendor admin-console / API level, not from contract text alone, that data sent to a vendor LLM API is not used to train the vendor's models. Re-verified on a recurrent cadence.

Priority compliance map. A one-page artifact tying each priority regulatory requirement to the specific organizational policy that carries it.

RA, Rogue Agents. One of the four HAI-specific TTPs. In Data terms, drifting agents that accumulate, retain, or propagate data outside policy.

REM, Requirements-Evidence Map. A per-asset map recording, for each applicable requirement in the AI/HAI Data Requirements Pack, whether the requirement is Met, Met-with-compensating-control, Gap-accepted, or Not-applicable, with a citation to evidence.

Reference pattern. A vetted "green path" architecture pattern published per AI/HAI data archetype. Data engineering teams reach for the pattern first; deviations require design review.

Retrieval poisoning. Planting hostile content, typically indirect prompt-injection instructions, in a retrieval store so it is returned as authoritative context to a RAG pipeline. A primary AGH vector in the Data domain.

Risk-tier rubric. A short table introduced at SM-Data L2 deriving a deterministic risk tier from auditable inputs. Drives the differential intensity of every downstream practice's L2 and L3 work.

Shadow data in AI / ungoverned data flow. Data flowing into or out of AI systems outside the program's visibility, attribution, and governance. The Data-domain program's primary L1 outcome is to make ungoverned data flows visible, attributable, and trending down.

Shadow-data-in-AI ratio. Data assets flowing to AI without a known owner or classification, divided by total AI data assets. A primary L1 outcome metric. Reported quarterly and trending down; reported per tier at L2.

TM, Tool Misuse. One of the four HAI-specific TTPs. In Data terms, a data-access tool or query interface invoked to exfiltrate beyond intended scope.

Training-data leakage. Memorized corpus content surfacing in model outputs, recoverable by targeted generation. Detected with training-data canaries.

Training-data poisoning. Corrupted, label-flipped, or backdoor-triggered records in a training corpus that corrupt model behavior. Detected with poison-detection scans at ingest.

33. Reference frameworks

This handbook is one of six domain handbooks that, together with a master handbook, constitute HAIAMM v3.0. The frameworks named here are referenced throughout. They are listed by name only; consult the issuing body's current published version when running an assessment.

Maturity-model lineage.

• OWASP SAMM (Software Assurance Maturity Model). HAIAMM borrows SAMM's lifecycle shape (Governance, Building, Verification, Operations) and practice-per-function structure.
• BSIMM (Building Security In Maturity Model). HAIAMM borrows the observational "this is what organizations actually do" posture at higher maturity levels.

AI-governance and data-governance frameworks (complementary).

• NIST AI RMF 1.0 + Playbook. The risk-management-framework counterpart to HAIAMM's maturity-model shape. NIST AI RMF MAP and MEASURE functions align closely to Data-domain TA/SR and DR/IR/ST work.
• ISO/IEC 42001 (AI Management System). A management-system standard for AI. HAIAMM Data-domain practices supply the data-governance operational evidence an ISO 42001 AIMS requires.
• ISO/IEC 23894 (AI risk management). AI risk-management guidance; HAIAMM contributes data-domain implementation guidance at L3.
• DAMA DMBOK / EDM Council DCAM. Classic data-management maturity references. HAIAMM extends them into AI-specific data territory and benchmarks against them at L3.
• CDMC (Cloud Data Management Capabilities). A data-management maturity benchmark used for external comparison at L3.

Regulations applicable to AI/HAI data.

• EU AI Act. Article 10 (data governance for high-risk AI), Annex IV (technical documentation), Article 12 (logging), Article 26 (deployer duties), Article 9 (risk management).
• GDPR. Article 5 (principles), Article 6 (lawful basis), Article 9 (special-category data), Article 22 (automated decision-making), Articles 15–22 (data subject rights), Article 30 (records of processing), Article 32 (security), Articles 33/34 (breach notification), Articles 44–49 (international transfers).
• SOC 2. CC6 / CC7 trust services criteria applicable to AI data stores.
• HIPAA. Safeguards on PHI in training, retrieval, and inference; minimum-necessary; BAA coverage.
• PCI-DSS 3.4. Controls on cardholder data in model-input data and prompt/completion logs.
• Sector-specific. FINRA/SEC recordkeeping (17a-4, FINRA 4370), FCRA, FERPA, and sector data-residency rules where applicable.

Threat taxonomies.

• MITRE ATLAS (Adversarial Threat Landscape for AI Systems). Canonical adversarial-ML reference. Data-domain TA consumes ATLAS data-attack technique IDs, AML.T0010 ML Supply Chain Compromise, AML.T0019 Publish Poisoned Datasets, AML.T0020 Poison Training Data, AML.T0024 Exfiltration via ML Inference API, AML.T0025 Exfiltration via Cyber Means, AML.T0048, AML.T0051 LLM Prompt Injection, and contributes back at L3.
• OWASP Top 10 for LLM Applications. Threat reference for LLM data handling, prompt leakage, and training-data risks. Consumed by TA-Data; reviewed in EG-Data curriculum.
• AI Vulnerability Database (AVID). Catalog of disclosed AI-specific vulnerabilities. Consumed by TA-Data; contributed to at L3.

Industry communities.

• CSA AI Safety Initiative / AI Controls Matrix. Cross-organization AI controls work; HAIAMM contributes the data-domain controls and curriculum at L3.
• OpenSSF AI. Open Source Security Foundation working group on AI. HAIAMM contributes training-data supply-chain advisories, embedding-store security guidance, and requirement schemas at L3.
• IAPP AI data-governance track. Privacy-practitioner community; HAIAMM contributes DPIA templates and reviewer curriculum at L3.
• Sector ISACs. FS-ISAC, H-ISAC, IT-ISAC, and others provide intelligence sharing for AI data incidents.

HAIAMM canonical companions.

• HAIAMM-v3.0-Framing.md, model master document; canonical definitions for the 12 practices, 6 domains, 3 maturity levels, cell template, dependency graph, through-lines, and authoring rules.
• AI-Attack-Taxonomy.md (HAA), high-impact AI attacks catalog cross-referenced to MITRE ATLAS.
• AI-Threat-Assessment-Methodology.md / Threat-Modeling-Methodology.md, organization-wide and per-system threat-modeling methodologies that the TA practice operationalizes.

Threat-tactic categories specific to HAIAMM (reproduced for reference).

• EA, Excessive Agency. The AI or agent has more capability, or reaches more data, than its use case requires.
• AGH, Agent Goal Hijack. The agent's benign goal is redirected by content injected along a trusted-looking path, including a poisoned retrieval store.
• TM, Tool Misuse. Tools or query interfaces available to the AI are invoked for attacker purposes, including data exfiltration beyond scope.
• RA, Rogue Agents. Autonomous agents drift from intended behavior, accumulating or propagating data outside policy.

34. Change log

End of HAIAMM v3.0 Data Domain Handbook.