Issue Management (IM)

Vendors Domain - HAIAMM v3.0

Practice Overview

Objective: Run a single backlog and a single incident playbook for AI-vendor issues, so that findings from TA snapshots, SR requirement gaps, DR conditions, IR drifts, ST failures, and ML detections all flow into one prioritized queue with named owners, SLAs, and a clear path to vendor-breach notification.

Description: IM-Vendors is the clearinghouse for everything the other Vendors practices produce. At L1 it maintains one issue backlog tagged by source (TA, SR, DR, IR, ST, ML, external breach), one triage rubric, one incident playbook specifically for AI-vendor events, and the vendor-breach-notification SLA tracker tied to contractual commitments from PC-Vendors.

Context: Without a unified backlog, AI-vendor issues scatter across Jira projects, engineer dashboards, legal trackers, and TPRM folders, so nothing ages correctly, nothing gets prioritized against anything else, and a vendor breach notification can sit while individual teams wait on each other. L1 IM-Vendors centralizes the queue and standardizes the playbook.

Maturity Level 1

Objective: Operate a single AI-vendor issue backlog with a standard triage rubric, an AI-vendor incident playbook, and vendor-breach-notification tracking

At this level, every AI-vendor issue has a home, a severity, an owner, and an SLA, and incidents follow a named playbook.

Dependencies

• SM-Vendors L1 (required): inventory provides the affected-vendor spine for each issue.
• PC-Vendors L1 (required): contractual breach-notification SLAs, DPA terms, and AUP rules are the basis for severity rubrics and incident response.
• TA-Vendors L1 (required): threat library drives incident-classification taxonomy.
• Supports / unblocks: ML-Vendors L1 (detections flow into this backlog), ST-Vendors L1 (test failures flow in), EH-Vendors L1 (control-surface findings flow in), EG-Vendors L1 (trends feed reviewer calibration and awareness content).

Desired Outcomes

• One backlog, one rubric, one incident playbook for AI-vendor issues.
• AI-vendor incidents are handled on a named playbook, not ad-hoc; legal/privacy/security/business-owner roles are pre-assigned.
• Vendor-breach-notification SLAs (contractual, GDPR Art. 33, HIPAA as applicable) are tracked and never missed.
• Backlog aging is visible to the program sponsor, with a small number of aging buckets the team actively manages.
• Post-incident reviews feed pattern updates (SA), requirement updates (SR), and training (EG), incidents generate organizational learning.

Activities

A) Stand up the AI-vendor issue backlog and triage rubric

One backlog with standardized metadata: - Source, TA / SR / DR / IR / ST / ML / External (vendor disclosure, public breach, customer report). - Affected vendor(s) and integration(s), linked to inventory. - Archetype(s), aligned to TA library. - Severity, blocker / critical / high / medium / low. Rubric anchors severity to: data-class exposure × regulated posture × number of users × whether vendor breach SLA is active. - Owner, named integration owner or vendor-admin owner. - SLA, severity-based (blocker: immediate containment; critical ≤72h to containment / ≤14d to closure; high ≤14d containment / ≤45d closure; medium ≤45d; low ≤90d). - Evidence, link to originating artifact (TA snapshot row, REM gap, IR finding, ST fail, ML alert, external notice).

Triage cadence: daily standup-level triage for new critical/blocker; weekly review for high/medium; monthly aging review for the full backlog.

B) Publish the AI-vendor incident playbook

Playbook entries cover the common AI-vendor incident classes: - Vendor breach notification received, confirm scope, classify affected data, trigger GDPR Art. 33 / HIPAA / contract SLAs, coordinate Legal/Privacy, notify affected users where required, log for deployer-duty evidence. - Vendor outage or degraded service, fallback or kill-switch activation, user communication, post-event review for the SA pattern. - Prompt-injection or output-integrity incident (production AI), containment (feature toggle, tool-scope shrink), scope assessment, customer-communication decision, ML detection tuning. - Shadow-AI data-exposure incident, containment (user credential revoke, API-key rotation, data-exfil assessment), amnesty-path reinforcement, policy-violation routing, deployer-duty evidence capture. - Agent runaway / tool-abuse incident, kill-switch, scope-reduction, session-log capture, human-in-the-loop reinforcement, post-event pattern update. - Vendor material change (model-family swap, plan change, subprocessor addition), trigger re-review in DR/IR, update REM.

Each entry: trigger, named roles, step-by-step, artifacts to collect, closure criteria, SLA targets.

C) Track vendor-breach-notification SLAs and run post-incident reviews

• Breach-SLA tracker: contractual SLA per vendor (from DPA/AI addendum) + regulatory SLAs (GDPR Art. 33 72-hour, HIPAA 60-day, sector-specific).
• Every critical/blocker incident gets a post-incident review within 14 days: what happened, what caught it, what didn't, what SA/SR/EG update falls out.
• Post-incident review outputs feed: SA pattern update queue, SR pack update queue, EG training-content queue, ML detection-backlog, and the shadow-AI threat doc refresh.

Outcome Metrics (L1)

Process Metrics (leading)

• Backlog triage cadence honored, daily critical triage, weekly high/medium, monthly aging.
• Playbook runbook rehearsals, at least one tabletop per quarter exercising an AI-vendor incident scenario.
• Aging pockets, number of items aging beyond their SLA trending down.

Effectiveness Metrics (business value)

• Repeat-class incident rate, a class occurring twice triggers an SA/SR update; repeat rate on the same class trending down.
• Deployer-duty evidence readiness, on an EU AI Act inquiry, the incident records show the logging, oversight, and notification chain.
• Reduced mean-time-to-close across severities over quarters.

Success Criteria

• Single AI-vendor issue backlog established with standardized metadata.
• AI-vendor incident playbook published, with at least 5 named incident classes and assigned roles.
• Vendor-breach-notification SLA tracker live; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA, SR, EG, and ML.
• Program-sponsor dashboard showing backlog aging, SLA adherence, and post-incident learnings refreshed monthly.

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

At this level, incident response differentiates by tier. Critical-tier incidents trigger full IM activation including Legal and Communications; High-tier gets scoped response; Medium/Low follow standard. Pre-established vendor-coordination channels handle Critical-tier vendor-side incidents. When a vendor breach affects multiple org integrations, supply-chain-style orchestration coordinates the response.

Dependencies

• IM-Vendors L1 (required): unified backlog, AI-vendor incident playbook, SLA tracker.
• SM-Vendors L2 (required): tiers drive response intensity.
• ML-Vendors L2 (required): richer detections feed severity classification.

Desired Outcomes

• Response intensity matches tier; Critical incidents don't wait in a general queue.
• Vendor-coordination channels exist before incidents, the first Critical-tier vendor breach is not the day you exchange contact information.
• Multi-integration vendor breaches get orchestrated response (one IC, one comms track, coordinated remediation).

Activities

A) Tiered incident playbook

• Critical: full IM team + Legal + Privacy + Communications + Executive Sponsor; ≤1h acknowledgement; ≤4h containment target.
• High: scoped response team; ≤4h acknowledgement; ≤24h containment target.
• Medium: standard response; ≤1 business day.
• Low: tracked and trended; aggregated handling.

B) Vendor-coordination playbook

• Pre-established comms channels with Critical-tier vendor security/incident teams.
• Template comms, NDA, joint-IR coordination protocol.
• Annual joint tabletop with top-5 Critical vendors.

C) Supply-chain-style orchestration

• When a single vendor breach affects multiple org integrations, IC coordinates across integration owners.
• Shared status board; shared comms; shared remediation tracking.
• Post-incident review spans all affected integrations.

Outcome Metrics (L2)

Process Metrics (leading)

• Playbook review cadence, quarterly.
• Vendor-coord channel health check, quarterly.
• IM on-call coverage, 24/7 for Critical-tier.

Effectiveness Metrics (business value)

• Reduced dwell time on Critical-tier incidents.
• Vendor-cooperation satisfaction (survey vendor IR teams post-exercise).

Success Criteria

• Critical MTTA ≤1h; MTTC ≤4h.
• ≥90% Critical vendors with coordination channel.
• ≥1 joint tabletop per year with top-5 Critical.

Maturity Level 3

Objective: Industry-coordinated incident response; contribute to AI-vendor incident taxonomy and response playbooks; automated SLA enforcement

At this level, incident handling is collaborative beyond the organization. ISAC participation, contribution to shared AI-vendor incident taxonomy, and automated SLA enforcement, including contract-level consequences from vendor SLA breach patterns, become part of the program.

Dependencies

• IM-Vendors L2 (required): tiered playbook, vendor coordination, orchestration.
• PC-Vendors L3 (required): contractual framework for automated SLA enforcement.

Desired Outcomes

• Industry-coordinated response operates, ISACs and peers exchange vendor incident intelligence.
• Program contributes incident classification and playbook patterns to standards bodies.
• Vendor-side SLA adherence is monitored automatically; patterns trigger contract consequences.

Activities

A) Industry-coordinated response

• Contribute and consume vendor-incident intelligence via sector ISACs (FS-ISAC, H-ISAC, IT-ISAC).
• Participate in ISAC AI-vendor incident exercises.

B) Contribute to AI-vendor incident taxonomy

• Classification schemes, severity anchors, response playbook templates contributed to standards (CSA, Shared Assessments, OpenSSF AI).

C) Automated SLA enforcement

• Vendor-side SLA adherence (notification-time, RCA-delivery, remediation-time) monitored from incident records.
• Patterns of breach trigger PC-Vendors contract review / non-renewal recommendation automatically.

Outcome Metrics (L3)

Process Metrics (leading)

• ISAC participation cadence, sector ISAC feeds consumed and contributions submitted at least quarterly; ISAC AI-vendor exercises attended annually.
• Industry contribution pipeline, ≥1 classification scheme, severity anchor, or playbook template in-flight (draft, in-review, published) at any time.
• Automated SLA tracker coverage growth, % Critical vendors with active automated SLA monitoring increasing month-over-month toward 100%.
• Contract-action queue freshness, SLA-breach → contract-action items reviewed within 5 business days with a named PC-Vendors owner.

Effectiveness Metrics (business value)

• Mean-time-to-close on Critical-tier incidents continues to compress quarter-over-quarter as ISAC-shared intelligence accelerates root-cause identification.
• External recognition, citations or adoption of contributed AI-vendor incident taxonomy and playbook templates by CSA, Shared Assessments, or sector standards bodies.
• Avoided-contract-cost, automated SLA enforcement catches vendor SLA breach patterns before manual contract review cycles; estimated avoided remediation and re-procurement costs tracked annually.
• Talent signal, security-operations hires and vendor-risk hires cite the program's ISAC engagement and externalized playbooks as a differentiator.

Success Criteria

• ≥4 ISAC contributions/year.
• ≥1 industry-taxonomy contribution/year.
• 100% Critical vendors under automated SLA tracking.
• Automated SLA-breach → contract action operating with ≤5 business day lead time and a traceable enforcement log.

Key Success Indicators

Level 1: - Single AI-vendor issue backlog operational with standardized metadata (source, affected vendor, archetype, severity, owner, SLA, evidence) covering ≥95% of AI-vendor issues. - AI-vendor incident playbook published with at least 5 named incident classes (vendor breach notification, outage, prompt-injection, shadow-AI data exposure, agent runaway), assigned roles, and SLA targets. - Vendor-breach-notification SLA tracker live and showing 100% adherence in the last 90 days across contractual, GDPR Art. 33, and HIPAA obligations. - Post-incident review loop wired to SA, SR, EG, and ML, every critical/blocker incident produces a review within 14 days. - Program-sponsor dashboard refreshed monthly showing backlog aging, SLA adherence, and post-incident learnings.

Level 2: - Tiered incident playbook operational, Critical MTTA ≤1h, MTTC ≤4h; High MTTA ≤4h; each tier with named roles and pre-staged comms templates. - ≥90% of Critical-tier vendors have pre-established coordination channels (comms, NDA, joint-IR protocol) before any incident occurs. - ≥1 joint tabletop per year with the top-5 Critical vendors; supply-chain orchestration used for 100% of multi-integration vendor breaches. - 24/7 IM on-call coverage for Critical-tier; playbook reviewed quarterly.

Level 3: - ≥4 ISAC contributions per year and ≥1 AI-vendor incident taxonomy contribution to CSA/Shared Assessments/OpenSSF AI with documented adoption. - 100% of Critical vendors under automated SLA tracking; SLA-breach → contract-action pipeline operating with ≤5 business day lead time. - Mean-time-to-close on Critical-tier incidents compressing quarter-over-quarter; avoided-contract-cost tracked annually from automated enforcement. - Quarterly ISAC AI-vendor intelligence feeds consumed and integrated into TA-Vendors and ML-Vendors detection libraries.

Common Pitfalls

Level 1: - ❌ "Single backlog" created but teams continue filing AI-vendor issues in separate Jira projects, engineering dashboards, and TPRM folders, the unified queue never achieves ≥95% coverage. - ❌ Triage rubric severity anchors are generic (probability × impact) without AI-vendor-specific axes, regulated-data exposure class and whether a vendor breach SLA is active are never factored in. - ❌ Playbook published but roles not pre-assigned, on the first live incident, the team spends the first hour figuring out who calls Legal, not containing the breach. - ❌ GDPR Art. 33 72-hour clock tracked informally; when a vendor breach notification arrives on a Friday afternoon the SLA slips before anyone documents a start time. - ❌ Post-incident reviews completed but outputs filed in a doc nobody reads, SA, SR, EG, and ML queues are never updated, and the same incident class recurs. - ❌ Vendor material-change incidents (model-family swap, subprocessor addition) not recognized as playbook triggers, DR and IR re-review never happens.

Level 2: - ❌ Tiered playbook written but Critical-tier activation criteria are vague, incidents that qualify for full-team + Legal + Communications activation stay in the standard queue until an executive escalates them. - ❌ Vendor-coordination channels established on paper but not tested, NDAs are unsigned, contact lists are stale, and the "pre-established" channel doesn't actually exist when the first Critical-tier incident fires. - ❌ Joint tabletop scheduled annually but scoped to generic IR scenarios rather than AI-vendor-specific classes (vendor model swap mid-incident, prompt-injection affecting customer-facing output); rehearsal value is low. - ❌ Supply-chain orchestration protocol exists for multi-integration breaches but no IC role is pre-designated; the first multi-integration vendor breach triggers ownership confusion across integration teams.

Level 3: - ❌ ISAC participation limited to consuming feeds, contributions are missing, and the program gets labeled a free-rider; influence over AI-vendor incident taxonomy standards diminishes. - ❌ Automated SLA tracking monitors notification-time but not RCA-delivery or remediation-time, the two SLA dimensions most often breached by AI vendors go untracked. - ❌ SLA-breach → contract action pipeline fires automatically but PC-Vendors contract-owner is not in the loop; enforcement actions are initiated without legal review, creating liability. - ❌ Industry taxonomy contributions reflect L1/L2 practice maturity, not L3, what is published doesn't match internal playbook sophistication, undermining external credibility.

Practice Maturity Questions

Level 1: 1. Is there a single AI-vendor issue backlog with standardized metadata (source, affected vendor, 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? 2. Is the AI-vendor incident playbook published with ≥5 named AI-vendor incident classes, pre-assigned roles, SLA targets, and evidence-collection steps, and has it been exercised in at least one tabletop in the last 90 days? 3. Is a vendor-breach-notification SLA tracker live covering contractual, GDPR Art. 33, and HIPAA obligations, with 100% adherence in the last 90 days and post-incident reviews wired to SA, SR, EG, and ML queues within 14 days of every critical/blocker closure?

Level 2: 1. Is a tiered incident playbook operational with Critical MTTA ≤1h and MTTC ≤4h, named full-team activation criteria (Legal, Privacy, Communications, Executive Sponsor), and 24/7 on-call coverage for Critical-tier? 2. Are ≥90% of Critical-tier vendors covered by pre-established, tested coordination channels (comms, NDA, joint-IR protocol) with at least one joint tabletop per year with the top-5 Critical vendors? 3. Is supply-chain 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?

Level 3: 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? 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? 3. Are ISAC-shared vendor incident intelligence feeds integrated into TA-Vendors and ML-Vendors detection libraries quarterly, and is mean-time-to-close on Critical-tier incidents demonstrably compressing as a result?

Document Version: HAIAMM v3.0 Practice: Issue Management (IM) Domain: Vendors Last Updated: 2026-05-12 Author: Verifhai