{"description":"Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.","edges":[{"id":"e-lock-executable-workplan-classify-disposition","source":"lock-executable-workplan","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-09","UC-IR-10","UC-LOG-06","UC-RISK-14","UC-ASSET-11","UC-BCDR-06","UC-BCDR-07","UC-BCDR-08"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-cybersecurity-incident-response","contentDigest":"sha256:24f03436d3713f92be067a14847e35f7b71d0b34c3bab5fe0e06bcc04156c45f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:24f03436d3713f92be067a14847e35f7b71d0b34c3bab5fe0e06bcc04156c45f","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-cybersecurity-incident-response"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-cybersecurity-incident-response","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2"],"teams":["it"]},"name":"Cybersecurity Incident Response","nodes":[{"data":{"description":"Validate severity and scope, distinguish false positives, and authorize a containment strategy that balances damage limitation with evidence preservation.","instructions":"**Objective** — Validate severity and scope, distinguish false positives, and authorize a containment strategy that balances damage limitation with evidence preservation.\n\n**Inputs**\n- The originating detection signal — SIEM/EDR/IDS alert, threat-intel hit, or user report — uploaded to this step as an alert export / raw-evidence file (the SIEM/EDR stays the external system of record).\n- Where an Incident Management Lifecycle workflow is running, its handoff package (initial ticket, reporter, affected systems) — a document attached to that upstream workflow's handoff step; otherwise the raw alert upload stands alone.\n- Affected systems that exist as Process items (process_type=it_general_control|security_process) plus the detection/logging Control items (domains=logging_monitoring_detection, UC-LOG-06) and the asset inventory (UC-ASSET-11) — the full inventory has no native Asset type, so an inventory extract is uploaded here; matching Process items are linked.\n- The incident categorization and severity scheme — a Policy item (policy_type=standard) where one exists, otherwise a scheme document referenced on this step — and any prior related or open incident Issues.\n- The validated-incident memo (step document) and the incident Issue from detection and validation.\n- The incident-response plan and severity-based playbooks — Policy items (policy_type=procedure|policy) attached to and referenced from the IR-family Control items (domains=incident_management_response, UC-IR-04/05); their documents attach here.\n- The on-call roster and response-team role definitions (lead, technical, communications, scribe) — roster document referenced on this step.\n- The evidence-handling / chain-of-custody policy (a Policy item, referenced from the UC-IR-06 Control) and the notification/communication matrix (UC-IR-07).\n\n**Procedure**\n_This checkpoint absorbs “Detect and validate incident”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Detect and validate incident: Triage the originating signal: pull the alert and correlate it across the available log sources (coach-query-data); confirm it is not a known false positive or a duplicate of an already-open incident.\n2. Validate it is a true security incident rather than a benign event — establish concrete indicators of compromise, confirm the activity is unauthorized or malicious, and record the detection timestamp and the detecting source. If it is a false positive, close it here with that determination and stop.\n3. Determine scope: enumerate the systems, accounts, data stores, and network segments affected; map each affected asset against the inventory (UC-ASSET-11); flag whether regulated/sensitive data or a BCDR-critical system (UC-BCDR-06) is involved.\n4. Assign a category (e.g., malware, unauthorized access, data exfiltration, denial of service) and a severity level using the org's scheme, citing the specific criteria that set the level (blast radius, data sensitivity, business impact).\n5. Establish the initial timeline (first observed, detected, validated) and note which volatile indicators must be preserved by the containment step.\n6. Create the incident record as an Issue (coach-item-create), link the affected assets (coach-items-link), and draft the validated-incident memo (detection facts, scope, category, severity, affected assets); attach it (coach-document-upload).\n7. Lock executable workplan: Confirm the incident declaration at the assigned severity and assign the incident lead and response roles per the roster; record who owns each role.\n8. Select the containment strategy and the playbook that matches the category and severity (UC-IR-05), explicitly balancing evidence preservation against damage limitation, and record the rationale.\n9. Set evidence-handling requirements: chain of custody, imaging versus live-response, and retention (UC-IR-06); name the evidence custodian.\n10. Set the internal communication plan and the thresholds that would trigger external or regulator notification — but do NOT execute any external notification here; that is handled by the separate reporting workflow (UC-IR-07).\n11. Lock final scope, owners, response SLAs/due dates, evidence requirements, and review expectations into the workplan; attach it (coach-document-upload) and update the incident Issue's status and owner (coach-item-update).\n\n**Record in AssureSwarm**\n- Item create — the incident record as an Issue (issue_type=exception, source=management_identified, severity, identified_date, description) via coach-item-create; no native Incident type, so the Issue force-fits the incident record and anchors the whole run.\n- Item relationship — the incident Issue linked to each affected Process item and each detection/logging Control item (coach-items-link).\n- Step document — the validated-incident memo (DOCX/PDF) attached to this step (coach-document-upload).\n- Step document — the locked response workplan (DOCX/PDF) attached to this step (coach-document-upload).\n- Item field update — the incident Issue's status (moved to in-response) and issue_owner set to the incident lead (coach-item-update).\n\n**Exit criteria**\n- The event is confirmed a genuine incident (or closed as a false positive); scope, category, and severity are set with stated criteria; affected assets are linked; the memo is attached. This memo is the input the response-plan activation reads.\n- The incident is declared with a lead and roles assigned; containment strategy, evidence-handling, and communication plan are set; the workplan is attached and the record status updated. The eradication-and-recovery step consumes this locked workplan, executing the approved containment actions first.","label":"Lock executable workplan","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-item-update"]}},"id":"lock-executable-workplan"},{"data":{"decisionField":"disposition_path","description":"Judge trusted-state recovery and observation-window evidence, own the exposed deficiency list and technical lessons, and classify the remaining remediation or escalation need.","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** — Judge trusted-state recovery and observation-window evidence, own the exposed deficiency list and technical lessons, and classify the remaining remediation or escalation need.\n\n**Inputs**\n- The locked workplan: containment strategy, evidence-handling requirements, and named evidence custodian.\n- The incident record (the anchor Issue) and its affected-asset links.\n- The forensic tooling and the evidence store, and the containment controls (UC-IR-05) and evidence-retention controls (UC-IR-06).\n- Known-good backups and trusted images — held in external backup/image repositories, represented in AssureSwarm by the BCDR Control items (domains=business_continuity_disaster_recovery, UC-BCDR-06/07/08) — and the recovery/BCDR procedures; restore/integrity evidence is uploaded to this step.\n- The eradication-and-recovery report (root cause plus the enumerated control deficiencies), the incident record and its full timeline, and the containment-and-evidence log.\n- The POA&M register — the open Issue items with issue_type=deficiency — and the risk register: Risk items (category=cyber_security etc., UC-RISK-14).\n- The affected unified controls (UC-IR-04 through UC-IR-10, UC-LOG-06, UC-ASSET-11, UC-BCDR-06/07/08) as Control items, the detection-control and playbook set, and the logging coverage (UC-LOG-06).\n- The response SLAs versus actuals (UC-IR-09, UC-IR-10).\n\n**Procedure**\n_This checkpoint absorbs “Eradicate and recover”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Eradicate and recover: Execute short-term containment per the workplan — isolate affected hosts and segments, disable compromised accounts and credentials, and block malicious indicators (IPs, domains, file hashes) — recording each action with its timestamp and operator.\n2. Before or during isolation, capture volatile and persistent evidence — memory, disk images, relevant logs — computing a hash for each artifact and recording chain of custody. Order collection by volatility so evidence is not lost to the containment action itself.\n3. Apply longer-term containment where needed (temporary patches, or standing up clean replacement systems for continued operation) without destroying evidence.\n4. Verify containment held: confirm there is no continued lateral movement or command-and-control beaconing in the logs (coach-query-data). If spread continues, widen the containment strategy and repeat.\n5. Log every containment action and evidence artifact against the incident Issue (coach-item-create, coach-items-link) and attach the containment-and-evidence log (coach-document-upload).\n6. Establish root cause from the forensic evidence just collected — the exploited vulnerability, misconfiguration, or credential compromise — and enumerate every affected system, indicator of compromise, and persistence mechanism.\n7. Eradicate: remove malware, close the exploited vulnerability (patch or configuration change), rotate every potentially compromised credential and key, and eliminate attacker persistence; confirm removal with a re-scan.\n8. Recover: restore systems from known-good backups or rebuild from trusted images (UC-BCDR-06/07/08), validating integrity before returning anything to production.\n9. Return to operation under heightened monitoring; confirm affected systems function normally and watch for reinfection or attacker-return indicators across the defined observation window.\n10. Record the root cause, the eradication and recovery actions, and — critically — the residual control deficiencies the incident exposed (what control should have prevented or detected it); update the incident Issue (coach-item-update) and attach the eradication-and-recovery report. The incident lead reviews the observation-window evidence, declares recovery clean, and owns the enumerated deficiency list, since that list drives everything downstream.\n11. Classify disposition: For each deficiency in the recovery report, confirm which unified control failed or was absent — the control that would have prevented or detected the incident.\n12. Create a POA&M item per deficiency (coach-item-create): weakness description, affected control, root cause, remediation milestone, resource estimate, and scheduled completion date.\n13. Assign an accountable owner and due date to each item, and link it to the incident record, to the affected control, and to the corresponding risk-register entry (coach-items-link, UC-RISK-14).\n14. For any deficiency that cannot be closed immediately, record an interim mitigation and the residual risk pending remediation.\n15. Attach the POA&M update summary.\n16. Reconstruct the end-to-end timeline — detection, validation, containment, eradication, recovery — and compute dwell time, time-to-detect, and time-to-contain against target SLAs (UC-IR-09).\n17. Assess detection efficacy: did existing monitoring and logging catch it, and how could detection have been earlier? Record any detection-rule or coverage gap.\n18. Assess response efficacy: playbook accuracy, decision quality, tooling gaps, and coordination issues; capture what worked and what failed.\n19. Derive concrete improvement actions — detection rules, playbook edits, control changes, training — each with a proposed owner. Keep these detection/process improvements distinct from the control-remediation deficiencies tracked in the POA&M so nothing is double-counted or dropped (UC-IR-10).\n20. Draft the technical lessons-learned report and attach it (coach-document-upload); create the tracked improvement items and link them to the incident (coach-item-create, coach-items-link).\n\n**Decision criteria**\n- Select `clean` (No reportable gap) when the root cause is eradicated, systems are recovered, and every exposed control deficiency already has an owned POA&M entry within tolerance — no residual issue warrants a separate action plan or an escalation.\n- Select `remediate` (Remediation required) when one or more deficiencies or lessons-learned actions need a consolidated, owned corrective action plan beyond routine POA&M tracking (for example a control redesign or a cross-team fix) before the incident can close.\n- Select `escalate` (Escalate significant issue) when the incident crosses a significant-deficiency or material threshold — major data loss, regulatory reportability, or unaccepted residual risk — requiring escalation to the system owner / authorizing official or a formal risk-acceptance decision.\n\n**Record in AssureSwarm**\n- Step document — each hashed forensic artifact attached to this step, plus the containment-and-evidence log (XLSX) and the eradication-and-recovery report (DOCX/PDF) listing the exposed control deficiencies; there is no native Evidence-register type, so artifact hashes and chain of custody are tracked inside the XLSX log (honest fallback).\n- Item relationship — the evidence artifacts and containment-action records linked to the anchor incident Issue so the log is reachable from the incident record.\n- Item field update — the incident Issue's root_cause (from the forensic finding) and status (moved to recovered) set via coach-item-update.\n- Item create — one POA&M Issue per deficiency (issue_type=deficiency, source=management_identified, issue_owner, target_remediation_date, remediation_plan carrying any interim mitigation, root_cause) via coach-item-create; these Issues ARE the POA&M register. Each detection/response improvement action is created as its own Issue (issue_type=opportunity or observation, issue_owner, target_remediation_date), kept distinct from the POA&M deficiency Issues so nothing is double-counted.\n- Item relationship — each POA&M Issue linked to the anchor incident Issue, to the failed Control item, and to the corresponding Risk item; each improvement Issue linked to the anchor incident Issue (coach-items-link).\n- Step document — the POA&M update summary and the technical lessons-learned report (DOCX/PDF) attached to this step.\n- Submit `disposition_path` (SELECT).\n- Record the step result with evidence references (the POA&M summary and the lessons-learned report) and the step's approver record (decision owner or approver).\n\n**Exit criteria**\n- Spread is stopped and verified in the logs; every evidence artifact is hashed and under chain of custody and the containment log is attached; root cause is identified and eliminated; systems are restored from trusted state and integrity-validated; the heightened-monitoring window is defined; the eradication-and-recovery report is attached listing the control deficiencies exposed. The disposition-classification step consumes this report — the POA&M update and the technical lessons-learned retrospective both run inside it.\n- Every exposed deficiency has a POA&M entry with owner, milestone, and due date, each linked to its control and risk entry, with interim mitigations recorded where needed; the timeline and SLA performance are documented, detection and response gaps are identified, improvement actions are owned, and both reports are attached; the form is submitted with rationale and owner and the unused branches are prunable. `clean` proceeds straight to the final package; `remediate` routes through the action plan first; `escalate` routes through escalation / risk-acceptance first.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-query-data","coach-item-update","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"classify-disposition"},{"data":{"description":"Agent builds an owned corrective action plan for the deficiencies flagged for remediation; human confirms every action is owned and dated","instructions":"**Objective** — Build a consolidated, owned corrective action plan for the deficiencies and improvement actions the disposition flagged for remediation.\n\n**Inputs**\n- The disposition rationale (remediate branch).\n- The POA&M entries and the lessons-learned improvement actions to be consolidated.\n- The affected controls and their owners.\n\n**Procedure**\n1. Gather the POA&M items and lessons-learned actions the disposition marked for consolidated remediation and group related items into single tracked actions so owners are not chasing fragments.\n2. For each action, document root cause, accountable owner, due date, interim mitigation, the validation evidence that will prove closure, and the reporting cadence.\n3. Set a validation checkpoint per action (who verifies, and against what evidence) so closure is defensible, not self-asserted.\n4. Create the action-plan item(s) (coach-item-create) and link them to the incident and the affected controls (coach-items-link); attach the action-plan document (coach-document-upload).\n\n**Record in AssureSwarm**\n- Item create — a consolidated rollup Issue (issue_type=deficiency, issue_owner, target_remediation_date, remediation_plan carrying the grouped actions, validation evidence, and cadence) via coach-item-create; grouped POA&M Issues' remediation_plan fields updated to point at it.\n- Item relationship — the rollup action-plan Issue linked to the anchor incident Issue and the affected Control items (coach-items-link).\n- Step document — the action-plan document attached to this step (coach-document-upload).\n\n**Exit criteria** — Every remediation action is owned and dated with defined validation evidence; the plan is linked to the incident and controls and attached. Feeds the final package.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"create-action-plan"},{"data":{"description":"Agent prepares the escalation/decision memo and captures the authority's decision or a formal risk acceptance; human authority makes the call","instructions":"**Objective** — Escalate the significant issue to the accountable authority (control owner, system owner, or authorizing official) or document a formal risk acceptance with conditions and follow-up ownership.\n\n**Inputs**\n- The disposition rationale (escalate branch) and the quantified impact and residual risk (UC-RISK-14).\n- The incident package assembled so far, and the escalation / authorization matrix.\n\n**Procedure**\n1. Prepare the decision memo: incident summary, quantified business and compliance impact, residual risk, and the specific decision being requested (remediate under conditions versus formally accept the risk). Where regulatory reportability is the trigger, name the external breach-notification / legal-reporting workflow this memo feeds — this cycle routes to it but does not execute the notification.\n2. Route the memo to the correct authority per the escalation matrix and capture the authority's decision.\n3. If the risk is accepted, record it as a formal risk acceptance with an expiry date and a monitoring trigger that would reopen it; if escalated for remediation, define the conditions and the follow-up owner.\n4. Create the escalation / risk-acceptance Issue (coach-item-create), link it to the incident and the Risk register (coach-items-link), set treatment=accept on the accepted Risk (coach-item-update), attach the decision memo (coach-document-upload), and notify the affected stakeholders (coach-notify).\n\n**Record in AssureSwarm**\n- Item create — the escalation / risk-acceptance record as an Issue (issue_type=policy_exception, exception_approver = the deciding authority, exception_expiry_date = the acceptance expiry) via coach-item-create.\n- Item relationship — the exception Issue linked to the anchor incident Issue and to the accepted Risk item (coach-items-link).\n- Item field update — where the risk is accepted, the linked Risk's treatment=accept, residual_rating, and risk_owner (the follow-up owner) set via coach-item-update.\n- Step document — the decision memo (DOCX/PDF) attached to this step (coach-document-upload); stakeholder notification via coach-notify.\n\n**Exit criteria** — The authority's decision is recorded with conditions and a follow-up owner; any risk acceptance carries an expiry and a monitoring trigger. Feeds the final package.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update","coach-document-upload","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Acknowledge receipt of the closed incident’s deficiency findings and open POA&M items for continuous monitoring.","instructions":"**Objective** — Acknowledge receipt of the closed incident’s deficiency findings and open POA&M items for continuous monitoring.\n\n**Inputs**\n- Every prior-step output: the validated-incident memo, the containment-and-evidence log, the eradication-and-recovery report, the POA&M update summary, the lessons-learned report, and the disposition decision.\n- Any consolidated action plan (remediate branch) or escalation / risk-acceptance memo (escalate branch), if one was produced.\n- The final incident package (step document).\n- The open POA&M entries — the deficiency Issues (issue_type=deficiency) — and the lessons-learned improvement Issues produced by this incident.\n- The Continuous Controls Monitoring Cycle workflow.\n- The designated evidence repository and its retention controls (UC-IR-06), and the control-execution log.\n\n**Procedure**\n_This checkpoint absorbs “Prepare final package”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Prepare final package: Assemble the package in a defensible order: executive summary, timeline, detection and validation, containment and evidence register, eradication and recovery, root cause, POA&M entries, lessons-learned actions, and the disposition decision with rationale and owner.\n2. Verify completeness against a closure checklist: every phase documented, every evidence artifact referenced with its hash, and every open item (POA&M, action plan, escalation follow-up) carrying a named owner and due date.\n3. Confirm internal consistency — the root cause, the POA&M deficiencies, and the lessons-learned actions tell one coherent story, with no orphaned or contradictory findings.\n4. Render and attach the final package (coach-document-upload); the workflow instance on the anchor Issue is the package index, and a standalone index record is created only if wanted (coach-item-create).\n5. Handoff to related workflow: Link the downstream Continuous Controls Monitoring Cycle workflow and pass it the final package and the open POA&M Issues (coach-document-link, coach-items-link); these deficiency Issues are shared items the ISCM cycle queries directly, so the handoff is link-not-copy.\n6. Annotate the handoff with the assumptions the monitoring cycle should carry and, explicitly, what it should NOT repeat (the completed detection, containment, and recovery work) so effort is not duplicated.\n7. Notify the ISCM cycle owner and confirm receipt (coach-notify).\n8. Export the full incident record and its evidence (coach-workflow-export) and archive it in the designated repository under retention and chain-of-custody controls, recording the archive location and reference.\n9. Confirm every open item — POA&M entries, action-plan actions, escalation or risk-acceptance follow-ups — is carried to a named owner with a due date, so nothing closes silently.\n10. Update the incident Issue to closed with the final disposition and key metrics (coach-item-update), and update the control-execution log.\n11. The incident lead declares the incident closed and communicates the closure and the final decision to stakeholders (coach-notify); that declaration, recorded on this step, closes the workflow.\n\n**Record in AssureSwarm**\n- Step document — the final incident package (a single PDF) attached to this step (coach-document-upload).\n- Workflow instance — the run itself on the anchor incident Issue is the durable package index and audit trail; there is no native package-index type, so where a standalone index record is wanted it is created as an Issue via coach-item-create (honest fallback).\n- Handoff package — the final package document linked to the ISCM cycle and the open POA&M deficiency Issues shared as-is; no re-copy, the Issues carry their own control/risk linkage.\n- Workflow instance — the full incident run and its evidence exported and archived in the designated repository under retention and chain-of-custody controls, with the archive location recorded.\n- Item field update — the anchor incident Issue's status set to closed and actual_remediation_date set via coach-item-update.\n- Notifications — receipt confirmation from the ISCM cycle owner and the stakeholder closure notice (coach-notify).\n\n**Exit criteria**\n- The package is complete and internally consistent; every open item is owned with a due date. The handoff step consumes this package.\n- The ISCM cycle is linked, the package and open items are delivered, and receipt is confirmed; the archived record is immutable and retrievable; the incident is closed with nothing left open without a tracked owner; closure is communicated. The closure recorded here ends the workflow.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-document-upload","coach-items-link","coach-notify","coach-workflow-export","coach-item-update"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-cybersecurity-incident-response"}