Security Requirements (SR) - Endpoints Assessment

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

v3.0 framing: The canonical source-of-truth for Security Requirements (SR) in the Endpoints domain is ../practices/SR-Endpoints-OnePager.md. Outcome metrics in this questionnaire are reproduced verbatim from that one-pager. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Security Requirements (SR) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Security Requirements (SR) Domain: Endpoints Purpose: Assess organizational maturity in authoring and maintaining the AI/HAI Endpoints Requirements Pack, a base set plus per-archetype deltas, and producing a Requirements-Evidence Map (REM) for every endpoint AI deployment approved for the managed estate. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

Instructions

Answer each question honestly based on current, implemented practices (not plans or aspirations)
Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked)
Scoring uses 4 tiers: Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
Answer progressively, Complete all Level 1 questions before Level 2
Level progression, Achieve ALL questions at 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 AND ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete AND 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete AND <2 metrics meet targets
0.0	Not Implemented	No evidence present

Maturity Level 1

Objective: Publish the AI/HAI Endpoints Requirements Pack (base plus per-archetype deltas), wire it into the SM intake gate, and produce a Requirements-Evidence Map for every endpoint AI deployment.

Question 1: Author the base AI/HAI Endpoints Requirements Pack

Q1.1: Does a published, versioned AI/HAI Endpoints Requirements Pack exist containing a base set (target ≤20 requirements) covering identity/DLP/extension allowlist/per-archetype data-class boundaries/no-train probing/endpoint logging/Art. 50/permission minimization/local-model integrity/edge integrity, with every requirement tagged to at least one TA-Endpoints archetype threat and one PC-Endpoints priority-compliance item?

Evidence Required: - [ ] Base requirements pack document published in the requirements registry with a version number and a named owner - [ ] Pack covers minimum base categories: identity and auth (SSO + MFA on AI consoles, managed-endpoint requirement for Critical-tier, personal-account prohibition, service-principal model), DLP at endpoint (DLP controls for regulated-data paste, AI-specific patterns, outbound egress monitoring to AI provider domains), browser extension allowlist and per-extension scope review (host permissions, page-content-read, DOM-write), per-archetype data-class boundaries (documented declaration of which data classes may flow to each endpoint AI archetype), vendor no-train assertion verified at admin-console level, endpoint logging (AI-tool use events, DLP alerts, extension installs logged and forwarded to SIEM), customer-facing AI disclosure (Art. 50, persistent and non-suppressible), mobile permission scope minimization, local-model integrity verification (signed artifacts verified at load time), edge device integrity (signed firmware and model artifacts, attestation at boot), kill-switch/disable path (≤4 hours to disable, tested annually), and affected-persons rights surface (Art. 22) - [ ] Each requirement row carries: ID, statement, rationale (threat tag + compliance tag), evidence source, test method, and acceptance criterion - [ ] REM (Requirements-Evidence Map) template exists and is linked from the SM intake checklist; template includes Met / Met-with-compensating-control / Gap-accepted / Not-applicable columns with evidence citation, gap owner, gap expiry, and compensating-control description - [ ] Accepted-gaps register exists with named owner and expiry date per row - [ ] Pack-version control record shows version, change date, and change summary for each revision - [ ] Cross-Vendors-domain REM linkage documented: for endpoint AI sourced from a vendor, the Endpoints REM cross-references the Vendors-domain REM for that vendor; vendor-level controls live in the Vendors REM; endpoint-local controls live in the Endpoints REM

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Base + archetype requirements packs published | 0 / 8 documents | /8 | 8 / 8 (base + 7 archetype deltas) | ☐ | Requirements registry | | % new endpoint AI approvals with a completed REM | measure | % | 100% | ☐ | SM intake ticket + REM artifact | | % active endpoint AI deployments in inventory with a current-year REM | measure | % | ≥90% | ☐ | Inventory × REM artifacts | | % of pack requirements tagged to a TA-Endpoints archetype threat and a PC-Endpoints priority-compliance item | measure | % | 100% | ☐ | Pack metadata | | Accepted-gap aging (median age of open accepted-gap rows) | measure | ___ days | ≤90 days | ☐ | REM backlog | | % of Critical-tier endpoint AI deployments with cross-Vendors-domain REM cross-reference on file | measure | ___% | 100% | ☐ | Cross-domain traceability log |

Metric Collection Guidance: - Packs published: Count published documents in the requirements registry: 1 base + 7 archetype deltas (AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity (SaaS-AI), mobile AI app, edge AI device). Source: requirements registry index. - % new endpoint AI approvals with REM: Query SM intake tickets closed in the last 90 days; count those with a linked REM artifact. Formula: REMs on file / total new endpoint AI approvals × 100. - % active deployments with current-year REM: Cross-reference SM inventory against REM artifact store; flag deployments with no REM dated in the current calendar year. Formula: deployments with current-year REM / total active deployments × 100. - % requirements tagged: Count requirements with both a TA threat tag and a PC compliance tag. Formula: tagged requirements / total requirements × 100. - % Critical-tier with cross-Vendors REM cross-reference: Count Critical-tier endpoint AI deployments sourced from external vendors; confirm each has a Vendors-domain REM cross-reference in the Endpoints REM. Formula: Critical-tier deployments with Vendors REM cross-reference / total Critical-tier vendor-sourced deployments × 100. - Accepted-gap aging: Compute median calendar days from gap-open date to today for all currently open rows.

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 of a published endpoints requirements pack)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Author per-archetype requirement deltas

Q2.1: Have per-archetype requirement deltas been authored and published for all seven endpoint AI archetypes (AI assistant/copilot on managed endpoint, browser-based AI tool, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity, mobile AI app, edge AI device), and are the correct deltas automatically applied at intake?

Evidence Required: - [ ] Seven archetype-delta documents (or pack sections) published with version numbers and tagged to TA-Endpoints archetype threats - [ ] Each delta includes minimum-viable scope items specific to its archetype (e.g., tool allowlist for AI assistant/copilot; per-extension scope review for browser-based tools; prompt-injection defense and Art. 50 disclosure testing for chatbots; signed app and on-device model signing for mobile AI apps; signed firmware + signed model and device attestation at boot for edge AI devices) - [ ] Intake process routes each endpoint AI deployment to base pack + applicable archetype delta(s); routing logic is documented and tested with at least one intake example per archetype - [ ] REM template enforces that archetype-specific delta rows are present and populated for the declared archetype - [ ] Pack-version control record reflects delta amendments and cross-references the TA-Endpoints archetype threat that drove each change - [ ] Traceability matrix links delta requirements back to TA-Endpoints archetype threat models and PC-Endpoints priority compliance map (EU AI Act Arts. 26, 50; GDPR Arts. 6, 9, 22; OWASP MASVS for mobile archetypes) - [ ] Compensating-controls list documents approved compensating controls for common gap patterns per archetype

Metric Collection Guidance: - Packs published: Verify all seven archetype-delta documents are present in the registry with current version numbers. - % new approvals with REM: Verify REM rows for the deployment's archetype delta are populated, not only base pack rows. - % active deployments with current-year REM: Confirm archetype delta rows are present in each REM. - % requirements tagged: Confirm all delta requirements carry both a TA threat tag and a PC compliance tag. - % Critical-tier with cross-Vendors REM cross-reference: Same as Q1. - Accepted-gap aging: Include archetype-delta gap rows in the aging calculation.

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Wire the pack into the SM intake gate and establish cross-Vendors-domain REM linkage

Q3.1: Is the requirements pack wired into the SM intake gate so that every endpoint AI deployment carries a completed REM, with Met rows citing specific evidence (MDM policy screenshot, admin-console state, extension scope review, DLP rule configuration, kill-switch test result, Art. 50 UX screenshot, model-signing verification log, or attestation record), and is cross-Vendors-domain REM linkage operational for Critical-tier vendor-sourced deployments?

Evidence Required: - [ ] SM intake checklist includes a gate step requiring a completed REM before Sanctioned status is issued for the endpoint AI deployment - [ ] At least three production endpoint AI REMs on file from the last 90 days, each showing Met / Gap-accepted / Not-applicable rows with specific evidence citations - [ ] Each Met row in the sample REMs cites a specific artifact (MDM policy screenshot, admin-console state, extension scope review artifact, DLP rule configuration, kill-switch test result, Art. 50 UX screenshot, model-signing verification log, or attestation record), not a narrative assertion - [ ] Each Gap-accepted row carries: compensating control, named owner, re-review date (≤90 days from open date at L1), and residual-risk rationale - [ ] Cross-Vendors-domain REM linkage is operational: Critical-tier endpoint AI deployments sourced from external vendors have a Vendors-domain REM cross-reference on file in their Endpoints REM; a change in the Vendors REM triggers a flag on the corresponding Endpoints REM - [ ] Material-change trigger list is documented (new tool access granted, permission scope expanded, model swap, new user population, new data class accessible) and included in the intake checklist - [ ] Pack-version control confirms quarterly refresh cadence with at least one refresh on record

Metric Collection Guidance: - Packs published: Confirm 8/8 documents in the registry with current version numbers. - % new approvals with REM: Pull SM intake ticket list for last 90 days; confirm each Sanctioned status was preceded by a linked REM artifact. - % active deployments with current-year REM: Run inventory × REM cross-reference; compute completion ratio. - % Critical-tier with cross-Vendors REM cross-reference: Query the Endpoints REM store for Critical-tier vendor-sourced deployments; confirm each has a Vendors-domain REM cross-reference field populated. - Accepted-gap aging: Confirm median open-gap age is within ≤90 days; flag any gap without a named owner or expiry.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Replace qualitative requirements with quantitative, SLA-bound, and binary-evidence conditions; calibrate the requirements pack per risk tier; and validate REM evidence continuously for Critical and High-tier deployments.

Question 4: Quantitative and binary requirement pack

Q4.1: Do 100% of pack requirements carry a quantitative or binary evidence condition, with every SLA (kill-switch test age, no-train re-verification cadence, DLP coverage percentage, attestation failure alert time) and binary state (SSO + MFA confirmed, Art. 50 disclosure red-team tested, extension scope review complete, model signing verified) specified, and has all qualitative "appropriate" and "reasonable" language been removed?

Evidence Required: - [ ] Requirements pack shows no qualitative language in any requirement statement; all language is measurable or binary - [ ] Kill-switch test requirement is binary: emergency-halt mechanism exists, tested quarterly, can disable the endpoint AI within 4 hours of decision; last test date and result on file; zero missed quarterly tests in the last 12 months - [ ] Vendor no-train assertion requirement is binary: vendor admin-console setting confirmed OFF + screenshot on file; re-verification completed quarterly; last re-verification result on file; zero findings of setting enabled in the last 12 months - [ ] Art. 50 disclosure (chatbot) requirement is binary: disclosure UX component present and persistent on every customer session start; verified in last ST-Endpoints test run with date; disclosure text meets Art. 50 specificity requirement; disclosure cannot be suppressed by system prompt (verified via red-team probe with date) - [ ] Extension scope review requirement is binary: each allowlisted AI extension has a completed scope review on file confirming host permissions justified; no extension with <all_urls> permission active on managed endpoints without a named compensating control and expiry date - [ ] DLP coverage for AI egress requirement specifies SLA: DLP rules covering ≥90% of known regulated-data formats; last DLP coverage review date; zero undetected regulated-data egress incidents to AI provider domains in the last 90 days (confirmed by IR review) - [ ] Mobile model integrity attestation requirement is binary: on-device model signing verified at load time; attestation log confirms zero unsigned-model loads in the last 90 days; failed attestation alert routed within 5 minutes of event - [ ] REM template updated to reflect quantitative conditions; each row's evidence field maps to the specific SLA or binary predicate - [ ] Pack-version control log shows the quantitative update was a tracked amendment with a version bump

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % requirements with quantitative or binary evidence condition | measure | % | 100% | ☐ | Requirements pack | | % Critical-tier REMs re-validated against observed reality in last 90 days | measure | % | ≥95% | ☐ | REM validation log | | Accepted-gap aging, median age of Critical-tier open gaps | measure | ___ days | ≤60 days | ☐ | Gap register | | % Critical-tier deployments with EU AI Act Art. 26 full deployer-duty checklist evidence in the REM | measure | % | 100% | ☐ | Compliance view | | % tier-appropriate pack overlay applied (Critical full depth, Low base only) | measure | % | 100% | ☐ | SM intake × REM artifact | | Pack update SLA from IR/IM finding to pack amendment assessment | measure | ___ days | ≤14 days | ☐ | IR/IM → pack telemetry |

Metric Collection Guidance: - % requirements quantitative/binary: Count requirements with a measurable SLA or explicit binary predicate vs. total requirements. Source: requirements pack document. - % Critical-tier REMs re-validated: Count Critical-tier endpoint AI REMs with a re-validation run (not self-attestation alone) in the last 90 days. Formula: re-validated Critical-tier deployment REMs / total Critical-tier deployments × 100. - Accepted-gap aging (Critical): Filter gap register to Critical-tier deployment rows; compute median calendar days open. - % Critical-tier with Art. 26 checklist: Count Critical-tier deployment REMs containing the EU AI Act Art. 26 full deployer-duty checklist appendix with verifiable evidence. - % tier-appropriate overlay applied: Sample 10 intake tickets across tiers; verify Critical-tier received full depth (Art. 50 red-team probe, executive sign-off) and Low-tier received base pack only. - Pack update SLA: Count IM-Endpoints incidents in the last 90 days that touched a pack requirement; confirm the percentage where a pack update assessment was completed within 14 days. Formula: incidents with assessment within 14 days / total incidents touching pack requirements × 100.

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Per-tier requirement depth

Q5.1: Has a per-tier pack overlay been published and enforced at SM intake, with Critical-tier deployments requiring full pack depth, executive sign-off, Art. 50 red-team probe, full Art. 26 checklist, a 60-day accepted-gap SLA, and cross-Vendors-domain REM cross-reference, and Low-tier deployments receiving base pack only?

Evidence Required: - [ ] Per-tier pack overlay document published showing Critical / High / Medium / Low tier treatment matrices - [ ] Critical-tier overlay includes: full base pack + all applicable archetype deltas; executive sign-off required; full REM required (no rows left blank); accepted-gap aging SLA of 60 days maximum before mandatory escalation to the program sponsor; EU AI Act Art. 26 full deployer-duty checklist as a discrete REM appendix; Art. 50 disclosure testing required (red-team probe confirming disclosure cannot be suppressed, not just a UX screenshot); quarterly re-validation of all Critical-tier REM evidence; cross-Vendors-domain REM cross-reference required - [ ] SM intake routing logic enforces tier-appropriate depth; intake ticket records tier assignment and pack overlay version applied - [ ] Accepted-gaps register is tiered: Critical-tier gaps are flagged before the 60-day escalation threshold, with pre-deadline notification to the named owner - [ ] REM auto-revalidation is wired to MDM telemetry, SaaS-admin audit logs, and DLP signals for Critical and High tiers - [ ] Pack updates from IR and IM findings are operationalized: every IM-Endpoints incident touching a pack requirement triggers a REM row re-validation for the affected deployment and a pack update assessment within 14 days - [ ] Pack-version control shows the per-tier overlay was versioned and announced to the reviewer community

Metric Collection Guidance: - % requirements quantitative/binary: Confirm no regressions from Q4 after the tier overlay was applied. - % Critical-tier REMs re-validated: Verify the re-validation cadence is operating using observable-reality checks (MDM telemetry, SaaS-admin audit log, DLP signals, vendor admin-console API, attestation service logs). - Accepted-gap aging (Critical): Confirm no Critical-tier deployment gap has exceeded 60 days without a documented escalation record naming the program sponsor. - % Critical-tier with Art. 26 checklist: Verify the Art. 26 appendix contains verifiable evidence (not vendor assertion alone) in every Critical-tier deployment REM. - Art. 50 red-team probe: Confirm the probe was completed (not only a UX screenshot) for all Critical-tier chatbot/conversational UI deployments.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: REM auto-revalidation wired to MDM, SaaS-admin, DLP, and attestation telemetry

Q6.1: Are Critical-tier endpoint AI REMs re-validated against observed reality at least quarterly and High-tier at least semi-annually, with validation wired to MDM/UEM telemetry, SaaS-admin audit logs, DLP signals, vendor admin-console API, and model-integrity attestation service, and pack updates from IR/IM findings completed within defined SLAs?

Evidence Required: - [ ] REM validation log exists and shows at least one completed validation run for every Critical-tier endpoint AI deployment in the last 90 days, using observable telemetry (not only self-report) - [ ] Validation is wired to: MDM/UEM telemetry (extension allowlist compliance confirmed; unauthorized app install alerts cross-checked against REM); SaaS-admin audit logs (AI feature enablement events confirmed against REM); DLP signals (regulated-data egress alerts to AI provider domains cross-checked); vendor admin-console API (no-train setting re-confirmed via API query, not only screenshot); model integrity attestation log (mobile and edge device attestation results pulled from the attestation service; zero unsigned-model loads confirmed) - [ ] Validation deltas are routed to IM-Endpoints as findings with severity tags and remediation SLAs matching the deployment's tier - [ ] Accepted-gaps register shows no Critical-tier deployment gap past 60 days without a documented escalation record naming the program sponsor - [ ] Every IM-Endpoints incident touching a pack requirement has triggered a REM row re-validation for the affected deployment and a pack update assessment within 14 days; IR findings that surface a missing requirement category triggered a pack amendment sprint within 30 days - [ ] REM-population status per deployment reflects the last validation date and outcome for each Critical/High-tier deployment - [ ] Pack-version control records any requirement amendments triggered by validation findings or IR/IM feedback

Metric Collection Guidance: - % Critical-tier REMs re-validated: Pull REM validation log; count Critical-tier deployments with a validation run recorded in the last 90 days using observable telemetry (not self-report). Formula: validated Critical-tier deployments / total Critical-tier deployments × 100. - Accepted-gap aging (Critical): Confirm the 60-day SLA is enforced; spot-check any gap older than 60 days for an escalation record; zero exceptions without documented escalation. - Telemetry wiring: Confirm the REM validation log shows results from MDM, SaaS-admin, DLP, vendor API, and attestation service for at least one Critical-tier deployment in the last 90 days. - Pack update SLA: Confirm IM-Endpoints incidents touching pack requirements have pack update assessment records within 14 days. - Art. 26 checklist: Confirm the checklist evidence is current and not a legacy document predating the current deployment configuration.

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 telemetry-wired REM validation or IR/IM feedback loop in place)

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Express the AI/HAI Endpoints Requirements Pack as a machine-readable artifact, automate REM-evidence validation from MDM/UEM and SaaS-admin signals, and contribute to industry-standard AI endpoint security requirements bodies.

Question 7: Machine-readable pack and endpoint-attestation at deploy

Q7.1: Is the AI/HAI Endpoints Requirements Pack expressed in a machine-readable schema (JSON or YAML), and do Critical-tier endpoint AI deployments fail the MDM policy gate or SaaS-admin gate when a REM requirement check fails?

Evidence Required: - [ ] Machine-readable requirements pack published (JSON or YAML schema); each requirement has: ID, machine-readable evidence type (MDM-policy-check / admin-console-API / attestation-log-query / DLP-telemetry / manual-attestation), acceptance predicate, and tier applicability field - [ ] Deployment or configuration gate for Critical-tier endpoint AI includes automated REM checks: SSO + MFA confirmed via IdP API; extension allowlist compliance confirmed via MDM policy; no-train setting confirmed via vendor admin-console API; DLP rules active and current; kill-switch mechanism confirmed tested within defined age; model-signing attestation confirmed for mobile and edge deployments - [ ] Failed REM check blocks the deployment for Critical-tier; evidence of at least one blocked deployment or a test of the block is on file - [ ] Passed REM checks write a signed attestation to the REM record; attestation log is queryable - [ ] REM-population status per deployment is updated automatically from endpoint-attestation results for automated evidence types - [ ] Pack published under a permissive license with external adoption tracking (forks, citations, downloads logged) - [ ] Pack-version control aligns the public version with the internal version; no version lag exceeding one quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier REM requirements with automated endpoint-attestation at deploy time | measure | % | ≥80% | ☐ | Attestation log | | % REM evidence rows auto-validated (vs. manual-only) | measure | % | ≥70% | ☐ | Validation telemetry | | Deployment gates triggered by failed Critical-tier REM check | measure | ___ | tracked; zero silent failures | ☐ | MDM / SaaS-admin telemetry | | Pack adoption (forks, citations, downloads of published artifact) | 0 | ___ | tracked, trending up | ☐ | External telemetry | | Industry-standard contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log |

Metric Collection Guidance: - % Critical-tier requirements with endpoint-attestation: Count Critical-tier REM requirement rows with an automated deployment check vs. total Critical-tier requirement rows. Formula: automated Critical-tier rows / total Critical-tier rows × 100. - % REM rows auto-validated: Count all endpoint AI REM rows where the last validation was performed by an automated check vs. total rows. Formula: auto-validated rows / total rows × 100. - Deployment gates triggered: Count blocked deployments in the last 90 days where the block was triggered by a failed Critical-tier REM check; confirm zero silent failures (deployments proceeding with a failing REM check). - Pack adoption: Query external telemetry for the published pack artifact; confirm an upward trend over a 3-month window. - Industry-standard contributions: Count substantive contributions to CSA endpoint AI / OWASP MASVS / NIST AI RMF Playbook / ISO AI security standards successor work in the last 12 months.

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 machine-readable pack or endpoint-attestation gate)

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Automated REM-evidence validation from runtime signals

Q8.1: Are ≥70% of endpoint AI REM evidence rows auto-validated via MDM/UEM, SaaS-admin, DLP telemetry, and attestation service ingestion, with automation error-rate monitored and human review reserved for Art. 50 UX review, Art. 22 affected-persons-rights surface documentation, novel clauses, and accepted-gap escalations?

Evidence Required: - [ ] REM validation pipeline is subscribed to MDM/UEM telemetry (extension allowlist violations, unauthorized app installs, policy-compliance state), SaaS-admin audit logs (AI feature enablement events, admin-console state changes), DLP signals (regulated-data egress alerts to AI provider domains), and attestation service logs (mobile and edge device model-integrity and firmware-integrity attestation results) - [ ] IM-Endpoints incident records feed the REM validation pipeline: post-incident reviews touching a pack requirement auto-flag relevant REM rows for re-validation - [ ] SM inventory change events (tier upgrade) auto-trigger a full REM re-validation run under the new tier's requirements depth - [ ] Automation error-rate (false-positive and false-negative gate failures) is monitored; a defined threshold triggers human review of the affected check - [ ] Human review queue is bounded: Art. 50 UX reviews, Art. 22 affected-persons-rights surface documentation, novel clauses, and accepted-gap escalations are the only items requiring manual handling - [ ] REM-population status per deployment reflects auto-validated rows separately from manual-attestation rows; staleness of each auto-validated row is tracked - [ ] Pack-version control records amendments triggered by automation findings

Metric Collection Guidance: - % auto-validated rows: Pull validation telemetry; count rows with an auto-validation result in the last 90 days vs. total active endpoint AI REM rows. Confirm the 70% target is met across Critical and High-tier deployments. - Automation error-rate: Query the pipeline's false-positive and false-negative logs; threshold for human review should be documented and applied consistently. - Human review queue: Confirm the queue contains only Art. 50 UX reviews, Art. 22 affected-persons-rights surface documentation, novel clauses, and accepted-gap escalations; no standard evidence type should be pending manual review beyond the defined SLA. - Endpoint-attestation gate: Confirm the gate from Q7 is still enforcing; zero silent failures. - Post-deploy drift: Confirm the attestation service is checking current state (not a historical snapshot); an extension gaining new permissions via an update would be detected.

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 automated REM-evidence validation from runtime signals)

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Standards contribution

Q9.1: Has the program contributed at least two substantive artifacts per year to recognized standards bodies, with contributions publicly documented and traceable to adoption in CSA endpoint AI, OWASP MASVS AI extensions, NIST AI RMF Playbook, or ISO/IEC 27090 successor guidance?

Evidence Required: - [ ] Contribution log lists at least 2 substantive contributions in the last 12 months with: body name (CSA, OWASP, NIST, ISO), contribution type, submission date, and external reference link - [ ] Contributions are legally vetted (internal legal review record on file) and anonymized or attributed per the org's disclosure policy - [ ] At least one contribution is a machine-readable artifact (endpoint AI requirement schema, REM schema for endpoint AI, OWASP MASVS AI extension requirement clauses, or equivalent) - [ ] External adoption is tracked: at least one contribution has a confirmed path to adoption (working group vote, draft inclusion, or citation in a published standard or guidance document) - [ ] Pack + REM schema published under a permissive license with version aligned to the internal version; no version lag exceeding one quarter - [ ] CSA endpoint AI security working group and/or OWASP MASVS AI working group engagement is documented with meeting participation or contribution submission records - [ ] Contribution pipeline has ≥2 contributions in-flight at any given time

Metric Collection Guidance: - Industry-standard contributions: Count contributions in the last 12 months in the contribution log; confirm each has a body name, submission date, and external reference link. Minimum 2 to meet target. - Pack adoption: Confirm external telemetry shows an upward trend in forks, citations, or downloads. - Contribution pipeline health: Confirm ≥2 contributions are actively in-flight (submitted or under working-group review), not only completed. - Version alignment: Check that the public pack version tag matches the current internal version tag. - L3 automation goals: Confirm the endpoint-attestation and auto-validation goals from Q7 and Q8 remain met.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Question	Activity	Score
Q1	L1-A: Base endpoints requirements pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q2	L1-B: Per-archetype deltas	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q3	L1-C: SM intake gate + REM per deployment + cross-Vendors linkage	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q4	L2-A: Quantitative and binary pack	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q5	L2-B: Per-tier requirement depth	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q6	L2-C: REM auto-revalidation wired to MDM/DLP/attestation telemetry	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q7	L3-A: Machine-readable pack + endpoint-attestation at deploy	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q8	L3-B: Automated REM-evidence from runtime signals	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Q9	L3-C: Standards contribution	☐ 1.0 / ☐ 0.67 / ☐ 0.33 / ☐ 0.0
Total		___ / 9.0

Achieved Maturity Level: ☐ Not Started / ☐ Level 1 / ☐ Level 2 / ☐ Level 3

Document Version: HAIAMM v3.0 Practice: Security Requirements (SR) Domain: Endpoints Questionnaire Authored: 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