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

Design Review (DR) - Data Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Design Review (DR) Domain: Data Purpose: Assess organizational maturity in operating the design checkpoint between intake approval and pipeline build-out for every new AI/HAI data flow, confirming SA-Data pattern adherence, SR-Data coverage, consent basis, and documented residual risks before engineering 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-Data Score = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every new AI/HAI data flow before pipeline build-out, producing a written decision traceable to the SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot

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

Q1.1: Is there a published, versioned per-archetype AI/HAI Data Design Checklist, one per SM-Data archetype (training corpus, inference input stream, retrieval store, prompt/completion log corpus, embedding store, fine-tuning dataset, evaluation/test set), traceable to the applicable SA-Data reference pattern, SR-Data requirements pack, and TA-Data threat snapshot?

Q1.2: Do training-corpus and fine-tuning-dataset checklists specifically cover DPIA trigger assessment, poison-detection scan scheduling, data minimization scope review, and opt-out-path design; and does the inference-input-stream checklist cover PII-redaction-edge design and no-train probe target?

Q1.3: Does the common spine of each checklist cover classification labeling, lineage/provenance, consent/lawful basis, retention policy, cross-border transfer mechanism, encryption at rest and in transit, access-control model, DSAR surface, and classification-label propagation?

Evidence Required: - [ ] Per-archetype checklist set published and version-controlled, one file or section per SM-Data archetype with an explicit version stamp - [ ] Training-corpus and fine-tuning-dataset checklists include all four mandatory items: DPIA trigger assessment, poison-detection scan scheduling, data minimization scope review, opt-out-path design - [ ] Inference-input-stream checklist includes PII-redaction-edge design and no-train probe target - [ ] Each checklist item carries an evidence pointer traced to a specific SA-Data pattern control or SR-Data requirement - [ ] Common spine items (classification labeling, lineage, consent basis, retention, cross-border transfer, encryption, access control, DSAR surface, classification propagation) present across all seven checklists - [ ] Named lead reviewer per archetype confirmed; DPO schedule reserved for personal-data full-lane reviews

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % AI/HAI data flows going to production with a completed DR decision record before build-out | % | % | ≥95% | ☐ | SM-Data inventory × DR records | | % DR records referencing the applicable SA-Data reference pattern and SR-Data 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 data flows reaching production with a dated DR decision record predating pipeline build-out start, divided by total data flows promoted to production. Source: SM-Data inventory joined to DR record store. Measured quarterly. - Pattern and REM reference rate: Inspect DR records for a hyperlink or identifier referencing the SA-Data reference pattern and SR-Data REM. Automated field validation preferred; manual spot-check acceptable at L1. - Fast-lane SLA: P50 of (DR decision date − review submission date) for fast-lane reviews. Source: review-tracking system timestamps. - Full-lane SLA: P50 of same calculation for full-lane reviews. Track DPO acknowledgment date separately for personal-data flows.

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, DPIA Trigger Identification, and Decision Records

Q2.1: Is a two-lane routing model operational, fast-lane (Low/Medium tier, on-pattern, no cross-border, no DPIA trigger, ≤2 BD) and full-lane (High/Critical tier, cross-border flow, regulated data class, DPIA trigger, or pattern deviation, ≤5 BD with DPO acknowledgment for personal-data flows), with routing criteria published and applied consistently?

Q2.2: Are DPIA triggers identified at design time, not post-deployment, and documented in the DR record with DPIA status and linked evidence?

Q2.3: Does every DR decision record contain: decision (approve / approve-with-conditions / send-back); checklist with evidence pointers; deviations with rationale; residual risks with named owner and expiry; DPO acknowledgment for personal-data flows; links to SM-Data inventory, TA-Data threat snapshot, SR-Data REM, and DPIA if triggered?

Evidence Required: - [ ] Routing criteria document specifying which tier/archetype/cross-border/DPIA combinations trigger full-lane vs. fast-lane - [ ] Decision record template with all required fields used consistently for the last 10 reviews (sample auditable) - [ ] DPIA trigger assessment embedded in the checklist for applicable archetypes (training corpus, fine-tuning dataset, inference input stream with regulated data) - [ ] Sample of ≥5 decision records showing DPO acknowledgment for personal-data flows - [ ] Approve-with-conditions items in a trackable backlog with named owner and expiry date per item - [ ] Evidence that DPIA triggers were identified at DR (not post-deployment) for at least one data flow in the last 12 months

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | DPIA triggers identified at DR vs. discovered post-deployment | % at-DR | % at-DR | trending toward 100% at-DR | ☐ | DR records × DPIA register | | 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: - DPIA at-DR rate: Count DPIAs for AI/HAI data flows where the DR decision record predates the DPIA registration date, divided by total DPIAs for AI/HAI data flows. Source: DR record store joined to DPIA register. Measured quarterly. - Approve-with-conditions aging: Query action-item backlog for items where (today − condition creation date) > 60 days and status is not resolved. Measured weekly.

Evidence Location	Validation Date	Notes

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

Q3.1: Are recurring pattern deviations and repeatedly-waived SR-Data requirements automatically queuing SA-Data pattern-update and SR-Data 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-Data incident trigger a re-examination of the DR decision record that approved the affected data flow, asking which checklist item would have caught the issue, and updating the checklist accordingly?

Q3.3: Are completed DPIAs linked back to the DR record, with DPIA findings requiring design changes routed back through the checklist before build-out proceeds?

Evidence Required: - [ ] Documented trigger rule: three same-direction deviations per archetype auto-queues SA-Data pattern-update review - [ ] SA-Data pattern-update queue and SR-Data pack-update queue showing items from DR feedback in the last 12 months - [ ] IM-Data 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-Data incident finding (before/after version comparison available) - [ ] DPIA feedback loop confirmed: at least one DPIA finding routed back to DR for checklist revision in the last 12 months - [ ] Pattern-deviation rate by archetype surfaced in a regular program review in the last quarter

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % DR records referencing the applicable SA-Data reference pattern and SR-Data REM | % | % | 100% | ☐ | DR records | | SA/SR update items queued from DR feedback in last 12 months | ___ | ___ | ≥1 | ☐ | SA/SR update queues | | % IM-Data 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-Data or SR-Data update queues whose "source" field references DR feedback. Measured quarterly. - IM incident DR re-examination: Review IM-Data incident records and confirm each has a linked DR record with a re-examination finding. Track as percentage. Measured after each incident closes.

Evidence Location	Validation Date	Notes

Maturity Level 2

Objective: Upgrade Critical-tier data-flow reviews to scenario-based walkthroughs driven by TA-Data per-flow models, detect design drift on a published cadence, and run joint DR-Data / DR-Software reviews for Critical-tier data flows feeding first-party AI artifacts

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

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

Q4.2: Are scenario sources refreshed quarterly from TA-Data per-flow deep models, MITRE ATLAS data-attack techniques (AML.T0018 Backdoor ML Model, AML.T0019 Poison Training Data, AML.T0025 Model Inversion, AML.T0037 Data from Information Repositories), and OWASP LLM entries relevant to the archetype?

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

Evidence Required: - [ ] DR records for Critical-tier data flows showing scenario-based walkthrough format with ≥3 named scenarios per review, each specific to the flow's data classes and consumer artifacts - [ ] Each scenario in the record maps to a design control or an accepted residual risk with named owner and expiry - [ ] Scenario library version-controlled with quarterly refresh dates and ATLAS technique citation provenance (AML.T IDs listed) - [ ] TA-Data per-flow deep threat model referenced in each Critical-tier DR record - [ ] High-tier DR records showing at least one augmenting scenario from the TA-Data archetype library - [ ] Reviewer population trained on scenario-based walkthrough technique including ATLAS data-attack techniques

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier DR records using scenario-based walkthrough | % | % | 100% | ☐ | DR records | | % Critical/High-tier data flows with drift check on published cadence | % | % | ≥95% | ☐ | Drift-check schedule × SM-Data 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 or IM-Data citations, divided by total Critical-tier DR records. Measured quarterly. - IR-stage surprises: Count IR findings with no corresponding DR condition for the same artifact. Source: IR records joined to DR records by artifact ID. Trend tracked quarter-over-quarter.

Evidence Location	Validation Date	Notes

Question 5: Design-Drift Detection for Data Flows

Q5.1: Is design-drift detection operating quarterly for Critical-tier and annually for High-tier data flows, using data-catalog change webhooks (Atlan / Collibra / DataHub / Unity Catalog), pipeline-metadata changes (Airflow / dbt / Fivetran), lineage-graph changes, classification-label-scan deltas (Macie / BigID / Purview), and cross-border-routing changes?

Q5.2: Are material drift findings (new data source added, classification scheme changed, cross-border routing changed, new consumer added, retention policy changed, DSAR-surface changed) automatically re-opening the DR record and routing back through the appropriate lane?

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

Evidence Required: - [ ] Drift-detection schedule showing Critical data flows checked quarterly and High data flows annually - [ ] Drift check artifacts (written diffs) for ≥3 Critical-tier data flows in the last 12 months - [ ] Classification criteria defining which delta types are material vs. non-material for data flows - [ ] At least one material drift finding that re-opened a DR record and routed to a new review - [ ] Staleness alert configuration confirmed (Critical data flow silent for >90 days triggers alert) - [ ] Drift-detection sources confirmed wired: data catalog webhooks, pipeline metadata, lineage graph, classification scan deltas, cross-border routing

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical/High-tier data flows with drift check on published cadence | % | % | ≥95% | ☐ | Drift-check schedule × SM-Data 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 data flows with a documented drift check in the last 90 days, divided by total Critical data flows in SM-Data 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

Question 6: Joint DR-Data / DR-Software Reviews for Critical-Tier Data Flows

Q6.1: Are joint DR-Data / DR-Software review records on file for 100% of Critical-tier data flows feeding first-party AI software artifacts, with the handoff boundary (data-pipeline team responsibilities vs. AI-software team responsibilities) documented in both records?

Q6.2: Do both records share residual-risk ownership, with risks spanning both the data flow and the AI artifact named in both records and assigned to a single named resolution owner?

Q6.3: Where a first-party AI artifact is new and no DR-Software record exists, does DR-Data hold the Sanctioned status until DR-Software completes?

Evidence Required: - [ ] Joint review calendar or coordination log showing DR-Data and DR-Software reviewers attending the same session for Critical-tier flows - [ ] DR-Data decision records for Critical-tier flows referencing the corresponding DR-Software record identifier - [ ] Handoff boundary explicitly documented in both records (pipeline controls vs. AI artifact controls) - [ ] Shared residual risks noted in both records with a single named resolution owner - [ ] Sanctioned-status hold mechanism confirmed, no Critical-tier data flow with a new AI artifact consumer advanced without a DR-Software record on file - [ ] Cross-domain coordination channel with DR-Software established

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier data flows feeding first-party AI artifacts with a joint DR-Data / DR-Software record | % | % | 100% | ☐ | DR records × software integration tracker | | % 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: - Joint record coverage: Count Critical-tier data flows with a consumer AI artifact that have a paired DR-Software record identifier in their DR-Data record, divided by total such flows. Source: DR record store joined to software integration tracker. Measured quarterly. - Shared residual risk completeness: Spot-check 5 joint reviews per quarter, verify shared residual risks appear in both records with a single named resolution owner.

Evidence Location	Validation Date	Notes

Maturity Level 3

Objective: Operate continuous design attestation via automated SA-Data-pattern-compliance scans, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to OpenSSF AI Data, DAMA, EDM Council, and CSA

Question 7: Continuous Design Attestation via SA-Data-Pattern-Compliance Scans

Q7.1: Are ≥90% of Critical-tier AI/HAI data flows producing a daily automated attestation signal, checking catalog-metadata currency, lineage-graph bounds, consent-basis currency, retention-enforcement status, encryption-key-vault binding, and cross-border routing, with deviations automatically opening DR-exception tickets triaged within 3 business days?

Q7.2: Are attestation artifacts machine-readable and regulator-consumable, producing GDPR Art. 35 DPIA evidence, EU AI Act Art. 10 data-governance records, and ISO/IEC 42001 AIMS operational records without manual assembly?

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

Evidence Required: - [ ] Attestation pipeline configuration showing daily scan cadence for Critical-tier data flows - [ ] Coverage report: % of Critical-tier flows producing a fresh attestation signal in the last 24 hours - [ ] Sample attestation artifact covering all six check domains: catalog metadata, lineage graph, consent basis, retention enforcement, encryption key vault, cross-border routing - [ ] 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 data flow silent for >48 hours triggers alert)

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % Critical-tier data flows 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 data flows with a completed attestation scan in the last 24 hours, divided by total Critical data flows. 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. Source: JIRA / Linear. Measured weekly. - Review backlog age: P90 age of non-exception review queue items. Source: review-tracking system. 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 data design rubrics, scenario templates keyed to AML.T data-attack techniques, pattern-evolution frameworks) to OpenSSF AI Data, DAMA International, EDM Council, or CSA AI Safety Initiative, 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, GitHub forks, or direct acknowledgment from peer organizations or standards bodies?

Evidence Required: - [ ] Contribution log showing ≥2 published artifacts in the last 12 months - [ ] Publication links (Apache 2.0 or equivalent license) to OpenSSF AI Data, DAMA, EDM Council, or CSA - [ ] 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 data flows 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 and attributed to this organization. Measured annually. - Adoption evidence: Log citations and forks quarterly. AML.T technique coverage in the published scenario templates tracked as a completeness signal.

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 data-attack techniques AML.T0018/AML.T0019/AML.T0025/AML.T0037; GDPR enforcement decisions; sector ISAC advisories; OWASP LLM / Agentic Top 10 revisions) and internal signals (IM-Data incident patterns by archetype, ST-Data findings, ML-Data telemetry anomalies), 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-Data incident reveals a checklist gap, is the gap propagated to SA-Data and SR-Data 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 AML.T ID, GDPR enforcement reference, or IM-Data incident ID) for each update - [ ] Evidence that AML.T data-attack techniques (AML.T0018/AML.T0019/AML.T0025/AML.T0037) were reviewed in the last quarter - [ ] In-flight DR review notifications sent when a pattern change affected the archetype under review - [ ] SA-Data and SR-Data update items queued from pattern-evolution checklist gaps - [ ] ATLAS 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 data flows 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 AML.T ID, GDPR enforcement case 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 Data Design Checklist	L1
Q2: Two-Lane Routing, DPIA Triggers, Decision Records	L1
Q3: Loop-back to SA-Data / SR-Data / IM-Data	L1
Q4: Scenario-Based Reviews (Critical/High)	L2
Q5: Design-Drift Detection	L2
Q6: Joint DR-Data / DR-Software Reviews	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-Data 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: Data 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