Security Requirements (SR)

Data Domain - HAIAMM v3.0

Practice Overview

Objective: Translate the threats from TA-Data and the policies from PC-Data into a reusable Requirements Pack for AI/HAI data assets, a base set plus per-archetype deltas, so every data asset entering or produced by an AI pipeline carries a testable Requirements-Evidence Map (REM) 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 (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, 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) that links 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

At this level, the organization stops re-deriving requirements intake by intake and starts selecting, adapting, and evidencing from a shared pack that every practice inherits.

Dependencies

• TA-Data L1 (required): requirements derive from the archetype threat library, without the threat library the pack is arbitrary rather than threat-driven.
• PC-Data L1 (required): requirements inherit policy guardrails and the priority compliance map (GDPR Arts. 6, 9, 17, 22, 28, 32, 35, 44–49; EU AI Act Arts. 10, 26; ISO/IEC 42001; SOC 2 CC9.2).
• SM-Data L1 (required): the SM inventory scope and archetype taxonomy define which assets the pack applies to and which archetype deltas are relevant.
• Supports / unblocks: SA-Data L1 (reference patterns implement the requirements), DR-Data L1 (design reviews check proposed pipelines against the pack), IR-Data L1 (implementation reviews verify the REM evidence is accurate), ST-Data L1 (security tests target the requirements), IM-Data L1 (findings route to the REM gap register).

Desired Outcomes

• A single AI/HAI Data Requirements Pack exists; data engineers, privacy engineers, and AppSec reviewers select from it rather than drafting from scratch at each intake.
• Every AI/HAI data asset approved for use in an AI pipeline has a REM showing which pack requirements are met (by what evidence), which gaps are accepted (with a named owner and expiry date), and which compensating controls are in place.
• GDPR Art. 6 lawful basis, Art. 28 processor obligations, Art. 35 DPIA conditions, and EU AI Act Art. 10 training-data quality requirements are traceable to specific pack requirements, not hand-waved in narrative.
• The pack is versioned, owned, and refreshed quarterly as threats (TA) and compliance expectations (PC) evolve.
• Downstream practices (SA, DR, IR, ST) inherit the REM rather than re-deriving requirements independently.

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 short (target ≤20 base requirements at L1). Each requirement has: an ID, a statement, a rationale (threat tag from TA-Data + 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 classification label (Critical / High / Medium / Low based on data sensitivity, regulatory status, and decision-affecting use); labels propagate through pipelines; downstream consumers honor them and do not process the asset beyond its classification scope; a classification label is required before the asset is approved for use in any AI system.
• Consent and lawful basis: documented GDPR Art. 6 lawful basis for processing; Art. 9 special-category-data condition documented where applicable (health data, biometric data, ethnic-origin data); consent verification performed before personal data is included in training or fine-tuning; re-use for secondary AI purposes (e.g., using inference logs as fine-tuning data) requires a new lawful-basis assessment.
• Lineage and provenance: every data asset has a documented source and chain-of-custody from origin to AI system entry; lineage metadata stored with the asset record; any transformation or curation step is recorded; source no longer accessible or trustworthy triggers re-classification.
• Retention: retention policy defined per archetype and per classification; retention schedule enforced by automated policy rather than manual cleanup; expiry enforced, assets past retention are purged or anonymized; DSAR deletion obligations can be fulfilled within the statutory period.
• Cross-border flows: GDPR Arts. 44–49 transfer mechanism documented for every cross-border flow involving personal data, adequacy decision, SCC, BCR, or Art. 49 derogation; mechanism recorded in the asset's REM and linked to the DPA or transfer agreement; assets containing personal data must not flow to a third country without a documented mechanism in place.
• Encryption: encryption at rest with documented key management (key separation by classification tier or by tenant where applicable); encryption in transit (TLS 1.2+ for all data-in-transit paths); key rotation schedule documented and enforced.
• Access control: RBAC plus classification-aware authorization, access rights scoped to the minimum required for the stated AI use case; service-principal model for pipeline access (no shared credentials); audit log of every access event (read, write, export, delete) retained to meet the longest applicable regulation; 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 is confirmed at the admin-console level and not trusted from contract text alone; no-train assertion re-verified on a documented cadence (not only at initial DPA review); a failed re-verification routes to IM as a Critical finding.
• Data Subject Access Rights (DSAR): capability to locate personal data belonging to a specific subject within training datasets and prompt/completion logs; DSAR response capability within GDPR Arts. 15–21 statutory timelines (30 days, extendable to 90 days); capability to execute Art. 17 deletion requests, remove subject data from training corpora and from logs, with a documented process for notifying downstream model-training teams of required retraining or fine-tune data removal.

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

On top of the base pack, each archetype carries a short delta (typically 3–8 additional requirements) reflecting the threat-specific and regulatory obligations from TA-Data's archetype threat models.

Deltas to ship at L1:

• Training corpus / training dataset: data-class pre-flight, no regulated PII, PHI, or customer-confidential data enters training without a documented GDPR Art. 6 lawful basis and, where applicable, Art. 9 special-category condition; DPIA completed if processing is likely to result in high risk to natural persons (Art. 35, training at scale on personal data typically triggers this); poisoned-data detection scan performed at ingest (automated or manual sampling) before the corpus is approved for training use; opt-out enforcement, a mechanism exists to exclude data from subjects who have exercised GDPR Art. 21 right to object or Art. 17 right to erasure, with documented propagation to downstream training jobs.
• Inference input stream: PII redaction at input-edge, personal data is identified and redacted or pseudonymized before transmission to a vendor LLM API unless the DPA explicitly covers the data class; classification-gated routing, regulated personal data (Art. 9 special categories) does not reach a vendor LLM endpoint whose no-train status is unverified; per-tenant context isolation, inputs from one tenant are not accessible in another tenant's inference context.
• Retrieval store: classification-labeled documents, every document in the retrieval index has a classification label at index time; per-tenant retrieval isolation, namespace partitioning prevents cross-tenant content retrieval; injection-defense requirement, retrieved content is treated as untrusted; provenance metadata on every retrieved chunk (source, last-verified date, classification); embedding-store access control, the underlying vector index is not world-readable.
• Prompt/completion log corpus: PII redaction at logging, prompt and completion text is screened and PII is redacted or pseudonymized at log-write time; retention by archetype, prompt/completion logs are subject to a retention schedule aligned to the GDPR Art. 5(1)(e) storage-limitation principle; export through a controlled DSAR-capable interface, no bulk export without access-control enforcement; per-tenant partitioning, log records are partitioned by tenant; no prompt/completion logs used as fine-tuning data without a new lawful-basis assessment.
• Embedding store: access control on raw embeddings, vector embeddings are not accessible without classification-aware RBAC; inversion-defense controls, clipping or noise mechanisms applied to embeddings of sensitive content; retrieval-only access model (no direct vector download without explicit authorization); per-tenant partitioning, embedding namespaces separated by tenant.
• Fine-tuning dataset: DPIA-gated curation, a DPIA is completed before a fine-tuning dataset containing personal data is approved; consent-tracked subject inclusion, each subject's consent basis is recorded with the dataset record; opt-out enforcement, subjects who have withdrawn consent are excluded before fine-tuning commences; lineage to training-job event, the dataset version used in each fine-tuning job is recorded for audit and for DSAR propagation.
• Evaluation / test set: isolation from training, eval set data does not flow to training pipelines; contamination-prevention gate, a deduplication check confirms no overlap between the eval set and the training corpus before evaluation runs; reproducibility metadata, eval set version, model version, and evaluation date recorded and retained; access control, eval set 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. Structure:

• Each applicable pack requirement (base + archetype delta) marked: Met / Met-with-compensating-control / Gap-accepted / Not-applicable (with justification for N/A).
• Each Met row cites specific evidence: classification label in the data catalog, consent-basis record, lineage record, DPA clause citation, admin-console screenshot, audit-log sample, DPIA reference, or test result reference.
• Each Met-with-compensating-control row describes the control, its coverage, and its limitations.
• Each Gap-accepted row names a compensating control (if any), a named owner, a re-review date (maximum 90 days at L1), and the residual-risk rationale accepted by the named sponsor.
• REM is stored with the SM inventory record for the data asset and linked from the intake ticket.

Material changes (new data source added to corpus, classification change, new cross-border flow, new downstream AI use) trigger REM re-review before the change is approved.

Outcome Metrics (L1)

Process Metrics (leading)

• Pack review cadence, quarterly refresh recorded; changes change-logged.
• REM turnaround, median ≤3 business days from threat snapshot (TA) to REM completion.
• Reviewer consistency, calibration on sample REMs produces ≤2 row-level diffs across independent reviewers.
• Material-change trigger rate, % of pipeline changes that trigger a REM re-review vs. changes that proceed without triggering one (expected zero unreviewed material changes at L1).

Effectiveness Metrics (business value)

• Requirements reused vs. invented, ≥80% of REM rows reference the pack unchanged; the remainder are archetype adaptations; zero rows invented per-intake from scratch.
• DSAR readiness, GDPR Arts. 15–21 subject-access inquiries answered via REM evidence without re-collection.
• Audit readiness, EU AI Act Art. 10 training-data quality inquiries and GDPR Art. 30 record-of-processing inquiries answered from REM without a separate collection exercise.

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; median age inside ≤90 days; every gap has a named owner and re-review date.

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

At this level, every requirement in the pack is either measurable (with a specific SLA) or binary (with an explicit evidence condition). REM rows are validated against observed reality for Critical/High-tier data assets, attestation is never trusted without corroboration. Accepted-gap aging is managed per tier. The pack differentiates meaningfully across tiers rather than applying the same base list universally. Critical-tier data assets carrying personal data at scale require DPIA completion and executive sign-off as explicit gate conditions. SR-Data REMs for data assets consumed by Software-domain artifacts cross-reference SR-Software REMs, closing the Software–Data traceability gap.

Dependencies

• SR-Data L1 (required): base pack, archetype deltas, and REM template must be established before quantitative refinement is meaningful.
• SM-Data L2 (required): the risk-tier rubric (based on classification, lineage, volume/criticality, cross-border flows, decision-affecting use, subject-access-rights exposure) determines which assets receive full per-tier treatment.
• TA-Data L2 (required): per-asset deep threat models inform per-asset requirement adjustments for Critical-tier assets.
• Supports / unblocks: SA-Data L2, DR-Data L2, IR-Data L2 (each inherits the quantitative per-tier pack), ST-Data L2 (tests validate pack SLAs directly).

Desired Outcomes

• Every requirement in the pack carries a specific, testable condition, a concrete SLA or a binary evidence condition, with all qualitative "reasonable" or "appropriate" language removed.
• REM rows for Critical and High-tier data assets are re-validated against observed reality at least quarterly (Critical) and semi-annually (High), not on attestation alone.
• Accepted-gap backlog aging is managed per tier: no Critical-tier gap stays open beyond 60 days without documented escalation to the program sponsor.
• Per-tier pack differentiation is visible and enforced: Critical-tier assets carry DPIA plus executive sign-off requirements and tight gap-aging SLAs; Low-tier assets run on base pack only.
• SR-Data REMs cross-reference SR-Software REMs for Software-domain artifacts that consume the data assets, enabling end-to-end compliance traceability.

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, ≤730 days for High-tier; last rotation date on file with zero overdue keys."
• No-train assertion: binary, "vendor API admin-console setting 'Training on your data' confirmed OFF as of [date], screenshot on file; re-verification scheduled quarterly; last re-verification result on file."
• DSAR deletion capability: SLA, "data-subject deletion requests fulfilled within 30 calendar days for standard requests, 60 days for complex training-corpus cases; last DSAR test result on file; zero requests past 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, "SCC / adequacy / 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, "DPIA completed and signed by DPO before the asset was approved; DPIA reviewed within the last 12 months or on material change; no Critical-tier personal-data asset active without a current DPIA."
• Access control audit log: SLA, "audit log retained ≥24 months for Critical-tier, ≥12 months for High-tier; log exportable within 5 business days of regulator or DSAR request; 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:

• Critical tier: full base pack + all applicable archetype deltas; DPIA mandatory (binary gate, no Critical-tier personal-data asset active without a completed and current DPIA); executive sign-off required (named DPO or Privacy Officer sign-off on the completed REM before pipeline approval is issued); full REM required (no rows left blank); accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; re-validation of all Critical-tier REM evidence quarterly; SR-Software cross-reference required for every Software-domain artifact that consumes the asset.
• High tier: full base pack + applicable archetype deltas; DPIA required where Art. 35 triggers apply; REM required; accepted-gap aging SLA of 90 days; re-validation of REM evidence semi-annually.
• Medium tier: base pack + applicable archetype deltas; DPIA recommended but not mandatory unless Art. 35 triggers apply; REM required; accepted-gap aging SLA of 120 days; re-validation annually.
• Low tier: base pack only; REM required; fast-track process (abbreviated evidence citations acceptable); re-validation at annual review.

C) Continuous REM-evidence validation and cross-domain linkage

Critical-tier REMs re-validated quarterly; High-tier semi-annually. Validation method: select N REM rows per asset (stratified sample, at least one row per base category), verify each cited evidence artifact against current observable reality: - Classification label: confirm label matches current data-catalog entry. - No-train: re-confirm admin-console setting and contract clause currency. - Retention: re-run retention-policy report; confirm zero overdue assets. - Access control: confirm RBAC assignments match stated scope; confirm no unauthenticated access events in audit log. - DPIA currency: confirm DPIA reviewed within the last 12 months or since last material change. - Cross-border flow mechanism: confirm SCC or adequacy decision current; no new flows added without a mechanism.

SR-Software cross-reference: for every Software-domain artifact (LLM-integrated app, agent, RAG pipeline, fine-tune/training workload) that consumes a data asset, the SR-Software REM for that artifact references the SR-Data REM for the data asset. A change in the data asset's classification or compliance status triggers a flag on the consuming Software artifact's REM.

Validation deltas are routed to IM-Data as findings with severity tags and remediation SLAs matching the asset's tier. Accepted-gap aging reviewed monthly; gaps approaching the escalation threshold notify the named owner before the deadline.

Outcome Metrics (L2)

Process Metrics (leading)

• Pack change-log, ≥1 substantive update per quarter reflecting new TA threats or PC compliance updates.
• REM validation sampling calendar, no missed quarters for Critical; no missed semi-annual cycle for High.
• Accepted-gap escalation SLA met, no gap hits escalation threshold without prior notification to the named owner.
• Cross-domain linkage health, no Critical-tier data asset actively consumed by a Software artifact whose SR-Software REM lacks the SR-Data cross-reference.

Effectiveness Metrics (business value)

• Time-to-regulator-inquiry drops as REM evidence is pre-assembled rather than collected on demand.
• DSAR response time stays inside statutory deadlines, tracked as a rolling 12-month average.
• Audit pass rate on AI-specific data controls, external auditors (SOC 2, ISO 42001, GDPR DPA inquiry) find REM evidence sufficient without supplemental interviews.

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.
• Accepted-gap backlog inside aging targets per tier; no Critical-tier gap past 60 days without documented escalation.
• 100% of Critical-tier personal-data assets have 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

At this level, the requirements pack and REM become machine-processable. Data pipeline deployments attest that an asset satisfies its REM at pipeline-deploy time, a pipeline that fails a Critical-tier REM requirement is blocked at the gate, not caught weeks later at the next manual review. The pack is published as a referenceable artifact adopted by OpenSSF AI, OWASP, DAMA / EDM Council, and the NIST AI RMF Playbook reference pack ecosystem.

Dependencies

• SR-Data L2 (required): quantitative pack and continuous validation must be mature before automation is trustworthy.
• PC-Data L3 (required): compliance-evidence automation substrate (machine-readable attestation) is the substrate that SR L3 pipeline gates consume.
• ML-Data L2+ (required): runtime signals (access log completeness, retention enforcement run results, no-train re-verification outputs) are the evidence sources that REM auto-validation reads.

Desired Outcomes

• A pipeline deploy fails the gate if a Critical-tier REM requirement is unmet, compliance is enforced at deploy time, not audited afterward.
• REM evidence is largely auto-validated; human review goes to novel clauses, edge-case N/A justifications, and accepted-gap escalations.
• The pack is referenced and adopted outside the organization, standards bodies cite it; peer organizations use the REM schema.
• The program contributes to the emerging vocabulary of machine-readable AI data security requirements (OpenSSF AI, OWASP LLM / Agentic, DAMA / EDM Council AI Data Governance, NIST AI RMF Playbook reference packs).

Activities

A) Machine-readable pack and pipeline attestation

Express the Requirements Pack (base + 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 / 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 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; 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; emit a warning and auto-route 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 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 trigger auto-flagging of 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. - GDPR supervisory authority guidance updates and adequacy-decision status changes, auto-flag cross-border-flow REM rows when an adequacy decision is suspended or a new SCC version is published.

Human review reserved for: novel requirement types not yet in the structured schema; accepted-gap escalations; DPIA sign-off; DSAR complex cases.

C) Standards contribution

Contribute to: - OpenSSF AI working group, machine-readable requirement schema for AI/HAI data security; REM schema as an open artifact. - OWASP LLM / Agentic Top 10, practitioner input on data-handling, training-data, and retrieval-store requirement categories and evidence conditions. - DAMA International / EDM Council AI Data Governance working groups, contribute the data-archetype REM schema as a referenceable AI data governance artifact. - NIST AI RMF Playbook reference packs, submit practitioner commentary on MEASURE and MANAGE function requirement language for data domain, grounded in REM experience.

Target: minimum 2 substantive contributions per year; legally vetted and anonymized.

Outcome Metrics (L3)

Process Metrics (leading)

• Structured-schema coverage, % of requirements expressed in machine-readable form (target: growing toward 100% of Critical/High-tier requirements).
• Automation error-rate monitored, false-positive and false-negative gate failures tracked; threshold triggers human review.
• Contribution pipeline ≥2 in-flight at any given time.
• Pack published version freshness, public version aligned with internal version (no version lag exceeding one quarter).

Effectiveness Metrics (business value)

• Reduced time-to-production for compliant data assets, the pipeline gate replaces manual REM review cycles for the ≥70% of requirements with automated checks.
• Zero Critical-tier pipeline deploys with unmet REM requirements reaching production, the gate enforces what used to be a post-hoc audit.
• Industry recognition as a contributor to AI data security requirements standards.

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.
• Zero Critical-tier data assets entering AI pipelines with a failing REM check (gate enforcing).
• Pack + REM schema published under permissive license with tracked external adoption.
• ≥2 substantive industry-standard contributions per year.

Key Success Indicators

Level 1: - AI/HAI Data Requirements Pack published: base set (≤20 requirements) plus seven per-archetype deltas (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), every requirement tagged to a TA-Data archetype threat and a PC-Data priority compliance item; reviewers selecting from the pack, not drafting per intake. - 100% of new AI/HAI data assets approved for AI pipeline use in the last 90 days have a completed REM on file, every applicable requirement marked Met / Met-with-compensating-control / Gap-accepted / Not-applicable, each Met row citing specific evidence, each Gap-accepted row naming a compensating control, owner, and re-review date. - ≥90% of active AI/HAI data assets in the SM inventory carry a current-year REM; accepted-gap backlog median age inside ≤90 days. - GDPR Art. 6 lawful basis, Art. 28 processor obligations, Art. 35 DPIA conditions, and EU AI Act Art. 10 training-data quality requirements are traceable to specific pack requirements in every applicable REM. - Named pack owner and quarterly refresh cadence operating; SA, DR, IR, ST practices citing REM rows rather than re-deriving requirements independently.

Level 2: - 100% of pack requirements carry a quantitative or binary evidence condition; all qualitative "reasonable" and "appropriate" language removed. - ≥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; validation deltas routed to IM-Data. - No Critical-tier accepted gap open beyond 60 days without documented escalation to the program sponsor; no High-tier gap beyond 90 days. - 100% of Critical-tier personal-data assets carry a completed and current DPIA, not a pending item or a pre-AI legacy DPIA that did not account for the AI use case.

Level 3: - Machine-readable Requirements Pack and REM schema published under permissive license with tracked adoption; ≥80% of Critical-tier requirements have pipeline attestation at deploy time. - ≥70% of REM evidence rows auto-validated via pipeline signals, runtime monitoring, and admin-console API; 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. - ≥2 substantive standards contributions per year to OpenSSF AI / OWASP LLM / DAMA / NIST AI RMF Playbook.

Common Pitfalls

Level 1: - ❌ The base pack is authored with 40+ requirements at L1, reviewers cannot complete a REM in ≤3 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. - ❌ Gap-accepted rows lack expiry dates and named owners, the backlog grows silently until an audit surfaces a Critical-tier gap that has been "accepted" for 18 months with no action. - ❌ 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. - ❌ Downstream practices (SA, DR, IR, ST) ignore the REM and re-derive requirements independently, the pack exists but provides zero actual reuse across the program. - ❌ 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 too loosely to be testable, "retention enforced for an appropriate period" becomes "12 months" on paper but is never confirmed against actual storage retention settings; the SLA exists but is never verified. - ❌ 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; evidence integrity is unverified. - ❌ 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. - ❌ SR-Software cross-references to SR-Data REMs are documented as a requirement but no process links the two, Software-domain reviewers do not know which data-asset REM to reference; the cross-domain traceability gap remains. - ❌ 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 org 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 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 (≤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? 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 / 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? 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?

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 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? 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? 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?

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? 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? 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?

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Data Last Updated: 2026-05-13 Author: Verifhai