Design Review (DR)

Endpoints Domain - HAIAMM v3.0

Practice Overview

Objective: Operate the design checkpoint between intake approval and deployment for every new AI/HAI-enabled endpoint or user-facing AI interface, confirming the proposed design follows the applicable SA-Endpoints reference pattern, covers the SR-Endpoints requirements pack, and documents residual risks before rollout begins.

Description: DR-Endpoints is the single moment where endpoint architecture (SA-Endpoints), requirements (SR-Endpoints), and threats (TA-Endpoints) meet a specific planned deployment. At L1 the review is deliberate but lean: a per-archetype design checklist, a named reviewer, and a written decision (approve / approve-with-conditions / send-back) stored against the SM-Endpoints inventory record. The review runs before the deployment team begins rollout, catching deviations when they cost hours to correct, not sprints. A two-lane model routes Low / Medium-tier endpoints to an async fast-lane (≤2 BD) and High / Critical-tier, customer-facing, regulated-data, or sector-scoped cases to a full-lane architect review (≤5 BD). Loop-back signals ensure the review process improves SA-Endpoints patterns and SR-Endpoints packs over time rather than accumulating silent technical debt.

Context: Without an endpoint design checkpoint, AI/HAI user-facing interfaces deploy without a verified data boundary, without a confirmed DLP scope, without output-filter placement, and without a kill-switch path. An AI assistant rolls out to managed endpoints before SSO and DLP are confirmed in scope. A browser extension is approved without a scope review. A customer-facing chatbot goes live without Art. 50 disclosure in the UX. DR-Endpoints enforces the handoff between "design approved" and "deployment begins," making deviations visible and deliberate. EU AI Act Art. 50 requires disclosure for AI interactions at the UX surface; the DR decision record is the documented pre-deployment decision that confirms disclosure is present.

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

At this level, design review is a consistent gate, not a heroic intervention when data loss or disclosure failures surface post-rollout. Every AI/HAI-enabled endpoint above the triage threshold receives a review before deployment begins, and every review produces a written decision linked to the SM-Endpoints inventory record.

Dependencies

• SA-Endpoints L1 (required): the reference patterns for each endpoint archetype are what the checklist measures the proposed design against; without patterns there is no review baseline.
• SR-Endpoints L1 (required): the requirements pack (base plus archetype deltas) defines the acceptance bar; the REM is the primary evidence input to the review.
• TA-Endpoints L1 (required): the per-archetype threat snapshot names what the design must defend against; the reviewer walks the snapshot's top threats against the proposed deployment design.
• EG-Endpoints L1 (required): reviewers must be able to recognize endpoint AI archetypes, endpoint-specific HAI TTPs, and ATLAS tactics before they can produce a credible DR decision.
• Supports / unblocks: IR-Endpoints L1 (implementation reviews check deployed endpoints against the approved design), ST-Endpoints L1 (tests target the approved endpoint configuration), IM-Endpoints L1 (incident triage references design assumptions).

Desired Outcomes

• Every AI/HAI-enabled endpoint above the triage threshold is reviewed before deployment; no production rollout occurs without a DR decision on file.
• DR decisions are written, versioned, and stored against the SM-Endpoints inventory record, not tribal knowledge held by the reviewing architect or endpoint team.
• Deviations from SA-Endpoints reference patterns are approved or rejected explicitly with a named reviewer, a rationale, and a residual-risk acceptance.
• Art. 50 disclosure presence is confirmed at design time for every customer-facing AI interface, not discovered missing post-launch.
• Review is timeboxed: teams know whether to expect a 2 BD async check or a 5 BD architect session based on the SM-Endpoints tier and deviation status.
• Recurring deviation themes feed back into SA-Endpoints (pattern updates) and SR-Endpoints (pack updates), the review accumulates organizational learning, not only per-ticket decisions.

Activities

A) Publish the per-archetype AI/HAI Endpoints Design Checklist

One checklist per SM-Endpoints archetype, derived from the applicable SA-Endpoints reference pattern and keyed to the SR-Endpoints base pack and archetype delta. Each item is a yes/no with an evidence pointer. The seven checklists share a common spine and carry archetype-specific additions:

Common spine across all seven checklists: - Pattern adherence, using the SA-Endpoints reference pattern or documented deviation with rationale. - Identity, managed-endpoint requirement confirmed for Critical-tier AI; SSO-backed human access to all admin and operational interfaces; service-principal model for automated access; secrets-vault-backed API keys to AI vendors, no hardcoded credentials in configuration. - DLP at endpoint, DLP inspection scope defined for the archetype; data classes flowing to the AI component declared; DLP policy wired and active at the endpoint boundary. - Vendor no-train probing, vendor no-train commitment confirmed via admin API or admin-console setting, not from contract language alone; the archetype's applicable vendor setting identified and confirmed. - Archetype-specific data-class boundaries, which data classes are in scope for this deployment; how regulated data is isolated or blocked from reaching the AI component; output-filter placement declared. - Art. 50 disclosure, for customer-facing or user-interactive AI interfaces, EU AI Act Art. 50 disclosure is present in the UX design; evidence pointer (screenshot / design mockup) linked from the DR record. - Logging, interaction, admin-audit, and identity events captured per the SR-Endpoints base pack; retention meeting the longest applicable regulation; export mechanism defined. - Kill-switch / disable path, emergency-halt mechanism in the design for the specific endpoint archetype; test plan defined; named owner for the disable action. - Affected-persons rights surface, if the endpoint AI affects persons (employees, customers), the DSAR or rights-exercise surface is identified and mapped in the design.

Archetype-specific additions:

• AI assistant / copilot on managed endpoint: managed-endpoint requirement (Critical-tier AI assistants require MDM-enrolled device); SSO and DLP scope confirmed (assistant does not operate outside the DLP-monitored surface); tool-allowlist declared (assistant cannot invoke tools not explicitly listed); audit-log completeness confirmed (all invocations captured with user identity and timestamp).

• Browser-based AI tool: extension allowlist verified (the tool is on the org-approved browser extension allowlist before any rollout); extension scope reviewed (declared permission set matches the minimum required; no over-broad host permissions); DLP integration confirmed (browser DLP policy enforced for content flowing to or from the extension); backend SSO confirmed (the tool authenticates through org SSO, not a standalone credential).

• Chatbot / conversational UI: prompt-injection defense present in the design (system prompt isolated from user input; injection-mitigation strategy declared); output filter present and active before response reaches the user; Art. 50 UX disclosure present (AI identity disclosed on every interaction); escalation path defined (customer can reach a human within declared SLA).

• Multi-modal AI interface: modality-specific input validation declared for each modality (image, voice, document); output safety filter applied to each modality's output path; cross-modal consistency test defined (same intent via different modalities produces consistent safe output); Art. 50 disclosure present for each interaction mode.

• AI-augmented productivity (SaaS-AI on endpoint): intake review required before tenant-wide enablement (no silent rollout of SaaS AI features); per-feature data scope declared (which workspace content each AI feature can access); conditional enablement design (feature can be scoped by tenant, role, or group, not only all-or-nothing); admin-audit events captured for feature enablement actions.

• Mobile AI app: signed app and model confirmed (app signing verified; local model signature verification in the design); permission minimization confirmed (requested permissions are the minimum required for the stated use case; no over-broad permissions); on-device integrity attestation defined (device attestation check before app grants access to sensitive features).

• Edge AI device: signed firmware and model confirmed (firmware signature chain defined; local model signature verification in the design); boot attestation declared (secure boot and attestation mechanism identified); physical-tamper detection defined (tamper-evident hardware or software mechanism in the design); remote-disable path confirmed (mechanism for remotely disabling the device's AI capability named and tested).

B) Triage and route reviews by risk tier and deployment status

The two-lane model is driven by the SM-Endpoints tier assignment and deviation flag:

• Fast-lane (Low / Medium tier, on-pattern): async checklist review by the designated reviewer; target SLA ≤2 business days. Output: one structured decision record, approve / approve-with-conditions (explicit list) / send-back (reasons stated), stored against the SM-Endpoints inventory record.
• Full-lane (High / Critical tier OR customer-facing OR regulated data OR sector-scoped OR any pattern deviation): 45–60 minute architect review with the deployment team walking the SA-Endpoints reference pattern section-by-section; target SLA ≤5 business days. Output: written decision record with the residual-risk list reviewed by a named architect.

Triage rules at L1 (before SM L2 tiers are established): customer-facing chatbots and AI interfaces, and any endpoint deployment processing regulated data, default to full-lane. All others default to fast-lane with override to full-lane available on reviewer judgment.

Decision record contents (both lanes): decision (approve / approve-with-conditions / send-back); checklist completed with evidence pointers; deviations listed with rationale; residual risks listed with named owner and expiry; reviewer name and date; links to SM-Endpoints inventory record, TA threat snapshot, and SR REM.

C) Close the loop with SA-Endpoints, SR-Endpoints, and IM-Endpoints

Design review is a learning surface for the program:

• SA pattern update trigger: three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Endpoints ownership. Recurring deviations signal the pattern is miscalibrated, not that deployment teams are wrong.
• SR pack update trigger: an SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review. If every chatbot team waives the same base requirement, the pack needs recalibration.
• IM incident feedback loop: every IM-Endpoints incident re-examines the DR decision record that approved the affected endpoint. Was the issue visible at design time? Which checklist item would have caught it? The answer updates the checklist and feeds the next archetype review cycle.

Outcome Metrics (L1)

Process Metrics (leading)

• Reviewer population staffed and trained (EG-Endpoints L1 completion confirmed); named lead reviewer per archetype.
• Fast-lane vs. full-lane ratio monitored, a drift toward all-fast-lane may indicate under-review; toward all-full-lane may indicate over-routing.
• Pattern-deviation rate tracked by archetype, feeds the SA pattern-update trigger.
• Checklists aligned to current SA-Endpoints reference patterns and SR pack; updated within 30 days of any SA or SR change.

Effectiveness Metrics (business value)

• Issues caught at design vs. caught at IR or in incident, design-stage catch rate trends up as the program matures.
• Engineering cycle-time impact, DR adds a small, predictable window; teams can plan; the gate is not open-ended.
• SA/SR update volume driven by DR feedback, a healthy program generates pattern and pack improvements, not only per-ticket decisions.

Success Criteria

• Per-archetype design checklists published, versioned, and traceable to the applicable SA-Endpoints reference pattern, SR requirements pack, and TA threat snapshot.
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype.
• ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record before deployment begins.
• SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Endpoints incident re-examines the DR record that approved the affected endpoint.
• Named reviewer population trained (EG-Endpoints L1) and active.

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Endpoints per-artifact models, run SaaS-admin handoff reviews before tenant-wide feature enablement, and detect design drift for High and Critical endpoints on a published cadence

At this level, design review for Critical-tier endpoints moves from checklist conformance to scenario-based conversations. The TA-Endpoints per-artifact deep threat models (available at TA L2) drive the scenarios. SaaS-AI feature enablement receives a dedicated handoff review, the admin-enablement workflow, approval chain, and drift-detection hook are reviewed before tenant-wide rollout. Design drift, the live endpoint posture diverging from the approved design, is detected on a published cadence and automatically re-routed to DR.

Dependencies

• DR-Endpoints L1 (required): per-archetype checklists, two-lane model, and loop-back triggers.
• TA-Endpoints L2 (required): per-artifact deep threat models are the source material for Critical-tier scenario walkthroughs.
• SA-Endpoints L2 (required): MDM-encoded and browser-policy-encoded patterns and tier-conditional overlays are what L2 reviews verify the design against.
• SM-Endpoints L2 (required): the risk-tier rubric determines which endpoints receive scenario-based reviews and drives the per-tier drift-detection cadence.
• Supports / unblocks: IR-Endpoints L2 (drift detected here re-opens IR), ST-Endpoints L2 (scenario-based reviews feed the security test suite).

Desired Outcomes

• Every Critical-tier DR covers 3–5 specific threat scenarios from the TA-Endpoints library, with the decision tied explicitly to how the proposed design handles each scenario.
• SaaS-AI features cannot be enabled tenant-wide without a DR handoff confirming the enable workflow, approval chain, data-scope declaration, and drift-detection hook are in place.
• Design drift is detected quarterly for Critical-tier and annually for High-tier; material drift automatically re-opens the DR record.
• Fewer IR-stage surprises, drift caught at the design review or drift-detection phase rather than at implementation review or incident.

Activities

A) Scenario-based reviews for Critical and High-tier endpoints

For every Critical-tier endpoint, the full-lane checklist walkthrough is replaced by a scenario walkthrough:

• Source 3–5 specific threat scenarios from the TA-Endpoints per-artifact deep threat model and from the TA-Endpoints archetype library. Scenarios must be specific to this endpoint's declared tool set, data classes, user population, and output-integrity-critical paths, not generic archetype scenarios.
• Walk each scenario: "If an adversary does X at this endpoint, does the proposed design have a control that prevents or detects it? Where? What is the residual risk?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry.
• Scenario sources: TA-Endpoints per-artifact deep threat model; anonymized IM-Endpoints incidents from the same archetype; MITRE ATLAS technique candidates relevant to the endpoint's primary control surface; OWASP MASVS (mobile), OWASP Browser-Extension Top 10 (browser tool), OWASP LLM / Agentic Top 10 (chatbot / AI assistant) entries relevant to the archetype.
• For High-tier endpoints: standard full-lane review augmented with at least one scenario from the TA archetype library; not a full scenario walkthrough.

B) SaaS-admin handoff review for tenant-wide AI feature enablement

Before any SaaS-AI feature (Copilot, Notion AI, Slack AI, Workspace AI, or equivalent) is enabled tenant-wide:

• A dedicated DR handoff review confirms: the enable workflow is documented (who approves, who executes, what constitutes an authorized enablement event); the data scope for the feature is declared (which workspace content the AI feature can access and which is excluded); conditional enablement is configured where possible (role-scoped or group-scoped, not all-tenants by default); the admin-audit log is confirmed to capture the enablement event; a drift-detection hook is in place to flag unauthorized or silent re-enablement.
• The DR decision record for SaaS-AI features explicitly identifies the admin-console states that constitute the "approved posture," so that IR-Endpoints L2 can compare live admin-console state against the record.
• Where the SaaS vendor does not expose admin-API controls for the feature, the DR record notes this gap as a residual risk with a named owner and a compensating control (e.g., contractual commitment, manual quarterly audit).

C) Design-drift detection

Compare the live endpoint posture against its approved DR design at the published cadence:

• Critical-tier: quarterly drift check. Sources checked: MDM policy state (DLP rules active, extension allowlist enforced, AI assistant scope matches design); browser admin policy state (extension allowlist enforced; per-extension scope honored); SaaS admin state (which AI features enabled per tenant / role matches design); chatbot Art. 50 disclosure still rendered (sample-check live UX); mobile app version and local-model signature current; edge device firmware and model signature current.
• High-tier: annual drift check using the same sources.
• Material drift (DLP scope widened, new AI feature enabled tenant-wide without DR, Art. 50 disclosure removed, tool-allowlist changed, managed-endpoint requirement dropped) automatically re-opens the DR record and routes back through the appropriate lane.
• Drift check produces a written artifact: the diff between approved design and live configuration, each delta classified as material / non-material, material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2)

Process Metrics (leading)

• Scenario library from TA-Endpoints refreshed quarterly; scenario content aligned to current TA-Endpoints per-artifact models.
• Drift-detection tooling health monitored, staleness alert if a Critical endpoint has no drift check in the last 90 days.
• SaaS-AI feature intake queue maintained; no tenant-wide enablement proceeds without a queued or completed DR handoff.
• Reviewer population trained on scenario-based walkthrough technique.

Effectiveness Metrics (business value)

• Fewer IR-stage surprises, drift caught pre-IR, not post-deployment.
• Scenario-driven reviews produce more specific approve-with-conditions lists; conditions are more actionable than checklist items.
• SaaS-AI feature DR handoffs reduce silent-enablement incidents where AI features access workspace content beyond their intended scope.

Success Criteria

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• SaaS-AI handoff review process operational; 100% of tenant-wide AI feature enablements in the last 90 days have a prior DR record.
• Design-drift detection operating for Critical (quarterly) and High (annual) endpoints; 100% of material drifts re-routed to DR.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

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

At this level, Critical-tier endpoints attest continuously rather than being reviewed periodically. MDM telemetry, browser-policy compliance scans, and SaaS-admin compliance feeds produce a daily signal that the endpoint's configuration remains within the bounds of the approved design. Pattern drift opens a DR-exception ticket automatically. Review rubrics, scenario templates, and pattern-evolution frameworks are contributed to CSA endpoint working groups, OWASP MASVS, and OASIS standards bodies. Pattern evolution is driven by external signals (MITRE ATLAS updates, sector ISACs, IM-Endpoints incidents) and internal signals (ML-Endpoints telemetry, ST-Endpoints red-team findings) on a quarterly cadence.

Dependencies

• DR-Endpoints L2 (required): scenario reviews, SaaS-admin handoff, and drift detection must be established before automation is trustworthy.
• SA-Endpoints L3 (required): externalized patterns supply the attestation frame; automated compliance scans verify against the published pattern.
• ML-Endpoints L2+ (required): monitoring signals (MDM telemetry, logging completeness, SaaS-admin event feeds) feed the continuous attestation pipeline.
• IM-Endpoints L2+ (required): incidents auto-trigger DR re-examination; the IM → DR feedback loop must be operational before L3 automation is meaningful.

Desired Outcomes

• Critical-tier endpoints' design posture is readable from a daily attestation signal, reviewers handle exceptions and novel configurations, not routine checks.
• Pattern evolution is driven quarterly by external signals (ATLAS, ISACs) and internal signals (IM-Endpoints, ML-Endpoints, ST-Endpoints) with a traceable change log.
• Review rubrics and scenario templates are published externally and adopted by peer organizations; the program contributes to the AI-assurance endpoint design-review ecosystem.
• DR review backlog shrinks to exception and novel-architecture work.

Activities

A) Continuous design attestation via MDM, browser-policy, and SaaS-admin compliance scans

• Critical-tier endpoints produce a daily attestation signal covering: MDM policy compliance (DLP rules active and match approved design; extension allowlist enforced; managed-endpoint AI assistant scope confirmed); browser admin policy state (extension allowlist enforced; per-extension scope honored, sourced from Chrome / Edge / Safari admin APIs); SaaS admin compliance (AI features enabled per tenant / role match the DR-approved posture, sourced from M365 / Slack / Workspace / Notion admin APIs); chatbot Art. 50 disclosure rendered (automated probe confirms disclosure present in live UX); mobile app version and local-model signature current (sourced from mobile MDM); edge device firmware and model signature current (sourced from device attestation reports).
• Deviations from the approved design automatically open a DR-exception ticket in IM-Endpoints; the ticket is triaged within 3 business days.
• Attestation artifacts are machine-readable and regulator-consumable, EU AI Act Art. 9 risk-management evidence and deployer-duty records per Art. 26 are produced by the attestation pipeline without manual assembly.
• Human reviewers handle: novel endpoint configurations that do not fit existing attestation rules; accepted exceptions with documented rationale; escalations from the IM-Endpoints backlog.

B) Contribute review rubrics and scenario templates to industry

• Publish under Apache 2.0 or equivalent through CSA endpoint working groups, OWASP MASVS extensions (mobile and browser-based AI tools), OASIS AI assurance standards, or applicable sector bodies:
• Per-archetype AI/HAI endpoint design review rubric (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS tactics and OWASP MASVS controls).
• Scenario template library (scenario format, per-archetype examples for each of the seven endpoint archetypes, debrief rubric for calibration exercises).
• Pattern-evolution framework (how external signals, ATLAS updates, sector ISACs advisories, IM incidents, feed DR checklist and scenario updates on a quarterly cadence).
• Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked.
• Adoption tracked: citations, forks, direct acknowledgment from peer organizations or standards bodies.

C) Pattern evolution driven by external and internal signals

• Quarterly pattern-evolution review: 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) plus internal signals (IM-Endpoints incident patterns by archetype, ML-Endpoints telemetry anomalies, ST-Endpoints red-team findings) feed structured checklist and scenario library updates.
• Updates change-logged with signal provenance; downstream DR records for in-flight reviews notified of pattern changes that affect their archetype.
• Where a new ATLAS technique or IM incident reveals a checklist gap, the gap is propagated to SA-Endpoints and SR-Endpoints as well, the traceability chain from threat to requirement to design review is maintained.

Outcome Metrics (L3)

Process Metrics (leading)

• Attestation-scan health, % Critical endpoints producing a fresh attestation signal in the last 24 hours; staleness alert if any Critical endpoint silent for >48 hours.
• External-signal ingestion cadence, ATLAS, OWASP MASVS, and ISAC feeds processed monthly into the pattern-update queue.
• Contribution pipeline, ≥1 artifact in draft, in-review, or published at any time.
• Exception-queue freshness, DR-exception tickets triaged within 3 business days of opening.

Effectiveness Metrics (business value)

• Reviewer-hours per endpoint per year trending down quarter-over-quarter as continuous attestation absorbs routine design-check work.
• External adoption of published rubrics and scenario templates, citations from peer organizations, sector bodies, or regulators signal industry recognition.
• Critical-incident MTTR shortened because endpoint design posture is continuously visible; incident responders do not need to reconstruct the approved design from scratch during an incident.

Success Criteria

• Daily attestation operating for ≥90% of Critical-tier endpoints across MDM, browser-policy, and SaaS-admin compliance sources; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the pre-L3 routine review volume.
• Quarterly pattern-evolution cadence traceable to external (MITRE ATLAS, OWASP MASVS, ISACs) and internal (IM-Endpoints, ML-Endpoints, ST-Endpoints) signals with a versioned change log.

Key Success Indicators

Level 1: - Per-archetype AI/HAI Endpoints Design Checklists published and versioned, one per SM-Endpoints archetype (AI assistant on managed endpoint, browser-based AI tool, chatbot / conversational UI, multi-modal AI interface, SaaS-AI productivity feature, mobile AI app, edge AI device), each traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot; each archetype checklist includes its mandatory specific items (AI assistant: managed-endpoint requirement, tool-allowlist, audit-log; chatbot: prompt-injection defense, output filter, Art. 50 UX, escalation path; edge device: signed firmware, boot attestation, physical-tamper detection, remote-disable). - Two-lane review model operational (fast-lane ≤2 BD, full-lane ≤5 BD) with named lead reviewers per archetype trained on EG-Endpoints L1 practitioner curriculum. - ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record before deployment begins; every decision record includes the residual-risk list with named owner and expiry. - SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements automatically queue SA and SR reviews; every IM-Endpoints incident re-examines the DR record that approved the affected endpoint.

Level 2: - 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with 3–5 scenarios sourced from TA-Endpoints per-artifact deep models and anonymized IM-Endpoints incidents; the DR decision is tied to how the design handles each scenario. - SaaS-AI handoff review process operational; 100% of tenant-wide AI feature enablements backed by a prior DR record confirming enable-workflow, data-scope declaration, and drift-detection hook. - Design-drift detection operating quarterly for Critical and annually for High endpoints, using MDM telemetry, browser-policy state, SaaS-admin state, and device attestation sources; 100% of material drifts re-routed to DR. - IR-stage design surprises measurably fewer over consecutive quarters.

Level 3: - ≥90% of Critical-tier endpoints producing a daily automated attestation signal via MDM, browser-policy, and SaaS-admin compliance scans; deviations auto-open DR-exception tickets triaged within 3 business days. - ≥2 externally contributed review artifacts per year published to CSA endpoint, OWASP MASVS, or OASIS with documented adoption; internal practice aligned to published versions. - Quarterly pattern-evolution loop traceable to MITRE ATLAS, OWASP MASVS, sector ISACs, IM-Endpoints incidents, ML-Endpoints telemetry, and ST-Endpoints findings; versioned change log maintained. - Review backlog ≤7 days for non-exception items; attestation volume has replaced routine review work.

Common Pitfalls

Level 1: - ❌ Design review runs after the deployment team has already rolled out the AI feature, the checkpoint loses leverage because rework cost is already sunk; the review becomes a retrospective, not a gate. - ❌ Checklists are identical across archetypes, the chatbot checklist does not include prompt-injection defense or Art. 50 UX because it was copy-pasted from the AI assistant checklist. - ❌ Fast-lane becomes the default for everything, customer-facing chatbots and regulated-data endpoints slip through with a 15-minute async check rather than the full-lane architect session they require. - ❌ Approve-with-conditions is issued but conditions have no named owner and no expiry date, conditions sit unresolved at go-live with no enforcement path. - ❌ Residual-risk list is blank because the reviewer does not want to document risk, the design record understates real exposure. - ❌ DR decision records are not linked to the SM-Endpoints inventory record, the program cannot answer "was this endpoint reviewed?" without a manual search. - ❌ Art. 50 disclosure requirement is listed in the checklist but marked as not-applicable for a customer-facing chatbot without documented reasoning.

Level 2: - ❌ "Scenario-based" review is the same checklist read aloud in a meeting, same items, different format; the scenario-to-design-control mapping is never actually performed. - ❌ SaaS-AI handoff review exists on paper but SaaS platform admins enable AI features directly from vendor dashboards without routing through DR, the intake step is bypassed. - ❌ Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live endpoint posture has diverged. - ❌ Scenario library is not refreshed quarterly, scenarios pulled from a 12-month-old TA snapshot do not reflect the current TA-Endpoints per-artifact model or recent IM-Endpoints incidents. - ❌ Per-tier drift-detection cadence exists on paper but the MDM / browser-policy / SaaS-admin compliance checks were never configured to produce structured diff outputs.

Level 3: - ❌ Attestation signals show green across all Critical endpoints but the underlying checks cover only MDM enrollment status, DLP scope, extension-allowlist enforcement, and Art. 50 disclosure presence are not checked; attestation is cosmetic. - ❌ Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed endpoints 18 months ago; peer adopters find inconsistencies when comparing the rubric to actual DR records. - ❌ Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every minor MDM policy update opens a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - ❌ Industry contributions are conference talks describing the program, no technical artifacts (rubrics, scenario templates, pattern-evolution frameworks) land in OWASP MASVS / CSA / OASIS with documented adoption.

Practice Maturity Questions

Level 1: 1. Is there a published, versioned per-archetype AI/HAI Endpoints Design Checklist, one per SM-Endpoints archetype (AI assistant 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 reference pattern, SR requirements pack, and TA threat snapshot, with archetype-specific items covering managed-endpoint requirement, tool-allowlist, DLP scope, vendor no-train probing, Art. 50 disclosure, kill-switch path, and affected-persons rights surface? 2. Do ≥95% of AI/HAI-enabled endpoints going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before deployment begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Endpoints L1, and a residual-risk list with named owner and expiry in every record? 3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA pattern-update and SR pack-update reviews, and does every IM-Endpoints incident trigger a re-examination of the DR record that approved the affected endpoint?

Level 2: 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Endpoints per-artifact deep models and anonymized IM-Endpoints incidents, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? 2. Is a SaaS-AI handoff review required before every tenant-wide AI feature enablement, confirming the enable workflow, approval chain, per-feature data-scope declaration, conditional-enablement configuration, and drift-detection hook are in place and documented in the DR record? 3. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using MDM telemetry, browser admin policy state, SaaS admin audit feeds, mobile MDM, and edge device attestation reports, with 100% of material drifts automatically re-routed to DR for a new review?

Level 3: 1. Are ≥90% of Critical-tier AI/HAI-enabled endpoints producing a daily automated attestation signal, checking MDM policy compliance, browser-policy enforcement, SaaS-admin feature state, Art. 50 disclosure presence, and device signature currency, with deviations auto-opening DR-exception tickets triaged within 3 business days? 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CSA endpoint working groups, OWASP MASVS, or OASIS, with documented adoption and internal practice aligned to the published versions? 3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS updates, OWASP MASVS revisions, sector ISAC advisories) and internal signals (IM-Endpoints incidents, ML-Endpoints telemetry, ST-Endpoints findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes?

Document Version: HAIAMM v3.0 Practice: Design Review (DR) Domain: Endpoints Last Updated: 2026-05-14 Author: Verifhai