{"description":"Standing operator workflow that runs on the existing Control item for the incident-reporting and information-spillage control (UC-IR-03; framework nist-800-53 | iso-27001 | nis2, domains incident_management_response) — one recurring workflow instance per operating cycle attaches to and enriches that Control item, never a duplicate. It consumes the prior cycle's carry-forward from the same Control: the last-sweep timestamp from the previous instance's close-and-archive record, plus the still-open corrective-action and obligation Issues linked to the Control. In scope: intake acknowledgment and triage routing across the monitored mailbox, hotline, and service portal; spillage containment/eradication and obligation assessment; and maintenance of the authorities and special-interest-group (SIG) contact register — spanning NIST 800-53 IR-6, IR-7, IR-9, and PM-15; ISO 27001 A.6.8, A.5.5, A.5.6; and NIS2 reporting duties. Named deliverables: the deduplicated intake register and acknowledgment log, the batch routing decision, the spill case with verified eradication, the obligation assessment and exposed-personnel training evidence, the refreshed authority/SIG contact register, the capability-health dashboard, the corrective-action register, and the archived operating record. Out of scope: full containment, investigation, and forensic response for genuine security events — those are handed off to the detect-to-respond workflow (via the route_to_incident_triage routing decision plus the linked intake Issues) rather than duplicated here.","edges":[{"id":"e-triage-and-route-reports-provide-ir-support-guidance","label":"Advisory","source":"triage-and-route-reports","target":"provide-ir-support-guidance","whenValue":"advisory_support"},{"id":"e-triage-and-route-reports-contain-and-purge-spillage","label":"Spillage","source":"triage-and-route-reports","target":"contain-and-purge-spillage","whenValue":"spillage_confirmed"},{"id":"e-triage-and-route-reports-maintain-authority-and-sig-contacts","label":"To triage","source":"triage-and-route-reports","target":"maintain-authority-and-sig-contacts","whenValue":"route_to_incident_triage"},{"id":"e-contain-and-purge-spillage-maintain-authority-and-sig-contacts","source":"contain-and-purge-spillage","target":"maintain-authority-and-sig-contacts"},{"id":"e-provide-ir-support-guidance-classify-capability-readiness","source":"provide-ir-support-guidance","target":"classify-capability-readiness"},{"id":"e-maintain-authority-and-sig-contacts-classify-capability-readiness","source":"maintain-authority-and-sig-contacts","target":"classify-capability-readiness"},{"id":"e-classify-capability-readiness-log-corrective-actions","label":"Gaps","source":"classify-capability-readiness","target":"log-corrective-actions","whenValue":"gaps_identified"},{"id":"e-classify-capability-readiness-close-and-archive","label":"Healthy","source":"classify-capability-readiness","target":"close-and-archive","whenValue":"healthy"},{"id":"e-log-corrective-actions-close-and-archive","source":"log-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-IR-03","UC-IR-11","UC-GOV-23"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-incident-reporting-spillage-response","contentDigest":"sha256:801f657afd613afa2d6a34b2a9198219da7d8f5923ef91d765537765855606a8","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:801f657afd613afa2d6a34b2a9198219da7d8f5923ef91d765537765855606a8","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-incident-reporting-spillage-response"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-incident-reporting-spillage-response","source":"coworkcanvas-gallery","standards":["nist-800-53","iso-27001","nis2"],"teams":["it","compliance-legal"]},"name":"Incident Reporting Channels & Spillage Response","nodes":[{"data":{"decisionField":"report_routing","description":"Review deduplicated, acknowledged intake with any missing firsthand facts, and classify advisory, genuine-event or spillage routing from the enriched batch.","formData":{"fields":[{"key":"report_routing","label":"Report Routing","options":[{"label":"Advisory support resolves it","value":"advisory_support"},{"label":"Route to incident triage","value":"route_to_incident_triage"},{"label":"Information spillage confirmed","value":"spillage_confirmed"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Review deduplicated, acknowledged intake with any missing firsthand facts, and classify advisory, genuine-event or spillage routing from the enriched batch.\n\n**Inputs**\n- The three well-known reporting channels — the monitored security mailbox, the incident hotline queue, and the service-desk portal category — which live in external systems; their channel inventory/definition is a document on this step carried from the prior cycle's archive and is summarized in the anchor Control item's description.\n- The acknowledgment SLA for each channel (default: hotline within 1 business hour; mailbox and portal within 1 business day) held as a Policy item (policy_type: standard) in the policy library, plus the on-duty incident-response (IR) support-resource roster uploaded (PBC/external) as the SLA-and-roster document on this step.\n- The timestamp of the last completed sweep, read from the prior workflow instance on this same Control (its close-and-archive record), to bound \"new since last sweep\".\n- Any carry-forward unacknowledged reports handed in as open Issue items linked to the anchor Control from the prior cycle's closure.\n\n**Procedure**\n_This checkpoint absorbs “Operate event-reporting channels”. 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. Operate event-reporting channels: Sweep all three channels, pulling every report received since the last sweep timestamp. Capture channel, reporter identity, receipt time, and the raw description verbatim.\n2. Deduplicate: reports describing the same underlying event (same asset, same time window, same symptom) collapse into one intake record with the duplicates linked, so a single event is not triaged multiple times.\n3. Create one intake record per distinct report capturing reporter, channel, receipt time, description, affected system or asset, and a preliminary sensitivity flag (does it appear to involve regulated or classified data?).\n4. Where a report arrives thin — a one-line email or a hotline note — ask only for the missing account, timing or affected-system facts through the existing reporting channel. Preserve the reporter’s own words and attach existing evidence as documents; a reporter who executes or approves any workflow checkpoint records their own contribution in native results.\n5. Acknowledge every reporter within that channel's SLA. A silent auto-reply does not count — the acknowledgment must confirm receipt and give the reporter the re-contact path.\n6. Confirm the IR support resource is staffed and reachable this cycle to advise reporters on how to report and how to handle a suspected event; log any coverage gap as an exception.\n7. Compile the acknowledgment log and flag any report still unacknowledged past its SLA for immediate escalation.\n\n**Decision criteria**\n- **advisory_support** — the report is a question or a benign observation the IR support resource can resolve with guidance, with no evidence of an actual security event or data exposure (e.g., \"is this email phishing?\" and it is confirmed benign). Pick when no incident and no spill exists.\n- **route_to_incident_triage** — the report describes a genuine security event (confirmed or credibly suspected compromise, malware, unauthorized access, or availability loss) that requires containment and investigation. These are handed to the detect-to-respond workflow; pick this when the event needs the full incident response rather than this channel workflow.\n- **spillage_confirmed** — sensitive, regulated, or classified information has landed on a system, mailbox, or share not authorized to hold it. Pick this for any confirmed information spill; it enters the containment-and-purge procedure regardless of whether it also constitutes an incident.\n\nBefore selecting, enrich each intake record with asset owner, data classification, and prior-report history so the decision rests on context, not the raw message; and scan open workflows to attach each report to any already-running incident or spill case and avoid duplicate cases.\n\n**Record in AssureSwarm**\n- Create one intake Issue per distinct report — issue_type: observation, source: management_identified, identified_date (receipt time), severity (from the preliminary sensitivity flag) — capturing channel, reporter identity, affected system/asset, and the verbatim description in its description; link each to the anchor Control item (item create; items link). There is no Incident type in the schema, so intake records ride on Issue — the channel/reporter/receipt-time detail lives in the description.\n- The original report and any targeted follow-up supply firsthand facts; populate the intake Issue description and severity from these sources and attach evidence documents through the existing channel.\n- Link duplicate reports of the same underlying event via Issue ↔ Issue relationships so one event is triaged once (items link).\n- Attach the intake register and the acknowledgment log (the SLA-met evidence) as an XLSX document on this step (document upload).\n- Log any IR support-resource coverage gap as an Issue (issue_type: deficiency) linked to the Control; run the channel sweeps and dedup lookups with coach-query-data.\nSubmit the `report_routing` SELECT with the chosen value; record the step result (why this disposition, with evidence-item references) and the step's approver record. Enrich each intake Issue's description with asset owner, data classification, and prior-report history so the decision rests on context (coach-item-update); scan open workflows to detect any already-running incident or spill case and avoid duplicate cases (coach-workflow-scan); run enrichment lookups with coach-query-data. Attach the routing-recommendation document to this step (coach-document-upload). On the `route_to_incident_triage` branch, this routing form plus the routing-recommendation document and the routed intake Issues ARE the handoff package the detect-to-respond workflow consumes — no separate handoff node is modeled in this workflow.\n\n**Exit criteria**\n- Every report received since the last sweep has an intake record, is deduplicated, and was acknowledged within its channel SLA; every thin report has either the missing firsthand facts or a recorded targeted attempt to obtain them; no report is left unlogged or unacknowledged; the IR support resource is confirmed reachable or its coverage gap is logged.\n- The SELECT is submitted with a rationale and named owner; the two unchosen branches are prunable; every batch report is either attached to an existing case or carried on the chosen branch.","kind":"decision","label":"Triage and route reports","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-item-update","coach-workflow-scan"]}},"id":"triage-and-route-reports"},{"data":{"description":"Agent drafts and logs response guidance through the IR support resource; human confirms the reporter was helped and no latent incident hides behind the question","instructions":"**Objective** — Deliver advice and assistance to the reporter through the IR support resource and close the advisory report, without losing sight of any latent incident hiding behind the question.\n\n**Inputs**\n- The intake record(s) routed `advisory_support` at the triage decision, with reporter, channel, and description.\n- The IR support-resource knowledge base and prior advisory interactions, for consistent guidance.\n- The re-report thresholds: the conditions that would turn this observation into a reportable event.\n\n**Procedure**\n1. Draft tailored guidance for the reporter: how to handle what they observed, what evidence to preserve (screenshots, message headers, do-not-delete), and the explicit conditions under which they must re-report the matter as an event.\n2. Record the support interaction as an item and link it to the originating intake record so the capability shows the advice provided and by whom.\n3. Ask the reporter through the existing reporting channel whether the guidance resolved the question or the matter needs reopening; record the reply on the intake Issue.\n4. Re-examine the report once more for a latent incident: a \"simple question\" that on inspection describes real unauthorized access must be reclassified back to triage, not closed as advisory.\n5. Attach the guidance and the support log.\n\n**Record in AssureSwarm**\n- Create the support-interaction Issue — issue_type: observation, source: management_identified — recording the advice given and by whom in its description, linked to the originating intake Issue via Issue ↔ Issue (item create; items link).\n- Record the reporter’s reply on resolution or reopening on the existing intake Issue.\n- Attach the guidance and the support log as a document on this step (document upload).\n\n**Exit criteria** — Guidance issued and acknowledged; the support interaction is logged and linked; the reporter’s reply or attempted follow-up is recorded; the support lead confirms no genuine incident is hiding behind the question before the advisory report is closed.","label":"Provide IR support guidance","performedBy":{"primitives":["coach-form-create","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"provide-ir-support-guidance"},{"data":{"description":"Agent identifies the spilled data and contamination extent and drives isolation and eradication from systems and backups; human verifies containment without amplifying exposure","instructions":"**Objective** — Execute the documented information-spillage procedure: identify the exposure, alert the right people without widening it, and verifiably eradicate the spilled information from every system and backup that holds it.\n\n**Inputs**\n- The intake Issue(s) routed `spillage_confirmed` at the triage decision (issue_type: observation), carrying the spilled-data description and the initial affected system.\n- The documented information-spillage procedure held as a Policy item (policy_type: procedure, policy_owner, review_frequency, next_review_date) with the procedure document attached; the pre-defined out-of-band spill-alert channel and personnel roster uploaded (PBC/external) as a document on this step.\n- The data classification scheme as a Policy item (policy_type: standard), and the system/asset inventory covering endpoints, mailboxes, file shares, collaboration tools, and backup sets as a CSV extract uploaded on this step — there is no Asset type, so the inventory and the contamination map live as step documents.\n\n**Procedure**\n1. Identify the spilled information, its classification, and the full extent of contamination across endpoints, mailboxes, file shares, collaboration tools, and backup sets; record a contamination map naming every location a copy reached.\n2. Alert the designated spill-response personnel through the pre-defined out-of-band channel — deliberately without forwarding, quoting, or attaching the spilled data, so the alert itself does not amplify exposure. This non-amplification discipline is the defining feature of spillage handling.\n3. Open a spill case item, isolate the affected systems, and drive purge of the spilled information from live systems and from backups, linking each isolation and eradication action to the case.\n4. Verify eradication: re-scan each mapped location to confirm the data is gone, including backup snapshots and any sync or versioning copies; any location that cannot be verified stays open on the case.\n5. Attach the contamination map and the containment-and-eradication log.\n\n**Record in AssureSwarm**\n- Open the spill case as an Issue — issue_type: exception, severity, root_cause, remediation_plan (the purge plan), verified_date (set once re-scan confirms eradication) — linked to the intake Issue(s) and the anchor Control (item create; items link). There is no Incident type, so the live-incident detail (contamination state, isolation actions) is carried in the case description and the attached logs.\n- Link each isolation and eradication action to the spill-case Issue via Issue ↔ Issue (items link).\n- Attach the contamination map (naming every location a copy reached) and the containment-and-eradication log as documents on this step (document upload); run scoping and re-scan lookups with coach-query-data.\n\n**Exit criteria** — The full contamination extent is identified and mapped; alerting was done through the out-of-band channel with no further exposure; the spilled information is verifiably eradicated from all affected systems and backups (confirmed by re-scan) before obligations are assessed.","label":"Contain and purge spillage","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload"]}},"id":"contain-and-purge-spillage"},{"data":{"description":"Agent maps the triggered notification obligations, assigns training to exposed personnel, refreshes the authority and special-interest-group contact register and records any incident-time notifications; human confirms the obligations are owned, the personnel trained, the spill documented, and the register current with defined usage protocols","instructions":"**Objective** — Map the notification obligations a spill or genuine event triggers, train the exposed personnel, and keep the authority and special-interest-group (SIG) contact register current and exercised under its usage protocol — with the human confirming, in one place, that every obligation is owned, the exposed personnel are trained, the spill is fully documented, and the register is current with defined usage protocols.\n\n**Inputs**\n- The verified spill-case Issue and contamination map from the containment step: which data, which classification, and who was exposed; plus the exposed-personnel list (everyone who received or handled the spilled data).\n- The obligation catalog — regulatory (e.g. GDPR 72-hour breach notice, NIS2 incident reporting), contractual notification clauses, and internal escalation duties keyed to data classification — held as a Policy item (policy_type: standard) with the catalog document attached; there is no Obligation type.\n- The authority and SIG contact register — regulators and supervisory bodies, law enforcement, sector CSIRTs, security forums, and professional associations, each with its last-reviewed date, the events it is used for, and the person authorized to use it — carried as the prior cycle's refreshed XLSX document from the last close-and-archive. There is no Contact type, so review-interval tracking is manual on the document.\n- Genuine-event intake Issues routed `route_to_incident_triage` at the triage decision (these may carry an authority-notification duty even though containment itself is handled by the detect-to-respond workflow).\n\n**Procedure**\n_Items 1–4 are agent-run (folded from the former \"Assess obligations and train\" step) and items 5–8 continue agent-run; the human moment is the single confirmation in item 9._\n1. Map the exposed data to every regulatory, contractual, and internal notification obligation it triggers; compile the obligation list with the responsible party and deadline for each, recording each clock start (e.g. NIS2 early-warning within 24 hours, GDPR within 72 hours).\n2. Create a notification or obligation task per triggered duty, set owner and due date, and link it to the spill case. Flag every authority-facing notification so it is executed through the usage protocol below rather than ad hoc.\n3. Build a targeted acknowledgment-and-training assignment for the exposed personnel covering safe handling and non-amplification, and track completion.\n4. Assemble the obligation assessment, the training-completion evidence, and the completed spill-response record.\n5. Pull the current contact register and flag every contact past its review interval (default annual). Draft updates stating when each contact is used, by whom, and the protocol for reaching it during an incident.\n6. For any authority-facing obligation flagged in item 2, or any genuine event requiring a regulator or CSIRT notice, execute the defined usage protocol: notify the relevant authority through the correct contact and within the deadline, and record the liaison as an item on the case.\n7. Capture the recommended practices, emerging-threat advisories, and regulatory expectations gathered through the SIG and forum channels, and route each to its accountable owner.\n8. Refresh the register with the new review dates and usage protocols, and compile the liaison log.\n9. Human confirmation: every triggered obligation has an owner and a deadline, exposed personnel are trained and have acknowledged, the spill response is fully documented, and the register is current with usage protocols — including in-incident use — with every required notification made through the right contact inside its deadline.\n\n**Record in AssureSwarm**\n- Create one notification/obligation task per triggered duty as an Issue — issue_type: deficiency, source: management_identified, issue_owner, target_remediation_date (the statutory deadline, e.g. NIS2 24-hour early warning, GDPR 72 hours) — linked to the spill-case Issue (item create; items link). There is no Obligation/Task type, so each duty's clock-start and deadline are carried on the Issue's date fields.\n- Issue the exposed-personnel training assignment through the existing training channel and retain completion and acknowledgement evidence (coach-workflow-scan).\n- Record each authority liaison as an Issue (issue_type: observation, source: management_identified) linked to its spill-case or obligation Issue, and as a row in the liaison log.\n- Dispatch each required notification through the correct registered contact within its deadline (coach-notify).\n- Attach as documents on this step: the obligation assessment, the training-completion evidence, the completed spill-response record, the refreshed contact register (XLSX, with usage protocols and updated review dates), and the liaison log. Pull the register, check review dates and run mapping lookups with coach-query-data. The register lives only as this step document because there is no Contact type.\n\n**Exit criteria** — The obligation assessment is complete with an owner and deadline on every triggered duty; exposed personnel are trained and have acknowledged; the spill response is fully documented; the register is current and complete with usage protocols (including in-incident use) defined; every required authority notification was made through the right contact within its deadline; gathered intelligence is routed to accountable owners.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` dispatches each triggered obligation notice to its owner with the deadline and case reference pre-filled, and sends the authority notification through the registered contact with the incident reference and statutory deadline attached.","label":"Maintain authority and SIG contacts","performedBy":{"primitives":["coach-query-data","coach-item-create","coach-items-link","coach-notify","coach-document-upload","coach-form-create","coach-workflow-scan"]}},"id":"maintain-authority-and-sig-contacts"},{"data":{"decisionField":"readiness_disposition","description":"Agent computes capability-health metrics and a dashboard; human classifies the cycle as healthy or gaps-identified","formData":{"fields":[{"key":"readiness_disposition","label":"Readiness Disposition","options":[{"label":"Healthy, within tolerance","value":"healthy"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge whether the standing incident-reporting capability operated within tolerance this cycle or carries gaps needing tracked corrective action, so only the relevant closure path continues. Owned by the control owner.\n\n**Decision criteria**\n- **healthy** — every metric is within tolerance: the acknowledgment SLA was met on all reports, no report was left unrouted or dropped, spill containment and backup-purge were verified, no triggered obligation is overdue, and no authority/SIG contact is past its review interval. Pick when the whole cycle is clean.\n- **gaps_identified** — any one of these is breached: an acknowledgment SLA miss, an unrouted or dropped report, an unverified spill purge, an overdue notification obligation, or a stale contact. Pick if even a single metric is out of tolerance.\n\nBefore selecting, compute the cycle metrics across intake acknowledgment (from the channels step), routing coverage (from the triage decision), spill containment and purge verification (from the spillage steps), obligation timeliness, and contact currency (from the contacts step); build a capability-health dashboard showing each metric against its threshold and its trend versus prior cycles; and list every breach with its owner and the evidence behind it.\n\n**Record in AssureSwarm** — Submit the `readiness_disposition` SELECT; record the step result (with the metrics cited) and the step's approver record. Build the capability-health dashboard sourced from the intake/spill/obligation Issue items and the step forms (coach-dashboard-create); attach the readiness summary as a document on this step (coach-document-upload); compute the metrics with coach-query-data.\n\n**Exit criteria** — The SELECT is submitted with a rationale and named owner; the dashboard reflects this cycle; the unchosen branch is prunable.","kind":"decision","label":"Classify capability readiness","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload"]}},"id":"classify-capability-readiness"},{"data":{"description":"Agent converts each identified gap into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every gap found at the readiness review into an owned, dated, tracked corrective action so nothing degrades the standing capability unaddressed.\n\n**Inputs**\n- The readiness summary and breach list from the readiness decision, each gap tied to the metric or case that surfaced it.\n- The corrective-action item type and the escalation matrix (which breaches must escalate to which accountable owner).\n\n**Procedure**\n1. Parse the readiness summary and list each gap with its root cause and the metric or case that surfaced it.\n2. Create a corrective-action item per gap capturing root cause, owner, due date, and interim mitigation, and link it to the driving metric or case.\n3. Raise capability-level improvement items for systemic gaps — an understaffed support resource, a stale spillage procedure, or a chronically overdue contact review — rather than only per-instance fixes.\n4. Escalate any notifiable or regulatory breach to the accountable owner per the escalation matrix.\n5. Attach the corrective-action register.\n\n**Record in AssureSwarm**\n- Create one corrective-action Issue per gap — issue_type: deficiency, source: self_assessment, root_cause, issue_owner, target_remediation_date — linked to the anchor Control and to the driving spill/intake/metric Issue (item create; items link).\n- Raise capability-level improvement Issues for systemic gaps (an understaffed support resource, a stale spillage procedure, a chronically overdue contact review) rather than only per-instance fixes.\n- Attach the corrective-action register (XLSX) as a document on this step (document upload).\n\n**Exit criteria** — Every gap has a named owner and due date; systemic gaps are raised as capability-level items; escalations are routed; nothing is left untracked before closure.","label":"Log corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record for the cycle: intake register, routing decisions, spill cases, obligation assessment, contact register and liaison log, the readiness result, and any corrective actions.\n- Open corrective actions (from the corrective-actions step on the gaps path), open obligations, and upcoming contact-review dates.\n- The evidence repository location and its retention and immutability controls.\n\n**Procedure**\n1. Export the full operating record and archive it in the designated evidence repository under retention controls, recording the archive location and reference.\n2. Create carry-forward items for open corrective actions, upcoming contact-review dates, and open obligations, and link each to its source so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log with the cycle result and key metrics, and confirm the next cadence review is scheduled.\n4. Attach the closure record.\n\n**Record in AssureSwarm**\n- Export the full operating record for the cycle and archive it under retention controls, recording the archive location and reference — the workflow instance itself is the durable audit trail on the anchor Control (workflow export; document upload).\n- Create carry-forward items for the still-open corrective-action and obligation Issues and upcoming contact-review dates, linking each to its source so they arrive as explicit inputs to the next instance on this Control (item create; items link). The open Issues carry forward as-is; only the next period's rollover record is new.\n- Attach the closure record as a document on this step (document upload).\n\n**Exit criteria** — The archived record is immutable and retrievable; the next review is scheduled; nothing remains open without a tracked owner; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-incident-reporting-spillage-response"}