Issue Management (IM) - Processes Assessment

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

v3.0 rewrite: The canonical framing for the Processes domain is Issue Management, unified backlog, tier-calibrated incident playbook, and regulatory SLA tracking for AI/HAI workflow issues. The fully v3.0 source-of-truth is ../practices/IM-Processes-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md. Primary tactic: MITRE ATLAS TA0014 Impact. Sector overlays: FCRA adverse-action, NYC LL 144, CO SB-21-169, FINRA model-risk.


Issue Management (IM) - Processes Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Issue Management (IM) Domain: Processes Purpose: Assess organizational maturity in operating a unified AI/HAI workflow issue backlog, AI-specific workflow incident playbook, and regulatory SLA tracker covering GDPR Arts. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA, FINRA, NYC LL 144, CO SB-21-169, and sector-specific obligations 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-Processes Score = Weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2


Maturity Level 1

Objective: Operate a single unified AI/HAI workflow issue backlog with a standard triage rubric, AI-specific workflow incident playbook including containment plays for the primary process incident classes, and regulatory SLA tracking for GDPR Arts. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA, FINRA, NYC LL 144, and CO SB-21-169 obligations

Question 1: Unified AI/HAI Workflow Issue Backlog and Triage Rubric

Q1.1: Is there a single AI/HAI workflow issue backlog with standardized metadata (source, affected workflow linked to SM-Processes inventory, severity rubric anchored to AI-specific axes, wrongful automated decision / HITL failure / disclosure failure / regulated-data breach 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)?

Evidence Required: - [ ] Single backlog record showing standardized metadata: Source (TA-Processes/SR-Processes/DR-Processes/IR-Processes/ST-Processes/ML-Processes/External including sector regulator enforcement actions, NYC LL 144 audit findings, EEOC bias enforcement, EU AI Act enforcement decisions), Affected workflow linked to SM-Processes inventory with archetype and tier, Severity per AI-specific workflow rubric, Owner, SLA, Regulatory flag (GDPR Art. 33, EU AI Act Art. 73, HIPAA, FCRA adverse-action, NYC LL 144, CO SB-21-169, FINRA), Evidence link - [ ] Triage rubric with AI-workflow-specific severity anchors: Critical (wrongful automated decision on Annex III workflow, HITL failure with real-world consequential outcomes, Art. 50 disclosure failure ≥1,000 interactions or regulated context, personal data breach in AI/HAI workflow triggering GDPR Art. 33, shadow AI handling regulated data, RAG-poisoning in consequential decision context), High, Medium, Low - [ ] Backlog coverage audit: ≥95% of AI/HAI workflow issues from all source practices vs. reconciliation from practice queues - [ ] Triage cadence records: daily Critical/High, weekly Medium, monthly aging, confirmed for last 90 days - [ ] SLA targets published: Critical ≤4h / ≤48h / ≤30d; High ≤24h/7d/45d; Medium ≤48h/14d; Low ≤5bd/30d

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI workflow issues in single backlog vs. scattered queues | % | % | ≥95% | ☐ | | | % of issues with complete standardized metadata | % | % | ≥95% | ☐ | | | % of Critical/High workflow issues acknowledged within SLA | % | % | 100% | ☐ | | | Monthly aging report delivered to sponsor on schedule | ___ / 12 | ___ / 12 | 12 / 12 | ☐ | |

Metric Collection Guidance: - Backlog coverage: Monthly reconciliation of single backlog vs. all source practices. Formula: backlog_issues / total_workflow_issues_filed × 100 - Metadata completeness: Spot-audit 20 random tickets per month. Source: backlog export - SLA acknowledgement: workflow_issues_acknowledged_within_SLA / total_new_Critical_High × 100. Source: backlog timestamps. Weekly - Aging report cadence: Count sponsor-facing aging reports delivered per year. Source: program reporting calendar

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/HAI workflow issue backlog)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


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

Q1.2: Is the AI/HAI workflow incident playbook published with seven named AI-specific workflow incident classes (wrongful-decision containment, HITL failure / rubber-stamp, disclosure failure Art. 50, class-shift / fairness security-intersection, content-generation harmful output, knowledge-management RAG-poisoning, shadow-AI-in-process), 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-specific workflow entries, published and version-controlled: (1) wrongful-decision containment, pause workflow, identify affected persons, manual review, GDPR Art. 22 notification, EU AI Act Art. 73 serious-incident assessment, Art. 26.5 deployer-suspension evaluation; (2) HITL failure / rubber-stamp, pause HITL step, 30-day reviewer-pool audit, retroactive review assessment, mandatory reviewer training escalation, Art. 26 non-conformance evaluation; (3) disclosure failure, identify suppressed surface, restore disclosure template, scope assessment (how many interactions, what period), retroactive disclosure, Art. 26 deployer-duty evaluation; (4) class-shift / fairness security-intersection only, pause decision-pipeline step, root-cause (model drift vs. data-poisoning vs. adversarial input vs. threshold manipulation), NYC LL 144 / EEOC / CO SB-21-169 / EU AI Act Art. 73 regulator notification evaluation; (5) content-generation harmful output, recall/retract harmful output, pause generation step, identify source (prompt/model/template), rollback to last-known-good, brand-safety filter update; (6) knowledge-management RAG-poisoning, quarantine affected corpus segment, disable retrieval pipeline, assess affected queries and users, re-index after removal and ST-Processes validation; (7) shadow-AI-in-process, pause/freeze unrecognized AI step, intake via SM-Processes, data-flow assessment, GDPR Art. 33 / EU AI Act Art. 73 evaluation, Vendors-domain IM routing if unvetted vendor involved - [ ] Each entry: trigger conditions, named roles (deployer-duty owner, Privacy/Legal, executive sponsor, workflow operations on-call), containment steps, artifacts, evidence-capture, closure criteria, SLA targets - [ ] Tabletop exercise records for each of the seven classes within last 12 months (one per quarter, rotating) - [ ] GDPR Art. 22 contestation timing documented: clock-start condition defined (internal awareness event or customer submission, whichever is earlier); named Privacy/Legal + workflow owner - [ ] EU AI Act Art. 26.5 deployer-suspension evaluation procedure: triggers identified (wrongful-decision, HITL failure, disclosure failure incidents)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI workflow incidents handled on a published playbook entry | % | % | 100% | ☐ | | | Tabletop exercises per year across all 7 workflow classes | ___ | ___ | ≥4 (rotating) | ☐ | | | GDPR Art. 22 contestation timing clock-start documented and confirmed for each qualifying incident | Yes/No | Yes/No | Yes | ☐ | | | Shadow-AI-in-process incidents routed to SM-Processes intake within 24h of detection | % | % | 100% | ☐ | |

Metric Collection Guidance: - Playbook coverage: workflow_incidents_handled_on_playbook / total_workflow_incidents × 100. Source: incident records - Tabletop cadence: Count completed tabletop exercises per year with documented scenario coverage. Source: tabletop log - Art. 22 contestation clock: For each qualifying incident, confirm clock-start documented. Source: SLA tracker + incident records - Shadow-AI routing: shadow_AI_incidents_routed_to_intake_within_24h / total_shadow_AI_detections × 100. Source: ML-Processes detection log × SM-Processes intake 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 AI-specific workflow incident playbook)

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 Arts. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations, 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-Processes, SR-Processes, EG-Processes, and ML-Processes?

Evidence Required: - [ ] Regulatory SLA tracker covering: GDPR Art. 33 (72h, Privacy/Legal, clock starts on first ML detection or IR finding), GDPR Art. 22 contestation timing (per workflow SR-Processes requirements), EU AI Act Art. 73 (immediate escalation for Annex III workflow incidents), EU AI Act Art. 26.5 (deployer-suspension evaluation on wrongful-decision/HITL failure/disclosure failure), HIPAA (60d, PHI incidents), FCRA adverse-action (adverse-action notices within applicable timeframe for AI-driven credit/employment/insurance decisions), NYC LL 144 (annual bias-audit findings tracked; public posting compliance), CO SB-21-169 (insurance unfair-discrimination tracking for CO-applicable decision pipelines), FINRA model-risk (material model-risk incidents tracked) - [ ] GDPR Art. 33 clock-start protocol: named owner, start-time documented on first ML-Processes detection, daily status updates; no missed windows in last 90 days - [ ] FCRA adverse-action tracking: named Compliance/Legal owner; procedure for flagging AI/HAI decision-pipeline incidents involving adverse credit/employment/insurance decisions - [ ] Post-incident review records for all Critical/blocker workflow incidents in last 12 months: root cause, what caught it, what did not, four update outputs (SA-Processes pattern update, SR-Processes requirements update, EG-Processes training update, ML-Processes detection update) all populated and tracked

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-Processes update outputs tracked (% Critical reviews with ≥1 per target) | % | % | 100% | ☐ | | | Median closure time for Critical workflow 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: workflow_reviews_within_14d / total_Critical_blocker_closures × 100. Source: review records - Update output completion: Verify all four downstream outputs exist and are tracked. Source: IM-Processes improvement issues log - MTTR: Median days from incident creation to root-cause filed. Source: backlog aging. Monthly

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 regulatory SLA tracker for processes domain)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


Maturity Level 2

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

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

Q2.1: Is a tier-calibrated workflow 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 workflow briefing, and tier-movement in the SM-Processes inventory automatically triggering IM configuration updates?

Evidence Required: - [ ] Tier-calibrated activation criteria: Critical (CISO + Privacy/Legal + workflow deployer-duty + executive sponsor, ≤1h MTTA, ≤4h MTTC, 24/7 on-call, pre-staged comms templates), High (AppSec + Privacy/Legal if regulated data + deployer-duty, ≤4h MTTA, ≤24h MTTC), 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 workflow list, active detection set, pause-workflow path per workflow, deployer-suspension evaluation trigger procedure - [ ] Tier-movement trigger: SM-Processes inventory tier-change → IM config update; evidence from last 3 tier-movement events - [ ] Pre-staged communication templates reviewed quarterly: internal escalation, customer-facing, regulatory notification drafts (Art. 26.5 deployer-suspension notification, GDPR Art. 33 draft)

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-Processes config update completed | % | % | 100% (within 14d Critical re-tier) | ☐ | |

Metric Collection Guidance: - MTTA / MTTC: From first ML-Processes detection to acknowledged / contained for Critical-tier workflow 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-Processes tier-change to IM config update. Source: SM log × IM config 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-calibrated workflow playbook)

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 workflow review outputs to SA/SR/EG/ML-Processes 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 practices on Critical-tier review closure, SA-Processes (architecture-backlog ticket), SR-Processes (pack-backlog ticket with failing requirement row), EG-Processes (training-backlog ticket with affected population), ML-Processes (detection-registry ticket with detection name, current query, proposed change) - [ ] Sample auto-created tickets from last 3 Critical-tier workflow reviews showing correct metadata - [ ] 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 pattern, pack, curriculum, or detection) from nominal - [ ] Accepted update 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-Processes (% 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_workflow_reviews_with_all_4_auto_tickets / total_Critical_workflow_reviews × 100. Source: integration telemetry - Downstream response: update_tickets_responded_within_14d / total_update_tickets × 100. Source: downstream backlog aging. Monthly - Sponsor review cadence: Count quarterly reviews with documented quality assessment. Source: program calendar - Substantive rate: substantive_count / total_reviewed × 100. Sponsor-assessed

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 auto-flow integration for processes domain)

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/HAI workflow incidents, with named cross-domain contacts for Software, Data, and Vendors 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: Processes → Software (agent rogue action writing to workflow, activates Software-domain IM agent-rogue-action play alongside Processes-domain wrongful-decision containment), Processes → Data (decision-pipeline AI model producing anomalous outputs from training-corpus poisoning, activates Data-domain IM training-corpus-poisoning play alongside Processes-domain class-shift/wrongful-decision play), Processes → Vendors (third-party AI model producing harmful outputs from vendor model update, activates Vendors-domain IM vendor-material-change play alongside Processes-domain wrongful-decision containment) - [ ] Named cross-domain contacts registry: Software-domain IM, Data-domain IM, Vendors-domain IM, last verified within 90 days - [ ] Quarterly contact verification records (last 4 quarters) - [ ] Multi-domain incident activation records: shared status board, single IC, joint post-incident review - [ ] IC designation procedure for cross-domain workflow incidents

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

Metric Collection Guidance: - Protocol usage: multi_domain_workflow_incidents_using_protocol / total_multi_domain_workflow × 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

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 cross-domain coordination for processes domain)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


Maturity Level 3

Objective: Contribute workflow incident patterns and playbook templates to OECD AI, ISO/IEC 42005, and sector ISACs; automate runbook decisioning for high-confidence detections; and benchmark MTTR against industry peers

Question 7: Industry-Coordinated Workflow Incident Sharing and Contribution

Q3.1: Does the program contribute ≥4 anonymized AI workflow incident-classification entries per year to sector ISACs and ≥2 contributions per year to OECD AI, ISO/IEC 42005, or CSA AI Safety Initiative, with all contributions maintained current, legally vetted, and tracked for external adoption?

Evidence Required: - [ ] ISAC participation records: sector ISAC membership; ISAC AI incident feeds consumed; ≥4 anonymized workflow incident-classification contributions per year (incident type, archetype, containment play, regulatory SLA activated, MTTR) - [ ] OECD AI / ISO/IEC 42005 / CSA contributions: ≥2 per year, AI/HAI workflow incident classification schema, playbook template structures, regulatory SLA tracking models, or ISO/IEC 42005 workflow-specific incident patterns (wrongful-decision, HITL failure, disclosure failure, RAG-poisoning plays) - [ ] Legal vetting sign-offs for all contributions; adoption tracking log - [ ] ISAC AI exercises attended: at least one per year with documented participation

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | ISAC AI workflow incident contributions per year | 0 | ___ | ≥4 | ☐ | | | OECD AI / ISO/IEC 42005 / CSA contributions per year | 0 | ___ | ≥2 | ☐ | | | Contribution pipeline items in-flight (draft/in-review/submitted) at any time | 0 | ___ | ≥2 | ☐ | | | External adoption events tracked | 0 | ___ | ≥1 | ☐ | |

Metric Collection Guidance: - ISAC contributions: Count anonymized workflow incident-classification submissions per year. Source: ISAC contribution log - OECD / ISO / CSA contributions: Count contributions per year. Source: contribution log - Pipeline health: Count items actively in-flight in the contribution pipeline. Source: contribution tracking log. Reviewed quarterly - Adoption events: Count citations or adoptions. Source: adoption tracking log. Semi-annual

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 external workflow incident contribution program)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


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

Q3.2: Are ≥3 pre-authorized automated containment actions live for workflow incidents (HITL-step pause, RAG-corpus quarantine, shadow-AI-step freeze, disclosure-template rollback), 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 workflow containment actions with confidence thresholds (e.g., pause Low/Medium-tier HITL step when reviewer-capacity saturation detection fires ≥95%; quarantine knowledge-management corpus segment when RAG-poisoning detection fires with specific flagged document ID on non-Critical-tier workflow; freeze unrecognized shadow-AI step in Low/Medium-tier workflow on ML-Processes shadow-AI detection; rollback disclosure template to last registry-registered version when disclosure-suppression fires on non-Critical-tier customer-facing flow) - [ ] Legal/Privacy and executive sponsor sign-off, dated and versioned - [ ] Critical-tier workflow 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-Processes backlog, human-review ticket, notification to workflow 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 workflow 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 workflow containment action types defined, vetted, and deployed. Source: pre-authorization policy + automation deployment record - Audit completeness: automated_workflow_actions_with_audit_AND_ticket / total_automated_workflow_actions × 100. Source: automation telemetry - Policy review: Count quarterly reviews completed. Source: review calendar - Out-of-cycle timeliness: reviews_within_5bd / total_unexpected_outcomes × 100. Source: out-of-cycle review 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 pre-authorized automated workflow containment)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


Question 9: MTTR Benchmarking for Workflow Incidents

Q3.3: Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per workflow 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, OECD AI incident database contributions from peer organizations, CISO and AI-safety practitioner peer roundtables, workflow governance practitioners, at least two active; updated semi-annually - [ ] Quarterly MTTR benchmark brief (last 4 quarters): MTTR per workflow incident class (wrongful-decision containment, HITL failure, disclosure failure, RAG-poisoning, shadow-AI-in-process, content-generation harmful output, class-shift/fairness) vs. benchmark; per tier vs. benchmark; delta trend - [ ] Investment-driver section: above-benchmark classes mapped to specific practice gap (missing detection, unclear playbook, reviewer-capacity constraint, DSAR infrastructure gap) with budget-linked improvement proposal - [ ] Quarterly brief delivery records (last 4 quarters on-time) - [ ] Benchmark data source refresh log: updated 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 workflow incident classes | ___ / 7 | ___ / 7 | ≥4 of 7 | ☐ | | | Above-benchmark workflow 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. Source: program reporting calendar - Benchmark performance: For each of 7 workflow incident classes, compare Critical-tier MTTR to benchmark. Count at or below. Source: MTTR brief. Quarterly - Investment proposals: above_benchmark_workflow_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

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 MTTR benchmarking for workflow incidents)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______


Summary Scorecard

Question Level Activity Score Notes
Q1: Unified workflow backlog and triage rubric L1 A ☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q2: AI-specific workflow playbook (7 process plays) L1 B ☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q3: Regulatory SLA tracker (FCRA/NYC LL 144/CO SB-21-169) and PIR loop L1 C ☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q4: Tier-calibrated workflow 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 / OECD AI / ISO 42005 / CSA contributions L3 A ☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q8: Pre-authorized automated workflow runbook L3 B ☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q9: MTTR benchmarking for workflow 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-Processes 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: Processes Source of Truth: docs/practices/IM-Processes-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