> **v3.0 framing:** The canonical source-of-truth for Security Requirements (SR) in the Data domain is [`../practices/SR-Data-OnePager.md`](../practices/SR-Data-OnePager.md). Outcome metrics in this questionnaire are reproduced verbatim from that one-pager. Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md) §8.

---

# Security Requirements (SR) - Data Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Security Requirements (SR)
**Domain:** Data
**Purpose:** Assess organizational maturity in authoring and maintaining the AI/HAI Data Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every data asset that enters or is active in an AI pipeline.
**Scoring Model:** Evidence + Outcome Metrics (see Scoring Methodology below)

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you did) and **Outcome Metrics** (how well it worked)
- **Scoring uses 4 tiers:** Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
- **Answer progressively**, Complete all Level 1 questions before Level 2
- **Level progression**, Achieve ALL questions at a lower level before advancing
- **Baseline first**, Record current metric values before setting targets

---

## Scoring Methodology

| Score | Label | Criteria |
|-------|-------|----------|
| 1.0 | Fully Mature | Evidence complete AND ≥3 outcome metrics meet targets |
| 0.67 | Implemented | Evidence complete AND 2 outcome metrics meet targets |
| 0.33 | Partial | Evidence partially complete AND <2 metrics meet targets |
| 0.0 | Not Implemented | No evidence present |

---

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

---

### Question 1: Author the base AI/HAI Data Requirements Pack

**Q1.1:** Does a published, versioned AI/HAI Data Requirements Pack exist containing a base set (target ≤20 requirements) covering classification/consent-basis/lineage/retention/cross-border flows/encryption/access control/no-train assertions/DSAR, with every requirement tagged to at least one TA-Data archetype threat and one PC-Data priority-compliance item?

**Evidence Required:**
- [ ] Base requirements pack document published in the requirements registry with a version number and a named owner
- [ ] Pack covers minimum base categories: classification and labeling, consent and lawful basis, lineage and provenance, retention, cross-border flows (GDPR Arts. 44–49), encryption, access control, no-train assertions, and Data Subject Access Rights (DSAR)
- [ ] Each requirement row carries: ID, statement, rationale (threat tag + compliance tag), evidence source, test method, and acceptance criterion
- [ ] REM (Requirements-Evidence Map) template exists and is linked from the SM intake checklist; template includes Met / Met-with-compensating-control / Gap-accepted / Not-applicable columns with evidence citation, gap owner, gap expiry, and compensating-control description
- [ ] Accepted-gaps register exists with named owner and expiry date per row
- [ ] Pack-version control record shows version, change date, and change summary for each revision
- [ ] Traceability matrix links each base requirement to at least one GDPR article (Arts. 6, 9, 17, 22, 28, 35, 44–49) or EU AI Act Art. 10 training-data quality requirement

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Base + archetype requirements packs published | 0 / 8 documents | ___/8 | 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 | ___ days | ≤90 days | ☐ | REM backlog |

**Metric Collection Guidance:**
- **Packs published:** Count published documents in the requirements registry: 1 base + 7 archetype deltas (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set). Source: requirements registry index.
- **% new approvals with REM:** Query SM intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: `REMs on file / total new data-asset approvals × 100`.
- **% active assets with current-year REM:** Cross-reference SM inventory against REM artifact store; flag assets with no REM dated in the current calendar year. Formula: `assets with current-year REM / total active assets × 100`.
- **% requirements tagged:** Inspect pack metadata fields; count requirements with both a TA threat tag and a PC compliance tag. Formula: `tagged requirements / total requirements × 100`.
- **Accepted-gap aging:** Query the accepted-gaps register; compute median calendar days from gap-open date to today for all currently open rows.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No evidence of a published data requirements pack)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 2: Author per-archetype requirement deltas

**Q2.1:** Have per-archetype requirement deltas been authored and published for all seven data archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), and are the correct deltas automatically applied at intake?

**Evidence Required:**
- [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Data archetype threats
- [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., DPIA-gated curation for fine-tuning datasets, per-tenant retrieval isolation for retrieval stores, PII redaction at logging for prompt/completion log corpus)
- [ ] Intake process routes each data asset to base pack + applicable archetype delta(s); routing logic is documented and tested with at least one intake example per archetype
- [ ] REM template enforces that archetype-specific delta rows are present and populated for the declared archetype
- [ ] Pack-version control record reflects delta amendments and cross-references the TA-Data archetype threat that drove each change
- [ ] Traceability matrix links delta requirements back to TA-Data archetype threat models and PC-Data priority compliance map (GDPR Art. 35 DPIA triggers, EU AI Act Art. 10 training data requirements)
- [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Base + archetype requirements packs published | 0 / 8 documents | ___/8 | 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 | ___ days | ≤90 days | ☐ | REM backlog |

**Metric Collection Guidance:**
- **Packs published:** Same as Q1, verify all seven archetype-delta documents are present in the registry with current version numbers.
- **% new approvals with REM:** Same as Q1, verify REM rows for the asset's archetype delta are populated, not only base pack rows.
- **% active assets with current-year REM:** Same as Q1, confirm archetype delta rows are present in each REM.
- **% requirements tagged:** Confirm all delta requirements carry both a TA threat tag and a PC compliance tag; flag untagged rows.
- **Accepted-gap aging:** Include archetype-delta gap rows in the aging calculation.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No archetype deltas published or applied at intake)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 3: Wire the pack into the SM intake gate and produce a REM per asset

**Q3.1:** Is the requirements pack wired into the SM intake gate so that every AI/HAI data asset approved for use in an AI pipeline carries a completed REM, with Met rows citing specific evidence (consent record, DPA clause, DPIA reference, lineage record), Gap-accepted rows naming an owner and expiry date, and material-change triggers defined?

**Evidence Required:**
- [ ] SM intake checklist includes a gate step requiring a completed REM before the data asset is approved for pipeline use
- [ ] At least three production REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations (not narrative assertions)
- [ ] Each Met row in the sample REMs cites a specific artifact: classification label in the data catalog, consent-basis record, lineage record, DPA clause citation, admin-console screenshot, DPIA reference, or audit-log sample
- [ ] Each Gap-accepted row carries: compensating control description (or "none"), named owner, re-review date (≤90 days from open date at L1), and residual-risk rationale
- [ ] REM-population status per asset is tracked and visible to the pack owner
- [ ] Material-change trigger list is documented (new data source added, classification change, new cross-border flow, new downstream AI use) and included in the intake checklist
- [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Base + archetype requirements packs published | 0 / 8 documents | ___/8 | 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 | ___ days | ≤90 days | ☐ | REM backlog |

**Metric Collection Guidance:**
- **Packs published:** Confirm 8/8 documents in the registry with current version numbers.
- **% new approvals with REM:** Pull SM intake ticket list for last 90 days; confirm each pipeline approval was preceded by a linked REM artifact.
- **% active assets with current-year REM:** Run inventory × REM cross-reference; compute completion ratio.
- **Evidence quality check:** Spot-check 10 REM rows across 3 assets; confirm each Met row cites a specific evidence artifact, not a narrative.
- **Accepted-gap aging:** Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No intake gate or REMs on file)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

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

---

### Question 4: Quantitative and binary requirement pack

**Q4.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?

**Evidence Required:**
- [ ] Requirements pack shows no qualitative language in any requirement statement; all language is measurable or binary
- [ ] Encryption at rest requirement is binary: classification-tier-appropriate encryption confirmed; key rotation ≤365 days for Critical-tier; last rotation date on file with zero overdue keys
- [ ] No-train assertion requirement is binary: vendor admin-console setting confirmed OFF + screenshot on file + quarterly re-verification cadence documented; last re-verification result on file
- [ ] DSAR deletion capability requirement specifies SLA: deletion requests fulfilled within 30 calendar days (standard) / 60 days (complex training-corpus cases); last DSAR test result on file; zero requests past statutory deadline in last 12 months
- [ ] Cross-border transfer mechanism requirement is binary: SCC / adequacy / BCR documented for each cross-border personal-data flow; mechanism currency re-confirmed within last 12 months; zero flows without a documented mechanism
- [ ] REM template updated to reflect quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate
- [ ] Pack-version control log shows the quantitative update was a tracked amendment with a version bump

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 | ___ days | ≤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 |

**Metric Collection Guidance:**
- **% requirements quantitative/binary:** Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Manual review or structured-schema parse of the pack document.
- **% Critical-tier REMs re-validated:** Count Critical-tier assets whose REM validation log shows a re-validation run (not self-attestation alone) in the last 90 days. Formula: `re-validated Critical-tier assets / total Critical-tier assets × 100`.
- **Accepted-gap aging (Critical):** Filter gap register to Critical-tier rows; compute median calendar days open.
- **% Critical-tier personal-data assets with current DPIA:** Count Critical-tier personal-data assets with a DPIA completed and reviewed within the last 12 months or since last material change. Formula: `assets with current DPIA / total Critical-tier personal-data assets × 100`.
- **% SR-Software REMs cross-referencing SR-Data REM:** Query the SR-Software REM store for Critical/High-tier Software artifacts; count those that include a reference to the corresponding SR-Data REM. Formula: `cross-referencing Software REMs / total Critical/High Software artifacts × 100`.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (Requirements still contain qualitative language)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 5: Per-tier requirement depth

**Q5.1:** Has a per-tier pack overlay been published and enforced at SM intake, with Critical-tier personal-data assets requiring a DPIA plus executive sign-off, a 60-day accepted-gap SLA, and SR-Software cross-referencing, and Low-tier assets receiving base pack only?

**Evidence Required:**
- [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices with distinct requirement depth and gap-aging SLAs
- [ ] Critical-tier overlay includes: full base pack + all applicable archetype deltas; DPIA mandatory (binary gate); DPO or Privacy Officer sign-off on the completed REM before pipeline approval; EU AI Act Art. 10 data-quality checklist; 60-day accepted-gap aging SLA; quarterly REM re-validation; SR-Software cross-reference required for every Software-domain artifact that consumes the asset
- [ ] SM intake routing logic enforces tier-appropriate depth; intake ticket records tier assignment and pack overlay version applied
- [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged before the 60-day escalation threshold, with pre-deadline notification to the named owner
- [ ] REM-population status per asset is visible by tier, with Critical-tier completion tracked separately
- [ ] Cross-domain linkage process is documented: SR-Software REMs for Critical/High Software artifacts reference the SR-Data REM for every data asset they consume; a change in data-asset classification triggers a flag on the consuming Software artifact's REM
- [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 | ___ days | ≤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 |

**Metric Collection Guidance:**
- **% requirements quantitative/binary:** Confirm no regressions, all requirements remain quantitative/binary after the tier overlay was applied.
- **% Critical-tier REMs re-validated:** Verify the re-validation cadence is operating, not just scheduled; confirm observable-reality checks are used.
- **Accepted-gap aging (Critical):** Confirm no Critical-tier gap has exceeded 60 days without a documented escalation record.
- **% Critical-tier personal-data assets with current DPIA:** Verify each Critical-tier personal-data asset has a DPIA completed by a qualified reviewer (DPO or privacy engineer); check DPO sign-off record is on file.
- **% SR-Software REMs cross-referencing SR-Data REM:** Pull last 30 days of SR-Software REM completions; confirm cross-reference field is populated for Critical/High Software artifacts.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No per-tier overlay or tier-based intake routing)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 6: Continuous REM-evidence validation and cross-domain linkage

**Q6.1:** Are Critical-tier REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation deltas routed to IM-Data as findings, no Critical-tier accepted gap aging beyond 60 days without documented escalation, and SR-Software cross-reference operating for Critical/High Software artifacts?

**Evidence Required:**
- [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier asset in the last 90 days, using observable reality checks (data-catalog, admin-console, audit log, IR findings, ML monitoring)
- [ ] Validation method documented: stratified sample of at least one row per base category (classification, consent/lawful basis, lineage, retention, cross-border flows, encryption, access control, no-train assertions, DSAR) per asset
- [ ] Validation deltas (row claimed Met but evidence fails re-validation) are routed to IM-Data as findings with severity tags and remediation SLAs matching the asset's tier
- [ ] Accepted-gaps register shows no Critical-tier gap past 60 days without a documented escalation record naming the program sponsor
- [ ] Cross-domain linkage health is monitored: no Critical-tier data asset actively consumed by a Software artifact whose SR-Software REM lacks the SR-Data cross-reference
- [ ] REM-population status per asset reflects the last validation date and outcome for each Critical/High-tier asset
- [ ] GDPR supervisory authority guidance updates and adequacy-decision status changes trigger auto-flagging of cross-border-flow REM rows within 5 business days

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 | ___ days | ≤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 |

**Metric Collection Guidance:**
- **% Critical-tier REMs re-validated:** Pull REM validation log; count Critical-tier assets with a validation run recorded in the last 90 days using observable-reality checks (not self-report). Formula: `validated Critical-tier assets / total Critical-tier assets × 100`.
- **Accepted-gap aging (Critical):** Confirm the 60-day SLA is enforced; spot-check any gap older than 60 days for an escalation record; zero exceptions without documented escalation.
- **Validation delta routing:** Confirm IM-Data backlog contains findings originating from REM validation deltas in the last 90 days.
- **DPIA currency:** Confirm all Critical-tier personal-data DPIAs have been reviewed within the last 12 months or since last material change.
- **SR-Software cross-reference health:** Confirm no Critical-tier data asset consumed by a Software artifact has a missing SR-Data cross-reference in the consuming Software artifact's REM.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No REM validation log or continuous re-validation in place)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

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

---

### Question 7: Machine-readable pack and pipeline attestation

**Q7.1:** Is the AI/HAI Data Requirements Pack expressed in a machine-readable schema (JSON or YAML), and do Critical-tier data asset pipeline deploys fail the gate when a REM requirement check fails?

**Evidence Required:**
- [ ] Machine-readable requirements pack published (JSON or YAML schema); each requirement has: ID, machine-readable evidence type (data-catalog-query / config-check / audit-log-query / test-result-reference / manual-attestation), acceptance predicate, and tier applicability field
- [ ] Pipeline deploy gate for Critical-tier assets includes automated REM checks: classification label confirmed in data catalog; encryption-at-rest confirmed; no-train setting confirmed via vendor admin-console API; access control RBAC confirmed; retention policy confirmed active; cross-border flow mechanism confirmed current
- [ ] Failed REM check blocks the pipeline deploy for Critical-tier assets; evidence of at least one blocked deploy or a test of the block is on file
- [ ] Passed REM checks write a signed attestation to the REM record; attestation log is queryable
- [ ] REM-population status per asset is updated automatically from pipeline attestation results for automated evidence types
- [ ] Pack published under a permissive license with external adoption tracking (forks, citations, downloads logged)
- [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 |

**Metric Collection Guidance:**
- **% Critical-tier requirements with pipeline attestation:** Count Critical-tier REM requirement rows with an automated pipeline check vs. total Critical-tier requirement rows. Formula: `automated Critical-tier rows / total Critical-tier rows × 100`.
- **% REM rows auto-validated:** Count all REM rows where the last validation was performed by an automated check vs. total rows. Formula: `auto-validated rows / total rows × 100`.
- **Pipeline deploy blocks:** Count blocked pipeline deploys in the last 90 days where the block was triggered by a failed Critical-tier REM check; confirm zero silent failures.
- **Pack adoption:** Query external telemetry for the published pack artifact; confirm an upward trend.
- **Industry-standard contributions:** Count substantive contributions to OpenSSF AI / OWASP LLM / DAMA / NIST AI RMF Playbook in the last 12 months.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No machine-readable pack or pipeline attestation gate)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 8: Automated REM-evidence validation from runtime signals

**Q8.1:** Are ≥70% of REM evidence rows auto-validated via pipeline signals, runtime monitoring (ML-Data), admin-console API ingestion, and adequacy-decision status feeds, with automation error-rate monitored and human review reserved for DPIA sign-off, DSAR complex cases, and accepted-gap escalations?

**Evidence Required:**
- [ ] REM validation pipeline is subscribed to ML-Data monitoring outputs (access-audit log completeness signal, no-train re-verification output, retention-enforcement run results) and routes failures to the correct REM rows
- [ ] IM-Data incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag the relevant REM rows for re-validation
- [ ] SM inventory change events (tier upgrade) auto-trigger 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 within a defined SLA
- [ ] Automation error-rate (false-positive and false-negative failures) is monitored; a defined threshold triggers human review of the affected check
- [ ] Human review queue is bounded: DPIA sign-off, DSAR complex cases, and accepted-gap escalations remain for manual handling; all other evidence types are auto-validated
- [ ] REM-population status per asset reflects auto-validated rows separately from manual-attestation rows; staleness of each auto-validated row is tracked

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 |

**Metric Collection Guidance:**
- **% auto-validated rows:** Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active REM rows. Confirm the 70% target is met across both Critical and High-tier assets.
- **Automation error-rate:** Query the pipeline's false-positive log and false-negative log; threshold for human review should be documented.
- **Human review queue:** Confirm the queue contains only DPIA sign-off, DSAR complex cases, and accepted-gap escalations; no other row types should be pending manual review for more than the defined SLA.
- **Pipeline gate:** Confirm the pipeline is still enforcing the gate from Q7; zero silent failures.
- **Adequacy-decision feed:** Verify the pipeline received at least one adequacy-decision status signal in the last 90 days (or confirm no changes occurred and the check was made).

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No automated REM-evidence validation from runtime signals)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 9: Standards contribution

**Q9.1:** Has the program contributed at least two substantive artifacts per year to recognized standards bodies, with contributions publicly documented and traceable to adoption in OpenSSF AI, OWASP LLM, DAMA / EDM Council, or NIST AI RMF Playbook?

**Evidence Required:**
- [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name, contribution type, submission date, and a link or reference to the external artifact
- [ ] Contributions are legally vetted (internal legal review record on file) and anonymized or attributed per the org's disclosure policy
- [ ] At least one contribution is a machine-readable artifact (data-archetype REM schema, JSON schema for data requirements, or equivalent) rather than commentary only
- [ ] External adoption is tracked: at least one contribution has a confirmed path to adoption (working group vote, draft inclusion, or citation in a published document)
- [ ] Pack and REM schema published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter
- [ ] DAMA / EDM Council AI Data Governance working group engagement is documented if applicable to the org's sector
- [ ] Contribution pipeline has ≥2 contributions in-flight at any given time

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % 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 |

**Metric Collection Guidance:**
- **Industry-standard contributions:** Count contributions in the last 12 months in the contribution log; confirm each has a body name, submission date, and external reference link. Minimum 2 to meet target.
- **Pack adoption:** Confirm external telemetry shows an upward trend in forks, citations, or downloads; a flat or declining trend is a gap signal.
- **Contribution pipeline health:** Confirm ≥2 contributions are actively in-flight.
- **Version alignment:** Confirm the public pack version tag matches the current internal version tag.
- **L3 automation goals:** Confirm the pipeline attestation and auto-validation goals from Q7 and Q8 remain met.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No standards contributions or external publication)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Summary Scorecard

| Question | Activity | Score | Notes |
|----------|----------|-------|-------|
| Q1 | L1-A: Base data requirements pack | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q2 | L1-B: Per-archetype deltas | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q3 | L1-C: SM intake gate + REM per asset | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q4 | L2-A: Quantitative and binary pack | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q5 | L2-B: Per-tier requirement depth | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q6 | L2-C: Continuous REM-evidence validation + cross-domain linkage | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q7 | L3-A: Machine-readable pack + pipeline attestation | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q8 | L3-B: Automated REM-evidence from runtime signals | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| Q9 | L3-C: Standards contribution | ☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0 | |
| **Total** | | **___ / 9.0** | |

**Achieved Maturity Level:** ☐ Not Started / ☐ Level 1 / ☐ Level 2 / ☐ Level 3

---

**Document Version:** HAIAMM v3.0
**Practice:** Security Requirements (SR)
**Domain:** Data
**Questionnaire Authored:** 2026-05-15
**Author:** Verifhai