Design Review (DR) - 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 Design Review (DR) in the Endpoints domain is ../practices/DR-Endpoints-OnePager.md. This questionnaire is authored against that one-pager. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md §8.

Design Review (DR) - Endpoints Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Design Review (DR) Domain: Endpoints Purpose: Assess organizational maturity in operating the design checkpoint between intake approval and deployment for every new AI/HAI-enabled endpoint or user-facing AI interface, confirming managed-endpoint requirement, DLP scope, vendor no-train probing, archetype-specific data-class boundaries, Art. 50 disclosure, logging, and kill-switch path before rollout begins 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 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 OR <2 outcome metrics meet targets
0.0	Not Implemented	No evidence of practice

Level Score = average of question scores within a level Overall DR-Endpoints Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every AI/HAI-enabled endpoint rollout before deployment, producing a written decision traceable to SA-Endpoints pattern, SR-Endpoints requirements, and TA-Endpoints threat snapshot

Question 1: Per-Archetype AI/HAI Endpoints Design Checklist

Q1.1: Is there a published, versioned per-archetype AI/HAI Endpoints Design Checklist, one per SM-Endpoints archetype (AI assistant / copilot on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), traceable to the applicable SA-Endpoints reference pattern, SR-Endpoints requirements pack, and TA-Endpoints threat snapshot?

Q1.2: Does the common spine of each checklist cover managed-endpoint requirement (Critical-tier AI assistants require MDM-enrolled device), identity (SSO-backed access, service-principal model, secrets vault), DLP at endpoint (inspection scope defined, data classes declared, DLP policy wired and active), vendor no-train probing (admin API or admin-console setting confirmed, not contract language alone), archetype-specific data-class boundaries (regulated data isolated or blocked), Art. 50 disclosure (UX present for customer-facing or user-interactive AI), logging (interaction, admin-audit, identity events; retention; export mechanism), kill-switch / disable path (emergency-halt mechanism; test plan; named owner), and affected-persons rights surface?

Q1.3: Do archetype-specific checklists include their mandatory additions, AI assistant (managed-endpoint requirement, tool-allowlist, audit-log completeness), chatbot (prompt-injection defense, output filter, Art. 50 UX, escalation path), edge device (signed firmware, boot attestation, physical-tamper detection, remote-disable path), and SaaS-AI feature (intake review required before tenant-wide enablement, per-feature data scope declared)?

Evidence Required: - [ ] Per-archetype checklist set published and version-controlled, one file or section per SM-Endpoints archetype with an explicit version stamp - [ ] Chatbot checklist includes all four mandatory items: prompt-injection defense, output filter, Art. 50 UX disclosure, and escalation path with SLA - [ ] Edge device checklist includes: signed firmware, boot attestation, physical-tamper detection, and remote-disable path - [ ] Vendor no-train probing item present in each checklist, specifying that admin-console confirmation is required, not just contract language - [ ] Kill-switch / disable path item present in each checklist with test plan requirement - [ ] Named lead reviewer per archetype confirmed (EG-Endpoints L1 completion verified)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI/HAI-enabled endpoints going to production with a completed DR decision record before deployment | % | % | ≥95% | ☐ | SM-Endpoints inventory × DR records | | % DR records referencing the applicable SA reference pattern and SR REM | % | % | 100% | ☐ | DR records | | Median review turnaround, fast-lane | ___ BD | ___ BD | ≤2 BD | ☐ | Review SLA telemetry | | Median review turnaround, full-lane | ___ BD | ___ BD | ≤5 BD | ☐ | Review SLA telemetry |

Metric Collection Guidance: - DR coverage: Count AI/HAI endpoints reaching production with a dated DR decision record predating deployment start, divided by total endpoints promoted to production. Source: SM-Endpoints inventory joined to DR record store. Measured quarterly. - Pattern and REM reference rate: Inspect DR records for a hyperlink or identifier referencing the SA-Endpoints reference pattern and SR-Endpoints REM. Automated field validation preferred. - Fast-lane SLA: P50 of (DR decision date − review submission date) for fast-lane reviews. Customer-facing chatbots and regulated-data endpoints always route to full-lane at L1. - Full-lane SLA: P50 of same calculation for full-lane reviews (High/Critical, customer-facing, regulated data, sector-scoped, pattern deviation).

Answer: - ☐ Fully Mature (Evidence complete + ≥3 metrics meet targets) - ☐ Implemented (Evidence complete + 2 metrics meet targets) - ☐ Partial (Evidence partially complete + <2 metrics meet targets) - ☐ Not Implemented (No per-archetype checklist published)

Evidence Location	Validation Date	Notes

Question 2: Two-Lane Routing and Decision Records

Q2.1: Is a two-lane routing model operational, fast-lane (Low/Medium tier, on-pattern, ≤2 BD) and full-lane (High/Critical tier, customer-facing, regulated data, sector-scoped, or pattern deviation, ≤5 BD), with routing criteria published and applied consistently?

Q2.2: Does every DR decision record contain: decision (approve / approve-with-conditions / send-back); checklist completed with evidence pointers; deviations listed with rationale; residual risks with named owner and expiry; reviewer name and date; links to SM-Endpoints inventory record, TA-Endpoints threat snapshot, and SR-Endpoints REM?

Q2.3: Are open approve-with-conditions items tracked to resolution, with named owners, expiry dates, and an enforcement path before deployment?

Evidence Required: - [ ] Routing criteria document specifying which tier/archetype/deviation combinations trigger full-lane vs. fast-lane - [ ] Decision record template with all required fields used for the last 10 reviews (sample auditable) - [ ] Approve-with-conditions items in a trackable backlog with named owner and expiry date per item - [ ] Sample of ≥5 decision records showing the residual-risk list populated with named owners (not blank) - [ ] Art. 50 disclosure item confirmed present (not marked not-applicable without documented reasoning) for customer-facing chatbot and conversational UI records - [ ] Reviewer training records confirming EG-Endpoints L1 completion for all active reviewers

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI/HAI-enabled endpoints going to production with a completed DR decision record before deployment | % | % | ≥95% | ☐ | SM-Endpoints inventory × DR records | | Open approve-with-conditions items aging >60 days | ___ | ___ | 0 | ☐ | Action-item backlog | | Median review turnaround, fast-lane | ___ BD | ___ BD | ≤2 BD | ☐ | Review SLA telemetry | | Median review turnaround, full-lane | ___ BD | ___ BD | ≤5 BD | ☐ | Review SLA telemetry |

Metric Collection Guidance: - Approve-with-conditions aging: Query action-item backlog for items where (today − condition creation date) > 60 days and status is not resolved. Measured weekly. - Art. 50 coverage: Spot-check DR records for customer-facing chatbots and conversational UIs, confirm Art. 50 disclosure item is present with evidence pointer (screenshot or design mockup link), not marked not-applicable without reasoning.

Evidence Location	Validation Date	Notes

Question 3: Loop-back to SA-Endpoints, SR-Endpoints, and IM-Endpoints

Q3.1: Are recurring pattern deviations and repeatedly-waived SR-Endpoints requirements automatically queuing SA-Endpoints pattern-update and SR-Endpoints pack-update reviews, with a threshold of three deviations in the same direction for the same archetype triggering a pattern-update review?

Q3.2: Does every IM-Endpoints incident trigger a re-examination of the DR decision record that approved the affected endpoint, asking which checklist item would have caught the issue?

Q3.3: Is the pattern-deviation rate tracked by archetype and surfaced in a regular program review?

Evidence Required: - [ ] Documented trigger rule: three same-direction deviations per archetype auto-queues SA-Endpoints pattern-update review - [ ] SA-Endpoints pattern-update queue and SR-Endpoints pack-update queue showing items from DR feedback in the last 12 months - [ ] IM-Endpoints incident post-mortems including a section linking back to the DR decision record with checklist re-examination findings - [ ] Checklist updated in response to at least one IM-Endpoints incident finding (version comparison available) - [ ] Pattern-deviation rate by archetype surfaced in a program review in the last quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % DR records referencing the applicable SA reference pattern and SR REM | % | % | 100% | ☐ | DR records | | SA/SR update items queued from DR feedback in last 12 months | ___ | ___ | ≥1 | ☐ | SA/SR update queues | | % IM-Endpoints incidents with a DR record re-examination step | % | % | 100% | ☐ | IM post-mortems | | Open approve-with-conditions items aging >60 days | ___ | ___ | 0 | ☐ | Action-item backlog |

Metric Collection Guidance: - SA/SR queue items from DR: Count items in SA-Endpoints or SR-Endpoints update queues with a DR-feedback source reference. Measured quarterly. - IM incident DR re-examination: Review IM-Endpoints incident records and confirm each has a linked DR record with a re-examination finding. Track coverage as a percentage. Measured after each incident closes.

Evidence Location	Validation Date	Notes

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs; run SaaS-admin handoff reviews before tenant-wide AI feature enablement; detect design drift for High and Critical endpoints on a published cadence

Question 4: Scenario-Based Reviews for Critical and High-Tier Endpoints

Q4.1: Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from the TA-Endpoints per-artifact deep threat model and anonymized IM-Endpoints incidents, with the DR decision tied explicitly to how the proposed design handles each scenario?

Q4.2: Are scenario sources refreshed quarterly from TA-Endpoints per-artifact deep models, MITRE ATLAS technique candidates relevant to the endpoint's primary control surface, OWASP MASVS (mobile), OWASP Browser-Extension Top 10 (browser tool), and OWASP LLM / Agentic Top 10 (chatbot / AI assistant) entries for the archetype?

Q4.3: For High-tier endpoints, is the standard full-lane review augmented with at least one scenario from the TA-Endpoints archetype library?

Evidence Required: - [ ] DR records for Critical-tier endpoints showing scenario-based walkthrough format with ≥3 named scenarios per review, specific to the endpoint's declared tool set, data classes, and user population - [ ] Each scenario maps to a design control or an accepted residual risk with named owner and expiry - [ ] Scenario library version-controlled with quarterly refresh dates and signal provenance (ATLAS technique, OWASP source, or IM incident ID cited) - [ ] TA-Endpoints per-artifact deep threat model referenced in each Critical-tier DR record - [ ] High-tier DR records showing at least one augmenting scenario from the TA-Endpoints archetype library - [ ] Reviewer population trained on scenario-based walkthrough technique including endpoint-specific OWASP and ATLAS sources

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier DR records using scenario-based walkthrough | % | % | 100% | ☐ | DR records | | % Critical/High-tier endpoints with drift check on published cadence | % | % | ≥95% | ☐ | Drift-check schedule × SM-Endpoints inventory | | % material drift findings re-routed to DR | % | % | 100% | ☐ | Drift-detection queue | | IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

Metric Collection Guidance: - Scenario-based coverage: Count Critical-tier DR records with a "scenarios" section listing ≥3 named threat scenarios with ATLAS, OWASP, or IM incident citations, divided by total Critical-tier DR records. Measured quarterly. - IR-stage surprises: Count IR findings with no corresponding DR condition for the same endpoint. Source: IR records joined to DR records. Trend tracked quarter-over-quarter.

Evidence Location	Validation Date	Notes

Question 5: SaaS-Admin Handoff Reviews for Tenant-Wide AI Feature Enablement

Q5.1: Before any SaaS AI feature (Copilot, Notion AI, Slack AI, Workspace AI, or equivalent) is enabled tenant-wide, does a dedicated DR handoff review confirm: the enable workflow is documented (who approves, who executes, what constitutes an authorized enablement event); the data scope is declared; conditional enablement is configured where possible; the admin-audit log captures the enablement event; and a drift-detection hook is in place to flag unauthorized or silent re-enablement?

Q5.2: Does the DR decision record for SaaS AI features explicitly identify the admin-console states that constitute the "approved posture", so that IR-Endpoints can compare live admin-console state against the record?

Q5.3: Where the SaaS vendor does not expose admin-API controls for a feature, is the gap noted as a residual risk with a named owner and compensating control (contractual commitment, manual quarterly audit) in the DR record?

Evidence Required: - [ ] SaaS-admin handoff review template with all five confirmation items: enable workflow, data scope, conditional enablement, admin-audit log, drift-detection hook - [ ] DR decision records for SaaS AI features explicitly identifying approved admin-console states - [ ] At least one SaaS-admin handoff review record from the last 12 months with all five items confirmed - [ ] DR records for SaaS features where vendor admin-API controls are absent, residual risk with compensating control documented - [ ] SaaS platform admin intake queue maintained, no tenant-wide enablement proceeds without a queued or completed DR handoff record

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % SaaS-AI tenant-wide feature enablements with a prior DR handoff record | % | % | 100% | ☐ | SaaS admin log × DR records | | % Critical-tier DR records using scenario-based walkthrough | % | % | 100% | ☐ | DR records | | % Critical/High-tier endpoints with drift check on published cadence | % | % | ≥95% | ☐ | Drift-check schedule × SM-Endpoints inventory | | IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

Metric Collection Guidance: - SaaS handoff coverage: Count tenant-wide SaaS AI feature enablements in the last 12 months with a prior DR handoff record, divided by total such enablements. Source: SaaS admin audit log joined to DR record store. Measured quarterly. - Silent enablement rate: Count tenant-wide AI feature enablements discovered without a prior DR record, divided by total enablements. Source: SaaS admin audit log compared to DR record store. Target: 0.

Evidence Location	Validation Date	Notes

Question 6: Design-Drift Detection for Endpoints

Q6.1: Is design-drift detection operating quarterly for Critical-tier and annually for High-tier endpoints, using MDM policy state, browser admin policy state, SaaS admin state (which AI features enabled per tenant / role), chatbot Art. 50 disclosure presence (sample-check), mobile app version and local-model signature, and edge device firmware and model signature?

Q6.2: Are material drift findings (DLP scope widened, new AI feature enabled tenant-wide without DR, Art. 50 disclosure removed, tool-allowlist changed, managed-endpoint requirement dropped) automatically re-opening the DR record and routing back through the appropriate lane?

Q6.3: Does the drift-detection tooling produce a staleness alert if a Critical endpoint has no drift check in the last 90 days?

Evidence Required: - [ ] Drift-detection schedule showing Critical endpoints checked quarterly and High endpoints annually - [ ] Drift check artifacts (written diffs) for ≥3 Critical-tier endpoints in the last 12 months, using MDM, browser admin policy, SaaS admin state, and disclosure presence sources - [ ] Classification criteria defining which delta types are material vs. non-material for endpoint design - [ ] At least one material drift finding that re-opened a DR record and routed to a new review - [ ] Staleness alert configuration confirmed (Critical endpoint silent for >90 days triggers alert) - [ ] Art. 50 disclosure presence included as a drift-check item for chatbot and conversational UI archetypes

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical/High-tier endpoints with drift check on published cadence | % | % | ≥95% | ☐ | Drift-check schedule × SM-Endpoints inventory | | % material drift findings re-routed to DR | % | % | 100% | ☐ | Drift-detection queue | | % Critical-tier DR records using scenario-based walkthrough | % | % | 100% | ☐ | DR records | | IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

Metric Collection Guidance: - Drift check cadence: Count Critical endpoints with a documented drift check in the last 90 days, divided by total Critical endpoints in SM-Endpoints inventory. Measured monthly. - Material drift re-routing: Count material drift findings with a corresponding DR re-review record, divided by total material findings. Measured per drift-check cycle.

Evidence Location	Validation Date	Notes

Maturity Level 3

Objective: Operate continuous design attestation via MDM, browser-policy, and SaaS-admin compliance scans; automate drift-triggered DR exception tickets; contribute review rubrics and scenario templates to CSA endpoint, OWASP MASVS, and OASIS

Question 7: Continuous Design Attestation via MDM, Browser-Policy, and SaaS-Admin Scans

Q7.1: Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily automated attestation signal, checking MDM policy compliance (DLP rules, extension allowlist, AI assistant scope), browser admin policy state (extension allowlist, per-extension scope), SaaS admin compliance (AI features per tenant / role match the DR-approved posture), chatbot Art. 50 disclosure rendered (automated probe), and mobile / edge device signature currency, with deviations automatically opening DR-exception tickets triaged within 3 business days?

Q7.2: Are attestation artifacts machine-readable and regulator-consumable, producing EU AI Act Art. 9 risk-management evidence and deployer-duty records per Art. 26 without manual assembly?

Q7.3: Do human reviewers handle only: novel endpoint configurations not covered by existing attestation rules, accepted exceptions with documented rationale, and IM-Endpoints escalations?

Evidence Required: - [ ] Attestation pipeline configuration showing daily scan cadence for Critical-tier endpoints across all five source types: MDM, browser admin policy, SaaS admin API, chatbot disclosure probe, device attestation - [ ] Coverage report: % of Critical-tier endpoints producing a fresh attestation signal in the last 24 hours - [ ] Sample attestation artifact covering all five check domains - [ ] DR-exception ticket queue showing tickets opened automatically on attestation deviation - [ ] Evidence that at least one DR-exception ticket was triaged within 3 business days of opening - [ ] Staleness alert confirmed (Critical endpoint silent for >48 hours triggers alert)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier endpoints producing a daily attestation signal | % | % | ≥90% | ☐ | Attestation telemetry | | Mean DR-exception ticket age from open to triage | ___ BD | ___ BD | ≤3 BD | ☐ | DR-exception queue | | Review backlog age, non-exception items | ___ days | ___ days | ≤7 days | ☐ | Review queue telemetry | | Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log |

Metric Collection Guidance: - Attestation coverage: Count Critical endpoints with a completed attestation scan across all five source types in the last 24 hours, divided by total Critical endpoints. Sourced from attestation pipeline run log. Measured daily; alert if below 90%. - Exception ticket SLA: P50 of (triage timestamp − open timestamp) for DR-exception tickets. Measured weekly. - Review backlog age: P90 age of non-exception review queue items. Measured weekly.

Evidence Location	Validation Date	Notes

Question 8: Contribute Review Rubrics and Scenario Templates to Industry

Q8.1: Has the program contributed ≥2 substantive review artifacts per year (per-archetype endpoint design rubrics, scenario templates, pattern-evolution frameworks) to CSA endpoint working groups, OWASP MASVS extensions (mobile and browser-based AI tools), OASIS AI assurance standards, or applicable sector bodies, with documented adoption?

Q8.2: Are internal rubrics and templates kept aligned to the published external versions, with internal deviations proposed as upstream changes rather than silently forked?

Q8.3: Is adoption tracked via citations, forks, or direct acknowledgment from peer organizations or standards bodies?

Evidence Required: - [ ] Contribution log showing ≥2 published artifacts in the last 12 months, per-archetype endpoint design rubrics, scenario templates (covering the seven endpoint archetypes), or pattern-evolution frameworks - [ ] Publication links (Apache 2.0 or equivalent) to CSA endpoint working groups, OWASP MASVS, OASIS, or applicable sector body - [ ] Adoption evidence: citations, forks, or written acknowledgment from a peer organization or standards body - [ ] Internal rubric version compared to external published version, confirmed aligned or upstream PR submitted for divergences - [ ] At least one artifact in draft, in-review, or published at the time of assessment

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Industry contributions per year (rubrics, scenario templates, pattern-evolution frameworks) | 0 | ___ | ≥2 | ☐ | Contribution log | | % Critical-tier endpoints producing a daily attestation signal | % | % | ≥90% | ☐ | Attestation telemetry | | Mean DR-exception ticket age from open to triage | ___ BD | ___ BD | ≤3 BD | ☐ | DR-exception queue | | Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log |

Metric Collection Guidance: - Industry contributions: Count distinct published artifacts publicly accessible under an open license. Measured annually. OWASP MASVS AI-extension adoption tracked separately as a key signal. - Adoption evidence: Log citations and forks quarterly. Scenario template adoption across mobile, browser, and chatbot archetypes tracked for completeness.

Evidence Location	Validation Date	Notes

Question 9: Quarterly Pattern Evolution Driven by External and Internal Signals

Q9.1: Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS technique additions relevant to endpoint AI archetypes; OWASP MASVS revisions; sector ISAC AI-specific endpoint advisories; OWASP Browser-Extension Top 10 updates; OWASP LLM / Agentic Top 10 revisions) and internal signals (IM-Endpoints incident patterns by archetype, ML-Endpoints telemetry anomalies, ST-Endpoints red-team findings), with a versioned change log?

Q9.2: Are downstream DR records for in-flight reviews notified of pattern changes that affect their archetype?

Q9.3: Where a new ATLAS technique or IM-Endpoints incident reveals a checklist gap, is the gap propagated to SA-Endpoints and SR-Endpoints to maintain the traceability chain?

Evidence Required: - [ ] Quarterly pattern-evolution review calendar with at least 4 sessions completed in the last 12 months, each with a dated agenda and change log entry - [ ] Change log showing signal provenance (ATLAS technique, OWASP MASVS revision, ISAC advisory reference, or IM incident ID) for each update - [ ] Evidence that ATLAS techniques, OWASP MASVS, and ISAC endpoint advisories were reviewed in the last quarter - [ ] In-flight DR review notifications sent when a pattern change affected the archetype under review - [ ] SA-Endpoints and SR-Endpoints update items queued from pattern-evolution checklist gaps - [ ] ATLAS, OWASP MASVS, and ISAC feeds ingested monthly into the pattern-update queue

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log | | % Critical-tier endpoints producing a daily attestation signal | % | % | ≥90% | ☐ | Attestation telemetry | | Industry contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log | | Review backlog age, non-exception items | ___ days | ___ days | ≤7 days | ☐ | Review queue telemetry |

Metric Collection Guidance: - Pattern-evolution cadence: Count completed quarterly reviews with a dated agenda and at least one change log entry citing an external signal source. Measured annually. - Signal provenance completeness: Spot-check 5 change log entries per quarter, verify each has a named source (ATLAS technique ID, OWASP MASVS revision reference, ISAC advisory, or IM incident ID).

Evidence Location	Validation Date	Notes

Summary Scorecard

Question	Level	Score (0 / 0.33 / 0.67 / 1.0)	Notes
Q1: Per-Archetype Endpoints Design Checklist	L1
Q2: Two-Lane Routing and Decision Records	L1
Q3: Loop-back to SA / SR / IM	L1
Q4: Scenario-Based Reviews (Critical/High)	L2
Q5: SaaS-Admin Handoff Reviews	L2
Q6: Design-Drift Detection	L2
Q7: Continuous Design Attestation	L3
Q8: Industry Contributions	L3
Q9: Quarterly Pattern Evolution	L3

Level 1 Score: ___ / 1.0 (average of Q1–Q3) Level 2 Score: ___ / 1.0 (average of Q4–Q6) Level 3 Score: ___ / 1.0 (average of Q7–Q9) Overall DR-Endpoints Score: ___ / 1.0 (L1 × 0.5 + L2 × 0.3 + L3 × 0.2)

Current Maturity Level: ☐ L1 ☐ L2 ☐ L3 Assessment Date: Assessor: Next Review Date:

Document Version: HAIAMM v3.0 Practice: Design Review (DR) 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