> **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`](../practices/IM-Processes-OnePager.md). Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../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