Issue Management (IM) - Infrastructure Assessment

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

v3.0 rewrite: The canonical framing for the Infrastructure domain is Issue Management, unified backlog, tier-calibrated incident playbook, and regulatory SLA tracking for AI infrastructure issues. The fully v3.0 source-of-truth is ../practices/IM-Infrastructure-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md. Primary tactic: MITRE ATLAS TA0014 Impact. Sector overlay: FedRAMP IR (1h high-severity), ISO/IEC 27035.

Issue Management (IM) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Issue Management (IM) Domain: Infrastructure Purpose: Assess organizational maturity in operating a unified AI infrastructure issue backlog, AI-infrastructure-specific incident playbook, and regulatory SLA tracker covering GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR, and ISO/IEC 27035 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 the practice

Level Score = Average of question scores within the level Overall IM-Infrastructure Score = Weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

Maturity Level 1

Objective: Operate a single unified AI infrastructure issue backlog with a standard triage rubric, AI-infrastructure-specific incident playbook with containment plays for the primary AI infrastructure incident classes, and regulatory SLA tracking for GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR, and ISO/IEC 27035

Question 1: Unified AI Infrastructure Issue Backlog and Triage Rubric

Q1.1: Is there a single AI infrastructure issue backlog with standardized metadata (source, affected component linked to SM-Infrastructure inventory, severity rubric anchored to AI-infrastructure-specific axes, cross-tenant breach / GPU residual-state leakage / registry compromise for Critical; confirmed control failure with potential impact for High, etc., owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external CVEs, CNCF advisories, ATLAS updates)?

Evidence Required: - [ ] Single backlog record showing standardized metadata: Source (TA/SR/DR/IR/ST/ML/External including CVEs for AI-infra components, cloud-provider bulletins, CNCF advisories, ATLAS updates), Affected component linked to SM-Infrastructure inventory with archetype and tier, Severity per AI-infrastructure rubric, Owner, SLA, Regulatory flag (GDPR Art. 33, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, FedRAMP IR), Evidence link - [ ] Triage rubric with AI-infrastructure severity anchors: Critical (active cross-tenant data access through inference endpoint or vector store, confirmed GPU residual-state leakage between tenants, orchestrator control-plane compromise with confirmed workflow execution under attacker control, model registry compromise with unsigned artifact in production, GDPR Art. 33 personal data breach through AI infrastructure, regulated data in transit through shadow inference endpoint), High, Medium, Low - [ ] Backlog coverage audit showing ≥95% of AI infrastructure issues from all source practices vs. reconciliation count including CVE advisory routing - [ ] Triage cadence records: daily Critical/High, weekly Medium, monthly aging, confirmed for last 90 days - [ ] SLA targets published: Critical acknowledge ≤4h / contain ≤48h / root-cause ≤30d; High ≤24h/7d/45d; Medium ≤48h/14d; Low ≤5bd/30d - [ ] Monthly aging dashboard delivered to program sponsor

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI infrastructure issues in single backlog vs. scattered queues | % | % | ≥95% | ☐ | | | % of issues with complete standardized metadata | % | % | ≥95% | ☐ | | | % of Critical/High infrastructure issues acknowledged within SLA | % | % | 100% | ☐ | | | External CVE/CNCF/ATLAS advisories routed to backlog within 5 business days | % | % | ≥95% | ☐ | |

Metric Collection Guidance: - Backlog coverage: Monthly reconciliation of single backlog vs. all source practices including CVE advisory feeds. Formula: backlog_issues / total_issues_filed × 100 - Metadata completeness: Spot-audit 20 random tickets per month; all required fields populated. Source: backlog export - SLA acknowledgement: issues_acknowledged_within_SLA / total_new_Critical_High × 100. Source: backlog timestamps. Weekly - Advisory routing: advisories_routed_within_5bd / total_applicable_advisories × 100. Source: advisory intake log. Weekly

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 unified AI infrastructure backlog)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 2: AI-Infrastructure-Specific Incident Playbook, Seven Containment Plays

Q1.2: Is the AI infrastructure incident playbook published with seven named AI-infrastructure-specific incident classes (cross-tenant breach, model registry compromise, GPU residual-state leakage, orchestrator compromise, vector-store mass-extraction, AI CI/CD pipeline compromise, shadow inference endpoint), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months?

Evidence Required: - [ ] Playbook with seven named AI-infrastructure-specific entries, published and version-controlled: (1) cross-tenant breach, inference-endpoint/vector-store disable, scope assessment, GDPR Art. 33 evaluation, credential rotation, per-tenant isolation remediation; (2) model registry compromise, promotion freeze, rollback to last-known-good, 30-day promotion audit, registry service-account and signing-key rotation, SLSA provenance re-verification; (3) GPU residual-state leakage, node drain and cordon, clearing-process configuration audit, cross-tenant exposure assessment, GDPR Art. 33 evaluation, clearing remediation and verification; (4) orchestrator compromise, kill all active workflows, service-account credential rotation, unauthorized-action audit, downstream write assessment; (5) vector-store mass-extraction, query-path disable for affected principal, classification-gated allowlist, embedding-inversion risk assessment; (6) AI CI/CD pipeline compromise, pipeline execution freeze, 30-day pipeline run audit, eval-suite replay for promoted artifacts, SBOM regeneration, signing-key rotation; (7) shadow inference endpoint, egress-block on identified shadow endpoint, SM-Infrastructure intake, data-flow assessment, GDPR Art. 33 / EU AI Act Art. 73 evaluation - [ ] Each entry: trigger conditions, named roles (infrastructure deployer-duty owner, cloud-security on-call, Privacy/Legal, executive sponsor), containment steps, artifacts to collect, evidence-capture instructions, closure criteria, SLA targets - [ ] Tabletop exercise records for each of the seven classes within last 12 months (one per quarter, rotating) - [ ] GPU clearing test records: quarterly clearing-success verification on production nodes - [ ] FedRAMP IR 1-hour notification path documented and tested for high-severity infrastructure incidents (if FedRAMP applicable)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI infrastructure incidents handled on a published playbook entry | % | % | 100% | ☐ | | | Tabletop exercises per year across all 7 infrastructure classes | ___ | ___ | ≥4 (rotating) | ☐ | | | GPU clearing verification test pass rate (quarterly) | % | % | 100% | ☐ | | | FedRAMP IR 1h notification path tested (if applicable) | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Playbook coverage: infra_incidents_handled_on_playbook / total_infra_incidents × 100. Source: incident records. Per incident - Tabletop cadence: Count completed tabletop exercises per year with documented scenario coverage. Source: tabletop log - GPU clearing test: Count quarterly clearing-success tests with pass result / total tests. Source: clearing test event records - FedRAMP IR test: Annual test of 1-hour notification path to FedRAMP ISSO; documented test record with pass/fail

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Q1.3: Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), PCI-DSS, FedRAMP IR (1h high-severity), and ISO/IEC 27035, with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA-Infrastructure, SR-Infrastructure, EG-Infrastructure, and ML-Infrastructure?

Evidence Required: - [ ] Regulatory SLA tracker covering: GDPR Art. 33 (72h, Privacy/Legal, clock starts on first ML detection or IR finding), EU AI Act Art. 73 (immediate escalation for Annex III-hosted artifact incidents), HIPAA (60d, PHI incidents), NYDFS Part 500 (72h, material cybersecurity events), PCI-DSS (cardholder data breach), FedRAMP IR (1h for high-severity incidents, Cloud Security / FedRAMP ISSO named owner), ISO/IEC 27035 (procedural baseline for all AI infrastructure incident response) - [ ] GDPR Art. 33 clock-start protocol: named owner documents start-time on first ML detection; daily status updates; no missed windows in last 90 days - [ ] FedRAMP IR 1-hour escalation path: named FedRAMP ISSO contact, escalation procedure, last-tested date (if FedRAMP applicable) - [ ] Post-incident review records for all Critical/blocker incidents in last 12 months: root cause, what caught it, what did not, four update outputs (SA-Infrastructure pattern update, SR-Infrastructure requirements update, EG-Infrastructure training update, ML-Infrastructure detection update) all populated and tracked as IM-Infrastructure improvement issues

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Regulatory SLA adherence (0 missed notifications) in last 90 days | ___ | 0 missed | 0 missed | ☐ | | | Post-incident reviews within 14 days of Critical/blocker closure | % | % | 100% | ☐ | | | SA/SR/EG/ML-Infrastructure update outputs tracked (% Critical reviews with ≥1 per target) | % | % | 100% | ☐ | | | Median closure time for Critical AI infrastructure incidents (root-cause) | ___ days | ___ days | ≤30 days | ☐ | |

Metric Collection Guidance: - Regulatory adherence: Zero missed notification windows across all tracked obligations. Source: SLA tracker. Weekly review - Review timeliness: infra_reviews_within_14d / total_Critical_blocker_closures × 100. Source: review records with timestamps - Update output completion: Verify all four downstream outputs exist and are tracked. Source: IM-Infrastructure improvement issues log - MTTR: Median days from incident creation to root-cause filed. Source: backlog aging. Monthly

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 2

Objective: Calibrate incident response depth per SM-Infrastructure L2 tier; establish dedicated on-call for Critical-tier infrastructure components; and automate cross-domain signal flow so that Infrastructure incidents affecting Software and Data domains generate coordinated response

Question 4: Tier-Calibrated Incident Playbook and 24/7 On-Call

Q2.1: Is a tier-calibrated incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier component briefing with clearing-failure and shadow-endpoint escalation paths, and tier-movement in SM-Infrastructure inventory automatically triggering IM configuration updates within 14 days?

Evidence Required: - [ ] Tier-calibrated activation criteria: Critical (CISO + Privacy/Legal + infrastructure deployer-duty + executive sponsor, ≤1h MTTA, ≤4h MTTC, 24/7, pre-staged comms templates), High (Infrastructure Security + Privacy/Legal if regulated data, ≤4h MTTA, ≤24h MTTC, business hours + escalation), Medium (standard queue, ≤1bd), Low (weekly aggregated) - [ ] 24/7 on-call rotation registry: named individuals per week, handoff protocol, no-gap periods confirmed last 90 days - [ ] On-call briefing (current): Critical-tier component list, active detection set, clearing-failure escalation path rehearsed quarterly, shadow-endpoint escalation path rehearsed quarterly - [ ] Tier-movement trigger: SM-Infrastructure tier-change → IM config update within 14 days for Critical re-tier; evidence from last 3 tier-movement events - [ ] Pre-staged communication templates reviewed quarterly: internal, customer-facing if applicable, regulatory notification drafts

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Critical-tier MTTA | ___ hr | ___ hr | ≤1 hour | ☐ | | | Critical-tier MTTC | ___ hr | ___ hr | ≤4 hours | ☐ | | | 24/7 on-call: no-gap periods in last 90 days | ___ gaps | ___ gaps | 0 gaps | ☐ | | | Tier-movement → IM config update within 14 days (Critical re-tier) | % | % | 100% | ☐ | |

Metric Collection Guidance: - MTTA / MTTC: From first ML-Infrastructure detection to acknowledged / contained for Critical-tier incidents. Source: IM telemetry. Per incident - On-call gaps: Count weeks with unassigned on-call period. Source: rotation registry. Monthly - Tier-movement latency: Days from SM-Infrastructure tier-change to IM config update. Source: SM tier-change log × IM config log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 5: Post-Incident Review Auto-Flow Integration

Q2.2: Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML-Infrastructure practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly?

Evidence Required: - [ ] Integration configuration: auto-ticket creation for all four downstream infrastructure practices on Critical-tier review closure, SA-Infrastructure (architecture-backlog ticket with incident reference), SR-Infrastructure (pack-backlog ticket with failing requirement row), EG-Infrastructure (training-backlog ticket with affected population), ML-Infrastructure (detection-registry ticket with detection name, current query, proposed change) - [ ] Sample auto-created tickets from last 3 Critical-tier reviews showing correct metadata and incident reference - [ ] Downstream backlog aging data: auto-ticket timestamps vs. owner response within 14 days; ≥90% adherence over last 12 months - [ ] Quarterly sponsor review records: quality assessment distinguishing substantive (concrete update to architecture pattern, requirements pack, curriculum, or detection) from nominal acknowledgement - [ ] Accepted outputs designated High-severity in receiving practice backlog, evidence in downstream tickets

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Post-incident review outputs auto-flowing to SA/SR/EG/ML-Infrastructure (% Critical reviews) | % | % | 100% | ☐ | | | Downstream practice owner response within 14 days | % | % | ≥90% | ☐ | | | Quarterly sponsor quality review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Substantive update output rate (sponsor-assessed) | % | % | ≥80% | ☐ | |

Metric Collection Guidance: - Auto-flow rate: Critical_infra_reviews_with_all_4_auto_tickets / total_Critical_infra_reviews × 100. Source: integration telemetry - Downstream response rate: update_tickets_responded_within_14d / total_update_tickets × 100. Source: downstream backlog aging. Monthly - Sponsor review: Count quarterly reviews with documented quality assessment. Source: program calendar - Substantive rate: substantive_count / total_reviewed × 100. Sponsor-assessed

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 6: Cross-Domain Coordination Protocol

Q2.3: Is a cross-domain coordination protocol published and used for 100% of multi-domain AI infrastructure incidents, with named cross-domain contacts for Software, Data, and Processes domains verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Evidence Required: - [ ] Cross-domain coordination protocol: Infrastructure → Software (inference endpoint compromise exposes Software-domain prompt/completion logs or model version, activates Software-domain EH and IM alongside Infrastructure containment), Infrastructure → Data (GPU residual-state leak or vector-store mass-extraction exposes Data-domain training corpus, activates Data-domain IM alongside Infrastructure containment), Infrastructure → Processes (orchestrator control-plane compromise causes unauthorized writes to business-process workflow, activates Processes-domain business-continuity coordinator alongside Infrastructure orchestrator-compromise play) - [ ] Named cross-domain contacts registry: Software-domain IM contact, Data-domain IM contact, Processes-domain IM contact, last verified within 90 days - [ ] Quarterly contact verification records (last 4 quarters): contacts confirmed reachable, channels tested - [ ] Multi-domain incident activation records: shared status board, single IC from primary impacted domain, joint post-incident review spanning all affected domains - [ ] IC designation procedure: pre-defined IC assignment rules for cross-domain infrastructure incidents; Infrastructure-incident-driven SA/SR/EG/ML updates auto-flow across all affected domains

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Cross-domain protocol used for 100% of multi-domain infrastructure incidents | % | % | 100% | ☐ | | | Cross-domain contact registry verified within last 90 days | Yes/No | Yes/No | Yes | ☐ | | | Joint post-incident reviews for multi-domain infrastructure incidents | % | % | 100% | ☐ | | | Quarterly contact verification on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | |

Metric Collection Guidance: - Protocol usage: multi_domain_infra_incidents_using_protocol / total_multi_domain_infra × 100. Source: incident coordination records - Contact currency: Date of last verification. Target: within 90 days. Source: contact registry - Joint PIR: multi_domain_incidents_with_joint_PIR / total_multi_domain × 100. Source: PIR records - Verification cadence: Count quarterly verification events. Source: program calendar

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 3

Objective: Contribute incident patterns and playbook templates to CNCF, OpenSSF AI, MITRE ATLAS, AVID, and sector ISACs; automate runbook decisioning for high-confidence detections; and benchmark MTTR against industry peers

Q3.1: Does the program contribute ≥4 anonymized AI infrastructure incident-classification entries per year to sector ISACs, ≥2 entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS AI infrastructure tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption?

Evidence Required: - [ ] ISAC participation records: sector ISAC membership (FS-ISAC AI WG, H-ISAC, IT-ISAC); ISAC AI incident feeds integrated; ≥4 anonymized contributions per year (incident type, archetype affected, ATLAS tactic tag, containment play used, MTTR) - [ ] AVID submission records: ≥2 AI infrastructure vulnerability entries per year (GPU residual-state leakage vectors, orchestrator injection surfaces, vector-store extraction patterns); maintenance log; legal sign-off per submission - [ ] MITRE ATLAS AI infrastructure contribution: ≥1 per year for AI infrastructure TTPs (cross-tenant access, model supply-chain compromise, orchestrator workflow injection); contribution tracking log - [ ] CNCF TAG Security contribution (if applicable): AI infrastructure incident severity-anchor definitions, playbook template schemas, Kubernetes-specific containment runbook patterns - [ ] OpenSSF AI Infrastructure contribution (if applicable): supply-chain incident response playbooks for model registry compromise and CI/CD pipeline integrity failure - [ ] Legal vetting sign-offs and external adoption tracking log for all contributions

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | ISAC AI infrastructure incident contributions per year | 0 | ___ | ≥4 | ☐ | | | AVID entries submitted per year | 0 | ___ | ≥2 | ☐ | | | ATLAS AI infrastructure contributions per year | 0 | ___ | ≥1 | ☐ | | | External adoption events tracked | 0 | ___ | ≥1 | ☐ | |

Metric Collection Guidance: - ISAC contributions: Count anonymized incident-classification submissions per year. Source: ISAC contribution log - AVID entries: Count entries created or materially updated per year. Source: AVID contribution log - ATLAS contributions: Count technique observations or mitigation entries submitted. Source: ATLAS contribution log - Adoption events: Count external citations or adoptions. Source: contribution tracking log. Semi-annual review

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 8: Pre-Authorized Automated Runbook Decisioning for Infrastructure Incidents

Q3.2: Are ≥3 pre-authorized automated infrastructure containment actions live (shadow-endpoint egress-block, GPU node drain on clearing failure, vector-store retrieval rate-limit, AI CI/CD pipeline freeze), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with the pre-authorization policy reviewed quarterly?

Evidence Required: - [ ] Pre-authorization policy: published list of ≥3 automated infrastructure containment actions with confidence thresholds (e.g., egress-block for shadow inference endpoint for non-Critical-tier components on first detection; GPU node drain on residual-state clearing failure for Medium-tier or lower nodes; vector-store retrieval-policy block for principal exceeding mass-extraction threshold on non-Critical-tier store; pipeline execution freeze for Low/Medium-tier AI CI/CD pipelines on integrity failure detection) - [ ] Legal/Privacy and executive sponsor sign-off records, dated and versioned - [ ] Critical-tier handling: human confirmation within 15 minutes; timer-based fallback with executive notification - [ ] Automation execution log samples (5 records): each action produces audit log entry in IM-Infrastructure backlog, human-review ticket auto-created, notification to component deployer-duty owner - [ ] Quarterly policy review records (last 4 quarters); unexpected-outcome triggered out-of-cycle reviews within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pre-authorized automated infrastructure containment actions operational | 0 | ___ | ≥3 defined, vetted, live | ☐ | | | % actions producing full audit record + human-review ticket | % | % | 100% | ☐ | | | Quarterly policy review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Unexpected-outcome out-of-cycle reviews within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Actions live: Count unique automated infrastructure containment action types defined, vetted, and deployed. Source: pre-authorization policy + automation deployment record - Audit completeness: automated_infra_actions_with_audit_AND_ticket / total_automated_infra_actions × 100. Source: automation telemetry - Policy review: Count quarterly reviews completed. Source: review calendar - Out-of-cycle timeliness: unexpected_reviews_within_5bd / total_unexpected_outcomes × 100. Source: out-of-cycle review log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 9: MTTR Benchmarking for Infrastructure Incidents

Q3.3: Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per infrastructure incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

Evidence Required: - [ ] MTTR benchmark data sources: sector ISAC AI incident data exchanges, BSIMM-style observational data, MITRE ATLAS practitioner community data, peer roundtables, at least two active; updated semi-annually - [ ] Quarterly MTTR benchmark brief (last 4 quarters): MTTR per infrastructure incident class (cross-tenant breach, model registry compromise, GPU residual-state leakage, orchestrator compromise, vector-store mass-extraction, AI CI/CD pipeline compromise, shadow inference endpoint) vs. benchmark; per tier vs. benchmark; delta trend - [ ] Investment-driver section: above-benchmark classes mapped to specific practice gap (missing detection, unclear playbook, on-call latency) with budget-linked improvement proposal - [ ] Quarterly brief delivery records (last 4 quarters on-time) - [ ] Benchmark data source refresh log: updated at least semi-annually; stale benchmarks flagged

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | MTTR benchmark brief published quarterly to sponsor | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Critical-tier MTTR at or below benchmark for ≥4 of 7 infrastructure incident classes | ___ / 7 | ___ / 7 | ≥4 of 7 | ☐ | | | Above-benchmark classes with investment proposals | % | % | 100% | ☐ | | | Benchmark data source refresh within last 6 months | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Brief cadence: Count briefs delivered on schedule per year. Source: program reporting calendar - Benchmark performance: For each of 7 infrastructure incident classes, compare Critical-tier MTTR to benchmark. Count at or below. Source: MTTR brief. Quarterly - Investment proposals: above_benchmark_classes_with_proposal / total_above_benchmark × 100. Source: brief investment-driver section - Benchmark freshness: Date of most recent external source update. Target: within 180 days. Source: benchmark refresh log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Summary Scorecard

Question	Level	Activity	Score
Q1: Unified infrastructure backlog and triage rubric	L1	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q2: AI-infrastructure incident playbook (7 plays)	L1	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q3: Regulatory SLA tracker (incl. FedRAMP IR) and PIR loop	L1	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q4: Tier-calibrated infrastructure playbook and 24/7 on-call	L2	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q5: Post-incident review auto-flow integration	L2	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q6: Cross-domain coordination protocol	L2	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q7: ISAC / AVID / ATLAS / CNCF / OpenSSF contributions	L3	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q8: Pre-authorized automated infrastructure runbook	L3	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q9: MTTR benchmarking for infrastructure incidents	L3	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0

Level 1 Score (avg Q1–Q3): _____ / 1.0

Level 2 Score (avg Q4–Q6): _____ / 1.0

Level 3 Score (avg Q7–Q9): _____ / 1.0

Overall IM-Infrastructure Score (L1×0.5 + L2×0.3 + L3×0.2): _____ / 1.0

Assessment Date: _________

Assessor: _________

Next Assessment Due: _________

Document Version: HAIAMM v3.0, 2026-05-15, Verifhai Practice: Issue Management (IM) Domain: Infrastructure Source of Truth: docs/practices/IM-Infrastructure-OnePager.md

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

Issue Management (IM) - Infrastructure Assessment

Issue Management (IM) - Infrastructure Domain

HAIAMM Assessment Questionnaire v3.0

Instructions

Scoring Methodology

Maturity Level 1

Question 1: Unified AI Infrastructure Issue Backlog and Triage Rubric

Question 2: AI-Infrastructure-Specific Incident Playbook, Seven Containment Plays

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Maturity Level 2

Question 4: Tier-Calibrated Incident Playbook and 24/7 On-Call

Question 5: Post-Incident Review Auto-Flow Integration

Question 6: Cross-Domain Coordination Protocol

Maturity Level 3

Question 7: Industry-Coordinated Infrastructure Incident Sharing and Contribution

Question 8: Pre-Authorized Automated Runbook Decisioning for Infrastructure Incidents

Question 9: MTTR Benchmarking for Infrastructure Incidents

Summary Scorecard