Environment Hardening (EH)

Data Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/EH-Data-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Operations

Objective: Publish and apply a hardening baseline for each data AI archetype, so the operating environment enforces the controls rather than documenting them.

Description: A program at this level has a published hardening baseline per archetype and applies it. The baseline covers per-request authorization on retrieval stores, encryption at rest and in transit with managed keys, redaction applied at log write, retention configured to the declared period, network isolation of training environments from production data paths, and immutable audit logging on corpus access. The distinction that matters is enforcement: a control in enforcing mode changes what can happen, and a control in audit mode changes only what is recorded, and the two are frequently confused in reporting. Consumption limits are part of the baseline rather than an operational afterthought, because an environment with no limit has no defence against the one attack that leaves every availability signal green.

---

Maturity Level 1, Foundational

Objective: Publish and apply a hardening baseline for each data AI archetype, so the operating environment enforces the controls rather than documenting them.

A program at this level has a published hardening baseline per archetype and applies it. The baseline covers per-request authorization on retrieval stores, encryption at rest and in transit with managed keys, redaction applied at log write, retention configured to the declared period, network isolation of training environments from production data paths, and immutable audit logging on corpus access. The distinction that matters is enforcement: a control in enforcing mode changes what can happen, and a control in audit mode changes only what is recorded, and the two are frequently confused in reporting. Consumption limits are part of the baseline rather than an operational afterthought, because an environment with no limit has no defence against the one attack that leaves every availability signal green.

Dependencies

• Required: SM-Data-L1, PC-Data-L1, SR-Data-L1, SA-Data-L1
• Alignment (not blocking): Existing infrastructure and endpoint hardening standards, so AI baselines extend the established estate rather than forming a parallel one
• Supports / unblocks: IR-Data-L1; ST-Data-L1; ML-Data-L1; IM-Data-L1; Required by: EH-Data-L2

Desired Outcomes

• Every data AI archetype has a published hardening baseline that is applied rather than recommended.
• Controls are in enforcing mode, and any control in audit mode is recorded as an exception with an owner.
• Consumption limits are part of the baseline, with per-consumer retrieval quotas with a declared behaviour at the quota configured rather than left unbounded.
• Baseline conformance is measured against the running environment rather than against intent.
• An exception to the baseline has an owner, a compensating control and an expiry.

Activities

A) Publish the hardening baseline per archetype

Author a hardening baseline per archetype covering per-request authorization on retrieval stores, encryption at rest and in transit with managed keys, redaction applied at log write, retention configured to the declared period, network isolation of training environments from production data paths, and immutable audit logging on corpus access. Express the baseline as configuration that can be applied and checked rather than as prose, and publish it alongside the reference architecture patterns so that the secure configuration travels with the secure design. State for every control whether it is enforcing or advisory, and default to enforcing, because a baseline whose enforcement status is unstated is assumed to be enforcing by everyone reporting on it and is frequently not. Where a control genuinely cannot be enforced in the current environment, record it as a known limitation rather than listing it in the baseline as though it were active.

B) Apply the baseline and measure conformance against the running environment

Apply the baseline to every asset of the archetype and measure conformance from the environment rather than from a checklist. Read configuration state, policy enforcement mode and runtime behaviour, and report conformance per control rather than as a single score, because one aggregate number lets a fully conformant set of easy controls conceal a missing hard one. Report separately the count of controls running in audit rather than enforcing mode, which is the most common way a baseline is nominally met and practically absent. Reconcile monthly and treat any asset with no baseline applied as a finding with an owner rather than as an onboarding backlog item.

C) Configure consumption limits and govern exceptions

Configure per-consumer retrieval quotas with a declared behaviour at the quota as part of the baseline for every asset, expressed relative to per retrieval query so that the limit bears a defensible relationship to the work the asset actually does. Declare the behaviour at the limit explicitly, being degrade, queue or refuse, and never silently continue, because a limit that is exceeded without effect is a reporting artefact rather than a control. Operate a baseline exception process: any control not applied requires an owner, a compensating control, an approver and an expiry, reviewed monthly, with expired exceptions treated as findings. Exceptions are healthy when visible and corrosive when absorbed into the environment as the new normal.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Data AI assets with the archetype hardening baseline applied	first application pass	≥90% of production assets within 9 months	Configuration state reconciled against the baseline definition
Baseline controls running in enforcing rather than audit mode	first enforcement audit	≥90%, with every audit-mode control recorded as an exception	Policy enforcement mode audit
Assets with consumption limits configured and an explicit at-limit behaviour declared	first limit audit	100% of production assets	Gateway and platform limit configuration audit; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1
Baseline exceptions carrying an owner, compensating control, approver and expiry	first exception review	100%, with none past expiry	Exception register
Conformance reported per control rather than as a single aggregate score	first reporting cycle	100% of baseline controls reported individually	Conformance report structure

Process Metrics (leading)

• Baseline conformance reconciled against the running environment at least monthly.
• Baseline reviewed quarterly against new findings, patterns and threat-library changes.
• Exception register reviewed monthly with expired entries closed or renewed within 10 business days.
• Newly provisioned assets receive the baseline at provisioning rather than after.

Effectiveness Metrics (business value)

• Time from asset provisioning to full baseline conformance falls toward zero as baselines are applied at creation.
• Findings attributable to a missing baseline control fall.
• Exception volume falls as baselines are refined to match what environments can genuinely enforce.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Baseline exceptions approved without a compensating control recorded	exception approval becoming a formality, where the control is waived and nothing replaces it, which is indistinguishable from not having the control at all	Exception register with compensating-control field
Controls switched from enforcing to audit mode, with the change approved and time-bounded	silent downgrade, where a control is moved to audit mode to resolve an operational problem and left there, so the baseline reports as met while enforcing nothing	Policy enforcement mode change log

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Assets with a consumption limit configured and a declared at-limit behaviour	per production asset	an environment with no effective ceiling, which leaves denial-of-wallet with no defence at the layer where it would actually be stopped	Gateway and platform limit configuration audit
Configured limit against observed consumption	per retrieval query	limits set so far above real load that they never bind, or so close to it that legitimate work trips them and operations disables the control	Limit configuration compared against the consumption ledger
Limit breaches where the declared at-limit behaviour did not occur	per limit breach event	a limit that is exceeded without effect, which is a reporting artefact rather than a control and is discovered only when it matters	Gateway enforcement log

Level of Effort (incremental over the level below)

• Stand-up: 160 hours · Ongoing: 110 hours/quarter
• DevOps / Platform Engineer — primary, 34 days/year
• AppSec / SecEng — regular, 14 days/year
• Security Architect — regular, 10 days/year
• Security Analyst / SOC — low, 6 days/year
• Material new tooling: Configuration conformance scanning against the baseline definitions

Success Criteria

• A hardening baseline is published per archetype as applicable configuration rather than prose, and applied to at least 90% of production data AI assets.
• At least 90% of baseline controls run in enforcing mode, with every audit-mode control recorded as an exception with an owner.
• Every production asset has a consumption limit configured with an explicit, declared at-limit behaviour.
• Conformance is reported per control rather than as an aggregate score that can conceal a missing hard control.
• Every baseline exception carries an owner, compensating control, approver and expiry, with none past expiry.

---

Maturity Level 2, Comprehensive

Objective: Calibrate data hardening intensity to asset tier, detect and remediate baseline drift continuously, and make consumption limits tier-proportionate and tested.

At this level hardening follows tier and holds over time. Critical-tier assets carry a stricter baseline with tighter isolation, shorter rotation intervals and no standing access, while drift detection runs continuously so a control silently relaxed is caught in days. Drift is this practice's defining failure at scale: environments are hardened once and then changed for operational reasons that are individually reasonable and collectively corrosive. Consumption limits are tier-proportionate and their at-limit behaviour is exercised rather than assumed.

Dependencies

• Required: EH-Data-L1, SM-Data-L2, IR-Data-L2
• Alignment (not blocking): Change management, so baseline changes ride existing change records
• Supports / unblocks: ST-Data-L2; ML-Data-L2; IM-Data-L2; Required by: EH-Data-L3

Desired Outcomes

• Baseline strictness follows asset tier, and the difference is published rather than negotiated.
• Baseline drift is detected continuously for high-tier assets and remediated within a stated window.
• Consumption limits are tier-proportionate and their at-limit behaviour has been exercised.
• Standing access to Critical-tier environments is absent rather than merely discouraged.
• A control relaxed for an operational reason is time-bounded rather than permanent by default.

Activities

A) Publish tier-calibrated baselines

Publish a baseline variant per tier rather than one baseline with exceptions. Critical adds per-tenant isolation, no standing human access with time-bound elevation, shorter secret rotation intervals, stricter egress allowlisting and full logging; Low takes single sign-on and the essential controls. Deriving the applicable variant from the inventory tier removes the negotiation that otherwise happens per asset and resolves toward the lighter variant. Publish the reasoning alongside the variants so that a team subject to the Critical baseline understands why, because a baseline that arrives without justification is complied with minimally and circumvented where possible. Drift in this domain most often appears as redaction disabled for debugging and a retrieval store granted a broader service identity, the second of which looks like a routine access change.

B) Detect and remediate drift continuously

Stand up continuous drift detection across the baseline controls for Critical- and High-tier assets, reading configuration state, policy enforcement mode and runtime behaviour, and alerting on change rather than on schedule. Publish remediation windows by tier and severity, tighter at Critical, and route detections into the shared issue backlog with tier-appropriate severity rather than into a dashboard. Drift is the defining failure of hardening at scale because environments are hardened once and then changed for operational reasons that are individually reasonable: a rule widened for a debugging session, a quota raised under load, an enforcement mode relaxed to unblock a deployment. Each is defensible and none is reverted unless something notices. Limit exercises in this domain drive a retrieval store to its quota and confirm the declared behaviour, which matters because extraction and legitimate heavy use are indistinguishable without it.

C) Make limits tier-proportionate and exercise them

Set consumption limits proportionate to tier and to the asset's observed workload, expressed relative to per retrieval query. Exercise the at-limit behaviour at least annually for Critical- and High-tier assets by driving the asset to its limit in a controlled test and confirming that the declared behaviour actually occurs, because a limit whose behaviour has never been observed is an assumption. Record the exercise result. Treat a cost-driven change to a limit, a logging level, a retention period or an enforcement mode on a Critical-tier asset as a material change requiring approval, since these are precisely the controls that cost pressure erodes and the erosion is invisible on any security dashboard. Cost pressure in this domain lands first on retention, which is the control regulators and investigators both depend on and the one whose absence is discovered latest.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Assets running the baseline variant derived from their tier	first tier-derivation pass	100% of Critical and High tier assets	Baseline assignment joined to inventory tier
Critical- and High-tier assets under continuous drift detection	first drift rollout	≥95% of Critical, ≥85% of High	Drift detection coverage registry
Time to detect baseline drift on a Critical-tier control	first quarter of drift telemetry	≤3 business days at the 90th percentile	Drift detection event log
Drift remediated within the tier and severity window	first quarter of remediation telemetry	≥90% per tier	Issue tracker with remediation-window fields
Standing human access to Critical-tier AI environments	first access review	0, with time-bound elevation only	Identity and access review
Critical- and High-tier assets whose at-limit behaviour was exercised in the last 12 months	first exercise round	100% of Critical, ≥90% of High	Limit exercise log with dates and outcomes

Process Metrics (leading)

• Baseline variant re-derived automatically when an asset's tier changes.
• Drift detection feed freshness monitored, with alerting when a feed goes stale.
• Cost-driven changes to limits, logging, retention or enforcement mode routed for approval at Critical tier.
• At-limit behaviour exercised on the tier cadence with results recorded.

Effectiveness Metrics (business value)

• Mean time a Critical-tier control spends in a drifted state falls, which is what drift detection exists to compress.
• Incidents attributable to a relaxed control fall.
• Hardening effort concentrates on Critical and High tiers relative to L1.
• Reverted operational relaxations rise as a share of relaxations, indicating temporary changes stay temporary.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Time-bound elevations to Critical-tier environments that expired without being reviewed	elevation becoming effectively standing access, where a time bound exists on paper and is renewed automatically without anyone assessing whether it is still needed	Privileged access session records
Drift remediation deferrals at Critical tier, with a named acceptance authority	deferral becoming the default response to drift under operational pressure, which converts continuous detection into continuous reporting	Drift finding disposition records
Enforcement-mode relaxations approved without an expiry	a temporary relaxation becoming permanent because nothing in the approval obliges anyone to revisit it	Policy enforcement mode change log

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Critical- and High-tier assets whose at-limit behaviour has been exercised and recorded	per Critical or High tier asset	a declared limit whose behaviour has never been observed, which is an assumption rather than a control at exactly the tiers that cannot afford one	Limit exercise log joined to inventory tier
Limit headroom: configured limit against observed peak consumption, by tier	per retrieval query	limits set without reference to real load, which either never bind or trip on legitimate work and are then disabled by operations	Limit configuration compared against consumption ledger peaks
Cost-driven relaxations of limits, logging or retention on Critical-tier assets	per approved change	assurance controls eroding under cost pressure with approval, which is the most common and least visible way a hardened environment degrades	Change records filtered to cost-motivated configuration changes

Level of Effort (incremental over the level below)

• Stand-up: 180 hours · Ongoing: 190 hours/quarter
• DevOps / Platform Engineer — primary, 40 days/year
• Security Analyst / SOC — regular, 18 days/year
• AppSec / SecEng — regular, 12 days/year
• Security Architect — low, 8 days/year
• Material new tooling: Continuous drift detection across configuration, policy mode and runtime state

Success Criteria

• A baseline variant per tier is published with its reasoning and derived automatically from the inventory.
• At least 95% of Critical-tier assets are under continuous drift detection, with detection within 3 business days.
• Standing human access to Critical-tier AI environments is zero, with time-bound elevation only.
• Every Critical-tier asset's at-limit behaviour has been exercised within 12 months and the result recorded.
• Cost-driven changes to limits, logging, retention or enforcement mode at Critical tier require approval as material changes.

---

Maturity Level 3, Industry-Leading

Objective: Make data AI environments self-correcting, with baselines applied at provisioning and drift remediated automatically where it is safe to do so.

At this level the environment corrects itself. Baselines are applied at provisioning so an asset is never unhardened, and drift on well-understood controls is remediated automatically rather than ticketed. Automatic remediation is bounded deliberately: the classes where it is safe are enumerated, everything else alerts, and every automated action is logged and reviewable, because an environment that silently repairs itself can also silently mask a genuine operational need. Limits adapt to observed workload within governed bounds rather than remaining static and eventually wrong.

Dependencies

• Required: EH-Data-L2, SA-Data-L3, ML-Data-L2, IM-Data-L2
• Alignment (not blocking): Platform engineering ownership, since automated remediation acts on their environments
• Supports / unblocks: Every other Data practice at L3, which inherits a self-correcting environment; Required by: IM-Data-L3

Desired Outcomes

• Assets are provisioned already conformant, so no asset exists in an unhardened state.
• Drift on enumerated safe classes is remediated automatically, and everything else alerts.
• Every automated remediation is logged, attributable and reviewable rather than silent.
• Consumption limits adapt to observed workload within governed bounds rather than remaining static.
• Repeated automatic remediation of the same control is treated as a signal rather than a success.

Activities

A) Apply baselines at provisioning

Move baseline application to provisioning time so that an asset is conformant from creation rather than hardened afterwards. Implement the baseline as infrastructure-as-code modules, admission policies and platform defaults, so the conformant configuration is the default path and a non-conformant asset requires deliberate effort to create. Block provisioning of Critical-tier assets that would not meet baseline. Measure the time an asset spends non-conformant after creation and drive it to zero, since that window is the one period in an asset's life when it is both unhardened and unmonitored, and it is the window most exploitation of new infrastructure actually uses. Provisioning-time conformance in this domain means a new corpus cannot be created without a classification and a retention period, which removes the most common origin of ungoverned data.

B) Automate remediation within enumerated bounds

Enumerate explicitly the drift classes that may be remediated automatically, being those where the correct state is unambiguous and reversion carries no operational risk, such as re-enabling logging, restoring an enforcement mode, or closing an egress rule not in the allowlist. Everything outside that list alerts to a human. Log every automated action with what changed, what it was reverted to and why, and make the log reviewable, because self-correction that is silent can mask a genuine operational need indefinitely and the team whose change was reverted will simply make it again. Track repeated remediation of the same control on the same asset as a signal that the baseline is wrong or the operational need is real, and route it to review rather than continuing to revert. Safe automatic remediation in this domain covers restoring redaction at log write and reverting an over-broad retrieval identity, while anything touching a live pipeline alerts instead.

C) Govern adaptive limits and publish the automation boundary

Allow consumption limits to adapt to observed workload within governed bounds, so that a limit tracks the asset's real demand rather than remaining static and becoming either irrelevant or obstructive. Set a hard ceiling that adaptation cannot cross without human approval, because an adaptive limit with no ceiling accommodates an attack as readily as it accommodates growth, and that is precisely the failure mode denial-of-wallet exploits. Express bounds relative to per retrieval query. Publish the list of controls that cannot be automatically applied or remediated and review it quarterly for reduction, so that the boundary of the automation is known rather than assumed to be complete. Adaptive limits in this domain track retrieval cost per query, where a rising per-query cost is a stronger extraction signal than rising volume alone.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Assets provisioned already conformant to their tier baseline	L2 post-provisioning application	≥95% of new assets	Provisioning telemetry joined to conformance scan
Time an asset spends non-conformant after creation	L2 remediation window	≤1 hour at the 90th percentile	Provisioning and conformance timestamps
Enumerated safe drift classes remediated automatically	first automation rollout	≥80% of drift events in the enumerated classes	Automated remediation log
Automated remediations logged with change, reversion and reason, and reviewable	first quarter of automation	100%	Remediation audit log
Repeated automatic remediation of the same control on the same asset	first quarter of automation	tracked, with any control remediated more than three times routed to review	Remediation log aggregated by control and asset
Adaptive limits operating within a governed hard ceiling	first adaptive rollout	100% of adaptive limits carry a ceiling requiring human approval to cross	Limit configuration audit

Process Metrics (leading)

• Provisioning blocks Critical-tier assets that would not meet baseline.
• Automated remediation scope reviewed quarterly, with classes added only after demonstrated safety.
• Repeated-remediation signals reviewed monthly and routed to baseline or operational review.
• Non-automatable control list reviewed quarterly with a reduction target.

Effectiveness Metrics (business value)

• Mean time in a drifted state approaches the detection interval, which is the level's defining outcome.
• Manual hardening effort per asset falls while conformance rises.
• Incidents attributable to an unhardened newly provisioned asset approach zero.
• Baseline changes driven by repeated-remediation signals rise, indicating the loop is informing the baseline.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Automated remediations reverted by a human within 24 hours	automation acting against a genuine operational need, which indicates the enumerated safe class was wrongly scoped and is invisible unless reversions are tracked	Remediation log joined to subsequent configuration changes
Adaptive limit ceiling increases approved, with the approver and justification recorded	ceiling creep, where each individual increase is justified and the cumulative effect is an unbounded limit nobody decided to create	Limit ceiling change log
Alerts for non-automatable drift acknowledged but not remediated within the tier window	alert fatigue on the drift classes that specifically require human judgment, which are the ones automation deliberately left to people	Drift alert disposition records

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Adaptive limits operating within a governed hard ceiling	per asset with an adaptive limit	an adaptive limit with no ceiling, which accommodates an attack exactly as readily as it accommodates growth and is the specific failure denial-of-wallet exploits	Limit configuration audit
Cumulative ceiling increase over the trailing year, per asset	per retrieval query	ceiling creep through individually justified increases, where the cumulative effect is an unbounded limit that nobody decided to create	Limit ceiling change log joined to the consumption ledger
Drift events on consumption-limit configuration, and time spent drifted	per limit configuration drift event	limits silently relaxed and left relaxed, which removes the one control that denial-of-wallet actually encounters	Drift detection log filtered to limit configuration

Level of Effort (incremental over the level below)

• Stand-up: 240 hours · Ongoing: 150 hours/quarter
• DevOps / Platform Engineer — primary, 44 days/year
• Security Analyst / SOC — regular, 16 days/year
• AppSec / SecEng — regular, 12 days/year
• Security Architect — low, 6 days/year
• Material new tooling: Automated remediation platform with scoped action classes, Adaptive limit management with governed ceilings

Success Criteria

• At least 95% of new assets are provisioned already conformant, with non-conformance windows at or under one hour.
• The drift classes eligible for automatic remediation are enumerated explicitly, and everything outside alerts to a human.
• Every automated remediation is logged with change, reversion and reason, and is reviewable.
• Repeated remediation of the same control is treated as a signal and routed to review rather than continuing to revert.
• Adaptive limits operate within a governed hard ceiling that requires human approval to cross.

---

Key Success Indicators

Level 1:

• A hardening baseline is published per archetype as applicable configuration rather than prose, and applied to at least 90% of production data AI assets.
• At least 90% of baseline controls run in enforcing mode, with every audit-mode control recorded as an exception with an owner.
• Every production asset has a consumption limit configured with an explicit, declared at-limit behaviour.
• Conformance is reported per control rather than as an aggregate score that can conceal a missing hard control.
• Every baseline exception carries an owner, compensating control, approver and expiry, with none past expiry.

Level 2:

• A baseline variant per tier is published with its reasoning and derived automatically from the inventory.
• At least 95% of Critical-tier assets are under continuous drift detection, with detection within 3 business days.
• Standing human access to Critical-tier AI environments is zero, with time-bound elevation only.
• Every Critical-tier asset's at-limit behaviour has been exercised within 12 months and the result recorded.
• Cost-driven changes to limits, logging, retention or enforcement mode at Critical tier require approval as material changes.

Level 3:

• At least 95% of new assets are provisioned already conformant, with non-conformance windows at or under one hour.
• The drift classes eligible for automatic remediation are enumerated explicitly, and everything outside alerts to a human.
• Every automated remediation is logged with change, reversion and reason, and is reviewable.
• Repeated remediation of the same control is treated as a signal and routed to review rather than continuing to revert.
• Adaptive limits operate within a governed hard ceiling that requires human approval to cross.

---

Common Pitfalls

Level 1:

• ❌ Leaving enforcement status unstated, so controls in audit mode are reported and believed to be enforcing.
• ❌ Reporting a single aggregate conformance score, which lets a set of easy controls conceal a missing hard one.
• ❌ Measuring conformance from a checklist rather than from the running environment, which records intent rather than state.
• ❌ Configuring a limit without declaring the behaviour at the limit, producing a threshold that is crossed without effect.
• ❌ Allowing exceptions without compensating controls, which is indistinguishable from not having the control.

Level 2:

• ❌ Running one baseline with per-asset exceptions rather than tier variants, which turns every asset into a negotiation resolving toward the lighter option.
• ❌ Detecting drift on a schedule rather than on change, which reintroduces the point-in-time weakness the activity exists to remove.
• ❌ Renewing time-bound elevations automatically, which produces standing access with a time bound written on it.
• ❌ Declaring limits without exercising them, so their behaviour is first learned during the event they exist for.
• ❌ Exempting cost-driven changes from approval, which is how hardened environments degrade with everyone's agreement.

Level 3:

• ❌ Hardening after provisioning rather than at it, leaving a window where the asset is both unhardened and unmonitored.
• ❌ Automating remediation without enumerating the safe classes, which eventually reverts something that mattered operationally.
• ❌ Making self-correction silent, so the team whose change was reverted simply makes it again and nobody learns.
• ❌ Treating repeated automatic remediation as a success metric rather than as evidence the baseline or the operational need is wrong.
• ❌ Allowing adaptive limits without a hard ceiling, which accommodates an attack as readily as growth.

---

Practice Maturity Questions

Level 1:

1. Is a hardening baseline published per data archetype as applicable configuration rather than prose, applied to at least 90% of production assets, and measured against the running environment rather than a checklist?
2. Are at least 90% of baseline controls in enforcing rather than audit mode, with audit-mode controls recorded as exceptions, and is conformance reported per control rather than as an aggregate that can conceal a missing hard control? For Data, the assessor should be shown the retrieval authorization and log-redaction configuration as applied.
3. Does every production asset have per-consumer retrieval quotas with a declared behaviour at the quota configured with an explicit declared at-limit behaviour, and does every baseline exception carry an owner, compensating control, approver and expiry?

Level 2:

1. Is a baseline variant published per tier with its reasoning and derived automatically from the inventory, rather than one baseline with per-asset exceptions that resolve toward the lighter option? Evidence this in the Data domain against the retrieval authorization and log-redaction configuration as applied.
2. Are at least 95% of Critical-tier assets under continuous drift detection with a 3 business day detection window, with detections routed into the shared backlog rather than a dashboard, and is standing human access to Critical-tier environments zero? For Data, the assessor should be shown the retrieval authorization and log-redaction configuration as applied.
3. Has every Critical-tier asset's at-limit behaviour been exercised within 12 months, and do cost-driven changes to limits, logging, retention or enforcement mode require approval as material changes? In Data, ask to see the retrieval authorization and log-redaction configuration as applied.

Level 3:

1. Are at least 95% of new assets provisioned already conformant with non-conformance windows at or under one hour, and is provisioning of non-conformant Critical-tier assets blocked? Evidence this in the Data domain against the retrieval authorization and log-redaction configuration as applied.
2. Are the drift classes eligible for automatic remediation enumerated explicitly with everything else alerting to a human, and is every automated action logged with change, reversion and reason and reviewable rather than silent? For Data, the assessor should be shown the retrieval authorization and log-redaction configuration as applied.
3. Is repeated automatic remediation of the same control treated as a signal routed to baseline or operational review, and do adaptive limits operate within a governed hard ceiling requiring human approval to cross? In Data, ask to see the retrieval authorization and log-redaction configuration as applied.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Is there a standard secure configuration for your AI systems?
• Are your AI security controls enforcing, or only logging?
• Does any AI system have a limit that would actually stop it?

Level 2:

• Would you know within days if an AI security control was relaxed?
• Does anyone hold standing admin access to your AI environments?
• Has anyone tested what happens when an AI system hits its limit?

Level 3:

• Is a new AI asset hardened before it exists, or afterwards?
• Does your environment fix a disabled control on its own?
• Can an adaptive limit grow without anyone approving it?

---

Tracking

Level 1 — Jira Epic, labels haiamm-eh-data-l1, haiamm-operations

• Done when: Baseline application at or above 90% of production assets with enforcing-mode share at or above 90% and every asset carrying a declared consumption limit, sustained two consecutive quarters.
• Git artifacts: platform/hardening/data/, platform/hardening/conformance.json, platform/hardening/exceptions.json
• Git signal: conformance.json is regenerated by the monthly scan against the running environment rather than hand-maintained, and exceptions.json is checked by CI for entries past expiry.
• CI check: hardening-conformance-scan

Level 2 — Jira Epic, labels haiamm-eh-data-l2, haiamm-operations

• Done when: Critical-tier drift detection coverage at or above 95% with detection within 3 business days, zero standing access, and every Critical-tier limit exercised within 12 months, sustained two quarters.
• Git artifacts: platform/hardening/baselines/, platform/hardening/drift-coverage.json, platform/limit-exercise-log.json
• Git signal: Baseline variants are versioned per tier in the platform repository, and drift-coverage.json is regenerated from the detection platform against the inventory.
• CI check: hardening-drift-coverage

Level 3 — Jira Epic, labels haiamm-eh-data-l3, haiamm-operations

• Done when: New assets provisioned conformant at or above 95% with non-conformance windows within one hour and every adaptive limit bounded by a governed ceiling, sustained two consecutive quarters.
• Git artifacts: platform/hardening/modules/, platform/remediation-scope.json, platform/limit-ceilings.json
• Git signal: remediation-scope.json enumerates the automatable drift classes and is reviewed quarterly, and limit-ceilings.json records an approver per ceiling change.
• CI check: provisioning-conformance-gate

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	RA	AML.T0018, AML.T0024, AML.T0025, AML.T0029	LLM02, LLM04, LLM08, LLM10	EU AI Act Art. 15; GDPR Art. 32; ISO/IEC 27001 A.8.9; ISO/IEC 42001 8.1; NIST AI RMF MANAGE 2.2
L2	RA	AML.T0018, AML.T0024, AML.T0025, AML.T0029	LLM02, LLM04, LLM08, LLM10	EU AI Act Art. 15; GDPR Art. 32; ISO/IEC 27001 A.8.9; ISO/IEC 42001 8.1; NIST AI RMF MANAGE 2.2
L3	RA	AML.T0018, AML.T0024, AML.T0025, AML.T0029	LLM02, LLM04, LLM08, LLM10	EU AI Act Art. 15; EU AI Act Art. 72; GDPR Art. 32; ISO/IEC 27001 A.8.9; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Environment Hardening (EH) / Domain: Data