Implementation Review (IR) - Endpoints Assessment

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

Implementation Review (IR) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Implementation Review (IR) Domain: Endpoints Purpose: Assess organizational maturity in verifying that the actual configuration of AI/HAI-enabled endpoints and user-facing AI interfaces matches the design approved at DR, and stays there as the endpoint evolves. 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 practice

Level Score = Average of the three question scores at that level Overall Score = Weighted average across all levels achieved

Maturity Level 1

Objective: Run per-archetype implementation reviews at deployment, annually, and on material change, verifying deployed endpoint configuration matches the SA-Endpoints pattern, the DR decision, and that the SR-Endpoints REM evidence is current

At this level, the gap between approved design and deployed endpoint configuration is systematically checked at the moments it matters most. Every review produces findings with severity tags, named owners, and SLA-bound resolution dates.

Question 1: Per-Archetype Endpoint IR Checklist

Q1.1: Is there a published, per-archetype IR checklist, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), covering MDM-policy-matches-design, config-matches-DR, SR REM evidence currency, logging-flow verification, and kill-switch test?

Evidence Required: - [ ] Published checklist per SM-Endpoints archetype on file and linked from the SM-Endpoints inventory (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device) - [ ] Chatbot / conversational UI checklist verifies Art. 50 disclosure rendered in live UX (not staging): sample-check of the live deployed interface confirming AI disclosure present on first and every subsequent interaction; screenshot as evidence - [ ] Edge AI device checklist verifies firmware and model signature currency (device attestation report confirms firmware version and model hash match DR-approved values) and remote-disable function (remote-disable command executed and AI capability confirmed unavailable within declared SLA) - [ ] MDM policy verification present (not design text only): DLP rules confirmed active via MDM console export (Jamf / Intune / Kandji), AI assistant allowlist enforcement confirmed, policy deployment scope confirmed matching approved endpoint population - [ ] Kill-switch test executed and recorded: test input, expected behavior, actual behavior, test date, and reviewer on file, not a checkbox without a test record; AI feature or assistant confirmed unavailable within specified SLA - [ ] Vendor no-train flag verified via admin API (not from contract language alone) for endpoints routing data to LLM providers: probe result on file with IR record

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI-enabled endpoints with a deployment IR record	___%	___%	100%	☐	SM-Endpoints inventory × IR records
% active AI/HAI-enabled endpoints with a current-year IR record	___%	___%	≥90%	☐	SM-Endpoints inventory × IR records
Critical / blocker findings open at deployment	___	___	0	☐	Findings backlog
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - Deployment IR coverage: count endpoints in SM-Endpoints inventory with a linked IR record dated at or before production rollout divided by total endpoints entering production. Formula: endpoints_with_deployment_IR / total_endpoints_in_production × 100 - Current-year IR coverage: count endpoints with an IR record dated within the last 12 months. Source: SM-Endpoints inventory last-IR-date field - Blocker findings at deployment: count Critical/blocker findings that were open on the deployment date. Source: IM-Endpoints findings history - High finding closure time: median calendar days from finding-opened to evidence-linked finding-closed. Source: IM-Endpoints backlog timestamps

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 per-archetype checklist published)

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 2: Review Triggers and Endpoint Drift Sources

Q1.2: Do 100% of new AI/HAI-enabled endpoints going to production in the last 90 days carry a deployment IR record, with material-change triggers wired to SM-Endpoints inventory events, and are MDM telemetry, browser policy state, SaaS admin audit feeds, mobile MDM, and edge attestation reports reviewed at each IR?

Evidence Required: - [ ] Deployment IR records on file for all endpoints entering production in the last 90 days; MDM policy export and admin-console screenshots confirm the IR was completed before the production rollout - [ ] Material-change trigger wired to SM-Endpoints inventory: SaaS-AI feature enabled tenant-wide, DLP scope changed, extension-allowlist updated, AI assistant or app version changed beyond DR-approved range, Art. 50 disclosure UX modified, local model or firmware signature changed, and vendor no-train settings changed all generate a review-due alert within 5 business days - [ ] MDM telemetry reviewed at each IR: Jamf / Intune / Kandji policy compliance reports; device enrollment and compliance state; AI app version and permission reports reviewed and compared against DR-approved MDM policy baseline - [ ] Browser admin policy state reviewed: Chrome / Edge / Safari admin policy export; extension allowlist compliance report; per-extension permission scope compared against DR-approved manifest for each installed extension - [ ] SaaS admin audit feeds reviewed: M365 admin audit log, Slack admin event log, Google Workspace admin audit, Notion admin settings reviewed for AI feature enable/disable events and data-scope configuration changes since the last IR - [ ] Edge device attestation reports reviewed: firmware version, model hash, secure-boot status, and tamper-detection status confirmed current against DR-approved values; any device outside the declared window documented as a finding

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI-enabled endpoints with a deployment IR record	___%	___%	100%	☐	SM-Endpoints inventory × IR records
% active AI/HAI-enabled endpoints with a current-year IR record	___%	___%	≥90%	☐	SM-Endpoints inventory × IR records
% material changes to production endpoints that trigger an IR before the change goes live	___%	___%	100%	☐	SM-Endpoints change events × IR records
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - Material-change IR trigger rate: cross-reference SM-Endpoints inventory material-change events against IR records created within 5 business days of each event - MDM telemetry review rate: % of IRs where MDM policy compliance report was actively queried (not just design text reviewed). Source: IR evidence records method field - SaaS admin audit review coverage: % of IRs where SaaS admin audit feeds were reviewed for AI feature events since the last IR. Source: IR evidence records - Edge attestation review coverage: % of IRs for edge device archetypes where device attestation reports were reviewed. Source: IR evidence records

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 3: Findings Tracking and SR-Endpoints REM Loop

Q1.3: Are findings severity-tagged and tracked in IM-Endpoints with named owners and SLA-bound closure dates, and does every IR finding that reveals stale or inaccurate REM evidence trigger an SR-Endpoints REM row update before the finding is closed?

Evidence Required: - [ ] Findings backlog in IM-Endpoints showing all IR findings with severity tag (Critical / High / Medium / Low), named owner (not "the IT team"), SLA-bound closure date, and linked after-fix evidence artifact (admin-console screenshot, MDM compliance report, SaaS audit log entry, test record) - [ ] SR-Endpoints REM update loop active: IR findings that reveal stale or inaccurate REM evidence have a linked REM row update on file before the finding is closed - [ ] Severity calibration consistent: Critical findings include Art. 50 disclosure absent from live customer-facing chatbot, DLP scope collapsed to allow regulated data to reach the AI vendor model, and vendor no-train setting verified from contract language without opening the vendor admin console, not downgraded to Medium - [ ] Mobile MDM reports reviewed at each IR for mobile AI app archetypes: app version compliance, model hash, and device attestation passing status confirmed and documented - [ ] Findings-aging dashboard reviewed at least monthly by the program sponsor: meeting record or dashboard screenshot on file - [ ] Kill-switch test record on file with date, method, and reviewer: AI feature or assistant confirmed unavailable within specified SLA, not a checklist box without a test execution record

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% AI/HAI-enabled endpoints with a deployment IR record	___%	___%	100%	☐	SM-Endpoints inventory × IR records
% active AI/HAI-enabled endpoints with a current-year IR record	___%	___%	≥90%	☐	SM-Endpoints inventory × IR records
Critical / blocker findings open at deployment	___	___	0	☐	Findings backlog
Median closure time for High findings	___ days	___ days	≤7 days	☐	Findings backlog

Metric Collection Guidance: - REM update loop rate: count IR findings where the closure is linked to an SR-Endpoints REM row update vs. total IR findings that identified stale REM evidence. Source: IM-Endpoints × SR-Endpoints REM cross-reference - Named-owner coverage: count findings with a named individual as owner divided by total open findings. Source: IM-Endpoints - SLA adherence by severity: % of High findings closed within 7 days; % of Critical findings closed before deployment cutover. Source: IM-Endpoints timestamps - Findings-aging review cadence: confirm monthly review via calendar record or dashboard export. Source: program sponsor review log

Evidence Location: _________

Validation Date: _________

Notes: _______

Maturity Level 2

Objective: Detect configuration drift continuously for Critical and High-tier endpoints via MDM webhook events, browser-policy state monitoring, SaaS-admin webhooks, mobile MDM scan deltas, edge attestation freshness, and vendor admin API recurrent probes; calibrate IR cadence per SM-Endpoints tier

At this level, implementation review becomes a continuous signal. MDM webhooks, browser-policy monitoring, SaaS-admin webhooks, mobile MDM scan deltas, edge attestation freshness, and vendor admin API probes are all wired to automated detection.

Question 4: Continuous Endpoint Drift Detection

Q2.1: Are ≥90% of Critical-tier AI/HAI-enabled endpoints under continuous drift detection, via MDM webhook events, browser-policy state monitoring, SaaS-admin webhooks, mobile MDM scan deltas, and edge device attestation freshness, with median detection latency ≤7 days?

Evidence Required: - [ ] MDM webhook events active for Critical and High-tier endpoints: Jamf / Intune / Kandji policy compliance events (DLP rule active/inactive, AI app allowlist changes, device enrollment/unenrollment) trigger automated comparison against the DR-approved MDM policy baseline; material deviations auto-open IR findings - [ ] Browser-policy state monitoring active: Chrome / Edge / Safari admin policy state checked on a scheduled basis against the DR-approved extension allowlist and per-extension permission scope; deviations auto-open IR findings - [ ] SaaS-admin webhook active for Critical and High-tier SaaS-AI integrations: M365 / Slack / Workspace / Notion admin event webhooks flag any AI feature enablement event at the tenant or broad-group level; a feature enablement without a corresponding open DR approval is a Critical finding - [ ] Mobile MDM scan deltas active: scheduled mobile MDM scan compares installed app version and model hash against DR-approved values; version or hash changes since the last scan auto-open IR findings - [ ] Edge attestation freshness monitored: edge device attestation report freshness checked against declared window (≤7 days for Critical-tier); a device without a current attestation auto-opens an IR finding - [ ] Drift-detection pipeline health monitored: % Critical endpoints producing a fresh signal in the last 7 days; on-call alert configured for >48 hours of feed silence; alert test record on file

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints under continuous drift detection (MDM, browser-policy, SaaS-admin, mobile MDM, edge attestation)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% Critical/High-tier endpoints with vendor no-train and data-handling settings verified via admin API (not contract alone)	___%	___%	≥80%	☐	Vendor API probing log
% SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR	___%	___%	≥95%	☐	SaaS-admin webhook telemetry

Metric Collection Guidance: - Continuous drift detection coverage: count Critical-tier endpoints with all five signal sources active (MDM webhooks, browser-policy monitoring, SaaS-admin webhooks, mobile MDM scan deltas, edge attestation freshness) divided by total Critical-tier endpoints. Source: drift-detection pipeline configuration registry - Drift detection latency: median time from change-event timestamp to IR-finding-opened timestamp. Source: IR telemetry × IM-Endpoints - SaaS-admin webhook coverage: count in-scope SaaS platforms with a webhook or polling integration configured divided by total in-scope SaaS platforms. Source: SaaS-admin webhook telemetry - Tier-cadence adherence: count endpoints reviewed within their published cadence window divided by total endpoints. Source: IR schedule × SM-Endpoints inventory last-IR-date

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 5: Vendor Admin API Probing for No-Train and Data-Handling Settings

Q2.2: Are vendor no-train and data-handling settings verified via vendor admin APIs on a monthly (Critical) and quarterly (High) probing cadence, not from contract language alone, covering ≥80% of Critical/High-tier endpoints?

Evidence Required: - [ ] Vendor admin API probe records on file for Critical/High-tier endpoints: Bedrock (Service Control Policy and CloudTrail logging active); Vertex AI / Gemini (Google Cloud Organization Policy, no training-data opt-in active); Azure OpenAI (data-processing and abuse-monitoring settings match DR-approved posture); OpenAI API (Org Settings API, data_controls.training_data_sharing = false); Anthropic (Organization admin settings confirming no-train commitment) - [ ] SaaS-AI platform admin settings probed for Critical/High-tier SaaS-AI endpoints: M365 Copilot admin settings, Slack AI admin settings, Google Workspace AI admin settings, Notion AI admin settings, data-scope and training-opt-out settings confirmed matching DR-approved posture; admin API used where available; UI-based verification with screenshot as fallback - [ ] Probing cadence log showing Critical-tier probes monthly and High-tier quarterly, not one-time screenshots; all probe runs date-stamped with method - [ ] Delta findings on file: any setting change detected (no-train toggle reset, data scope expanded, training opt-in activated by feature launch) generated a finding with severity matching the data-class impact of the change - [ ] Vendor API probing calendar maintained: missed probes tracked as process-metric failures with root cause and remediation on file - [ ] IR findings from probe deltas auto-open IM-Endpoints tickets with severity and owner pre-populated

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints under continuous drift detection (MDM, browser-policy, SaaS-admin, mobile MDM, edge attestation)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% Critical/High-tier endpoints with vendor no-train and data-handling settings verified via admin API (not contract alone)	___%	___%	≥80%	☐	Vendor API probing log
Tier-cadence adherence (% of endpoints reviewed on their published cadence)	___%	___%	≥95%	☐	IR schedule × SM-Endpoints inventory

Metric Collection Guidance: - Vendor admin API probe coverage: count Critical/High-tier endpoints with a vendor admin API probe result dated within the current probe cycle (≤30 days Critical, ≤90 days High) divided by total Critical/High-tier endpoints. Source: vendor API probing log - Delta finding rate: count probe cycles where a setting change was detected and a finding was generated vs. total probe cycles. Source: probe log × IM-Endpoints - Probe cadence compliance: count monthly Critical-tier probes completed on schedule vs. planned. Source: probing calendar - API vs. UI ratio: % of probes conducted via vendor admin API vs. UI-based screenshot fallback. Source: probing log method field

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 6: SaaS-AI Feature Flagging and Tier-Calibrated Cadence

Q2.3: Are ≥95% of SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR within 24 hours, and is tier-cadence adherence ≥95% with Critical-tier findings aged per the SM-Endpoints L2 tier-treatment matrix SLAs?

Evidence Required: - [ ] SaaS-admin webhook coverage confirmed for all in-scope SaaS platforms: M365 / Slack / Workspace / Notion webhooks (or polling for platforms without webhooks) configured to flag any AI feature enablement event at the tenant or broad-group level; coverage list on file - [ ] Feature-enablement events without a corresponding open DR approval confirmed to be treated as Critical findings: at least one example of a feature enablement auto-flagged and routed to IR in the last 12 months on file - [ ] Tier-cadence enforcement visible in SM-Endpoints inventory: Critical-tier endpoints flagged when no IR in the last 180 days; escalation to program sponsor automated and test record on file - [ ] IR backlog tier-aware: Critical-tier findings reported separately; no Critical-tier finding waiting behind Low-tier queue items; tiered backlog dashboard or report on file - [ ] Drift findings from automated detection auto-open IM-Endpoints tickets, not dead-ending in an alert dashboard; confirmed via a sample of auto-opened findings from the last 90 days - [ ] Tier-SLA breach rate tracked: count Critical-tier findings exceeding the SM-Endpoints L2 tier-treatment matrix SLA divided by total Critical-tier findings; rate reported to program sponsor monthly

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints under continuous drift detection (MDM, browser-policy, SaaS-admin, mobile MDM, edge attestation)	___%	___%	≥90%	☐	Drift-detection telemetry
Median drift detection latency, Critical-tier	___ days	___ days	≤7 days	☐	IR telemetry
% SaaS-AI tenant-wide feature enablements automatically flagged and routed to IR	___%	___%	≥95%	☐	SaaS-admin webhook telemetry
Tier-cadence adherence (% of endpoints reviewed on their published cadence)	___%	___%	≥95%	☐	IR schedule × SM-Endpoints inventory

Metric Collection Guidance: - SaaS-AI feature flagging rate: count SaaS-AI tenant-wide feature enablement events that were automatically flagged and routed to IR within 24 hours divided by total detected enablement events. Source: SaaS-admin webhook telemetry - Tier-cadence adherence: count endpoints reviewed within their published cadence window divided by total endpoints. Source: SM-Endpoints inventory last-IR-date × cadence policy - Critical-tier SLA breach rate: count Critical-tier findings exceeding the SM-Endpoints L2 tier-treatment matrix SLA divided by total Critical-tier findings. Source: IM-Endpoints timestamps - Auto-open ticket rate: count drift findings that auto-opened an IM-Endpoints ticket divided by total drift findings. Source: drift-detection telemetry × IM-Endpoints

Evidence Location: _________

Validation Date: _________

Notes: _______

Maturity Level 3

Objective: Continuous configuration attestation for Critical-tier endpoints with a daily attestation signal confirming pattern compliance and evidence freshness, automatic IM ticket on drift, and contribution to CSA endpoint working groups, OWASP MASVS, and OASIS attestation standards

At this level, Critical-tier AI/HAI-enabled endpoints are attested continuously. Every Critical endpoint produces a daily attestation signal across pattern compliance, evidence freshness, and configuration tolerance. Drift auto-opens IM-Endpoints tickets.

Question 7: Daily Attestation Signal for Endpoints

Q3.1: Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily attestation signal across all three dimensions (pattern compliance, evidence freshness, configuration tolerance), with deviations auto-opening IM-Endpoints tickets within 1 hour?

Evidence Required: - [ ] Daily attestation pipeline operational covering three dimensions per Critical-tier endpoint: (1) pattern compliance, MDM DLP rules match approved scope, browser extension allowlist enforced, SaaS-AI feature state matches DR-approved posture, Art. 50 disclosure confirmed present in live UX via automated probe, device firmware and model signatures current; (2) evidence freshness, vendor admin API probe ≤30 days (Critical) / ≤90 days (High), Art. 50 disclosure sample-check ≤7 days (Critical chatbots), kill-switch test ≤90 days, MDM policy compliance report ≤24 hours; (3) configuration tolerance, deployed configuration within declared tolerances (minor app version updates within approved range tolerated; SaaS-AI feature scope expansion never tolerated without DR re-review) - [ ] Auto-open IM-Endpoints ticket on drift: ticket created within 1 hour of detection; carries drift dimension (pattern compliance / evidence freshness / configuration), specific control that failed tolerance, and link to DR decision record - [ ] Attestation-pipeline health monitored: % Critical endpoints with fresh signal in the last 24 hours; on-call paged for any Critical endpoint silent for >24 hours; pager history on file - [ ] Zero stale-evidence violations confirmed for Critical-tier REMs: no evidence citations in active Critical-tier REMs outside their defined freshness window - [ ] Attestation artifacts regulator-consumable: machine-readable format confirmed suitable for EU AI Act Art. 9 risk-management evidence and deployer-duty records per Art. 26 via test export - [ ] Configuration tolerance definitions documented per-control: tolerance rules versioned and linked from SM-Endpoints inventory; tuned to avoid alert fatigue from minor MDM policy refreshes or app patch updates

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Endpoints integration telemetry
Evidence freshness violations (stale evidence in active REMs)	___	___	0 for Critical; trending toward 0 for High	☐	Attestation telemetry
IR reviewer-hours per Critical endpoint per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - Daily attestation coverage: count Critical-tier endpoints with a signed attestation artifact dated within the last 24 hours covering all three dimensions divided by total Critical-tier endpoints. Source: attestation pipeline telemetry - Auto-open ticket latency: median time from drift-detection event to IM-Endpoints ticket created. Source: attestation pipeline timestamp × IM-Endpoints created-at timestamp - Stale-evidence violations: count Critical-tier REM rows with evidence citations outside their freshness window. Source: attestation pipeline evidence-freshness dimension output - IR reviewer-hours: total hours logged for Critical-tier endpoint IR activities per year. Source: reviewer time tracking

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 8: External Endpoint Schema Contribution

Q3.2: Has the program published per-archetype configuration baseline schemas to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented external adoption and internal practice aligned to the published versions?

Evidence Required: - [ ] Per-archetype configuration baseline schemas published to at least one external body: CSA endpoint working groups (reference attestation schema for AI/HAI-enabled endpoint configurations), OWASP MASVS extensions (mobile AI app and browser-based AI tool configuration baselines), or OASIS AI assurance standards (per-archetype endpoint configuration controls mapped to OASIS control categories) - [ ] Internal practice aligned to published external versions: documented mapping between internal IR checklist and published schema; internal-only deviations proposed as upstream changes with a PR or issue link - [ ] External adoption tracked: citations, forks, direct acknowledgment from peer organizations, or inclusion in external tooling or assessment frameworks, evidence on file - [ ] Schema publication pipeline active: at least one schema in-draft, in-review, or published at any time; publication status tracker maintained - [ ] Adoption trend documented: at least one adoption data point on file since initial publication - [ ] Internal schema version pinned to published external version: divergence documented as a proposed upstream change

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Endpoints integration telemetry
External adoption of published configuration baseline schemas	0	tracked	trending up	☐	External telemetry
IR reviewer-hours per Critical endpoint per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - External adoption: count citations, forks, and direct acknowledgments per quarter since publication. Source: GitHub stars/forks, external publication references, peer organization acknowledgments - Schema alignment rate: % of internal IR checklist items directly traceable to a published external schema item. Source: internal-to-external schema mapping document - Publication pipeline health: number of schemas in active publication stages. Source: publication tracker

Evidence Location: _________

Validation Date: _________

Notes: _______

Question 9: Automated Drift-to-IM Escalation and Post-Incident Feedback Loop

Q3.3: Is the post-incident IR feedback loop operational, IM-Endpoints post-incident reviews include a mandatory IR-record re-examination step, and ≥1 attestation rule update is produced per material incident?

Evidence Required: - [ ] All IR findings (daily attestation and periodic reviews) flow into IM-Endpoints automatically with severity and SLA pre-populated from the SM-Endpoints L2 tier-treatment matrix; no manual entry required for attestation-generated findings - [ ] IM-Endpoints SLA clock automated: overdue Critical findings escalate to the program sponsor at 50% and 100% of the SLA window automatically; escalation automation tested quarterly with synthetic finding, test record on file - [ ] Post-incident IR feedback loop documented in the IM-Endpoints incident-review template: a mandatory IR-record re-examination step confirmed in the last material incident review record - [ ] Attestation rule updates produced from incident learning: at least one attestation rule update linked from a completed incident review in the last 12 months - [ ] Post-incident IR step completion tracked: % of material incidents in the last 12 months with a completed post-incident review including the IR-record re-examination step - [ ] Attestation-pipeline health log on file: ≥90% of Critical endpoints with fresh signal in the last 24 hours; pager history on file

Outcome Metrics:

Metric	Baseline	Current	Target	Met?	Notes
% Critical-tier endpoints producing a daily attestation signal	___%	___%	≥90%	☐	Attestation telemetry
% attestation findings auto-opening IM tickets within 1 hour of detection	___%	___%	≥95%	☐	IM-Endpoints integration telemetry
Evidence freshness violations (stale evidence in active REMs)	___	___	0 for Critical; trending toward 0 for High	☐	Attestation telemetry
IR reviewer-hours per Critical endpoint per year	___ hrs	___ hrs	trending down QoQ	☐	Reviewer time tracking

Metric Collection Guidance: - Auto-open ticket rate: count attestation-generated findings that created an IM-Endpoints ticket within 1 hour divided by total attestation-generated findings. Source: attestation pipeline × IM-Endpoints integration telemetry - Escalation automation test pass rate: % of quarterly escalation tests that confirmed correct automated escalation. Source: escalation test records - Post-incident IR step completion: % of material incident post-reviews with the IR-record re-examination step completed. Source: IM-Endpoints incident review records - Attestation rule update rate: count attestation rule updates linked from post-incident reviews in the last 12 months. Source: attestation pipeline rule-change log × IM-Endpoints incident reviews

Evidence Location: _________

Validation Date: _________

Notes: _______

Summary Scorecard

Level	Question	Score	Weight
L1	Q1: Per-Archetype Endpoint IR Checklist	___	33%
L1	Q2: Review Triggers and Endpoint Drift Sources	___	33%
L1	Q3: Findings Tracking and SR-Endpoints REM Loop	___	33%
L1 Total		___
L2	Q4: Continuous Endpoint Drift Detection	___	33%
L2	Q5: Vendor Admin API Probing, No-Train and Data-Handling	___	33%
L2	Q6: SaaS-AI Feature Flagging and Tier-Calibrated Cadence	___	33%
L2 Total		___
L3	Q7: Daily Attestation Signal for Endpoints	___	33%
L3	Q8: External Endpoint Schema Contribution	___	33%
L3	Q9: Automated Escalation and Post-Incident Feedback	___	33%
L3 Total		___
Overall IR-Endpoints Score		___

Current Maturity Level: ___

Key Findings:

Priority Improvements:

Document Version: HAIAMM v3.0 Practice: Implementation Review (IR) Domain: Endpoints Questionnaire Date: 2026-05-15 Author: Verifhai

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