Issue Management (IM)

Endpoints Domain - HAIAMM v3.0

Practice Overview

Objective: Run the single unified backlog for AI/HAI endpoint issues across the Endpoints domain, findings from TA-Endpoints, SR-Endpoints, DR-Endpoints, IR-Endpoints, ST-Endpoints, ML-Endpoints, and external advisories, with a tier-calibrated incident playbook containing AI-specific containment plays for the primary endpoint incident classes, and regulatory SLA tracking (GDPR Art. 33, EU AI Act Art. 50 transparency failure remediation, EU AI Act Art. 73 serious-incident reporting, HIPAA, PCI-DSS endpoint breach, sector-specific).

Description: IM-Endpoints is the clearinghouse for everything the other Endpoints-domain practices produce. Every TA-Endpoints threat snapshot row carrying residual risk, every SR-Endpoints REM accepted gap, every DR-Endpoints approve-with-conditions item, every IR-Endpoints drift finding, every ST-Endpoints test failure, every ML-Endpoints detection alert, and every external advisory (vendor SaaS-AI advisories, browser extension store flags, mobile app store security flags, edge-device CVEs, MITRE ATLAS endpoint-technique updates) flows into a single prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous incident playbook. The playbook includes AI-specific endpoint containment plays, regulated-data egress via AI assistant (endpoint-isolate, DLP-rule-tune, GDPR Art. 33 evaluation), unsanctioned browser extension (extension force-remove, data-flow assessment), SaaS-AI silent-enablement (feature-disable, intake-amnesty, GDPR Art. 33 evaluation), chatbot abuse / jailbreak at scale (rate-limit tighten, prompt-injection corpus update), multi-modal injection incident (input-validation tighten, output-filter update), mobile-AI integrity failure (MDM force-update, model re-pin), and edge-device tamper (remote-disable, firmware re-attestation). Every Critical or blocker incident receives a post-incident review whose outputs flow back to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints. The regulatory SLA tracker ensures GDPR Art. 33 72-hour breach notification, EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73 serious-incident reporting, and sector-specific windows are never missed.

Context: Without a unified backlog, AI/HAI endpoint issues scatter across MDM dashboards, DLP alert queues, SaaS-admin change logs, mobile-device security consoles, edge device management platforms, and product-team backlogs. A browser extension force-installed by a user that bypassed MDM policy sits in the MDM event log for two weeks before anyone recognizes it as a data-exfiltration risk. A SaaS vendor's AI feature is silently enabled by an admin; the privacy team finds out when a GDPR data subject inquiry mentions AI-processed emails. A chatbot jailbreak campaign runs over a weekend; the ML-Endpoints alert fires but routes to a queue nobody checks until Monday. An edge device with failed attestation continues to operate because the tamper alert went to a ticketing system with no on-call owner. IM-Endpoints closes all of these gaps with a single backlog, a single triage rubric, and a named on-call path for every severity class.

Maturity Level 1

Objective: Operate a single unified AI/HAI endpoint issue backlog with a standard triage rubric, AI-specific incident playbook including containment plays for the primary endpoint incident classes, and regulatory SLA tracking for GDPR Art. 33, EU AI Act Art. 50 and Art. 73, HIPAA, PCI-DSS, and sector-specific obligations

At this level, every AI/HAI endpoint issue has a home, a severity, an owner, and an SLA, and incidents follow a named playbook with AI-specific endpoint containment actions rather than generic IT incident response.

Dependencies

• SM-Endpoints L1 (required): the inventory provides the affected-archetype and owning-team spine for every issue; without the inventory, the backlog cannot route issues to accountable owners.
• PC-Endpoints L1 (required): priority compliance map anchors the regulatory SLA tracker (GDPR Art. 33, EU AI Act Art. 50 and Art. 73, HIPAA, PCI-DSS endpoint breach, COPPA, FERPA, sector-specific); triage rubric severity definitions reference compliance exposure.
• TA-Endpoints L1 (required): archetype threat library drives the incident classification taxonomy and the AI-specific endpoint incident classes in the playbook.
• ML-Endpoints L1 (required): detections from ML-Endpoints are the primary runtime input to the issue backlog; without ML-Endpoints L1, the detection-to-backlog feed does not exist and runtime endpoint incidents go unreported until they are externally visible.
• Supports / unblocks: ML-Endpoints L1 (post-incident reviews feed detection tuning back into ML-Endpoints); SA-Endpoints L1 (post-incident reviews generate pattern-update requests); SR-Endpoints L1 (post-incident reviews generate requirements-pack update requests); EG-Endpoints L1 (incident trends feed training-content updates).

Desired Outcomes

• One backlog, one triage rubric, one incident playbook for all AI/HAI endpoint issues, regardless of source practice or endpoint archetype.
• AI-specific endpoint incident classes are handled on named playbook entries with pre-assigned roles, containment steps, and SLA targets, not improvised at incident time.
• Regulatory SLA tracker is live and showing zero missed notification windows for GDPR Art. 33, EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA, PCI-DSS endpoint breach, COPPA (children-facing endpoints), FERPA (educational endpoints), and sector-specific obligations in the last 90 days.
• Post-incident reviews for Critical / blocker incidents produce named updates to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints within 14 days of incident closure, incidents generate organizational learning, not just closure tickets.
• Backlog aging is visible to the program sponsor monthly; a small number of aging buckets are actively managed with clear escalation paths.

Activities

A) Stand up the AI/HAI endpoint issue backlog and triage rubric

One backlog with standardized metadata:

• Source, TA-Endpoints (threat snapshot residual risk) / SR-Endpoints (REM accepted gap) / DR-Endpoints (approve-with-conditions item) / IR-Endpoints (drift finding) / ST-Endpoints (test failure, red-team finding) / ML-Endpoints (detection alert) / External (vendor SaaS-AI advisory, browser extension store flag, mobile app store security flag, edge-device CVE, MITRE ATLAS endpoint-technique update, customer report).
• Affected archetype(s), linked to SM-Endpoints inventory; archetype, tier, owning team.
• Severity, Critical / High / Medium / Low per the rubric below.
• Owner, named archetype owner from the SM-Endpoints inventory; escalation path to program sponsor.
• SLA, severity-based (published at L1; per-tier calibrated at L2).
• Evidence, link to originating artifact (TA snapshot row, REM gap row, DR decision, IR finding, ST test result, ML alert ticket, external advisory URL).
• Regulatory flag, whether the issue carries a regulatory notification obligation (GDPR Art. 33 clock started, EU AI Act Art. 50 transparency failure identified, EU AI Act Art. 73 clock started, HIPAA breach-notification triggered, PCI-DSS endpoint breach identified, COPPA or FERPA implication, sector-specific).

Severity rubric (AI/HAI endpoint specific):

• Critical, regulated data actively exfiltrated via an AI/HAI endpoint; chatbot or multi-modal AI interface operating without EU AI Act Art. 50 disclosure at scale (Art. 50 transparency failure); edge AI device physically tampered with and continuing to operate; personal data breach via AI endpoint triggering GDPR Art. 33; mobile AI app serving a compromised local model to a large user cohort; SaaS-AI feature processing regulated data without approved data-scope and GDPR Art. 33 trigger assessment required.
• High, confirmed control failure in a production AI/HAI endpoint archetype with potential for harm if not contained (DLP allow event for regulated customer data to an AI assistant; unsanctioned browser extension with data-access permissions installed on ≥10 endpoints; edge device attestation failure with network access; chatbot jailbreak campaign at scale with customer-facing impact; SaaS-AI feature enabled tenant-wide without intake where regulated data may be in scope).
• Medium, confirmed gap in a non-production archetype or a production archetype with compensating controls active; no current active impact; SR-Endpoints REM accepted gap past expiry; IR-Endpoints drift finding on a Medium-tier archetype; single mobile-app model integrity failure without evidence of broader cohort impact.
• Low, informational; non-urgent gap; recommendation from an external advisory not yet assessed; Low-tier archetype logging gap; edge-device CVE not yet assessed for applicability.

SLA targets (published at L1, per-tier calibrated at L2):

• Critical: acknowledge ≤4 hours / contain ≤48 hours / root-cause ≤30 days.
• High: acknowledge ≤24 hours / contain ≤7 days / root-cause ≤45 days.
• Medium: acknowledge ≤48 hours / remediate ≤14 days.
• Low: acknowledge ≤5 business days / remediate ≤30 days.

Triage cadence: daily review for Critical and new High; weekly queue review for Medium; monthly aging review for the full backlog.

B) Publish the AI-specific endpoint incident playbook

Publish playbook entries for the primary AI/HAI endpoint incident classes. Each entry includes: trigger conditions, named roles (endpoint-security on-call, Privacy/Legal contact, SaaS-admin owner, executive sponsor escalation path), step-by-step containment, artifacts to collect, evidence-capture instructions for the deployer-duty record, closure criteria, and SLA targets.

Playbook entries (at L1, publish all of the following):

Regulated-data egress via AI assistant: Trigger: ML-Endpoints detection of DLP-allow event where data class is regulated and the destination is an AI tool endpoint. Containment: (1) endpoint-isolate the affected managed endpoint from AI provider network access via MDM policy update; (2) assess scope, which principal, which AI tool, which data class, what volume of regulated data may have been transmitted; (3) confirm the DLP rule that should have blocked this event and identify why it allowed; (4) tune the DLP rule to block this pattern; (5) route to Privacy/Legal for GDPR Art. 33 evaluation, clock starts at ML-Endpoints detection time if breach is plausible; (6) assess affected data, what regulated data was transmitted, to which AI provider, under which no-train commitment. Evidence: ML-Endpoints DLP allow event, affected session log export, DLP rule configuration before and after tune, GDPR Art. 33 assessment record, deployer-duty record update. User coaching referral to EG-Endpoints.

Unsanctioned browser extension: Trigger: ML-Endpoints detection of extension-install event where extension ID is not in the SM-Endpoints allowlist. Containment: (1) extension force-remove via MDM browser policy update to the affected endpoint or endpoint cohort; (2) update the extension block list in the browser policy to prevent reinstall; (3) assess data-flow: which data the extension had permission to access and whether any data-transfer events are present in the ML-Endpoints log for the extension's network endpoints; (4) user coaching: route principal to EG-Endpoints for policy-awareness training; (5) if data-transfer events indicate regulated data may have been transmitted, escalate to Privacy/Legal for GDPR Art. 33 evaluation. Evidence: ML-Endpoints extension-install event, extension permission-grant events, browser activity log for the extension process, MDM policy update record, user coaching referral.

SaaS-AI silent-enablement (shadow AI in SaaS): Trigger: ML-Endpoints detection of SaaS-admin AI feature-enablement event with no matching SM-Endpoints intake approval record. Containment: (1) feature-disable: coordinate with the SaaS admin to disable the enabled AI feature or reduce its scope to zero pending intake review; (2) admin-audit review: pull the full SaaS-admin audit log for the feature-enablement change, identify who enabled it, via which mechanism (console / API / provider-initiated), and when; (3) intake-amnesty path: route the feature through the SM-Endpoints intake process; if the feature passes intake, re-enable with approved scope and documented no-train confirmation; (4) data-scope assessment: determine what data the AI feature processed while active without approval; (5) GDPR Art. 33 evaluation if regulated data flowed: if the feature processed regulated data (PII, PHI) without a documented lawful basis or data-processing agreement covering the AI feature, assess GDPR Art. 33 and Art. 28 obligations. Evidence: ML-Endpoints SaaS-admin audit event, SaaS-admin audit log export for the feature, intake review record, data-scope assessment, GDPR evaluation record.

Chatbot abuse / jailbreak at scale: Trigger: ML-Endpoints abuse-detection event of type jailbreak-attempt or prompt-injection-attempt at volume above threshold, or ST-Endpoints chatbot-abuse red-team finding in production scope. Containment: (1) rate-limit tighten: reduce per-session and per-IP rate limits for the affected chatbot endpoint to limit ongoing abuse volume; (2) prompt-injection corpus update: add confirmed jailbreak patterns from the incident to the ST-Endpoints regression corpus and the ML-Endpoints detection query; (3) output-filter tune: update the chatbot's output-safety filter rules to address any new output patterns observed in the abuse campaign; (4) assess customer impact: review chatbot session logs for the abuse window to determine whether any customers received injected or unsafe outputs; (5) customer communications if material: if abuse campaign produced customer-facing unsafe outputs at scale, prepare and deliver customer communication per the Legal-reviewed template. Evidence: ML-Endpoints abuse-detection events, session log export for the abuse window, rate-limit configuration change record, prompt-injection corpus update record, output-filter rule change record.

Multi-modal injection incident: Trigger: ML-Endpoints output safety-filter event with category indicating injected or unsafe content originating from a multi-modal input (image, audio, video), or ST-Endpoints multi-modal injection test finding. Containment: (1) modality-specific input-validation tighten: for the modality identified as the injection vector (image / audio / video), update the input-validation rule (content-hash allowlist, MIME-type restriction, input-size limit) to reject the class of inputs that enabled the injection; (2) output safety-filter update: update the output safety-filter rules to cover the newly identified output pattern; (3) regression-corpus update: add the confirmed injection payload (or its hash) to the ST-Endpoints multi-modal injection regression corpus; (4) assess customer impact: if injected outputs were delivered to customers, assess scope and prepare customer communication if material. Evidence: ML-Endpoints input event and output safety-filter event, affected session log export, input-validation rule change record, output-filter rule change record, regression-corpus update record.

Mobile-AI integrity failure: Trigger: ML-Endpoints local-model integrity event with result fail for a mobile AI app. Containment: (1) app force-update via MDM: push a mandatory app update to all affected devices via the enterprise MDM (Intune, Jamf, or equivalent) to restore a known-good app version with a verified model; (2) local-model signature re-pin: update the reference hash for the local model in the SM-Endpoints inventory and in the app's model-verification configuration; (3) affected-installs assessment: identify the scope of devices with the failed integrity check, how many devices, which principal cohort, how long the failure was present before detection; (4) assess whether the compromised model produced outputs that reached customers or influenced decisions with regulatory significance; (5) if customer-affecting AI outputs originated from a compromised model, notify affected customers and assess EU AI Act Art. 26 and Art. 50 implications. Evidence: ML-Endpoints model-integrity event, MDM force-update record, model-hash re-pin record, affected-installs assessment.

Edge-device tamper: Trigger: ML-Endpoints physical-tamper event with tamper sensor triggered, or boot-attestation event with result fail on a Critical-tier edge AI device. Containment: (1) remote-disable: immediately remotely disable the affected edge device via the edge device management console; document the remote-disable timestamp and invoking principal; (2) physical-recovery procedure: dispatch physical-recovery team to the device location per the physical-security recovery SOP; device is not re-enabled until physical inspection confirms no tamper; (3) firmware re-attestation: after physical inspection and any required firmware re-flash, perform a full boot-attestation cycle; confirm attestation result pass before re-enabling network uplink; (4) affected-data assessment: assess what data the device processed, transmitted, or received during the period between the tamper event and the remote-disable; if regulated data was involved, assess GDPR Art. 33 obligations; (5) update the SM-Endpoints device record with the incident reference and re-attestation confirmation. Evidence: ML-Endpoints tamper event and boot-attestation events, remote-disable record, physical-inspection report, firmware re-attestation record, affected-data assessment.

C) Track regulatory SLAs and run post-incident reviews

Regulatory SLA tracker, live, named obligation, with automated escalation on approach:

• GDPR Art. 33, 72-hour supervisory-authority notification window after the controller becomes aware of a personal data breach; clock starts on the first internal alert that constitutes awareness (ML-Endpoints detection, IR-Endpoints finding, external notification). Named owner: Privacy/Legal. Any GDPR Art. 33 clock started from an AI/HAI endpoint incident is flagged in the IM-Endpoints backlog record; daily-at-minimum status update required until the notification is filed or the clock expires.
• EU AI Act Art. 50 transparency failure remediation, when an Art. 50 disclosure suppression or failure is identified (ML-Endpoints detection or ST-Endpoints test failure), the affected customer-facing AI endpoint must be remediated (disclosure restored and confirmed by ST test) within a documented SLA; if the suppression affected customers at scale, regulatory notification assessment is required. Named owner: Privacy/Legal + product deployer-duty owner.
• EU AI Act Art. 73 serious incident, serious incident involving a high-risk AI system (Annex III) or an AI system posing an unacceptable risk from the Endpoints domain; reporting timeline per the implementing act; track and escalate to Privacy/Legal immediately on any Annex III-classified endpoint archetype incident. Named owner: Privacy/Legal + executive sponsor.
• HIPAA breach notification, 60-day discovery-to-notification ceiling for covered entities and business associates; flag any AI/HAI endpoint incident involving PHI immediately. Named owner: Privacy/Legal.
• PCI-DSS endpoint breach, cardholder data breach notification requirements from an AI/HAI endpoint; named owner per the org's PCI compliance program.
• COPPA, children-facing endpoint incidents (chatbot or conversational UI serving minors); child data privacy notification obligations. Named owner: Privacy/Legal.
• FERPA, educational endpoint incidents involving student data. Named owner: Privacy/Legal.
• Sector mobile-banking, mobile AI app incidents in sector-regulated mobile banking environments. Named owner: per the org's sector compliance program.

Every Critical or blocker incident receives a post-incident review within 14 days of containment: - What happened: root cause, how the incident initiated, what controls failed or were absent. - What caught it: which ML-Endpoints detection, IM source, or external report surfaced it first; was this the expected detection path or a gap? - What did not catch it: which controls should have detected or prevented this but did not. - Update outputs (all four must be populated for Critical incidents): - SA-Endpoints: pattern-update request if the incident exploited an architectural gap. - SR-Endpoints: requirements-pack update request if the incident exploited a missing or vague requirement. - EG-Endpoints: training-content update request if the incident indicates a literacy gap in the workforce population using or managing AI endpoints. - ML-Endpoints: detection-update request (new detection, tuned query, or evidence that an existing detection's query can be sharpened).

Outcome Metrics (L1)

Process Metrics (leading)

• Backlog triage cadence honored, daily Critical/High triage; weekly Medium; monthly aging.
• Playbook runbook rehearsal, at least one tabletop per quarter exercising an AI-specific endpoint incident scenario (rotate through the seven playbook classes).
• Regulatory SLA tracker reviewed weekly; named owner confirms clock start dates and status.
• Aging pockets, number of issues aging past SLA tracked; trending down.
• External advisory intake cadence, vendor SaaS-AI advisories, browser-extension store flags, mobile-app-store security flags, and edge-device CVEs reviewed weekly; applicable advisories routed to the backlog within 5 business days.

Effectiveness Metrics (business value)

• Repeat-class incident rate, an incident class occurring twice in 12 months without producing a SA/SR/EG/ML update after the first occurrence is a process failure; repeat rate on same class trending down.
• Deployer-duty evidence chain, on a GDPR Art. 33 inquiry, EU AI Act Art. 50 audit, or PCI-DSS assessment, the incident records show the logging, containment, and notification chain for the affected endpoint archetype; evidence assembled within ≤5 business days.
• Mean-time-to-contain across Critical and High-severity AI/HAI endpoint incidents trending down over quarters.

Success Criteria

• Single AI/HAI endpoint issue backlog established with standardized metadata; triage rubric with AI-specific severity definitions published.
• Seven AI-specific endpoint incident playbook entries published (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper), each with named roles, containment steps, evidence-capture instructions, and SLA targets.
• Regulatory SLA tracker live covering GDPR Art. 33, EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA, PCI-DSS endpoint breach, COPPA, FERPA, and sector-specific obligations; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints; every Critical/blocker incident produces a review within 14 days with named update outputs.
• Program-sponsor dashboard showing backlog aging, SLA adherence, and post-incident learning outputs refreshed monthly.

Maturity Level 2

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

At this level, incident response differentiates by tier. Critical-tier endpoint archetypes have a dedicated on-call rotation, pre-staged executive escalation paths, and a 24/7 coverage model. High-tier archetypes have scoped response with defined escalation. Medium and Low follow the standard queue. Post-incident reviews auto-feed SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints queues via integration rather than manual handoff. When an AI/HAI endpoint incident affects cross-domain scope (a managed-endpoint AI assistant whose data-exfiltration reaches a Software-domain LLM backend, or a SaaS-AI feature whose data-scope encompasses a Data-domain training corpus, or a chatbot whose output corruption affects a Processes-domain business workflow), coordinated cross-domain response is activated.

Dependencies

• IM-Endpoints L1 (required): unified backlog, AI-specific endpoint incident playbook, and regulatory SLA tracker must be operational before per-tier calibration adds meaningful depth.
• SM-Endpoints L2 (required): risk-tier rubric (Critical / High / Medium / Low) and tier-treatment matrix drive response intensity; without SM-Endpoints L2 tiers, per-tier incident response has no substrate.
• ML-Endpoints L2 (required): richer detections (anomaly-based, cross-archetype correlated) feed severity classification with higher-fidelity signals; tier-calibrated logging depth makes evidence collection faster and more complete at L2.
• Supports / unblocks: ML-Endpoints L2 detection tuning loop (IM-Endpoints L2 post-incident reviews, now with tier-context, produce more targeted detection updates); SA-Endpoints L2 pattern evolution (incidents from Critical-tier archetypes with IaC-encoded configurations drive conformance-test updates).

Desired Outcomes

• Response intensity matches tier, Critical-tier endpoint incidents do not wait in the general queue; they activate a named response team, a dedicated on-call path, and the full containment playbook within the published SLA.
• Post-incident review outputs auto-flow to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints backlogs via a defined integration rather than manual handoff, no update gets lost in a shared document.
• Cross-domain coordination is explicit: an Endpoints-domain incident that implicates the Software domain (a managed-endpoint AI assistant data-exfiltration that reaches an LLM-backend service), the Data domain (a SaaS-AI feature that processed a training corpus without approval), or the Processes domain (a chatbot output corruption that affected a customer-service workflow) activates a named cross-domain coordination protocol.
• Tier-movement in the SM-Endpoints inventory auto-triggers IM-Endpoints policy changes: when an archetype is re-tiered to Critical, the on-call path, playbook variant, and SLA targets are automatically updated in the IM-Endpoints backlog configuration.

Activities

A) Tier-calibrated incident playbook and on-call

Extend L1 playbook entries with tier-specific activation criteria and on-call coverage:

• Critical tier: full IM activation, CISO or delegate + Privacy/Legal + endpoint-security deployer-duty owner + executive sponsor notification; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named AI/HAI endpoint incident responder in each on-call rotation; pre-staged communication templates (internal, customer-facing, regulatory) loaded and reviewed quarterly.
• High tier: scoped response team, endpoint-security lead + Privacy/Legal (if regulated data involved) + deployer-duty owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with after-hours escalation path defined.
• Medium tier: standard response; ≤1 business day acknowledgement; queue-based triage.
• Low tier: tracked in queue; aggregated weekly handling.

Critical-tier on-call rotation documented: named individuals per week, coverage handoff protocol, on-call briefing that includes the current Critical-tier archetype list, active detection set, and known compensating controls or gaps.

B) Post-incident review auto-flow integration

• Wire IM-Endpoints post-incident review outputs to downstream practice backlogs via a defined integration:
• SA-Endpoints pattern-update request → SA-Endpoints architecture-backlog ticket (auto-created with IM-Endpoints incident reference linked).
• SR-Endpoints requirements-pack update request → SR-Endpoints pack-backlog ticket (auto-created with requirements-pack version and failing requirement row linked).
• EG-Endpoints training-content update request → EG-Endpoints training-backlog ticket (auto-created with affected population segment and incident summary linked).
• ML-Endpoints detection-update request → ML-Endpoints detection-registry update ticket (auto-created with detection name, current query, and proposed change linked).
• SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days; accepted updates are treated as High-severity issues in the receiving practice's backlog.
• Post-incident review quality reviewed quarterly by the program sponsor, are the update outputs substantive (concrete change to a pattern, pack, curriculum, or detection) or nominal?

C) Cross-domain coordination protocol

Publish a cross-domain coordination protocol that activates when an Endpoints-domain AI/HAI incident implicates another domain:

• Endpoints → Software: a managed-endpoint AI assistant data-exfiltration incident reveals that regulated data was transmitted to a Software-domain LLM-backend service; activates Software-domain EH and IM alongside Endpoints-domain containment. Named Software-domain IM contact on file.
• Endpoints → Data: a SaaS-AI feature enabled without intake approval processed data that is classified as a Data-domain training corpus or prompt/completion log corpus; activates Data-domain EH and IM alongside Endpoints-domain SaaS-AI silent-enablement play. Named Data-domain IM contact on file.
• Endpoints → Processes: a customer-facing chatbot output-corruption incident (multi-modal injection or jailbreak-at-scale producing harmful outputs) affected a customer-service workflow that routes outputs to a business-process decision; activates Processes-domain business-continuity coordinator alongside Endpoints-domain chatbot abuse play. Named Processes-domain IM contact on file.

Cross-domain incident activations: shared status board, one unified incident commander (IC) from the primary impacted domain, coordinated remediation tracking, and a joint post-incident review spanning all affected domains.

Outcome Metrics (L2)

Process Metrics (leading)

• Critical-tier playbook review cadence, quarterly, tested in a tabletop covering the tier's specific archetype list.
• On-call rotation health, no uncovered periods; handoff briefing completed per rotation; on-call briefing includes updated Critical-tier archetype list.
• Post-incident review quality score, sponsor reviews a sample quarterly; nominal updates flagged for improvement.
• Cross-domain coordination contacts verified quarterly, named contacts are current, communication channels tested.

Effectiveness Metrics (business value)

• Dwell time on Critical-tier incidents (time from first ML-Endpoints detection to containment action complete) trending down as L2 matures.
• Downstream practice update acceptance rate, % of Critical-tier post-incident updates accepted and resolved by the downstream practice; measures whether the feedback loop actually improves the program.
• Cross-domain coordination saves time vs. uncoordinated parallel response, measured as MTTU and MTTC on multi-domain Endpoints incidents.

Success Criteria

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML-Endpoints backlogs; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents.
• Tier-movement in SM-Endpoints inventory auto-triggers IM-Endpoints configuration update (on-call path, playbook variant, SLA targets).

Maturity Level 3

Objective: Contribute endpoint incident patterns and playbook templates to CSA Endpoint, OWASP MASVS, and sector ISACs; automate runbook decisioning for low-severity, high-confidence detections; and benchmark MTTR against industry peers

At this level, IM-Endpoints is a contributor to the AI-assurance endpoint incident-response ecosystem. Anonymized endpoint incident classification schemes, AI-specific severity anchors, and playbook templates for the seven primary AI/HAI endpoint incident classes are contributed to sector ISACs, CSA Endpoint AI Safety Initiative, and OWASP MASVS. Pre-authorized automated containment actions execute for low-severity, high-confidence detections without human triage delay, force-removing an unsanctioned browser extension, disabling a shadow-AI SaaS feature, remotely disabling a tampered edge device, within seconds of detection. Mean-time-to-resolve benchmarks are established from ISAC and peer data.

Dependencies

• IM-Endpoints L2 (required): tiered playbook, post-incident review auto-flow, and cross-domain coordination must be operational and producing clean incident-pattern data before contributions to external bodies are substantive.
• PC-Endpoints L3 (required): continuous compliance attestation substrate supports automated evidence capture for pre-authorized containment actions; legal authority for automated actions flows from the policy and compliance program.
• ML-Endpoints L3 (required): detection-as-code and high-confidence anomaly detection signals provide the automation trigger quality needed for pre-authorized runbook execution.

Desired Outcomes

• Industry-standard incident classification and response playbooks for AI/HAI endpoint incidents are contributed and maintained, sector ISACs, OWASP MASVS, and CSA cite the org's artifacts.
• Pre-authorized automated containment actions execute for a defined set of low-severity, high-confidence endpoint incident types, reducing MTTR for these classes to seconds from hours.
• MTTR benchmarks are established from ISAC and peer data; the program's performance against benchmarks is reported to the sponsor quarterly and drives investment decisions.
• Contributions to CSA Endpoint AI Safety Initiative and OWASP MASVS reflect the org's first-party endpoint incident experience with AI/HAI endpoint containment plays.

Activities

A) Industry-coordinated endpoint incident sharing and contribution

• Participate in sector ISAC AI endpoint incident-sharing programs (FS-ISAC AI working group, mobile-banking AI endpoint incidents; H-ISAC, patient-facing chatbot incidents; IT-ISAC, managed-endpoint AI incidents):
• Consume ISAC AI endpoint incident feeds; integrate relevant advisories into the IM-Endpoints external-advisory source.
• Contribute anonymized endpoint incident classification (incident type, ATLAS tactic tag, HAI-TTP tag, archetype, containment play used, MTTR achieved) on a per-incident-class basis; target ≥4 ISAC contributions per year.
• Contribute to AI endpoint incident standards:
• CSA Endpoint AI Safety Initiative, AI endpoint severity-anchor definitions, playbook template schemas for the seven endpoint incident classes, SaaS-AI shadow-enablement response templates.
• OWASP MASVS, mobile AI app incident response patterns (model-integrity failure response, on-device data-breach response); contribute verification requirements for mobile AI app incident-response capability.
• Contribute to MITRE ATLAS endpoint-technique documentation, submit endpoint-derived technique observations or mitigation entries for endpoint-relevant tactics; target ≥1 ATLAS contribution per year for Endpoints-primary tactics.

B) Pre-authorized automated runbook decisioning

Define and publish a pre-authorization policy for automated containment actions, the set of actions that can execute without human approval when a detection fires at a defined confidence threshold:

• Pre-authorized actions (examples; published list vetted by Privacy/Legal and executive sponsor):
• Extension force-remove for a Low-tier or Medium-tier endpoint when an unsanctioned-browser-extension detection fires above 95% confidence threshold (extension ID definitively not in allowlist, data-access permissions confirmed).
• SaaS-AI feature disable for a shadow-AI-in-SaaS detection on a non-Critical-tier SaaS feature (feature enablement event with no intake record, confidence threshold: feature ID definitively not in approved list).
• Edge-device remote-disable for a tamper-detection event on a non-Critical-tier edge device when a physical-tamper event fires above 99% confidence threshold.
• Rate-limit emergency-tighten for a customer-facing chatbot when a chatbot-abuse-pattern-at-scale detection fires above 90% confidence threshold (volume and pattern both exceeded).
• Pre-authorized actions for Critical-tier archetypes require human confirmation within 15 minutes; the action fires after that window if no human confirmation arrives (timer-based fallback), with executive notification at fire time.
• All pre-authorized actions produce: a full audit log entry in the IM-Endpoints backlog, a human-review ticket auto-created at the time of execution, and a notification to the archetype's deployer-duty owner.
• Pre-authorization policy reviewed quarterly by Privacy/Legal and the executive sponsor; any automated action that produces an unexpected outcome triggers a review of the pre-authorization threshold.

C) MTTR benchmarking

• Establish MTTR benchmarks from:
• ISAC AI endpoint incident data exchanges.
• OWASP MASVS practitioner community data on mobile AI app incident response times.
• CSA Endpoint AI Safety Initiative observational data.
• Peer roundtables (CISO and AI-endpoint practitioner communities).
• Publish a quarterly MTTR benchmark brief to the program sponsor:
• MTTR per incident class vs. benchmark (regulated-data egress, unsanctioned extension, SaaS-AI silent-enablement, chatbot abuse, multi-modal injection, mobile-AI integrity failure, edge-device tamper).
• MTTR per tier (Critical, High, Medium) vs. benchmark.
• Delta trend (improving, stable, degrading) vs. benchmark.
• Investment driver: where MTTR is above benchmark, root-cause mapped to a specific practice gap (missing detection, unclear playbook, on-call latency) with a budget-linked improvement proposal.

Outcome Metrics (L3)

Process Metrics (leading)

• ISAC participation cadence, sector ISAC feeds consumed and contributions submitted at least quarterly; ISAC AI exercises attended annually.
• Contribution pipeline health, ≥2 endpoint-playbook/CSA/OWASP items in-flight (draft, in-review, submitted) at any time.
• Pre-authorization policy review cadence, quarterly; any automated action producing an unexpected outcome triggers an out-of-cycle review.
• Benchmark data source refresh, MTTR benchmark inputs updated at least semi-annually; stale benchmarks flagged.

Effectiveness Metrics (business value)

• MTTR for pre-authorized containment classes drops to seconds from hours, the most significant MTTR-reduction lever available without adding headcount.
• Mean-time-to-contain on Critical-tier Endpoints incidents continuing to compress as ISAC-shared intelligence accelerates root-cause identification and playbook refinement.
• External recognition, citations or adoption of contributed AI endpoint incident taxonomy artifacts by ISACs, CSA, OWASP MASVS, or sector standards bodies.
• Budget efficiency, MTTR benchmark brief demonstrates that pre-authorized automation and ISAC-sourced playbook refinements deliver MTTR improvement without proportional headcount growth.

Success Criteria

• ≥4 ISAC AI endpoint incident contributions per year; ≥2 CSA / OWASP MASVS contributions per year; ≥1 ATLAS Endpoints-tactic contribution per year; all contributions anonymized, legally vetted, and maintained.
• ≥3 pre-authorized automated containment actions live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records + human-review tickets on execution.
• Quarterly MTTR benchmark brief published to sponsor; Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes; deltas above benchmark linked to investment proposals.
• Pre-authorization policy reviewed quarterly; no unauthorized automated action executed; all unexpected automation outcomes reviewed within 5 business days.

Key Success Indicators

Level 1: - Single AI/HAI endpoint issue backlog operational with standardized metadata (source, affected archetype linked to SM-Endpoints inventory, severity rubric with AI-endpoint-specific axes, owner, SLA, regulatory flag, evidence link) capturing ≥95% of AI/HAI endpoint issues from all source practices. - Seven AI-specific endpoint incident playbook entries published (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper) with named roles, containment plays, evidence-capture instructions, and SLA targets, each exercised in at least one tabletop in the last 12 months. - Regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA (60d), PCI-DSS endpoint breach, COPPA, FERPA, and sector-specific obligations; 100% adherence in the last 90 days. - Post-incident review loop wired to SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints, every Critical/blocker incident produces a review within 14 days with named update outputs for each downstream practice. - Program-sponsor dashboard refreshed monthly showing backlog aging, SLA adherence, and post-incident learning outputs.

Level 2: - Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation that includes a current Critical-tier archetype briefing. - Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML-Endpoints backlogs; ≥90% of downstream practice owners responding within 14 days. - Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents; named cross-domain contacts for Software, Data, and Processes domains verified quarterly. - Tier-movement in SM-Endpoints inventory auto-triggers IM-Endpoints configuration updates within 14 days (Critical re-tier) or 30 days (other tiers).

Level 3: - ≥4 ISAC AI endpoint contributions per year; ≥2 CSA / OWASP MASVS contributions per year; ≥1 ATLAS Endpoints-tactic contribution per year, all maintained and tracked for external adoption. - ≥3 pre-authorized automated containment actions live, vetted, producing 100% audit records, with quarterly policy review and zero unauthorized executions. - Quarterly MTTR benchmark brief published; Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes; deltas linked to investment proposals.

Common Pitfalls

Level 1: - ❌ "Single backlog" created but source practices continue filing into separate queues, ML-Endpoints alerts route to a DLP console queue nobody monitors, ST-Endpoints failures stay in the CI dashboard, and vendor SaaS-AI advisories land in a shared email inbox; the backlog achieves only 40% coverage and the ≥95% target is never reached. - ❌ Severity rubric anchors are generic (probability × impact without AI-endpoint-specific axes), a chatbot EU AI Act Art. 50 disclosure suppression affecting thousands of customer sessions is triaged Low because the rubric does not capture regulatory-notification triggers; it should be Critical. - ❌ Playbook entries published but roles not pre-assigned, on the first live SaaS-AI silent-enablement incident, the team spends the first 45 minutes figuring out who has access to the SaaS admin console to disable the feature, not disabling it. - ❌ GDPR Art. 33 72-hour clock informally tracked, when a DLP allow event for regulated customer data to an AI assistant lands on a Friday evening, the clock starts but no named owner confirms the start time; the SLA slips before anyone documents the awareness event. - ❌ Post-incident reviews completed but outputs filed in a shared document that no downstream practice owner reads, SA-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints do not update; the same chatbot jailbreak pattern recurs with the same output-filter gap six months later. - ❌ Vendor SaaS-AI advisories (e.g., provider announces a change to AI data retention for M365 Copilot) are not recognized as IM-Endpoints playbook triggers, the no-train confirmation for the SaaS-AI feature is now void; the Endpoints-domain IR review and IM-Endpoints backlog entry never happen.

Level 2: - ❌ Critical-tier activation criteria are vague, a chatbot abuse campaign at scale that qualifies for full-team + executive activation stays in the standard queue until the product owner escalates on Monday; the SLA requiring ≤1-hour acknowledgement is already missed by the time the right people engage. - ❌ Post-incident review auto-flow integration wired but downstream practice backlogs never treat the auto-created tickets as actionable, the SR-Endpoints team closes the ticket as "acknowledged" without updating the requirements pack; the same unsanctioned-extension gap recurs. - ❌ Cross-domain coordination protocol exists on paper but no IC is pre-designated, the first cross-domain incident where a managed-endpoint AI assistant data-exfiltration reaches the Software-domain LLM backend produces ownership confusion; Endpoints-domain IM and Software-domain IM both wait for the other. - ❌ 24/7 on-call coverage implemented but the on-call briefing is stale, the rotation shift includes a Critical-tier archetype list that was accurate 90 days ago; a new Critical-tier customer-facing chatbot added last sprint is not in the briefing; on-call responders do not know the escalation path for it.

Level 3: - ❌ ISAC participation limited to consuming feeds, contributions are absent; the org is labeled a free-rider; influence over AI endpoint incident taxonomy standards diminishes. - ❌ Pre-authorized automated containment fires on a Critical-tier archetype because the confidence threshold was set too loosely, a false positive executes a rate-limit tighten on a production customer-facing chatbot during peak traffic; the pre-authorization policy had no Critical-tier exception check. - ❌ MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI endpoint portfolio scale, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch. - ❌ OWASP MASVS contributions submitted once and never updated, the mobile AI app incident-response patterns contributed reflect a vulnerability class from 18 months ago that has since been mitigated; the community builds on stale data. - ❌ Automated containment produces audit records that are technically complete but lack the narrative context needed for a post-incident root-cause review, humans reviewing automated extension-force-remove logs cannot reconstruct what the detection saw and why the confidence threshold triggered.

Practice Maturity Questions

Level 1: 1. Is there a single AI/HAI endpoint issue backlog with standardized metadata (source, affected archetype linked to SM-Endpoints inventory, severity rubric anchored to AI-endpoint-specific axes, active regulated-data exfiltration via AI / Art. 50 disclosure suppression at scale / edge tamper with ongoing operation / GDPR Art. 33 trigger 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-Endpoints, SR-Endpoints, DR-Endpoints, IR-Endpoints, ST-Endpoints, ML-Endpoints, external)? 2. Is the AI/HAI endpoint incident playbook published with ≥7 named AI-specific endpoint incident classes (regulated-data egress via AI assistant, unsanctioned browser extension, SaaS-AI silent-enablement, chatbot abuse / jailbreak at scale, multi-modal injection, mobile-AI integrity failure, edge-device tamper), 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? 3. Is the regulatory SLA tracker live covering GDPR Art. 33 (72h), EU AI Act Art. 50 transparency-failure remediation, EU AI Act Art. 73, HIPAA (60d), PCI-DSS endpoint breach, COPPA, FERPA, 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-Endpoints, SR-Endpoints, EG-Endpoints, and ML-Endpoints?

Level 2: 1. Is a tier-calibrated 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 archetype briefing, and tier-movement in the SM-Endpoints inventory automatically triggering IM-Endpoints configuration updates (on-call path, playbook variant, SLA targets) within 14 days (Critical re-tier)? 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML-Endpoints practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly to distinguish substantive changes from nominal acknowledgements? 3. Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI endpoint incidents, with named cross-domain contacts for Software, Data, and Processes domains verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Level 3: 1. Does the program contribute ≥4 anonymized AI endpoint-incident-classification entries per year to sector ISACs, ≥2 contributions per year to CSA Endpoint AI Safety Initiative or OWASP MASVS, and ≥1 contribution per year to MITRE ATLAS Endpoints-tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption? 2. Are ≥3 pre-authorized automated containment actions live (extension force-remove, SaaS-AI feature disable, edge-device remote-disable, or chatbot rate-limit tighten classes), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? 3. Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per 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?

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