Security Architecture (SA) - Endpoints Assessment

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

Secure Architecture (SA) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

v3.0 canonical source: ../practices/SA-Endpoints-OnePager.md. Outcome metrics, activities, and success criteria are verbatim from that document. Subject rule (§12.1): the AI is what is being secured, not a tool performing security tasks.

Practice: Secure Architecture (SA) Domain: Endpoints Purpose: Assess organizational maturity in publishing and operationalizing reference architectures for safely deploying each AI/HAI endpoint archetype the organization uses 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

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + 3 or more outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + fewer than 2 metrics meet targets
Not Implemented	0.0	No evidence of the practice

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

Maturity Level 1

Objective: Publish reference architectures per endpoint AI archetype and an anti-pattern catalog derived from real incidents; link each pattern to SR-Endpoints requirements and TA-Endpoints threats.

Question 1: Publish Reference Architectures per Endpoint AI Archetype

Q1.1: Has the organization published a reference architecture pattern for each of the seven endpoint AI archetypes it deploys, AI assistant/copilot on managed endpoint, browser-based AI tool/extension, chatbot/conversational UI, multi-modal AI interface, AI-augmented productivity (SaaS-AI feature), mobile AI app, and edge AI device, with each pattern including a labeled deployment diagram, data-boundary definition, identity and auth model, DLP/egress controls, logging specification, and explicit row-by-row mapping to SR-Endpoints requirements and TA-Endpoints threats with HAI TTP tags and applicable MITRE ATLAS mitigation IDs, accessible within one click of the SM inventory record?

Evidence Required: - [ ] Architecture registry listing all seven endpoint AI archetype reference patterns with version and publication date - [ ] Each pattern document includes a labeled deployment diagram covering scope, data boundary, identity and auth (SSO + MFA, managed-endpoint requirement, personal-account prohibition), deployment topology, DLP / egress controls, logging spec, SR mapping, and threat mapping - [ ] Managed-endpoint enforcement documented in AI assistant and browser extension patterns (MDM policy enforced, personal device use blocked) - [ ] Art. 50 disclosure component documented in chatbot pattern (persistent disclosure, cannot be suppressed by system prompt or UX flow) - [ ] HAI TTP tags (EA / AGH / TM / RA) and applicable MITRE ATLAS mitigation IDs present in each pattern - [ ] SM inventory records link to the applicable reference pattern within one click of the deployment record - [ ] 100% of chatbot and conversational UI deployments with a confirmed Art. 50 disclosure implementation on file (verified by ST-Endpoints test, not only UX screenshot)

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns published per archetype (AI assistant, browser extension, chatbot, multi-modal, AI-augmented productivity, mobile AI, edge AI) | 0 / 7 | 7 / 7 | Architecture registry | ☐ | | | % active endpoint AI deployments in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | % of chatbot and conversational UI deployments with a confirmed Art. 50 disclosure implementation on file | measure | 100% | IR spot-check / ST-Endpoints test result | ☐ | | | Pattern-to-SR requirement mapping coverage | measure | 100% of pattern controls tagged to SR requirement | Pattern metadata | ☐ | |

Metric Collection Guidance: - Patterns published: Count published patterns with all required skeleton elements present for all seven archetypes. Source: architecture registry. Reviewed quarterly. - Inventory deployment adoption: Query SM inventory for each active endpoint AI deployment's pattern-adoption field. Count deployments classified as "on pattern" or "deviation with review" divided by total active deployments. Source: SM inventory export. - Art. 50 disclosure confirmation: Run ST-Endpoints test for each chatbot and conversational UI deployment. Confirm that the disclosure component is present, persistent, and cannot be suppressed. Count compliant deployments divided by total chatbot/conversational UI deployments. Source: ST-Endpoints test result records. - SR mapping coverage: For each pattern, count controls with a SR requirement tag divided by total controls. Aggregate across all seven patterns. Source: pattern metadata.

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)

Evidence Location: __ Validation Date: __ Notes: ___

Question 2: Publish the Anti-Pattern Catalog

Q1.2: Has the organization published an anti-pattern catalog with a minimum of 10 entries, each naming the pattern, explaining why it is dangerous, citing a real or representative incident, and linking to the reference pattern element that replaces it, linked from the AI Acceptable Use Policy, the SM intake gate, and EG-Endpoints training, and are 100% of chatbot and conversational UI deployments verified via ST-Endpoints test to have a persistent Art. 50 disclosure that cannot be suppressed?

Evidence Required: - [ ] Anti-pattern catalog document with at least 10 named entries covering the L1 mandatory set (AI assistant on unmanaged endpoint, browser extension with <all_urls> permission and AI backend, chatbot without Art. 50 disclosure, multi-modal without input validation, SaaS-AI feature enabled tenant-wide without intake, mobile AI with broad permissions, edge AI without firmware/model signing, no-train assertion trusted from contract text, endpoint AI with no kill-switch, chatbot with no escalation-to-human path) - [ ] Each entry includes: description, why dangerous, real/representative incident, and the reference pattern element that replaces it - [ ] Catalog linked from the AI Acceptable Use Policy (with a dated link) - [ ] Catalog linked from the SM intake gate (verified by IR spot-check) - [ ] Catalog referenced in EG-Endpoints training materials with a dated curriculum link - [ ] ST-Endpoints test records confirming Art. 50 disclosure for all chatbot and conversational UI deployments (not only UX screenshots)

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-pattern catalog published and linked from intake / SM inventory | n/a | Yes | Document registry | ☐ | | | % of chatbot and conversational UI deployments with Art. 50 disclosure confirmed by ST-Endpoints test (not only UX screenshot) | measure | 100% | ST-Endpoints test result | ☐ | | | Anti-pattern catalog entries with a real-incident or representative-incident citation | measure | 100% of entries | Catalog metadata | ☐ | | | Time from new IM-Endpoints incident classification to anti-pattern catalog entry | measure | ≤30 days | Catalog change log | ☐ | |

Metric Collection Guidance: - Catalog published: Binary check, catalog exists, is versioned, and links are present from the three required touchpoints. Source: document registry audit. - Art. 50 disclosure test: ST-Endpoints test for each chatbot/conversational UI deployment. Tests must include: disclosure present on session start, disclosure cannot be suppressed by system prompt, disclosure cannot be suppressed by user request, disclosure cannot be suppressed by UX flow. Count deployments with a passing ST-Endpoints test divided by total chatbot/conversational UI deployments. Source: ST-Endpoints test result records. - Incident citation coverage: Count anti-pattern entries with an incident citation field populated divided by total entries. Source: catalog metadata. - Catalog update lead time: From IM-Endpoints incident classification timestamp to catalog-entry publication timestamp. Source: IM-Endpoints log and catalog change log.

Evidence Location: __ Validation Date: __ Notes: ___

Question 3: Integrate Patterns into the Intake/Inventory Flow and Establish the Deviation-Review Path

Q1.3: Is a repeat-deviation signal operational, such that three deviations in the same direction for the same archetype automatically queue a pattern-update review with SA ownership, and are 85% or more of active endpoint AI deployments in the SM inventory classified as "on pattern" or "deviation with review" with no silent deviations?

Evidence Required: - [ ] SM inventory fields for pattern-adoption status populated for all active endpoint AI deployments - [ ] Repeat-deviation signal wired: a query, report, or automation that detects three or more deviations in the same direction for the same endpoint AI archetype and generates a pattern-update queue item - [ ] Pattern-update queue items traceable to deviation records with SA ownership assigned - [ ] New-archetype lead-time SLA documented (target: 30 days from first intake in a new endpoint AI archetype category to pattern publication) - [ ] Pattern quarterly review schedule with change-log entries maintained - [ ] Zero deployments with unreviewed/silent deviations confirmed by audit

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % active endpoint AI deployments in the SM inventory using a named reference pattern or documented deviation | measure | ≥85% | Inventory × pattern metadata | ☐ | | | Repeat-deviation signal operational (three deviations in same direction queue pattern-update review) | measure | Yes, operational and tested | Deviation-review log | ☐ | | | New-archetype lead time (days from first intake to pattern publication) | measure | ≤30 days | Architecture registry change log | ☐ | | | Silent-deviation count (deployments with no pattern classification) | measure | 0 | SM inventory audit | ☐ | |

Metric Collection Guidance: - Inventory adoption: Same query as Q1.1 outcome metric 2. Reported monthly. - Repeat-deviation signal: Demonstrate by showing at least one instance of the trigger firing and a resulting pattern-update queue item. Source: deviation-review log and pattern-update queue. - New-archetype lead time: For each new endpoint AI archetype category added to the inventory in the review period, measure elapsed days from first intake record to published pattern date. Source: SM inventory and architecture registry. - Silent deviations: Export SM inventory and count endpoint AI deployments where pattern-adoption field is null, empty, or unclassified. Target is zero. Source: SM inventory export.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 2

Objective: Extend reference patterns to multi-region, sector-specific, and tier-conditional variants; encode patterns as MDM configuration profiles and SaaS-admin baselines; update the anti-pattern catalog from IM-Endpoints incidents.

Question 4: Tier-Conditional Pattern Extensions as MDM Profiles and SaaS-Admin Baselines

Q2.1: Are the four tier-conditional extended patterns, Critical overlay, High overlay, multi-region/cross-border, and managed-endpoint enforcement, published as deployable MDM configuration profiles or SaaS-admin configuration baselines with conformance checks, and are 80% or more of Critical and High-tier endpoint AI deployments running on encoded patterns as confirmed by MDM compliance reporting and the SM inventory?

Evidence Required: - [ ] Four tier-conditional pattern variants documented and published: Critical overlay (per-tenant isolation baselines, sector-specific regulatory overlays, kill-switch MDM configuration, EU AI Act Art. 26 full deployer-duty controls, Art. 50 red-team probe requirement), High overlay (monitoring and logging MDM / SaaS-admin modules, standard ML-Endpoints L2 detections pre-configured), multi-region / cross-border pattern (data-residency enforcement at SaaS-admin console or MDM policy), managed-endpoint enforcement pattern (conditional access policy: enrollment confirmed before access) - [ ] Each variant encoded as a deployable MDM configuration profile (Apple MDM / Intune / Workspace ONE or equivalent) or SaaS-admin configuration baseline - [ ] Each profile or baseline ships with a conformance check: no-train setting confirmed, extension allowlist applied, DLP rules active, audit logging forwarded to SIEM, kill-switch mechanism configured - [ ] Configuration profiles version-pinned with drift-detection mechanism - [ ] 100% of Critical-tier deployments with EU AI Act Art. 26 and Art. 50 controls explicitly mapped in the pattern documentation

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Tier-conditional pattern variants published (Critical overlay, High overlay, multi-region, managed-endpoint enforcement) | 0 / 4 | 4 / 4 | Architecture registry | ☐ | | | % Critical and High-tier endpoint AI deployments using an MDM-profile or SaaS-admin-baseline-encoded pattern | measure | ≥80% | MDM compliance report × SM inventory | ☐ | | | Conformance check coverage across MDM-profile and SaaS-admin-baseline deployments | measure | 100% of encoded deployments | MDM compliance / SaaS-admin report | ☐ | | | % Critical-tier deployments with EU AI Act Art. 26 and Art. 50 controls explicitly mapped in the pattern | measure | 100% | Pattern metadata | ☐ | |

Metric Collection Guidance: - Tier-conditional variants: Count published variants with MDM profile / SaaS-admin baseline and conformance check present. Source: architecture registry. Reviewed quarterly. - Encoded pattern adoption rate: Cross-reference MDM compliance report against SM inventory for all Critical and High-tier endpoint AI deployments. Divide encoded-pattern count by total Critical/High count. Source: MDM compliance report and SM inventory export. - Conformance check coverage: Count encoded deployments with a passing conformance check in the last 30 days divided by total encoded deployments. Source: MDM compliance / SaaS-admin report. - EU AI Act mapping: Count Critical-tier deployments whose pattern document includes Art. 26 and Art. 50 control-mapping section divided by total Critical-tier deployments. Source: pattern metadata.

Evidence Location: __ Validation Date: __ Notes: ___

Question 5: Patterns as MDM Configuration Profiles and SaaS-Admin Baselines

Q2.2: Has the anti-pattern catalog been updated from three or more real IM-Endpoints incidents in the last 12 months, with new entries surfaced at intake time rather than stored only in a reference document, and is conformance checking covering 100% of encoded deployments with findings tracked to resolution?

Evidence Required: - [ ] IM-Endpoints incident log showing at least 3 incidents in the last 12 months classified to an anti-pattern (existing or new) - [ ] Anti-pattern catalog change log showing entries added from IM-Endpoints classifications with incident references - [ ] Anti-patterns surfaced at intake time: SM intake gate shows current anti-patterns alongside approved archetype selection - [ ] Conformance check failure log for the last 90 days showing findings with assigned owners and resolution timestamps - [ ] MDM profile / SaaS-admin baseline update notification mechanism operational (teams consuming a profile are notified of updates requiring remediation) - [ ] Profile change log maintained with dated entries

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Anti-pattern catalog additions fed from IM-Endpoints incidents in last 12 months | measure | ≥3 additions | Anti-pattern change log | ☐ | | | Conformance check coverage across MDM-profile and SaaS-admin-baseline deployments | measure | 100% of encoded deployments | MDM compliance / SaaS-admin report | ☐ | | | Conformance check findings tracked to resolution (no open findings >30 days without an owner) | measure | 100% of findings have an owner and resolution timeline | Conformance finding tracker | ☐ | | | MDM profile / SaaS-admin baseline update notification SLA | measure | ≤10 business days | Profile change log + notification records | ☐ | |

Metric Collection Guidance: - Anti-pattern additions from incidents: Count catalog entries added in the last 12 months that carry an IM-Endpoints incident reference. Source: anti-pattern catalog change log. - Conformance check coverage: Same as Q2.1. Reviewed monthly. - Finding resolution tracking: Export conformance check findings. Count findings with no assigned owner or with age >30 days and no resolution timestamp. Target is zero. Source: conformance finding tracker. - Profile notification SLA: For each MDM profile or SaaS-admin baseline update in the review period, calculate elapsed days from profile version-bump to last team-notification confirmation. Source: profile change log and notification records.

Evidence Location: __ Validation Date: __ Notes: ___

Question 6: EU AI Act Art. 26 and Art. 50 Mapping and Managed-Endpoint Enforcement

Q2.3: Are 100% of Critical-tier deployments carrying explicit EU AI Act Art. 26 and Art. 50 control mappings in the pattern documentation, and is the tier-treatment matrix from SM L2 reflected in the pattern variants, Critical deployments get the Critical overlay (including Art. 50 red-team probe and kill-switch MDM configuration), High deployments get the High overlay, Medium/Low follow the base pattern?

Evidence Required: - [ ] Tier-treatment matrix from SM-Endpoints L2 documented and linked from the SA-Endpoints pattern selection guide - [ ] Evidence that Critical-tier deployments are using the Critical overlay MDM profile / SaaS-admin baseline including kill-switch MDM configuration (confirmed by MDM compliance report, not only policy) - [ ] Evidence that High-tier deployments are using the High overlay MDM / SaaS-admin modules (confirmed by MDM compliance report) - [ ] Art. 50 red-team probe result on file for at least one Critical-tier chatbot deployment confirming disclosure cannot be suppressed by any known jailbreak technique - [ ] Managed-endpoint conditional access policy confirmed operational: IdP/MDM enforcement confirmed by at least one test record showing access denied from an unmanaged device - [ ] Quarterly reconciliation record of Critical/High deployment list against encoded-pattern adoption

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | % Critical-tier deployments with EU AI Act Art. 26 and Art. 50 controls explicitly mapped in the pattern | measure | 100% | Pattern metadata | ☐ | | | % Critical-tier deployments confirmed on the Critical overlay (including kill-switch MDM configuration) | measure | 100% | MDM compliance report × SM inventory | ☐ | | | % High-tier deployments confirmed on the High overlay | measure | ≥80% | MDM compliance report × SM inventory | ☐ | | | Quarterly tier-treatment matrix reconciliation completed on schedule | measure | 4 of 4 quarters completed | Reconciliation log | ☐ | |

Metric Collection Guidance: - Art. 26/50 mapping coverage: Count Critical-tier deployments whose pattern document includes Art. 26 and Art. 50 control-mapping section divided by total Critical-tier deployments. Source: pattern metadata audit. - Critical overlay adoption: Cross-reference SM inventory (Critical-tier deployments) against MDM compliance report (profile ID applied). Count deployments using the Critical overlay profile divided by total Critical-tier deployments. Source: MDM compliance report and SM inventory. - High overlay adoption: Same method applied to High-tier deployments. Source: MDM compliance report and SM inventory. - Reconciliation cadence: Count reconciliation records completed in the last 12 months. Target is 4. Source: reconciliation log.

Evidence Location: __ Validation Date: __ Notes: ___

Maturity Level 3

Objective: Publish reference patterns as open industry artifacts; contribute pattern-derived mitigations to MITRE ATLAS; engage standards bodies and regulators on architecture norms for AI/HAI endpoint deployment.

Question 7: Publish Reference Patterns as Open Artifacts

Q3.1: Have five or more reference patterns been published as open artifacts under a recognized open license via at least one industry body, OWASP MASVS, CSA endpoint AI security initiative, OpenSSF AI, or equivalent, and have two or more of those patterns been cited or forked by recognized industry or sector bodies, with documented adoption evidence and internal practice aligned to the published version?

Evidence Required: - [ ] At least 5 patterns published under Apache 2.0 or equivalent open license in a public repository (OWASP, CSA, OpenSSF AI, or equivalent) - [ ] Publication link, license declaration, and publication date on file for each published pattern - [ ] At least 2 patterns with documented external citations or forks (GitHub fork count, citation in published work, documented adopter organization) - [ ] Pattern adoption telemetry report (GitHub forks, citations, documented adopters) covering the last 12 months - [ ] Internal-external alignment audit showing zero unexplained divergences between internal pattern versions and published external versions - [ ] New archetypes or overlays developed internally proposed for external inclusion within 90 days of internal publication (process documented)

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Reference patterns externally published (open license) | 0 | ≥5 patterns published | External repository | ☐ | | | Patterns cited or forked by recognized industry bodies | 0 | ≥2 cited or forked | External telemetry / citation tracking | ☐ | | | Internal practice aligned to published external version | n/a | 100%, zero unexplained internal deviations | Pattern diff audit | ☐ | | | New internal endpoint AI archetypes proposed for external inclusion within 90 days | measure | 100% of new internal archetypes | Architecture registry change log | ☐ | |

Metric Collection Guidance: - Patterns published: Count patterns with a public repository URL, open-license declaration, and publication date. Source: external repository and architecture registry. - External citations/forks: Count external citations and GitHub forks. Source: external telemetry report. - Internal-external alignment: Run a quarterly diff between internal pattern version and published external version. Count unexplained divergences. Source: pattern diff audit. - External proposal lead time: For each new internal endpoint AI archetype, measure elapsed days from internal publication to external proposal submission. Source: architecture registry and external contribution log.

Evidence Location: __ Validation Date: __ Notes: ___

Question 8: Contribute to MITRE ATLAS Mitigation Library

Q3.2: Have two or more MITRE ATLAS AML.M00xx mitigation entries been proposed or validated, traceable to specific SA-Endpoints pattern controls aligned to ATLAS primary tactics TA0007 Privilege Escalation, TA0008 Defense Evasion, TA0011 Exfiltration, and TA0005 Persistence, and is there an active ATLAS practitioner engagement cadence with at least one contribution or validation per six months?

Evidence Required: - [ ] ATLAS contribution log with at least 2 entries showing proposed or validated AML.M00xx mitigations traceable to SA-Endpoints pattern controls - [ ] Priority controls aligned to ATLAS primary tactics: TA0007 Privilege Escalation (extension scope minimization, tool allowlist, managed-endpoint enforcement, permission minimization), TA0008 Defense Evasion (chatbot output filter, modality-specific input validation, model signing verification), TA0011 Exfiltration (DLP at endpoint, no-train enforcement, uplink signing and encryption), TA0005 Persistence (firmware/model signing, per-session memory bounds) - [ ] ATLAS practitioner community engagement records covering the last 12 months - [ ] Traceability table linking each ATLAS contribution to the specific SA-Endpoints pattern control it corresponds to - [ ] At least 1 ATLAS contribution or validation completed in each 6-month period over the last 12 months

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | MITRE ATLAS mitigation entries proposed or validated by SA-Endpoints | 0 | ≥2 AML.M00xx entries | ATLAS contribution log | ☐ | | | ATLAS contributions traceable to SA-Endpoints pattern controls (TA0007 / TA0008 / TA0011 / TA0005) | 0 | 100% of contributions have pattern traceability | ATLAS contribution log + traceability table | ☐ | | | ATLAS contribution or validation cadence | measure | ≥1 per 6-month period | ATLAS contribution log | ☐ | | | ATLAS practitioner community engagement events or submissions | measure | ≥2 per year | Engagement records | ☐ | |

Metric Collection Guidance: - ATLAS contributions: Count AML.M00xx entries in the ATLAS contribution log with a status of "proposed" or "validated." Source: ATLAS contribution log. - Pattern traceability: For each ATLAS contribution, verify that a traceability row linking to a specific SA-Endpoints pattern control is present. Source: traceability table. - Contribution cadence: Divide the last 12 months into two 6-month periods. Count contributions or validations in each period. Source: ATLAS contribution log timestamps. - Community engagement: Count ATLAS practitioner working-group events, comment submissions, or practitioner-meeting records. Source: engagement records.

Evidence Location: __ Validation Date: __ Notes: ___

Question 9: Engage Regulators and Standards Bodies on Endpoint AI Architecture Norms

Q3.3: Is there at least one documented reference to SA-Endpoints patterns in a regulatory implementing-act, sector guidance document, or published standards text, and is the regulatory engagement calendar maintained with active items, target timelines, and evidence of substantive (not declaratory) participation in EU AI Act Art. 50 implementing guidance consultations, OWASP MASVS AI extensions, ISO/IEC 42001 AIMS, NIST AI RMF Playbook, or sector-specific regulatory processes?

Evidence Required: - [ ] At least 1 documented reference to SA-Endpoints patterns in a regulatory implementing-act, sector guidance document, or published standards text - [ ] Regulatory engagement calendar with active items listing the body, engagement type, submission status, and target timeline - [ ] EU AI Act Art. 50 implementing guidance consultation submissions where SA-Endpoints chatbot pattern's disclosure controls were submitted as evidence of "state of the art" - [ ] OWASP MASVS AI extension contribution record: mobile AI app pattern submitted as input to MASVS mobile AI security controls - [ ] ISO/IEC 42001 AIMS community guidance contribution record covering endpoint AI deployment documentation - [ ] Sector-specific engagement record: FINRA/SEC (AI-assisted financial advice endpoint controls), HHS/FDA (AI-enabled device firmware signing), or NYDFS Part 500 (AI endpoint security) - [ ] Evidence that engagement is substantive: submission text or contribution artifact includes SA-Endpoints pattern content (not only a letter of participation)

Outcome Metrics: | Metric | Baseline | Target | Source | Met? | Notes | |--------|----------|--------|--------|------|-------| | Regulatory or standards-body references to SA-Endpoints patterns | 0 | ≥1 documented reference | Regulatory engagement log | ☐ | | | Regulatory engagement calendar maintained with active items | measure | Yes, maintained with ≥2 active items at all times | Regulatory engagement calendar | ☐ | | | External contribution pipeline (pattern items in-flight: draft, in-review, or in-publication) | measure | ≥2 items in-flight at all times | External contribution pipeline log | ☐ | | | Internal-external alignment audit completed quarterly | measure | 4 of 4 quarters completed | Pattern diff audit log | ☐ | |

Metric Collection Guidance: - Regulatory references: Search implementing-act consultation responses, OWASP/CSA/ISO published guidance, and standards text for citations of SA-Endpoints patterns. Count distinct documented references. Source: regulatory engagement log and external citation tracking. - Engagement calendar health: Review the calendar. Count active items with a named target body, engagement type, and target timeline. Source: regulatory engagement calendar. - Contribution pipeline: Count items in the external contribution pipeline with a status of draft, in-review, or in-publication. Source: external contribution pipeline log. Reviewed monthly. - Alignment audit cadence: Count quarterly diff audits completed in the last 12 months. Target is 4. Source: pattern diff audit log.

Evidence Location: __ Validation Date: __ Notes: ___

Summary Scorecard

Level	Q1 Score	Q2 Score	Q3 Score	Level Score
L1, Publish reference architectures and anti-pattern catalog	___/1.0	___/1.0	___/1.0	___/1.0
L2, MDM-profile/SaaS-admin encoded patterns with conformance checks	___/1.0	___/1.0	___/1.0	___/1.0
L3, Open artifacts, ATLAS contributions, regulatory engagement	___/1.0	___/1.0	___/1.0	___/1.0

Overall SA-Endpoints Score (L1×0.5 + L2×0.3 + L3×0.2): ___/1.0

Maturity Statement: - Score 0.0–0.32: Pre-L1, reference patterns and anti-pattern catalog are not yet published; no vetted green path exists for endpoint AI deployment teams. - Score 0.33–0.65: L1 Partial, some reference patterns published but Art. 50 disclosure verification, catalog linkage, or deviation tracking is incomplete. - Score 0.66–0.79: L1 Achieved, all seven endpoint AI archetypes have reference patterns; anti-pattern catalog published; Art. 50 disclosure confirmed by ST-Endpoints test; deviation-review path operational. - Score 0.80–0.89: L2 Achieved, four tier-conditional MDM/SaaS-admin patterns operational; Art. 26 and Art. 50 mapping at target; incident-informed catalog updates in place. - Score 0.90–1.0: L3 Achieved, patterns published as open industry artifacts; ATLAS contributions traceable to TA0007/TA0008/TA0011/TA0005; regulatory engagement substantive and documented.

Document Version: HAIAMM v3.0 Practice: Secure Architecture (SA) Domain: Endpoints Questionnaire Version: v3.0 Publication 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