Issue Management (IM)

Data Domain - HAIAMM v3.0

Practice Overview

Objective: Run the single unified backlog for AI/HAI data issues across the Data domain, findings from TA-Data threat snapshots, SR-Data REM gaps, DR-Data approve-with-conditions items, IR-Data drift findings, ST-Data failures, ML-Data detections, and external advisories, with a tier-calibrated incident playbook containing AI-specific data containment plays, and regulatory SLA tracking covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA breach notification, NYDFS Part 500, and state privacy law notification windows.

Description: IM-Data is the clearinghouse for everything the other Data-domain practices produce. Every TA-Data threat snapshot row carrying residual risk, every SR-Data REM accepted gap with an owner and expiry, every DR-Data approve-with-conditions item, every IR-Data drift finding, every ST-Data CI corpus failure or red-team finding, every ML-Data detection that fires, and every external advisory (ATLAS data-attack technique updates, AVID submissions, GDPR enforcement decisions, sector-regulator AI advisories, DPA enforcement actions) flows into a single, prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous incident playbook. The playbook includes AI-specific data containment plays: training corpus poisoning containment, retrieval store extraction containment, embedding inversion containment, prompt/completion log breach containment, cross-border flow violation containment, consent-withdrawal non-propagation remediation, and DSAR fulfillment failure escalation. Every Critical or blocker data incident receives a post-incident review whose outputs flow back to SA-Data, SR-Data, EG-Data, and ML-Data. The regulatory SLA tracker ensures GDPR Art. 33 72-hour, EU AI Act Art. 73 serious-incident reporting, HIPAA 60-day, and state privacy law notification windows are never missed because of organizational diffusion.

Context: Without a unified backlog, AI/HAI data issues scatter across privacy dashboards, data-engineering Jira projects, compliance trackers, and ML-platform alert channels. TA-Data residual risks from a training-corpus poison threat age without remediation owners. SR-Data REM gaps renew silently past their expiry dates. An ML-Data canary-leakage detection fires on a Friday and routes to the data-platform alert channel with no named on-call owner. A consent-withdrawal event is recorded in the consent-management system but never propagates to the training pipeline because there is no IM-Data backlog entry tracking propagation SLAs. A GDPR Art. 33 72-hour clock starts the moment the organization becomes aware of a personal data breach, not when the responsible team processes the notification. IM-Data closes all of these gaps with a single backlog, a single triage rubric, a named on-call path for every severity class, and a regulatory SLA tracker that begins counting from the first internal awareness event, not from when a ticket is eventually filed.

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

At this level, every AI/HAI data issue has a home, a severity, an owner, and an SLA, and data incidents follow a named playbook with AI-specific containment actions rather than generic data-breach response.

Dependencies

• SM-Data L1 (required): the AI/HAI data inventory provides the affected-asset and owning-team spine for every issue; without the inventory, the backlog cannot route issues to accountable owners.
• PC-Data L1 (required): the priority compliance map anchors the regulatory SLA tracker (GDPR Art. 33, GDPR Art. 34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, state privacy laws); triage rubric severity definitions reference compliance exposure.
• TA-Data L1 (required): the archetype threat library drives the incident classification taxonomy and the AI-specific data incident classes in the playbook.
• ML-Data L1 (required): detections from ML-Data are the primary runtime input to the issue backlog; without ML-Data L1, the detection-to-backlog feed does not exist and runtime data incidents go unreported until they are externally visible.
• Supports / unblocks: ML-Data L1 (post-incident reviews feed detection-tuning back into ML-Data); SA-Data L1 (post-incident reviews generate pattern-update requests); SR-Data L1 (post-incident reviews generate requirements-pack update requests); EG-Data L1 (data incident trends feed training-content updates).

Desired Outcomes

• One backlog, one triage rubric, one incident playbook for all AI/HAI data issues, regardless of source practice.
• AI-specific data incident classes are handled on named playbook entries with pre-assigned roles, containment steps, and SLA targets, not improvised at incident time.
• Regulatory SLA tracker is live showing zero missed notification windows for GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, and applicable state privacy laws in the last 90 days.
• Post-incident reviews for Critical / blocker data incidents produce named updates to SA-Data, SR-Data, EG-Data, and ML-Data within 14 days of incident closure.
• Backlog aging is visible to the program sponsor monthly; a small number of aging buckets are actively managed with clear escalation paths.

Activities

A) Stand up the AI/HAI data issue backlog and triage rubric

One backlog with standardized metadata:

• Source, TA-Data (threat snapshot residual risk) / SR-Data (REM accepted gap) / DR-Data (approve-with-conditions item) / IR-Data (drift finding) / ST-Data (CI corpus failure, red-team finding) / ML-Data (detection alert) / External (ATLAS data-attack technique update, AVID submission, GDPR enforcement decision, DPA enforcement action, sector-regulator AI advisory, customer report).
• Affected asset(s), linked to SM-Data inventory; archetype, classification tier, owning team.
• Severity, Critical / High / Medium / Low per the rubric below.
• Owner, named data-asset owner from the SM-Data inventory; escalation path to program sponsor.
• SLA, severity-based (published at L1; per-tier calibrated at L2).
• Evidence, link to originating artifact (TA-Data snapshot row, REM gap row, DR decision, IR-Data finding, ST-Data test result, ML-Data alert ticket, external advisory URL).
• Regulatory flag, whether the issue carries a regulatory notification obligation (GDPR Art. 33 clock started, GDPR Art. 34 high-risk-to-data-subject notification triggered, EU AI Act Art. 73 clock started, HIPAA breach-notification triggered, NYDFS Part 500 triggered, state privacy law notification triggered).

Severity rubric (AI/HAI data domain specific):

• Critical, regulated-data exfiltration confirmed from any AI/HAI data asset (training corpus, retrieval store, prompt/completion log corpus, embedding store, inference input stream, fine-tuning dataset, evaluation/test set); training corpus poisoning confirmed (malicious data introduced into the corpus, evidenced by ST-Data canary or poison-detection scan finding); DSAR cannot be fulfilled because the required data cannot be located or exported within the statutory window; cross-border flow of regulated data confirmed without a legal transfer mechanism; personal data breach in an AI/HAI data asset triggering GDPR Art. 33.
• High, confirmed control failure in a production AI/HAI data asset with potential for harm if not contained (retrieval extraction attempt detected but no confirmed data exfiltration; embedding inversion attempt detected; no-train flag changed without IM-Data review approval; consent-withdrawal propagation failure past the 30-day SLA).
• Medium, confirmed gap in a non-production data asset or a production data asset with compensating controls active; no current active impact; SR-Data REM accepted gap past expiry with no renewal; IR-Data drift finding on a Medium-tier data asset; retention-policy violation on a Low or Medium-tier asset.
• Low, informational; non-urgent gap; recommendation from an external advisory not yet assessed; Low-tier data asset logging gap; minor classification-label discrepancy without an active data-flow impact.

SLA targets (published at L1; per-tier calibrated at L2):

• Critical: acknowledge ≤4 hours / contain ≤48 hours / root-cause ≤30 days.
• High: acknowledge ≤24 hours / contain ≤7 days / root-cause ≤45 days.
• Medium: acknowledge ≤48 hours / remediate ≤14 days.
• Low: acknowledge ≤5 business days / remediate ≤30 days.

Triage cadence: daily review for Critical and new High; weekly queue review for Medium; monthly aging review for the full backlog.

B) Publish the AI-specific data incident playbook

Publish playbook entries for the primary AI/HAI data incident classes. Each entry includes: trigger conditions, named roles (data-asset owner, Privacy/Legal contact, executive sponsor escalation path), step-by-step containment, artifacts to collect, evidence-capture instructions for the deployer-duty record, closure criteria, and SLA targets.

Training corpus poisoning containment (ATLAS TA0014 Impact / TM TTP): Trigger: ML-Data poison-detection scan event flagged; ST-Data CI corpus integrity check failure; external advisory of a known-malicious dataset source appearing in the org's corpus. Containment: (1) quarantine the affected dataset, remove from the active training pipeline by revoking the pipeline service account's access to the quarantined dataset path; (2) roll back affected model versions trained on the poisoned corpus to the previous clean model version in the model registry; (3) execute eval-harness replay against the rolled-back model version to confirm the poisoning effect is absent; (4) conduct a lineage audit, identify all training jobs that consumed the poisoned dataset and all model versions derived from those jobs; (5) assess whether the poisoned data included personal data (GDPR Art. 33 trigger evaluation); (6) update the dataset deny-list with the poisoned source. Evidence: poison-detection scan event record, model rollback event record, eval-replay results, training-job lineage audit, dataset-quarantine access-control change record.

Retrieval store extraction containment (ATLAS TA0013 Exfiltration / TM TTP): Trigger: ML-Data retrieval extraction attempt detection (anomalous query volume or pattern); IR-Data finding of excessive retrieval store access. Containment: (1) disable the retrieval store for the affected principal or query path; (2) implement a classification-gated query allowlist, queries that return documents above a classification threshold require explicit approval; (3) assess which documents and content were accessed during the extraction attempt; (4) assess whether extracted content included personal data (GDPR Art. 33 evaluation); (5) re-enable the retrieval store after classification-gated allowlist is in place; (6) update the retrieval store's service-account access policy to enforce per-principal rate limits. Evidence: retrieval event log export for the affected period, access-disable configuration record, classification-gated allowlist configuration, affected-document assessment.

Embedding inversion containment (ATLAS TA0013 Exfiltration / TM TTP): Trigger: ML-Data embedding inversion attempt detection (anomalous bulk access to embedding store); IR-Data finding of embedding store access outside declared operational profile. Containment: (1) lock down the embedding store, disable bulk-export access for all principals; enable per-query access only with a rate limit applied; (2) escalate to the inversion-defense configuration, apply or tighten the inversion-defense mechanism (noise injection, dimensionality reduction, query-result truncation) per the SA-Data reference pattern; (3) assess which embeddings were accessed and whether the accessed embedding vectors correspond to personal data (GDPR Art. 33 evaluation if personal data is recoverable from embeddings with high confidence); (4) notify affected data subjects if inversion risk to personal data is material (GDPR Art. 34 evaluation). Evidence: embedding access event log export, access-lockdown configuration record, inversion-defense configuration record, affected-subject assessment.

Prompt/completion log corpus breach containment (ATLAS TA0013 Exfiltration / EA TTP): Trigger: ML-Data export event from the prompt/completion log corpus to an unauthorized destination; IR-Data finding of unauthorized access to the prompt/completion log store; ML-Data bulk-export DLP alert. Containment: (1) disable export access to the prompt/completion log store for all non-essential principals; (2) assess the scope of the breach, which log records were exported, which principals, what time window, what data classes were present in the exported records; (3) engage Privacy/Legal immediately, GDPR Art. 33 clock evaluation (prompt/completion logs containing PII = personal data breach if exported without authorization); (4) if high-risk to data subjects (e.g., logs contain medical information, financial information, or data enabling discrimination), assess GDPR Art. 34 direct notification obligation; (5) re-enable log store access under enhanced access controls (JIT access for export operations) after the breach is contained. Evidence: export event audit log, access-disable configuration record, scope-assessment document, data-class inventory of exported records.

Cross-border flow violation containment (ATLAS TA0013 Exfiltration / EA TTP): Trigger: ML-Data cross-border flow violation detection (regulated data replicating to an unapproved region without a transfer mechanism); IR-Data finding of storage replication configuration without a documented SCC or adequacy basis. Containment: (1) disable the cross-border replication or data-transfer configuration immediately; (2) assess which regulated data assets were transferred and to which region; (3) assess whether the transfer constitutes a reportable incident under GDPR Arts. 33/34 or applicable national implementing legislation; (4) engage Privacy/Legal to determine the appropriate transfer mechanism (SCC, adequacy, BCR) and file it before re-enabling the replication; (5) notify the relevant supervisory authority if the transfer of personal data without a legal basis constitutes a reportable personal data breach. Evidence: storage-replication configuration record, data-asset list affected, data-transfer volume and type assessment, transfer-mechanism documentation, supervisory-authority notification record if applicable.

Consent-withdrawal not propagated (ATLAS TA0014 Impact / EA TTP): Trigger: ML-Data consent-withdrawal non-propagation detection (consent withdrawal recorded in consent registry but no deletion/exclusion event in training dataset audit log within 30 days); IR-Data finding of training corpus still containing records linked to a withdrawn-consent subject. Containment: (1) conduct a training-set audit, identify all datasets containing records linked to the withdrawing data subject using the lineage registry; (2) generate deletion/exclusion events for the affected records in all identified datasets; (3) evaluate whether model versions trained on datasets containing the withdrawn-consent subject's data must be rolled back or retrained (assessment criteria: was the subject's data material to the trained model's behavior? is this a high-risk AI system subject to EU AI Act Art. 9 risk-management obligations?); (4) confirm with the data subject that their request has been fulfilled (GDPR Art. 12 response obligation); (5) update the consent-propagation SLA monitoring in ML-Data to flag the affected subject's record as resolved. Evidence: consent-withdrawal event record, training-dataset audit, deletion/exclusion event records, model-rollback evaluation, data-subject confirmation record.

DSAR fulfillment failure escalation (GDPR Art. 15 / Art. 12 / EA TTP): Trigger: DSAR received for a data subject whose data appears in AI/HAI data assets; DSAR cannot be fulfilled within the statutory window (GDPR Art. 12: 30 days, extendable to 90 days for complexity) because the data-asset export path is untested, the asset is not in the SM-Data inventory, or the DSAR-capable export has not been implemented. Containment: (1) escalate to Privacy/Legal immediately; (2) activate the manual-fulfillment path, identify all AI/HAI data assets in scope by querying the SM-Data inventory for data assets whose processing purposes include the data subject's data; (3) attempt manual extraction from each identified asset within the 30-day window; (4) if the 30-day deadline cannot be met, notify the data subject within 30 days of the delay and the new expected date (Art. 12(3)); (5) if the deadline cannot be met due to a systemic gap in the ML-Data export path, file an IM-Data finding of Critical severity, DSAR infrastructure gap, and open a remediation track; (6) if the delay is material and a DPA inquiry is likely, notify Privacy/Legal for DPA pre-notification assessment. Evidence: DSAR receipt record, SM-Data inventory query results, manual-extraction attempts, Art. 12 extension notification record if sent, IM-Data finding record.

C) Track regulatory SLAs and run post-incident reviews

Regulatory SLA tracker, live, named obligation, with automated escalation on approach:

• GDPR Art. 33, 72-hour supervisory-authority notification window after the controller becomes aware of a personal data breach; clock starts on the first internal alert constituting awareness (ML-Data detection fire, IR-Data finding, external notification, data-subject complaint). Named owner: Privacy/Legal. If a GDPR Art. 33 clock starts from an AI/HAI data incident, the IM-Data backlog record is flagged; a daily-at-minimum status update is required until the notification is filed or the clock expires.
• GDPR Art. 34, direct notification to data subjects for high-risk breaches; timeline: without undue delay; assessment required immediately after Art. 33 notification or simultaneously. Named owner: Privacy/Legal. Flag immediately on any Art. 33-triggering AI/HAI data incident for Art. 34 high-risk assessment.
• EU AI Act Art. 73, serious incident involving a high-risk AI system (Annex III); reporting timeline per the implementing act; at L1, track and escalate to Privacy/Legal immediately on any Annex III-classified data asset incident. Named owner: Privacy/Legal + executive sponsor.
• HIPAA breach notification, 60-day discovery-to-notification ceiling for covered entities and business associates; individual notification without unreasonable delay; HHS Secretary notification within 60 days. Named owner: Privacy/Legal. Flag any AI/HAI data incident involving PHI immediately.
• NYDFS Part 500, 72-hour notification to the Superintendent for material cybersecurity events affecting covered entities. Named owner: CISO / Privacy/Legal.
• PCI-DSS, cardholder data breach notification requirements; named owner per the org's PCI compliance program. Flag any AI/HAI data incident involving cardholder data immediately.
• State privacy law SLAs, CCPA/CPRA consumer-notification obligations; US state breach-notification laws (30–60 days depending on jurisdiction); named owner per the org's state-privacy compliance program.

Every Critical or blocker data incident receives a post-incident review within 14 days of containment: - What happened: root cause, how the incident initiated, what controls failed or were absent. - What caught it: which ML-Data detection, IM-Data source, or external report surfaced it first; was this the expected detection path or a gap? - What did not catch it: which controls should have detected or prevented this but did not. - Update outputs (all four must be populated for Critical incidents): - SA-Data: pattern-update request if the incident exploited an architectural gap in a data reference pattern. - SR-Data: requirements-pack update request if the incident exploited a missing or vague data-handling requirement. - EG-Data: training-content update request if the incident indicates a literacy gap in the data-engineering or privacy-compliance population. - ML-Data: detection-update request (new detection, tuned query, or evidence that an existing detection's query can be sharpened to catch this incident class earlier).

Post-incident review outputs are tracked as IM-Data issues of their own (type: improvement); they age against the same process metric cadence as other issues.

Outcome Metrics (L1)

Process Metrics (leading)

• Backlog triage cadence honored, daily Critical/High triage; weekly Medium; monthly aging.
• Playbook runbook rehearsal, at least one tabletop per quarter exercising an AI-specific data incident scenario (rotate through the seven playbook classes).
• Regulatory SLA tracker reviewed weekly; named owner confirms clock-start dates and status for any active or recent incidents.
• Aging pockets, number of issues aging past SLA tracked; trending down.

Effectiveness Metrics (business value)

• Repeat-class data incident rate, an incident class occurring twice in 12 months without a SA/SR/EG/ML-Data update after the first occurrence is a process failure; repeat rate on same class trending down.
• Deployer-duty evidence chain, on a GDPR audit or EU AI Act Art. 26 inquiry, the incident records show the detection, containment, and notification chain for the affected data asset; evidence assembled within ≤5 business days.
• Mean-time-to-contain across Critical and High-severity AI/HAI data incidents trending down over quarters.

Success Criteria

• Single AI/HAI data issue backlog established with standardized metadata; triage rubric with AI-specific data severity definitions published.
• Seven AI-specific data incident playbook entries published (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log breach, cross-border flow violation, consent-withdrawal not propagated, DSAR fulfillment failure), each with named roles, containment steps, evidence-capture instructions, and SLA targets.
• Regulatory SLA tracker live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA, NYDFS Part 500, PCI-DSS, and applicable state privacy laws; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Data, SR-Data, EG-Data, and ML-Data; every Critical/blocker data incident produces a review within 14 days with named update outputs.
• Program-sponsor dashboard showing backlog aging, SLA adherence, and post-incident learning outputs refreshed monthly.

Maturity Level 2

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

At this level, incident response differentiates by tier. Critical-tier data assets have a dedicated on-call rotation, pre-staged executive escalation paths, and a 24/7 coverage model. High-tier data assets have scoped response with defined escalation. Medium and Low follow the standard queue. Post-incident reviews auto-feed SA-Data, SR-Data, EG-Data, and ML-Data queues via integration rather than manual handoff. When an AI/HAI data incident affects cross-domain scope (a training corpus breach that also implicates Software-domain models or Infrastructure-domain storage), coordinated cross-domain response is activated.

Dependencies

• IM-Data L1 (required): unified backlog, AI-specific data incident playbook, and regulatory SLA tracker must be operational before per-tier calibration adds meaningful depth.
• SM-Data L2 (required): risk-tier rubric and tier-treatment matrix drive response intensity; without SM-Data L2 tiers, per-tier data incident response has no substrate.
• ML-Data L2 (required): richer detections (anomaly-based, cross-archetype correlated) feed severity classification with higher-fidelity signals; tier-calibrated logging depth makes evidence collection faster and more complete at L2.
• Supports / unblocks: ML-Data L2 detection tuning loop (IM-Data L2 post-incident reviews, with tier-context, produce more targeted detection updates); SA-Data L2 pattern evolution (incidents from Critical-tier data assets drive data-architecture pattern updates).

Desired Outcomes

• Response intensity matches tier, Critical-tier data incidents do not wait in the general queue; they activate a named response team, a dedicated on-call path, and the full containment playbook within the published SLA.
• Post-incident review outputs auto-flow to SA-Data, SR-Data, EG-Data, and ML-Data practice backlogs via a defined integration rather than manual handoff, no data-incident learning gets lost in a shared document.
• Cross-domain coordination is explicit: a Data-domain incident that implicates the Software domain (a training corpus breach affecting models in production), the Infrastructure domain (a storage misconfiguration exposing training data), or the Processes domain (a DSAR that cannot be fulfilled because business-process data flows are unmapped) activates a named cross-domain coordination protocol.
• Tier-movement in the SM-Data inventory auto-triggers IM-Data policy changes: when a data asset is re-tiered to Critical, the on-call path, playbook variant, and SLA targets are automatically updated in the IM-Data backlog configuration within 14 days.

Activities

A) Tier-calibrated data incident playbook and on-call

Extend L1 playbook entries with tier-specific activation criteria and on-call coverage:

• Critical tier: full IM-Data activation, CISO or delegate + Privacy/Legal + data-asset owner + executive sponsor notification; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named data-security incident responder; pre-staged communication templates (internal, customer-facing, supervisory-authority notification draft) loaded and reviewed quarterly.
• High tier: scoped response team, Privacy/Legal + data-asset owner; ≤4 hours acknowledgement; ≤24 hours containment-action initiated; business-hours on-call with after-hours escalation path defined.
• Medium tier: standard response; ≤1 business day acknowledgement; queue-based triage.
• Low tier: tracked in queue; aggregated weekly handling.

Critical-tier on-call rotation documented: named individuals per week, coverage hand-off protocol, on-call briefing that includes the current Critical-tier data asset list, their active detection set, and the containment playbook paths specific to those archetypes.

B) Post-incident review auto-flow integration

• Wire IM-Data post-incident review outputs to downstream practice backlogs via a defined integration:
• SA-Data pattern-update request → SA-Data architecture-backlog ticket (auto-created with IM-Data incident reference linked).
• SR-Data requirements-pack update request → SR-Data pack-backlog ticket (auto-created with requirements-pack version and failing requirement row linked).
• EG-Data training-content update request → EG-Data training-backlog ticket (auto-created with affected population segment and data-incident summary linked).
• ML-Data detection-update request → ML-Data detection-registry update ticket (auto-created with detection name, current query, and proposed change linked).
• SLA for downstream updates: Critical-tier post-incident review outputs must be accepted or rejected by the downstream practice owner within 14 days; accepted updates are treated as High-severity issues in the receiving practice's backlog.
• Post-incident review quality reviewed quarterly by the program sponsor, are the update outputs substantive (concrete change to an architecture pattern, requirements pack, curriculum, or detection) or nominal (a note saying "consider reviewing")?

C) Cross-domain coordination protocol

Publish a cross-domain coordination protocol that activates when a Data-domain AI/HAI data incident implicates another domain:

• Data → Software: a training corpus poisoning or breach affects model versions currently in production in the Software domain; activates the Software-domain IM-Software model-rollback play alongside the Data-domain corpus-quarantine and lineage-audit play; named Software-domain IM contact on file.
• Data → Infrastructure: a storage misconfiguration exposes a training corpus or prompt/completion log corpus to unauthorized access via a direct storage-API path; activates Infrastructure-domain EH and IM alongside Data-domain containment; named Infrastructure-domain IM contact on file.
• Data → Processes: a DSAR fulfillment failure reveals that business-process data flows feeding AI/HAI data assets are not mapped in the SM-Data or Processes-domain inventory; activates Processes-domain privacy coordinator alongside Data-domain DSAR escalation play; named Processes-domain contact on file.

Cross-domain incident activations: shared status board, one unified IC (from the primary impacted domain), coordinated remediation tracking, and a joint post-incident review spanning all affected domains.

Outcome Metrics (L2)

Process Metrics (leading)

• Critical-tier data playbook review cadence, quarterly, tested in a tabletop covering the tier's specific data asset list.
• On-call rotation health, no uncovered periods; hand-off briefing completed per rotation; briefing includes updated Critical-tier data asset list and active detection set.
• Post-incident review quality score, sponsor reviews a sample quarterly; nominal updates flagged for improvement.
• Cross-domain coordination contacts verified quarterly, named contacts are current, communication channels tested.

Effectiveness Metrics (business value)

• Dwell time on Critical-tier data incidents (time from first ML-Data detection to containment action complete) trending down as L2 matures.
• Downstream practice update acceptance rate, % of Critical-tier post-incident updates accepted and resolved by the downstream practice; measures whether the feedback loop actually improves the data-security program.
• Cross-domain coordination saves time vs. uncoordinated parallel response, measured as MTTU and MTTC on multi-domain data incidents.

Success Criteria

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation that includes a current Critical-tier data asset briefing.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA-Data/SR-Data/EG-Data/ML-Data backlogs; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI data incidents.
• Tier-movement in SM-Data inventory auto-triggers IM-Data configuration updates within 14 days (Critical re-tier) or 30 days (other tiers).

Maturity Level 3

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

At this level, IM-Data is a contributor to the AI-assurance data-incident-response ecosystem. Anonymized data incident classification schemes, AI-specific data severity anchors, and playbook templates for the seven primary AI/HAI data incident classes are contributed to sector ISACs, MITRE ATLAS, AVID, DAMA, and CSA AI Safety Initiative. Pre-authorized automated containment actions execute for low-severity, high-confidence data detections, disabling a retrieval store's bulk-query path, revoking a pipeline service account's access to a quarantined dataset, or blocking a cross-border replication configuration, within seconds of detection. MTTR benchmarks are established from ISAC and peer data, and the program's MTTR is measured against those benchmarks quarterly.

Dependencies

• IM-Data L2 (required): tiered playbook, post-incident review auto-flow, and cross-domain coordination must be operational and producing clean data-incident pattern data before contributions to external bodies are substantive.
• PC-Data L3 (required): continuous compliance attestation substrate supports automated evidence capture for pre-authorized containment actions; legal authority for automated actions flows from the policy and compliance program.
• ML-Data L3 (required): detection-as-code and high-confidence anomaly detection signals provide the automation trigger quality needed for pre-authorized runbook execution on data assets.

Desired Outcomes

• Industry-standard data incident classification and response playbooks for AI/HAI data incidents are contributed and maintained, sector ISACs, AVID, ATLAS, and DAMA cite the org's artifacts.
• Pre-authorized automated containment actions execute for a defined set of low-severity, high-confidence data incident types, reducing MTTR for these classes to seconds from hours.
• MTTR benchmarks are established from ISAC and peer data; the program's performance against benchmarks is reported to the sponsor quarterly and drives investment decisions.
• Contributions to MITRE ATLAS TA0014 Impact tactic documentation reflect the org's first-party data-incident experience with AI/HAI data containment plays.

Activities

A) Industry-coordinated data incident sharing and contribution

• Participate in sector ISAC AI data incident-sharing programs (FS-ISAC AI working group, H-ISAC, IT-ISAC, sector-specific):
• Consume ISAC AI data incident feeds; integrate applicable advisories into the IM-Data external-advisory source.
• Contribute anonymized data incident classification (incident type, ATLAS tactic tag, HAI-TTP tag, data archetype affected, containment play used, regulatory SLA outcome, MTTR achieved) on a per-incident-class basis; target ≥4 ISAC contributions per year.
• Contribute to AI data incident taxonomy standards:
• MITRE ATLAS TA0014 Impact, submit incident-derived technique observations or mitigation entries for Impact-tactic techniques relevant to data assets (training-data poisoning, data exfiltration, consent-manipulation); target ≥1 ATLAS contribution per year for IM-Data primary tactics.
• AVID (AI Vulnerability Database), submit AI/HAI data vulnerability entries for novel data incident classes discovered in production (training corpus poisoning methods, embedding inversion methods, consent-withdrawal propagation failures); target ≥2 AVID entries per year.
• DAMA (Data Management Body of Knowledge), contribute AI/HAI data incident response patterns, data-archetype severity definitions, and DSAR fulfillment escalation playbook templates for inclusion in DAMA AI data governance guidance.
• CSA AI Safety Initiative, AI data incident severity-anchor definitions and playbook template schemas for the data domain.
• Contribute to MITRE ATLAS TA0014 Impact documentation focused on data-domain techniques.

B) Pre-authorized automated runbook decisioning for data incidents

Define and publish a pre-authorization policy for automated containment actions on AI/HAI data assets, the set of actions that can execute without human approval when a detection fires at a defined confidence threshold:

• Pre-authorized actions (examples; published list vetted by Privacy/Legal and executive sponsor):
• Retrieval store bulk-query path disable for a Low or Medium-tier retrieval store when a retrieval extraction attempt detection fires above 90% confidence threshold.
• Pipeline service account access revocation for a quarantined training dataset when a poison-detection scan fires above 95% confidence threshold and the affected dataset is not at Critical tier.
• Cross-border replication disable for a storage replication configuration when a cross-border flow violation detection fires (regulated data replicating to an unapproved region).
• Embedding store bulk-export access disable for a Low or Medium-tier embedding store when an embedding inversion attempt detection fires above 90% confidence threshold.
• Critical-tier data assets: pre-authorized actions for Critical-tier data assets require human confirmation within 15 minutes; the action fires after that window if no human confirmation arrives (timer-based fallback), with immediate executive notification at fire time.
• All pre-authorized actions produce: a full audit-log entry in the IM-Data backlog, a human-review ticket auto-created at execution time, and a notification to the data asset's named owner.
• Pre-authorization policy reviewed quarterly by Privacy/Legal and the executive sponsor; any automated action that produces an unexpected outcome triggers an out-of-cycle review.

C) MTTR benchmarking for data incidents

• Establish MTTR benchmarks from:
• ISAC AI data incident data exchanges.
• BSIMM-style observational data on AI/HAI data incident response at comparable organizations.
• MITRE ATLAS practitioner community data on data-domain incident response.
• Peer roundtables (Privacy Officer and AI data-security practitioner communities).
• Publish a quarterly MTTR benchmark brief to the program sponsor:
• MTTR per data incident class vs. benchmark (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log breach, cross-border flow violation, consent-withdrawal non-propagation, DSAR fulfillment failure).
• MTTR per tier (Critical, High, Medium) vs. benchmark.
• Delta trend (improving, stable, degrading) vs. benchmark.
• Investment driver: where MTTR is above benchmark, root-cause mapped to a specific practice gap (missing detection, unclear playbook, on-call latency, DSAR infrastructure gap) with a budget-linked improvement proposal.

Outcome Metrics (L3)

Process Metrics (leading)

• ISAC participation cadence, sector ISAC feeds consumed and contributions submitted at least quarterly; ISAC AI data exercises attended annually.
• Contribution pipeline health, ≥2 taxonomy/playbook/ATLAS items in-flight (draft, in-review, submitted) at any time.
• Pre-authorization policy review cadence, quarterly; any automated action producing an unexpected outcome triggers an out-of-cycle review.
• Benchmark data source refresh, MTTR benchmark inputs updated at least semi-annually; stale benchmarks flagged.

Effectiveness Metrics (business value)

• MTTR for pre-authorized containment classes (retrieval store extraction, embedding inversion, cross-border flow violation) drops to seconds from hours, the most significant MTTR-reduction lever available without adding headcount.
• Mean-time-to-contain on Critical-tier data incidents continuing to compress as ISAC-shared intelligence accelerates root-cause identification and playbook refinement.
• External recognition, citations or adoption of contributed AI data incident taxonomy artifacts by ISACs, ATLAS, AVID, DAMA, or sector standards bodies.

Success Criteria

• ≥4 ISAC AI data incident contributions per year; ≥2 AVID data vulnerability entries per year; ≥1 ATLAS TA0014 Impact contribution per year; all contributions anonymized, legally vetted, and maintained.
• ≥3 pre-authorized automated containment actions live, vetted by Privacy/Legal and the executive sponsor, producing 100% audit records + human-review tickets on execution.
• Quarterly MTTR benchmark brief published to sponsor; Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes; deltas above benchmark linked to investment proposals.
• Pre-authorization policy reviewed quarterly; no unauthorized automated action executed; all unexpected automation outcomes reviewed within 5 business days.

Key Success Indicators

Level 1: - Single AI/HAI data issue backlog operational with standardized metadata (source, affected data asset linked to SM-Data inventory, archetype, severity rubric, owner, SLA, regulatory flag, evidence link) capturing ≥95% of AI/HAI data issues from all source practices. - Seven AI-specific data incident playbook entries published (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log breach, cross-border flow violation, consent-withdrawal not propagated, DSAR fulfillment failure) with named roles, containment plays, evidence-capture instructions, and SLA targets, each exercised in at least one tabletop in the last 12 months. - Regulatory SLA tracker live covering GDPR Arts. 33/34, EU AI Act Art. 73, HIPAA (60d), NYDFS Part 500 (72h), PCI-DSS, and applicable state privacy laws; 100% adherence in the last 90 days. - Post-incident review loop wired to SA-Data, SR-Data, EG-Data, and ML-Data, every Critical/blocker data incident produces a review within 14 days with named update outputs for each downstream practice. - Program-sponsor dashboard refreshed monthly showing backlog aging, SLA adherence, and post-incident learning outputs.

Level 2: - Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation that includes a current Critical-tier data asset briefing with archetype-specific containment playbook paths. - Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA-Data/SR-Data/EG-Data/ML-Data backlogs; ≥90% of downstream practice owners responding within 14 days. - Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI data incidents; named cross-domain contacts (Software, Infrastructure, Processes) verified quarterly. - Tier-movement in SM-Data inventory auto-triggers IM-Data configuration updates within 14 days (Critical re-tier) or 30 days (other tiers).

Level 3: - ≥4 ISAC AI data incident contributions per year; ≥2 AVID data vulnerability entries per year; ≥1 ATLAS TA0014 Impact contribution per year, all maintained and tracked for external adoption. - ≥3 pre-authorized automated containment actions live, vetted, producing 100% audit records, with quarterly policy review and zero unauthorized executions. - Quarterly MTTR benchmark brief published; Critical-tier MTTR at or below benchmark for ≥4 of 7 data incident classes; deltas linked to investment proposals.

Common Pitfalls

Level 1: - ❌ "Single backlog" created but source practices continue filing into separate queues, ST-Data failures stay in the CI pipeline dashboard, ML-Data alerts route to a data-platform Slack channel, and TA-Data residual risks live in a spreadsheet; the backlog achieves only ~40% of issues and the ≥95% coverage target is never reached. - ❌ Severity rubric anchors are generic (probability × impact without AI-specific data axes), a consent-withdrawal non-propagation event is triaged Low because the generic rubric does not capture GDPR Art. 33 exposure from continued processing of a withdrawn-consent subject's data in a training corpus. - ❌ Playbook entries published but roles not pre-assigned, on the first live training corpus poisoning incident, the team spends the first hour determining who has authority to quarantine the dataset and revoke the pipeline service account's access, not executing the quarantine. - ❌ GDPR Art. 33 72-hour clock tracked informally, when a prompt/completion log corpus export to an unauthorized destination is discovered on a Friday evening, the clock starts but no named owner documents the awareness event; the SLA slips before the first status update is filed. - ❌ DSAR fulfillment path never tested, the first DSAR arrives for a data subject whose data appears in a training corpus; the export takes 4 weeks because no one has tested the DSAR-capable export path and the ML-Data export SLA was never drilled. - ❌ Post-incident reviews completed but outputs filed in a document that no downstream practice owner reads, SA-Data, SR-Data, EG-Data, and ML-Data do not update; the same consent-withdrawal non-propagation incident class recurs with the same root cause 6 months later.

Level 2: - ❌ Critical-tier activation criteria are vague, a confirmed retrieval store extraction attempt that qualifies for full-team + executive activation stays in the standard queue until the data-asset owner escalates; the SLA that required ≤1-hour acknowledgement is already missed by the time the right people engage. - ❌ Post-incident review auto-flow integration wired but downstream practice backlogs never treat the auto-created tickets as actionable, the SR-Data team closes the ticket as "acknowledged" without updating the requirements pack; the feedback loop is nominally present but produces no change. - ❌ Cross-domain coordination protocol exists on paper but no IC is pre-designated for cross-domain data incidents, the first incident where a training corpus breach affects Software-domain model versions produces ownership confusion between Data-domain IM and Software-domain IM; both wait for the other to take the IC role. - ❌ 24/7 on-call coverage implemented but the on-call briefing is stale, the rotation briefing includes a Critical-tier data asset list that was accurate 60 days ago; a newly tiered Critical-tier training corpus is not in the briefing; the on-call responder does not know the quarantine path for the affected dataset.

Level 3: - ❌ ISAC participation limited to consuming feeds, contributions are absent; the org is labeled a free-rider; influence over AI data incident taxonomy standards diminishes and the ISAC feed quality degrades without reciprocal intelligence. - ❌ Pre-authorized automated containment fires on a Critical-tier data asset because the confidence threshold was set without a Critical-tier exception check, a false positive disables a retrieval store backing a production customer-facing AI feature; the pre-authorization policy had no Critical-tier confirmation-window logic. - ❌ MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI data portfolio scale or regulatory exposure, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch the program. - ❌ AVID data vulnerability entries submitted once and never updated, novel data incident classes evolve; the org's AVID entries reflect vulnerabilities from 18 months ago that have since been mitigated; the community builds on stale data. - ❌ Automated containment produces audit records that are technically complete but lack narrative context, humans reviewing automated-action logs cannot reconstruct what the ML-Data detection observed or why the confidence threshold triggered; post-incident root-cause analysis requires reconstructing context that was never captured.

Practice Maturity Questions

Level 1: 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)? 2. Is the AI/HAI data incident playbook published with ≥7 named AI-specific data incident classes (training corpus poisoning, retrieval store extraction, embedding inversion, prompt/completion log 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? 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?

Level 2: 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 playbook paths, and tier-movement in the SM-Data inventory automatically triggering IM-Data configuration updates (on-call path, playbook variant, SLA targets) within 14 days (Critical re-tier)? 2. Is a post-incident review auto-flow integration live routing Critical-tier 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 to distinguish substantive changes from nominal acknowledgements? 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?

Level 3: 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? 2. Are ≥3 pre-authorized automated 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 on execution, with the pre-authorization policy reviewed quarterly and any unexpected outcome triggering an out-of-cycle review? 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?

Document Version: HAIAMM v3.0 Practice: Issue Management (IM) Domain: Data Last Updated: 2026-05-13 Author: Verifhai