Implementation Review (IR) - Infrastructure Assessment

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

Implementation Review (IR) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Implementation Review (IR) Domain: Infrastructure Purpose: Assess organizational maturity in verifying that the actual configuration of AI/HAI infrastructure matches the design approved at DR, and stays there as components evolve. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

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

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 metrics meet targets
0.0	Not Implemented	No evidence of practice

Level Score = Average of the three question scores at that level Overall Score = Weighted average across all levels achieved

Maturity Level 1

Objective: Run per-archetype implementation reviews at go-live, annually, and on material change, verifying deployed configuration matches the SA-Infrastructure pattern, the DR decision, and that the SR-Infrastructure REM evidence is current

At this level, the gap between approved design and running infrastructure is systematically checked at the moments it matters most. Every review produces findings with severity tags, named owners, and SLA-bound resolution dates.

Question 1: Per-Archetype Infrastructure IR Checklist

Q1.1: Is there a published, per-archetype IR checklist, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), covering IaC-state-matches-pattern, config-matches-DR, SR REM evidence currency, logging-event production, and per-tenant isolation confirmation?

Evidence Required: - [ ] Published checklist per SM-Infrastructure archetype on file and linked from the SM-Infrastructure inventory (inference endpoint, model registry, GPU/accelerator fleet, orchestrator/control plane, vector-store, AI-specific CI/CD, feature store) - [ ] GPU fleet checklist explicitly requires a residual-state-clearing test record (job A on GPU node, job B on same node, verify job A's memory inaccessible to job B) and a classification-aware scheduling probe - [ ] Inference endpoint checklist requires mTLS confirmation, per-tenant rate-limit confirmation, signed-artifact enforcement verification, and PII-redaction-at-logging test (synthetic PII-containing prompt; PII absent from log output) - [ ] Model-registry checklist verifies signed-artifacts-only policy (attempt to push unsigned artifact, rejection confirmed) and lineage-required policy (attempt to promote without lineage, rejection confirmed) - [ ] IaC plan-vs-apply state reviewed at each IR: Terraform / Pulumi planned vs. applied state compared against the DR-approved baseline; deviations documented as findings with severity tags - [ ] Per-tenant isolation verified by a cross-tenant probe (not only by reviewing the IaC module description): test confirms one tenant cannot access another's data, compute, or model artifacts through the component

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI infrastructure components with a go-live IR record	___%	___%	100%	☐	SM-Infrastructure inventory × IR records
% active AI/HAI infrastructure components with a current-year IR record	___%	___%	≥90%	☐	SM-Infrastructure inventory × IR records
Critical / blocker findings open at go-live	___	___	0	☐	Findings backlog
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - Go-live IR coverage: count components in SM-Infrastructure inventory with a linked IR record dated at or before production cutover divided by total components entering production. Formula: components_with_golive_IR / total_components_in_production × 100 - Current-year IR coverage: count components with an IR record dated within the last 12 months. Source: SM-Infrastructure inventory last-IR-date field - Blocker findings at go-live: count Critical/blocker findings open on the go-live date. Source: IM-Infrastructure findings history - High finding closure time: median calendar days from finding-opened to evidence-linked finding-closed. Source: IM-Infrastructure backlog timestamps

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 per-archetype checklist published)

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 2: Review Triggers and IaC Drift Sources

Q1.2: Do 100% of new AI/HAI infrastructure components going to production in the last 90 days carry a go-live IR record, and do ≥90% of all active components carry a current-year IR record, with material-change triggers wired to SM-Infrastructure inventory events?

Evidence Required: - [ ] Go-live IR records on file for all infrastructure components entering production in the last 90 days; IaC plan output and cloud-provider API responses confirm IR was completed before production cutover - [ ] Material-change trigger wired to SM-Infrastructure inventory: GPU scheduling policy changes, new tenants on shared components, rate-limit policy changes, workload identity changes, encryption key rotation to a new mechanism, and model version or signing policy changes generate a review-due alert within 5 business days - [ ] Cloud-provider API drift sources reviewed at each IR: AWS Config / GCP Asset Inventory / Azure Policy state compared against DR-approved baseline; deviations documented as findings - [ ] Kubernetes / orchestrator API drift reviewed: deployment manifest drift vs. DR-approved manifests compared and deviations documented - [ ] Model-registry events reviewed: model version changes and signing policy changes since the last IR confirmed and compared against SM-Infrastructure inventory record - [ ] Annual review calendar populated from the SM-Infrastructure inventory with components nearing review-due date visible at least 30 days in advance

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI infrastructure components with a go-live IR record	___%	___%	100%	☐	SM-Infrastructure inventory × IR records
% active AI/HAI infrastructure components with a current-year IR record	___%	___%	≥90%	☐	SM-Infrastructure inventory × IR records
% material changes to production components that trigger an IR before the change ships	___%	___%	100%	☐	SM-Infrastructure change events × IR records
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - Material-change IR trigger rate: cross-reference SM-Infrastructure inventory material-change events against IR records created within 5 business days of each event - Current-year IR coverage: count components with an IR record dated within the last 365 days divided by total active components. Source: SM-Infrastructure inventory last-IR-date - Cloud-provider API drift detection rate: % of IRs where cloud-provider API state was actively queried (not just IaC text reviewed). Source: IR evidence records method field - High closure time: median days from finding-opened to evidence-linked closure. Source: IM-Infrastructure timestamps

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 3: Findings Tracking and SR-Infrastructure REM Loop

Q1.3: Are findings severity-tagged and tracked in IM-Infrastructure with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Infrastructure REM row update before the finding is closed?

Evidence Required: - [ ] Findings backlog in IM-Infrastructure showing all IR findings with severity tag (Critical / High / Medium / Low), named owner (not "the platform team"), SLA-bound closure date, and linked after-fix evidence artifact (IaC plan output, probe result, screenshot) - [ ] SR-Infrastructure REM update loop active: IR findings that reveal stale or inaccurate REM evidence have a linked REM row update on file before the finding is closed - [ ] Severity calibration consistent: Critical findings include GPU node sharing Critical-tier and non-Critical workloads without residual-state-clearing, rate-limit removal from an inference endpoint, and signing policy disabled on the model registry, not downgraded to Medium - [ ] CI/CD job parameter drift sources reviewed: build-job parameters (model versions, pipeline signing, eval-gate settings) compared against the DR-approved specification for components reviewed in the last 90 days - [ ] Findings-aging dashboard reviewed at least monthly by the program sponsor: meeting record or dashboard screenshot on file - [ ] Workload identity and encryption key placement verified via cloud-provider IAM API and KMS API (not assumed from IaC text alone): IAM API response and KMS API response on file with IR record

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI infrastructure components with a go-live IR record	___%	___%	100%	☐	SM-Infrastructure inventory × IR records
% active AI/HAI infrastructure components with a current-year IR record	___%	___%	≥90%	☐	SM-Infrastructure inventory × IR records
Critical / blocker findings open at go-live	___	___	0	☐	Findings backlog
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - REM update loop rate: count IR findings where the closure is linked to an SR-Infrastructure REM row update vs. total IR findings that identified stale REM evidence. Source: IM-Infrastructure × SR-Infrastructure REM cross-reference - Named-owner coverage: count findings with a named individual as owner divided by total open findings. Source: IM-Infrastructure - SLA adherence by severity: % of High findings closed within 7 days; % of Critical findings closed before go-live. Source: IM-Infrastructure timestamps - Findings-aging review cadence: confirm monthly review via calendar record or dashboard export. Source: program sponsor review log

Evidence Location: _________

Validation Date: _________

Notes: _______

Maturity Level 2

Objective: Detect configuration drift continuously for Critical and High-tier components via IaC drift-detection tooling, cloud-provider Config Rules, admission-controller checks, model-registry webhooks, and vendor admin API probes; calibrate IR cadence per SM-Infrastructure tier

At this level, implementation review becomes a continuous signal. IaC drift tooling, cloud Config Rules, admission-controller policy checks, model-registry webhooks, and vendor admin API probes are all wired to automated detection.

Question 4: Continuous Infrastructure Drift Detection

Q2.1: Are ≥90% of Critical-tier AI/HAI infrastructure components under continuous drift detection, via IaC drift-detection tooling, cloud-provider Config Rules / asset-inventory APIs, admission-controller policy checks, model-registry webhooks, and CI/CD parameter monitoring, with median detection latency ≤7 days?

Evidence Required: - [ ] IaC drift-detection tooling active for Critical and High-tier components: Terraform Cloud / Atlantis / Pulumi state diff runs on a defined cadence; configuration deviations from the approved IaC module auto-open IR findings - [ ] Cloud-provider Config Rules / asset-inventory APIs continuously checking: AWS Config Rules, GCP Asset Inventory, or Azure Policy continuously monitoring resource configurations against the DR-approved baseline; violations auto-open IR findings with severity tags - [ ] Admission-controller policy checks enforcing SA-Infrastructure reference pattern controls at the Kubernetes API level: Kyverno / Gatekeeper policies enforce workload identity annotations, image signing, and resource quota policies; policy violations auto-open IR findings - [ ] Model-registry webhooks active: model version promotions, signing policy changes, and lineage-exemption events trigger an IR re-review gate; a model promotion without a corresponding DR material-change review generates a Critical finding automatically - [ ] Vendor admin API recurrent probes for managed AI infrastructure components (Amazon Bedrock fleet configuration, Vertex AI model deployment settings, Azure OpenAI deployment configurations): recurrent probes verify rate-limit settings, signing policies, and logging configurations match the DR-approved baseline; delta from the previous probe opens an IR finding - [ ] Drift-detection pipeline health monitored: % Critical components with a fresh signal in the last 7 days; on-call alert configured for >48 hours of feed silence; alert test record on file

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components under continuous drift detection (IaC, cloud Config Rules, admission-controller, model-registry webhooks)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% Critical/High-tier components with vendor admin API probes current (within defined cadence)	___%	___%	≥80%	☐	Vendor API probing log
Tier-cadence adherence (% of components reviewed on their published cadence)	___%	___%	≥95%	☐	IR schedule × SM-Infrastructure inventory

Metric Collection Guidance: - Continuous drift detection coverage: count Critical-tier components with all four signal sources active (IaC drift, cloud Config Rules, admission-controller, model-registry webhooks) divided by total Critical-tier components. Source: drift-detection pipeline configuration registry - Drift detection latency: median time from change-event timestamp to IR-finding-opened timestamp. Source: IR telemetry × IM-Infrastructure - Vendor admin API probe coverage: count Critical/High-tier managed components with a vendor admin API probe result within the current probe cycle divided by total Critical/High-tier managed components. Source: vendor API probing log - Tier-cadence adherence: count components reviewed within their published cadence window. Source: IR schedule × SM-Infrastructure inventory last-IR-date

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 5: Vendor Admin API Probing and Tier-Calibrated Cadence

Q2.2: Are vendor admin API probes current for ≥80% of Critical/High-tier managed components on a monthly (Critical) and quarterly (High) cadence, and is tier-cadence adherence ≥95%?

Evidence Required: - [ ] Vendor admin API probe records on file for Critical/High-tier managed AI infrastructure components: Bedrock fleet configuration, Vertex AI model deployment settings, Azure OpenAI deployment configurations, rate-limit settings, signing policies, and logging configurations verified against DR-approved baseline - [ ] Probing cadence log showing Critical-tier probes monthly and High-tier quarterly, not one-time screenshots; delta from the previous probe documented with IR findings when settings changed - [ ] Delta findings on file: any setting change detected (rate-limit policy reset, signing enforcement changed, logging configuration altered) generated an IR finding with severity matching the security impact - [ ] Tier-cadence enforcement visible in SM-Infrastructure inventory: Critical-tier components flagged when no IR in the last 180 days; escalation to program sponsor automated and test record on file - [ ] IR backlog tier-aware: Critical-tier findings reported separately; no Critical-tier finding waiting behind Low-tier queue items - [ ] Vendor API probing calendar maintained: missed probes tracked as process-metric failures with root cause and remediation on file

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components under continuous drift detection (IaC, cloud Config Rules, admission-controller, model-registry webhooks)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% Critical/High-tier components with vendor admin API probes current (within defined cadence)	___%	___%	≥80%	☐	Vendor API probing log
% Critical/High-tier components with boundary probes on record (current IR cycle)	___%	___%	100%	☐	IR records

Metric Collection Guidance: - Vendor admin API probe currency: count Critical/High-tier managed components with a probe result dated within the current probe cycle (≤30 days Critical, ≤90 days High) divided by total Critical/High-tier managed components. Source: vendor API probing log - Delta finding rate: count probe cycles where a setting change was detected and a finding was generated vs. total probe cycles. Source: probe log × IM-Infrastructure - Probe cadence compliance: count monthly Critical-tier probes completed on schedule vs. planned. Source: probing calendar - Tier-cadence adherence: % of components reviewed within their published cadence window. Source: SM-Infrastructure inventory last-IR-date × cadence policy

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 6: Per-Archetype Boundary Probing

Q2.3: Are 100% of Critical/High-tier infrastructure components covered by boundary probes in the current IR cycle, confirming cross-tenant isolation, signing enforcement, rate-limit enforcement, GPU residual-state-clearing, and pipeline-gate enforcement?

Evidence Required: - [ ] Inference endpoint boundary probe records: cross-tenant probe (tenant A credentials attempting to access tenant B's endpoint) confirmed rejected; unsigned-model-artifact serving probe confirmed rejected; PII-redaction-at-logging confirmed via synthetic PII-containing prompt - [ ] GPU fleet boundary probe records: residual-state-clearing test executed (job A on GPU node, job B on same node, job A's GPU memory confirmed inaccessible to job B); test date, test method, actual result, and reviewer on file within the current IR cycle - [ ] Orchestrator boundary probe records: unsigned workflow definition submission confirmed rejected; step-privilege-boundary test (invoking a resource from within one step that belongs to another step's principal scope) confirmed rejected - [ ] Vector-store boundary probe records: cross-tenant retrieval probe (query from tenant A matching tenant B's index) returned zero results or namespacing error; classification labels confirmed present and correct in query results - [ ] AI-CI/CD boundary probe records: unsigned pipeline submission confirmed rejected; model artifact promotion without a passing eval attestation confirmed blocked at the gate - [ ] Boundary probe failures documented as Critical findings for Critical-tier components and High findings for High-tier components; no downgraded severity

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components under continuous drift detection (IaC, cloud Config Rules, admission-controller, model-registry webhooks)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% Critical/High-tier components with vendor admin API probes current (within defined cadence)	___%	___%	≥80%	☐	Vendor API probing log
% Critical/High-tier components with boundary probes on record (current IR cycle)	___%	___%	100%	☐	IR records

Metric Collection Guidance: - Boundary probe coverage: count Critical/High-tier components with a complete boundary probe record in the current IR cycle divided by total Critical/High-tier components. Source: IR records - Boundary probe pass rate: % of boundary probes where all expected rejections were confirmed. Source: boundary probe records - GPU residual-state-clearing test coverage: % of Critical/High-tier GPU fleet components with a residual-state-clearing test record in the current IR cycle. Source: IR records - Tier-SLA breach rate: count Critical-tier findings exceeding SM-Infrastructure L2 tier-treatment matrix SLA divided by total Critical-tier findings. Source: IM-Infrastructure timestamps

Evidence Location: _________

Validation Date: _________

Notes: _______

Maturity Level 3

Objective: Continuous configuration attestation for Critical-tier components, daily attestation signal confirming IaC-pattern compliance and evidence freshness, automatic IM ticket on drift, and contribution to OpenSSF AI reference attestation schemas, CNCF AI working group, and OWASP LLM / Agentic Top 10 infrastructure patterns

At this level, Critical-tier AI/HAI infrastructure components are attested continuously. Every Critical component produces a daily attestation signal across IaC-pattern compliance, evidence freshness, and configuration tolerance. Drift auto-opens IM-Infrastructure tickets.

Question 7: Daily Attestation Signal for Infrastructure

Q3.1: Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily attestation signal across all three dimensions (IaC-pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Infrastructure tickets within 1 hour?

Evidence Required: - [ ] Daily attestation pipeline operational covering three dimensions per Critical-tier component: (1) IaC-pattern compliance, workload identity correctly assigned, encryption keys in KMS, rate-limit configuration active, per-tenant isolation policy intact, image pins enforced, signing policies active; (2) evidence freshness, IaC plan ≤1 day, boundary probe ≤90 days, vendor admin API probe ≤30 days (Critical) / ≤90 days (High), GPU residual-state-clearing test ≤90 days; (3) configuration tolerance, deployed configuration within declared tolerances (patch versions tolerated; image family changes not tolerated without DR re-review) - [ ] Auto-open IM-Infrastructure ticket on drift: ticket created within 1 hour of detection; carries drift dimension, specific control that failed tolerance, and link to DR decision record - [ ] Attestation-pipeline health monitored: % Critical components with fresh signal in the last 24 hours; on-call paged for any Critical component silent for >24 hours; pager history on file - [ ] Zero stale-evidence violations confirmed for Critical-tier REMs: no evidence citations outside their defined freshness window - [ ] Attestation artifacts regulator-consumable: machine-readable format confirmed suitable for EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records via test export - [ ] Configuration tolerance definitions documented per-control: tolerance rules versioned and linked from SM-Infrastructure inventory; tuned to avoid alert fatigue from minor image patch updates

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Infrastructure integration telemetry
Evidence freshness violations (stale evidence in active REMs)	___	___	0 for Critical; trending toward 0 for High	☐	Attestation telemetry
IR reviewer-hours per Critical component per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - Daily attestation coverage: count Critical-tier components with a signed attestation artifact dated within the last 24 hours covering all three dimensions divided by total Critical-tier components. Source: attestation pipeline telemetry - Auto-open ticket latency: median time from drift-detection event to IM-Infrastructure ticket created. Source: attestation pipeline timestamp × IM-Infrastructure created-at timestamp - Stale-evidence violations: count Critical-tier REM rows with evidence citations outside their freshness window. Source: attestation pipeline evidence-freshness dimension output - IR reviewer-hours: total hours logged for Critical-tier infrastructure IR activities per year. Source: reviewer time tracking

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 8: External Infrastructure Schema Contribution

Q3.2: Has the program published per-archetype configuration baseline schemas to OpenSSF AI, CNCF AI Working Group, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented external adoption and internal practice aligned to the published versions?

Evidence Required: - [ ] Per-archetype configuration baseline schemas published to at least one external body: OpenSSF AI working group (reference attestation schema compatible with SLSA / in-toto), CNCF AI Working Group (per-archetype configuration controls for AI/ML infrastructure on Kubernetes), or OWASP LLM / Agentic Top 10 infrastructure patterns (inference endpoint, model registry, GPU fleet, orchestrator, vector-store archetypes) - [ ] Internal practice aligned to published external versions: documented mapping between internal IR checklist and published schema; internal-only deviations proposed as upstream changes with a PR or issue link - [ ] External adoption tracked: citations, forks, direct acknowledgment from peer organizations, or inclusion in external tooling or assessment frameworks, evidence on file - [ ] Schema publication pipeline active: at least one schema in-draft, in-review, or published at any time; publication status tracker maintained - [ ] Adoption trend documented: at least one adoption data point on file since initial publication - [ ] Internal schema version pinned to published external version: divergence documented as a proposed upstream change

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Infrastructure integration telemetry
External adoption of published configuration baseline schemas	0	tracked	trending up	☐	External telemetry
IR reviewer-hours per Critical component per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - External adoption: count citations, forks, and direct acknowledgments per quarter since publication. Source: GitHub stars/forks, external publication references, peer organization acknowledgments - Schema alignment rate: % of internal IR checklist items directly traceable to a published external schema item. Source: internal-to-external schema mapping document - Publication pipeline health: number of schemas in active publication stages. Source: publication tracker

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 9: Automated Drift-to-IM Escalation and Post-Incident Attestation Refinement

Q3.3: Is the post-incident IR feedback loop operational, IM-Infrastructure post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident?

Evidence Required: - [ ] All IR findings (daily attestation and periodic reviews) flow into IM-Infrastructure automatically with severity and SLA pre-populated from the SM-Infrastructure L2 tier-treatment matrix; no manual entry required for attestation-generated findings - [ ] IM-Infrastructure SLA clock automated: overdue Critical findings escalate to the program sponsor at 50% and 100% of the SLA window automatically; escalation automation tested quarterly with synthetic finding, test record on file - [ ] Post-incident IR feedback loop documented in the IM-Infrastructure incident-review template: a mandatory IR-record re-examination step confirmed in the last material incident review record - [ ] Attestation rule updates produced from incident learning: at least one attestation rule update linked from a completed incident review in the last 12 months - [ ] Post-incident IR step completion tracked: % of material incidents in the last 12 months with a completed post-incident review including the IR-record re-examination step - [ ] Attestation-pipeline health log on file: ≥90% of Critical components with fresh signal in the last 24 hours; pager history on file

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier components producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Infrastructure integration telemetry
Evidence freshness violations (stale evidence in active REMs)	___	___	0 for Critical; trending toward 0 for High	☐	Attestation telemetry
IR reviewer-hours per Critical component per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - Auto-open ticket rate: count attestation-generated findings that created an IM-Infrastructure ticket within 1 hour divided by total attestation-generated findings. Source: attestation pipeline × IM-Infrastructure integration telemetry - Escalation automation test pass rate: % of quarterly escalation tests that confirmed correct automated escalation. Source: escalation test records - Post-incident IR step completion: % of material incident post-reviews with the IR-record re-examination step completed. Source: IM-Infrastructure incident review records - Attestation rule update rate: count attestation rule updates linked from post-incident reviews in the last 12 months. Source: attestation pipeline rule-change log × IM-Infrastructure incident reviews

Evidence Location: _________

Validation Date: _________

Notes: _______

Summary Scorecard

Level	Question	Score	Weight
L1	Q1: Per-Archetype Infrastructure IR Checklist	___	33%
L1	Q2: Review Triggers and IaC Drift Sources	___	33%
L1	Q3: Findings Tracking and SR-Infrastructure REM Loop	___	33%
L1 Total		___
L2	Q4: Continuous Infrastructure Drift Detection	___	33%
L2	Q5: Vendor Admin API Probing and Tier-Calibrated Cadence	___	33%
L2	Q6: Per-Archetype Boundary Probing	___	33%
L2 Total		___
L3	Q7: Daily Attestation Signal for Infrastructure	___	33%
L3	Q8: External Infrastructure Schema Contribution	___	33%
L3	Q9: Automated Escalation and Post-Incident Attestation Refinement	___	33%
L3 Total		___
Overall IR-Infrastructure Score		___

Current Maturity Level: ___

Key Findings:

Priority Improvements:

Document Version: HAIAMM v3.0 Practice: Implementation Review (IR) Domain: Infrastructure Questionnaire Date: 2026-05-15 Author: Verifhai

Instructions:

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

↓ Download as Markdown