> **v3.0 canonical:** This questionnaire is authored against the v3.0 source-of-truth one-pager [`../practices/ML-Endpoints-OnePager.md`](../practices/ML-Endpoints-OnePager.md) and the §10.2 priority compliance map in [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md). Through-lines: EU AI Act Art. 12 and Art. 50 transparency / disclosure audit trail · GDPR Art. 30 records of processing for customer-facing AI · ISO/IEC 42001 AIMS operational evidence.

---

# Monitoring & Logging (ML) - Endpoints Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Monitoring & Logging (ML)
**Domain:** Endpoints
**Purpose:** Assess organizational maturity in establishing the per-archetype logging baseline for AI/HAI endpoints, operating a high-signal detection set targeting TA-Endpoints threats, and producing the evidence trail that satisfies EU AI Act Arts. 12 and 50, GDPR Art. 30, and ISO/IEC 42001 AIMS requirements on demand.

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you have done) and **Outcome Metrics** (how well it is working)
- **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 a 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 outcome metrics meet targets |
| 0.0 | Not Implemented | No evidence of the practice |

**Level score** = average of the three question scores for that level.
**Overall ML-Endpoints score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.

---

## Maturity Level 1
**Objective:** Establish the per-archetype logging baseline, operate a small high-signal detection set targeting the top TA-Endpoints threats, and produce an on-demand evidence trail that satisfies EU AI Act Arts. 12 and 50, GDPR Art. 30, and ISO/IEC 42001 AIMS requirements within a published SLA.

---

### Question 1: Per-Archetype Logging Baseline

**Q1.1:** Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI endpoint archetype in the SM-Endpoints inventory, and has compliance of each production archetype been measured against it within the last quarter?

**Evidence Required:**
- [ ] Published baseline specifying minimum events per archetype: AI assistant/copilot on managed endpoint (session/paste-block-paste-allow DLP-decision/tool-call/admin-audit), browser-based AI tool (extension-install/extension-uninstall/extension-permission-grant/DLP-decision/backend-SSO), chatbot/conversational UI (customer-interaction with disclosure-shown flag/output-filter/abuse-detection), multi-modal AI interface (input with content hash/output-safety-filter/cross-modal-consistency), AI-augmented productivity SaaS-AI (admin-audit AI-feature enablement/per-feature usage/DLP-decision), mobile AI app (app-launch/permission-grant/local-model-integrity/on-device-action), edge AI device (boot-attestation/physical-tamper/uplink/remote-disable), and admin-audit + identity events cross-archetype
- [ ] Chatbot interaction events: disclosure-shown flag (yes/no, disclosure-template-version) and PII redaction recorded per session, not raw customer message content for regulated data
- [ ] Edge AI device: boot-attestation result, firmware version, and sealed PCR values hash included in boot-attestation event
- [ ] Retention window configured per §10.2 priority compliance map: EU AI Act Art. 12 high-risk logs ≥6 months; GDPR Art. 30 per data-class and purpose; HIPAA ≥6 years where applicable; COPPA for children-facing endpoints; FERPA for educational endpoints; sector mobile-banking where applicable; longest governs per archetype
- [ ] Export path (JSON or structured format) tested at least annually; export SLA ≤24 hours documented
- [ ] Compliance audit within the last quarter; gaps on IM-Endpoints backlog with named owner

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % production AI/HAI endpoint archetypes meeting per-archetype logging baseline | ___% | ___% | ≥90% | ☐ | |
| % production endpoint archetypes with retention meeting longest applicable regulation | ___% | ___% | 100% | ☐ | |
| Export SLA test result, on-demand pull time (quarterly drill) | ___h | ___h | ≤24h | ☐ | |
| Archetype-baseline gap count on IM-Endpoints backlog with named owner | ___ | ___ | 0 unowned gaps | ☐ | |

**Metric Collection Guidance:**
- **Logging baseline compliance**: Cross-reference each production endpoint archetype against the published baseline checklist. Count archetypes meeting all required fields divided by total archetypes. Source: logging configuration audit × SM-Endpoints inventory.
- **Retention compliance**: Compare configured retention against the longest applicable regulation from §10.2 plus sector overlays for each archetype. Source: retention policy audit.
- **Export SLA**: Time the quarterly deployer-duty drill. Measure request trigger to assembled package. Source: drill records.
- **Gap count**: Count IM-Endpoints open findings tagged "logging-baseline-gap" with named owner. Source: IM-Endpoints backlog.

**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 logging baseline)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 2: High-Signal Detection Set

**Q1.2:** Is a high-signal detection set of ≤12 detections active, each tied to a TA-Endpoints archetype threat, including regulated-data paste-attempt, customer-data egress via AI assistant, unsanctioned browser extension, SaaS-AI shadow-enablement, mobile-app integrity failure, edge tamper, Art. 50 disclosure suppression, chatbot abuse at scale, and cross-tenant SaaS-AI exposure, with false-positive rates tracked and monthly tuning reviews occurring?

**Evidence Required:**
- [ ] Detection registry: each entry includes owner, detection query, SLA, archetype tag, HAI-TTP tag, last-tuned date, and false-positive rate
- [ ] Regulated-data paste-attempt blocked (high volume) detection active: DLP block events for regulated-data paste into AI tool prompt fields exceeding threshold per user/endpoint in rolling window; routes to IM-Endpoints and EG-Endpoints (EA TTP)
- [ ] Customer-data egress via AI assistant detection active: DLP allow event where data class is regulated customer data and destination is an AI tool endpoint; single allow event at this classification routes immediately as High-severity (ATLAS TA0013 / AGH TTP)
- [ ] Unsanctioned browser extension installed detection active: extension-install event where extension ID not in SM-Endpoints browser-extension allowlist (EA TTP)
- [ ] SaaS-AI feature enabled tenant-wide without intake detection active: SaaS-admin audit event recording new AI feature enablement without matching SM-Endpoints intake approval (EA TTP)
- [ ] Mobile-app local-model integrity failure detection active: local-model integrity event where integrity check result = fail; any single failure routes to IM-Endpoints
- [ ] Edge-device tamper / attestation failure detection active: boot-attestation event with result fail, or physical-tamper event with tamper sensor triggered; routes immediately to IM-Endpoints for remote-disable evaluation
- [ ] Chatbot EU AI Act Art. 50 disclosure suppression detection active: customer-interaction event where disclosure-shown flag is false at session start for a scope where Art. 50 disclosure is required
- [ ] Chatbot abuse-pattern at scale detection active: abuse-detection events of type jailbreak-attempt or prompt-injection-attempt above threshold per session/time window (ATLAS TA0008 / AGH TTP)
- [ ] Cross-tenant data exposure via SaaS-AI feature detection active: DLP-decision event for SaaS-AI data flows where data scope includes a tenant or org-unit boundary not declared in the feature's SM-Endpoints intake record; routes as Critical (TM TTP)
- [ ] Monthly tuning review log with review dates and changes

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Total active detections in detection registry | ___ | ___ | ≤12 | ☐ | |
| Median detection-to-IM-Endpoints-ticket time for Critical-tier archetypes | ___h | ___h | ≤1h | ☐ | |
| % detections with FP rate tracked and last-tuned date ≤30 days | ___% | ___% | 100% | ☐ | |
| Monthly tuning reviews completed (last 12 months) | ___/12 | ___/12 | 12/12 | ☐ | |

**Metric Collection Guidance:**
- **Active detections**: Count entries in detection registry with status = active. Source: detection registry.
- **Detection-to-ticket time**: Measure from detection alert to IM-Endpoints ticket creation for Critical-tier archetype detections. Source: alert → ticket telemetry (P50).
- **FP rate tracked**: Count detections with FP rate populated and last-tuned date ≤30 days divided by total active detections. Source: detection tuning log.
- **Monthly reviews**: Count monthly tuning review sessions with documented output in the last 12 calendar months. Source: detection tuning log.

**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 active detection set)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 3: Deployer-Duty Evidence Trail

**Q1.3:** Has the evidence trail for EU AI Act Arts. 12 and 50, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Endpoints log store, including sector overlays where applicable, and has a quarterly deployer-duty drill confirmed evidence assembles within the ≤24-hour SLA?

**Evidence Required:**
- [ ] EU AI Act Art. 12 wiring: for every endpoint archetype assessed as Annex III high-risk or decision-affecting, interaction/output-filter/admin-audit events captured at required retention; deployer-duty evidence view produced per archetype
- [ ] EU AI Act Art. 50 wiring: for every customer-facing chatbot and multi-modal AI interface, the disclosure-shown flag and disclosure-template-version in the customer-interaction log constitute the Art. 50 audit trail; retention confirmed at required window; export path tested annually
- [ ] GDPR Art. 30 wiring: DLP-decision/session/admin-audit events with principal identity and data-class tag for each personal-data-processing endpoint archetype link to Art. 30 record; log-store retention linked per archetype
- [ ] ISO/IEC 42001 AIMS wiring: admin-audit events for AI-feature enablement changes, DLP-rule changes, rate-limit configuration changes, and integrity-check results identified as AIMS operational records; gaps on IM-Endpoints findings
- [ ] Sector overlay compliance: COPPA for children-facing endpoints (interaction logs do not contain PII for minors in clear-text; age-gate decision events); FERPA for educational endpoints; sector mobile-banking where applicable
- [ ] Quarterly deployer-duty drill records showing: archetype selected, drill start time, package assembly time, gaps found, disposition to IM-Endpoints

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Quarterly deployer-duty drills completed (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| Evidence assembly time in most recent drill | ___h | ___h | ≤24h | ☐ | |
| % customer-facing chatbot/multi-modal archetypes with Art. 50 audit trail documented | ___% | ___% | 100% | ☐ | |
| Sector overlay retention windows confirmed where applicable | ___ | ___ | all applicable confirmed | ☐ | |

**Metric Collection Guidance:**
- **Drill completion**: Count quarterly drill sessions in the last 4 quarters with documented output. Source: drill records.
- **Assembly time**: Record most recent drill's assembly time. Source: drill records.
- **Art. 50 audit trail**: Count customer-facing chatbot and multi-modal archetypes with disclosure-shown flag event schema instrumented and Art. 50 audit trail documented divided by total such archetypes. Source: evidence registry × SM-Endpoints inventory.
- **Sector overlay confirmation**: Verify retention configuration for each in-scope sector overlay (COPPA, FERPA, mobile-banking) against the applicable regulatory requirement. Source: retention policy audit.

**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 evidence trail wiring or drill program)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Maturity Level 2
**Objective:** Calibrate logging depth and detection set to the SM-Endpoints L2 risk-tier rubric; integrate with SIEM for cross-archetype correlation; and feed incident-driven and ST-Endpoints-driven detection updates into a continuous tuning loop.

---

### Question 4: Tier-Calibrated Logging Depth

**Q2.1:** Is tier-calibrated logging depth applied per the SM-Endpoints L2 tier-treatment matrix, Critical-tier archetypes retaining full interaction-event and DLP-decision log corpora at the longest regulatory window, Low-tier archetypes receiving baseline only, and is this calibration automatically updated when an archetype is re-tiered (Critical re-tier within 14 days)?

**Evidence Required:**
- [ ] Tier-treatment matrix applied: Critical = full interaction-event and DLP-decision log corpora (not hashes) at longest regulatory window + full admin-audit at maximum fidelity + all detections + anomaly detection baselines + log store partitioned; High = full interaction and DLP-decision events + standard admin-audit + core detections + anomaly baselines; Medium = interaction event hashes + standard admin-audit + shadow-AI emergence and baseline detections; Low = baseline schema only + shadow-AI emergence detection only
- [ ] Re-tier update process: Critical re-tier logging depth updated within 14 days; other tiers within 30 days; evidence of last re-tier event with update timestamp
- [ ] ML-Endpoints log store is primary source for PC-Endpoints compliance evidence bundles; ML-Endpoints logging-baseline validation element ≤30 days stale for Critical-tier archetypes

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier endpoint archetypes with full interaction-event and DLP-decision log corpora retained at longest regulatory window | ___% | ___% | 100% | ☐ | |
| % archetypes with logging depth matching current tier assignment | ___% | ___% | 100% | ☐ | |
| ML-Endpoints logging-baseline validation freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| Critical re-tier events with logging depth updated within 14 days (last 4 quarters) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Critical-tier full corpus**: Audit log-store retention for each Critical-tier endpoint archetype. Confirm full interaction-event and DLP-decision corpus at longest regulatory window. Source: log-store retention audit × SM-Endpoints inventory.
- **Tier-match coverage**: Compare current tier assignment to logging configuration per archetype. Source: SM-Endpoints inventory × logging configuration audit.
- **Validation freshness**: Check date of most recent ML-Endpoints logging-baseline validation in PC-Endpoints evidence bundle per Critical-tier archetype. Source: evidence registry.
- **Re-tier compliance**: For each Critical re-tier event in the last 4 quarters, measure days from re-tier decision to logging configuration update. Source: SM-Endpoints change log × logging audit trail.

**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 tier-calibrated logging depth)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 5: SIEM Integration and Cross-Archetype Correlation

**Q2.2:** Is the SIEM ingesting ML-Endpoints log feeds with ≥3 cross-archetype correlation rules active, covering multi-archetype data-exfiltration chain, browser-extension to SaaS-AI lateral move, and chatbot abuse escalation chain, and is a quarterly detection tuning cycle operating from IM-Endpoints post-incident and ST-Endpoints inputs including external advisory updates?

**Evidence Required:**
- [ ] SIEM ingesting all tier-appropriate ML-Endpoints log feeds; ingestion health monitored; no rule silent >90 days without investigation
- [ ] Multi-archetype data-exfiltration chain rule active: regulated-data DLP-allow event on AI assistant correlates to matching data-class access event on a SaaS-AI feature from the same principal in the same session window fires correlated exfiltration-chain detection
- [ ] Browser-extension to SaaS-AI lateral move rule active: unsanctioned-extension-install detection correlates to a SaaS-AI feature-enablement admin-audit event from the same principal within 24 hours
- [ ] Chatbot abuse escalation chain rule active: chatbot abuse-pattern detection correlates to an unusual SSO sign-in to the AI provider management console from the same principal's device in the same time window
- [ ] Quarterly detection review cycle records: IM-Endpoints post-incident input, ST-Endpoints finding input (disclosure-suppression tests, DLP bypass tests, chatbot abuse tests), external advisories (ATLAS endpoint techniques, OWASP MASVS, app-store flags, edge-device CVEs) reviewed quarterly; ≥1 net detection change per cycle
- [ ] Monthly anomaly-baseline refresh for Critical and High-tier endpoint archetypes documented

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-archetype SIEM correlation rules active and verified (last 90 days) | ___ | ___ | ≥3 active | ☐ | |
| Quarterly detection tuning cycles executed (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| % Critical/High-tier endpoint archetypes with anomaly-detection baselines established | ___% | ___% | ≥90% | ☐ | |
| Anomaly-detection FP rate for Critical-tier (trend direction) | ___ | ___ | trending down | ☐ | |

**Metric Collection Guidance:**
- **Correlation rules active**: Count SIEM rules with status = active; verify last-fired date ≤90 days or document no applicable events. Source: SIEM rule registry.
- **Tuning cycles**: Count quarterly cycles with documented IM-Endpoints and ST-Endpoints feedback integration and ≥1 net change. Source: detection change log.
- **Anomaly baselines**: Count Critical/High-tier endpoint archetypes with behavioral anomaly-detection baselines divided by total Critical/High-tier archetypes. Source: detection telemetry.
- **FP rate trend**: Compare anomaly FP rate current quarter vs. prior quarter for Critical-tier endpoint archetypes. Source: alert telemetry.

**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 SIEM integration or tuning loop)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 6: Anomaly Detection on Endpoint-AI Behavioral Patterns

**Q2.3:** Are ≥90% of Critical/High-tier endpoint archetypes running anomaly-detection baselines, with behavioral profiles refreshed monthly and FP rates tracked and trending down, and is the ML-Endpoints logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier archetypes in PC-Endpoints compliance evidence bundles?

**Evidence Required:**
- [ ] Behavioral baselines established for Critical and High-tier endpoint archetypes: DLP-decision volume, session patterns, extension-install rate, SaaS-AI feature usage patterns, mobile-app integrity check results, edge attestation cadence, specific to each archetype
- [ ] Monthly baseline refresh cadence honored; last-refresh date per archetype; seasonal usage patterns (holiday chatbot traffic, quarterly SaaS-AI feature rollout) accounted for in refresh cadence
- [ ] FP rate tracked per detection; detections exceeding 20% FP reviewed at quarterly cycle; detections not firing TP in 90 days reviewed for retirement
- [ ] PC-Endpoints compliance evidence bundle showing ML-Endpoints logging-baseline validation element ≤30 days for each Critical-tier archetype

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier endpoint archetypes with anomaly-detection behavioral baselines | ___% | ___% | ≥90% | ☐ | |
| % anomaly-detection baselines refreshed monthly, Critical-tier (last 3 months) | ___% | ___% | 100% | ☐ | |
| Compliance evidence bundle ML-Endpoints validation freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| Shadow-AI endpoint discoveries initiated by ML-Endpoints detections (trend toward zero undetected) | ___ | ___ | trending down | ☐ | |

**Metric Collection Guidance:**
- **Baseline establishment**: Count Critical/High-tier endpoint archetypes with documented behavioral baselines divided by total Critical/High-tier archetypes. Source: detection telemetry.
- **Refresh cadence**: For each Critical-tier archetype baseline, verify last-refresh date ≤30 days. Source: anomaly baseline refresh records.
- **Evidence bundle freshness**: Check ML-Endpoints logging-baseline validation date in PC-Endpoints evidence bundle per Critical-tier archetype. Source: evidence registry.
- **Shadow-AI discoveries**: Count unsanctioned browser extension or SaaS-AI shadow-enablement findings initiated by ML-Endpoints detections by quarter. Source: IM-Endpoints backlog.

**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 anomaly detection baselines)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Maturity Level 3
**Objective:** Express detections as code with automated deployment; apply anomaly detection on endpoint-AI behavioral patterns; contribute anonymized detection signatures and telemetry schemas to CSA Endpoint AI Safety Initiative, OWASP MASVS, and sector ISACs.

---

### Question 7: Detection-as-Code for Endpoints Domain

**Q3.1:** Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic endpoint-AI log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Endpoints inventory entries within 24 hours?

**Evidence Required:**
- [ ] Detection registry showing ≥90% of active detections with source-control reference (repo, path, version)
- [ ] Detection CI/CD pipeline: unit tests over synthetic endpoint-AI event log data including SaaS-AI admin-audit event formats, edge-device attestation events, mobile-AI integrity events, and browser extension install events; integration tests against log replay environment
- [ ] Synthetic test data reflects realistic field combinations present in real DLP-bypass patterns and SaaS-AI admin-audit events after provider updates, not generic log events
- [ ] Detection deployment via same change-management pipeline as AI/HAI endpoint configuration; no ad hoc SIEM console edits; detection changes reviewed before deployment
- [ ] Automation verifying detection coverage on SM-Endpoints inventory change events within 24 hours; gap findings opened in IM-Endpoints automatically

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % detections expressed as version-controlled, CI/CD-deployed code artifacts | ___% | ___% | ≥90% | ☐ | |
| Detection coverage auto-verified on SM-Endpoints inventory change within 24h | ___% | ___% | 100% | ☐ | |
| Detection CI/CD pipeline health, builds passing (last 90 days) | ___% | ___% | ≥95% | ☐ | |
| Detection deployment lead time (merge to production) | ___h | ___h | <24h | ☐ | |

**Metric Collection Guidance:**
- **Detection-as-code coverage**: Count detections with source-control reference divided by total active detections. Source: detection registry × source control.
- **Auto-verification**: For each SM-Endpoints inventory change event in the last quarter, verify automated gap check triggered within 24 hours. Source: automation telemetry.
- **Pipeline health**: Count CI/CD detection pipeline builds with result = success divided by total builds in last 90 days. Source: CI/CD telemetry.
- **Lead time**: Measure time from detection code merge approval to production deployment. Source: CI/CD deployment records.

**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** (Detections not in source control or CI/CD)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 8: Anomaly Detection on Endpoint-AI Behavioral Patterns at Scale

**Q3.2:** Are ≥90% of Critical/High-tier endpoint archetypes running anomaly detection on endpoint-AI behavioral patterns, with anomaly models retrained monthly on production log data, model versions tracked in the ML-Endpoints model registry, and anomaly alerts feeding the IM-Endpoints backlog through the same detection-to-ticket pipeline?

**Evidence Required:**
- [ ] DLP-decision sequence anomaly model active: sessions with DLP-decision sequence (block frequency, data-class distribution, AI tool context pattern) that is a statistical outlier from normal user sessions, attacker data-staging, pre-exfiltration paste patterns, policy-bypass probe sequences
- [ ] Extension-install behavior anomaly model active: install patterns (frequency, permission profile, install timing relative to DLP events) outside the baseline for the endpoint cohort, signals potential insider or compromised-account extension deployment
- [ ] SaaS-AI feature-usage anomaly model active: feature-usage events whose data-scope-access distribution shifts from baseline on a rolling window, potential cross-tenant access or unusual bulk-data access
- [ ] Edge-device attestation cadence anomaly model active: devices with attestation event cadence, PCR-value-change pattern, or uplink-volume distribution deviating from device cohort baseline, signals firmware tampering or replay-attack preparation
- [ ] Mobile-app integrity failure cluster model active: cluster of local-model integrity failures across a device cohort within a time window, signals coordinated model-swap attempt or compromised distribution channel
- [ ] Anomaly models retrained monthly; training data excludes attacker-session logs from past incidents; model versions tracked in ML-Endpoints model registry
- [ ] Anomaly model alerts route to IM-Endpoints through same detection-to-ticket pipeline as rule-based detections; severity tagged to archetype's tier

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier endpoint archetypes with anomaly detection active on endpoint-AI behavioral patterns | ___% | ___% | ≥90% | ☐ | |
| Anomaly model retraining cadence honored (last 6 months) | ___/6 | ___/6 | 6/6 monthly | ☐ | |
| % anomaly model alerts routed to IM-Endpoints within ≤1h of detection | ___% | ___% | ≥95% | ☐ | |
| True-positive incidents surfaced first by anomaly detection (vs. rule-based), trend | ___ | ___ | trending up | ☐ | |

**Metric Collection Guidance:**
- **Anomaly detection coverage**: Count Critical/High-tier endpoint archetypes with active anomaly models across the five behavioral dimensions divided by total Critical/High-tier archetypes. Source: anomaly model registry.
- **Retraining cadence**: Count months in the last 6 where a new anomaly model version was registered per archetype. Source: ML-Endpoints model registry.
- **Alert routing**: Count anomaly alerts reaching an IM-Endpoints ticket within 1 hour divided by total anomaly alerts. Source: alert → ticket telemetry.
- **TP trend**: Count incidents where first detection signal was an anomaly model alert by quarter. Source: incident retrospectives.

**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 ML-driven anomaly detection on endpoint-AI patterns)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 9: Industry Contribution, Endpoint Detection Signatures and Schemas

**Q3.3:** Has the program contributed ≥2 telemetry-standard artifacts per year to CSA Endpoint AI Safety Initiative or equivalent, and ≥12 anonymized detection signatures per year to sector ISACs, with OWASP MASVS contributions for mobile AI app integrity detection tracked and maintained?

**Evidence Required:**
- [ ] CSA Endpoint AI Safety Initiative contribution records: semantic event schemas for AI/HAI endpoint telemetry (DLP-decision events for AI prompt contexts, SaaS-AI admin-audit events, edge-device attestation events, mobile-AI integrity events); at least 2 schema contributions per year
- [ ] OWASP MASVS contribution records: detection-pattern examples and verification criteria for mobile AI app security (local-model integrity verification, on-device AI data-boundary detection, secure enclave usage for AI operations); at least 1 MASVS contribution per annual cycle; in-progress or published
- [ ] Sector ISAC submission records: anonymized endpoint-AI detection signatures (mobile-banking AI app integrity patterns for FS-ISAC, patient-facing chatbot abuse patterns for H-ISAC); legal-vet records per submission; at least one per month
- [ ] Contribution maintenance evidence: schema versioning showing contributions updated when internal practice changes; not point-in-time submissions
- [ ] Adoption tracking: records of external citations or integrations of contributed schemas; ISAC partners citing contributed signatures

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Telemetry-standard contributions per year (CSA Endpoint AI Safety Initiative or equivalent) | ___ | ___ | ≥2 | ☐ | |
| ISAC detection signatures contributed per year | ___ | ___ | ≥12 | ☐ | |
| OWASP MASVS contributions for mobile AI app integrity (in-progress or published) | ___ | ___ | ≥1 | ☐ | |
| Contributions with evidence of external adoption | ___ | ___ | ≥1 | ☐ | |

**Metric Collection Guidance:**
- **CSA contributions**: Count schema or semantic-convention contributions to CSA Endpoint AI Safety Initiative or equivalent in the last 12 months. Source: contribution log.
- **ISAC signatures**: Count anonymized endpoint-AI detection signatures submitted to sector ISACs in the last 12 months. Source: contribution log × ISAC submission receipts.
- **MASVS contributions**: Count OWASP MASVS contribution items with status in-progress or published. Source: OWASP MASVS contribution tracking.
- **External adoption**: Count external citations, integrations, or acknowledgments. Source: contribution tracking record.

**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 industry contributions)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Summary Scorecard

| Question | Level | Activity | Score (0.0 / 0.33 / 0.67 / 1.0) | Notes |
|----------|-------|----------|----------------------------------|-------|
| Q1: Per-Archetype Logging Baseline | L1 | A | | |
| Q2: High-Signal Detection Set | L1 | B | | |
| Q3: Deployer-Duty Evidence Trail | L1 | C | | |
| Q4: Tier-Calibrated Logging Depth | L2 | A | | |
| Q5: SIEM Integration and Cross-Archetype Correlation | L2 | B | | |
| Q6: Anomaly Detection on Endpoint-AI Behavioral Patterns | L2 | C | | |
| Q7: Detection-as-Code for Endpoints Domain | L3 | A | | |
| Q8: Anomaly Detection at Scale | L3 | B | | |
| Q9: Industry Contribution, Endpoints | L3 | C | | |

**L1 Score** (avg Q1–Q3): _____ / 1.0
**L2 Score** (avg Q4–Q6): _____ / 1.0
**L3 Score** (avg Q7–Q9): _____ / 1.0
**Overall ML-Endpoints Score** (L1×0.5 + L2×0.3 + L3×0.2): _____ / 1.0

**Assessor:** _________________________________
**Assessment Date:** _________________________________
**Next Review Date:** _________________________________

---

**Document Version:** HAIAMM v3.0, 2026-05-15, Verifhai
**Practice:** Monitoring & Logging (ML)
**Domain:** Endpoints
**Source of Truth:** `docs/practices/ML-Endpoints-OnePager.md`
**Compliance Map:** `docs/HAIAMM-v3.0-Framing.md` §10.2