Issue Management (IM) - Data Assessment

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

v3.0 rewrite: The canonical framing for the Data domain is Issue Management, unified backlog, tier-calibrated incident playbook, and regulatory SLA tracking for AI/HAI data issues. The fully v3.0 source-of-truth is ../practices/IM-Data-OnePager.md. Canonical subject and through-lines: ../HAIAMM-v3.0-Framing.md. Primary tactic: MITRE ATLAS TA0014 Impact / TA0013 Exfiltration.

Issue Management (IM) - Data Domain

HAIAMM Assessment Questionnaire v3.0

Practice: Issue Management (IM) Domain: Data Purpose: Assess organizational maturity in operating a unified AI/HAI data issue backlog, AI-specific data incident playbook, and regulatory SLA tracker covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, and state privacy laws 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

Each question is scored on a 4-tier scale:

Score	Label	Criteria
1.0	Fully Mature	Evidence complete + ≥3 outcome metrics meet targets
0.67	Implemented	Evidence complete + 2 outcome metrics meet targets
0.33	Partial	Evidence partially complete + <2 metrics meet targets
0.0	Not Implemented	No evidence of the practice

Level Score = Average of question scores within the level Overall IM-Data Score = Weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

Maturity Level 1

Objective: Operate a single unified AI/HAI data issue backlog with a standard triage rubric, AI-specific data incident playbook including containment plays for the primary data incident classes, and regulatory SLA tracking for GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, and state privacy law obligations

Question 1: Unified AI/HAI Data Issue Backlog and Triage Rubric

Q1.1: Is there a single AI/HAI data issue backlog with standardized metadata (source, affected data asset linked to SM-Data inventory, archetype, severity rubric anchored to AI-specific data axes, confirmed regulated-data exfiltration / training corpus poisoning confirmed / DSAR fulfillment failure / cross-border flow without legal mechanism for Critical; confirmed control failure with potential data exposure for High, etc., owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA-Data, SR-Data, DR-Data, IR-Data, ST-Data, ML-Data, external)?

Evidence Required: - [ ] Single backlog record showing standardized metadata: Source (TA-Data/SR-Data/DR-Data/IR-Data/ST-Data/ML-Data/External), Affected data asset linked to SM-Data inventory with archetype and classification tier, Severity per AI-specific data rubric, Owner, SLA, Regulatory flag (GDPR Art. 33/34, EU AI Act Art. 73, HIPAA, NYDFS, state privacy law), Evidence link - [ ] Triage rubric document with AI-specific data severity anchors: Critical (regulated-data exfiltration confirmed, training corpus poisoning confirmed, DSAR cannot be fulfilled within statutory window, cross-border flow of regulated data without legal mechanism, GDPR Art. 33 personal data breach), High (confirmed control failure with potential data exposure), Medium, Low - [ ] Backlog coverage audit showing ≥95% of AI/HAI data issues from all source practices vs. reconciliation from practice queues - [ ] Triage cadence records: daily Critical/High review, weekly Medium, monthly aging, confirming cadence for last 90 days - [ ] SLA targets published: Critical acknowledge ≤4h / contain ≤48h / root-cause ≤30d; High ≤24h/7d/45d; Medium ≤48h/14d; Low ≤5bd/30d - [ ] Monthly aging dashboard delivered to program sponsor showing open issues by SLA bucket and classification tier

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI data issues in single backlog vs. scattered queues | % | % | ≥95% | ☐ | | | % of backlog issues with complete standardized metadata | % | % | ≥95% | ☐ | | | % of Critical/High data issues acknowledged within SLA | % | % | 100% | ☐ | | | Monthly aging report delivered to sponsor on schedule | ___ / 12 | ___ / 12 | 12 / 12 | ☐ | |

Metric Collection Guidance: - Backlog coverage: Monthly reconciliation, count issues in single backlog vs. sum from all source practices. Formula: backlog_issues / total_issues_filed × 100 - Metadata completeness: Spot-audit 20 random tickets per month; all required fields populated. Source: backlog export - SLA acknowledgement: data_issues_acknowledged_within_SLA / total_new_Critical_High × 100. Source: backlog timestamps. Measured weekly - Aging report cadence: Count sponsor-facing aging reports delivered per calendar year. Source: program reporting calendar

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 unified data issue backlog)

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 2: AI-Specific Data Incident Playbook, Seven Data Containment Plays

Q1.2: Is the AI/HAI data incident playbook published with seven named AI-specific data incident classes (training corpus poisoning / dataset quarantine + model rollback, retrieval store extraction, embedding inversion, prompt/completion log corpus breach, cross-border flow violation, consent-withdrawal not propagated, DSAR fulfillment failure), each with pre-assigned roles, containment plays, evidence-capture steps, and SLA targets, and has each class been exercised in at least one tabletop in the last 12 months?

Evidence Required: - [ ] Playbook document with seven named AI-specific data incident entries published and version-controlled: (1) training corpus poisoning, dataset quarantine, pipeline service-account access revocation, model rollback to previous clean version in model registry, eval-harness replay, lineage audit; (2) retrieval store extraction, store disable, classification-gated query allowlist, GDPR Art. 33 evaluation; (3) embedding inversion, bulk-export lockdown, inversion-defense mechanism (noise injection, dimensionality reduction), GDPR Art. 33/34 assessment; (4) prompt/completion log corpus breach, export-access disable, scope assessment, GDPR Art. 33 evaluation; (5) cross-border flow violation, replication disable, transfer-mechanism assessment (SCC/adequacy/BCR), supervisory-authority notification assessment; (6) consent-withdrawal not propagated, training-set audit using lineage registry, deletion/exclusion events, model rollback evaluation; (7) DSAR fulfillment failure, Privacy/Legal escalation, manual-fulfillment path, Art. 12 extension notification if needed - [ ] Each entry: trigger conditions, named roles (data-asset owner, Privacy/Legal, executive sponsor), step-by-step containment, artifacts to collect, evidence-capture instructions, closure criteria, SLA targets - [ ] Tabletop exercise records for each of the seven classes within last 12 months (minimum one per quarter, rotating) - [ ] Dataset deny-list maintenance procedure: poison-detected sources added; reviewed quarterly - [ ] DSAR fulfillment path tested: at least one full-cycle DSAR drill executed in last 12 months with export path confirmed functional within 30-day statutory window

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | % of AI/HAI data incidents handled on a published playbook entry | % | % | 100% | ☐ | | | Tabletop exercises covering data incident classes per year | ___ | ___ | ≥4 (rotating) | ☐ | | | DSAR fulfillment drill completed and export path confirmed functional | Yes/No | Yes/No | Yes | ☐ | | | Consent-withdrawal propagation SLA adherence (≤30 days to deletion/exclusion) | % | % | 100% | ☐ | |

Metric Collection Guidance: - Playbook coverage: data_incidents_handled_on_named_playbook / total_data_incidents × 100. Source: incident records. Per incident - Tabletop cadence: Count tabletop exercises per year with documented scenario coverage. Source: tabletop exercise log - DSAR drill: Annual confirmation of SM-Data inventory query + data-asset export path within 30-day window. Source: DSAR drill record - Consent propagation: consent_withdrawals_propagated_within_30d / total_consent_withdrawals × 100. Source: consent-management system × training-dataset audit log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Q1.3: Is the regulatory SLA tracker live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), and applicable state privacy laws, with 100% adherence in the last 90 days, and does every Critical/blocker data incident produce a post-incident review within 14 days with named update outputs flowing to SA-Data, SR-Data, EG-Data, and ML-Data?

Evidence Required: - [ ] Regulatory SLA tracker covering: GDPR Art. 33 (72h, Privacy/Legal owner, clock starts at first ML-Data detection or IR-Data finding), GDPR Art. 34 (Art. 34 high-risk assessment triggered simultaneously with Art. 33 notification decision), EU AI Act Art. 73 (immediate escalation for Annex III data asset incidents), HIPAA (60d, PHI incidents), NYDFS Part 500 (72h), PCI-DSS (cardholder data breach), state privacy laws (CCPA/CPRA and applicable state breach notification SLAs) - [ ] GDPR Art. 33 clock-start protocol: named owner confirms start-time documentation on first ML-Data detection; daily status updates until notification filed or clock expires; no missed windows in last 90 days - [ ] Art. 34 assessment procedure: high-risk-to-data-subject evaluation completed and documented within 24 hours of Art. 33 notification for each qualifying data incident - [ ] Post-incident review records for all Critical/blocker data incidents in last 12 months: root cause, what caught it, what did not, four update outputs (SA-Data pattern update, SR-Data requirements update, EG-Data training update, ML-Data detection update) all populated and tracked as IM-Data improvement issues

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Regulatory SLA adherence (0 missed notifications) in last 90 days | ___ | 0 missed | 0 missed | ☐ | | | Post-incident reviews completed within 14 days of Critical/blocker closure | % | % | 100% | ☐ | | | SA/SR/EG/ML-Data update outputs tracked and resolved (% Critical reviews with ≥1 output per target) | % | % | 100% | ☐ | | | Median closure time for Critical AI/HAI data incidents (root-cause) | ___ days | ___ days | ≤30 days | ☐ | |

Metric Collection Guidance: - Regulatory SLA adherence: Count qualifying data incidents where notification was filed within the applicable window. Zero missed = 100% adherence. Source: SLA tracker. Reviewed weekly - Review timeliness: data_reviews_within_14d / total_Critical_blocker_closures × 100. Source: review records with timestamps - Update output completion: For each Critical data review, verify all four downstream outputs exist and are tracked in IM-Data improvement issues - MTTR: Median days from incident creation to root-cause record filed. Source: backlog aging. Calculated monthly

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 2

Objective: Calibrate incident response depth per SM-Data L2 risk tier; establish dedicated on-call rotation for Critical-tier data assets; and automate cross-domain signal flow so that Data domain incidents affecting Software, Infrastructure, or Processes generate coordinated response

Question 4: Tier-Calibrated Data Incident Playbook and 24/7 On-Call

Q2.1: Is a tier-calibrated data incident playbook operational with Critical-tier MTTA ≤1 hour and MTTC ≤4 hours, 24/7 on-call coverage with a documented rotation including a current Critical-tier data asset briefing with archetype-specific containment paths, and tier-movement in the SM-Data inventory automatically triggering IM-Data configuration updates within 14 days?

Evidence Required: - [ ] Tier-calibrated activation criteria: Critical (CISO + Privacy/Legal + data-asset owner + executive sponsor, ≤1h MTTA, ≤4h MTTC, 24/7, pre-staged supervisory-authority notification drafts), High (Privacy/Legal + data-asset owner, ≤4h MTTA, ≤24h MTTC), Medium (standard queue, ≤1bd), Low (weekly aggregated) - [ ] 24/7 on-call rotation registry: named individuals per week, handoff protocol, confirmed no-gap periods in last 90 days - [ ] On-call briefing (current version): Critical-tier data asset list with archetype-specific containment paths (training corpus, quarantine path; retrieval store, disable path; prompt/completion log, export-access disable path) - [ ] Tier-movement trigger: SM-Data inventory tier-change → IM-Data config update within 14 days for Critical re-tier; evidence from last 3 tier-movement events - [ ] Pre-staged communication templates reviewed quarterly including supervisory-authority notification draft for GDPR Art. 33 qualifying data incidents

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Critical-tier MTTA | ___ hr | ___ hr | ≤1 hour | ☐ | | | Critical-tier MTTC | ___ hr | ___ hr | ≤4 hours | ☐ | | | 24/7 on-call: no-gap periods in last 90 days | ___ gaps | ___ gaps | 0 gaps | ☐ | | | Tier-movement → IM-Data config update within 14 days (Critical re-tier) | % | % | 100% | ☐ | |

Metric Collection Guidance: - MTTA / MTTC: Measured from first ML-Data detection or backlog creation to acknowledged / contained for Critical-tier data incidents. Source: IM-Data telemetry. Per incident - On-call gaps: Count weeks in last 90 days with unassigned on-call period. Source: rotation registry. Monthly review - Tier-movement latency: Days from SM-Data tier-change to IM-Data config update. Target: ≤14 days for Critical re-tier. Source: SM-Data log × IM-Data config log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 5: Post-Incident Review Auto-Flow Integration

Q2.2: Is a post-incident review auto-flow integration live routing Critical-tier data review outputs to SA-Data/SR-Data/EG-Data/ML-Data practice backlogs, with ≥90% of downstream practice owners responding within 14 days and the sponsor reviewing output quality quarterly?

Evidence Required: - [ ] Integration configuration: auto-ticket creation for all four downstream data practices on Critical-tier review closure, SA-Data (architecture-backlog ticket), SR-Data (pack-backlog ticket with failing requirement row), EG-Data (training-backlog ticket with affected population), ML-Data (detection-registry ticket with detection name, current query, proposed change) - [ ] Sample auto-created tickets from last 3 Critical-tier data reviews showing correct metadata and incident reference linking - [ ] Downstream backlog aging data: auto-ticket timestamps vs. owner response within 14 days; ≥90% adherence over last 12 months - [ ] Quarterly sponsor review records: quality assessment distinguishing substantive (concrete update to architecture pattern, requirements pack, curriculum, or detection) from nominal acknowledgement - [ ] Accepted update outputs designated High-severity in receiving practice backlog, evidence in downstream tickets

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Post-incident review outputs auto-flowing to SA/SR/EG/ML-Data (% Critical reviews) | % | % | 100% | ☐ | | | Downstream practice owner response within 14 days | % | % | ≥90% | ☐ | | | Quarterly sponsor quality review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Substantive update output rate (sponsor-assessed) | % | % | ≥80% | ☐ | |

Metric Collection Guidance: - Auto-flow rate: Critical_data_reviews_with_all_4_auto_tickets / total_Critical_data_reviews × 100. Source: integration telemetry - Downstream response rate: update_tickets_responded_within_14d / total_update_tickets × 100. Source: downstream backlog aging. Monthly - Sponsor review cadence: Count quarterly reviews with documented quality assessment. Source: program calendar - Substantive rate: Sponsor-assessed: substantive_count / total_reviewed × 100

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 6: Cross-Domain Coordination Protocol

Q2.3: Is a cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI data incidents, with named cross-domain contacts for Software, Infrastructure, and Processes domains verified quarterly, a single IC from the primary impacted domain, and joint post-incident reviews spanning all affected domains?

Evidence Required: - [ ] Cross-domain coordination protocol: Data → Software (training corpus breach affects production models, activates Software-domain IM model-rollback play alongside Data corpus-quarantine and lineage-audit), Data → Infrastructure (storage misconfiguration exposes training corpus, activates Infrastructure EH and IM), Data → Processes (DSAR fulfillment failure reveals unmapped business-process data flows, activates Processes-domain privacy coordinator alongside Data DSAR escalation) - [ ] Named cross-domain contacts registry: Software-domain IM contact, Infrastructure-domain IM contact, Processes-domain IM contact, last verified within 90 days - [ ] Quarterly contact verification records (last 4 quarters): contacts confirmed reachable, communication channels tested - [ ] Multi-domain incident activation records: shared status board used, single IC from primary impacted domain, joint post-incident review spanning all affected domains - [ ] IC designation procedure: pre-defined IC assignment rules for cross-domain data incidents

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Cross-domain protocol used for 100% of multi-domain data incidents | % | % | 100% | ☐ | | | Cross-domain contact registry verified within last 90 days | Yes/No | Yes/No | Yes | ☐ | | | Joint post-incident reviews completed for multi-domain data incidents | % | % | 100% | ☐ | | | Quarterly contact verification on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | |

Metric Collection Guidance: - Protocol usage: multi_domain_data_incidents_using_protocol / total_multi_domain × 100. Source: incident coordination records - Contact currency: Date of last verification across all three domains. Target: within 90 days. Source: contact registry - Joint PIR: multi_domain_incidents_with_joint_PIR / total_multi_domain × 100. Source: PIR records - Verification cadence: Count quarterly contact verification events. Source: program calendar

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Maturity Level 3

Objective: Contribute data incident patterns and playbook templates to MITRE ATLAS, AVID, DAMA, and sector ISACs; automate runbook decisioning for high-confidence data detections; and benchmark MTTR against industry peers

Q3.1: Does the program contribute ≥4 anonymized AI data incident-classification entries per year to sector ISACs, ≥2 data vulnerability entries per year to AVID, and ≥1 contribution per year to MITRE ATLAS TA0014 Impact tactic documentation, with all contributions maintained current, legally vetted, and tracked for external adoption?

Evidence Required: - [ ] ISAC participation: sector ISAC membership (FS-ISAC AI WG, H-ISAC, IT-ISAC, or sector-specific); ISAC AI data incident feed integrated into IM-Data external-advisory source; ≥4 anonymized contributions per year (incident type, ATLAS tactic tag, data archetype, containment play used, regulatory SLA outcome, MTTR) - [ ] AVID submission records: ≥2 AI/HAI data vulnerability entries per year (training corpus poisoning methods, embedding inversion methods, consent-withdrawal propagation failures); maintenance log; legal sign-off per submission - [ ] MITRE ATLAS TA0014 Impact contribution: ≥1 per year for data-domain techniques (training-data poisoning, data exfiltration, consent-manipulation); contribution tracking log - [ ] DAMA contribution (if applicable): AI/HAI data incident response patterns or DSAR fulfillment escalation playbook templates contributed to DAMA AI data governance guidance - [ ] Legal vetting sign-offs and external adoption tracking log for all contributions

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | ISAC AI data incident contributions per year | 0 | ___ | ≥4 | ☐ | | | AVID data vulnerability entries submitted per year | 0 | ___ | ≥2 | ☐ | | | ATLAS TA0014 Impact data contributions per year | 0 | ___ | ≥1 | ☐ | | | External adoption events tracked | 0 | ___ | ≥1 | ☐ | |

Metric Collection Guidance: - ISAC contributions: Count anonymized data incident-classification submissions per year. Source: ISAC contribution log - AVID entries: Count entries created or materially updated per year. Source: AVID contribution log - ATLAS contributions: Count technique observations or mitigation entries submitted for data-domain tactics. Source: ATLAS contribution log - Adoption events: Count external citations or adoptions. Source: contribution tracking log. Semi-annual review

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 8: Pre-Authorized Automated Runbook Decisioning for Data Incidents

Q3.2: Are ≥3 pre-authorized automated data containment actions live (retrieval store bulk-query disable, pipeline service-account access revocation for quarantined datasets, cross-border replication disable, embedding store bulk-export disable), vetted by Privacy/Legal and the executive sponsor, producing 100% audit records plus human-review tickets, with the pre-authorization policy reviewed quarterly?

Evidence Required: - [ ] Pre-authorization policy: published list of ≥3 automated data containment actions with confidence thresholds (retrieval store bulk-query disable for Low/Medium-tier on extraction-attempt detection ≥90%; pipeline service-account revocation for quarantined dataset on poison-detection ≥95% and non-Critical-tier; cross-border replication disable on flow-violation detection; embedding store bulk-export disable for Low/Medium-tier on inversion-attempt detection ≥90%) - [ ] Legal/Privacy and executive sponsor sign-off records, dated and versioned - [ ] Critical-tier data asset handling: human confirmation within 15 minutes; timer-based fallback with executive notification - [ ] Automation execution log samples (5 records): each automated action produces audit log entry in IM-Data backlog, human-review ticket auto-created, notification to data asset owner - [ ] Quarterly policy review records (last 4 quarters); unexpected-outcome triggered out-of-cycle reviews within 5 business days

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | Pre-authorized automated data containment actions operational | 0 | ___ | ≥3 defined, vetted, live | ☐ | | | % actions producing full audit record + human-review ticket | % | % | 100% | ☐ | | | Quarterly policy review on schedule | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Unexpected-outcome out-of-cycle reviews within 5 business days | % | % | 100% | ☐ | |

Metric Collection Guidance: - Actions live: Count unique automated data containment action types defined, vetted, and deployed. Source: pre-authorization policy + deployment record - Audit completeness: automated_data_actions_with_audit_AND_ticket / total_automated_data_actions × 100. Source: automation telemetry - Policy review cadence: Count quarterly reviews completed. Source: review calendar - Out-of-cycle timeliness: reviews_within_5bd / total_unexpected_outcomes × 100. Source: out-of-cycle review log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Question 9: MTTR Benchmarking for Data Incidents

Q3.3: Is a quarterly MTTR benchmark brief published to the sponsor comparing the program's MTTR per data incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

Evidence Required: - [ ] MTTR benchmark data sources: sector ISAC AI data incident exchanges, BSIMM-style observational data, MITRE ATLAS practitioner community data, Privacy Officer / AI data-security peer roundtable inputs, at least two active; updated semi-annually - [ ] Quarterly MTTR benchmark brief (last 4 quarters): MTTR per data incident class (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log breach, cross-border flow violation, consent-withdrawal non-propagation, DSAR fulfillment failure) vs. benchmark; per tier vs. benchmark; delta trend - [ ] Investment-driver section: above-benchmark classes mapped to specific practice gap (missing detection, unclear playbook, on-call latency, DSAR infrastructure gap) with budget-linked improvement proposal - [ ] Quarterly brief delivery records (last 4 quarters on-time) - [ ] Benchmark data source refresh log: updated at least semi-annually; stale benchmarks flagged

Outcome Metrics: | Metric | Baseline | Current | Target | Met? | Notes | |--------|----------|---------|--------|------|-------| | MTTR benchmark brief published quarterly to sponsor | ___ / 4 | ___ / 4 | 4 / 4 | ☐ | | | Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes | ___ / 7 | ___ / 7 | ≥4 of 7 | ☐ | | | Above-benchmark classes with investment proposals | % | % | 100% | ☐ | | | Benchmark data source refresh within last 6 months | Yes/No | Yes/No | Yes | ☐ | |

Metric Collection Guidance: - Brief cadence: Count briefs delivered on schedule per year. Source: program reporting calendar - Benchmark performance: For each of 7 data incident classes, compare Critical-tier MTTR to benchmark. Count at or below. Source: MTTR brief. Quarterly - Investment proposals: above_benchmark_classes_with_proposal / total_above_benchmark × 100. Source: brief investment-driver section - Benchmark freshness: Date of most recent external data source update. Target: within 180 days. Source: benchmark refresh log

Evidence Location: _________

Metric Validation Date: _________

Notes: _______

Summary Scorecard

Question	Level	Activity	Score
Q1: Unified data issue backlog and triage rubric	L1	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q2: AI-specific data incident playbook (7 data plays)	L1	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q3: Regulatory SLA tracker and post-incident review loop	L1	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q4: Tier-calibrated data playbook and 24/7 on-call	L2	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q5: Post-incident review auto-flow integration	L2	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q6: Cross-domain coordination protocol	L2	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q7: ISAC / AVID / ATLAS / DAMA contributions	L3	A	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q8: Pre-authorized automated data runbook	L3	B	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0
Q9: MTTR benchmarking for data incidents	L3	C	☐ 1.0 ☐ 0.67 ☐ 0.33 ☐ 0.0

Level 1 Score (avg Q1–Q3): _____ / 1.0

Level 2 Score (avg Q4–Q6): _____ / 1.0

Level 3 Score (avg Q7–Q9): _____ / 1.0

Overall IM-Data Score (L1×0.5 + L2×0.3 + L3×0.2): _____ / 1.0

Assessment Date: _________

Assessor: _________

Next Assessment Due: _________

Document Version: HAIAMM v3.0, 2026-05-15, Verifhai Practice: Issue Management (IM) Domain: Data Source of Truth: docs/practices/IM-Data-OnePager.md

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

Issue Management (IM) - Data Assessment

Issue Management (IM) - Data Domain

HAIAMM Assessment Questionnaire v3.0

Instructions

Scoring Methodology

Maturity Level 1

Question 1: Unified AI/HAI Data Issue Backlog and Triage Rubric

Question 2: AI-Specific Data Incident Playbook, Seven Data Containment Plays

Question 3: Regulatory SLA Tracker and Post-Incident Review Loop

Maturity Level 2

Question 4: Tier-Calibrated Data Incident Playbook and 24/7 On-Call

Question 5: Post-Incident Review Auto-Flow Integration

Question 6: Cross-Domain Coordination Protocol

Maturity Level 3

Question 7: Industry-Coordinated Data Incident Sharing and Contribution

Question 8: Pre-Authorized Automated Runbook Decisioning for Data Incidents

Question 9: MTTR Benchmarking for Data Incidents

Summary Scorecard