Environment Hardening (EH) - Endpoints Assessment

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

v3.0 questionnaire. Source of truth: ../practices/EH-Endpoints-OnePager.md. Canonical subject and through-lines: ../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

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

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

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

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

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

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

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

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

Instructions:

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

↓ Download as Markdown