Issue Management (IM)

Endpoints Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/IM-Endpoints-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Operations

Objective: Run one backlog for endpoints AI issues with an AI-aware severity taxonomy and published service levels, so AI findings age and escalate like everything else.

Description: A program at this level handles AI issues on the same rails as every other security issue, with a severity taxonomy extended to cover the failure modes AI actually produces. The taxonomy names regulated data pasted into an unsanctioned assistant, a browser extension found reading internal application pages, injection through content reaching an endpoint assistant, a capability enabled on unmanaged devices, and denial-of-wallet against a public conversational interface, because a severity scheme built for classical vulnerabilities rates these either as nothing or as whatever the assessor improvises. One backlog matters more than it sounds: AI findings kept in a separate register age quietly, escalate to nobody, and are rediscovered at the next assessment.

---

Maturity Level 1, Foundational

Objective: Run one backlog for endpoints AI issues with an AI-aware severity taxonomy and published service levels, so AI findings age and escalate like everything else.

A program at this level handles AI issues on the same rails as every other security issue, with a severity taxonomy extended to cover the failure modes AI actually produces. The taxonomy names regulated data pasted into an unsanctioned assistant, a browser extension found reading internal application pages, injection through content reaching an endpoint assistant, a capability enabled on unmanaged devices, and denial-of-wallet against a public conversational interface, because a severity scheme built for classical vulnerabilities rates these either as nothing or as whatever the assessor improvises. One backlog matters more than it sounds: AI findings kept in a separate register age quietly, escalate to nobody, and are rediscovered at the next assessment.

Dependencies

• Required: SM-Endpoints-L1, PC-Endpoints-L1, TA-Endpoints-L1
• Alignment (not blocking): Existing vulnerability and incident management, so AI issues extend the established backlog and escalation path
• Supports / unblocks: IR-Endpoints-L1; ST-Endpoints-L1; ML-Endpoints-L1; EG-Endpoints-L2; Required by: IM-Endpoints-L2

Desired Outcomes

• AI issues sit in the same backlog as other security issues, with the same ageing and escalation.
• The severity taxonomy names the AI-specific failure modes, including regulated data pasted into an unsanctioned assistant and denial-of-wallet.
• Every issue carries a severity, an owner and a service level from the moment it is created.
• Containment actions for AI-specific incidents are documented before they are needed.
• Issue sources are wired in, so findings from testing, review and monitoring arrive automatically.

Activities

A) Extend the severity taxonomy to AI failure modes

Extend the existing severity taxonomy rather than writing a new one, adding the AI-specific classes that a classical scheme cannot rate: regulated data pasted into an unsanctioned assistant, a browser extension found reading internal application pages, injection through content reaching an endpoint assistant, a capability enabled on unmanaged devices, and denial-of-wallet against a public conversational interface. For each class, state what makes it Critical, High, Medium or Low, using the dimensions that actually vary, being the data exposed, the reversibility of the effect, the population affected and whether the asset acts or advises. Include denial-of-wallet as a named class with its own criteria, because it degrades no availability signal and a scheme keyed to availability rates it as nothing while the budget drains. Publish worked examples per class, since a taxonomy without examples is applied inconsistently and its inconsistency is invisible in the aggregate.

B) Run one backlog with wired-in sources and service levels

Route every AI finding into the shared security backlog rather than a separate AI register. Wire the sources so findings arrive automatically: implementation review, security testing, monitoring detections, adversarial exercises, vendor advisories and self-reports. Assign a severity, an owner and a service level at creation rather than at triage, because an issue that waits for triage to acquire a service level is an issue whose clock has not started. Publish service levels by severity and report adherence rather than backlog size, since backlog size is a function of discovery rate as much as of remediation and improves when discovery stops.

C) Document containment for AI-specific incidents

Write containment actions for each AI-specific incident class before they are needed, covering removing the extension through endpoint management, revoking the capability's identity grants, blocking the destination at the gateway, and applying per-user limits. AI containment differs from classical containment in a way that catches teams out: the fastest effective action is usually to remove the system's ability to act rather than to take the system offline, because an AI asset that is merely unavailable stops delivering value while an asset whose tool access is revoked stops causing harm and may keep delivering. Name who is authorised to invoke each action at what hour, and verify the technical means exists and works. An action documented but never exercised is discovered to be unavailable at the worst moment.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
AI issues managed in the shared security backlog rather than a separate register	first backlog consolidation	100%	Issue tracker records tagged by domain
Issues carrying a severity, owner and service level at creation	first quarter of intake telemetry	≥95% at creation rather than at triage	Issue tracker creation records
Issue sources wired to create records automatically	first wiring pass	≥80% of issues arrive from a wired source rather than manual entry	Issue creation source field
AI-specific severity classes with published criteria and worked examples	first taxonomy publication	100% of named classes	Severity taxonomy documentation
Containment actions documented and technically verified as available	first verification pass	100% of documented actions verified at least once	Containment verification records

Process Metrics (leading)

• Service-level adherence reported weekly by severity, rather than backlog size alone.
• Severity taxonomy reviewed quarterly against new incident classes.
• Containment actions exercised at least annually to confirm they still work.
• Unwired issue sources reviewed monthly and connected.

Effectiveness Metrics (business value)

• Median age of open AI issues by severity falls, reported separately from volume.
• Time from detection to containment for AI incidents falls.
• Repeat issues of the same class fall as root causes reach the practices that own them.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Issues closed without a recorded remediation or acceptance	closure as backlog hygiene rather than resolution, where an issue is marked done because it is old rather than because anything changed	Issue tracker closure records with disposition
Severity downgrades applied after creation, with the downgrading authority recorded	severity drift under service-level pressure, where reclassification is used to make a clock more comfortable rather than to correct an assessment	Issue severity change history

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Denial-of-wallet incidents detected, with time from onset to containment	per denial-of-wallet incident	budget drain running long because no availability signal degrades, which makes detection time the entire loss and is invisible to conventional incident triggers	Incident records joined to the consumption ledger
Consumption anomaly cost accrued before containment	per active user	containment measured in elapsed time rather than in accrued cost, which understates the urgency of exactly the incident class where cost is the harm	Consumption ledger during the incident window
AI incidents whose containment action was a consumption limit rather than a service withdrawal	per contained AI incident	defaulting to taking the system offline when revoking its ability to act or spend would have contained the harm while preserving the service	Incident containment action records

Level of Effort (incremental over the level below)

• Stand-up: 120 hours · Ongoing: 120 hours/quarter
• Security Analyst / SOC — primary, 32 days/year
• AppSec / SecEng — regular, 14 days/year
• Program Manager / Practice Lead — regular, 10 days/year
• Security Architect — low, 6 days/year

Success Criteria

• All AI issues are managed in the shared security backlog with the same ageing and escalation as other security issues.
• The severity taxonomy names the AI-specific classes including denial-of-wallet, with published criteria and worked examples.
• At least 95% of issues carry a severity, owner and service level at creation rather than at triage.
• At least 80% of issues arrive from a wired source rather than manual entry.
• Containment actions are documented per AI incident class and technically verified as available.

---

Maturity Level 2, Comprehensive

Objective: Calibrate endpoints AI issue service levels to asset tier, run rehearsed AI incident response, and close the loop from root cause to the practice that owns it.

At this level response is proportionate and rehearsed. Service levels vary by tier and severity, incident playbooks for AI-specific classes are exercised rather than written, and every incident reaching a root cause is routed to the practice that owns the fix rather than closed where it was found. Regulatory notification clocks are known and instrumented, because the EU AI Act and GDPR both impose windows that begin at awareness and a team discovering the obligation during the incident has already lost most of the window.

Dependencies

• Required: IM-Endpoints-L1, SM-Endpoints-L2, ML-Endpoints-L1
• Alignment (not blocking): Enterprise incident response and crisis management, so AI incidents escalate through the established path
• Supports / unblocks: EG-Endpoints-L2; TA-Endpoints-L2; SA-Endpoints-L2; ST-Endpoints-L2; Required by: DR-Endpoints-L3, EG-Endpoints-L3, EH-Endpoints-L3, IM-Endpoints-L3, IR-Endpoints-L3, ML-Endpoints-L2, TA-Endpoints-L3

Desired Outcomes

• Service levels vary by asset tier and severity, and adherence is reported per tier.
• AI incident playbooks are exercised rather than written, and the exercise finds gaps.
• Regulatory notification clocks are instrumented rather than discovered during an incident.
• Root causes are routed to the practice that owns the fix rather than closed where they were found.
• Deferral and acceptance authority rises with tier and severity.

Activities

A) Calibrate service levels and authority to tier

Publish remediation service levels by severity and asset tier, tighter at Critical, and report adherence per tier rather than in aggregate, because an aggregate figure can be met while every Critical-tier breach is missed. Make deferral and risk-acceptance authority rise with tier and severity, so a deferred Critical finding requires executive acceptance with an expiry and quarterly review. Report deferrals to the sponsor alongside closures, since a practice reporting only what it closed describes a backlog that does not exist. Track findings deferred and later implicated in an incident as a distinct measure of whether deferral judgment is sound rather than merely authorised. Tier-proportionate response in this domain is shaped by population size, since an extension issue affects every device that installed it and containment is a fleet operation rather than an asset one.

B) Rehearse AI incident response and instrument the notification clocks

Write and exercise incident playbooks for each AI-specific class, covering detection signals, containment using removing the extension through endpoint management, revoking the capability's identity grants, blocking the destination at the gateway, and applying per-user limits, evidence preservation, communication and recovery. Exercise at least semi-annually with the people who would actually respond, including out of hours, and measure the exercise by the gaps it finds rather than by its completion. Instrument the regulatory notification clocks explicitly: identify which incident classes trigger EU AI Act serious-incident reporting or GDPR breach notification, what starts the clock, who decides, and what evidence the notification requires. A team that discovers a 72-hour obligation 40 hours into an incident has lost most of the window to a question it could have answered in advance. Playbook exercises in this domain rehearse removing an extension fleet-wide through endpoint management, which is fast when it works and slow when the device is off the network.

C) Route root causes to the owning practice

Require every incident reaching a root cause to name the practice that owns the fix and to open a work item there, rather than closing the incident where it was found. An incident caused by a missing architectural control belongs to secure architecture, one caused by an untested threat belongs to security testing, one caused by a knowledge gap belongs to education. Closing it in the incident record alone guarantees recurrence, and recurrence is the single clearest signal that a response practice is functioning as a repair shop rather than as a feedback mechanism. Track the share of incidents whose root cause was already known and untreated, which separates a discovery problem from an action problem and is usually uncomfortable reading. Root causes in this domain most often belong to education and environment hardening, particularly allowlist enforcement mode.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Issues remediated within the tier and severity service level	first quarter of tiered telemetry	≥90% per tier, reported per tier rather than in aggregate	Issue tracker with tier and service-level fields
AI incident playbooks exercised in the last 12 months	first exercise round	100% of AI-specific classes, including an out-of-hours exercise	Exercise register with dates and findings
Incident classes with an instrumented regulatory notification clock	first regulatory mapping	100% of classes that can trigger a notification obligation	Notification decision tree with owners
Incidents reaching root cause with a work item opened in the owning practice	first quarter of loop telemetry	≥90%	Incident records joined to practice backlogs
Deferred Critical findings carrying executive acceptance with expiry	first tiered deferral review	100%, with none past expiry	Finding disposition records
Incidents whose root cause was already known and untreated	first quarter of root-cause analysis	tracked and falling, reported openly	Root-cause analysis joined to the threat library and prior findings

Process Metrics (leading)

• Playbooks exercised semi-annually, including at least one out-of-hours exercise per year.
• Notification decision tree reviewed whenever an in-scope obligation changes.
• Root-cause routing verified monthly so incidents are not closed without an owning practice.
• Deferred Critical findings reviewed quarterly with the sponsor.

Effectiveness Metrics (business value)

• Time from detection to containment falls, reported per incident class.
• Recurrence of the same root-cause class falls, which is the measure that the feedback loop works.
• Regulatory notifications made within the required window, with none late.
• Deferred findings later implicated in incidents fall.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Incidents closed without a root cause recorded, by severity	closure without diagnosis, which guarantees recurrence and is most common under load at exactly the times recurrence is least affordable	Incident records with root-cause field
Risk acceptances at Critical tier, with the accepting authority and expiry recorded	acceptance authority drifting downward under pressure, so the decision to live with a Critical risk is taken by whoever is available	Finding disposition records joined to asset tier
Exercise findings closed without a change to the playbook or the environment	rehearsal treated as a compliance activity rather than as a source of correction, which is visible only by tracking what the exercise changed	Exercise findings joined to playbook change log

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Denial-of-wallet incidents contained within their tier service level	per denial-of-wallet incident	a response clock calibrated to availability incidents applied to an incident class where cost accrues continuously and no availability signal ever degrades	Incident records joined to the consumption ledger
Cost accrued between detection and containment, by tier	per active user	containment urgency judged by elapsed time rather than by accruing cost, which systematically under-prioritises the incident class where the two diverge most	Consumption ledger during incident windows
Emergency consumption limits applied during incidents and subsequently reverted	per applied emergency limit	emergency limits left in place indefinitely and degrading legitimate service, or reverted immediately and leaving the exposure open, neither of which is visible without tracking	Gateway limit change log joined to incident records

Level of Effort (incremental over the level below)

• Stand-up: 150 hours · Ongoing: 170 hours/quarter
• Security Analyst / SOC — primary, 38 days/year
• AppSec / SecEng — regular, 14 days/year
• Legal / Privacy Counsel — regular, 10 days/year
• Program Manager / Practice Lead — low, 8 days/year
• Executive Sponsor — low, 2 days/year

Success Criteria

• Service levels vary by tier and severity with adherence at or above 90% reported per tier rather than in aggregate.
• Every AI incident playbook has been exercised within 12 months, including an out-of-hours exercise, and measured by the gaps it found.
• Regulatory notification clocks are instrumented with owners and evidence requirements identified in advance.
• At least 90% of incidents reaching root cause open a work item in the practice that owns the fix.
• Incidents whose root cause was already known and untreated are tracked openly and falling.

---

Maturity Level 3, Industry-Leading

Objective: Automate endpoints AI issue triage and containment where it is safe, measure response by outcome rather than activity, and contribute incident learning back to the field.

At this level triage and first-line containment are largely automatic for well-understood classes, so response time approaches detection time. The practice measures itself by recurrence and by harm avoided rather than by ticket throughput. Incident learning is contributed back in anonymised form, which matters in AI security because the public corpus of real AI incidents is thin and most organisations learn only from their own, which is the slowest possible way to learn.

Dependencies

• Required: IM-Endpoints-L2, ML-Endpoints-L2, EH-Endpoints-L3
• Alignment (not blocking): Platform engineering, since automated containment acts on production systems
• Supports / unblocks: Every other Endpoints practice at L3, which receives routed root causes and learning; Required by: ML-Endpoints-L3

Desired Outcomes

• Triage and first-line containment are automatic for enumerated, well-understood classes.
• Every automated containment action is logged, attributable and reversible.
• Response is measured by recurrence and harm avoided rather than by ticket throughput.
• Anonymised incident learning is contributed back to a field where the public corpus is thin.
• The classes that require human judgment are enumerated rather than assumed.

Activities

A) Automate triage and bounded first-line containment

Automate severity assignment, ownership routing and duplicate detection from the detection signal, so an issue arrives with its clock started and its owner assigned. Enumerate explicitly the containment actions that may fire automatically, being those where the correct response is unambiguous and reversible, such as applying an emergency consumption limit, revoking a specific tool credential or blocking a destination. Everything else alerts. Log every automated action with what was done, on what evidence, and how to reverse it. Publish the human-judgment classes explicitly, because automated containment is safest when its boundary is stated rather than assumed, and the assumption is always that it covers more than it does. Automatic containment in this domain is well bounded: removing an extension through endpoint management, revoking a capability grant and applying a per-user limit are all fast and reversible.

B) Measure response by outcome rather than activity

Shift the primary measures from throughput to outcome: recurrence rate by root-cause class, harm avoided estimated from the consumption ledger and the affected population, and time from detection to containment rather than to closure. Ticket throughput and backlog size remain as health indicators but are explicitly not the practice's outcome measures, because both are dominated by discovery rate and both improve when discovery degrades. Report recurrence to the sponsor as the headline, since a response practice that closes quickly and recurs constantly is failing at the thing it exists for while every throughput metric looks excellent. Recurrence in this domain clusters around extension permission changes and data pasted into unsanctioned tools, which points remediation at education and environment hardening.

C) Contribute anonymised incident learning back

Contribute at least four substantive artifacts per year: anonymised incident case studies, detection and containment patterns, playbooks others can adopt, and technique observations submitted to MITRE ATLAS where they fit. The public corpus of real AI security incidents is thin, disproportionately so relative to the deployment base, which means most organisations learn only from their own incidents, which is the slowest and most expensive way to learn anything. Contributing changes that for everyone including the contributor. Anonymise carefully, review legally, coordinate disclosure with any affected vendor or provider, and count only accepted artifacts. Prefer contributing the incidents that were most surprising internally, since those carry the most information for others. Endpoint incident write-ups contribute well as extension risk cases, which feed directly into the shared classifications the whole control depends on.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Issues arriving with severity, owner and clock assigned automatically	L2 manual triage rate	≥85% auto-triaged	Issue creation telemetry
Enumerated containment classes executed automatically within the detection window	first automation rollout	≥70% of eligible events, with everything else alerting	Automated containment log
Automated containment actions logged with evidence and reversal path	first quarter of automation	100%	Containment audit log
Recurrence rate by root-cause class	first quarter of outcome measurement	tracked and falling year over year, reported to the sponsor as the headline measure	Root-cause analysis aggregated by class over time
Accepted external incident-learning contributions per year	0	≥4 accepted, anonymised, legally reviewed and disclosure-coordinated	Contribution log with acceptance references

Process Metrics (leading)

• Automated containment scope reviewed quarterly, with classes added only after demonstrated safety.
• Human-judgment class list published and reviewed quarterly.
• Recurrence reviewed monthly with the practices owning the root causes.
• Contribution pipeline carries at least two artifacts in draft or review.

Effectiveness Metrics (business value)

• Time from detection to containment approaches detection time for automated classes.
• Recurrence by root-cause class falls, which is the practice's defining outcome.
• Harm avoided, estimated from the ledger and affected population, is reported annually and reconciled with Finance where it is monetary.
• External adoption of contributed playbooks and detection patterns.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Automated containment actions reversed by a human within one hour	automation acting on a misread signal, which indicates the enumerated class was wrongly scoped and is only visible if reversals are tracked separately from actions	Containment log joined to subsequent manual changes
Incidents in human-judgment classes acknowledged but not actioned within the tier window	alert fatigue concentrating precisely on the classes automation deliberately left to people because they need judgment	Alert disposition records
Recurrence accepted without a corresponding work item in the owning practice	recurrence normalised as a cost of doing business, which is how a response practice becomes a repair shop	Recurrence records joined to practice backlogs

Consumption Metrics (denominated, never absolute spend)

Metric	Denominator	Economic failure it detects	Source
Automated emergency consumption limits applied within the detection window	per denial-of-wallet detection	cost accruing through a human triage delay on an incident class where the loss is continuous and the correct response is unambiguous	Automated containment log joined to the consumption ledger
Cost accrued between detection and automated containment	per active user	an automation path that fires but not fast enough to matter, which looks successful in coverage terms and fails in loss terms	Consumption ledger during incident windows
Harm avoided from contained consumption incidents, computed from burn rate and time to contain	per contained consumption incident	a response practice unable to state what its speed is worth, which loses the argument for the investment that made the speed possible	Incident records joined to the consumption ledger

Level of Effort (incremental over the level below)

• Stand-up: 200 hours · Ongoing: 140 hours/quarter
• Security Analyst / SOC — primary, 36 days/year
• DevOps / Platform Engineer — regular, 20 days/year
• AppSec / SecEng — regular, 12 days/year
• Legal / Privacy Counsel — low, 6 days/year
• Material new tooling: Automated triage and bounded containment orchestration

Success Criteria

• At least 85% of issues arrive auto-triaged with severity, owner and clock assigned.
• Automatic containment classes are enumerated explicitly, everything else alerts, and every automated action is logged with evidence and a reversal path.
• Recurrence rate by root-cause class is the practice's headline measure, reported to the sponsor, rather than throughput or backlog size.
• Harm avoided is estimated from the consumption ledger and affected population and reported annually.
• At least four accepted external incident-learning contributions per year, anonymised and disclosure-coordinated.

---

Key Success Indicators

Level 1:

• All AI issues are managed in the shared security backlog with the same ageing and escalation as other security issues.
• The severity taxonomy names the AI-specific classes including denial-of-wallet, with published criteria and worked examples.
• At least 95% of issues carry a severity, owner and service level at creation rather than at triage.
• At least 80% of issues arrive from a wired source rather than manual entry.
• Containment actions are documented per AI incident class and technically verified as available.

Level 2:

• Service levels vary by tier and severity with adherence at or above 90% reported per tier rather than in aggregate.
• Every AI incident playbook has been exercised within 12 months, including an out-of-hours exercise, and measured by the gaps it found.
• Regulatory notification clocks are instrumented with owners and evidence requirements identified in advance.
• At least 90% of incidents reaching root cause open a work item in the practice that owns the fix.
• Incidents whose root cause was already known and untreated are tracked openly and falling.

Level 3:

• At least 85% of issues arrive auto-triaged with severity, owner and clock assigned.
• Automatic containment classes are enumerated explicitly, everything else alerts, and every automated action is logged with evidence and a reversal path.
• Recurrence rate by root-cause class is the practice's headline measure, reported to the sponsor, rather than throughput or backlog size.
• Harm avoided is estimated from the consumption ledger and affected population and reported annually.
• At least four accepted external incident-learning contributions per year, anonymised and disclosure-coordinated.

---

Common Pitfalls

Level 1:

• ❌ Keeping AI findings in a separate register, where they age quietly, escalate to nobody and are rediscovered at the next assessment.
• ❌ Using a severity scheme keyed to availability, which rates denial-of-wallet as nothing while the budget drains.
• ❌ Assigning severity at triage rather than creation, so the issue's clock does not start until someone looks at it.
• ❌ Reporting backlog size rather than service-level adherence, a number that improves when discovery stops.
• ❌ Documenting containment actions without verifying the technical means exists, which is discovered at the worst moment.

Level 2:

• ❌ Reporting service-level adherence in aggregate, which can be met while every Critical-tier breach is missed.
• ❌ Writing playbooks without exercising them, so their gaps are found during the incident rather than before it.
• ❌ Discovering a notification obligation mid-incident, by which point most of the window is gone.
• ❌ Closing incidents where they were found, which guarantees the same root cause returns.
• ❌ Reporting closures without deferrals, which describes a backlog that does not exist.

Level 3:

• ❌ Automating containment without enumerating the safe classes, which eventually acts on a misread signal in a way that matters.
• ❌ Measuring the practice by throughput, which is dominated by discovery rate and improves when discovery degrades.
• ❌ Tracking automated actions without tracking reversals, which hides automation that is acting wrongly.
• ❌ Normalising recurrence as a cost of doing business, which is how a response practice becomes a repair shop.
• ❌ Withholding incident learning, which keeps the whole field, including the withholder, learning only from its own incidents.

---

Practice Maturity Questions

Level 1:

1. Does the severity taxonomy extend the existing scheme with AI-specific classes including regulated data pasted into an unsanctioned assistant and denial-of-wallet, with published criteria keyed to data exposed, reversibility, population affected and whether the asset acts or advises, plus worked examples per class?
2. Are all AI issues managed in the shared security backlog with at least 95% carrying severity, owner and service level at creation, and do at least 80% arrive from a wired source rather than manual entry? For Endpoints, the assessor should be shown an incident record showing fleet-wide extension removal.
3. Are containment actions documented for every AI incident class, covering removing the extension through endpoint management and the others, with named invocation authority and technical availability verified rather than assumed?

Level 2:

1. Do service levels vary by asset tier and severity with adherence reported per tier rather than in an aggregate that can be met while every Critical-tier breach is missed? Evidence this in the Endpoints domain against an incident record showing fleet-wide extension removal.
2. Have AI incident playbooks been exercised within 12 months including out of hours, measured by the gaps found, and are regulatory notification clocks instrumented in advance with owners and evidence requirements identified? For Endpoints, the assessor should be shown an incident record showing fleet-wide extension removal.
3. Do at least 90% of incidents reaching root cause open a work item in the owning practice rather than closing where they were found, and is the share whose root cause was already known and untreated tracked openly? In Endpoints, ask to see an incident record showing fleet-wide extension removal.

Level 3:

1. Are at least 85% of issues auto-triaged with severity, owner and clock assigned, and are automatic containment classes enumerated explicitly with everything else alerting and every action logged with evidence and a reversal path? Evidence this in the Endpoints domain against an incident record showing fleet-wide extension removal.
2. Is recurrence rate by root-cause class the practice's headline outcome measure reported to the sponsor, rather than throughput and backlog size which are dominated by discovery rate and improve when discovery degrades? For Endpoints, the assessor should be shown an incident record showing fleet-wide extension removal.
3. Does the organisation contribute at least four accepted anonymised incident-learning artifacts per year with disclosure coordinated, prioritising the incidents that were most surprising internally? In Endpoints, ask to see an incident record showing fleet-wide extension removal.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Do AI security issues go into the same backlog as everything else?
• Does your severity scale have a rating for an AI that drains your budget?
• Do you know how to stop an AI agent acting without taking it offline?

Level 2:

• Have you rehearsed an AI incident with the people who would respond?
• Do you know which AI incidents start a regulatory notification clock?
• When an AI incident is fixed, does another practice get a work item?

Level 3:

• Does an AI security alert get an owner without a human assigning one?
• Do you measure whether the same AI issue keeps coming back?
• Have you published an anonymised AI incident others can learn from?

---

Tracking

Level 1 — Jira Epic, labels haiamm-im-endpoints-l1, haiamm-operations

• Done when: All AI issues in the shared backlog with severity, owner and service level assigned at creation for at least 95%, and every containment action verified as available, sustained two quarters.
• Git artifacts: security/incidents/endpoints/, security/severity-taxonomy.md, security/containment-playbooks/
• Git signal: severity-taxonomy.md carries worked examples per class and a commit within each quarterly review, and containment playbooks record a verification date per action.
• CI check: containment-verification-check

Level 2 — Jira Epic, labels haiamm-im-endpoints-l2, haiamm-operations

• Done when: Per-tier service-level adherence at or above 90% with every AI playbook exercised within 12 months and root-cause routing at or above 90%, sustained two consecutive quarters.
• Git artifacts: security/playbooks/, security/exercise-register.json, security/notification-decision-tree.md
• Git signal: exercise-register.json records findings and resulting playbook changes per exercise, and the notification decision tree names an owner and evidence requirement per obligation.
• CI check: incident-playbook-currency

Level 3 — Jira Epic, labels haiamm-im-endpoints-l3, haiamm-operations

• Done when: Auto-triage at or above 85% with every automated containment action logged with evidence and reversal path, and recurrence by root-cause class falling, sustained two consecutive quarters.
• Git artifacts: security/containment-scope.json, security/recurrence-analysis.json, governance/contribution-log.json
• Git signal: containment-scope.json enumerates the automatable classes and is reviewed quarterly, and recurrence-analysis.json is regenerated from root-cause records rather than maintained by hand.
• CI check: containment-scope-review

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	AGH, TM	AML.T0029, AML.T0051, AML.T0053	LLM01, LLM02, LLM10	EU AI Act Art. 26; EU AI Act Art. 73; GDPR Art. 33; NIST AI RMF MANAGE 4.1; ISO/IEC 42001 10.1
L2	AGH, TM	AML.T0029, AML.T0051, AML.T0053	LLM01, LLM02, LLM10	EU AI Act Art. 73; EU AI Act Art. 26; GDPR Art. 33; GDPR Art. 34; NIST AI RMF MANAGE 4.1; ISO/IEC 42001 10.1
L3	AGH, TM	AML.T0029, AML.T0051, AML.T0053	LLM01, LLM02, LLM10	EU AI Act Art. 73; EU AI Act Art. 72; GDPR Art. 33; NIST AI RMF MANAGE 4.1; ISO/IEC 42001 10.1; ISO/IEC 42001 10.2

---

Document Version: HAIAMM v3.5 (generated) / Practice: Issue Management (IM) / Domain: Endpoints