> **v3.0 questionnaire.** Source of truth: [`../practices/EH-Endpoints-OnePager.md`](../practices/EH-Endpoints-OnePager.md). Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md) §8.

---

# Environment Hardening (EH) - Endpoints Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Environment Hardening (EH)
**Domain:** Endpoints
**Purpose:** Assess organizational maturity in hardening the identity, endpoint-runtime, data-flow, mobile/edge integrity, and customer-facing envelopes for all seven AI/HAI endpoint archetypes

---

## 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

Each question is scored on a 4-tier scale:

| 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 control |

**Level Score** = Average of question scores within the level
**Overall Score** = Weighted average across levels (L1: 50%, L2: 30%, L3: 20%)

---

## Maturity Level 1

**Objective:** Harden the five envelope dimensions for all seven AI/HAI endpoint archetypes so each endpoint type operates under a baseline that prevents the most dangerous data-egress, identity, and integrity failures.

---

### Question 1: Identity Envelope and Endpoint-Runtime Hardening

**Q1.1:** Are SSO + MFA enforced on all AI consoles accessed from managed endpoints with personal-account prohibition via conditional-access rule, is an MDM-enforced AI-tool allowlist active on ≥95% of managed endpoints, and are DLP rules tuned for AI-specific exfiltration patterns (regulated-PII paste into LLM prompts, bulk customer-data export via assistant, source-code paste outside approved coding assistant) deployed and active?

**Evidence Required:**
- [ ] IdP conditional-access policy records: SSO + MFA enforced on AI provider management consoles (OpenAI, Anthropic, Gemini, Copilot, SaaS-AI admin) and internal AI assistant admin consoles; local-account access disabled for org-domain identities
- [ ] Personal-account prohibition configuration: browser policy and DLP rule preventing employees from authenticating to consumer AI services with personal accounts while org data is present in the browsing context
- [ ] Managed-endpoint requirement for Critical-tier AI assistant and copilot use: conditional-access policy requires MDM-enrolled, MDM-compliant device posture before granting access to Critical-tier AI surfaces
- [ ] MDM platform (Intune, Jamf, VMware Workspace ONE, or equivalent) AI-tool allowlist policy configuration, permits only approved AI tools; blocks unsanctioned AI application installation or execution; allowlist governed by SM-Endpoints intake
- [ ] DLP rule configuration covering AI-specific exfiltration patterns: regulated-PII paste into LLM prompt fields, bulk customer-data export via AI assistant, source-code paste outside approved coding assistant (file-type and content heuristics), bulk personal-data queries via AI assistant
- [ ] EDR (CrowdStrike, SentinelOne, Microsoft Defender) process-behavior signatures for AI-data-exfiltration: LLM client process connecting to unapproved AI provider endpoints, bulk file upload to AI API endpoint, browser-extension accessing sensitive local files and initiating AI provider API calls

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI endpoint archetypes in the SM-Endpoints inventory with a named baseline hardening status | ___% | ___% | 100% | ☐ | |
| % managed endpoints with MDM-enforced AI-tool allowlist active | ___% | ___% | ≥95% | ☐ | |
| DLP rules tuned for AI-specific exfiltration patterns deployed and active on managed endpoints | 0 / set | target set | target set defined + deployed | ☐ | |
| Regulated-data-to-unapproved-AI incidents (documented blocks where regulated PII was prevented from reaching unapproved AI surface) | ___ | ___ | tracked; trending down | ☐ | |

**Metric Collection Guidance:**
- **Archetype hardening status coverage**: Audit SM-Endpoints inventory records; count archetypes with named baseline hardening status across all five envelope dimensions. Source: SM-Endpoints inventory audit
- **MDM allowlist coverage**: Query MDM compliance dashboard for managed endpoints with AI-tool allowlist policy applied. Source: MDM compliance dashboard
- **DLP rule deployment**: Confirm AI-specific exfiltration rules are active in DLP management console; verify rules target LLM prompt-paste, bulk export, and source-code-paste scenarios. Source: DLP management console
- **Regulated-data block events**: Count DLP block events where regulated PII was prevented from reaching an unapproved AI surface per quarter. Source: DLP/egress 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 identity envelope or endpoint-runtime hardening)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 2: Data-Flow Envelope and Vendor No-Train Flag Verification

**Q2.1:** Is a classification-aware egress policy active, preventing regulated data from flowing to no-train-unverified AI surfaces, with vendor no-train flag confirmation documented at intake for all sanctioned AI endpoint tools and annual recurrent verification scheduled, and are SaaS-admin AI-feature enablement gates enforced?

**Evidence Required:**
- [ ] Classification-aware egress DLP policy: regulated data (PII, PHI, PCI card numbers, classified source code) cannot flow to a no-train-unverified AI surface; DLP policy enforces boundary by data class
- [ ] Vendor no-train flag verification records at intake via IR-Endpoints review for every sanctioned AI endpoint tool, contractual and technical no-train commitment confirmed; compensating DLP rule applied where technical verification is not possible
- [ ] Annual recurrent verification schedule for vendor no-train status, tools approaching annual review date flagged 30 days in advance; re-verification documented in SM-Endpoints inventory record
- [ ] Per-archetype data-class boundary declarations in SM-Endpoints inventory, maximum classification of data each of the seven archetypes may process; DLP policy enforces boundary; violations route to IM-Endpoints
- [ ] SaaS-admin AI-feature governance: no AI feature (Notion AI, Slack AI, Zoom AI Companion, M365 Copilot, Salesforce Einstein, or equivalent) enabled tenant-wide without SM-Endpoints intake approval; shadow-AI features (active without approval) routed to IM-Endpoints within 5 business days
- [ ] Browser extension allowlist management: managed-browser policy restricts AI browser extensions to approved list; quarterly review with SM-Endpoints working group

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % sanctioned AI endpoint tools with vendor no-train flag confirmed at intake | ___% | ___% | 100% | ☐ | |
| Annual recurrent no-train verification schedule in place for all sanctioned tools | ___% | ___% | 100% | ☐ | |
| Shadow-AI-in-SaaS findings discovered and blocked within 5 business days | ___% | ___% | 100% within SLA | ☐ | |
| Data-class boundary violations (regulated data routed to unauthorized AI surface) per quarter | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **No-train confirmation coverage**: Audit SM-Endpoints inventory records for each sanctioned AI tool; count those with vendor no-train confirmation documented. Source: SM-Endpoints inventory × IR review records
- **Annual re-verification schedule**: Review re-verification calendar; count tools with a scheduled annual review. Source: SM-Endpoints inventory × IR calendar
- **Shadow-AI-in-SaaS resolution SLA**: Count shadow-AI SaaS features discovered and blocked within 5 business days / total discovered. Source: SaaS admin audit × IM-Endpoints backlog
- **Data-class boundary violations**: Count DLP events where regulated data was routed to an unauthorized AI surface per quarter. Source: DLP alert telemetry × IM-Endpoints 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 classification-aware egress or vendor no-train verification)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 3: Mobile/Edge Integrity and Customer-Facing Envelope Hardening

**Q3.1:** Do 100% of mobile AI apps ship with a signed app and signed local model verified at launch, managed edge AI devices ship with signed firmware and boot-time integrity attestation, and do 100% of customer-facing chatbots display a compliant EU AI Act Art. 50 disclosure with escalation-to-human routing operational?

**Evidence Required:**
- [ ] Mobile AI app code-signing records: enterprise or approved-public-store distribution path; local on-device model cryptographic signature verified at app launch; unsigned models rejected
- [ ] Edge AI device signed firmware configuration: firmware signing certificate managed in secrets vault; unsigned firmware rejected at secure boot; boot-time integrity attestation active
- [ ] On-device model integrity attestation: at each boot or model-load event, device verifies model against reference hash in SM-Endpoints inventory; integrity failure reported to MDM and ML-Endpoints
- [ ] Secure enclave usage for mobile AI apps processing regulated data (iOS Secure Enclave, Android StrongBox) for key storage and sensitive operations
- [ ] Physical-tamper detection for edge AI devices in physically accessible environments (TPM attestation, sealed PCR values, or vendor-equivalent); tamper events trigger IM-Endpoints alert and MDM quarantine
- [ ] Centrally managed EU AI Act Art. 50 disclosure template library covering customer-facing archetypes; disclosure rendered before or at session start; verified by ST-Endpoints automated test in the test battery; escalation-to-human routing tested and logged

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % mobile AI apps with signed app + signed local model verified at launch | ___% | ___% | 100% | ☐ | |
| % managed edge AI devices with signed firmware and boot-time integrity attestation active | ___% | ___% | 100% | ☐ | |
| % customer-facing chatbots / conversational UIs displaying compliant EU AI Act Art. 50 disclosure before or at session start (confirmed by ST-Endpoints test) | ___% | ___% | 100% | ☐ | |
| Shadow-AI-in-SaaS findings trending down as SaaS-admin governance matures | ___ | ___ | trending down | ☐ | |

**Metric Collection Guidance:**
- **Mobile app signing coverage**: Query MDM telemetry for managed mobile AI apps; count those with code-signing verification and local-model integrity check at launch. Source: MDM telemetry × app signing records
- **Edge device firmware attestation coverage**: Query edge device management console for devices with signed firmware and boot-time attestation active. Source: MDM / edge device management console
- **Art. 50 disclosure coverage**: Review ST-Endpoints test battery results for customer-facing chatbots; count those passing the disclosure-present test. Source: ST-Endpoints test results
- **Shadow-AI-in-SaaS trend**: Count shadow-AI SaaS features discovered per quarter before vs. after SaaS-admin governance activation. Source: SaaS admin audit × IM-Endpoints 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 mobile/edge integrity controls or Art. 50 disclosure)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 2

**Objective:** Calibrate hardening depth per SM-Endpoints L2 risk tier; apply dedicated rate-limiting for Critical customer-facing endpoints; enforce managed-endpoint requirement at the identity layer for Critical AI assistant use; and apply HSM-backed attestation for Critical edge devices.

---

### Question 4: Critical Customer-Facing Endpoint Hardening and Managed-Endpoint Enforcement

**Q2.1:** Are 100% of Critical-tier AI assistant endpoints with managed-endpoint requirement enforced at the identity-layer conditional-access policy (not only MDM policy), and are 100% of Critical-tier customer-facing AI endpoints operating under dedicated (non-shared) rate-limit and abuse-detection profiles reviewed quarterly?

**Evidence Required:**
- [ ] IdP conditional-access policy (Azure AD Conditional Access, Okta Device Trust, Google BeyondCorp, or equivalent) enforcing MDM-enrolled, MDM-compliant device posture for Critical-tier AI assistant and copilot endpoints, identity-layer enforcement, not only MDM policy
- [ ] Evidence that gaps between the MDM policy and identity-layer enforcement have been identified and closed (unmanaged-device sessions cannot reach Critical-tier AI surfaces regardless of MDM policy state)
- [ ] Dedicated rate-limit configuration for each Critical-tier customer-facing chatbot and conversational UI: per-session message rate, per-user daily token budget, per-IP connection rate, per-tenant-segment cumulative volume, not shared with non-Critical tiers
- [ ] Dedicated abuse-detection configuration for each Critical-tier customer-facing endpoint: jailbreak-attempt detection, prompt-injection-pattern matching, volume-anomaly detection, detection alerts route to ML-Endpoints within 1 minute
- [ ] Quarterly rate-limit threshold review records, thresholds adjusted against actual traffic baselines before abuse patterns can destabilize the endpoint
- [ ] False-positive threshold review for abuse-detection rules, monthly review cadence for Critical-tier customer-facing endpoints

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier AI assistant endpoints with managed-endpoint requirement enforced at the identity (conditional-access) layer | ___% | ___% | 100% | ☐ | |
| % Critical-tier customer-facing AI endpoints with dedicated (non-shared) rate-limit and abuse-detection profile | ___% | ___% | 100% | ☐ | |
| Quarterly rate-limit threshold review completed against traffic baseline | ___/year | ___/year | 4/year | ☐ | |
| Unmanaged-device sessions reaching Critical-tier AI surfaces (target zero) | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **Identity-layer managed-endpoint coverage**: Audit IdP conditional-access policies for Critical-tier AI assistant endpoints; verify device-posture requirement is enforced at the IdP layer. Source: IdP conditional-access policy audit × SM inventory
- **Dedicated rate-limit coverage**: Audit rate-limit configuration registry for Critical-tier customer-facing endpoints; verify dedicated (not shared) profiles. Source: rate-limit configuration registry × SM inventory
- **Rate-limit review cadence**: Count quarterly rate-limit reviews completed against traffic baseline per year. Source: governance review records
- **Unmanaged-device session count**: Count IdP sign-in events from non-compliant/non-enrolled devices reaching Critical-tier AI surfaces. Source: IdP sign-in logs × conditional-access policy

**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 identity-layer enforcement or dedicated rate-limit for Critical-tier)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 5: HSM-Backed Attestation for Critical Edge Devices and SaaS-Admin IaC

**Q2.2:** Do 100% of Critical-tier edge AI devices use HSM-backed attestation with physical-tamper detection, attestation failures routing to IM-Endpoints within 5 minutes, and is SaaS-admin AI-feature configuration expressed as IaC for Critical and High-tier SaaS-AI with daily drift detection active?

**Evidence Required:**
- [ ] HSM-backed attestation configuration for Critical-tier edge AI devices: TPM 2.0 backed by HSM or vendor-equivalent secure element; attestation keys generated and stored in HSM, non-exportable; remote attestation service verifies sealed PCR values at each boot
- [ ] Attestation failure alert routing: failures route to IM-Endpoints within 5 minutes; device remote-disable confirmed within 4 hours of unresolved failure
- [ ] Physical-tamper detection with HSM seal for Critical-tier edge devices: any physical access to device internals triggers HSM-detected tamper event; tamper event routes to IM-Endpoints and initiates remote-disable if device is network-accessible
- [ ] SaaS-admin AI-feature configuration expressed as IaC (SaaS admin API scripts, Terraform SaaS provider modules, or equivalent) stored in version-controlled configuration management for Critical and High-tier SaaS-AI
- [ ] Daily drift detection between declared IaC configuration and live SaaS admin console state, deviations routed to IM-Endpoints; new AI-feature enablement via pull-request workflow, not ad hoc admin console change
- [ ] Tier-treatment matrix published and enforced at provisioning for all five envelope dimensions per SM-Endpoints L2 tier

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier edge AI devices with HSM-backed attestation and physical-tamper detection | ___% | ___% | 100% | ☐ | |
| Critical-tier edge device attestation failures routing to IM-Endpoints within 5 minutes | ___% | ___% | 100% | ☐ | |
| SaaS-admin AI-feature configuration expressed as IaC with daily drift detection active (Critical + High-tier SaaS-AI) | ___% | ___% | target set complete for Critical + High-tier | ☐ | |
| False-positive rate on AI-specific DLP signals for Critical-tier endpoints (trend) | ___% | ___% | actively tuned; trending down | ☐ | |

**Metric Collection Guidance:**
- **HSM-backed attestation coverage**: Audit device attestation telemetry for Critical-tier edge AI devices; verify HSM-backed attestation (not software-only TPM) and tamper detection active. Source: device attestation telemetry
- **Attestation failure routing SLA**: Count Critical-tier edge device attestation failures with IM-Endpoints alert within 5 minutes / total failures. Source: attestation telemetry × IM-Endpoints log
- **SaaS-admin IaC coverage**: Audit IaC registry for SaaS-admin AI-feature configuration entries for Critical + High-tier SaaS-AI; verify daily drift detection active. Source: IaC registry × SaaS admin audit
- **DLP false-positive rate trend**: Count DLP alerts tagged as false-positive per month for Critical-tier endpoint patterns; compute rate and track trend. Source: DLP alerting 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 HSM-backed attestation or SaaS-admin IaC)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 6: Tier-Hardening Matrix Enforcement and EU AI Act Art. 50 Compliance at Scale

**Q2.3:** Is the tier-hardening matrix published and enforced at provisioning for all five envelope dimensions, with EU AI Act Art. 50 disclosure tested per release as a deployment blocker for Critical-tier customer-facing endpoints, and are tier-hardening gaps tracked as open IM-Endpoints findings with tier-appropriate SLAs?

**Evidence Required:**
- [ ] Published tier-treatment matrix document covering managed-endpoint requirement, AI-tool allowlist depth, DLP depth, rate-limit/abuse-detection tier, Art. 50 disclosure test cadence, mobile app integrity, edge device attestation, and SaaS-admin AI governance depth per tier (Critical/High/Medium/Low)
- [ ] Provisioning-gate configuration enforcing tier controls at archetype registration, not post-hoc; tier-change triggers hardening-profile upgrade
- [ ] EU AI Act Art. 50 disclosure test configuration as a deployment blocker for Critical-tier customer-facing endpoints: disclosure absence or template mismatch fails the deployment gate; tested per release
- [ ] SM-Endpoints inventory records showing hardening status per tier for each archetype; gaps between required and actual controls tracked as open IM-Endpoints findings with tier-appropriate SLA
- [ ] Content inspection DLP configuration for Critical-tier AI assistant endpoints: DLP inspects AI prompt fields for regulated-data classes; block on confirmed regulated data
- [ ] Mobile app integrity verified at each launch for Critical-tier mobile AI apps: MDM reports integrity failure within 1 hour of detection

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Tier-hardening matrix enforced at provisioning and on tier-change (not only initial provisioning) | ☐ yes / ☐ no |, | yes | ☐ | |
| EU AI Act Art. 50 disclosure test configured as deployment blocker for Critical-tier customer-facing endpoints | ___% | ___% | 100% of Critical-tier customer-facing endpoints | ☐ | |
| % SM-Endpoints inventory records with hardening status per tier populated | ___% | ___% | 100% | ☐ | |
| Tier-hardening gaps tracked as open IM-Endpoints findings with tier-appropriate SLA | ___% | ___% | 100% of gaps tracked | ☐ | |

**Metric Collection Guidance:**
- **Tier-change enforcement**: Verify provisioning pipeline watches for tier-change events in SM-Endpoints and re-applies hardening profile. Source: provisioning pipeline configuration
- **Art. 50 disclosure deployment blocker**: Review CI/CD pipeline configuration for Critical-tier customer-facing endpoints; confirm disclosure test is a blocking gate. Source: CI/CD pipeline configuration
- **Inventory hardening status**: Review SM-Endpoints inventory records; count archetypes with hardening-status field populated per tier. Source: SM-Endpoints inventory
- **Gap tracking coverage**: Count tier-hardening gaps opened as IM-Endpoints findings / total gaps identified. 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 tier-hardening matrix enforcement or Art. 50 compliance gate)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Maturity Level 3

**Objective:** Express all EH-Endpoints controls as MDM/browser-policy/SaaS-admin IaC modules; implement adaptive tightening driven by ML-Endpoints detections and IM-Endpoints incidents; and contribute AI/HAI endpoint hardening baselines to CSA, OWASP MASVS, and sector ISACs.

---

### Question 7: Hardening-as-Code, IaC Modules for All EH-Endpoints Controls

**Q3.1:** Are all EH-Endpoints controls expressed as version-controlled IaC modules, identity, endpoint-runtime, data-flow, mobile/edge integrity, and customer-facing envelopes, with drift detection running daily and ≥70% of low-risk drift auto-remediated?

**Evidence Required:**
- [ ] Identity envelope IaC module: IdP conditional-access policy module (managed-endpoint device-posture requirement, MFA enforcement, personal-account prohibition rule, AI-console session scope); parameterized by archetype and tier; applied via IdP configuration API
- [ ] Endpoint-runtime IaC module: MDM configuration profile module (AI-tool allowlist policy, app blocking, browser extension allowlist, screen-capture policy for AI sessions); DLP rule configuration module (AI-specific rule sets, content-inspection for Critical-tier); browser policy templates (Chrome Enterprise / Edge Enterprise)
- [ ] Data-flow IaC module: DLP egress-rule configuration for per-archetype data-class boundaries; vendor no-train flag verification schedule and alert rule; classification-aware routing policy
- [ ] Mobile/edge integrity IaC module: mobile app signing policy, local-model hash registry and launch-time attestation rule, edge device attestation policy (HSM configuration, sealed PCR value registry, tamper-alert routing); deployable via MDM API and edge device management console API
- [ ] Customer-facing IaC module: rate-limit configuration (per-archetype, per-tier, parameterized threshold table), abuse-detection rule module (jailbreak and prompt-injection pattern library, volume-anomaly threshold), Art. 50 disclosure template registry (version-controlled, Legal-reviewed, per-archetype), brand-safety filter configuration
- [ ] Drift-detection pipeline running daily; low-risk drift auto-remediated; high-risk drift (MFA disabled on AI console, rate-limit removed from Critical-tier chatbot, edge attestation policy deleted) triggers human-review alert within 2 business days + IM-Endpoints finding

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % EH-Endpoints controls expressed as IaC (version-controlled, authoritative deployed source, not stubs) | ___% | ___% | ≥90% | ☐ | |
| IaC drift auto-remediation rate for low-risk findings | ___% | ___% | ≥70% | ☐ | |
| High-risk drift findings human-reviewed within 2 business days | ___% | ___% | 100% | ☐ | |
| New AI/HAI endpoint archetypes auto-provisioned with tier-appropriate hardening within 24h of SM-Endpoints registration | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **IaC coverage**: Count EH-Endpoints controls with authoritative IaC (deployed state = IaC spec, not stub) / total EH-Endpoints controls. Source: IaC registry
- **Auto-remediation rate**: Count low-risk drift findings auto-remediated / total low-risk drift findings per quarter. Source: remediation telemetry
- **High-risk drift review SLA**: Count high-risk findings with human review within 2 business days / total high-risk findings. Source: policy change log × IM-Endpoints backlog
- **Auto-provisioning SLA**: Compare SM-Endpoints registration timestamps against IaC provisioning completion within 24h. Source: inventory × IaC provisioning 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 IaC for EH-Endpoints controls)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 8: Adaptive Policy Tightening from ML-Endpoints and IM-Endpoints Signals

**Q3.2:** Is an adaptive-policy pipeline operational, with ML-Endpoints detections (regulated-data paste volume spikes, chatbot abuse patterns, SaaS-AI shadow-enablement, edge-device integrity failures) and IM-Endpoints incident patterns generating human-approved tightening proposals traceable to source signals?

**Evidence Required:**
- [ ] Adaptive-tightening pipeline wiring ML-Endpoints signals: regulated-data paste-attempt volume spike → DLP rule sensitivity increase proposal; chatbot abuse-pattern detection (jailbreak at scale) → rate-limit tightening + prompt-injection corpus update; SaaS-AI feature silently enabled → SaaS-admin IaC rollback + intake-amnesty trigger; edge-device integrity failure rate above threshold → attestation policy tightening; mobile-app local-model integrity failure cluster → model signing re-pin + MDM force-update trigger
- [ ] Adaptive-tightening pipeline wiring IM-Endpoints post-incident review records: hardening gap → hardening-baseline update proposal; DLP bypass → DLP rule tuning proposal with IM incident reference
- [ ] Human-approval gate for all proposals (security platform engineer approval before deploy)
- [ ] Machine-readable change log records with source signal (ML-Endpoints detection trend ID or IM-Endpoints incident ID), approval record, downstream notification timestamp
- [ ] Feedback loop to TA-Endpoints threat library and SR-Endpoints requirements pack for changes reflecting new endpoint threat patterns
- [ ] Signal feed freshness monitoring, ML-Endpoints and IM-Endpoints feeds checked weekly; stale feeds (>7 days without processed event) flagged

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Adaptive-policy changes per quarter traceable to ML-Endpoints or IM-Endpoints source signal | 0 | ___ | tracked; growing | ☐ | |
| % adaptive-policy proposals human-approved before deploy | ___% | ___% | 100% | ☐ | |
| Downstream endpoint and product teams notified within 24h of tightening change | ___% | ___% | 100% | ☐ | |
| Stale signal feeds (>7 days without processed ML-Endpoints or IM-Endpoints event) | ___ | ___ | 0 stale feeds | ☐ | |

**Metric Collection Guidance:**
- **Traceable changes**: Count policy changes in change log with valid source signal reference per quarter. Source: policy change log
- **Human-approval rate**: Count proposals deployed with approval record / total proposals deployed. Source: policy change log
- **Notification SLA**: Count tightening changes with downstream team notification within 24h / total. Source: notification log
- **Signal feed freshness**: Check last-processed timestamp for each ML-Endpoints and IM-Endpoints feed. Source: pipeline monitoring

**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 adaptive-policy pipeline for EH-Endpoints)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

### Question 9: Industry AI/HAI Endpoint Hardening Baseline Contributions

**Q3.3:** Does the program contribute ≥2 AI/HAI endpoint hardening baselines per year to industry bodies, CSA AI Safety Initiative, OWASP MASVS, or sector ISACs, with documented adoption and baselines maintained current with internal practice?

**Evidence Required:**
- [ ] Contribution records showing ≥2 substantive submissions per year to CSA AI Safety Initiative, OWASP MASVS (Mobile Application Security Verification Standard), or sector ISACs (FS-ISAC, H-ISAC, IT-ISAC AI working groups), e.g., AI endpoint allowlist governance, DLP AI-specific pattern library, SaaS-AI governance baseline, mobile AI app signing and local-model integrity attestation controls, edge AI device hardening patterns
- [ ] Evidence of adoption or citation of contributed baselines by the recipient body (CSA publication, OWASP MASVS PR, ISAC advisory)
- [ ] Maintenance records confirming contributions are updated when internal practice advances (new archetype, new DLP pattern for multi-modal inputs), not published once and left to diverge
- [ ] Auto-provisioning trigger configuration: SM-Endpoints registration event fires IaC provisioning workflow within 24 hours; tier-change event triggers hardening-profile upgrade using current tier
- [ ] Incident rate comparison on IaC-encoded endpoint deployments vs. hand-configured deployments over rolling 12 months, IaC lower
- [ ] Quarterly adaptive-policy change log traceable to ML-Endpoints detections and IM-Endpoints incident patterns

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry AI/HAI endpoint hardening baseline contributions per year | 0 | ___ | ≥2 | ☐ | |
| New AI/HAI endpoint archetypes auto-provisioned with tier-appropriate hardening within 24h of SM-Endpoints registration | ___% | ___% | 100% | ☐ | |
| Contributed baselines maintained current with internal practice (not published once and diverged) | ☐ yes / ☐ no |, | yes | ☐ | |
| Incident rate on IaC-encoded endpoint deployments vs. hand-configured (rolling 12-month) | IaC: ___ / hand: ___ |, | IaC lower | ☐ | |

**Metric Collection Guidance:**
- **Contribution count**: Count published contributions with named recipient body and contribution artifact per calendar year. Source: contribution log
- **Auto-provisioning SLA**: Compare SM-Endpoints registration timestamps against IaC provisioning completion within 24h. Source: inventory × IaC provisioning telemetry
- **Maintenance alignment**: Review most recent version of each contributed baseline; confirm it reflects current internal practice (check for new archetypes or DLP patterns added internally but not yet in the published version). Source: contribution log × practice review
- **Incident rate comparison**: Count IM-Endpoints incidents per archetype unit for IaC-encoded vs. hand-configured deployments over rolling 12 months. Source: IM-Endpoints incident log × deployment configuration 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 industry contributions or auto-provisioning)

**Evidence Location:** _______________
**Validation Date:** _______________
**Notes:** _______________

---

## Summary Scorecard

| Level | Question | Score (0.0 / 0.33 / 0.67 / 1.0) |
|-------|----------|----------------------------------|
| L1 | Q1: Identity Envelope and Endpoint-Runtime Hardening | ___ |
| L1 | Q2: Data-Flow Envelope and Vendor No-Train Verification | ___ |
| L1 | Q3: Mobile/Edge Integrity and Customer-Facing Envelope | ___ |
| L2 | Q4: Critical Customer-Facing Endpoint Hardening and Managed-Endpoint Enforcement | ___ |
| L2 | Q5: HSM-Backed Attestation for Critical Edge Devices and SaaS-Admin IaC | ___ |
| L2 | Q6: Tier-Hardening Matrix Enforcement and Art. 50 Compliance Gate | ___ |
| L3 | Q7: Hardening-as-Code IaC Modules | ___ |
| L3 | Q8: Adaptive Policy Tightening | ___ |
| L3 | Q9: Industry Endpoint Hardening Baseline Contributions | ___ |

**L1 Score** (avg Q1–Q3): ___
**L2 Score** (avg Q4–Q6): ___
**L3 Score** (avg Q7–Q9): ___
**Overall Score** (L1×0.5 + L2×0.3 + L3×0.2): ___

---

**Document Version:** HAIAMM v3.0
**Practice:** Environment Hardening (EH)
**Domain:** Endpoints
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai