{"description":"Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.","edges":[{"id":"e-analyze-scope-and-impact-execute-notifications","source":"analyze-scope-and-impact","target":"execute-notifications"},{"id":"e-analyze-scope-and-impact-eradicate-and-recover","source":"analyze-scope-and-impact","target":"eradicate-and-recover"},{"id":"e-eradicate-and-recover-classify-disposition","source":"eradicate-and-recover","target":"classify-disposition"},{"id":"e-execute-notifications-classify-disposition","source":"execute-notifications","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clean"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-IR-04","UC-IR-05","UC-IR-06","UC-IR-07","UC-IR-08","UC-IR-09","UC-IR-10","UC-GOV-24","UC-ASSET-11","UC-BCDR-06","UC-BCDR-08","UC-BCDR-09","UC-DATA-15"],"department":"operations","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-incident-management-lifecycle","contentDigest":"sha256:77c1602449f9eb3f1137db475d9bf0562db8468f039c984fdbba64e37e5a422a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:77c1602449f9eb3f1137db475d9bf0562db8468f039c984fdbba64e37e5a422a","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-incident-management-lifecycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-incident-management-lifecycle","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001","gdpr","nydfs-500"],"teams":["operations","it","compliance-legal"]},"name":"Incident Management Lifecycle","nodes":[{"data":{"description":"Accountable incident owner: Judge factual impact and data exposure, set evidence-based severity and ownership, and approve the single linked incident record and response workplan.","formData":{"fields":[{"key":"what_was_observed","label":"What did you observe? Describe it factually, without interpretation","required":true,"type":"textarea"},{"key":"detection_timestamp","label":"Date you first became aware of it","required":true,"type":"date"},{"key":"incident_kind","label":"Type of incident","options":[{"label":"Operational","value":"operational"},{"label":"Security","value":"security"},{"label":"Not sure","value":"unsure"}],"required":true,"type":"select"},{"key":"systems_or_data_affected","label":"Systems, processes, or data you believe are affected","required":true,"type":"textarea"},{"key":"regulated_data_possible","label":"Personal, customer, or otherwise regulated data may be involved","required":false,"type":"checkbox"},{"key":"actions_already_taken","label":"Containment or mitigation already taken, and by whom","required":true,"type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Obtain the reporter’s facts, establish the detection clock and linked incident record, and approve the assessed impact, severity, ownership and response scope.\n\n**Inputs**\n- The reporter's account of what was observed, submitted on this step's form: the incident kind (operational or security), the detection timestamp, the systems or data believed affected, and any containment or mitigation already taken.\n- The shared issue item type — incidents are captured here (there is no separate incident item type), with the intake source preset to the incident category.\n- The process, control, and risk taxonomy for linkage, plus matched controls' owners as owner candidates.\n- Issue history and the risk universe, to route ownership and avoid duplicate records. No upstream workflow feeds this step; the trigger is incident detection itself.\n- The approved incident record (kind noted in `description`, `identified_date`, initial severity, linked process/controls/risks).\n- System and asset inventory, data classification, and process ownership needed to trace blast radius.\n- For a data incident: the categories and record counts of personal or regulated data potentially exposed (these drive breach-notification thresholds).\n- KRI/KPI data and issue history for comparable prior incidents.\n\n**Procedure**\n*Autonomous preparation incorporates Open incident record; Accountable incident owner reviews the combined evidence.*\n1. Send the intake form to the person who detected or reported the incident and work from their answers: title; what happened (folding in any containment/mitigation already taken); the incident kind; the detection timestamp recorded as `identified_date` (this starts the incident clock); and an initial severity.\n2. Set severity from the impact assessment rather than from the reporter's alarm level. A security incident defaults to the highest severity pending investigation — propose that default and let the owner override. Each severity carries an SLA window used later to set remediation deadlines: High 90 days, Medium-High 270 days, Medium 540 days, Low 720 days from detection.\n3. Resolve the affected process and control: search the process/control/risk taxonomy for topic overlap with the reported description, match existing controls and risks by tag, and read the matched controls' owners as strong owner candidates. Link the incident to the affected process, controls, and risks and propose the accountable owner from that linkage.\n4. Lock the response workplan: confirm final scope, the accountable owner, target due dates, the evidence each downstream step must produce, and review expectations — so scope does not drift once work begins.\n5. Create the incident issue item with intake fields, severity, `identified_date`, proposed owner, and process/control/risk linkages populated, as a suggested change for a person to review and approve. Never auto-commit; surface the proposed severity, owner, and linkages with a one-paragraph rationale so the reviewer can override.\n6. Establish the timeline: first detection (`identified_date`), estimated first occurrence, and the window of exposure. A longer undetected window widens scope.\n7. Map the blast radius: enumerate affected systems, applications, and business processes from the linked control/process records; for a security incident, trace lateral exposure (accounts, credentials, connected systems).\n8. Quantify data impact: identify the data categories affected, whether any is personal or regulated (GDPR personal data, NYDFS nonpublic information), and an estimated record count. Flag any threshold that could trigger a statutory notification.\n9. Re-score severity against the evidence and reconcile with the initial severity set at intake; if it moves, record the change and its driver (an upgrade shortens the SLA and may add notification obligations).\n10. Assess control failure: identify which control(s) failed or were absent — this seeds CAPA and the later disposition — and whether the same failure exposes other processes.\n\n**Record in AssureSwarm**\n- **Item create** — the incident as an Issue item (coach-item-create) with `description`, `severity`, `source: management_identified`, `identified_date` (the detection clock), and `issue_owner`. Issue has no incident-specific `issue_type` value and no field for the incident kind, so the kind (operational vs security) is recorded in the `description` — an honest fallback (there is no native Incident type).\n- The form on this step, answered by the person who detected or reported the incident, captures their factual account: what was observed, when they became aware, the incident kind, the systems or data affected, whether regulated data may be involved, the containment already taken, with identity/contact supplied by the named assignment; attach any supporting screenshots or logs as source documents.\n- **Item relationships** — link the incident Issue to the affected Process, Control, and Risk items resolved from the taxonomy query (coach-query-data): Issue ↔ Process, Issue ↔ Control, Issue ↔ Risk, with the accountable owner proposed from the matched `Control.control_owner`.\n- **Item field update** — record the locked workplan scope, owners, due dates, and evidence expectations in the incident Issue's `remediation_plan`/`description`.\n- **Step document** — attach the scope-and-impact assessment to this step (coach-document-upload); the system/asset inventory and data classification it rests on have no native type and are supplied as uploads on this step (no native Asset type).\n- **Item field update** — summarize affected systems, data categories, and record counts in the incident Issue's `description`, and re-score `severity` if the evidence moved it, noting the driver (coach-item-update).\n- **Item relationships** — link any additional Control or Risk items discovered in scope to the incident Issue.\n\n**Exit criteria**\nJudge factual impact and data exposure, set evidence-based severity and ownership, and approve the single linked incident record and response workplan.\nAn approved incident Issue item exists with `source: management_identified`, the kind noted in `description`, `identified_date`, `severity` and its SLA window, containment summary, accountable owner, and Process/Control/Risk linkage populated, and the workplan (scope, owners, due dates, evidence) is locked — ready for scope-and-impact analysis and the notification clock.\nA documented scope-and-impact assessment naming affected systems, data categories and counts, control failures, and a reconciled severity is attached to the incident, with any notification-threshold flags raised for notification deadline calculation.\n\n**Form recipient** — this step's form is answered by the person who detected or reported the incident, outside the entire incident execution and approval team. A participating executor records their firsthand account in the native result. Send it with a form assignment; the owner's own work goes in the step result.","label":"Analyze scope and impact","performedBy":{"agent":"grc-artist","note":"incident-intake router (open incident issue: kind, detection clock, severity SLA, containment, control linkage; locks response workplan) incident scope, blast-radius, and data-impact assessment","primitives":["coach-item-create","coach-form-fill","coach-query-data","coach-document-upload","coach-item-update"]}},"id":"analyze-scope-and-impact"},{"data":{"description":"Named notification approver for each internal/regulatory audience: Judge notification applicability and authorize each precise notice and recipient set before sending, with detection-based statutory and remediation clocks retained.","instructions":"**Objective** — Calculate detection-based deadlines and obtain the designated person’s approval for every required notification before sending and recording delivery.\n\n**Inputs**\n- The incident's detection timestamp (`identified_date`) and reconciled severity from the record.\n- The applicable regulatory notification obligations and their authority sources (e.g., GDPR Art. 33 72-hour supervisory-authority window; NYDFS 500.17 72-hour superintendent window; contractual customer-notice terms).\n- The notification-threshold flags raised in the scope-and-impact assessment.\n- Owners and escalation thresholds for each deadline.\n- The incident record with severity, owner, and watchlist.\n- The notification deadlines, authority sources, and owners calculated in this checkpoint, plus the scope-and-impact assessment that supplies what must be disclosed.\n- Internal stakeholder and external regulator distribution lists and the approved message templates.\n\n**Procedure**\n*Autonomous preparation incorporates Start notification clock; Named notification approver for each internal/regulatory audience reviews the combined evidence.*\n1. Anchor every deadline to `identified_date`; do not reset the clock on later discovery.\n2. Derive the remediation SLA window from severity and record it in `target_remediation_date` on the incident Issue (there is no `sla_due` field — the single remediation deadline lives in `target_remediation_date`): High 90 days, Medium-High 270 days, Medium 540 days, Low 720 days from detection.\n3. Capture each external regulatory notification deadline separately — these run on their own statutory clocks, often far shorter than the remediation SLA (for example a 72-hour breach-notification window). Record each deadline, its authority source, and its owner.\n4. Cross-check the scope assessment's threshold flags: if regulated-data exposure crosses a reporting threshold, ensure the matching statutory clock is recorded; if it does not, document why no external notification is due.\n5. Because these clock values update the existing incident item rather than create a new one, record them in the native result and apply the reviewed values to the record; flag any deadline already at risk given elapsed time.\n6. Route by severity: a High-severity incident (and a Medium-High security incident) triggers an urgent escalation notice to the incident owner and watchlist; lower-severity incidents ride the normal approval flow with no extra escalation.\n7. For each required external regulatory notification, draft the notice against its statutory deadline using the scope assessment's facts (affected data categories, counts, timeline), and route it to the approver for that authority.\n8. Send only after human approval — the agent prepares drafts and stages recipients, but a person authorizes every send. Nothing leaves the organization unapproved.\n9. Capture each sent notice, its recipients, and its timestamp as evidence linked to the incident; record the deadline as met or missed.\n10. Where a potential obligation does not apply, document the non-applicability with its rationale rather than leaving it blank.\n\n**Record in AssureSwarm**\n- **Item field update** — set the remediation SLA deadline in the incident Issue's `target_remediation_date` (there is no `sla_due` field; the single remediation deadline lives here), from the reviewed deadline calculation.\n- **Step result** — record each external regulatory notification deadline, its authority source, and its owner in the native result (Issue has no per-authority notification-deadline field, and the regulatory-obligation catalog has no native Obligation type — it is kept as a step reference document). Framework applicability is partly encoded on the linked Control items via `Control.framework` (gdpr, nydfs-500), queried with coach-query-data.\n- Escalate any imminent deadline to its owner.\n- **Step documents** — upload each sent notice as evidence (coach-document-upload) and link it to the incident Issue (coach-document-link).\n- **Step result and native approvals** — record audience, severity trigger and deadline met/missed in the result, linked to the named approver’s native approval and sent-notice evidence.\n\n**Exit criteria**\nJudge notification applicability and authorize each precise notice and recipient set before sending, with detection-based statutory and remediation clocks retained.\nAll remediation and notification deadlines are recorded against the incident with named owners and authority sources, threshold applicability is documented either way, and any imminent deadline is escalated.\nEvery required internal and regulatory notification is approved, sent, and evidenced against the incident within its deadline, or its non-applicability is documented.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` drafts and stages each severity-routed notification to its recipients for human approval before send.","label":"Execute notifications","performedBy":{"agent":"grc-artist","note":"incident notification and SLA clock engine per-severity incident notification routing engine","primitives":["coach-form-fill","coach-query-data","coach-document-upload","coach-notify"]}},"id":"execute-notifications"},{"data":{"description":"Remove the root cause and restore affected systems to a verified good state","instructions":"**Objective** — Contain, eradicate, and recover from the incident — removing the root technical or process cause and restoring affected systems and processes to a verified good state — and evidence each action.\n\n**Inputs**\n- The scope-and-impact assessment (affected systems, data, control failures).\n- The incident record with severity and owner.\n- For a security-category incident, the containment and forensics handoff package from the Cybersecurity Incident Response workflow, which owns the real-time SOC mechanics; this step consumes its output rather than duplicating it.\n- Recovery/restoration runbooks and BCDR procedures for the affected systems (no native type — supplied as step-linked documents).\n\n**Procedure**\n1. Confirm containment is in place and holding (isolation, credential resets, blocking) before eradication; if containment relies on the Cybersecurity Incident Response handoff package, verify it covers every system in scope.\n2. Eradicate the root cause: remove malware or persistence, close the exploited gap, revoke compromised access, or correct the failed process/configuration that produced an operational incident.\n3. Recover: restore systems and data from verified-clean sources, validate integrity, and monitor for recurrence before returning to production; follow BCDR restoration procedures where invoked.\n4. Verify: confirm affected services are healthy, the exposure window is closed, and no indicators of continued compromise remain; capture verification evidence.\n5. Record residual risk that eradication did not fully close — this feeds the disposition and CAPA.\n\n**Record in AssureSwarm**\n- **Step documents** — attach containment, eradication, and recovery evidence to this step (coach-document-upload); link the Cybersecurity Incident Response containment/forensics handoff package into this step if the incident is security-category (coach-document-link). BCDR/recovery runbooks have no native type and are linked as step documents.\n- **Item field update** — update the incident Issue with recovery status and residual-risk notes in its `management_response`/`description` (coach-item-update).\n\n**Exit criteria** — The root cause is eradicated, affected systems and processes are recovered and verified, all actions are evidenced, and residual risk is recorded — ready for lessons-learned and CAPA.","label":"Eradicate and recover","performedBy":{"agent":"grc-artist","note":"containment, eradication, and BCDR recovery evidence","primitives":["coach-document-upload","coach-item-update"]}},"id":"eradicate-and-recover"},{"data":{"decisionField":"disposition_path","description":"Incident owner and GRC disposition authority: Judge root causes, response failures and residual exposure and select clean closure, corrective work or significant-issue escalation.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Analyze lessons and root causes, record proposed corrective/preventive actions and choose the incident’s appropriate closure path.\n\n**Decision criteria**\nInputs for preparation: - The scope-and-impact assessment (control failures identified) and the eradicate-and-recover evidence (what was fixed and the residual risk).\n- The notification record (were deadlines met; any process gaps in the response itself).\n- The linked controls and risks and the issue history, for recurrence patterns.\n\n*Autonomous preparation incorporates Run lessons learned and CAPA; Incident owner and GRC disposition authority reviews the combined evidence.*\n1. Run a structured root-cause analysis (e.g., 5-whys or fishbone) to the true cause, not the symptom; distinguish the technical trigger from the control or process weakness that let it happen or go undetected.\n2. Separate corrective actions (fix this instance / close the specific gap) from preventive actions (stop the class of failure recurring — control redesign, monitoring, training).\n3. Assess whether a linked control failed by design or by operation, and whether the control itself needs updating; note any control that should be added.\n4. For each CAPA, assign an owner, a due date, interim mitigation, and the validation evidence that will prove it effective; tie each to the control or risk it strengthens.\n5. Capture response-process lessons (detection lag, notification friction) so the incident program itself improves.\n\n- `clean` (No reportable gap): the root cause is understood, the control held or the gap was immaterial and already closed by recovery, no CAPA of consequence remains, and no escalation threshold is met. Proceeds straight to the final package.\n- `remediate` (Remediation required): the root-cause analysis surfaced control gaps needing owned corrective/preventive actions that are not yet complete, and residual risk is within appetite once the action plan executes. Routes to build an owned action plan.\n- `escalate` (Escalate significant issue): the incident is a significant or material issue — regulatory exposure, a missed statutory deadline, residual risk outside appetite, or a board/executive reporting threshold met. Routes to the risk owner, GRC lead, executive sponsor, or board delegate for escalation or a documented risk acceptance.\n\n**Record in AssureSwarm**\n- **Step document** — attach the root-cause analysis to this step (coach-document-upload), and record its conclusion in the incident Issue's `root_cause` (coach-item-update).\n- **Item create + relationships** — record each CAPA as a child Issue item (coach-item-create) with `issue_owner`, `target_remediation_date`, `remediation_plan`, and `recommendation` (the validation evidence), linked to the incident Issue and to the Control or Risk it strengthens (coach-items-link): CAPA Issue ↔ incident Issue, CAPA Issue ↔ Control/Risk.\n- **Item field update** — where the incident revealed a design or operating weakness, update the linked Control items (e.g. `Control.frequency`, `Control.automation`) and Risk items (`Risk.residual_rating`, `Risk.likelihood`/`Risk.impact`) (coach-item-update).\n- Submit the `disposition_path` SELECT with the chosen branch value (`clean`, `remediate`, or `escalate`).\n- Record the decision rationale and evidence references in the native step result, and name the decision owner or approver.\n\n**Exit criteria**\nJudge root causes, response failures and residual exposure and select clean closure, corrective work or significant-issue escalation.\nA documented root-cause analysis and a set of owned, dated CAPAs (each tied to a control or risk with validation evidence) are recorded, and any control update is captured — ready for disposition.\nThe `disposition_path` form is submitted with a documented rationale and owner, and the two unused branches are prunable because their edge values match the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","note":"root-cause analysis and CAPA generation","primitives":["coach-item-create","coach-items-link","coach-item-update","coach-document-upload"]}},"id":"classify-disposition"},{"data":{"description":"Build an owned, dated remediation plan that closes the exposed control gaps","instructions":"**Objective** — Build an owned, dated remediation action plan that closes the control gaps the incident exposed and drives residual risk back within appetite.\n\n**Inputs**\n- The disposition decision (`remediate`) and its rationale.\n- The root-cause analysis and CAPA list from lessons-learned, with the specific control and process gaps.\n- Control and risk owners and the appetite thresholds the remediation must satisfy.\n\n**Procedure**\n1. For each gap, state the root cause, the corrective action, and the accountable owner — a named person, not a team.\n2. Set a due date proportionate to severity and the remediation SLA window already recorded on the incident; sequence any dependencies.\n3. Define interim mitigation for any gap that cannot be closed before its due date, so exposure is bounded in the meantime.\n4. Define the validation evidence that will demonstrate each action is effective, and the reporting cadence to the owner and governance.\n5. Confirm the post-remediation residual risk lands within appetite; if it will not, flag for escalation instead.\n\n**Record in AssureSwarm**\n- **Item create + relationships** — record each action as a child Issue item (coach-item-create) with `issue_owner`, `target_remediation_date`, `remediation_plan` (interim mitigation), and `recommendation` (validation evidence), linked to the incident Issue and the affected Control (coach-items-link): action Issue ↔ incident Issue, action Issue ↔ Control.\n- **Item field update** — capture the reporting cadence in the action Issue's `remediation_plan` and confirm the linkage to the incident and its controls (coach-item-update).\n\n**Exit criteria** — Every exposed gap has an owned, dated action with interim mitigation, validation evidence, and a reporting cadence, and post-remediation residual risk is confirmed within appetite (or flagged for escalation).","label":"Create action plan","performedBy":{"agent":"grc-artist","note":"owned remediation action-plan builder","primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Bring a significant incident to the accountable authority for a governed decision","instructions":"**Objective** — Bring a significant incident to the accountable authority for a governed decision — escalate for direction or formally accept the residual risk — with a defensible decision memo.\n\n**Inputs**\n- The disposition decision (`escalate`) and its rationale.\n- Quantified impact and residual risk from the scope assessment and root-cause analysis, and the appetite position it breaches.\n- The escalation path: risk owner, GRC lead, executive sponsor, or board delegate per the governance model.\n\n**Procedure**\n1. Prepare a decision memo: what happened, quantified impact (financial, regulatory, operational), root cause, residual risk versus appetite, and the options with a recommendation.\n2. Quantify impact in the organization's terms (loss estimate, regulatory penalty exposure, customers or records affected) so the decision-maker can weigh it.\n3. Route to the correct authority by threshold; capture their decision — direction to remediate, formal risk acceptance with conditions, or further escalation.\n4. If risk is accepted, record the conditions, the acceptance owner, the expiry or review date, and the monitoring trigger that reopens it.\n5. Define follow-up ownership so the escalation does not stall.\n\n**Record in AssureSwarm**\n- **Step document** — attach the decision memo to this step (coach-document-upload).\n- **Item field update** — record the authority's decision, conditions, and owner in the incident Issue's `management_response` (coach-item-update).\n- **Risk acceptance** — for a formal risk acceptance, set `treatment: accept` on the linked Risk item and record its `risk_owner`, plus the acceptance conditions, the review/expiry date, and the monitoring trigger that reopens it. (A standalone policy waiver would instead be an Issue with `issue_type: policy_exception`, `exception_approver`, and `exception_expiry_date` linked to the Policy/Risk; here the acceptance rides the incident Issue and its linked Risk.)\n\n**Exit criteria** — The memo is delivered, the accountable authority's decision (escalation direction or conditioned risk acceptance) is recorded with owner and follow-up, and any acceptance carries an expiry and a monitoring trigger.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","note":"significant-issue escalation and risk-acceptance memo","primitives":["coach-document-upload","coach-item-update"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Quarterly Board Reporting receiving owner and incident owner: Accept the incident governance summary and residual obligations without reopening the investigation, and sign the handoff only with notifications evidenced and CAPAs owned and dated.","instructions":"**Objective** — Compile the incident’s decided evidence and reporting summary, retain the immutable archive and carry forward scheduled corrective and acceptance reviews.\n\n**Inputs**\n- The incident record and every attached artifact: the scope-and-impact assessment, containment/eradication/recovery evidence, notification evidence, the root-cause analysis and CAPA list, and the disposition decision.\n- Any action plan (remediation path) or decision memo / risk acceptance (escalation path).\n- Open constraints and residual risk still outstanding at closure.\n- The verified final package compiled in this checkpoint, including its downstream-scope note, and the incident record with all linked evidence, decisions, and CAPAs.\n- The disposition decision and any escalation or risk-acceptance record (what the board needs to see).\n- The linkage target: the Quarterly Board & Audit-Committee GRC Reporting workflow.\n- Open CAPAs and action items, risk-acceptance expiries, and monitoring triggers still outstanding.\n- Records-retention requirements for incident and regulatory-notification evidence.\n\n**Procedure**\n*Autonomous preparation incorporates Prepare final package; Quarterly Board Reporting receiving owner and incident owner reviews the combined evidence.*\n1. Compile the package: incident summary and timeline, scope and impact, response and recovery evidence, notifications sent with deadlines met or missed, the root-cause analysis, the CAPA or action plan, and the disposition decision with its owner.\n2. Verify completeness against the incident record — every required deadline evidenced, every CAPA owned and dated, the disposition rationale present; a gap here is a rework signal, not a formatting nit.\n3. State the residual risk and any open constraints plainly so the downstream reader and the archive both see what remains.\n4. Note explicitly what the downstream Quarterly Board & Audit-Committee GRC Reporting workflow should consume and should NOT repeat — it reports the outcome; it does not re-investigate.\n5. Produce the proposed conclusion and route the package for review.\n6. Create or link the downstream Quarterly Board & Audit-Committee GRC Reporting workflow instance and attach the final package as its input handoff.\n7. Carry forward only what governance reporting needs: incident significance, regulatory exposure, disposition, residual risk, and CAPA status — not the full forensic detail.\n8. State the assumptions the package rests on and, explicitly, what the downstream workflow should not repeat (it reports the outcome; it does not re-open the investigation).\n9. Confirm the downstream owner has received and acknowledged the handoff so nothing is dropped at the boundary. Check every other closure precondition at the same time: all required notifications are evidenced, CAPAs are owned and dated, and the disposition decision is recorded with its owner.\n10. Archive the final package and lock the incident's evidence per retention policy so the audit trail is immutable.\n11. Update linked records — set the incident status to closed, and update linked controls and risks with the incident outcome and any control changes made.\n12. Schedule follow-up: monitoring triggers for accepted risk, validation checkpoints for open CAPAs, and any review or expiry date carried from an escalation.\n13. Communicate the final decision and closure to the incident owner, stakeholders, and the downstream reporting owner; the acknowledged handoff signed on this step is the closure.\n\n**Record in AssureSwarm**\n- **Step document** — render and compile the governance package (PDF/DOCX) and attach it to this step and the incident Issue (coach-render-package, coach-document-upload).\n- **Item relationships** — link the package to the incident Issue and its CAPA/action Issue items (coach-items-link).\n- Record each receiving owner’s actual acceptance in native approvals, with scope and limitations in the native result. Retain the source owner’s closure sign-off where the procedure requires it.\n- **Handoff package** — link the final governance package to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow instance as its input handoff (coach-document-link, coach-items-link).\n- **Item field update** — record the handoff acknowledgment and the carried-forward summary on the incident Issue; set its status to closed and record `actual_remediation_date`/`verified_date`; update the linked Control and Risk items with the incident outcome and any control change (coach-item-update).\n- **Step document / workflow instance** — archive and lock the final package per retention policy so the run itself stands as the immutable audit trail (coach-document-upload).\n- **Item relationships** — link outstanding CAPA Issues and their `target_remediation_date`/`verified_date` review dates to their owners as the scheduled follow-up (coach-items-link).\n\n**Exit criteria**\nAccept the incident governance summary and residual obligations without reopening the investigation, and sign the handoff only with notifications evidenced and CAPAs owned and dated.\nA complete, verified evidence-and-decision package — with residual risk, open constraints, and the downstream-scope note — is attached to the incident and ready for handoff.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the evidence, decisions, and CAPA links into a single reviewable governance package.\nThe final package is linked to the Quarterly Board & Audit-Committee GRC Reporting workflow with a carried-forward summary and a no-repeat note, and the downstream owner has acknowledged receipt. The incident is closed with an immutable archived package, linked control and risk records reflect the outcome, every open CAPA and accepted-risk review has a scheduled owner and date, and closure is communicated.","label":"Handoff to related workflow","performedBy":{"agent":"grc-artist","note":"final evidence-and-decision package assembler downstream governance-reporting handoff","primitives":["coach-render-package","coach-document-upload","coach-items-link","coach-item-update"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-incident-management-lifecycle"}