> **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`](../practices/IM-Vendors-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: 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

**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-vendor incident playbook)

**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

**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 vendor-breach-notification SLA tracker)

**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

**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 tiered vendor incident playbook or coordination channels)

**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

**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 supply-chain orchestration for vendor breaches)

**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

**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 or vendor-side SLA tracking)

**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

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

**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

**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 AI-vendor incident contribution program)

**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

**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 automated vendor SLA enforcement)

**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

**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 AI-vendor incidents)

**Evidence Location:** _________________________________

**Metric Validation Date:** _________________________________

**Notes:** ___________________________________________

---

## Summary Scorecard

| Question | Level | Activity | Score | Notes |
|----------|-------|----------|-------|-------|
| 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