# 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)

| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| Base + archetype requirements packs published | 0 / 8 documents | 8 / 8 (base + 7 archetype deltas) | Requirements registry |
| % new AI/HAI data asset approvals with a completed REM | measure | 100% | SM intake ticket + REM artifact |
| % active AI/HAI data assets in inventory with a current-year REM | measure | ≥90% | Inventory × REM artifacts |
| % of pack requirements tagged to a TA-Data archetype threat and a PC-Data priority-compliance item | measure | 100% | Pack metadata |
| Accepted-gap aging (median age of open accepted-gap rows) | measure | ≤90 days | REM backlog |

#### 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)

| Metric | Baseline | L2 Target | Source |
|---|---|---|---|
| % requirements with quantitative or binary evidence condition | measure | 100% | Requirements pack |
| % Critical-tier REMs re-validated against observed reality in last 90 days | measure | ≥95% | REM validation log |
| Accepted-gap aging, median age of Critical-tier open gaps | measure | ≤60 days | Gap register |
| % Critical-tier personal-data assets with a completed and current DPIA | measure | 100% | Compliance view |
| % SR-Software REMs cross-referencing the relevant SR-Data REM | measure | ≥90% for Critical/High Software artifacts | Cross-domain traceability log |

#### 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)

| Metric | Baseline | L3 Target | Source |
|---|---|---|---|
| % Critical-tier REM requirements with automated pipeline attestation at deploy time | measure | ≥80% | Pipeline attestation log |
| % REM evidence rows auto-validated (vs. manual-only) | measure | ≥70% | Validation telemetry |
| Pipeline deploy blocks triggered by failed Critical-tier REM check | measure | tracked; zero silent failures | Pipeline telemetry |
| Pack adoption (forks, citations, downloads of published artifact) | 0 | tracked, trending up | External telemetry |
| Industry-standard contributions per year | 0 | ≥2 | Contribution log |

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