Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.
v3.0 questionnaire. Source of truth:
../practices/EH-Processes-OnePager.md. Canonical subject and through-lines:../HAIAMM-v3.0-Framing.md§8.
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
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%)
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.
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: ___
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: ___
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: ___
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.
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: ___
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: ___
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: ___
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.
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: ___
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: ___
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: ___
| 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
Instructions: