Environment Hardening (EH)

Data Domain - HAIAMM v3.0

Practice Overview

Objective: Harden the storage, pipeline, access, cross-border, and egress envelopes that surround the data flowing into and out of AI/HAI systems, training corpora, inference inputs, retrieval stores, prompt/completion logs, embeddings, fine-tuning datasets, and evaluation/test sets, so each data asset rests, moves, and leaves the boundary under controls that match its classification tier.

Description: EH-Data tunes the organization's existing storage, identity, network, and DLP controls for the specific surfaces that AI/HAI data assets create. Five envelope dimensions are in scope: (1) the storage envelope, encryption at rest with HSM-rooted keys, key separation per tenant where applicable, per-classification-tier storage backend, replication and backup policy aligned to retention, and deletion verification on expiry; (2) the pipeline envelope, encryption in transit (mTLS), pipeline service-account least-privilege, CI/CD secrets management for data-pipeline credentials, signed dataset artifacts, SLSA-style provenance for training datasets and embedding artifacts, and deny-listing of known-poisoned upstream datasets; (3) the access envelope, SSO + MFA on data catalogs, model registries, prompt-log stores, and vector stores; RBAC + classification-aware authorization; service-principal model for pipeline access; audit log on every access; just-in-time access for sensitive datasets; (4) the cross-border envelope, data-residency enforcement (region pinning), transfer-mechanism gates (SCC / adequacy / BCR), cross-region replication policy aligned to GDPR Arts. 44–49; (5) the egress envelope, DLP tuned for AI-specific exfiltration patterns: bulk-embedding exports, prompt/completion-log bulk exports, training-dataset exports, and model-weight exfiltration where data crosses the boundary without explicit approval for regulated content.

Context: AI/HAI data assets accumulate risks that classic data-governance controls were not designed to address. A training corpus containing withdrawn-consent subjects sits in an object-storage bucket with no retention enforcement. A retrieval store holds confidential documents ingested without classification labels, queryable by any service account with read access. Prompt/completion logs accumulate PII in clear-text because the logging pipeline was wired before Privacy reviewed it. Fine-tuning datasets cross a data-residency boundary during a cloud-migration that nobody mapped to GDPR Art. 44. Embedding files are exported in bulk to a contractor's environment without DLP triggering because the DLP rules match credit-card numbers, not high-dimensional float arrays. EH-Data closes these gaps not by adding new tooling but by tuning controls the organization already has, storage encryption policies, IAM, secrets vaults, DLP, egress allowlists, data catalogs, for the specific surfaces the seven AI/HAI data archetypes create.

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

At this level, existing platform and security controls are AI/HAI-data-aware. Training corpora and fine-tuning datasets carry signed provenance attestations. Retrieval stores and embedding stores require SSO + MFA for console access and named service accounts for pipeline access. Prompt/completion log stores enforce PII redaction before write. Egress from data pipelines is allowlisted. Cross-border flows for regulated data are gated. Every AI/HAI data asset in the SM-Data inventory has a classification label, a named owner, and a baseline hardening status.

Dependencies

• SM-Data L1 (required): the AI/HAI data inventory and archetype taxonomy identify which assets exist and which envelope dimensions apply to each; without the inventory, hardening scope is guesswork.
• PC-Data L1 (required): the AI Data-Handling Policy and priority compliance map define what to enforce at each envelope; GDPR, HIPAA, and sector-specific retention and cross-border obligations drive the cross-border and storage envelope requirements.
• SA-Data L1 (required): reference patterns define the "green path", data-catalog access model, mTLS pipeline configuration, egress allowlist, that hardening controls must enable for sanctioned data flows and detect deviations from for unsanctioned ones.
• Supports / unblocks: ML-Data L1 (the access and egress signals these controls emit feed monitoring), ST-Data L1 (tests exercise the hardening controls directly), IM-Data L1 (data incidents often originate at the control surfaces hardened here).

Desired Outcomes

• Every AI/HAI data asset in production has a classification label; no unclassified data asset is accessible by any pipeline service account.
• Training corpora and fine-tuning datasets carry signed SLSA-style provenance attestations; promotion without provenance is blocked.
• Retrieval stores, prompt/completion log stores, and embedding stores require SSO + MFA for console access; pipeline access runs under named, least-privilege service accounts; audit logs capture every access event.
• Prompt/completion log stores enforce PII redaction before write for all assets processing regulated data; Privacy/Legal sign-off documented where clear-text regulated data is retained.
• Egress from data pipeline service accounts is allowlisted to declared downstream systems; unexpected bulk exports trigger an alert.
• Cross-border flows for regulated data are documented; transfer mechanisms (SCC / adequacy / BCR) are on file before cross-region replication activates.

Activities

A) Harden the storage and pipeline envelopes

For every AI/HAI data asset registered in the SM-Data inventory, establish and enforce a minimum storage and pipeline hardening baseline:

• Encryption at rest: all seven archetypes, training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set, encrypted at rest using the platform's default AES-256 (or equivalent) backend; for assets classified Confidential or higher, key management must use a dedicated KMS or HSM-rooted key rather than a shared platform default.
• Key separation: where a storage backend serves multiple tenants (e.g., a shared vector store, a shared prompt-log store), each tenant's data is encrypted under a separate key or in a separate storage partition with access-control boundary enforcement; shared-key architectures for Confidential or higher classified assets are a blocking finding.
• Classification-tier storage backend: regulated data classes (PII, PHI, PCI) are stored in storage backends certified for the applicable compliance regime (e.g., HIPAA-eligible S3 configuration, PCI-DSS-compliant storage tier); mixed-tier storage (regulated and public data in the same bucket or table without access-control partitioning) is a blocking finding.
• Replication and backup policy: replication and backup policies are aligned to the asset's retention and regulatory requirements; backups of regulated data assets are encrypted under separate keys; backup access requires the same access-control model as the primary store.
• Deletion verification on expiry: for assets with a defined retention expiry (prompt/completion log corpus, inference input stream where applicable), deletion verification runs at the expiry date; cryptographic deletion (key destruction before data deletion is confirmed) is the target for Confidential+ assets; soft-delete with a 30-day hold is acceptable for Low-classification assets.
• Pipeline encryption in transit: all data-pipeline connections between data assets (ingestion, ETL, embedding generation, fine-tuning job, retrieval pipeline, evaluation harness) use TLS 1.2 minimum; mTLS is required for connections crossing trust boundaries (e.g., a training pipeline reading from a compliance-certified storage backend); plaintext pipeline connections are blocking findings.
• Signed dataset artifacts: training corpora and fine-tuning datasets promoted through the data pipeline carry a provenance attestation (source, classification, consent basis, lineage, processing job identity); any dataset promotion without a signed provenance attestation is blocked at the data-pipeline gate.
• Deny-list for known-poisoned upstream datasets: a deny-list of known-poisoned dataset sources (cross-referenced from ATLAS advisories, AVID, and internal ST-Data findings) is checked at ingestion for training corpora and fine-tuning datasets; ingestion of a deny-listed source is blocked.
• Pipeline service-account least-privilege: each data pipeline component runs under a named service account with access only to the specific asset paths it requires; no wildcard IAM policies; no shared credentials across pipeline stages.

B) Harden the access envelope

• SSO + MFA on data-facing consoles: data catalog, model registry, prompt-log store console, vector store console, embedding store console, and evaluation harness console all require SSO/SAML/OIDC; local-account access is disabled for org-domain identities; MFA always enforced.
• RBAC + classification-aware authorization: access to each AI/HAI data asset is governed by a role that maps to the asset's classification tier, a role that grants read access to Public-classification data does not grant read access to Confidential-classification data in the same catalog; classification-aware authorization is enforced at the data-catalog or storage-layer level, not only at the application layer.
• Service-principal model for pipeline access: data pipelines access AI/HAI data assets exclusively through named service principals; no pipeline uses interactive user credentials or shared static keys; service-principal credentials are stored in a secrets vault; rotation cadence ≤90 days for all pipeline credentials.
• Audit log on every access: every read, write, export, and delete event on AI/HAI data assets is logged to an append-only audit log; audit log access is separated from the data asset access role (a pipeline service account that writes to the training corpus cannot delete or modify the audit log for that corpus).
• Just-in-time access for sensitive datasets: for training corpora, fine-tuning datasets, and evaluation/test sets classified Confidential or higher, interactive human access is granted just-in-time (scoped, time-limited ≤8 hours, approval-gated) rather than via standing permissions; standing interactive access to sensitive dataset stores is a blocking finding.
• CI/CD secrets management for data-pipeline credentials: all data-pipeline credentials (storage access keys, database connection strings, embedding API keys, evaluation API keys) are managed in the secrets vault; plaintext credentials in pipeline scripts, configuration files, or CI/CD environment variables are blocking findings; CI secrets-scanning enforced on every PR touching data pipeline code.

C) Harden the cross-border and egress envelopes

• Data-residency enforcement (region pinning): for AI/HAI data assets classified as subject to data-residency requirements (PII, PHI, regulated financial data), storage and processing are pinned to the approved region; cross-region replication for residency-controlled assets requires an explicit transfer-mechanism gate (SCC / adequacy decision / BCR) documented before replication activates; unapproved cross-region replication is a blocking finding.
• Transfer-mechanism gates: for every cross-border flow involving regulated data assets (training corpus, inference input stream, prompt/completion log corpus), the applicable GDPR transfer mechanism (SCC, adequacy, BCR) is documented in the data-asset record; flows without a documented transfer mechanism are blocked at the pipeline gate until documentation is on file.
• Cross-region replication policy audit: existing cross-region replication configurations for all seven AI/HAI data archetypes are audited against the documented transfer-mechanism registry; any replication configuration without a matching transfer-mechanism record is flagged as an open IM-Data finding.
• DLP tuned for AI-specific egress patterns: the DLP system's egress rules are extended to cover patterns specific to AI/HAI data exfiltration, bulk-embedding exports (large float-array files or batch embedding API exports to external destinations), prompt/completion-log bulk exports (CSV/JSON bulk exports of logged prompt/completion pairs), training-dataset exports (bulk export of training data files to unmanaged storage), and inference-input-stream exports (bulk export of inference request payloads); DLP rules alert or block based on the classification of the data being exported.
• Classification-aware egress policy: regulated data (PII, PHI, PCI) cannot leave the approved storage boundary without an explicit approval gate; egress of regulated data to an unapproved destination is a blocking finding; a shadow-AI data-flow alert fires when a data-pipeline service account initiates a bulk export to a destination not in the declared data-flow map.

Outcome Metrics (L1)

Process Metrics (leading)

• CI secrets-scanning cadence, runs on every PR touching data-pipeline code; zero PRs merged without a passing secrets-scan check.
• Dataset provenance attestation review cadence, monthly check that all promoted training and fine-tuning datasets carry valid signatures; failures route to IM-Data.
• Access audit-log completeness check, weekly confirmation that audit logs are writing for all production data asset stores; gaps are immediate IM-Data findings.
• Cross-border replication audit cadence, quarterly; new replication configurations checked against transfer-mechanism registry within 5 business days of activation.

Effectiveness Metrics (business value)

• Unclassified-data-flow incidents trending down after classification-label enforcement activates, documented cases where unlabeled data flows were caught before reaching a higher-sensitivity context.
• Egress-block events on AI-specific DLP rules per quarter, trend measured; successful blocks documented.
• Frictionless sanctioned pipeline adoption, time-to-productive for data engineering teams using the vault-backed, least-privilege, mTLS-enforced pipeline stack does not regress as hardening tightens.

Success Criteria

• 100% of AI/HAI data assets in production have a classification label, a named owner, and a baseline hardening status in the SM-Data inventory.
• 100% of training corpora and fine-tuning datasets carry signed SLSA-style provenance attestations at promotion; promotion without provenance blocked by the pipeline gate.
• 100% of data-facing consoles require SSO + MFA; all pipeline service accounts use named, vault-managed credentials; CI secrets-scanning enforced with zero current hardcoded-credential findings.
• Cross-border replication for regulated data assets documented with transfer mechanisms; all existing replication configurations reconciled against the transfer-mechanism registry.
• DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and active.

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 DLP for Critical-tier data assets; and enforce tier-conditional access controls and residency enforcement across all seven archetypes

At this level, hardening is no longer one-size-fits-all. The SM-Data L2 tier-treatment matrix drives every hardening decision across the five envelope dimensions. Critical-tier data assets (training corpora containing regulated data, inference input streams processing PII at scale, prompt/completion log corpora with GDPR Art. 30 obligations) receive HSM-rooted per-tenant keys, dedicated storage backends, enhanced DLP with content inspection, just-in-time-only interactive access with approval gates ≤4 hours, and zero-trust data access. Low-tier assets remain on the L1 baseline. Every hardening decision is traceable to the asset's tier assignment in the SM-Data inventory.

Dependencies

• EH-Data L1 (required): baseline storage, pipeline, access, cross-border, and egress envelope controls are the substrate L2 differentiates.
• SM-Data L2 (required): the risk-tier rubric and tier-treatment matrix (Critical / High / Medium / Low) determine which hardening depth applies to each data asset; the tier is the primary input to every calibration decision.
• SA-Data L2 (required): tier-conditional reference patterns define the "green path" for hardened Critical and High-tier data architectures; EH-Data L2 enforces those patterns at the storage and identity layer.
• Supports / unblocks: ML-Data L2 (enhanced access controls and audit signals at Critical tier feed tier-calibrated monitoring), IM-Data L2 (tier-calibrated incident response depends on tier-calibrated hardening for blast-radius containment and rapid evidence assembly).

Desired Outcomes

• Hardening depth is visibly differentiated: Critical-tier data assets run in a more constrained, more observable envelope than Low-tier assets; reviewers and regulators can verify the differentiation from the asset's configuration record in the SM-Data inventory.
• Critical-tier data assets use HSM-rooted keys with per-tenant key separation enforced at the storage layer, not only at the application layer.
• Enhanced DLP policies for Critical-tier assets include content inspection on egress paths, not just pattern matching on filenames or volume thresholds.
• Zero-trust data access enforced for Critical-tier: no standing interactive access to training corpora, fine-tuning datasets, or evaluation/test sets classified Critical; all interactive access is just-in-time, approval-gated, time-limited (≤4 hours), and fully logged.
• Tier-hardening matrix published and enforced at provisioning; SM-Data inventory records show hardening status per tier; gaps are open IM-Data findings.

Activities

A) Tier-conditional hardening calibration

Publish a hardening tier-treatment matrix aligned to SM-Data L2's risk tiers:

Each AI/HAI data asset record in the SM-Data inventory carries its tier's hardening status; gaps between required and actual controls are open IM-Data findings with an SLA matching the asset's tier.

B) HSM-rooted key management and zero-trust data access for Critical-tier

• HSM-rooted key management for Critical-tier: for all Critical-tier AI/HAI data assets, key material is generated and stored in an HSM (AWS CloudHSM, GCP Cloud HSM, Azure Dedicated HSM, or on-premise HSM); no key for a Critical-tier asset resides in software-only KMS; per-tenant key separation is enforced at the HSM level where a shared storage backend serves multiple tenants; key rotation ≤30 days.
• Zero-trust data access: for Critical-tier training corpora, fine-tuning datasets, and evaluation/test sets:
• No standing interactive access with read or write permissions; access is just-in-time, scoped to the specific dataset path, time-limited (≤4 hours), and requires an approval gate before grant.
• Approval gate records (requestor, purpose, approver, grant time, expiry) are written to the audit log at grant time; session activity during the JIT window is logged at the storage layer.
• JIT access tooling integrated with the secrets vault and the data catalog's access-control plane; manual credential sharing as a workaround is a blocking IM-Data finding.
• Ephemeral credentials for Critical-tier pipelines: Critical-tier data pipelines use ephemeral credentials (short-lived tokens from the IAM system, not long-lived service account keys); token lifetime ≤1 hour; token revocation on pipeline completion logged to the audit trail.

C) Enhanced DLP and cross-border residency enforcement

• Content inspection for Critical-tier egress: for Critical-tier data asset egress paths, extend DLP from pattern matching to content inspection:
• Prompt/completion-log bulk export inspection: inspect export payloads for PII patterns before allowing export to any destination outside the approved boundary.
• Training-dataset export inspection: inspect training-dataset archives for regulated data classes before allowing export; block export if regulated data is detected without an explicit approval gate.
• Embedding export inspection: alert on bulk exports of embedding vectors from Critical-tier embedding stores to any external destination; block exports exceeding size thresholds without explicit approval.
• Archetype-specific custom DLP patterns: each of the seven data archetypes has at least one custom DLP pattern tuned to its exfiltration surface:
• Training corpus / fine-tuning dataset: archive-file export containing dataset metadata headers.
• Inference input stream: bulk batch-inference request export in JSON/CSV format.
• Retrieval store / embedding store: bulk vector-file export (large float arrays in npy, parquet, or bin format).
• Prompt/completion log corpus: structured log export containing prompt/completion field patterns.
• Evaluation/test set: export of evaluation set files (labeled dataset formats) to external destinations.
• Residency enforcement at storage layer: for Critical-tier and High-tier data assets subject to residency requirements, residency enforcement is implemented at the storage layer (region-locked S3 bucket policies, GCP Organization Policy constraints, Azure policy locks on storage accounts) rather than relying solely on application-layer controls; any storage-layer policy change that would permit cross-region replication for a residency-controlled Critical-tier asset triggers an IM-Data finding.

Outcome Metrics (L2)

Process Metrics (leading)

• HSM key-rotation cadence, Critical-tier keys rotated ≤30 days; High-tier ≤90 days; deviations are open IM-Data findings.
• JIT access log review, weekly review; access grants exceeding the 4-hour time limit trigger immediate IM-Data findings.
• DLP content-inspection review cadence, monthly false-positive/false-negative rate review for Critical-tier egress paths; tuning changes logged.
• Residency enforcement audit cadence, quarterly; any storage-layer policy change on residency-controlled assets reviewed and documented within 5 business days.

Effectiveness Metrics (business value)

• Reduced undetected regulated-data egress volume from Critical-tier assets after content-inspection DLP enforcement.
• Fewer cross-tenant storage-access findings in IR reviews for Critical-tier assets after HSM-rooted per-tenant key separation.
• Insider-risk signal quality, content-inspection DLP detection of regulated-data bulk exports from data-pipeline paths provides the IM-Data team with actionable signals not available at L1.

Success Criteria

• 100% of Critical-tier data assets under HSM-rooted key management with per-tenant key separation; key rotation ≤30 days.
• 100% of Critical-tier data assets with zero-trust JIT access; no standing interactive credentials for training corpora, fine-tuning datasets, or evaluation/test sets at Critical tier.
• ≥90% of Critical-tier data asset egress paths with content-inspection DLP active; false-positive rate monitored and trending down.
• Tier-hardening matrix published and enforced; SM-Data inventory records show hardening status per tier; gaps are open IM-Data findings.
• Storage-layer residency enforcement active for 100% of Critical-tier and High-tier residency-controlled data assets.

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, DAMA, and sector ISACs

At this level, hardening is code. Every EH-Data control, storage-backend configuration, key-management policy, pipeline service-account provisioning, access-control policy, DLP rule set, cross-border gate, egress allowlist, is expressed as a Terraform or Pulumi module in a version-controlled IaC registry. Drift is detected continuously; low-risk drift is auto-remediated. Adaptive tightening fires when ML-Data detection trends or IM-Data incident patterns signal an emerging risk. Hardening baselines are contributed to OpenSSF AI, DAMA, EDM Council, and sector ISACs.

Dependencies

• EH-Data L2 (required): HSM-rooted key management, zero-trust data access, content-inspection DLP, and storage-layer residency enforcement must be operational before automation and adaptive tightening are trustworthy.
• ML-Data L2+ (required): ML-Data detections (retrieval extraction attempts, embedding inversion attempts, cross-border flow violations, bulk egress anomalies) are the upstream source for adaptive policy-tightening proposals.
• IM-Data L2+ (required): incident patterns from post-incident reviews feed adaptive tightening proposals and drive hardening-baseline updates.
• SM-Data L3 (alignment): automated inventory signals trigger auto-provisioning of hardening controls for new data assets; tier-change signals trigger hardening-profile upgrades.

Desired Outcomes

• All EH-Data controls are reviewable as code; a security engineer can open the IaC registry and understand exactly what hardening applies to any data asset without reading a configuration console.
• Drift between deployed configuration and the IaC specification is detected within hours; low-risk drift is auto-remediated; high-risk drift triggers a human-review alert within 2 business days.
• Adaptive tightening is traceable: every policy change has a source signal (ML-Data detection trend ID or IM-Data incident ID), a human-approval record, and a downstream notification to affected data engineering teams.
• AI/HAI data hardening baselines published by this program are adopted by at least one industry body (OpenSSF, DAMA, EDM Council, or a sector ISAC).
• New AI/HAI data assets are auto-provisioned with their tier-appropriate hardening controls at asset registration, not retroactively after an IR-Data or IM-Data finding.

Activities

A) Hardening-as-code: IaC for all EH-Data controls

Express every EH-Data control as a version-controlled, forkable IaC module parameterized by archetype and tier:

• Storage envelope module: Terraform / Pulumi module for storage-backend provisioning (encryption configuration, key-management policy attachment, compliance-tier selection, bucket/table access-control policy, cross-region replication policy with transfer-mechanism gate, deletion-policy and lifecycle-rule configuration); parameterized by data archetype and classification tier.
• Pipeline envelope module: pipeline service-account creation module (named service account, least-privilege IAM policy, mTLS configuration, secrets vault path provisioning, ephemeral-credential rotation schedule); CI/CD pipeline template additions for dataset provenance attestation enforcement and deny-list check; encoded as reusable pipeline components.
• Access envelope module: data-catalog and vector-store console access-control module (SSO enforcement, JIT access configuration for Critical/High-tier, audit-log destination configuration, RBAC policy attachment); parameterized by tier.
• Cross-border module: residency enforcement module (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); egress allowlist rule for data pipeline service accounts; expressed as configuration-as-code for DLP and CASB platforms.

IaC modules version-pinned; module updates notify consuming data-engineering teams with a required-remediation flag. A drift-detection pipeline runs hourly against all deployed data-asset configurations; low-risk drift is auto-remediated; high-risk drift (key management downgrade, access-control loosening, egress allowlist expansion for regulated assets) triggers a human-review alert within 2 business days and an IM-Data finding.

B) Adaptive policy tightening from ML-Data and IM-Data signals

Wire ML-Data detection signals and IM-Data incident patterns to a human-approved adaptive-tightening pipeline:

• ML-Data signals:
• Retrieval extraction attempt detected (anomalous query volume / pattern on a retrieval store) → egress-narrowing proposal for the affected retrieval store's service account.
• Embedding inversion attempt detected → embedding-store access lockdown proposal; enhanced egress DLP rule tightening proposal for the affected embedding store.
• Cross-border flow violation detected (regulated data crossing a regional boundary without a documented transfer mechanism) → residency-enforcement tightening proposal; transfer-mechanism registry update trigger.
• Bulk egress anomaly from data-pipeline service account → egress-allowlist review proposal for the affected service account; DLP rule sensitivity increase proposal.
• IM-Data signals: post-incident review records that identify a hardening gap → hardening-baseline update proposal; Critical-tier data incident involving a misconfigured storage access policy → zero-trust access upgrade proposal for affected tier.
• Adaptive tightening pipeline: proposals are human-reviewed before deploy (security platform engineer approval); the change log is machine-readable; downstream data-engineering teams notified within 24 hours of a tightening change that affects their asset's hardening profile.
• Feedback loop to TA-Data and SR-Data: hardening changes that reflect a new threat pattern feed back to the TA-Data threat library and to the SR-Data requirements pack as potential new requirements.

C) Contribute hardening baselines to industry

• Contribute anonymized EH-Data hardening baseline modules to:
• OpenSSF AI, dataset provenance attestation standards, pipeline service-account least-privilege patterns, signed-artifact verification for training datasets.
• DAMA (Data Management Body of Knowledge), AI/HAI data asset classification schemes, key-management tier treatment, retention and deletion verification standards.
• EDM Council, financial-sector AI data governance hardening patterns (applicable where AI is used in financial data processing).
• Sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), sector-relevant hardening patterns for AI/HAI data assets in regulated environments.
• Target: ≥2 substantive contributions per year; maintained upstream; internal practice aligns with the published external version.
• Auto-provisioning trigger: when a new AI/HAI data asset is registered in the SM-Data inventory, the IaC automation automatically provisions its tier-appropriate hardening profile within 24 hours.

Outcome Metrics (L3)

Process Metrics (leading)

• IaC coverage growth rate, % of EH-Data controls migrated to IaC month-over-month; target ≥90% before the quarter closes.
• Adaptive-policy pipeline freshness, ML-Data and IM-Data signal feeds checked weekly; stale feeds (>7 days without a processed event) flagged.
• Industry contribution pipeline, ≥1 hardening artifact (OpenSSF contribution, DAMA submission, ISAC brief) in-flight at any time (draft, in-review, or published).
• Drift queue, open high-risk drift findings triaged and human-reviewed within 2 business days; low-risk resolved within 5 business days.

Effectiveness Metrics (business value)

• Reviewer-hours per hardening-configuration change drop quarter-over-quarter as IaC and adaptive-policy automation absorb manual review cycles.
• External recognition, OpenSSF, DAMA, or sector ISAC adoption of contributed AI/HAI data hardening baselines; citations in sector publications.
• Time-to-hardened for new AI/HAI data assets decreases from "days after IR-Data review" to "hours after SM-Data registration" as auto-provisioning operates.
• Incident rate on IaC-encoded data deployments lower than on hand-configured deployments, tracked as a rolling 12-month comparison.

Success Criteria

• ≥90% of EH-Data controls expressed as IaC; drift detected continuously with ≥70% of low-risk drift auto-remediated; high-risk drift human-reviewed within 2 business days.
• Adaptive-policy pipeline operational, ML-Data and IM-Data signals generate human-approved policy-tightening proposals on a tracked cadence; change log traceable to source signals.
• New AI/HAI data assets auto-provisioned with tier-appropriate hardening within 24 hours of SM-Data inventory registration.
• ≥2 industry hardening baseline contributions per year (OpenSSF, DAMA, EDM Council, sector ISACs) with documented adoption.
• Quarterly adaptive-policy change log traceable to ML-Data detections and IM-Data incident patterns.

Key Success Indicators

Level 1: - 100% of AI/HAI data assets in production have a classification label, a named owner, and a baseline hardening status in the SM-Data inventory; no unclassified asset is accessible by any pipeline service account. - 100% of training corpora and fine-tuning datasets carry signed SLSA-style provenance attestations at promotion; promotion without provenance blocked by the pipeline gate. - 100% of data-facing consoles (catalog, model registry, prompt-log store, vector store, embedding store) require SSO + MFA; all pipeline service accounts use named, vault-managed credentials; CI secrets-scanning enforced with zero hardcoded-credential findings. - Cross-border replication for regulated data assets documented with transfer mechanisms (SCC / adequacy / BCR); all existing replication configurations reconciled against the transfer-mechanism registry. - DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and active.

Level 2: - 100% of Critical-tier data assets under HSM-rooted key management with per-tenant key separation; key rotation ≤30 days; zero standing interactive credentials at Critical tier. - ≥90% of Critical-tier data asset egress paths with content-inspection DLP active; false-positive rate monitored and trending down. - Storage-layer residency enforcement active for 100% of Critical-tier and High-tier residency-controlled data assets. - Tier-hardening matrix published and enforced at provisioning; SM-Data inventory records show hardening status per tier; gaps are open IM-Data findings.

Level 3: - ≥90% of EH-Data controls expressed as IaC; drift detected continuously; ≥70% of low-risk drift auto-remediated; high-risk drift human-reviewed within 2 business days. - Adaptive-policy pipeline operational with ML-Data and IM-Data signal sources; change log machine-readable and traceable. - New AI/HAI data assets auto-provisioned with tier-appropriate hardening within 24 hours of SM-Data inventory registration. - ≥2 industry hardening baseline contributions per year (OpenSSF, DAMA, EDM Council, sector ISACs) with documented adoption.

Common Pitfalls

Level 1: - ❌ Classification labels added to the data catalog but not enforced at the storage or pipeline layer, a service account with "internal" role reads a "regulated" dataset because the storage access policy was never updated to reflect the classification. - ❌ Provenance attestations required by policy but not enforced at the pipeline gate, training jobs consume unsigned datasets because the gate check was implemented as an informational warning rather than a blocking step. - ❌ SSO enforced on the data-catalog console but the underlying storage backend (S3, GCS, Azure Blob) accepts direct access via long-lived storage account keys held by pipeline team members, the SSO enforcement is a UI control, not a storage-layer policy. - ❌ Cross-border replication configured during a cloud migration without transfer-mechanism documentation, the organization has been replicating regulated training data across regions for 18 months with no SCC in place; discovered during an audit. - ❌ DLP rules tuned for credit-card numbers and SSNs but not for AI-specific egress patterns, bulk embedding exports to a contractor's GCS bucket go undetected because the DLP engine does not recognize high-dimensional float arrays as sensitive. - ❌ Audit logs configured for the data catalog UI but not for direct storage API access, a pipeline service account reads and exports training corpus files directly via the storage API, leaving no trace in the catalog audit log.

Level 2: - ❌ HSM-rooted key management declared for Critical-tier assets but the HSM integration is only at the KMS level, not at the storage-backend level, the storage backend encrypts with a software-KMS-wrapped key; the HSM is upstream but the storage layer never calls it directly; an HSM compromise does not actually protect the data at rest. - ❌ JIT access for Critical-tier datasets implemented via a ticketing workflow but the underlying IAM still grants standing read permissions to the approver role, the JIT process is a ceremonial approval step; the underlying access control is unchanged. - ❌ Content-inspection DLP scoped to browser-based download traffic but the training-dataset bulk export vector is a CI/CD pipeline step that runs as a background service, the DLP controls the human-facing surface and misses the programmatic exfiltration path entirely. - ❌ Tier-hardening matrix exists but is evaluated during DR review and never at provisioning, a new High-tier data asset goes live with Medium-tier baseline controls because the provisioning template was copied from an older asset and the tier field was not updated.

Level 3: - ❌ IaC coverage declared at ≥90% but the registry counts data assets that have an IaC stub, not assets whose IaC is the authoritative deployed source, drift accumulates between the stub and the live configuration; the auto-remediation pipeline fires on the stub's expected state, not the real deployed state. - ❌ Adaptive-policy pipeline wired to ML-Data detections but not to IM-Data incidents, post-incident hardening opportunities (where an IR-Data review identified a storage misconfiguration that contributed to a breach) are never converted to tightening proposals. - ❌ Industry hardening baselines contributed but not maintained upstream, internal practice advances (new archetype added, new egress pattern) while the published DAMA or OpenSSF contribution reflects a 12-month-old state; external adopters find the published version conflicts with advice from the program's engineers. - ❌ Auto-provisioning trigger fires but reads the previous tier assignment, a Medium-to-Critical tier upgrade is reflected in SM-Data inventory within hours but the hardening profile is not updated because the IaC provisioning pipeline reads a cached tier field.

Practice Maturity Questions

Level 1: 1. Does every AI/HAI data asset in the SM-Data inventory (across all seven archetypes: training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set) carry a classification label, a named owner, and a baseline hardening status, and are all training corpora and fine-tuning datasets gated at promotion by a signed SLSA-style provenance attestation that blocks unsigned datasets from entering the training pipeline? 2. Do all data-facing consoles (data catalog, model registry, prompt-log store, vector store, embedding store) require SSO + MFA, with all pipeline service accounts running under named, vault-managed credentials, confirmed by CI secrets-scanning with zero hardcoded-credential findings, and is every read, write, export, and delete event on AI/HAI data assets written to an append-only audit log with access-control separation between pipeline teams and log administrators? 3. Are cross-border flows for regulated data assets (PII, PHI, regulated financial data) documented with a transfer mechanism (SCC / adequacy / BCR) on file before replication activates, with all existing replication configurations reconciled against the transfer-mechanism registry, and are DLP rules tuned for AI-specific egress patterns (bulk embeddings, prompt/completion-log exports, training-dataset exports) deployed and actively monitored?

Level 2: 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, with standing interactive credentials deprecated for Critical-tier? 2. Are ≥90% of Critical-tier data asset egress paths (bulk exports from training corpora, fine-tuning datasets, retrieval stores, embedding stores, prompt/completion log corpora) subject to content-inspection DLP, with false-positive rates actively monitored and trending down through monthly review cadences, and is a tier-hardening matrix published and enforced at provisioning with gaps tracked as open IM-Data findings? 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, confirmed by a quarterly storage-policy audit, and are archetype-specific custom DLP patterns deployed for each of the seven AI/HAI data archetypes?

Level 3: 1. Are ≥90% of EH-Data controls expressed as authoritative IaC (not stubs) in a version-controlled IaC registry, with drift detected continuously and ≥70% of low-risk drift auto-remediated, with a machine-readable change log visible to downstream data-engineering teams, and high-risk drift human-reviewed within 2 business days? 2. Is the adaptive-policy pipeline operational, with ML-Data detections and IM-Data incidents generating human-approved policy-tightening proposals on a tracked cadence, every change traceable to a source signal, and downstream data-engineering teams notified within 24 hours of a tightening change affecting their asset's hardening profile? 3. Does the program contribute ≥2 AI/HAI data hardening baselines per year to industry bodies (OpenSSF, DAMA, EDM Council, sector ISACs) with documented adoption, and are new AI/HAI data assets auto-provisioned with their tier-appropriate hardening profile within 24 hours of SM-Data inventory registration?

Document Version: HAIAMM v3.0 Practice: Environment Hardening (EH) Domain: Data Last Updated: 2026-05-13 Author: Verifhai