Issue Management (IM)

Processes Domain - HAIAMM v3.0

Practice Overview

Objective: Run the single unified backlog for AI/HAI issues across the Processes domain, findings from TA-Processes threat snapshots, SR-Processes REM gaps, DR-Processes conditions, IR-Processes drifts, ST-Processes failures, ML-Processes detections, and external advisories, with a tier-calibrated incident playbook containing AI-specific workflow containment plays, and regulatory SLA tracking covering GDPR Arts. 22/33, EU AI Act Arts. 26/50/73, HIPAA, FCRA, FINRA, NYC LL 144, CO SB-21-169, and sector-specific obligations.

Description: IM-Processes is the clearinghouse for everything the other Processes-domain practices produce. Every TA-Processes threat snapshot row carrying residual risk, every SR-Processes REM accepted gap with an owner and expiry, every DR-Processes approve-with-conditions item, every IR-Processes drift finding, every ST-Processes failure, every ML-Processes detection that fires, and every external advisory (sector regulator enforcement actions, NYC LL 144 bias-audit findings, EEOC bias enforcement, EU AI Act enforcement decisions) flows into a single, prioritized backlog with named owners, tier-calibrated SLAs, and an unambiguous incident playbook. The playbook includes AI-specific workflow containment plays: wrongful-decision containment, HITL failure / rubber-stamp incident response, disclosure failure remediation, class-shift / fairness incident handling (security-intersection only), content-generation harmful output containment, knowledge-management RAG-poisoning containment, and shadow-AI-in-process containment. Every Critical or blocker incident receives a post-incident review whose outputs flow back to SA-Processes, SR-Processes, EG-Processes, and ML-Processes. The regulatory SLA tracker ensures GDPR Art. 33 72-hour breach notification, EU AI Act Art. 73 serious-incident reporting, FCRA adverse-action timelines, and NYC LL 144 audit windows are never missed because of organizational diffusion.

Context: Without a unified backlog, AI/HAI workflow issues scatter across product JIRA projects, compliance trackers, legal dashboards, and BPM alert channels. TA-Processes residual risks from a decision-pipeline threat age without remediation owners. An ML-Processes rubber-stamp HITL detection fires on a Friday and routes to a Slack channel with no named on-call owner. A GDPR Art. 22 contestation request arrives and nobody can locate the decision log because the IR-Processes finding about log-retention compliance is still open in a separate queue. An EU AI Act Art. 50 disclosure failure affects 10,000 customer interactions and the organization does not know whether Art. 73 serious-incident reporting is required because no playbook entry covers that scenario. IM-Processes 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.

Maturity Level 1

Objective: Operate a single unified AI/HAI workflow issue backlog with a standard triage rubric, AI-specific workflow incident playbook including containment plays for the primary process incident classes, and regulatory SLA tracking for GDPR Arts. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA, FINRA, NYC LL 144, and CO SB-21-169 obligations

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

Dependencies

• SM-Processes L1 (required): the workflow inventory provides the affected-workflow and owning-team spine for every issue; without the inventory, the backlog cannot route issues to accountable owners.
• PC-Processes L1 (required): the priority compliance map anchors the regulatory SLA tracker (GDPR Arts. 22/33, EU AI Act Arts. 26/50/73, HIPAA, FCRA, FINRA, NYC LL 144, CO SB-21-169, sector-specific); triage rubric severity definitions reference compliance exposure.
• TA-Processes L1 (required): archetype threat library drives the incident classification taxonomy and the AI-specific process incident classes in the playbook.
• ML-Processes L1 (required): detections from ML-Processes are the primary runtime input to the workflow issue backlog; without ML-Processes L1, the detection-to-backlog feed does not exist and runtime workflow incidents go unreported until they are externally visible.
• Supports / unblocks: ML-Processes L1 (post-incident reviews feed detection-tuning back into ML); SA-Processes L1 (post-incident reviews generate pattern-update requests); SR-Processes L1 (post-incident reviews generate requirements-pack update requests); EG-Processes L1 (incident trends feed training-content updates).

Desired Outcomes

• One backlog, one triage rubric, one incident playbook for all AI/HAI workflow issues, regardless of source practice.
• AI-specific workflow 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. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, and CO SB-21-169 obligations in the last 90 days.
• Post-incident reviews for Critical / blocker workflow incidents produce named updates to SA-Processes, SR-Processes, EG-Processes, and ML-Processes 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 workflow issue backlog and triage rubric

One backlog with standardized metadata:

• Source, TA-Processes (threat snapshot residual risk) / SR-Processes (REM accepted gap) / DR-Processes (approve-with-conditions item) / IR-Processes (drift finding) / ST-Processes (CI corpus failure, red-team finding) / ML-Processes (detection alert) / External (sector regulator enforcement action, NYC LL 144 audit finding, EEOC bias enforcement, EU AI Act enforcement decision, DPA advisory, customer report).
• Affected workflow(s), linked to SM-Processes inventory; archetype, tier, owning team.
• Severity, Critical / High / Medium / Low per the rubric below.
• Owner, named workflow owner from the SM-Processes inventory; escalation path to program sponsor.
• SLA, severity-based (published at L1; per-tier calibrated at L2).
• Evidence, link to originating artifact (TA snapshot row, REM gap row, DR decision, IR finding, ST test result reference, ML alert ticket, external advisory URL).
• Regulatory flag, whether the issue carries a regulatory notification obligation (GDPR Art. 33 clock started, EU AI Act Art. 73 clock started, HIPAA breach-notification triggered, FCRA adverse-action remediation triggered, NYC LL 144 audit finding, sector-specific).

Severity rubric (AI/HAI Processes domain specific):

• Critical, wrongful automated decision affecting a named individual or class in a High-risk AI system context (Annex III workflow); HITL failure confirmed on a workflow with real-world consequential outcomes (credit denial, employment, benefits); confirmed Art. 50 disclosure failure affecting ≥1,000 customer interactions or in a regulated context; personal data breach in an AI/HAI workflow (decision log, HITL review log, input stream) triggering GDPR Art. 33; shadow AI confirmed handling regulated data without intake; RAG-poisoning confirmed delivering false information in a consequential decision context.
• High, confirmed HITL rubber-stamp on a Critical/High-tier workflow (reviewers matching AI ≥98% over a defined window); confirmed workflow-definition change deployed without DR re-review for material changes; Art. 50 disclosure suppressed in a non-regulated context; GDPR Art. 22 contestation request that cannot be fulfilled within the statutory window; class-shift / decision-distribution anomaly on a protected-attribute security-intersection workflow pending root-cause.
• Medium, confirmed gap in a non-production workflow or a production workflow with compensating controls active; SR-Processes REM accepted gap past expiry with no renewal; IR-Processes drift finding on a Medium-tier workflow; reviewer-capacity SLA at-risk alert unresolved after 24 hours.
• Low, informational; non-urgent gap; recommendation from an external advisory not yet assessed; Low-tier workflow logging gap; minor classification-routing discrepancy without 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 workflow incident playbook

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

Wrongful-decision containment:

Trigger: ML-Processes detection of a decision-pipeline event where the AI output appears inconsistent with the approved threshold, the HITL reviewer overrode the AI output without rationale on a Critical-tier workflow, or a customer contestation surfaces a decision inconsistent with stated criteria. Containment: (1) pause the affected workflow step pending manual review of recent decisions; (2) identify affected persons, pull decision-log records for the period in question; (3) manual review of affected decisions by a named senior reviewer; (4) notify affected individuals of their right to contestation under GDPR Art. 22 (or applicable regulation); (5) assess whether the AI system is an Annex III High-risk system, if yes, evaluate EU AI Act Art. 73 serious-incident reporting; (6) evaluate EU AI Act Art. 26.5 deployer-suspension obligation if non-conformance discovered; (7) preserve the full decision log for the affected period as evidence. Evidence: decision log export, HITL review log export, deployer-duty record update, Art. 22 contestation handling records.

HITL failure / rubber-stamp incident:

Trigger: ML-Processes rubber-stamp HITL detection (reviewer matches AI ≥98% over a defined window on a Critical/High-tier workflow); or an internal audit or external review confirms systematic non-review of AI recommendations. Containment: (1) pause the affected HITL workflow step; (2) audit the reviewer pool, pull review events for the last 30 days for all reviewers in the affected pool; (3) assess whether any decisions during the rubber-stamp period should be retroactively reviewed; (4) mandatory reviewer training escalation for affected reviewers; (5) assess whether the rubber-stamp period constitutes non-conformance that requires regulator notification (EU AI Act Art. 26 deployer duties; sector-specific); (6) implement enhanced reviewer-capacity monitoring and load-balancing before restarting the HITL step. Evidence: reviewer-session log export, decision log for affected period, reviewer-capacity event log, ML detection record.

Disclosure failure (Art. 50):

Trigger: ML-Processes disclosure-suppression detection (Art. 50 disclosure UI not rendered in a customer-facing flow execution); or a customer complaint confirming they did not receive the required disclosure. Containment: (1) identify the surface or workflow step where the disclosure was suppressed; (2) fix the disclosure rendering defect or restore the suppressed template from the central registry; (3) assess scope, how many customer interactions occurred without the required disclosure, over what period; (4) retroactive disclosure to affected customers (notification that a prior interaction involved AI-generated content or an AI-assisted decision, per Art. 50 spirit); (5) evaluate whether the suppression constitutes an Art. 26 deployer-duty non-conformance requiring regulator evaluation; (6) assess whether an A/B test or unauthorized product change caused the suppression and route findings to the responsible team's IM backlog. Evidence: disclosure-completion event log for the affected period, template-registry change log, affected-customer list, deployer-duty record update.

Class-shift / fairness incident (security-intersection only):

Scope: this playbook entry applies only where a decision-distribution shift constitutes a security concern, specifically, where a bias-driven shift could represent a gate-bypass (adversarial manipulation of the AI model to favor or disfavor a class for unauthorized purposes) or a fairness manipulation attack on the workflow. Pure AI-fairness concerns without a security dimension are addressed through separate AI ethics / fairness governance processes. Trigger: ML-Processes decision-distribution drift detection on a protected-attribute security-intersection workflow; or ST-Processes adversarial-fairness test finding. Containment: (1) pause the affected decision-pipeline step; (2) root-cause analysis: is the shift attributable to model drift, data-poisoning, adversarial input manipulation, or threshold manipulation; (3) assess affected persons, pull decision records for the affected period; (4) evaluate sector regulator notification (NYC LL 144 bias-audit window; EEOC if employment context; CO SB-21-169 if insurance context; EU AI Act Art. 73 if Annex III); (5) evaluate GDPR Art. 33 if personal data was processed under the drifted model. Evidence: decision-distribution metric event log for the affected period, model-version and threshold-change audit log, affected-person decision records, deployer-duty record update.

Content-generation harmful output:

Trigger: ML-Processes brand-safety filter event with severity above threshold; or a customer report of harmful, false, or legally problematic AI-generated content published through an org-owned customer-facing flow. Containment: (1) recall or retract the harmful output from the channel where it was published (email recall, content deletion, API rollback of generated content where technically feasible); (2) customer-facing apology or correction notification as appropriate; (3) pause the content-generation workflow step pending root-cause; (4) identify which generation prompt, model version, or workflow template produced the harmful output; (5) rollback the generation prompt or workflow template to the last-known-good version; (6) evaluate regulator notification if the output touched regulated topics (financial advice, medical information, legal advice) or violated applicable law; (7) update the brand-safety filter with new patterns from the incident. Evidence: generation event log for the affected period, output-review event log, published-content record (screenshot or archived copy), prompt-rollback configuration record, deployer-duty record update.

Knowledge-management RAG-poisoning:

Trigger: ML-Processes retrieval-poisoning detection event (flagged document ID in a retrieval sequence for a knowledge-management workflow); or a user report of factually false or confidential information surfaced through a knowledge-management query. Containment: (1) quarantine the affected corpus segment, remove the flagged document(s) from the retrieval allowlist; (2) disable the retrieval pipeline for the affected corpus pending re-indexing; (3) assess affected queries, pull retrieval event logs for the period in which the poisoned document was in the corpus; (4) identify users who received responses influenced by the poisoned retrieval; (5) notify affected users if the retrieval materially affected a consequential decision or included regulated data; (6) evaluate GDPR Art. 33 if the poisoned retrieval resulted in regulated personal data being improperly disclosed; (7) re-index the corpus after removal of the poisoned document and validation by ST-Processes retrieval-poisoning test; (8) assess whether the poisoning was adversarial (intentional injection) or incidental (unvetted source ingest). Evidence: retrieval event log for the affected period, retrieval-poisoning detection record, quarantine configuration record, affected-user list, GDPR Art. 33 assessment record.

Shadow-AI-in-process containment:

Trigger: ML-Processes shadow-AI-in-process detection (new AI step detected in a workflow definition version that does not appear in the SM-Processes inventory); or a workflow operations report of an unrecognized AI-powered step producing unexpected outputs in a production workflow. Containment: (1) pause or freeze the affected workflow step, block execution of the unrecognized AI step until inventory intake is complete; (2) identify the workflow, owning team, and developer responsible for the unauthorized addition; (3) route the AI step through the SM-Processes intake process (amnesty path if appropriate, no-punish intake in exchange for full disclosure); (4) assess the data-flow: what data did the shadow AI step process, from what sources, for what period; (5) if regulated personal data transited the shadow AI step, evaluate GDPR Art. 33 and EU AI Act Art. 73 obligations; (6) assess whether the shadow AI step involved an unvetted vendor, if yes, route to Vendors-domain IM for TPRM intake; (7) document the shadow-AI incident in the SM-Processes inventory as a finding. Evidence: workflow-definition version diff showing the unrecognized AI step, shadow-AI detection record, data-flow assessment, intake record, GDPR Art. 33 / EU AI Act Art. 73 assessment 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 that constitutes awareness (ML detection, IR finding, external notification, customer complaint). Named owner: Privacy/Legal. If a GDPR Art. 33 clock starts from a workflow incident, the IM-Processes backlog record is flagged; a daily-at-minimum status update is required until the notification is filed or the clock expires.
• GDPR Art. 22 contestation timing, organizations subject to Art. 22 must provide individuals with the right to obtain human intervention, express their point of view, and contest the decision; the contestation response SLA is defined per workflow per SR-Processes requirements. Named owner: Privacy/Legal + workflow owner.
• EU AI Act Art. 73, serious incident involving an Annex III High-risk AI system; reporting timeline per the implementing act; escalate immediately to Privacy/Legal on any Annex III-classified workflow incident. Named owner: Privacy/Legal + executive sponsor.
• EU AI Act Art. 26.5, deployer obligation to suspend use of the AI system if non-conformance with Art. 26 deployer duties is discovered. Named owner: Privacy/Legal + CISO. Evaluation triggered by: wrongful-decision incident, HITL failure incident, disclosure failure incident.
• HIPAA breach notification, 60-day discovery-to-notification ceiling for covered entities and business associates where AI/HAI workflow incidents involve PHI. Named owner: Privacy/Legal.
• FCRA adverse-action, adverse-action notices required within the applicable timeframe when AI/HAI decision pipelines produce adverse credit, employment, or insurance decisions. Named owner: Compliance / Legal.
• NYC LL 144 bias audit, annual bias audit requirement for automated employment decision tools used in NYC; audit findings must be publicly posted; IM-Processes tracks open audit findings from the most recent LL 144 audit cycle. Named owner: Compliance.
• CO SB-21-169 insurance unfair-discrimination, Colorado SB 21-169 requires insurers using external consumer data and AI/ML to demonstrate non-discrimination; IM-Processes tracks CO-applicable decision-pipeline incidents. Named owner: Compliance / Legal.
• FINRA model-risk, for financial-sector decision pipelines, FINRA model-risk guidance requires model validation, ongoing monitoring, and documentation of model limitations; material model-risk incidents are tracked in IM-Processes. Named owner: Compliance / Legal.

Every Critical or blocker 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 detection, IM 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-Processes: pattern-update request if the incident exploited an architectural gap.
• SR-Processes: requirements-pack update request if the incident exploited a missing or vague requirement.
• EG-Processes: training-content update request if the incident indicates a literacy gap in the workflow-operations population.
• ML-Processes: detection-update request (new detection, tuned query, or evidence that an existing detection's query can be sharpened).

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 workflow incident scenario (rotate through the seven playbook classes).
• Regulatory SLA tracker reviewed weekly; named owner confirms clock start dates and status.
• Aging pockets, number of issues aging past SLA tracked; trending down.

Effectiveness Metrics (business value)

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

Success Criteria

• Single AI/HAI workflow issue backlog established with standardized metadata; triage rubric with AI-specific severity definitions published.
• Seven AI-specific workflow incident playbook entries published (wrongful-decision containment, HITL failure / rubber-stamp, disclosure failure, class-shift / fairness (security-intersection only), content-generation harmful output, knowledge-management RAG-poisoning, shadow-AI-in-process), each with named roles, containment steps, evidence-capture instructions, and SLA targets.
• Regulatory SLA tracker live covering GDPR Arts. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations; 100% adherence in the last 90 days.
• Post-incident review loop wired to SA-Processes, SR-Processes, EG-Processes, and ML-Processes; every Critical/blocker 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-Processes L2 risk tier; establish dedicated on-call rotation and escalation paths for Critical-tier workflows; and automate cross-domain signal flow so that Processes domain incidents affecting Software or Data domains generate coordinated response

At this level, incident response differentiates by tier. Critical-tier workflows have a dedicated on-call rotation, pre-staged executive escalation paths, and a 24/7 coverage model. Post-incident reviews auto-feed SA, SR, EG, and ML queues via integration. When a Processes domain incident affects cross-domain scope (a workflow incident whose root cause is a Software-domain agent rogue action, or a Data-domain training-corpus poisoning that affected a decision pipeline), coordinated cross-domain response is activated.

Dependencies

• IM-Processes L1 (required): unified backlog, AI-specific workflow incident playbook, and regulatory SLA tracker must be operational before per-tier calibration adds meaningful depth.
• SM-Processes L2 (required): risk-tier rubric and tier-treatment matrix drive response intensity.
• ML-Processes L2 (required): richer detections (anomaly-based, cross-workflow correlated) feed severity classification with higher-fidelity signals; tier-calibrated logging depth makes evidence collection faster at L2.
• Supports / unblocks: ML-Processes L2 detection tuning loop (IM L2 post-incident reviews produce more targeted detection updates); SA-Processes L2 pattern evolution (incidents from Critical-tier workflows with IaC-encoded patterns drive conformance-test updates).

Desired Outcomes

• Response intensity matches tier, Critical-tier workflow 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, SR, EG, and ML practice backlogs via a defined integration rather than manual handoff.
• Cross-domain coordination is explicit: a Processes-domain incident that implicates the Software domain (an agent rogue action affecting a workflow) or the Data domain (a data-poisoning event that corrupted a decision pipeline's training data) activates a named cross-domain coordination protocol.
• Tier-movement in the SM-Processes inventory auto-triggers IM policy changes.

Activities

A) Tier-calibrated incident playbook and on-call

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

• Critical tier: full IM activation, CISO or delegate + Privacy/Legal + workflow deployer-duty owner + executive sponsor notification; ≤1 hour acknowledgement; ≤4 hours containment-action initiated; 24/7 on-call coverage with a named AI/HAI workflow incident responder in each on-call rotation; pre-staged communication templates (internal, customer-facing, regulatory) loaded and reviewed quarterly.
• High tier: scoped response, AppSec lead + Privacy/Legal (if regulated data involved) + deployer-duty 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 handoff protocol, on-call briefing including the current Critical-tier workflow list and their active detection set.

B) Post-incident review auto-flow integration

Wire IM-Processes's post-incident review outputs to downstream practice backlogs via a defined integration:

• SA-Processes pattern-update request → SA-Processes architecture-backlog ticket (auto-created with IM incident reference linked).
• SR-Processes requirements-pack update request → SR-Processes pack-backlog ticket (auto-created with requirements-pack version and failing requirement row linked).
• EG-Processes training-content update request → EG-Processes training-backlog ticket (auto-created with affected population segment and incident summary linked).
• ML-Processes detection-update request → ML-Processes 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.

C) Cross-domain coordination protocol

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

• Processes → Software: a production agent (Software domain) makes unauthorized writes to a business-process workflow (customer records, financial records, case management system); activates Software-domain IM's agent-rogue-action playbook alongside Processes-domain wrongful-decision containment play; named Software-domain IM contact on file.
• Processes → Data: a decision-pipeline workflow's AI model is producing anomalous outputs attributable to training-corpus poisoning (Data domain); activates Data-domain IM's training-corpus-poisoning playbook alongside Processes-domain class-shift / wrongful-decision play; named Data-domain IM contact on file.
• Processes → Vendors: a third-party AI model embedded in a decision pipeline produces harmful outputs attributable to a vendor model update; activates Vendors-domain IM's vendor-material-change playbook alongside Processes-domain wrongful-decision containment; named Vendors-domain IM 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 playbook review cadence, quarterly, tested in a tabletop covering the tier's specific workflow list.
• On-call rotation health, no uncovered periods; hand-off briefing completed per rotation; on-call briefing includes updated Critical-tier workflow list.
• 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 workflow incidents (time from first ML 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.
• Cross-domain coordination saves time vs. uncoordinated parallel response, measured as MTTU and MTTC on multi-domain incidents.

Success Criteria

• Critical-tier MTTA ≤1 hour; MTTC ≤4 hours; 24/7 on-call coverage with a documented rotation.
• Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML backlogs; ≥90% of downstream practice owners responding within 14 days.
• Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI workflow incidents.
• Tier-movement in SM-Processes inventory auto-triggers IM configuration update (on-call path, playbook variant, SLA targets).

Maturity Level 3

Objective: Contribute workflow incident patterns and playbook templates to OECD AI, ISO/IEC 42005, and sector ISACs; automate runbook decisioning for low-severity, high-confidence detections; and benchmark MTTR against industry peers

At this level, IM-Processes is a contributor to the AI-assurance workflow-incident ecosystem. Anonymized workflow incident classification schemes, AI-specific severity anchors, and playbook templates for the seven primary AI/HAI workflow incident classes are contributed to OECD AI, ISO/IEC 42005, CSA AI Safety Initiative, and sector ISACs. Pre-authorized automated containment actions execute for low-severity, high-confidence detections without human triage delay. MTTR benchmarks are established from ISAC and peer data.

Dependencies

• IM-Processes L2 (required): tiered playbook, post-incident review auto-flow, cross-domain coordination must be operational and producing clean incident-pattern data before contributions to external bodies are substantive.
• PC-Processes 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-Processes L3 (required): detection-as-code and high-confidence behavioral anomaly detection signals provide the automation trigger quality needed for pre-authorized runbook execution.

Desired Outcomes

• Industry-standard incident classification and response playbooks for AI/HAI workflow incidents are contributed and maintained, OECD AI, ISO/IEC 42005, and sector ISACs cite the org's artifacts.
• Pre-authorized automated containment actions execute for a defined set of low-severity, high-confidence incident types, reducing MTTR for these classes to minutes from hours.
• MTTR benchmarks are established from ISAC and peer data; performance against benchmarks is reported to the sponsor quarterly.
• Contributions to ISO/IEC 42005 AI incident management documentation reflect the org's first-party workflow incident experience.

Activities

A) Industry-coordinated incident sharing and contribution

Participate in sector ISAC AI incident-sharing programs and standards bodies:

• Consume ISAC AI incident feeds; integrate relevant advisories into the IM-Processes external-advisory source.
• Contribute anonymized incident classification (incident type, archetype, containment play used, regulatory SLA activated, MTTR achieved) on a per-incident-class basis; target ≥4 ISAC contributions per year.
• Contribute to AI workflow incident taxonomy standards:
• OECD AI, AI/HAI workflow incident classification schema, playbook template structures, regulatory SLA tracking models.
• ISO/IEC 42005, AI incident management standard; contribute workflow-specific incident patterns (wrongful-decision, HITL failure, disclosure failure, RAG-poisoning containment plays) as candidate process guidance.
• CSA AI Safety Initiative, workflow incident severity-anchor definitions, evidence-capture standards for deployer-duty compliance.

Target: ≥4 ISAC contributions per year; ≥2 OECD AI / ISO/IEC 42005 / CSA contributions per year; all contributions anonymized, legally vetted, and maintained.

B) Pre-authorized automated runbook decisioning

Define and publish a pre-authorization policy for automated containment actions, 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):
• Pause a Low-tier or Medium-tier HITL workflow step when a reviewer-capacity saturation detection fires above 95% confidence (queue depth exceeds SLA breach threshold), pauses new item routing pending human escalation acknowledgement.
• Quarantine a knowledge-management corpus segment when a RAG-poisoning detection fires with a specific flagged document ID on a non-Critical-tier workflow, removes the flagged document from the retrieval allowlist pending review.
• Block execution of an unrecognized AI step (shadow-AI-in-process) in a Low/Medium-tier workflow when the ML-Processes shadow-AI detection fires, freezes the step pending inventory intake.
• Rollback a disclosure template to the last registry-registered version when a disclosure-suppression detection fires on a non-Critical-tier customer-facing flow.
• Pre-authorized actions for Critical-tier workflows require human confirmation within 15 minutes; the action fires after that window if no human confirmation arrives, with executive notification at fire time.
• All pre-authorized actions produce: a full audit log entry in the IM-Processes backlog, a human-review ticket auto-created at the time of execution, and a notification to the workflow's deployer-duty owner.
• Pre-authorization policy reviewed quarterly by Privacy/Legal and the executive sponsor.

C) MTTR benchmarking

Establish MTTR benchmarks from:

• ISAC AI incident data exchanges.
• OECD AI incident database contributions from peer organizations.
• Peer roundtables (CISO and AI-safety practitioner communities; workflow governance practitioners).

Publish a quarterly MTTR benchmark brief to the program sponsor:

• MTTR per incident class vs. benchmark (wrongful-decision containment, HITL failure, disclosure failure, RAG-poisoning, shadow-AI-in-process, content-generation harmful output, class-shift/fairness).
• 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 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.
• Contribution pipeline health, ≥2 taxonomy / playbook / standards 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.

Effectiveness Metrics (business value)

• MTTR for pre-authorized containment classes drops from hours to minutes, quantified per class per quarter.
• Mean-time-to-contain on Critical-tier workflow incidents continuing to compress as ISAC-shared intelligence accelerates root-cause identification.
• External recognition, citations or adoption of contributed AI workflow incident taxonomy artifacts by OECD AI, ISO/IEC 42005, CSA, or sector ISACs.

Success Criteria

• ≥4 ISAC AI incident contributions per year; ≥2 OECD AI / ISO/IEC 42005 / CSA contributions 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 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 workflow issue backlog operational with standardized metadata capturing ≥95% of AI/HAI workflow issues from all source practices. - Seven AI-specific workflow incident playbook entries published (wrongful-decision containment, HITL failure/rubber-stamp, disclosure failure, class-shift/fairness (security-intersection only), content-generation harmful output, knowledge-management RAG-poisoning, shadow-AI-in-process) 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. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations; 100% adherence in the last 90 days. - Post-incident review loop wired to SA-Processes, SR-Processes, EG-Processes, and ML-Processes, every Critical/blocker incident produces a review within 14 days with named update outputs. - 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 workflow briefing. - Post-incident review auto-flow integration live; 100% of Critical-tier review outputs auto-routed to SA/SR/EG/ML backlogs; ≥90% of downstream practice owners responding within 14 days. - Cross-domain coordination protocol published and used for 100% of multi-domain AI/HAI workflow incidents; named cross-domain contacts for Software, Data, and Vendors domains verified quarterly. - Tier-movement in SM-Processes inventory auto-triggers IM configuration updates.

Level 3: - ≥4 ISAC contributions per year; ≥2 OECD AI / ISO/IEC 42005 / CSA contributions 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 incident classes; deltas linked to investment proposals.

Common Pitfalls

Level 1: - ❌ "Single backlog" created but source practices continue filing into separate queues, ST-Processes failures stay in the CI dashboard, ML-Processes alerts route to a Slack channel, and TA-Processes residual risks live in a spreadsheet; the backlog achieves only ~40% coverage and the ≥95% target is never achieved. - ❌ Triage rubric severity anchors are generic (probability × impact without AI-specific axes), a wrongful automated decision affecting a named individual under an Annex III workflow is triaged Medium because the rubric has no axis for EU AI Act Art. 73 applicability. - ❌ Playbook entries published but roles not pre-assigned, on the first wrongful-decision incident, the team spends the first 30 minutes figuring out who notifies affected persons, not notifying them. - ❌ GDPR Art. 22 contestation timing is tracked as an obligation but the clock-start condition is not defined, when a customer submits a contestation, nobody confirms whether the internal awareness event that starts the SLA was the customer's submission or an earlier ML-Processes detection. - ❌ Post-incident reviews completed but outputs filed in a document that no downstream practice owner reads, SA-Processes, SR-Processes, EG-Processes, and ML-Processes do not update; the same incident class recurs with the same root cause six months later. - ❌ Shadow-AI-in-process incidents are treated as vendor intake events (routed to Vendors-domain IM) rather than triggering the Processes-domain shadow-AI-in-process playbook, the data-flow assessment and GDPR Art. 33 evaluation never happen.

Level 2: - ❌ Critical-tier activation criteria are vague, wrongful-decision incidents involving Annex III workflows stay in the standard queue until the deployer-duty 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 ML-Processes team closes the detection-update ticket as "acknowledged" without updating the detection query; the feedback loop is nominally present but produces no change. - ❌ Cross-domain coordination protocol exists on paper but no IC is pre-designated, the first cross-domain incident where a Software-domain agent rogue action writes to a Processes-domain workflow produces ownership confusion; both domains wait for the other to take the IC role. - ❌ 24/7 on-call coverage implemented but the on-call briefing is stale, new Critical-tier workflows are not in the briefing; on-call responders do not know the pause-workflow path for recently tiered workflows.

Level 3: - ❌ ISAC participation limited to consuming feeds, contributions are absent; the org is a free-rider; influence over AI workflow incident taxonomy standards diminishes. - ❌ Pre-authorized automated containment fires on a Critical-tier workflow because the confidence threshold was set too loosely, a false positive pauses a production customer-facing flow handling thousands of active sessions; the pre-authorization policy had no Critical-tier exception check. - ❌ MTTR benchmark brief cites benchmarks from organizations with fundamentally different AI/HAI workflow portfolio scale, "we are at benchmark" is true but the benchmark set was chosen to flatter rather than stretch. - ❌ OECD AI / ISO/IEC 42005 contributions submitted once and never updated, novel workflow incident classes evolve; the org's contribution reflects patterns 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 detection saw and why the threshold triggered; post-incident root-cause reviews are impaired.

Practice Maturity Questions

Level 1: 1. Is there a single AI/HAI workflow issue backlog with standardized metadata (source, affected workflow linked to SM-Processes inventory, severity rubric anchored to AI-specific axes, wrongful automated decision / HITL failure / disclosure failure / regulated-data breach for Critical; confirmed control failure with potential impact for High; etc., owner, SLA, regulatory flag, evidence link) capturing ≥95% of issues from all source practices (TA, SR, DR, IR, ST, ML, external)? 2. Is the AI/HAI workflow incident playbook published with seven named AI-specific workflow incident classes (wrongful-decision containment, HITL failure/rubber-stamp, disclosure failure, class-shift/fairness (security-intersection only), content-generation harmful output, knowledge-management RAG-poisoning, shadow-AI-in-process), 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. 22/33, EU AI Act Arts. 26.5/50/73, HIPAA, FCRA adverse-action, FINRA model-risk, NYC LL 144, CO SB-21-169, and sector-specific obligations, with 100% adherence in the last 90 days, and does every Critical/blocker incident produce a post-incident review within 14 days with named update outputs flowing to SA-Processes, SR-Processes, EG-Processes, and ML-Processes?

Level 2: 1. Is a tier-calibrated 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 workflow briefing, and tier-movement in the SM-Processes inventory automatically triggering IM configuration updates within 14 days (Critical re-tier)? 2. Is a post-incident review auto-flow integration live routing Critical-tier review outputs to SA/SR/EG/ML 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 workflow incidents, with named cross-domain contacts for Software, Data, and Vendors 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 workflow incident-classification entries per year to sector ISACs and ≥2 contributions per year to OECD AI, ISO/IEC 42005, or CSA AI Safety Initiative, with all contributions maintained current, legally vetted, and tracked for external adoption? 2. Are ≥3 pre-authorized automated containment actions live (HITL-step pause, RAG-corpus quarantine, shadow-AI-step freeze, or disclosure-template rollback classes), 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 incident class and per tier against ISAC-sourced and peer-sourced benchmarks, with Critical-tier MTTR at or below benchmark for ≥4 of 7 incident classes and deltas above benchmark linked to specific practice gaps and investment proposals?

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