{"description":"Recurring vulnerability & patch management lifecycle covering NIST SP 800-53 RA-5 (vulnerability scanning) and SI-2 (flaw remediation) and NIST CSF 2.0 ID.RA and PR.PS. Each cycle runs as one recurring instance anchored to the EXISTING vulnerability & patch management Control item (a Control with domains = vulnerability_patch_management — e.g. the UC-VULN-01 scanning control, control_owner = cycle owner); the instance enriches that Control's evidence trail rather than creating a new subject, and the instance itself is the cycle record. In scope: authenticated scanning of the confirmed asset inventory, severity-based triage against the SLA matrix, standard and emergency remediation, rescan verification, time-bound risk acceptance of residuals, metrics reporting, and cycle closure. Named deliverables: the deduplicated, enriched finding register (one vulnerability_scan Issue per finding, linked to the Control), rescan closure evidence, time-bound compensating-control-backed risk-acceptance exceptions (policy_exception Issues), and the cycle KPI & trend report. Consumed as inputs, not produced: the authoritative asset inventory / CMDB and the enterprise change-approval policy (a Policy item). The workflow is self-triggered by its own scheduled scan window (or an actively-exploited advisory) with no upstream or downstream workflow — its carry-forward package feeds the next iteration of this same cycle at intake.","edges":[{"id":"e-scan-and-triage-emergency-fix-and-approve","label":"Emergency","source":"scan-and-triage","target":"emergency-fix-and-approve","whenValue":"emergency_remediation"},{"id":"e-scan-and-triage-remediate-on-schedule","label":"Standard","source":"scan-and-triage","target":"remediate-on-schedule","whenValue":"standard_cycle"},{"id":"e-emergency-fix-and-approve-verify-by-rescan","source":"emergency-fix-and-approve","target":"verify-by-rescan"},{"id":"e-remediate-on-schedule-verify-by-rescan","source":"remediate-on-schedule","target":"verify-by-rescan"},{"id":"e-verify-by-rescan-report-metrics-and-trends","label":"Resolved","source":"verify-by-rescan","target":"report-metrics-and-trends","whenValue":"resolved"},{"id":"e-verify-by-rescan-risk-accept-residuals","label":"Residual","source":"verify-by-rescan","target":"risk-accept-residuals","whenValue":"residual_findings"},{"id":"e-risk-accept-residuals-report-metrics-and-trends","source":"risk-accept-residuals","target":"report-metrics-and-trends"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-VULN-01","UC-VULN-03","UC-ASSET-10","UC-ASSET-09"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-vulnerability-patch-management","contentDigest":"sha256:9774074d4b29f254001fafd22efa7e724864084b0d28613d5fb5bbb8791a8dc4","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:9774074d4b29f254001fafd22efa7e724864084b0d28613d5fb5bbb8791a8dc4","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-vulnerability-patch-management"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-vulnerability-patch-management","source":"coworkcanvas-gallery","standards":["nist-800-53","nist-csf-2"],"teams":["it"]},"name":"Vulnerability & Patch Management Cycle","nodes":[{"data":{"decisionField":"triage_path","description":"Agent establishes scope, runs authenticated scans, normalizes and enriches findings into a triage sheet; human reviews it and routes the cycle","formData":{"fields":[{"key":"triage_path","label":"Scan and triage","options":[{"label":"Emergency remediation required","value":"emergency_remediation"},{"label":"Standard remediation cycle","value":"standard_cycle"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Establish the cycle scope and SLA matrix, run authenticated scans across it, normalize and enrich every finding into a triage sheet, then decide whether any finding forces emergency remediation or the cycle proceeds on the standard SLA track.\n\n**Inputs**\n- Authoritative asset inventory / CMDB: in-scope asset groups, network segments, and explicit exclusions with justification. This is consumed as an input — the workflow does not maintain the inventory itself.\n- The scan window calendar, the severity SLA matrix (per-tier remediation deadlines, current version), and credential vault status for authenticated scanning.\n- The open exception / risk-acceptance register from prior cycles, flagging any acceptance that expires during this window.\n- Threat-intel feeds: the CISA KEV catalog, EPSS scores, and any actively-exploited advisory that may have triggered this cycle.\n\n**Procedure**\n1. Compile scope: pull the asset inventory and lock the in-scope asset groups, segments, and justified exclusions for this cycle; assign a cycle identifier and record the trigger (scheduled window, actively-exploited advisory, or ad hoc request) plus named owners for triage, change approval, and risk acceptance.\n2. Confirm the SLA matrix version is current and load per-tier deadlines (illustrative defaults: Critical 7d, High 30d, Medium 90d — always use the org matrix where it differs). Query the exception register and flag acceptances expiring this window as findings requiring re-decision.\n3. Launch or ingest authenticated scans across the confirmed scope; verify signature/plugin feeds are current, rerun failed or unauthenticated targets, and record job ids, timestamps, and the authenticated-coverage percentage. Coverage below roughly 90% of in-scope assets is itself a finding.\n4. Merge every scanner's output into one finding register, deduplicating by asset + vulnerability identifier (CVE / plugin id).\n5. Enrich each finding with CVSS base score, CISA KEV membership, EPSS exploitability, asset criticality, internet exposure, and prior-cycle status (new / recurring / covered by an open acceptance).\n6. Propose a remediation path and accountable owner per finding, and flag any that meets the documented emergency threshold — actively exploited, KEV-listed, or CVSS >= 9.0 on an internet-facing or business-critical asset.\n7. Draft the triage sheet: counts by severity, coverage gaps, expired acceptances, and the emergency candidates with their supporting evidence.\n\n**Decision criteria**\n- Choose **Emergency remediation required** (`emergency_remediation`) when at least one finding credibly exceeds the emergency threshold — a KEV-listed or actively-exploited vulnerability on an internet-facing or business-critical asset, or any finding whose exploitation is imminent and cannot wait for the standard change window.\n- Choose **Standard remediation cycle** (`standard_cycle`) when all findings can be safely remediated within their SLA-tier deadlines through the normal change calendar.\n\n**Record in AssureSwarm**\n- Attach the scan job manifest and the triage sheet (document upload); create one Issue per finding with `source: vulnerability_scan`, `issue_type: finding`, `severity`, `issue_owner`, `identified_date`, and an SLA-derived `target_remediation_date` (item create), and link each finding Issue to the anchor Control (items-link) — there is no Asset item type, so asset scope stays in the uploaded scope extract rather than an item link.\n- Submit `triage_path`; record the citation-backed decision in the step result (name the specific finding ids) and the approver in the step's approver record.\n\n**Exit criteria** — Scope and SLA matrix confirmed; authenticated coverage recorded; every finding enriched and owned in the register; triage sheet attached; `triage_path` submitted with rationale; the unselected branch is prunable.","kind":"decision","label":"Scan and triage","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link"]}},"id":"scan-and-triage"},{"data":{"description":"Agent drafts the emergency change record with rollback plan and coordinates deployment; human approves the emergency change","instructions":"**Objective** — Contain and remediate the emergency findings under an expedited, approved change with a tested rollback, so imminently-exploitable vulnerabilities are closed or mitigated before the next scheduled window.\n\n**Inputs**\n- The emergency candidates and their supporting evidence from the triage sheet (the `emergency_remediation` branch of Scan and triage).\n- The affected asset/service map and current owners from the finding register.\n- The org's emergency-change procedure and the authority matrix for expedited approvals.\n\n**Procedure**\n1. Draft the emergency change record per finding: proposed fix (patch, configuration change, or compensating control), affected asset and service list, and an impact / blast-radius analysis.\n2. Author an executable rollback plan per platform and attach it to the change record; the change is not approvable without one.\n3. Prepare interim mitigations for anything that cannot deploy immediately — network isolation, WAF or virtual patching, or disabling the vulnerable feature. Obtain the authorized emergency owner’s native approval for these exact production actions and rollback before applying any of them; then record actual execution and time.\n4. On approval, coordinate deployment: sequence targets, schedule the expedited window, notify affected service owners, and monitor health checks wave by wave, updating the change record in real time; call the rollback if a wave's health checks fail.\n5. Reconcile the entire finding register: each emergency finding maps to a deployed fix, an applied compensating control, or an escalation with a named owner and date. Retain all non-emergency findings in this selected path under the same standard SLA, accountable-owner, normal change-authorization and daily escalation rules; do not depend on the pruned standard node to handle them.\n\n**Record in AssureSwarm** — Attach the emergency change record and rollback plan as documents on this step (document upload) — there is no Change item type, so name each affected finding Issue in the change record's text rather than creating a change item or an items-link; note any interim mitigations on the affected finding's `Issue.remediation_plan` (item field update).\n\n**Exit criteria** — Emergency change approved by an authorized owner before any production-touching action; every emergency finding in a deployed, mitigated, or escalated terminal state; rollback plan attached and per-wave health-check results recorded.","label":"Emergency fix and approve","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-items-link","coach-item-update"]}},"id":"emergency-fix-and-approve"},{"data":{"description":"Agent raises SLA-tracked remediation tickets and escalates breaches; human unblocks stalled items","instructions":"**Objective** — Drive the standard-cycle findings to closure inside their SLA-tier deadlines through tracked tickets and booked change windows, escalating breaches so nothing ages silently past SLA.\n\n**Inputs**\n- The standard-cycle findings and owners from the finding register (the `standard_cycle` branch of Scan and triage).\n- The severity SLA matrix with per-tier deadlines and the change calendar (including blackout dates).\n- Remediation guidance and patch sources for each finding.\n\n**Procedure**\n1. Raise a remediation ticket per finding or finding group with a named owner, an SLA-derived due date, links to remediation guidance and the fix source, and a proposed change window on or before the due date.\n2. Sequence dependent systems correctly (reboot requirements, cluster failover order) and book windows on the change calendar, avoiding blackout dates. Obtain the normal change authority’s recorded approval before executing production changes, and keep its approved scope and rollback evidence with each finding.\n3. Track ticket progress against the SLA matrix daily; record patched-versus-planned counts per window as deployments complete.\n4. Escalate SLA breaches and stalled tickets to the owning manager with the aging evidence, logging every escalation.\n5. Keep the finding register synchronized with ticket status so the remediated population is rescan-ready.\n\n**Record in AssureSwarm** — Remediation tickets are not separate items: record each as field updates on the finding Issue in place — `Issue.remediation_plan`, `Issue.issue_owner`, and `Issue.target_remediation_date`, advancing the Issue's status as the fix moves through its change window (item field update). Refresh finding status from remediation progress (query-data / workflow-scan); log escalations as updates on the finding Issue.\n\n**Exit criteria** — Every standard-cycle finding has a ticket with an owner and SLA due date; escalations logged for every breach; the register marks the remediated population rescan-ready; the human has unblocked disputed ownership and resourcing trade-offs.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-scan` tracks ticket aging against the SLA matrix and surfaces breaches for escalation.","label":"Remediate on schedule","performedBy":{"primitives":["coach-item-create","coach-query-data","coach-workflow-scan","coach-item-update"]}},"id":"remediate-on-schedule"},{"data":{"decisionField":"rescan_result","description":"Agent rescans remediated assets and diffs before and after; human reviews the diff and classifies the outcome","formData":{"fields":[{"key":"rescan_result","label":"Verify by rescan","options":[{"label":"All findings verified resolved","value":"resolved"},{"label":"Residual findings remain","value":"residual_findings"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Prove remediation actually closed the findings by rescanning with the same authenticated policy and diffing against the pre-remediation baseline, then decide whether the cycle is fully resolved or residual findings remain.\n\n**Inputs**\n- Assets marked remediated on either branch (emergency and/or standard) from the finding register.\n- The original authenticated scan policy and the pre-remediation baseline results.\n\n**Procedure**\n1. Rescan every asset marked remediated using the identical authenticated scan policy as the original scan — a different policy invalidates the diff.\n2. Diff the rescan results against the pre-remediation baseline; classify each finding as verified-closed, still-open, or recurred.\n3. Draft closure evidence per verified finding with rescan job references, reconciling residual counts exactly to the finding register. No finding may be closed on ticket status alone.\n4. Compile the before/after diff summary: closure rate by severity and every residual finding with its owner and SLA position.\n\n**Decision criteria**\n- Choose **All findings verified resolved** (`resolved`) only when every in-scope finding is evidenced closed by rescan results.\n- Choose **Residual findings remain** (`residual_findings`) when any finding is still open or recurred. Route all residuals to the residual-risk owner: that owner records continued, owned remediation for findings still within SLA and considers formal acceptance only when justified; this branch does not itself accept risk.\n\n**Record in AssureSwarm** — Attach the rescan exports and diff summary (document upload); on each verified finding Issue set `Issue.actual_remediation_date` and `Issue.verified_date` and transition it to closed status (item field update). Submit `rescan_result`; cite rescan job references in the step result and the owner in the step's approver record.\n\n**Exit criteria** — Rescan run under the original policy; diff summary attached; every finding classified against rescan evidence; `rescan_result` submitted with references; the unselected branch is prunable.","kind":"decision","label":"Verify by rescan","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-update"]}},"id":"verify-by-rescan"},{"data":{"description":"Agent drafts time-bound exception records with compensating controls; human approves or rejects each risk acceptance","instructions":"**Objective** — Convert findings that cannot meet SLA into time-bound, compensating-control-backed exceptions signed by an authorized owner, so residual risk is explicit, expiring, and re-surfaced — never silently dropped.\n\n**Inputs**\n- The residual findings with their owners and SLA position from the diff summary (the `residual_findings` branch of Verify by rescan).\n- The risk register and the authority matrix mapping risk levels to who may sign.\n- Org policy on maximum acceptance duration.\n\n**Procedure**\n1. Draft an exception record per residual finding: residual-risk statement, affected assets, proposed compensating controls, the owner's business justification, and an expiry date no longer than policy allows.\n2. Validate each draft for completeness; flag weak justifications or findings where remediation looks feasible within a revised date rather than acceptance.\n3. Link each proposed exception to its finding and enter it in the risk register as a draft, explicitly pending decision. Keep feasible remediation and any finding still within SLA under an owner-acknowledged plan rather than forcing an acceptance.\n4. Schedule an expiry review per acceptance so it automatically resurfaces in a future cycle's intake.\n5. Present each draft for human decision: the approver judges whether the compensating controls genuinely reduce exploitability for the specific finding and confirms they hold authority for the risk level per the authority matrix.\n\n**Record in AssureSwarm** — Create each acceptance as an Issue with `issue_type: policy_exception`, `exception_approver` (the signing owner), and `exception_expiry_date` (the acceptance expiry) (item create) and link each exception Issue to its finding Issue (items-link); set `treatment: accept` on the linked Risk item only after the authorized owner actually accepts it. A rejected proposal or continued remediation retains its actual treatment and owner-acknowledged due date, without an acceptance record.\n\n**Exit criteria** — Every residual finding has either a signed, unexpired acceptance by an authorized owner, or a rejected-and-rescheduled remediation with a new owner-acknowledged due date carried into the next cycle; each acceptance has a scheduled expiry review.","label":"Risk-accept residuals","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"risk-accept-residuals"},{"data":{"description":"Agent compiles KPIs, trend charts, and SLA compliance from the finding register, then archives the cycle's reperformable evidence and stages the carry-forward package; human approves distribution — that approval is the cycle's closure","instructions":"**Objective** — Produce the cycle's KPI and trend report for security leadership and asset owners, computed directly from the finding register, and get distribution approved — that approval closes the cycle, whose evidence is then archived reperformable and whose open items are staged as the next cycle's intake.\n\n**Inputs**\n- The finding register in its post-verification state, plus signed acceptances from Risk-accept residuals (on the residual path) or the resolved outcome from Verify by rescan (on the resolved path).\n- Prior-cycle metrics and the agreed KPI thresholds.\n- The cycle's scan and rescan exports, change tickets, and decision rationales.\n- The retention location and the recurring scan schedule.\n\n**Procedure**\n_Items 1–4 produce the report and item 5 is the human moment; items 6–9 close the workflow (folded from the former \"Close and archive\" step) — the distribution approval recorded here is the closure._\n1. Compute cycle KPIs directly from the register with no manual adjustment: mean-time-to-remediate by severity, SLA attainment, authenticated-coverage percentage, new-versus-recurring ratio, and open acceptances by expiry date.\n2. Build trend charts comparing this cycle to prior cycles against the agreed thresholds; flag deteriorating trends and threshold breaches.\n3. Draft the stakeholder report: top residual risks, upcoming acceptance expiries, and proposed next-cycle improvement actions with suggested owners.\n4. Prepare the distribution package for security leadership and asset owners.\n5. First reconcile every finding to verified closure, authorized unexpired acceptance, or owned dated carry-forward; stop on any ambiguous state. The cycle owner reviews the report for accuracy and framing, confirms every improvement action carries a named owner, and approves the exact recipients and distribution. That approval is the cycle's closure; the remaining items file it.\n6. Verify every finding is terminal: verified-closed, formally accepted with an unexpired acceptance, or carried forward with an owner and due date — no ambiguous states.\n7. Archive scan and rescan exports, the finding register, change tickets, signed acceptances, decision rationales, and the metrics report to the retention location, sufficient for an independent assessor to reperform this cycle's decisions from evidence alone.\n8. Compile the carry-forward package of open findings and upcoming acceptance expiries for the next cycle's intake.\n9. Update the recurring schedule with the next scan window; record the closure timestamp and archive references.\n\n**Record in AssureSwarm**\n- Build the metrics dashboard (dashboard-create); export the report package (item-export) and attach it to the cycle.\n- Export the cycle archive (workflow-export) and upload the retention package (document upload).\n- Record the distribution approval as this step's approval — it is the closure, so no separate confirmation is recorded — plus the closure timestamp and archive references on the cycle.\n\n**Exit criteria** — KPIs computed from the register; trend charts built with breaches flagged; report reviewed for accuracy and framing; improvement actions carry named owners; distribution approved; no finding in an ambiguous state; archive complete and reperformable; carry-forward package staged; next scan window scheduled.\n\n> **⚡ Audit Artist accelerator:** `/coach-dashboard-create` assembles the KPI and trend charts from the finding register into the leadership dashboard; `/coach-workflow-export` packages the cycle's evidence and decision rationales into the retention archive.","label":"Report metrics and trends","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-export-package","coach-workflow-export","coach-document-upload"]}},"id":"report-metrics-and-trends"}],"sourceTemplateId":"workflow-library:controls-vulnerability-patch-management"}