Issue Management (IM) - Endpoints Assessment

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

v3.0 rewrite: The canonical framing for the Endpoints domain is Issue Management, unified backlog, tier-calibrated incident playbook, and regulatory SLA tracking for AI/HAI endpoint issues. The fully v3.0 source-of-truth is ../practices/IM-Endpoints-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md. Primary tactic: MITRE ATLAS TA0014 Impact. Sector overlays: COPPA (children-facing endpoints), FERPA (educational endpoints), sector mobile-banking.

Issue Management (IM) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Issue Management (IM) Domain: Endpoints Purpose: Assess organizational maturity in operating a unified AI/HAI endpoint issue backlog, AI-specific endpoint incident playbook, and regulatory SLA tracker covering GDPR Art. 33, EU AI Act Art. 50/73, HIPAA, PCI-DSS, COPPA, FERPA, and sector-specific obligations Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively - Complete all Level 1 questions before Level 2
Level progression - Achieve ALL questions at lower level before advancing
Baseline first - Record current metric values before setting targets

Scoring Methodology

Score	Label	Criteria
1.0	Fully Mature	Evidence complete + ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete + 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete + <2 metrics meet targets
0.0	Not Implemented	No evidence of the practice

Level Score = Average of question scores within the level Overall IM-Endpoints Score = Weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

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, COPPA, FERPA, and sector-specific obligations

Question 1: Unified AI/HAI Endpoint Issue Backlog and Triage Rubric

Q1.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?

Evidence Required: - [ ] Single backlog record showing standardized metadata: Source (TA-Endpoints/SR-Endpoints/DR-Endpoints/IR-Endpoints/ST-Endpoints/ML-Endpoints/External including vendor SaaS-AI advisories, browser-extension store flags, mobile-app-store security flags, edge-device CVEs, MITRE ATLAS endpoint-technique updates), Affected archetype linked to SM-Endpoints inventory with archetype and tier, Severity per AI-endpoint rubric, Owner, SLA, Regulatory flag (GDPR Art. 33, EU AI Act Art. 50 transparency failure, EU AI Act Art. 73, HIPAA, PCI-DSS, COPPA, FERPA, sector-specific), Evidence link - [ ] Triage rubric with AI-endpoint-specific severity anchors: Critical (regulated data actively exfiltrated via AI/HAI endpoint, chatbot or multi-modal AI without EU AI Act Art. 50 disclosure at scale, edge AI device physically tampered and continuing to operate, personal data breach via AI endpoint triggering GDPR Art. 33, mobile AI app serving compromised local model at scale, SaaS-AI feature processing regulated data without approved scope with GDPR Art. 33 trigger), High (DLP allow event for regulated data to AI assistant, unsanctioned extension with data-access permissions on ≥10 endpoints, edge attestation failure with network access, chatbot jailbreak at scale), Medium, Low - [ ] Backlog coverage audit: ≥95% of AI/HAI endpoint issues from all source practices vs. reconciliation - [ ] Triage cadence: daily Critical/High, weekly Medium, monthly aging, confirmed last 90 days - [ ] SLA targets: Critical ≤4h/≤48h/≤30d; High ≤24h/7d/45d; Medium ≤48h/14d; Low ≤5bd/30d - [ ] External advisory intake cadence: vendor SaaS-AI advisories, browser-extension store flags, mobile-app-store security flags, edge-device CVEs reviewed weekly; applicable advisories routed to backlog within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI endpoint issues in single backlog vs. scattered queues | % | % | ≥95% | ☐ | | | % of issues with complete standardized metadata | % | % | ≥95% | ☐ | | | % of Critical/High endpoint issues acknowledged within SLA | % | % | 100% | ☐ | | | External advisories routed to backlog within 5 business days | % | % | ≥95% | ☐ | |

Metric Collection Guidance: - Backlog coverage: Monthly reconciliation of single backlog vs. all source practices including external advisory feeds. Formula: backlog_issues / total_endpoint_issues_filed × 100 - Metadata completeness: Spot-audit 20 random tickets per month. Source: backlog export - SLA acknowledgement: endpoint_issues_acknowledged_within_SLA / total_new_Critical_High × 100. Source: backlog timestamps. Weekly - Advisory routing: advisories_routed_within_5bd / total_applicable_advisories × 100. Source: advisory intake log. Weekly

Answer: - ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets) - ☐ Implemented (Evidence complete + 2 metrics meet targets) - ☐ Partial (Evidence partially complete + <2 metrics meet targets) - ☐ Not Implemented (No unified AI/HAI endpoint issue backlog)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 2: AI-Specific Endpoint Incident Playbook, Seven Endpoint Containment Plays

Q1.2: Is the AI/HAI endpoint incident playbook published with seven 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?

Evidence Required: - [ ] Playbook with seven named AI-specific endpoint entries, published and version-controlled: (1) regulated-data egress via AI assistant, endpoint-isolate via MDM, DLP rule tune, GDPR Art. 33 evaluation, no-train commitment assessment for receiving AI provider; (2) unsanctioned browser extension, extension force-remove via MDM browser policy, block-list update, data-flow assessment, user coaching referral to EG-Endpoints, GDPR Art. 33 evaluation if regulated data transmitted; (3) SaaS-AI silent-enablement, feature-disable with SaaS admin, admin audit log review, intake-amnesty path through SM-Endpoints, data-scope assessment, GDPR Art. 33 / Art. 28 evaluation if regulated data processed without approved DPA; (4) chatbot abuse / jailbreak at scale, rate-limit tighten, prompt-injection corpus update, output-filter tune, customer-impact assessment, customer communication if material; (5) multi-modal injection, modality-specific input-validation tighten (image/audio/video), output safety-filter update, regression-corpus update, customer-impact assessment; (6) mobile-AI integrity failure, MDM force-update to known-good app version, local-model signature re-pin, affected-installs assessment, EU AI Act Art. 26 / Art. 50 evaluation if customer outputs from compromised model; (7) edge-device tamper, remote-disable via edge device management console, physical-recovery dispatch, firmware re-attestation before re-enabling, affected-data assessment, GDPR Art. 33 evaluation - [ ] Each entry: trigger conditions, named roles (endpoint-security on-call, Privacy/Legal, SaaS-admin owner, executive sponsor), containment steps, artifacts, evidence-capture, closure criteria, SLA targets - [ ] Tabletop exercise records for each of the seven classes within last 12 months (one per quarter, rotating) - [ ] Edge-device remote-disable function tested quarterly: invocation path, scope, re-attestation confirmation procedure - [ ] COPPA / FERPA escalation path documented and tested for children-facing and educational endpoint incidents

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI endpoint incidents handled on a published playbook entry | % | % | 100% | ☐ | | | Tabletop exercises per year across all 7 endpoint classes | ___ | ___ | ≥4 (rotating) | ☐ | | | Edge-device remote-disable function test pass rate (quarterly) | % | % | 100% | ☐ | | | Vendor SaaS-AI advisory recognized as playbook trigger and routed within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Playbook coverage: endpoint_incidents_handled_on_playbook / total_endpoint_incidents × 100. Source: incident records - Tabletop cadence: Count exercises per year with documented endpoint-scenario coverage. Source: tabletop log - Remote-disable test: Count quarterly tests with pass result / total quarterly tests. Source: test event records - Advisory routing: SaaS_AI_advisories_routed_as_playbook_triggers_within_5bd / total_applicable_advisories × 100. Source: advisory intake log × IM-Endpoints backlog intake

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Q1.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?

Evidence Required: - [ ] Regulatory SLA tracker covering: GDPR Art. 33 (72h, Privacy/Legal, clock starts on first ML-Endpoints detection), EU AI Act Art. 50 transparency-failure remediation (affected customer-facing AI endpoint remediated, disclosure restored and confirmed by ST test, within documented SLA; if suppression affected customers at scale, regulatory notification assessment required), EU AI Act Art. 73 (immediate escalation for Annex III endpoint archetype incidents), HIPAA (60d, PHI incidents, Privacy/Legal), PCI-DSS (cardholder data breach from AI/HAI endpoint), COPPA (children-facing endpoint incidents, Privacy/Legal), FERPA (educational endpoint incidents with student data, Privacy/Legal), sector mobile-banking (mobile AI app incidents in sector-regulated environments, per sector compliance program) - [ ] GDPR Art. 33 clock-start protocol: named owner, first ML-Endpoints detection = clock start, daily status updates; no missed windows in last 90 days - [ ] EU AI Act Art. 50 remediation SLA: defined SLA for restoring disclosure on suppressed customer-facing AI endpoints; ST-Endpoints confirmation test required before closure - [ ] Post-incident review records for all Critical/blocker endpoint incidents in last 12 months: root cause, what caught it, what did not, four update outputs (SA-Endpoints, SR-Endpoints, EG-Endpoints, ML-Endpoints) all populated and tracked

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Regulatory SLA adherence (0 missed notifications) in last 90 days | ___ | 0 missed | 0 missed | ☐ | | | Post-incident reviews within 14 days of Critical/blocker closure | % | % | 100% | ☐ | | | SA/SR/EG/ML-Endpoints update outputs tracked (% Critical reviews with ≥1 per target) | % | % | 100% | ☐ | | | Median closure time for Critical endpoint incidents (root-cause) | ___ days | ___ days | ≤30 days | ☐ | |

Metric Collection Guidance: - Regulatory adherence: Zero missed notification windows across all tracked obligations. Source: SLA tracker. Weekly review - Review timeliness: endpoint_reviews_within_14d / total_Critical_blocker_closures × 100. Source: review records - Update output completion: Verify all four downstream outputs exist and are tracked. Source: IM-Endpoints improvement issues log - MTTR: Median days from incident creation to root-cause filed. Source: backlog aging. Monthly

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 2

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

Question 4: Tier-Calibrated Endpoint Incident Playbook and 24/7 On-Call

Q2.1: Is a tier-calibrated endpoint 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?

Evidence Required: - [ ] Tier-calibrated activation criteria: Critical (CISO + Privacy/Legal + endpoint-security deployer-duty + executive sponsor, ≤1h MTTA, ≤4h MTTC, 24/7, pre-staged comms templates), High (endpoint-security lead + Privacy/Legal if regulated data + deployer-duty, ≤4h MTTA, ≤24h MTTC), Medium (standard queue, ≤1bd), Low (weekly aggregated) - [ ] 24/7 on-call rotation registry: named individuals per week, handoff protocol, no-gap periods confirmed last 90 days - [ ] On-call briefing (current): Critical-tier archetype list, active detection set, known compensating controls or gaps, remote-disable path for Critical-tier edge devices, MDM force-update path for Critical-tier mobile AI apps - [ ] Tier-movement trigger: SM-Endpoints tier-change → IM-Endpoints config update within 14 days for Critical re-tier; evidence from last 3 tier-movement events - [ ] Pre-staged communication templates reviewed quarterly: internal, customer-facing, regulatory notification drafts

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Critical-tier MTTA | ___ hr | ___ hr | ≤1 hour | ☐ | | | Critical-tier MTTC | ___ hr | ___ hr | ≤4 hours | ☐ | | | 24/7 on-call: no-gap periods in last 90 days | ___ gaps | ___ gaps | 0 gaps | ☐ | | | Tier-movement → IM-Endpoints config update within 14 days (Critical re-tier) | % | % | 100% | ☐ | |

Metric Collection Guidance: - MTTA / MTTC: From first ML-Endpoints detection to acknowledged / contained for Critical-tier endpoint incidents. Source: IM-Endpoints telemetry. Per incident - On-call gaps: Count weeks with unassigned on-call period. Source: rotation registry. Monthly - Tier-movement latency: Days from SM-Endpoints tier-change to IM-Endpoints config update. Source: SM log × IM config log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 5: Post-Incident Review Auto-Flow Integration

Q2.2: Is a post-incident review auto-flow integration live routing Critical-tier endpoint 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?

Evidence Required: - [ ] Integration configuration: auto-ticket creation for all four downstream endpoint practices on Critical-tier review closure, SA-Endpoints (architecture-backlog ticket), SR-Endpoints (pack-backlog ticket with failing requirement row), EG-Endpoints (training-backlog ticket with affected population), ML-Endpoints (detection-registry ticket with detection name, current query, proposed change) - [ ] Sample auto-created tickets from last 3 Critical-tier endpoint reviews showing correct metadata - [ ] Downstream backlog aging data: auto-ticket timestamps vs. owner response within 14 days; ≥90% adherence over last 12 months - [ ] Quarterly sponsor review records: quality assessment distinguishing substantive (concrete update to pattern, pack, curriculum, or detection) from nominal - [ ] Accepted update outputs designated High-severity in receiving practice backlog

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Post-incident review outputs auto-flowing to SA/SR/EG/ML-Endpoints (% Critical reviews) | % | % | 100% | ☐ | | | Downstream practice owner response within 14 days | % | % | ≥90% | ☐ | | | Quarterly sponsor quality review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Substantive update output rate (sponsor-assessed) | % | % | ≥80% | ☐ | |

Metric Collection Guidance: - Auto-flow rate: Critical_endpoint_reviews_with_all_4_auto_tickets / total_Critical_endpoint_reviews × 100. Source: integration telemetry - Downstream response: update_tickets_responded_within_14d / total_update_tickets × 100. Source: downstream backlog aging. Monthly - Sponsor review: Count quarterly reviews with documented quality assessment. Source: program calendar - Substantive rate: substantive_count / total_reviewed × 100. Sponsor-assessed

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 6: Cross-Domain Coordination Protocol

Q2.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?

Evidence Required: - [ ] Cross-domain coordination protocol: Endpoints → Software (managed-endpoint AI assistant data-exfiltration reaching Software-domain LLM-backend service, activates Software-domain EH and IM alongside Endpoints containment), Endpoints → Data (SaaS-AI feature processed data classified as Data-domain training corpus without approval, activates Data-domain EH and IM alongside Endpoints SaaS-AI silent-enablement play), Endpoints → Processes (chatbot output-corruption affecting customer-service workflow routing outputs to business-process decision, activates Processes-domain business-continuity coordinator alongside Endpoints chatbot-abuse play) - [ ] Named cross-domain contacts registry: Software-domain IM, Data-domain IM, Processes-domain IM, last verified within 90 days - [ ] Quarterly contact verification records (last 4 quarters) - [ ] Multi-domain incident activation records: shared status board, single IC from primary impacted domain, joint post-incident review - [ ] IC designation procedure for cross-domain endpoint incidents

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Cross-domain protocol used for 100% of multi-domain endpoint incidents | % | % | 100% | ☐ | | | Cross-domain contact registry verified within last 90 days | Yes/No | Yes/No | Yes | ☐ | | | Joint post-incident reviews for multi-domain endpoint incidents | % | % | 100% | ☐ | | | Quarterly contact verification on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | |

Metric Collection Guidance: - Protocol usage: multi_domain_endpoint_incidents_using_protocol / total_multi_domain_endpoint × 100. Source: incident coordination records - Contact currency: Date of last verification. Target: within 90 days. Source: contact registry - Joint PIR: multi_domain_incidents_with_joint_PIR / total_multi_domain × 100. Source: PIR records - Verification cadence: Count quarterly verification events. Source: program calendar

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 3

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

Q3.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?

Evidence Required: - [ ] ISAC participation records: sector ISAC membership (FS-ISAC AI WG for mobile-banking AI endpoint incidents, H-ISAC for patient-facing chatbot incidents, IT-ISAC for managed-endpoint AI incidents); ISAC AI endpoint incident feeds consumed; ≥4 anonymized contributions per year (incident type, ATLAS tactic tag, HAI-TTP tag, archetype, containment play, MTTR) - [ ] CSA Endpoint AI Safety Initiative contributions: ≥1 per year, AI endpoint severity-anchor definitions, playbook template schemas, SaaS-AI shadow-enablement response templates - [ ] OWASP MASVS contributions (if applicable): ≥1 per year, mobile AI app incident response patterns (model-integrity failure response, on-device data-breach response), verification requirements for mobile AI app incident-response capability - [ ] MITRE ATLAS Endpoints-tactic contribution: ≥1 per year for endpoint-relevant tactics; contribution tracking log - [ ] Legal vetting sign-offs; adoption tracking log

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | ISAC AI endpoint incident contributions per year | 0 | ___ | ≥4 | ☐ | | | CSA / OWASP MASVS contributions per year | 0 | ___ | ≥2 | ☐ | | | ATLAS Endpoints-tactic contributions per year | 0 | ___ | ≥1 | ☐ | | | External adoption events tracked | 0 | ___ | ≥1 | ☐ | |

Metric Collection Guidance: - ISAC contributions: Count anonymized endpoint incident-classification submissions per year. Source: ISAC contribution log - CSA / OWASP contributions: Count contributions per year. Source: contribution log - ATLAS contributions: Count technique observations or mitigation entries for endpoint-relevant tactics. Source: ATLAS contribution log - Adoption events: Count citations or adoptions. Source: adoption tracking log. Semi-annual

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 8: Pre-Authorized Automated Runbook Decisioning for Endpoint Incidents

Q3.2: Are ≥3 pre-authorized automated endpoint containment actions live (extension force-remove, SaaS-AI feature disable, edge-device remote-disable, chatbot rate-limit tighten), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with the pre-authorization policy reviewed quarterly?

Evidence Required: - [ ] Pre-authorization policy: published list of ≥3 automated endpoint containment actions with confidence thresholds (e.g., extension force-remove for Low/Medium-tier endpoint when unsanctioned-extension detection fires ≥95%, extension ID definitively not in allowlist, data-access permissions confirmed; SaaS-AI feature disable for shadow-AI-in-SaaS detection on non-Critical-tier feature, feature ID definitively not in approved list; edge-device remote-disable for non-Critical-tier device when physical-tamper detection fires ≥99%; rate-limit emergency-tighten for customer-facing chatbot when abuse-pattern-at-scale detection fires ≥90%, volume and pattern both exceeded) - [ ] Legal/Privacy and executive sponsor sign-off records, dated and versioned - [ ] Critical-tier archetype handling: human confirmation within 15 minutes; timer-based fallback with executive notification - [ ] Automation execution log samples (5 records): each action produces audit log entry in IM-Endpoints backlog, human-review ticket, notification to archetype deployer-duty owner - [ ] Quarterly policy review records (last 4 quarters); unexpected-outcome triggered out-of-cycle reviews within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pre-authorized automated endpoint containment actions operational | 0 | ___ | ≥3 defined, vetted, live | ☐ | | | % actions producing full audit record + human-review ticket | % | % | 100% | ☐ | | | Quarterly policy review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Unexpected-outcome out-of-cycle reviews within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Actions live: Count unique automated endpoint containment action types defined, vetted, and deployed. Source: pre-authorization policy + automation deployment record - Audit completeness: automated_endpoint_actions_with_audit_AND_ticket / total_automated_endpoint_actions × 100. Source: automation telemetry - Policy review: Count quarterly reviews completed. Source: review calendar - Out-of-cycle timeliness: reviews_within_5bd / total_unexpected_outcomes × 100. Source: out-of-cycle review log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 9: MTTR Benchmarking for Endpoint Incidents

Q3.3: Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per endpoint 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?

Evidence Required: - [ ] MTTR benchmark data sources: sector ISAC AI endpoint incident data exchanges, OWASP MASVS practitioner community data on mobile AI app incident response, CSA Endpoint AI Safety Initiative observational data, CISO and AI-endpoint practitioner peer roundtables, at least two active; updated semi-annually - [ ] Quarterly MTTR benchmark brief (last 4 quarters): MTTR per endpoint incident class (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) vs. benchmark; per tier vs. benchmark; delta trend - [ ] Investment-driver section: above-benchmark classes mapped to specific practice gap (missing detection, unclear playbook, MDM policy gap, on-call latency) with budget-linked improvement proposal - [ ] Quarterly brief delivery records (last 4 quarters on-time) - [ ] Benchmark data source refresh log: updated semi-annually; stale benchmarks flagged

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | MTTR benchmark brief published quarterly to sponsor | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Critical-tier MTTR at or below benchmark for ≥4 of 7 endpoint incident classes | ___ / 7 | ___ / 7 | ≥4 of 7 | ☐ | | | Above-benchmark endpoint classes with investment proposals | % | % | 100% | ☐ | | | Benchmark data source refresh within last 6 months | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Brief cadence: Count briefs delivered on schedule. Source: program reporting calendar - Benchmark performance: For each of 7 endpoint incident classes, compare Critical-tier MTTR to benchmark. Count at or below. Source: MTTR brief. Quarterly - Investment proposals: above_benchmark_endpoint_classes_with_proposal / total_above_benchmark × 100. Source: brief investment-driver section - Benchmark freshness: Date of most recent external source update. Target: within 180 days. Source: benchmark refresh log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Summary Scorecard

Question	Level	Activity	Score
Q1: Unified endpoint backlog and triage rubric	L1	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q2: AI-specific endpoint playbook (7 endpoint plays)	L1	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q3: Regulatory SLA tracker (COPPA/FERPA) and PIR loop	L1	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q4: Tier-calibrated endpoint playbook and 24/7 on-call	L2	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q5: Post-incident review auto-flow integration	L2	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q6: Cross-domain coordination protocol	L2	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q7: ISAC / CSA / OWASP MASVS / ATLAS contributions	L3	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q8: Pre-authorized automated endpoint runbook	L3	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q9: MTTR benchmarking for endpoint incidents	L3	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0

Level 1 Score (avg Q1–Q3): _____ / 1.0

Level 2 Score (avg Q4–Q6): _____ / 1.0

Level 3 Score (avg Q7–Q9): _____ / 1.0

Overall IM-Endpoints Score (L1×0.5 + L2×0.3 + L3×0.2): _____ / 1.0

Assessment Date: _________

Assessor: _________

Next Assessment Due: _________

Document Version: HAIAMM v3.0, 2026-05-15, Verifhai Practice: Issue Management (IM) Domain: Endpoints Source of Truth: docs/practices/IM-Endpoints-OnePager.md

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown

Issue Management (IM) - Endpoints Assessment

Issue Management (IM) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

Instructions

Scoring Methodology

Maturity Level 1

Question 1: Unified AI/HAI Endpoint Issue Backlog and Triage Rubric

Question 2: AI-Specific Endpoint Incident Playbook, Seven Endpoint Containment Plays

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Maturity Level 2

Question 4: Tier-Calibrated Endpoint Incident Playbook and 24/7 On-Call

Question 5: Post-Incident Review Auto-Flow Integration

Question 6: Cross-Domain Coordination Protocol

Maturity Level 3

Question 7: Industry-Coordinated Endpoint Incident Sharing and Contribution

Question 8: Pre-Authorized Automated Runbook Decisioning for Endpoint Incidents

Question 9: MTTR Benchmarking for Endpoint Incidents

Summary Scorecard