{"description":"Run one operating cycle of an existing business continuity / disaster recovery plan-testing Control (the BC/DR test control this instance attaches to, UC-BCDR-04 \"tests\"): plan, execute, and evaluate a BC/DR exercise against the RTO and RPO objectives, then fold the resulting gaps back into the BC and DR plans as versioned redlines — a decision-aware workflow. It consumes as declared inputs the in-force BC and DR plans (existing Policy items), the business impact analysis (BIA), and prior after-action reports; it creates an Audit item (audit_type=operational) as the definitive exercise record, and produces named deliverables: an approved exercise package, an actual-versus-target RTO/RPO scorecard, remediation findings (Issue items), and a signed-off after-action report with an indexed evidence package. In scope: scoping, running, and evaluating one scheduled or triggered BC/DR exercise for the selected in-scope systems and business services, and folding resulting gaps back into the BC and DR plans. Out of scope: real incident response, and recovery-objective (RTO or RPO) changes to systems outside the agreed exercise scope. Standalone: no upstream or downstream workflow is required; any cross-workflow linkage — for example a related incident-response or BIA-maintenance workflow — is expressed as a declared input, not a predecessor.","edges":[{"id":"e-prepare-exercise-package-execute-and-capture","source":"prepare-exercise-package","target":"execute-and-capture"},{"id":"e-execute-and-capture-evaluate-against-objectives","source":"execute-and-capture","target":"evaluate-against-objectives"},{"id":"e-evaluate-against-objectives-brief-management-and-file","label":"Met","source":"evaluate-against-objectives","target":"brief-management-and-file","whenValue":"objectives_met"},{"id":"e-evaluate-against-objectives-remediate-and-update-plans","label":"Gaps","source":"evaluate-against-objectives","target":"remediate-and-update-plans","whenValue":"gaps_identified"},{"id":"e-remediate-and-update-plans-verify-plan-updates","source":"remediate-and-update-plans","target":"verify-plan-updates"},{"id":"e-verify-plan-updates-brief-management-and-file","source":"verify-plan-updates","target":"brief-management-and-file"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{"UC-BCDR-04":"tests"},"controls":["UC-BCDR-10","UC-BCDR-01","UC-BCDR-03","UC-ASSET-11","UC-BCDR-04","UC-BCDR-07"],"department":"operations","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-bcdr-test-exercise","contentDigest":"sha256:a8327d73b34cf64076fa4977e8aedb36e95121d78b859e40ddbc05bbbf6079a0","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:a8327d73b34cf64076fa4977e8aedb36e95121d78b859e40ddbc05bbbf6079a0","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-bcdr-test-exercise"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-bcdr-test-exercise","source":"coworkcanvas-gallery","standards":["iso-27001","nist-800-53"],"teams":["operations","it"]},"name":"Business Continuity & DR Test Exercise","nodes":[{"data":{"description":"Approve the exercise scope and objectives and the agent-prepared scenario, injects, runbooks, contact trees, schedule, and notifications","instructions":"**Objective** — Define the exercise scope and objectives and assemble an approved, ready-to-run exercise package (scenario, injects, runbooks, contact trees, schedule, and notifications) for the sponsor and owner to sign off before anyone runs the drill.\n\n**Inputs**\n- The in-force business continuity (BC) and disaster recovery (DR) plans — existing Policy items (policy_type: procedure, domains: business_continuity_disaster_recovery, framework: iso-27001 + nist-800-53) with the governed plan documents attached — plus the business impact analysis (BIA) and prior exercise after-action reports as linked documents (the BIA has no native item type; prior reports are the brief-management-and-file documents of archived runs). The anchor is the existing BC/DR test Control this run attaches to.\n- The declared RTO and RPO targets per in-scope system or service, read from the plan Policy items and the BIA. The in-scope systems and business services are existing Process items (process_type: business_process | operational | it_general_control); Process carries no RTO/RPO field, so restate each target in the scope charter and flag any that is missing, stale, or inconsistent between the plans and the BIA.\n- The change calendar, regulator and customer commitments, and the authoritative staff and vendor directory (for contact trees and call trees) — all external-system data mirrored into the exercise package as documents (no native directory or calendar item type).\n- The trigger for this exercise (annual schedule, post-incident follow-up, contractual commitment, or major system change) and any open findings that should shape it; when the trigger is a prior incident or open finding, relate this run to the existing Issue item(s) that motivated it. No upstream workflow feeds this step; where a related workflow exists (for example incident-response or BIA-maintenance), its handoff is a declared input, not a predecessor.\n\n**Procedure**\n1. Establish scope and success criteria: from the BC and DR plans and the BIA, list the candidate systems and business services with their RTO and RPO targets, select the in-scope set, and record out-of-scope exclusions with reasons. Define measurable success criteria tied to those targets and to ISO 27001 A.5.29 and A.5.30 and NIST 800-53 CP-4. Confirm the exercise type — tabletop discussion, functional component test, or full failover — matches business priority and risk appetite.\n2. Draft the scenario narrative and a timed master events list of injects that plausibly stress the in-scope systems (for example a regional cloud outage, ransomware encryption of primary storage, loss of a data center, or failure of a critical vendor). Map every success criterion to at least one inject or measurement so nothing is left unmeasured.\n3. Compile the package: current recovery runbooks, contact trees and call trees verified against the authoritative directory, role assignments with named backups (facilitator, scribes, participants, sponsor), data-capture templates for timings and decisions, and abort criteria with rollback steps for any live failover component.\n4. Schedule: propose a date and window that clears the change calendar and participant availability, and prepare calendar holds for every participant.\n5. Draft the notifications for participants, the service desk, security monitoring, operations, and affected business owners, including prework, briefing materials, and the drill-labeling convention so exercise traffic is never mistaken for a real incident. Send on approval and log acknowledgments and attendance as they arrive.\n\n**Record in AssureSwarm**\n- Attach the scope-and-objectives charter and the exercise package (scenario, injects, runbooks, contact trees, schedule, abort criteria) to this step (step document, PDF/DOCX).\n- Link the BC and DR plan Policy items, the anchor BC/DR test Control, and the in-scope Process items to this workflow instance (item relationship); attach the BIA and prior after-action reports as linked documents (document link) — the BIA has no native item type.\n- Log participant acknowledgments and confirmed role backups as documents on this step (there is no native attendance field).\n\n**Exit criteria** — Sponsor and owner have approved the scope, exercise type, targets, and success criteria; the scenario and injects are judged realistic; the abort criteria demonstrably protect production; the date and change window are approved; every critical role has a confirmed person and backup; and stakeholders have acknowledged the schedule.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — drafts and sends the participant and stakeholder notifications with the drill-labeling convention and logs acknowledgments.","label":"Prepare exercise package","performedBy":{"primitives":["coach-query-data","coach-items-link","coach-document-upload","coach-notify"]}},"id":"prepare-exercise-package"},{"data":{"description":"Humans run the exercise while the agent captures timings, decisions, deviations, and evidence, then validate the log","instructions":"**Objective** — Run the exercise while the agent captures a timestamped, attributable record of timings, decisions, deviations, and evidence, then have the facilitator validate that record as the definitive account of what happened.\n\n**Inputs**\n- The approved exercise package from the prepare step: rules of engagement, abort criteria, scenario, and the planned inject timeline.\n- The confirmed participant roster with role backups.\n- The live exercise channels (chat, conference bridge) and the monitoring dashboards for the in-scope systems.\n\n**Procedure**\n1. At the start of the window, open the exercise record with the rules of engagement, the abort criteria, and the planned inject timeline, and log participant check-ins against the roster.\n2. Timestamp each inject as the facilitator releases it, and record any deviation from the scripted timeline with the stated reason.\n3. Keep a timestamped log of every significant decision, action, communication, and runbook deviation as participants work the recovery; transcribe verbal observations from the exercise channels into attributable entries (who, what, when).\n4. Record per-system recovery milestones — declaration, mobilization, failover start, service restored, data validated — so that actual recovery time and actual data-loss window can later be computed. File screenshots, monitoring extracts, and chat transcripts as evidence against the timeline.\n5. After the close, reconstruct the definitive timeline and transcribe the hot-wash debrief, attributing each observation to a specific plan section, runbook step, or team.\n\nHumans run the exercise itself: the facilitator releases injects and invokes the abort criteria if production is threatened, and participants execute the BC and DR runbooks as they would in a real event. The agent only records.\n\n**Record in AssureSwarm** — Create the exercise record as an Audit item (item create): audit_type = operational, scope = the in-scope systems and services, lead_auditor = the facilitator, fieldwork_start and fieldwork_end = the exercise window, description = the scenario summary. Relate that Audit item to the anchor BC/DR test Control and to the in-scope Process items (item relationship). Attach the validated activity log, recovery timeline, evidence (screenshots, monitoring extracts, chat transcripts), and hot-wash transcript as documents on this step against the Audit item (document upload).\n\n**Exit criteria** — The window has closed; the facilitator and owner have reviewed the captured log and timeline; misattributed or missing entries are corrected while memories are fresh; and the record is confirmed as the definitive account of the exercise.","label":"Execute exercise and capture record","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"execute-and-capture"},{"data":{"decisionField":"exercise_outcome","description":"Decide whether the exercise met its RTO, RPO, and process objectives or exposed gaps","formData":{"fields":[{"key":"exercise_outcome","label":"Exercise outcome","options":[{"label":"Objectives met","value":"objectives_met"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether the exercise met its RTO, RPO, and process objectives or exposed gaps. Owned by the exercise owner and the sponsor.\n\n**Decision criteria**\n- Compute the actual recovery time and the actual data-loss window per in-scope system from the validated exercise log, and diff each against the RTO and RPO targets in the approved scope charter, flagging every miss with its margin.\n- Score each process objective — declaration speed, communications timeliness, decision authority, and runbook accuracy — as met or missed from the timestamped record; any abort or safety intervention counts as an automatic gap.\n- Choose `objectives_met` only when every success criterion passed with no material process failure. Choose `gaps_identified` when any RTO or RPO target was missed, the exercise was aborted, or a material weakness surfaced. When in doubt between the two, treat an unmet target or an abort as gaps.\n\n**Record in AssureSwarm** — Submit this step's form (step form): `exercise_outcome` SELECT with the chosen branch, the step result with evidence references, and the step's approver record. Update the exercise Audit item's `rating` (item field update): satisfactory when objectives_met, needs_improvement or unsatisfactory when gaps_identified. Attach the actual-versus-target scorecard file as a document on this step and present it as a dashboard (dashboard) so every result is visible at a glance. The recorded outcome must match the final scorecard.\n\n**Exit criteria** — The form is submitted, the recorded outcome matches the scorecard, and only the selected branch (met or gaps) proceeds while the unused branch is prunable.","kind":"decision","label":"Evaluate against objectives","performedBy":{"primitives":["coach-query-data","coach-item-update","coach-dashboard-create"]}},"id":"evaluate-against-objectives"},{"data":{"description":"Approve remediation actions and the agent-drafted BC and DR plan updates and redlines","instructions":"**Objective** — Turn every gap into an owned, dated corrective action and draft the BC and DR plan redlines that close it, for the remediation owners and the plan owner to approve before publication. Runs only on the gaps path.\n\n**Inputs**\n- The validated scorecard and evaluation summary from the evaluate decision (`gaps_identified` branch), with each missed objective and material observation and its supporting evidence.\n- The current BC and DR plans, contact lists and call trees, dependency maps, and failover procedures (the AssureSwarm plan items and their linked documents).\n- The corrective-action tracker and the document-control conventions (version numbering).\n\n**Procedure**\n1. Convert every missed objective and material observation on the scorecard into a draft finding with a plain root-cause statement, a proposed remediation action, a suggested owner, a due date, a severity, and any interim mitigation needed while a service stays exposed. Link each finding to the exercise evidence that supports it.\n2. Register the accepted findings in the corrective-action tracker and notify each owner of their assignment and date.\n3. Draft the BC and DR plan updates as redlines: revised recovery procedures that failed or drifted from reality, corrected contact lists, call trees, and escalation paths, updated dependency maps and failover steps, and proposed RTO or RPO changes where the exercise proved a target unachievable — each objective change flagged for business re-approval, never relaxed silently.\n4. Prepare the document-control package: a change summary and a new version number per affected document, ready to publish once approved.\n\n**Record in AssureSwarm** — Create one Issue per gap (item create): issue_type = finding, source = self_assessment (the closest source value for an exercise finding), severity, root_cause, remediation_plan, issue_owner, identified_date, target_remediation_date. Relate each Issue to the exercise Audit item, the anchor BC/DR test Control, the affected in-scope Process item(s), and the BC or DR plan Policy item it revises (item relationship). On publication, bump the affected plan Policy items' `version` and `next_review_date` (item field update). Attach the redlined plan updates and the change summary as documents on this step (step document, DOCX); flag every proposed RTO or RPO change for business re-approval inside the change summary.\n\n**Exit criteria** — Remediation owners have accepted or amended their actions and dates; the plan owner has approved or rejected each redline and routed every recovery-objective change to the accountable business owner for explicit re-approval; every gap on the scorecard carries at least one owned, dated action; and no update is published until approved.","label":"Remediate and update plans","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update","coach-document-upload"]}},"id":"remediate-and-update-plans"},{"data":{"description":"Independently confirm the published plan changes actually close the findings","instructions":"**Objective** — Independently confirm that the published plan changes actually close each finding, verified by a reviewer who did not author the changes.\n\n**Inputs**\n- The remediation register and the published, approved plan updates with their new version numbers from the remediate step.\n- A finding-to-edit map pairing each plan-update finding with the specific published edit that claims to close it.\n- The authoritative staff and vendor directory for the contact and escalation cross-checks.\n\n**Procedure**\n1. Build the verification pack: map every plan-update finding to the specific published edit that claims to close it, with side-by-side before-and-after excerpts and the new document version numbers.\n2. Cross-check the corrected contact details and escalation paths against the authoritative directory and flag any mismatches.\n3. Confirm that every changed recovery objective (RTO or RPO) carries a recorded business approval; flag any change published without one.\n4. Record the reviewer's verdict per finding, and route any returned items back to their remediation owner with the reason and a due date.\n\n**Record in AssureSwarm** — On each Issue verified closed, set `actual_remediation_date` and `verified_date` and move its status to closed (item field update); a returned Issue keeps a fresh `target_remediation_date` and stays open. Link each verified finding to its closing plan edit (document link) and attach the verification pack as a document on this step (step document).\n\n**Exit criteria** — An independent reviewer (not a change author) has walked the pack, confirmed each revised procedure is executable — naming the right systems, access, and order of steps — and marked each finding verified closed or returned for rework. No finding is closed without an evidenced edit or a documented risk-acceptance decision.","label":"Verify plan updates","performedBy":{"primitives":["coach-query-data","coach-item-update","coach-document-upload"]}},"id":"verify-plan-updates"},{"data":{"description":"Present the agent-drafted after-action report to management, obtain sign-off, and file the indexed evidence package; that sign-off closes and archives the exercise","instructions":"**Objective** — Present the after-action report to management, obtain written sign-off, file the complete, indexed evidence package, and close the exercise on that signature. This is a join: it waits for the `objectives_met` branch of the evaluate decision and, on the gaps path, for the verified plan updates.\n\n**Inputs**\n- On the met path: the validated scorecard and the exercise record from the evaluate decision.\n- On the gaps path: additionally the remediation register and the verified plan updates from the verify step — both inputs converge here before this step starts.\n- The approved scope charter, exercise package, notification log, captured activity log and timeline, and the decision form from the earlier steps.\n- The standing corrective-action tracker, the exercise calendar, and the records-retention schedule.\n\n**Procedure**\n\n_Items 1–3 are agent-run preparation, item 4 is the human moment, and items 5–8 close the workflow (folded from the former \"Close and archive\" step) — the sign-off recorded on this step is the closure, with no separate confirmation._\n\n1. Draft the after-action report and management briefing: scenario, results against objectives with the actual-versus-target table, key observations, remediation status with owners and dates, residual risks requiring acceptance, and trends versus prior exercises, with every number reconciled to the scorecard.\n2. Assemble the evidence package — the approved charter, the exercise package and notification log, the captured activity log and timeline, the scorecard and decision form, and, where the gaps path ran, the remediation register and verified plan updates — with consistent naming and dates, cross-references to ISO 27001 A.5.29 and A.5.30 and NIST 800-53 CP-4, access controls on sensitive recovery details, and an index of still-open remediation items.\n3. Draft the minutes template to capture management decisions, risk acceptances with the accepting executive named, requested follow-ups, and the proposed date and type of the next exercise.\n4. The owner presents to the sponsor and the management review forum, leads the residual-exposure discussion, and obtains written sign-off: management decides each risk acceptance — naming the accepting executive — and commits to the date and type of the next exercise. Confirm the minutes, sign-off, and evidence index are accurate before filing.\n5. Scan the workflow to confirm every preceding step is complete, the decision form is submitted, and the evidence package is indexed and retrievable by reference; resolve any orphaned item the scan surfaces rather than filing around it.\n6. Confirm every still-open remediation action has been transferred to its standing corrective-action tracker with an owner and a due date.\n7. Update the exercise calendar with the completion date and the committed next exercise, and send the closure notice to the sponsor and participants.\n8. Export and archive the complete workflow record alongside the evidence package with the applied retention period, and confirm the archive is complete and unaltered.\n\n**Record in AssureSwarm** — Attach the after-action report and the indexed evidence package as documents on this step (step document, PDF) and link the underlying records — the exercise Audit item, the scorecard, the decision form, and (on the gaps path) the remediation register and verified plan updates (document link). Set `report_date` on the exercise Audit item (item field update). For each residual exposure management accepts, update the relevant business_continuity Risk item — `treatment` = accept and the agreed `residual_rating` — with the accepting executive named in the minutes. Export the open-remediation index as a CSV of the open Issue items (item export). Then run the workflow scan (workflow scan) and export and archive the workflow record (workflow export), recording the closure date, the closing owner, and the pointer to the evidence package.\n\n**Exit criteria** — The owner has presented to the sponsor and the management review forum, led the residual-exposure discussion, and obtained written sign-off; management has decided each risk acceptance and committed to the next exercise; the recorded minutes, sign-off, and evidence index are confirmed accurate; every orphaned item the scan surfaced is resolved and every still-open remediation action sits on the standing tracker with an owner and due date; and the archive is confirmed complete and unaltered with the closure date, closing owner, and evidence-package pointer recorded, leaving nothing open inside this workflow.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — assembles the after-action report and indexed evidence package with consistent naming, cross-references, and access controls.","label":"Brief management and file evidence","performedBy":{"primitives":["coach-document-upload","coach-item-update","coach-export-package","coach-render-package","coach-workflow-scan","coach-workflow-export"]}},"id":"brief-management-and-file"}],"sourceTemplateId":"workflow-library:controls-bcdr-test-exercise"}