Issue Management (IM) - Vendors Assessment

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

v3.0 rewrite: The canonical framing for the Vendors domain is Issue Management, unified backlog, AI-vendor incident playbook, and vendor-breach-notification SLA tracking. The fully v3.0 source-of-truth is ../practices/IM-Vendors-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md. Primary tactic: MITRE ATLAS TA0014 Impact. Sector overlays: FS-ISAC, H-ISAC, IT-ISAC; vendor-specific contractual SLAs from PC-Vendors DPAs.

Issue Management (IM) - Vendors Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Issue Management (IM) Domain: Vendors Purpose: Assess organizational maturity in operating a unified AI-vendor issue backlog, AI-vendor incident playbook, and vendor-breach-notification SLA tracker covering contractual, GDPR Art. 33, HIPAA, 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-Vendors Score = Weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

Maturity Level 1

Objective: Operate a single AI-vendor issue backlog with a standard triage rubric, an AI-vendor incident playbook with named containment plays, and vendor-breach-notification SLA tracking covering contractual, GDPR Art. 33, HIPAA, and sector-specific obligations

Question 1: Unified AI-Vendor Issue Backlog and Triage Rubric

Q1.1: Is there a single AI-vendor issue backlog with standardized metadata (source, affected vendor and integration linked to SM-Vendors inventory, severity rubric anchored to data-class × regulated posture × breach-SLA status, owner, SLA) capturing ≥95% of AI-vendor issues, with daily/weekly/monthly triage cadences operating?

Evidence Required: - [ ] Single backlog record showing standardized metadata: Source (TA/SR/DR/IR/ST/ML/External including vendor disclosures, public breaches, customer reports), Affected vendor and integration linked to SM-Vendors inventory with archetype, Severity per AI-vendor rubric (data-class exposure × regulated posture × number of users × whether vendor breach SLA is active), Owner (named integration owner or vendor-admin owner), SLA, Evidence link - [ ] Triage rubric document with AI-vendor-specific severity anchors: Blocker (immediate containment), Critical (≤72h containment / ≤14d closure), High (≤14d containment / ≤45d closure), Medium (≤45d), Low (≤90d), anchored to regulated-data exposure class and active vendor breach SLA status - [ ] Backlog coverage audit: ≥95% of AI-vendor issues from all source practices vs. reconciliation from separate Jira projects, TPRM folders, legal trackers - [ ] Triage cadence records: daily Critical/Blocker review, weekly High/Medium, monthly aging, confirmed for last 90 days - [ ] Monthly aging report delivered to program sponsor showing open issues by SLA bucket and vendor tier

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI-vendor issues in single backlog vs. ad-hoc elsewhere | % | % | ≥95% | ☐ | | | % of issues with complete standardized metadata | % | % | ≥95% | ☐ | | | % of Critical/Blocker AI-vendor issues acknowledged within SLA | % | % | 100% | ☐ | | | Median closure time for high-severity AI-vendor issues | ___ days | ___ days | ≤14 days | ☐ | |

Metric Collection Guidance: - Backlog coverage: Monthly reconciliation, backlog issues vs. sum from all source practices including TPRM folders, legal trackers. Formula: backlog_issues / total_vendor_issues_filed × 100 - Metadata completeness: Spot-audit 20 random tickets per month; all required fields populated. Source: backlog export - SLA acknowledgement: vendor_issues_acknowledged_within_SLA / total_new_Critical_Blocker × 100. Source: backlog timestamps. Weekly - Median closure: Median days from issue creation to closure for high-severity vendor issues. 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 unified AI-vendor issue backlog)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 2: AI-Vendor Incident Playbook, Five Vendor-Specific Containment Plays

Q1.2: Is the AI-vendor incident playbook published with ≥5 named AI-vendor incident classes (vendor breach notification received, vendor outage/degraded service, prompt-injection or output-integrity incident, shadow-AI data-exposure incident, agent runaway / tool-abuse incident) plus vendor material-change trigger (no-train flag flip discovered, model-family swap, subprocessor addition), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has it been exercised in at least one tabletop in the last 12 months?

Evidence Required: - [ ] Playbook document with ≥5 named AI-vendor incident entries plus vendor-material-change trigger, published and version-controlled: (1) vendor breach notification received, confirm scope, classify affected data, trigger GDPR Art. 33 / HIPAA / contractual SLAs, coordinate Legal/Privacy, notify affected users where required, log for deployer-duty evidence; (2) vendor outage/degraded service, fallback or kill-switch activation, user communication, post-event review; (3) prompt-injection or output-integrity incident, containment (feature toggle, tool-scope shrink), scope assessment, ML detection tuning; (4) shadow-AI data-exposure incident, user credential revoke, API-key rotation, data-exfil assessment, amnesty-path reinforcement; (5) agent runaway / tool-abuse, kill-switch, scope-reduction, session-log capture, HITL reinforcement; plus (6) vendor material change, no-train flag flip discovered, model-family swap, subprocessor addition, triggers DR/IR re-review and REM update - [ ] Each entry: trigger conditions, named roles (Legal/Privacy, integration owner, executive sponsor), step-by-step containment, artifacts to collect, evidence-capture for deployer-duty record, closure criteria, SLA targets - [ ] Tabletop exercise records for the playbook classes within last 12 months (at least one per quarter) - [ ] No-train flag monitoring procedure: process for detecting vendor-side no-train flag flip (change to data-processing terms) and routing to IM-Vendors as a material-change trigger - [ ] Vendor concentration risk procedure: defined threshold for vendor concentration (e.g., single vendor handling >X% of AI/HAI workloads) triggering IM-Vendors escalation to program sponsor

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI-vendor incidents handled on a published playbook entry | % | % | 100% | ☐ | | | Tabletop exercises per year (AI-vendor incident scenarios) | ___ | ___ | ≥4 | ☐ | | | Vendor material-change triggers routed to IM-Vendors within 5 business days of detection | % | % | 100% | ☐ | | | No-train flag monitoring coverage (% Critical-tier vendors with active flag monitoring) | % | % | 100% | ☐ | |

Metric Collection Guidance: - Playbook coverage: vendor_incidents_handled_on_playbook / total_vendor_incidents × 100. Source: incident records. Per incident - Tabletop cadence: Count completed tabletop exercises per year with documented vendor-scenario coverage. Source: tabletop exercise log - Material-change routing: material_change_triggers_routed_within_5bd / total_material_change_triggers × 100. Source: vendor change-event log × IM-Vendors backlog intake log - No-train monitoring: Count Critical-tier vendors with active no-train flag monitoring in place / total Critical-tier vendors × 100. Source: vendor monitoring registry

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 3: Vendor-Breach-Notification SLA Tracker and Post-Incident Review Loop

Q1.3: Is a vendor-breach-notification SLA tracker live covering contractual SLA per vendor (from DPA/AI addendum) plus regulatory SLAs (GDPR Art. 33 72h, HIPAA 60d, NYDFS Part 500 72h, sector-specific), 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, SR, EG, and ML?

Evidence Required: - [ ] Vendor-breach-notification SLA tracker: contractual SLA per vendor from DPA/AI addendum (notification-time, RCA-delivery, remediation-time) plus regulatory SLAs (GDPR Art. 33 72h, HIPAA 60d, NYDFS Part 500 72h, and sector-specific); named owner per obligation; clock-start condition documented for each - [ ] GDPR Art. 33 clock-start protocol: clock starts on first internal alert constituting awareness of a personal data breach (ML detection, IR finding, vendor notification); named Privacy/Legal owner; no missed windows in last 90 days - [ ] EU AI Act Art. 26.5 deployer-suspension evaluation: procedure for evaluating deployer-suspension obligation when a vendor incident reveals non-conformance with EU AI Act Art. 26 deployer duties - [ ] Post-incident review records for all critical/blocker vendor incidents in last 12 months: what happened, what caught it, what did not, four update outputs (SA pattern update, SR requirements update, EG training update, ML detection-backlog update + shadow-AI threat doc refresh) - [ ] Update outputs tracked in IM-Vendors as improvement issues; delivered to downstream practice queues within 14 days of review completion

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Vendor-breach-notification SLA adherence (0 missed) in last 90 days | ___ | 0 missed | 0 missed | ☐ | | | Post-incident reviews completed within 14 days of critical/blocker closure | % | % | 100% | ☐ | | | SA/SR/EG/ML update outputs from critical reviews tracked and resolved | % | % | 100% produce ≥1 per target | ☐ | | | Deployer-duty evidence assembled within ≤5 business days on regulatory inquiry | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - SLA adherence: Zero missed vendor breach notification windows across contractual and regulatory obligations. Source: SLA tracker. Reviewed weekly - Review timeliness: vendor_reviews_within_14d / total_critical_blocker_closures × 100. Source: review records with timestamps - Update output completion: Verify SA/SR/EG/ML outputs exist and are tracked for each critical review. Source: IM-Vendors improvement issues - Deployer-duty readiness: Annual drill, assemble incident evidence chain within 5 business days; record pass/fail

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 2

Objective: Tier-calibrated incident response, formal vendor-coordination playbook for Critical-tier, and supply-chain-style orchestration when an AI vendor breach affects multiple org integrations

Question 4: Tiered Vendor Incident Playbook and Pre-Established Coordination Channels

Q2.1: Is a tiered incident playbook operational with Critical MTTA ≤1h and MTTC ≤4h, named full-team activation criteria (Legal, Privacy, Communications, Executive Sponsor), 24/7 on-call coverage for Critical-tier, and ≥90% of Critical-tier vendors covered by pre-established, tested coordination channels?

Evidence Required: - [ ] Tier-calibrated activation criteria: Critical (full IM team + Legal + Privacy + Communications + Executive Sponsor, ≤1h acknowledgement, ≤4h containment, 24/7 on-call), High (scoped response, ≤4h acknowledgement, ≤24h containment), Medium (standard, ≤1 business day), Low (tracked and trended) - [ ] 24/7 on-call rotation registry: named individuals per week, handoff protocol, no-gap periods confirmed last 90 days - [ ] Vendor-coordination channel registry for Critical-tier vendors: pre-established comms channels, NDA status, joint-IR coordination protocol per vendor, ≥90% of Critical-tier vendors covered and channels verified active within last 90 days - [ ] Annual joint tabletop records with top-5 Critical vendors (at least one per year): scenario used, attendees, findings, follow-up actions, scenario must cover an AI-vendor-specific class (vendor model swap mid-incident, prompt-injection affecting customer output, vendor-side no-train flip discovered during incident) - [ ] Pre-staged communication templates: internal escalation, customer-facing, regulatory notification draft, reviewed quarterly

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Critical-tier MTTA (mean time to acknowledge) | ___ hr | ___ hr | ≤1 hour | ☐ | | | Critical-tier MTTC (mean time to contain) | ___ hr | ___ hr | ≤4 hours | ☐ | | | % Critical-tier vendors with pre-established, tested coordination channel | % | % | ≥90% | ☐ | | | Joint tabletop with top-5 Critical vendors per year | ___ | ___ | ≥1 / year | ☐ | |

Metric Collection Guidance: - MTTA / MTTC: Measured from first IM-Vendors detection or backlog creation to acknowledged / contained for Critical-tier vendor incidents. Source: IM telemetry. Per incident - Coordination channel coverage: Critical_tier_vendors_with_tested_channel / total_Critical_tier_vendors × 100. Source: vendor-coord registry. Quarterly review - Tabletop cadence: Count joint tabletops with top-5 Critical vendors per year covering AI-vendor-specific scenarios. Source: tabletop exercise log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 5: Supply-Chain-Style Orchestration for Multi-Integration Vendor Breaches

Q2.2: Is supply-chain-style orchestration (single IC, shared status board, coordinated remediation) used for 100% of multi-integration vendor breaches, with the post-incident review spanning all affected integrations?

Evidence Required: - [ ] Supply-chain orchestration protocol: when a single vendor breach affects multiple org integrations, IC coordinates across all integration owners; shared status board activated; shared communication track; shared remediation tracking; joint post-incident review spanning all affected integrations - [ ] IC designation procedure for multi-integration vendor breaches: pre-defined IC assignment rules (no ambiguity when a vendor breach affects multiple teams) - [ ] Multi-integration vendor breach records (if applicable): shared status board used, single IC designated, joint post-incident review completed - [ ] Cross-domain activation records (if applicable): vendor breach implicating Software-domain Software-domain IM activates alongside IM-Vendors; vendor breach implicating Data-domain IM activates; vendor breach implicating Processes-domain activates Processes-domain IM alongside IM-Vendors - [ ] Quarterly contact verification: named cross-domain contacts for Software, Data, and Processes domains verified current within last 90 days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Supply-chain orchestration used for 100% of multi-integration vendor breaches | % | % | 100% | ☐ | | | Joint post-incident reviews completed for multi-integration breaches | % | % | 100% | ☐ | | | Cross-domain contacts verified within last 90 days | Yes/No | Yes/No | Yes | ☐ | | | 24/7 IM on-call coverage for Critical-tier vendor incidents | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Orchestration usage: multi_integration_breaches_with_orchestration / total_multi_integration_breaches × 100. Source: orchestration records - Joint PIR: multi_integration_breaches_with_joint_PIR / total_multi_integration_breaches × 100. Source: PIR records - Contact currency: Date of last cross-domain contact verification. Target: within 90 days. Source: contact registry - On-call coverage: Confirm 24/7 rotation documented with no gaps. Source: on-call registry

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 6: Post-Incident Review Auto-Flow Integration and Vendor-Side SLA Tracking

Q2.3: Are post-incident review outputs from Critical-tier vendor incidents auto-flowing to SA/SR/EG/ML practice backlogs with ≥90% of downstream owners responding within 14 days, and is vendor-side SLA adherence (notification-time, RCA-delivery, remediation-time) tracked per Critical-tier vendor?

Evidence Required: - [ ] Integration configuration: auto-ticket creation for all four downstream practices on Critical-tier vendor review closure, SA (architecture-backlog ticket), SR (pack-backlog ticket with failing requirement row), EG (training-backlog ticket), ML (detection-backlog ticket + shadow-AI threat doc refresh trigger) - [ ] Sample auto-created tickets from last 3 Critical-tier vendor reviews showing correct metadata - [ ] Downstream backlog aging data: auto-ticket timestamps vs. owner response within 14 days; ≥90% adherence - [ ] Vendor-side SLA tracking registry: per Critical-tier vendor, track vendor notification-time, RCA-delivery-time, and remediation-time against contractual SLAs from DPA/AI addendum; patterns of breach flagged for PC-Vendors contract review - [ ] Quarterly sponsor review: quality assessment of post-incident update outputs; vendor-side SLA breach patterns reviewed

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Post-incident review outputs auto-flowing to SA/SR/EG/ML (% Critical reviews) | % | % | 100% | ☐ | | | Downstream practice owner response within 14 days | % | % | ≥90% | ☐ | | | Critical-tier vendors with active vendor-side SLA tracking (notification + RCA + remediation) | % | % | ≥90% | ☐ | | | Vendor-side SLA breach patterns flagged to PC-Vendors within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Auto-flow rate: Critical_vendor_reviews_with_all_4_auto_tickets / total_Critical_vendor_reviews × 100. Source: integration telemetry - Downstream response: update_tickets_responded_within_14d / total_update_tickets × 100. Source: downstream backlog aging. Monthly - Vendor-side SLA coverage: Count Critical-tier vendors with active notification + RCA + remediation SLA tracking / total Critical-tier vendors × 100. Source: vendor SLA tracking registry - Breach flag timeliness: SLA_breach_patterns_flagged_within_5bd / total_breach_patterns × 100. Source: vendor SLA tracking log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 3

Objective: Industry-coordinated AI-vendor incident response; contribute to AI-vendor incident taxonomy and response playbooks; and automate vendor SLA enforcement including contract-level consequences for SLA breach patterns

Q3.1: Does the program contribute ≥4 times per year to sector ISACs (FS-ISAC, H-ISAC, IT-ISAC) and ≥1 AI-vendor incident taxonomy artifact to standards bodies (CSA, Shared Assessments, OpenSSF AI) with documented adoption?

Evidence Required: - [ ] ISAC participation records: sector ISAC membership (FS-ISAC AI WG, H-ISAC, IT-ISAC, or sector-specific); ISAC AI-vendor incident feeds consumed and integrated into TA-Vendors and ML-Vendors detection libraries quarterly; ≥4 anonymized contributions per year (vendor incident class, containment play used, MTTR, regulatory SLA outcome) - [ ] AI-vendor incident taxonomy contribution: ≥1 classification scheme, severity anchor, or playbook template contributed per year to CSA AI Safety Initiative, Shared Assessments, or OpenSSF AI, with documented adoption or acknowledgement by the receiving body - [ ] ISAC AI-vendor incident exercises attended: at least one per year with documented participation record - [ ] Legal vetting sign-offs for all external contributions; adoption tracking log - [ ] ISAC feed integration records: quarterly confirmation that consumed ISAC AI-vendor intelligence is integrated into TA-Vendors threat library updates and ML-Vendors detection library updates

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | ISAC contributions per year | 0 | ___ | ≥4 | ☐ | | | AI-vendor incident taxonomy contribution to CSA/Shared Assessments/OpenSSF AI per year | 0 | ___ | ≥1 | ☐ | | | ISAC AI-vendor intelligence integrated into TA-Vendors and ML-Vendors quarterly | Yes/No | Yes/No | Yes | ☐ | | | Adoption events (citation or adoption of contributed artifacts) | 0 | ___ | ≥1 | ☐ | |

Metric Collection Guidance: - ISAC contributions: Count anonymized vendor incident-classification submissions per year. Source: ISAC contribution log - Taxonomy contributions: Count classification schemes, severity anchors, or playbook templates contributed to CSA/Shared Assessments/OpenSSF AI per year. Source: contribution log - ISAC feed integration: Quarterly confirmation record that ISAC feeds updated TA-Vendors and ML-Vendors libraries. Source: library update records - Adoption events: Count citations or documented adoptions. Source: adoption tracking log. Semi-annual review

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 8: Automated Vendor SLA Enforcement

Q3.2: Are 100% of Critical vendors under automated SLA tracking covering notification-time, RCA-delivery, and remediation-time, with SLA-breach patterns triggering a PC-Vendors contract-review action within ≤5 business days through a traceable enforcement log?

Evidence Required: - [ ] Automated vendor SLA tracking deployment: 100% of Critical-tier vendors have active automated monitoring of three SLA dimensions, vendor notification-time (from incident discovery to organization notification), RCA-delivery-time (from containment to RCA document delivery), remediation-time (from RCA to confirmed remediation); monitoring source: incident records × DPA/AI addendum SLA values - [ ] SLA breach pattern detection: automated logic that identifies when a vendor has breached their contractual SLA on ≥1 dimension on ≥2 incidents in a rolling 12-month period, generating a contract-review action routed to PC-Vendors owner within ≤5 business days - [ ] Traceable enforcement log: each SLA breach pattern trigger produces an audit trail record in the enforcement log with: vendor name, SLA dimension breached, incident references, breach count, routing date to PC-Vendors, PC-Vendors owner acknowledgement - [ ] PC-Vendors owner in the loop: enforcement log reviewed by PC-Vendors contract owner within ≤5 business days; legal review required before any enforcement action is initiated - [ ] Legal review confirmation: enforcement actions traceable to legal-reviewed records; no unauthorized enforcement actions

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical vendors with automated SLA tracking (all 3 dimensions) | % | % | 100% | ☐ | | | SLA-breach → contract-action lead time | ___ days | ___ days | automated, ≤5 business days | ☐ | | | Enforcement log coverage (% breach triggers with traceable audit record) | % | % | 100% | ☐ | | | Legal review confirmed before enforcement action initiated | % | % | 100% | ☐ | |

Metric Collection Guidance: - SLA tracking coverage: Count Critical-tier vendors with active automated monitoring of all 3 SLA dimensions / total Critical-tier vendors × 100. Source: vendor SLA tracking registry. Reviewed monthly - Lead time: Measure days from SLA breach pattern trigger to PC-Vendors owner acknowledgement. Target: automated routing ≤5 business days. Source: enforcement telemetry - Audit completeness: SLA_breach_triggers_with_enforcement_log_record / total_SLA_breach_triggers × 100. Source: enforcement log - Legal review: enforcement_actions_with_legal_review / total_enforcement_actions_initiated × 100. Source: enforcement log. Reviewed monthly

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 9: MTTR Benchmarking for AI-Vendor Incidents

Q3.3: Are ISAC-shared AI-vendor intelligence feeds integrated into TA-Vendors and ML-Vendors detection libraries quarterly, and is mean-time-to-close on Critical-tier vendor incidents demonstrably compressing as a result of ISAC and playbook improvements?

Evidence Required: - [ ] MTTR benchmark data sources: sector ISAC AI-vendor incident data exchanges, Shared Assessments / CSA observational data, peer roundtables (CISO and vendor-risk practitioner communities), at least two active; updated at least semi-annually - [ ] Quarterly MTTR benchmark brief (last 4 quarters): MTTR per vendor incident class (vendor breach notification, shadow-AI data-exposure, agent runaway, vendor material change, prompt-injection, vendor outage) vs. benchmark; MTTR per tier vs. benchmark; delta trend (improving/stable/degrading) - [ ] Investment-driver section: above-benchmark incident classes mapped to specific practice gap (missing detection, stale coordination channel, unclear playbook) with budget-linked improvement proposal - [ ] Quarterly brief delivery records (last 4 quarters on-time) - [ ] Evidence of MTTR compression: compare MTTR for Critical-tier vendor incidents this year vs. prior year; attribute improvements to specific ISAC intelligence, playbook refinements, or automation

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | MTTR benchmark brief published quarterly to sponsor | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Mean-time-to-close Critical-tier vendor incidents (year-over-year) | ___ days | ___ days | compressing | ☐ | | | Above-benchmark vendor incident classes with investment proposals | % | % | 100% | ☐ | | | Benchmark data source refresh within last 6 months | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Brief cadence: Count MTTR benchmark briefs delivered on schedule per year. Source: program reporting calendar - MTTR compression: Compare median MTTR for Critical-tier vendor incidents in current year vs. prior year. Source: backlog aging data. Annual comparison - Investment proposals: above_benchmark_vendor_classes_with_proposal / total_above_benchmark × 100. Source: brief investment-driver section - Benchmark freshness: Date of most recent external data source update. Target: within 180 days. Source: benchmark refresh log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Summary Scorecard

Question	Level	Activity	Score
Q1: Unified AI-vendor backlog and triage rubric	L1	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q2: AI-vendor incident playbook (5+ vendor plays + material-change)	L1	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q3: Vendor-breach-notification SLA tracker and PIR loop	L1	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q4: Tiered vendor playbook and pre-established coordination channels	L2	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q5: Supply-chain orchestration for multi-integration breaches	L2	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q6: Post-incident review auto-flow and vendor-side SLA tracking	L2	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q7: ISAC contributions and AI-vendor incident taxonomy	L3	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q8: Automated vendor SLA enforcement	L3	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q9: MTTR benchmarking for AI-vendor 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-Vendors 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: Vendors Source of Truth: docs/practices/IM-Vendors-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) - Vendors Assessment

Issue Management (IM) - Vendors Domain

HAIAMM Assessment Questionnaire v3.0

Instructions

Scoring Methodology

Maturity Level 1

Question 1: Unified AI-Vendor Issue Backlog and Triage Rubric

Question 2: AI-Vendor Incident Playbook, Five Vendor-Specific Containment Plays

Question 3: Vendor-Breach-Notification SLA Tracker and Post-Incident Review Loop

Maturity Level 2

Question 4: Tiered Vendor Incident Playbook and Pre-Established Coordination Channels

Question 5: Supply-Chain-Style Orchestration for Multi-Integration Vendor Breaches

Question 6: Post-Incident Review Auto-Flow Integration and Vendor-Side SLA Tracking

Maturity Level 3

Question 7: Industry-Coordinated AI-Vendor Incident Sharing and Contribution

Question 8: Automated Vendor SLA Enforcement

Question 9: MTTR Benchmarking for AI-Vendor Incidents

Summary Scorecard