> **v3.0 canonical:** This questionnaire is authored against the v3.0 source-of-truth one-pager [`../practices/ML-Data-OnePager.md`](../practices/ML-Data-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 deployer-duty logs · GDPR Art. 30 records of processing · GDPR Art. 15 DSAR export · ISO/IEC 42001 AIMS operational evidence.

---

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

**Practice:** Monitoring & Logging (ML)
**Domain:** Data
**Purpose:** Assess organizational maturity in establishing the per-archetype logging baseline for AI/HAI data assets, operating a high-signal detection set targeting TA-Data threats, and producing the evidence trail that satisfies EU AI Act Art. 12, GDPR Arts. 30 and 15, 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-Data 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-Data threats, and produce an on-demand evidence trail that satisfies EU AI Act Art. 12, 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 data archetype in the SM-Data inventory, and has compliance of each production data asset been measured against it within the last quarter?

**Evidence Required:**
- [ ] Published baseline specifying minimum events per archetype: training corpus (ingestion/poison-scan/training-job/eval-result-as-gate/model-promotion), inference input stream (PII-redaction-decision/classification-routing-decision/no-train-flag-check), retrieval store (retrieval/poisoning-detection/per-tenant-isolation-check/ingest), prompt/completion log corpus (log-write/retention-expiry/export), embedding store (access/inversion-defense-decision/per-tenant-partition-check), evaluation/test set (access/isolation-check), and admin-audit + identity events cross-archetype
- [ ] Retention window configured to meet or exceed the longest applicable regulation per §10.2 priority compliance map: EU AI Act Art. 12 high-risk logs ≥6 months; GDPR Art. 30 records-of-processing retention per data-class and purpose; HIPAA PHI ≥6 years where applicable; longest governs per asset
- [ ] Export path (JSON or CSV) tested at least annually per archetype; on-demand pull SLA ≤24 hours documented; DSAR-capable export SLA ≤72 hours tested at least semi-annually
- [ ] Log integrity: write-once or append-only storage for admin-audit and deployer-duty evidence tiers; cryptographic integrity verification for Critical-tier asset audit logs; access-control separation between data-engineering teams and log store administrators
- [ ] Compliance audit within the last quarter, each production data asset scored against its archetype baseline; gaps on IM-Data backlog with named owner
- [ ] PII scrubbing applied before logging where logging the raw field would create a regulated-data exposure

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % production AI/HAI data assets meeting per-archetype logging baseline | ___% | ___% | ≥90% | ☐ | |
| % production AI/HAI data assets with retention meeting longest applicable regulation | ___% | ___% | 100% | ☐ | |
| Evidence pull SLA, on-demand (quarterly drill) | ___h | ___h | ≤24h | ☐ | |
| DSAR-capable export SLA test result (semi-annual) | ___h | ___h | ≤72h | ☐ | |

**Metric Collection Guidance:**
- **Logging baseline compliance**: Cross-reference each production data asset in the SM-Data inventory against the published baseline checklist. Count assets meeting all required fields divided by total assets. Source: logging configuration audit.
- **Retention compliance**: Compare configured retention against the longest applicable regulation from §10.2 for each data asset. Source: retention policy audit × SM-Data inventory.
- **Evidence pull SLA**: Time the quarterly deployer-duty drill for each archetype. Measure request trigger to assembled package. Source: drill records.
- **DSAR SLA**: Time the semi-annual DSAR export path test for a named data subject record in a training corpus or prompt/completion log. Source: DSAR drill 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** (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-Data archetype threat, including classification-label drift, unclassified-data-flow, retrieval extraction attempt, embedding inversion attempt, training-data canary leakage, cross-border flow violation, retention-policy violation, no-train flag flip, and consent-withdrawal non-propagation, with false-positive rates tracked and monthly tuning reviews occurring?

**Evidence Required:**
- [ ] Detection registry: each entry includes owner, detection query, SLA, ATLAS-tactic or HAI-TTP tag, last-tuned date, and false-positive rate
- [ ] Classification-label drift detection active: ingestion or routing event with null, empty, or conflicting classification label vs. parent corpus fires detection (ATLAS TA0010 / EA TTP)
- [ ] Unclassified-data-flow detection active: storage access event where asset-id has no classification label on file in SM-Data inventory (ATLAS TA0010 / EA TTP)
- [ ] Retrieval extraction attempt detection active: single principal exceeds N retrieval queries (≥3 standard deviations above baseline) in rolling time window (ATLAS TA0013 / TM TTP)
- [ ] Embedding inversion attempt detection active: bulk-read or bulk-export on embedding store exceeding declared operational profile or from principal not in declared access list (ATLAS TA0013 / TM TTP)
- [ ] Training-data canary leakage detection active: canary string emitted verbatim in a model completion correlated to training-job event linking canary-containing dataset version (ATLAS TA0013 / TM TTP)
- [ ] Cross-border flow violation detection active: storage-replication event for residency-controlled asset without active transfer-mechanism record for destination region (ATLAS TA0013 / EA TTP)
- [ ] Retention-policy violation detection active: daily schedule comparing active asset records against retention-expiry dates in SM-Data inventory (ATLAS TA0014 / EA TTP)
- [ ] No-train flag flip detection active: flag changed from set to unset without IM-Data review approval event in the audit trail (ATLAS TA0008 / AGH TTP)
- [ ] Consent-withdrawal non-propagation detection active: weekly schedule comparing consent-withdrawal registry against active-dataset lineage registry; propagation SLA >30 days fires detection (ATLAS TA0014 / EA 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-Data-ticket time for Critical-tier data assets | ___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-Data ticket creation for Critical-tier data asset 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 Art. 12, GDPR Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Data log store, and has a quarterly deployer-duty drill confirmed the evidence package assembles within ≤24 hours, and a DSAR export path test confirmed the ≤72-hour DSAR SLA within the last 6 months?

**Evidence Required:**
- [ ] EU AI Act Art. 12 wiring: for every data asset associated with an Annex III high-risk AI system, ingestion/access/classification-routing/admin-audit events captured at ≥6-month retention; deployer-duty evidence view (log record + retention attestation + export test result) produced per asset
- [ ] GDPR Art. 30 wiring: access/PII-redaction-decision/consent-basis events for personal-data assets constitute records-of-processing entries; log-store retention linked to Art. 30 record per asset; DSAR-capable export path operational and tested
- [ ] ISO/IEC 42001 AIMS wiring: training-job/model-promotion/eval-result-as-gate/consent-basis-change/admin-audit events identified as AIMS operational records; gaps opened as IM-Data findings
- [ ] Quarterly deployer-duty drill records showing: asset selected, drill start time, package assembly time, gaps found, disposition to IM-Data
- [ ] DSAR export path test executed within last 6 months; record showing time-to-export for a named data subject in a training corpus or prompt/completion log
- [ ] §10.2 priority compliance map referenced in retention and exportability evidence requirements for each high-risk data asset

**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 | ☐ | |
| DSAR export path test, time to export for named data subject | ___h | ___h | ≤72h | ☐ | |
| % high-risk data assets with deployer-duty evidence view produced | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Drill completion**: Count quarterly drill sessions in the last 4 quarters with documented output. Source: drill records.
- **Assembly time**: Record the most recent drill's assembly time from request to assembled package. Source: drill records.
- **DSAR test**: Record time from DSAR drill trigger to exported package for a named data subject record. Source: DSAR drill records.
- **Evidence view coverage**: Count Annex III high-risk-associated data assets with a deployer-duty evidence view on file divided by total such assets. Source: evidence registry × SM-Data inventory.

**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-Data L2 risk-tier rubric; integrate with SIEM for cross-archetype correlation; and feed incident-driven and ST-Data-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-Data L2 tier-treatment matrix, Critical-tier data assets retaining full event corpora at the longest regulatory window, Low-tier assets receiving baseline only, and is this calibration automatically updated when a data asset is re-tiered, with Critical re-tier updates completing within 14 days?

**Evidence Required:**
- [ ] Tier-treatment matrix applied: Critical = full event logging at longest regulatory window + cryptographic audit-log integrity + per-asset log isolation with separate access-control boundary; High = full event logging at regulatory minimum; Medium = event hashes/summaries at regulatory minimum + standard admin-audit; Low = baseline schema only + classification-drift detection only
- [ ] Critical-tier data assets: audit-log cryptographic integrity verification active; per-asset log isolation enforced; all detections tuned to the asset
- [ ] Re-tier update process documented: Critical re-tier logging depth updated within 14 days; other tiers within 30 days; evidence of last re-tier event with update timestamp
- [ ] ML-Data log store is the primary source for PC-Data compliance evidence bundles; ML-Data logging-baseline validation element ≤30 days stale for Critical-tier assets

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier data assets with full event corpora retained at longest regulatory window | ___% | ___% | 100% | ☐ | |
| % data assets with logging depth matching current tier assignment | ___% | ___% | 100% | ☐ | |
| ML-Data 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 configuration for each Critical-tier data asset. Confirm full event logging at longest applicable regulatory window. Source: log-store retention audit × SM-Data inventory.
- **Tier-match coverage**: Compare current tier assignment to logging configuration for each asset. Source: SM-Data inventory × logging configuration audit.
- **Validation freshness**: Check date of most recent ML-Data logging-baseline validation in PC-Data compliance evidence bundle per Critical-tier asset. 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-Data 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-Data log feeds with ≥3 cross-archetype correlation rules active, covering retrieval-to-embedding exfiltration chain, training-data canary plus consent-withdrawal correlation, and cross-border flow plus classification escalation, and is a quarterly detection tuning cycle operating from IM-Data post-incident and ST-Data inputs including DPA enforcement advisory review?

**Evidence Required:**
- [ ] SIEM ingesting all tier-appropriate ML-Data log feeds; ingestion health monitored; no rule silent >90 days without investigation
- [ ] Retrieval-to-embedding exfiltration chain rule active: same principal issues anomalous retrieval queries on a retrieval store and bulk embedding export from the associated embedding store in the same session window fires unified high-severity detection
- [ ] Training-data canary plus consent-withdrawal correlation rule active: canary-leakage detection on a model completion correlates to a consent-withdrawal record for a subject in the affected training corpus version; escalates to Critical regardless of tier; triggers GDPR Art. 33 evaluation
- [ ] Cross-border flow plus classification-escalation rule active: cross-border flow violation on a regulated data asset correlates to a classification-label change on that asset within 24 hours; escalates to Critical
- [ ] Quarterly detection review cycle records: IM-Data post-incident input, ST-Data finding input, DPA enforcement advisory review included; ≥1 net detection change per cycle
- [ ] Monthly anomaly-baseline refresh for Critical and High-tier data assets documented; last-refresh date per asset

**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 with DPA advisory review (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| % Critical/High-tier data assets with anomaly-detection baselines established | ___% | ___% | ≥90% | ☐ | |
| Anomaly-detection FP rate for Critical-tier data assets (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 in window. Source: SIEM rule registry.
- **Tuning cycles with DPA review**: Count quarterly cycles where meeting record references DPA enforcement advisory review with ≥1 net change. Source: detection change log.
- **Anomaly baselines**: Count Critical/High-tier data assets with behavioral anomaly-detection baseline divided by total Critical/High-tier assets. Source: detection telemetry.
- **FP rate trend**: Compare anomaly-detection FP rate current quarter vs. prior quarter for Critical-tier data assets. 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 AI/HAI Data Corpora

**Q2.3:** Are ≥90% of Critical/High-tier data assets running anomaly-detection baselines across retrieval query, embedding access, and training-pipeline event dimensions, with behavioral profiles refreshed monthly and FP rates tracked and trending down, and is the ML-Data logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier assets in PC-Data compliance evidence bundles?

**Evidence Required:**
- [ ] Anomaly detection active for Critical and High-tier data assets across three dimensions: retrieval query pattern (bulk/probe/multi-session extraction patterns), embedding access corpus (bulk export preparation sequences and unusual partition access), training-pipeline event stream (dataset composition or consent-basis anomalies vs. prior approved runs)
- [ ] Consent-withdrawal propagation latency anomaly model active: outlier propagation delays trigger early warning before the rule-based retention-violation detection fires
- [ ] Monthly baseline refresh cadence honored; last-refresh date per asset in the anomaly detection system
- [ ] FP rate tracked per detection; detections exceeding 20% FP reviewed at quarterly cycle; detections not firing a TP in 90 days reviewed for retirement
- [ ] PC-Data compliance evidence bundle showing ML-Data logging-baseline validation element ≤30 days for each Critical-tier asset

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier data assets with anomaly detection active (retrieval, embedding, training-pipeline) | ___% | ___% | ≥90% | ☐ | |
| % anomaly-detection baselines refreshed monthly, Critical-tier (last 3 months) | ___% | ___% | 100% | ☐ | |
| Compliance evidence bundle ML-Data validation freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| DSAR fulfillment inside ≤72h SLA, no manual log reconstruction (last 4 quarters) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Anomaly detection coverage**: Count Critical/High-tier data assets with active anomaly models across all three dimensions divided by total Critical/High-tier assets. Source: anomaly model registry.
- **Refresh cadence**: For each Critical-tier asset baseline, verify last-refresh date ≤30 days. Source: anomaly baseline refresh records.
- **Evidence bundle freshness**: Check ML-Data logging-baseline validation date in PC-Data compliance evidence bundle per Critical-tier asset. Source: evidence registry.
- **DSAR fulfillment**: Count DSARs fulfilled within ≤72h without manual log reconstruction divided by total DSARs touching AI/HAI data assets. Source: DSAR fulfillment 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 anomaly detection baselines)

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

---

## Maturity Level 3
**Objective:** Express detections as code with automated deployment; apply anomaly detection to retrieval, inference, and training event corpora; and contribute anonymized detection signatures and telemetry schemas to OWASP LLM data-detection patterns, sector ISACs, and DAMA.

---

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

**Q3.1:** Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic data-asset event patterns, and is detection coverage auto-verified for 100% of new or re-tiered SM-Data 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 data-asset event patterns (realistic retrieval extraction events, embedding access bulk-export sequences, consent-withdrawal propagation events), integration tests against log replay environment populated with anonymized historical events
- [ ] Synthetic test data reflects realistic field combinations present in real retrieval extraction attempts (document IDs, tenant-id, principal, volume), not generic HTTP events
- [ ] Detection deployment via same change-management pipeline as data-pipeline code; no ad hoc SIEM console edits; detection changes reviewed before deployment
- [ ] Automation verifying detection coverage on SM-Data inventory change events within 24 hours; gap findings opened in IM-Data 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-Data 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-Data inventory change event in the last quarter, verify automated gap check triggered and completed 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 AI/HAI Data Corpora at Scale

**Q3.2:** Are ≥90% of Critical/High-tier data assets running anomaly detection on retrieval query, embedding access, and training-pipeline event corpora, with anomaly models retrained monthly on production event data, model versions tracked in the model registry with SLSA-style provenance, and anomaly alerts feeding the IM-Data incident backlog through the same pipeline as rule-based detections?

**Evidence Required:**
- [ ] Retrieval query pattern anomaly model active: multi-session extraction patterns that individually fall below the rule-based threshold but collectively exceed baseline surface as anomalies
- [ ] Embedding access corpus anomaly model active: bulk export preparation sequences and novel argument patterns in embedding API calls detected
- [ ] Training-pipeline event stream anomaly model active: dataset composition, consent-basis distribution, or provenance lineage that differs statistically from prior approved training runs
- [ ] Consent-withdrawal propagation latency anomaly model active: outlier propagation delays trigger early warning before retention-violation rule fires
- [ ] Model registry entries with SLSA-style provenance for each anomaly model version: retraining date, training data window, data exclusion evidence (no attacker-session logs included in training data to prevent poisoned baseline)
- [ ] Monthly retraining cadence honored; anomaly model alerts route to IM-Data through same detection-to-ticket pipeline as rule-based detections

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier data assets with anomaly detection active across all corpus dimensions | ___% | ___% | ≥90% | ☐ | |
| Anomaly model retraining cadence honored (last 6 months) | ___/6 | ___/6 | 6/6 monthly | ☐ | |
| % anomaly model alerts routed to IM-Data 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 data assets with active anomaly models across all four corpus dimensions divided by total Critical/High-tier assets. Source: anomaly model registry.
- **Retraining cadence**: Count months in the last 6 where a new anomaly model version was registered per asset. Source: model registry.
- **Alert routing**: Count anomaly alerts reaching an IM-Data 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 data corpora)

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

---

### Question 9: Industry Contribution, Data-Domain Detection Signatures and Schemas

**Q3.3:** Has the program contributed ≥2 telemetry-standard artifacts per year to OWASP LLM data-detection patterns, DAMA, or equivalent, and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked?

**Evidence Required:**
- [ ] OWASP LLM / Agentic Top 10 data-detection pattern contributions: retrieval extraction, embedding inversion, training-data canary leakage, consent-withdrawal non-propagation detection patterns; at least one per release cycle
- [ ] DAMA DMBOK AI data governance contribution records: event schema definitions for training-corpus ingestion events, retrieval-store access events, embedding-store access events, and consent-propagation events
- [ ] MITRE ATLAS AML.M00xx mitigation entries proposed or validated: priority, TA0013 Exfiltration (retrieval extraction, embedding inversion, canary leakage), TA0014 Impact (consent-withdrawal, retention violation, no-train-flag bypass)
- [ ] Sector ISAC submission records (FS-ISAC, H-ISAC, IT-ISAC): anonymized, generalized data-domain detection signatures; legal-vet records per submission; signatures implementable by partner organizations without significant reconstruction
- [ ] Contribution maintenance evidence: schema versioning showing contributions updated when internal practice evolves; not point-in-time submissions

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Telemetry-standard contributions per year (OWASP LLM data patterns, DAMA, or equivalent) | ___ | ___ | ≥2 | ☐ | |
| ISAC detection signatures contributed per year | ___ | ___ | ≥12 | ☐ | |
| ATLAS AML.M00xx detection-mitigation entries proposed or validated | ___ | ___ | ≥2 | ☐ | |
| Contributions with evidence of external adoption (citations, integrations, acknowledgments) | ___ | ___ | ≥1 | ☐ | |

**Metric Collection Guidance:**
- **Telemetry contributions**: Count schema or detection-pattern contributions to OWASP LLM data patterns, DAMA, or equivalent in the last 12 months. Source: contribution log.
- **ISAC signatures**: Count anonymized data-domain signatures submitted to sector ISACs in the last 12 months. Source: contribution log × ISAC submission receipts.
- **ATLAS entries**: Count AML.M00xx entries with the organization as proposer or validator. Source: ATLAS contribution log.
- **External adoption**: Count external citations, integrations, or acknowledgments of contributed artifacts. 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 Data Corpora | L2 | C | | |
| Q7: Detection-as-Code for Data Domain | L3 | A | | |
| Q8: Anomaly Detection on AI/HAI Data Corpora at Scale | L3 | B | | |
| Q9: Industry Contribution, Data-Domain | 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-Data 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:** Data
**Source of Truth:** `docs/practices/ML-Data-OnePager.md`
**Compliance Map:** `docs/HAIAMM-v3.0-Framing.md` §10.2