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

---

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

**Practice:** Environment Hardening (EH)
**Domain:** Processes
**Purpose:** Assess organizational maturity in hardening the workflow-definition, HITL, disclosure, data-flow, and audit envelopes for AI/HAI-embedded business workflows

---

## 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 workflow-definition, HITL, disclosure, data-flow, and audit envelopes for all AI/HAI-embedded business workflows so each workflow executes within a governed perimeter and unsanctioned modifications or AI insertions are observable.

---

### Question 1: Workflow-Definition and Audit Envelope Hardening

**Q1.1:** Are workflow definitions for all seven AI/HAI process archetypes stored in version control with signed commits or equivalent integrity attestation, with peer review enforced for all AI-step changes, DR re-review triggered for material changes, and immutable decision logs active for Critical/High-tier workflows?

**Evidence Required:**
- [ ] Version-control and signed-commit (or equivalent integrity attestation) configuration for all seven archetypes (decision pipeline, customer-facing flow, HITL chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow)
- [ ] BPM runtime enforcement records confirming definitions are loaded only after signature verification at deploy time, unsigned definitions rejected at the deploy gate
- [ ] Change review policy and enforcement records, AI-step modifications require peer review (at minimum one reviewer other than the author) before merge; change log entry produced for each version promoted to production
- [ ] DR re-review gate configuration for material changes (model, threshold, HITL configuration, data-routing rule, or disclosure placement changes); fast-lane checklist for immaterial changes
- [ ] Rollback playbook for each workflow in inventory, last-known-good definition version, trigger criteria, named rollback authority, rollback time target (Critical ≤1h, High ≤4h); tested at least annually
- [ ] Immutable decision log configuration (write-once or append-only storage) for all AI/HAI outputs affecting business outcomes; application-tier service accounts cannot delete or overwrite decision log records

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI-embedded workflows in production with a signed, version-controlled workflow definition | ___% | ___% | 100% | ☐ | |
| % AI-step workflow changes with peer review before merge | ___% | ___% | 100% | ☐ | |
| Material workflow changes with DR re-review gate completed before production promotion | ___% | ___% | 100% | ☐ | |
| % Critical/High-tier workflows with immutable decision logs active (append-only or write-once storage) | ___% | ___% | 100% for Critical/High-tier | ☐ | |

**Metric Collection Guidance:**
- **Signed definition coverage**: Audit BPM platform / VCS against SM-Processes inventory; count workflows with signed, version-controlled definitions active in production. Source: BPM platform / VCS audit × SM inventory
- **Peer review coverage**: Review pull-request history for AI-step changes; count those with at least one non-author reviewer. Source: VCS audit
- **DR re-review gate adherence**: Count material workflow changes with a DR decision record on file before production promotion / total material changes. Source: DR decision log × change records
- **Decision log coverage**: Audit log storage configuration for Critical/High-tier workflows; confirm write-once or append-only backend. Source: audit-log 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 signed definitions, peer review, or immutable logs)

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

---

### Question 2: HITL and Override-Authority Envelope Hardening

**Q2.1:** Do all HITL review interfaces require SSO + MFA with individually attributable reviewer identities, with reviewer rotation and load balancing enforced for Critical/High-tier workflows, reviewer-capacity monitoring active with SLA-at-risk alerting, and override-authority enforcement blocking auto-override?

**Evidence Required:**
- [ ] IdP configuration records showing SSO/SAML/OIDC enforcement on all HITL review interfaces (BPM task lists, review queues, decision-approval UIs), local-account access disabled; shared review accounts are a blocking finding
- [ ] Reviewer identity resolution configuration, each review-queue action is attributed to the authenticated identity from the SSO session; anonymous or role-only attribution is a blocking finding for Critical/High-tier
- [ ] Reviewer rotation and load-balancing configuration for Critical/High-tier decision pipelines and approval workflows, maximum reviewer proportion per rolling 7-day window documented and enforced in workflow definition; configuration version-controlled
- [ ] Reviewer-capacity monitoring configuration: queue depth and estimated SLA breach time tracked per HITL-gated step; SLA-at-risk alert firing at configurable threshold (≤4h for Critical-tier); escalation alert routes to workflow owner and IM-Processes backlog
- [ ] Override-authority enforcement configuration: only authorized override-role reviewers can override AI recommendations at each step; bulk-override or auto-override actions blocked at the review-UI layer
- [ ] Tamper-evident override audit trail configuration: reviewer identity, override direction, rationale (mandatory for Critical/High-tier), timestamp, decision context logged; append-only log with hash chain or equivalent

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % HITL review UIs requiring SSO + MFA (no local-account or shared-account access) | ___% | ___% | 100% | ☐ | |
| % Critical/High-tier workflows with reviewer-capacity monitoring and SLA-at-risk alerting active | ___% | ___% | 100% | ☐ | |
| Reviewer-capacity SLA-at-risk alerts acknowledged within 2h for Critical-tier | ___% | ___% | 100% within 2h for Critical-tier | ☐ | |
| % Critical/High-tier workflows with tamper-evident override audit trail active | ___% | ___% | 100% for Critical/High-tier | ☐ | |

**Metric Collection Guidance:**
- **SSO + MFA coverage**: Audit IdP configuration for each HITL review UI entry; verify SSO is the only auth path and MFA is enforced. Source: IdP audit × workflow inventory
- **Capacity monitoring coverage**: Review monitoring configuration for Critical/High-tier HITL steps; confirm queue-depth and SLA-breach-time metrics are tracked. Source: monitoring configuration audit
- **Alert response time SLA**: Count SLA-at-risk alerts acknowledged within 2h for Critical-tier / total alerts. Source: alert management system
- **Override audit trail coverage**: Review audit log configuration for Critical/High-tier workflows; confirm tamper-evident backend and required fields are populated on override events. Source: audit-log 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 SSO on HITL UIs, no capacity monitoring, or no tamper-evident audit)

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

---

### Question 3: Disclosure and Data-Flow Envelope Hardening

**Q3.1:** Are Art. 50 disclosure templates managed in a central registry with disclosure-suppression detection active, is classification-aware data-flow routing enforced at workflow ingress preventing regulated PII from reaching uncleared AI steps, and is a PII redaction layer active where required?

**Evidence Required:**
- [ ] Central disclosure template registry configuration: all EU AI Act Art. 50 disclosure UX templates managed in registry; product teams consume templates from registry; no product team can modify or suppress a template without a governed update process (change request, Privacy/Legal review, registry version bump)
- [ ] Disclosure suppression prevention: A/B tests involving a disclosure component registered with Privacy/Legal before launch; A/B-test traffic splits involving disclosure variants logged; metric alert if disclosure-present variant traffic share falls below policy-defined minimum
- [ ] Affected-persons-rights SLA monitoring for GDPR Art. 22 workflows: contestation-response SLA monitored per workflow; SLA-at-risk escalation alert fires; response completion events logged in audit trail
- [ ] Classification-aware data-flow routing configuration at workflow ingress: data classification labels inherited from upstream system; BPM engine or inline classification gateway enforces routing, Confidential+ data routed only to AI steps cleared for that classification; routing decisions logged as classification-routing events
- [ ] PII redaction or tokenization layer at workflow ingress for customer-facing flows and decision pipelines receiving regulated PII from external sources; redaction rule application logged; workflows passing raw regulated PII to AI steps without Privacy/Legal sign-off are blocking findings
- [ ] Per-tenant workflow isolation configuration for customer-facing flows serving multiple tenants: execution contexts isolated per tenant; verified by ST-Processes isolation tests

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Art. 50 disclosure templates managed in central registry (no unregistered deployed disclosure templates) | ___% | ___% | 100% | ☐ | |
| % workflows subject to GDPR Art. 22 with tamper-evident override audit trail and affected-persons-rights SLA monitoring active | ___% | ___% | 100% for Critical/High-tier | ☐ | |
| Classification-aware routing enforced at workflow ingress for all workflows processing regulated PII | ___% | ___% | 100% | ☐ | |
| Disclosure suppression incidents (Art. 50 disclosure suppressed by unregistered A/B test or unreviewed product change) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **Template registry coverage**: Audit deployed disclosure template implementations against the central registry; count unregistered templates. Source: template registry × deployed-UI audit
- **GDPR Art. 22 control coverage**: Review audit log and SLA monitoring configuration for workflows tagged as Art. 22 subject. Source: workflow configuration audit
- **Classification-aware routing coverage**: Audit BPM engine or gateway routing rules for workflows processing regulated PII; verify classification check is enforced at ingress. Source: workflow configuration review
- **Disclosure suppression incidents**: Count incidents where an Art. 50 disclosure was suppressed by an unregistered A/B test or unreviewed change. Source: IM-Processes incident log

**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 central disclosure registry, no classification-aware routing, or no PII redaction)

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

---

## Maturity Level 2

**Objective:** Calibrate hardening depth per SM-Processes L2 risk tier; apply dedicated reviewer pools and JIT access for workflow changes on Critical-tier workflows; enforce tamper-evident log integrity verification and enhanced disclosure monitoring at the tier level.

---

### Question 4: JIT Access for Workflow Changes and Dedicated Reviewer Pools

**Q2.1:** Are 100% of Critical-tier workflow-definition changes executed under JIT access (≤4-hour time-limited, approval-gated, automatic revocation at expiry) with no standing write access, and are dedicated reviewer pools operational for all Critical-tier HITL steps with capacity monitoring and cross-tier queue-bleed enforcement?

**Evidence Required:**
- [ ] JIT access tooling configuration for Critical-tier BPM definition changes: scoped to specific workflow definition, time-limited (≤4h), approval-gated (workflow owner or security lead), automatic revocation at expiry; change log records the JIT access grant ID alongside each definition version
- [ ] Standing developer write access to Critical-tier BPM definitions deprecated, confirmation that API endpoints also enforce JIT (not only UI)
- [ ] Dedicated reviewer pool configuration for Critical-tier decision pipelines, HITL chains, and approval workflows: pool membership declared in workflow definition (version-controlled), exclusively assigned to Critical-tier items, capacity continuously monitored
- [ ] Cross-tier queue-bleed prevention: Critical-tier items served only to reviewers in the designated pool; cross-tier bleed (Critical items reviewed by non-pool reviewer) is a compliance finding
- [ ] Enhanced override-authority enforcement for Critical-tier: override limited to named individuals in a defined role; overrides without rationale field automatically escalated to workflow owner within 1 hour; repeated no-rationale overrides trigger pool audit
- [ ] Pool-size review trigger when capacity utilization consistently exceeds 80% or when SM-Processes tier-treatment matrix changes

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier workflow-definition changes using JIT access (no standing write permissions) | ___% | ___% | 100% | ☐ | |
| % Critical-tier HITL steps with dedicated reviewer pools and capacity monitoring | ___% | ___% | 100% | ☐ | |
| Cross-tier queue-bleed incidents (Critical items reviewed by non-pool reviewer) | ___ | ___ | 0 | ☐ | |
| HITL rubber-stamping rate for Critical-tier (reviewer-decision-matches-AI-recommendation rate) trend | ___% | ___% | trending down | ☐ | |

**Metric Collection Guidance:**
- **JIT access coverage**: Audit IAM/BPM access log for Critical-tier definition changes; verify all changes use JIT grants, not standing tokens. Source: IAM / BPM access log × change log
- **Dedicated pool coverage**: Review workflow configuration records for Critical-tier HITL steps; confirm dedicated pool with capacity monitoring. Source: workflow configuration audit × SM inventory
- **Cross-tier queue-bleed count**: Query review queue logs for Critical-tier items reviewed by non-pool reviewers. Source: review queue telemetry
- **Rubber-stamping rate**: Compute rate at which reviewer decisions match AI recommendations for Critical-tier items over rolling 30-day window. Source: HITL decision log

**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 JIT access for workflow changes or dedicated reviewer pools)

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

---

### Question 5: Tamper-Evident Log Integrity Verification and Enhanced Disclosure Monitoring

**Q2.2:** Are Critical-tier decision log integrity verification jobs running at least weekly, with any hash mismatch or log gap an immediate IM-Processes finding, and is a per-execution disclosure completion metric active for Critical-tier customer-facing flows maintaining 100% completion with deviations routing to IM-Processes within 4 hours?

**Evidence Required:**
- [ ] Write-once backend configuration for Critical-tier decision logs (object storage with Object Lock, WORM-capable log platform, or equivalent)
- [ ] Scheduled integrity verification job configuration running at least weekly, verifies the log chain hash for each Critical-tier workflow's decision log; last successful verification timestamp is a compliance-evidence artifact
- [ ] IM-Processes finding creation triggered immediately on hash mismatch or detected log gap, alert routing confirmed
- [ ] Per-execution disclosure completeness metric instrumentation: workflow execution engine emits a disclosure-completion event (disclosure step reached yes/no, template version rendered, timestamp, execution-ID) for each Critical-tier customer-facing flow execution
- [ ] Metric aggregation producing per-workflow disclosure completion rate; rate below 100% in any rolling 24h window triggers IM-Processes finding within 4 hours
- [ ] Affected-persons-rights escalation path for Critical-tier GDPR Art. 22 workflows: named Privacy/Legal owner, SLA documented in workflow configuration, escalation alert at 75% of SLA elapsed; responses logged in tamper-evident audit trail

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Critical-tier decision log integrity verification, last successful check within 7 days | ___% | ___% | 100% of Critical-tier workflows | ☐ | |
| Integrity verification failures immediately triggering IM-Processes findings | ___% | ___% | 100% | ☐ | |
| Per-execution disclosure completion rate for Critical-tier customer-facing flows | ___% | ___% | 100% per 24h rolling window | ☐ | |
| Disclosure completion deviations routing to IM-Processes within 4 hours | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Integrity verification cadence**: Check last successful integrity verification timestamp for each Critical-tier workflow's decision log; confirm within 7 days. Source: integrity-check telemetry
- **Failure-to-IM routing**: Count integrity verification failures with an IM-Processes finding created immediately / total failures. Source: integrity-check telemetry × IM-Processes backlog
- **Disclosure completion rate**: Aggregate disclosure-completion events per Critical-tier customer-facing workflow per rolling 24h window. Source: disclosure-completion metric
- **Deviation routing SLA**: Count disclosure completion rate deviations with IM-Processes finding created within 4 hours / total deviations. Source: disclosure-completion metric × IM-Processes backlog

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No log integrity verification or per-execution disclosure monitoring)

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

---

### Question 6: Tier-Hardening Matrix Enforcement and Per-Tenant Runtime Isolation

**Q2.3:** Is a tier-hardening matrix published and enforced at provisioning, with per-tenant runtime isolation operational for Critical-tier multi-tenant customer-facing flows confirmed by IR-Processes reviews and ST-Processes isolation tests, and are HITL rubber-stamping rates trending down after dedicated-pool and capacity-monitoring activation?

**Evidence Required:**
- [ ] Published tier-treatment matrix covering workflow-definition change access, reviewer pool depth, override authority, decision log storage, disclosure monitoring, data-flow classification routing, and per-tenant isolation per tier (Critical/High/Medium/Low)
- [ ] Provisioning-gate configuration enforcing tier hardening controls at workflow registration, not post-hoc after DR/IR finding; tier-change event triggers hardening-profile upgrade
- [ ] Per-tenant runtime context isolation for Critical-tier multi-tenant customer-facing flows: one tenant's input data, AI step context, and decision outputs not accessible to another tenant's execution context
- [ ] IR-Processes review records confirming per-tenant isolation for Critical-tier multi-tenant flows (annual minimum)
- [ ] ST-Processes isolation test wired into CI for Critical-tier multi-tenant flows, isolation regressions detected in CI, not only at annual review
- [ ] SM-Processes inventory records showing hardening status per tier for each workflow; tier-hardening gaps tracked as open IM-Processes findings

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier multi-tenant customer-facing flows with per-tenant runtime isolation confirmed (IR review + ST test) | ___% | ___% | 100% | ☐ | |
| % SM-Processes inventory workflow records with hardening status per tier populated | ___% | ___% | 100% | ☐ | |
| Tier-hardening matrix enforced at provisioning and on tier-change (not only at initial provisioning) | ☐ yes / ☐ no |, | yes | ☐ | |
| Zero disclosure-suppression incidents for Critical-tier customer-facing flows after per-execution completeness monitoring activated | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **Per-tenant isolation coverage**: Review IR-Processes findings for Critical-tier multi-tenant flows; confirm ST isolation test passes in CI. Source: IR findings × ST test results
- **Inventory hardening status**: Review SM-Processes inventory records; count workflows with hardening-status field populated per tier. Source: SM-Processes inventory
- **Tier-change enforcement**: Verify provisioning pipeline watches for tier-change events in SM-Processes and re-applies hardening profile. Source: provisioning pipeline configuration
- **Disclosure suppression incidents**: Count incidents where a Critical-tier disclosure was suppressed after per-execution monitoring was activated. Source: IM-Processes incident log

**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 tier-hardening matrix or per-tenant runtime isolation)

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

---

## Maturity Level 3

**Objective:** Express all EH-Processes controls as workflow-as-code IaC modules; implement adaptive tightening driven by ML-Processes detection signals and IM-Processes incidents; and contribute AI/HAI workflow hardening baselines to OECD AI, ISO/IEC 42005, and sector ISACs.

---

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

**Q3.1:** Are all EH-Processes controls expressed as version-controlled IaC modules, workflow-definition integrity, HITL configuration, disclosure-template registry, classification-routing policy, JIT access, log-integrity, and per-tenant isolation, with drift detection on a scheduled cadence and ≥70% of low-risk drift auto-remediated?

**Evidence Required:**
- [ ] Workflow-definition integrity IaC module: BPM-as-code templates encoding signing policy, peer-review gate configuration, and DR re-review gate rule per archetype and tier; consumed by BPM platform CI/CD pipeline
- [ ] HITL configuration IaC module: reviewer-pool membership, capacity-monitoring thresholds, load-balancing rules, SLA-at-risk alert configuration expressed as code; reviewer-pool changes require a code review
- [ ] Disclosure-template registry IaC module: template IDs, version history, permitted deployment targets, A/B-test registration requirements encoded as IaC; deployed template inventory automatically reconciled against registry
- [ ] Classification-routing IaC module: classification-aware routing rules, PII-redaction ingress configuration, and data-class-to-AI-step clearance mapping as policy-as-code
- [ ] JIT access IaC module: JIT access policy for Critical-tier workflow-definition changes (scope, time limit, approver roles, automatic revocation) as IAM policy-as-code
- [ ] Log-integrity and per-tenant isolation IaC modules: write-once storage configuration, integrity-verification schedule, hash-chain parameters, alert thresholds; tenant-context isolation enforcement rules with test suite
- [ ] Drift-detection pipeline on scheduled cadence; low-risk drift auto-remediated; high-risk drift (JIT policy removed, disclosure template suppressed, log integrity disabled) triggers human-review alert within 2 business days + IM-Processes finding

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % EH-Processes controls expressed as IaC (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-embedded workflows auto-provisioned with tier-appropriate hardening within 24h of SM-Processes registration | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **IaC coverage**: Count EH-Processes controls with authoritative IaC (deployed state = IaC spec, not stub) / total EH-Processes 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 within 2 business days / total high-risk findings. Source: policy change log × IM-Processes backlog
- **Auto-provisioning SLA**: Compare SM-Processes registration timestamps against IaC provisioning completion within 24h. Source: inventory × IaC provisioning telemetry

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No IaC for EH-Processes controls)

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

---

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

**Q3.2:** Is an adaptive-policy pipeline operational, with ML-Processes detections (rubber-stamp HITL, disclosure suppression, shadow-AI-in-process) and IM-Processes incident patterns generating human-approved tightening proposals on a tracked cadence, with every change traceable to a source signal and affected workflow teams notified within 24 hours?

**Evidence Required:**
- [ ] Adaptive-tightening pipeline wiring ML-Processes signals: rubber-stamp HITL (reviewer-matches-AI ≥98% on Critical-tier) → dedicated-reviewer-pool audit + capacity-increase proposal; disclosure-suppression detection → per-execution alerting threshold tightening; shadow-AI-in-process (new AI step not in inventory) → JIT access tightening + SM-Processes intake alert
- [ ] Adaptive-tightening pipeline wiring IM-Processes post-incident review records: hardening gap → IaC module update proposal; HITL failure → reviewer-pool structure review proposal; log tampering → log-integrity verification frequency increase proposal
- [ ] Human-approval gate for all proposals (workflow security lead approval before deploy)
- [ ] Machine-readable change log records with source signal (ML detection trend ID or IM incident ID), approval record, downstream notification timestamp
- [ ] Feedback loop to TA-Processes (new threat entry) and SR-Processes (new requirements-pack item) for changes reflecting new workflow attack patterns
- [ ] Adaptive-policy pipeline freshness monitoring, ML-Processes and IM-Processes signal feeds checked weekly; stale feeds (>7 days without processed event) flagged

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

**Metric Collection Guidance:**
- **Traceable changes**: Count policy changes in change log with valid source signal reference per quarter. Source: policy change log
- **Human-approval rate**: Count proposals deployed with approval record / total proposals deployed. Source: policy change log
- **Notification SLA**: Count tightening changes with workflow team notification within 24h / total. Source: notification log
- **Signal feed freshness**: Check last-processed timestamp for each ML-Processes and IM-Processes feed. Source: pipeline monitoring

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No adaptive-policy pipeline for EH-Processes)

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

---

### Question 9: Industry AI/HAI Workflow Hardening Baseline Contributions

**Q3.3:** Does the program contribute ≥2 AI/HAI workflow hardening baselines per year to industry bodies, OECD AI, ISO/IEC 42005, CSA AI Safety Initiative, or sector ISACs, with documented adoption and baselines maintained current with internal practice?

**Evidence Required:**
- [ ] Contribution records showing ≥2 substantive submissions per year to OECD AI governance working groups, ISO/IEC 42005 AI incident management, CSA AI Safety Initiative, or sector ISACs, workflow-definition integrity controls, HITL operational controls, disclosure governance patterns
- [ ] Evidence of adoption or citation of contributed baselines by the recipient body
- [ ] Maintenance records confirming contributions are updated when internal practice advances, not published once and left to diverge
- [ ] Auto-provisioning trigger configuration: SM-Processes registration event fires IaC provisioning workflow within 24 hours; tier-change triggers hardening-profile upgrade using current (not cached) tier
- [ ] Evidence that HITL failure rate on Critical-tier is lower on IaC-encoded workflow deployments than on hand-configured workflows (rolling 12-month comparison)
- [ ] Quarterly adaptive-policy change log traceable to ML-Processes detections and IM-Processes incident patterns

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry AI/HAI workflow hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | |
| New AI/HAI-embedded workflows auto-provisioned with tier-appropriate hardening within 24h of SM-Processes registration | ___% | ___% | 100% | ☐ | |
| Contributed baselines maintained current with internal practice (not published once and diverged) | ☐ yes / ☐ no |, | yes | ☐ | |
| HITL failure rate on IaC-encoded deployments vs. hand-configured workflows (rolling 12-month) | IaC: ___% / hand: ___% |, | IaC lower | ☐ | |

**Metric Collection Guidance:**
- **Contribution count**: Count published contributions with named recipient body and contribution artifact per calendar year. Source: contribution log
- **Auto-provisioning SLA**: Compare SM-Processes registration timestamps against IaC provisioning completion within 24h. 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
- **HITL failure rate comparison**: Compare Critical-tier rubber-stamping rate (or SLA breach rate) for IaC-encoded vs. hand-configured workflows over rolling 12 months. Source: HITL decision log × workflow configuration records

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

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

---

## Summary Scorecard

| Level | Question | Score (0.0 / 0.33 / 0.67 / 1.0) |
|-------|----------|----------------------------------|
| L1 | Q1: Workflow-Definition and Audit Envelope | ___ |
| L1 | Q2: HITL and Override-Authority Envelope | ___ |
| L1 | Q3: Disclosure and Data-Flow Envelope | ___ |
| L2 | Q4: JIT Access for Workflow Changes and Dedicated Reviewer Pools | ___ |
| L2 | Q5: Tamper-Evident Log Integrity and Enhanced Disclosure Monitoring | ___ |
| L2 | Q6: Tier-Hardening Matrix and Per-Tenant Runtime Isolation | ___ |
| L3 | Q7: Hardening-as-Code IaC Modules | ___ |
| L3 | Q8: Adaptive Policy Tightening | ___ |
| L3 | Q9: Industry Workflow Hardening 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:** Processes
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai