> **v3.0 questionnaire.** Source of truth: [`../practices/EH-Data-OnePager.md`](../practices/EH-Data-OnePager.md). Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md) §8.

---

# Environment Hardening (EH) - Data Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Environment Hardening (EH)
**Domain:** Data
**Purpose:** Assess organizational maturity in hardening the storage, pipeline, access, cross-border, and egress envelopes for AI/HAI data assets across all seven archetypes

---

## 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 lower level before advancing
- **Baseline first** - Record current metric values before setting targets

---

## Scoring Methodology

Each question is scored on a 4-tier scale:

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

**Level Score** = Average of question scores within the level
**Overall Score** = Weighted average across levels (L1: 50%, L2: 30%, L3: 20%)

---

## Maturity Level 1

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

---

### Question 1: Storage and Pipeline Envelope Hardening

**Q1.1:** Are all seven AI/HAI data archetypes encrypted at rest with classification-tier-appropriate key management, do training corpora and fine-tuning datasets carry signed SLSA-style provenance attestations at promotion, and are pipeline connections using TLS 1.2 minimum with mTLS across trust boundaries?

**Evidence Required:**
- [ ] Encryption-at-rest configuration records for all seven archetypes (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), AES-256 or equivalent; Confidential+ assets using dedicated KMS or HSM-rooted key
- [ ] Key-separation configuration for multi-tenant storage backends, per-tenant key or separate partition with access-control boundary for Confidential+ assets
- [ ] Signed SLSA-style provenance attestation records for training corpora and fine-tuning datasets at pipeline promotion, source, classification, consent basis, lineage, processing job identity
- [ ] Data pipeline gate configuration blocking promotion of unsigned datasets
- [ ] mTLS configuration for pipeline connections crossing trust boundaries; TLS 1.2 minimum for all pipeline connections
- [ ] Deny-list check configuration at ingestion (ATLAS advisories, AVID, internal ST-Data findings) for training and fine-tuning datasets

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI data assets in production with a classification label and a named owner | ___% | ___% | 100% | ☐ | |
| % training corpora and fine-tuning datasets with signed provenance attestations at promotion | ___% | ___% | 100% | ☐ | |
| % data-pipeline service accounts using dedicated named vault-managed credentials (CI secrets-scan with zero hardcoded-credential findings) | ___% | ___% | 100% | ☐ | |
| Plaintext pipeline connections across trust boundaries (missing mTLS) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **Classification label coverage**: Audit SM-Data inventory records; count assets with classification label and named owner populated. Source: SM-Data inventory audit
- **Provenance attestation coverage**: Query data pipeline gate telemetry for promotion events; count those with a valid signed attestation. Formula: `attested_promotions / total_promotions × 100`. Source: data-pipeline gate telemetry
- **Named credentials coverage**: Run CI secrets-scan across data pipeline code repos; count pipeline service accounts using dedicated vault-managed credentials. Source: secrets vault audit × CI scan telemetry
- **Plaintext connection count**: Audit pipeline network configurations for connections missing TLS across trust boundaries. Source: network configuration review

**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 storage/pipeline hardening)

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

---

### Question 2: Access Envelope Hardening

**Q1.2:** Do all data-facing consoles (data catalog, model registry, prompt-log store, vector store, embedding store) require SSO + MFA with an append-only audit log on every access event, and is just-in-time access enforced for human interactive access to Confidential+ datasets?

**Evidence Required:**
- [ ] IdP configuration records showing SSO/SAML/OIDC enforcement on data catalog, model registry, prompt-log store console, vector store console, and embedding store console, local-account access disabled for org-domain identities
- [ ] MFA enforcement policy records for all data-facing consoles
- [ ] RBAC configuration showing classification-aware authorization, roles scoped to asset classification tier, not granting cross-tier read access
- [ ] Append-only audit log configuration for every read, write, export, and delete event on AI/HAI data assets, access-control separation between pipeline operators and log administrators
- [ ] JIT access configuration for Confidential+ training corpora, fine-tuning datasets, and evaluation/test sets, scoped to specific dataset path, time-limited (≤8h), approval-gated; no standing interactive access
- [ ] CI secrets-scanning configuration for data-pipeline credentials as a blocking PR check on every PR touching data pipeline code

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI data-facing consoles requiring SSO + MFA | ___% | ___% | 100% | ☐ | |
| % Confidential+ AI/HAI data assets with JIT access enforced (no standing interactive credentials) | ___% | ___% | 100% | ☐ | |
| Audit log completeness, % production data asset stores with append-only audit logs actively writing | ___% | ___% | 100% | ☐ | |
| Access-audit-log gaps detected per week (target zero) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **SSO + MFA coverage**: Audit IdP configuration for each data-facing console entry; verify SSO is the only auth path and MFA is enforced. Source: IdP configuration audit
- **JIT access coverage**: Query IAM audit log for interactive access events on Confidential+ datasets; verify all use time-limited JIT grants with no standing permissions. Source: IAM audit telemetry
- **Audit log completeness**: Run weekly confirmation job that audit logs are writing for all production data asset stores. Source: audit-log completeness check
- **Log gap count**: Count gaps detected by the weekly audit log completeness check per week. Source: monitoring telemetry

**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 access envelope hardening)

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

---

### Question 3: Cross-Border and Egress Envelope Hardening

**Q1.3:** Are cross-border flows for regulated data assets documented with a transfer mechanism (SCC/adequacy/BCR) on file before replication activates, and are DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports, inference-input-stream exports) deployed and active?

**Evidence Required:**
- [ ] Transfer-mechanism registry records for every cross-border flow involving regulated AI/HAI data assets, SCC, adequacy decision, or BCR documented before cross-region replication activates
- [ ] Data-pipeline gate configuration blocking cross-border flows for regulated assets without a documented transfer mechanism on file
- [ ] Cross-region replication audit records for all seven archetypes reconciled against the transfer-mechanism registry
- [ ] DLP rule configuration covering AI-specific egress patterns: bulk-embedding exports (large float-array files, batch embedding API exports to external destinations), prompt/completion-log bulk exports (CSV/JSON), training-dataset exports (bulk archive exports), inference-input-stream bulk exports
- [ ] Classification-aware egress policy, regulated data cannot leave approved storage boundary without an explicit approval gate; shadow-AI data-flow alert for data-pipeline service account bulk exports to undeclared destinations
- [ ] Region-pinning enforcement records for AI/HAI data assets subject to data-residency requirements

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-border flows for regulated data assets with a documented transfer mechanism on file | ___% | ___% | 100% | ☐ | |
| DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and active | 0 / set | target set | target set defined + deployed | ☐ | |
| % AI/HAI data assets subject to residency requirements with region-pinning enforcement active | ___% | ___% | 100% | ☐ | |
| Egress-block events on AI-specific DLP rules per quarter (trend measured) | ___ | ___ | tracked; blocks documented | ☐ | |

**Metric Collection Guidance:**
- **Transfer-mechanism coverage**: Audit transfer-mechanism registry against cross-region replication configurations for all seven archetypes. Source: transfer-mechanism registry × replication config
- **DLP rule deployment**: Confirm AI-specific egress rules are active in DLP management console for each archetype exfiltration surface. Source: DLP management console
- **Residency enforcement coverage**: Audit storage-layer policies for residency-controlled assets. Source: storage policy audit
- **DLP block events**: Count DLP block events attributed to AI-specific egress rules per quarter. Source: DLP alert telemetry

**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 cross-border gating or AI-specific egress DLP)

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

---

## Maturity Level 2

**Objective:** Calibrate hardening depth per risk tier using the SM-Data L2 tier-treatment matrix; apply HSM-rooted per-tenant key management and enhanced content-inspection DLP for Critical-tier data assets; enforce tier-conditional access controls and storage-layer residency enforcement.

---

### Question 4: HSM-Rooted Key Management and Zero-Trust Data Access for Critical-Tier

**Q2.1:** Are 100% of Critical-tier AI/HAI data assets under HSM-rooted key management with per-tenant key separation at the storage layer and key rotation ≤30 days, and is zero-trust JIT access (≤4-hour time-limited, approval-gated) enforced for all interactive access to Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets?

**Evidence Required:**
- [ ] HSM configuration records for Critical-tier data assets (AWS CloudHSM, GCP Cloud HSM, Azure Dedicated HSM, or on-premise HSM), key material generated and stored in HSM, not software-only KMS; keys non-exportable
- [ ] Per-tenant key separation configuration at the HSM level for Critical-tier shared storage backends, separate key per tenant
- [ ] Key rotation policy records, Critical-tier ≤30 days; automated rotation confirmed active with rotation completion logs
- [ ] JIT access tooling configuration for Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets, scoped to specific dataset path, time-limited ≤4h, approval-gated, automatic revocation at expiry
- [ ] Approval gate audit log records (requestor, purpose, approver, grant time, expiry) written to audit log at grant time; session activity logged at storage layer during JIT window
- [ ] Ephemeral credential configuration for Critical-tier data pipelines, token lifetime ≤1h; token revocation on pipeline completion logged

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data assets with HSM-rooted key management | ___% | ___% | 100% | ☐ | |
| % Critical-tier data assets with zero-trust JIT access (no standing interactive credentials) | ___% | ___% | 100% | ☐ | |
| Critical-tier key rotation cadence, % rotated within 30-day SLA | ___% | ___% | 100% | ☐ | |
| JIT access grants exceeding 4-hour time limit (target zero) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **HSM coverage**: Audit KMS/HSM configuration for each Critical-tier data asset; verify key material root is HSM-backed, not software KMS. Source: KMS/HSM audit
- **JIT access coverage**: Query IAM audit log for interactive access events on Critical-tier datasets; verify all use JIT grants with no standing permissions. Source: IAM audit telemetry
- **Key rotation SLA**: Review key rotation logs for Critical-tier assets; count keys rotated within the 30-day window. Source: KMS rotation telemetry
- **JIT time-limit violations**: Count JIT access grants with session duration exceeding 4h. Source: IAM audit telemetry

**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 HSM-rooted key management or zero-trust data access)

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

---

### Question 5: Content-Inspection DLP and Tier-Hardening Matrix Enforcement

**Q2.2:** Are ≥90% of Critical-tier data asset egress paths subject to content-inspection DLP, with archetype-specific custom DLP patterns deployed for each of the seven data archetypes, and is a tier-hardening matrix published and enforced at provisioning with gaps tracked as open IM-Data findings?

**Evidence Required:**
- [ ] Content-inspection DLP configuration for Critical-tier egress paths: prompt/completion-log export inspection (PII pattern check before export), training-dataset export inspection (regulated-data class detection before export), embedding export inspection (size-threshold block without explicit approval)
- [ ] Archetype-specific custom DLP patterns: training corpus/fine-tuning dataset archive metadata headers, inference input stream batch exports (JSON/CSV format), retrieval/embedding store bulk vector-file exports (`.npy`, `.parquet`, `.bin`), prompt/completion log corpus structured log exports, evaluation/test set labeled-dataset format exports
- [ ] Published tier-treatment matrix covering encryption keys, storage backend, pipeline access, console access, audit log retention, DLP depth, cross-border gating, backup/deletion per tier (Critical/High/Medium/Low)
- [ ] Provisioning-gate configuration enforcing tier hardening controls at asset registration, not post-hoc after DR/IR finding
- [ ] SM-Data inventory records showing hardening status per tier for each data asset
- [ ] IM-Data findings records for tier-hardening gaps with tier-appropriate SLA tracking

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data asset egress paths with content-inspection DLP active | ___% | ___% | ≥90% | ☐ | |
| False-positive rate on AI-specific DLP/egress signals for Critical-tier assets (trend) | ___% | ___% | actively tuned; trending down | ☐ | |
| % SM-Data inventory records with hardening status per tier populated | ___% | ___% | 100% | ☐ | |
| Tier-hardening gaps tracked as open IM-Data findings (100% of gaps tracked) | ___% | ___% | 100% of gaps tracked | ☐ | |

**Metric Collection Guidance:**
- **Content-inspection DLP coverage**: Audit DLP configuration for Critical-tier egress paths; verify content inspection (not only pattern matching on filename or volume) is active. Source: DLP management console
- **False-positive rate trend**: Count DLP alerts tagged as false-positive per month for Critical-tier assets; compute rate and track trend over rolling 90 days. Source: alert telemetry
- **Inventory hardening status**: Review SM-Data inventory records; count assets with hardening-status field populated per tier. Source: SM-Data inventory
- **Gap tracking coverage**: Count tier-hardening gaps opened as IM-Data findings / total gaps identified in last tier-audit. Source: IM-Data backlog

**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 content-inspection DLP or tier-hardening matrix)

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

---

### Question 6: Storage-Layer Residency Enforcement and Cryptographic Deletion for Critical-Tier

**Q2.3:** Is storage-layer residency enforcement (region-locked storage policies, not application-layer only) active for 100% of Critical-tier and High-tier residency-controlled data assets, and is cryptographic deletion enforced at expiry for Critical-tier assets?

**Evidence Required:**
- [ ] Storage-layer residency enforcement configuration: region-locked S3 bucket policies, GCP Organization Policy constraints, or Azure policy locks on storage accounts for Critical-tier and High-tier residency-controlled assets
- [ ] Evidence that enforcement is at the storage layer, storage API access attempts that would cross a residency boundary are blocked at the storage layer, not only at the application layer
- [ ] Cryptographic deletion configuration for Critical-tier assets at expiry, key destruction before data deletion confirmed; deletion verification records retained
- [ ] Backup encryption configuration for Critical-tier assets, backups under a separate HSM-rooted key from the primary key
- [ ] Quarterly storage-policy audit records, any storage-layer policy change on residency-controlled assets triggers an IM-Data finding within 5 business days
- [ ] Per-tenant HSM-rooted key separation confirmed for Critical-tier multi-tenant storage backends (IR-Data or audit finding)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier and High-tier residency-controlled data assets with storage-layer residency enforcement (not application-layer only) | ___% | ___% | 100% | ☐ | |
| % Critical-tier assets with cryptographic deletion enforced at expiry | ___% | ___% | 100% for Critical-tier | ☐ | |
| Storage-layer residency policy changes triggering IM-Data finding within 5 business days | ___% | ___% | 100% | ☐ | |
| Critical-tier multi-tenant storage backends with per-tenant HSM-rooted key separation confirmed | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Storage-layer residency coverage**: Audit storage-layer policies (bucket policies, org policies, storage account locks) for all residency-controlled Critical and High-tier assets. Source: storage policy audit
- **Cryptographic deletion coverage**: Review lifecycle policy configurations for Critical-tier assets; verify key destruction precedes data deletion at expiry. Source: storage lifecycle configuration
- **Residency policy change detection**: Count storage-layer policy changes on residency-controlled assets routed to IM-Data within 5 business days / total such changes. Source: cloud audit log × IM-Data backlog
- **Per-tenant key separation**: Audit HSM/KMS key assignments for Critical-tier multi-tenant storage backends; count tenants with dedicated HSM-rooted keys. Source: KMS/HSM audit

**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 storage-layer residency enforcement)

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

---

## Maturity Level 3

**Objective:** Express all EH-Data controls as IaC modules; implement adaptive policy tightening driven by ML-Data detections and IM-Data incidents; and contribute AI/HAI data hardening baselines to OpenSSF AI, DAMA, EDM Council, and sector ISACs.

---

### Question 7: Hardening-as-Code, IaC Modules for All EH-Data Controls

**Q3.1:** Are all EH-Data controls expressed as version-controlled, authoritative IaC modules, covering storage, pipeline, access, cross-border, and egress envelopes, with drift detection running hourly and ≥70% of low-risk drift auto-remediated?

**Evidence Required:**
- [ ] IaC registry records showing storage envelope module (encryption configuration, key-management policy attachment, compliance-tier selection, access-control policy, cross-region replication policy with transfer-mechanism gate, deletion lifecycle rules), deployed as authoritative source, not stubs
- [ ] Pipeline envelope IaC: pipeline service-account creation module (named service account, least-privilege IAM, mTLS configuration, secrets vault path provisioning, ephemeral-credential rotation schedule); CI/CD pipeline template additions for dataset provenance attestation enforcement and deny-list check
- [ ] Access envelope IaC: data-catalog and vector-store access-control module (SSO enforcement, JIT access configuration for Critical/High-tier, audit-log destination configuration, RBAC policy attachment)
- [ ] Cross-border module: residency enforcement (region-lock storage policy, transfer-mechanism registry reference, cross-region replication gating rule); alert rule for policy-change events on residency-controlled assets
- [ ] Egress module: DLP rule configuration module (AI-specific egress patterns, content-inspection policies for Critical-tier, archetype-specific custom patterns) as configuration-as-code for DLP/CASB platform
- [ ] Drift-detection pipeline running hourly; low-risk drift auto-remediated; high-risk drift (key management downgrade, access-control loosening, egress allowlist expansion for regulated assets) triggers human-review alert within 2 business days + IM-Data finding

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % EH-Data controls expressed as IaC (version-controlled, authoritative deployed source, not stubs) | ___% | ___% | ≥90% | ☐ | |
| IaC drift auto-remediation rate for low-risk findings | ___% | ___% | ≥70% | ☐ | |
| High-risk drift findings human-reviewed within 2 business days | ___% | ___% | 100% | ☐ | |
| New AI/HAI data assets auto-provisioned with tier-appropriate hardening within 24h of SM-Data registration | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **IaC coverage**: Count EH-Data controls with authoritative IaC (deployed state = IaC spec, not stub) / total EH-Data controls. Source: IaC registry
- **Auto-remediation rate**: Count low-risk drift findings auto-remediated / total low-risk drift findings per quarter. Source: remediation telemetry
- **High-risk drift review SLA**: Count high-risk findings with human review completed within 2 business days / total high-risk findings. Source: policy change log × IM-Data backlog
- **Auto-provisioning SLA**: Compare SM-Data registration timestamps against IaC provisioning completion timestamps; count within 24h / total. Source: inventory × IaC provisioning telemetry

**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 IaC for EH-Data controls)

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

---

### Question 8: Adaptive Policy Tightening from ML-Data and IM-Data Signals

**Q3.2:** Is an adaptive-policy pipeline operational, with ML-Data detections (retrieval extraction attempts, embedding inversion, cross-border violations, bulk egress anomalies) and IM-Data incident patterns generating human-approved tightening proposals on a tracked cadence, with every change traceable to a source signal?

**Evidence Required:**
- [ ] Adaptive-tightening pipeline configuration wiring ML-Data signals: retrieval extraction attempt (anomalous query volume) → egress-narrowing proposal; embedding inversion attempt → embedding-store access lockdown proposal; cross-border flow violation → residency-enforcement tightening proposal; bulk egress anomaly → egress-allowlist review + DLP sensitivity increase proposal
- [ ] Adaptive-tightening pipeline configuration wiring IM-Data post-incident review records (storage misconfiguration contributing to a finding) to hardening-baseline update proposals
- [ ] Human-approval gate configuration for all proposals before deploy
- [ ] Machine-readable change log records showing source signal (ML-Data detection trend ID or IM-Data incident ID), approval record, and downstream notification per tightening change
- [ ] Evidence that downstream data-engineering teams are notified within 24 hours of a tightening change affecting their asset's hardening profile
- [ ] Feedback loop to TA-Data threat library and SR-Data requirements pack for hardening changes reflecting new threat patterns

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Adaptive-policy changes per quarter traceable to ML-Data or IM-Data source signal | 0 | ___ | tracked; growing | ☐ | |
| % adaptive-policy proposals human-approved before deploy (no unapproved auto-deploy) | ___% | ___% | 100% | ☐ | |
| Downstream data-engineering teams notified within 24h of tightening change | ___% | ___% | 100% | ☐ | |
| Stale signal feeds (>7 days without processed ML-Data or IM-Data event) | ___ | ___ | 0 stale feeds | ☐ | |

**Metric Collection Guidance:**
- **Traceable changes**: Count policy changes in the change log with a valid source signal reference per quarter. Source: policy change log
- **Human-approval rate**: Count proposals deployed with an approval record / total proposals deployed. Source: policy change log
- **Notification SLA**: Count tightening changes with downstream team notification within 24h / total tightening changes. Source: notification log
- **Signal feed freshness**: Check last-processed timestamp for each ML-Data and IM-Data feed; flag feeds with >7 days since last processed event. Source: pipeline monitoring

**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 adaptive-policy pipeline for EH-Data)

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

---

### Question 9: Industry Hardening Baseline Contributions

**Q3.3:** Does the program contribute ≥2 AI/HAI data hardening baselines per year to industry bodies, OpenSSF AI, DAMA, EDM Council, or sector ISACs, with documented adoption and internal practice aligned with the published version?

**Evidence Required:**
- [ ] Contribution records showing ≥2 substantive submissions per year to OpenSSF AI, DAMA (DMBOK), EDM Council, or sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups)
- [ ] Evidence of adoption or citation of contributed baselines by the recipient body
- [ ] Maintenance records showing internal practice stays aligned with the published external version, not diverged
- [ ] Auto-provisioning trigger configuration for SM-Data registration events: IaC provisioning workflow fires within 24 hours
- [ ] Tier-change event handling configuration: Medium-to-Critical tier upgrade triggers hardening-profile upgrade in provisioning pipeline, not stale cached tier
- [ ] Quarterly adaptive-policy change log records traceable to ML-Data detections and IM-Data incident patterns

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | |
| New AI/HAI data assets auto-provisioned with tier-appropriate hardening within 24h of SM-Data registration | ___% | ___% | 100% | ☐ | |
| Contributed baselines maintained upstream (internal practice aligned with published version) | ☐ yes / ☐ no |, | yes | ☐ | |
| Adaptive-policy change log machine-readable with source signal reference field confirmed | ☐ yes / ☐ no |, | yes | ☐ | |

**Metric Collection Guidance:**
- **Contribution count**: Count published contributions with a named recipient body and a contribution artifact per calendar year. Source: contribution log
- **Auto-provisioning SLA**: Compare SM-Data registration timestamps against IaC provisioning completion timestamps; count within 24h / total. Source: inventory × IaC provisioning telemetry
- **Maintenance alignment**: Review most recent version of each contributed baseline; confirm it reflects current internal practice. Source: contribution log × practice review
- **Change log format**: Confirm policy change log is machine-readable (JSON/YAML) with source signal reference field populated on each entry. Source: policy change log audit

**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 industry contributions or auto-provisioning)

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

---

## Summary Scorecard

| Level | Question | Score (0.0 / 0.33 / 0.67 / 1.0) |
|-------|----------|----------------------------------|
| L1 | Q1: Storage and Pipeline Envelope | ___ |
| L1 | Q2: Access Envelope | ___ |
| L1 | Q3: Cross-Border and Egress Envelope | ___ |
| L2 | Q4: HSM-Rooted Key Management and Zero-Trust Data Access | ___ |
| L2 | Q5: Content-Inspection DLP and Tier-Hardening Matrix | ___ |
| L2 | Q6: Storage-Layer Residency Enforcement | ___ |
| L3 | Q7: Hardening-as-Code IaC Modules | ___ |
| L3 | Q8: Adaptive Policy Tightening | ___ |
| L3 | Q9: Industry Baseline Contributions | ___ |

**L1 Score** (avg Q1–Q3): ___
**L2 Score** (avg Q4–Q6): ___
**L3 Score** (avg Q7–Q9): ___
**Overall Score** (L1×0.5 + L2×0.3 + L3×0.2): ___

---

**Document Version:** HAIAMM v3.0
**Practice:** Environment Hardening (EH)
**Domain:** Data
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai