Environment Hardening (EH) - Data Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 questionnaire. Source of truth: ../practices/EH-Data-OnePager.md. Canonical subject and through-lines: ../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

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

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

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

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

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

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

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

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

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown