{"description":"Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.","edges":[{"id":"e-plan-and-authorize-test-classify-disposition","source":"plan-and-authorize-test","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Remediate","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-prepare-final-package","label":"Clean","source":"classify-disposition","target":"prepare-final-package","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-prepare-final-package","source":"create-action-plan","target":"prepare-final-package"},{"id":"e-escalate-or-accept-risk-prepare-final-package","source":"escalate-or-accept-risk","target":"prepare-final-package"},{"id":"e-prepare-final-package-handoff-to-related-workflow","source":"prepare-final-package","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{"UC-SDLC-14":"operates","UC-VULN-02":"operates"},"controls":["UC-VULN-02","UC-SDLC-14","UC-SDLC-04","UC-CONFIG-04","UC-NET-01","UC-NET-02","UC-NET-03","UC-NET-04","UC-SDLC-05","UC-VULN-04","UC-VULN-07"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-technical-security-testing-pentest","contentDigest":"sha256:c28fb0e08623dc507cf60fcdf8730d6f0b13de3d95018f9692f7c72965a24317","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:c28fb0e08623dc507cf60fcdf8730d6f0b13de3d95018f9692f7c72965a24317","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-technical-security-testing-pentest"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"controls-technical-security-testing-pentest","source":"coworkcanvas-gallery","standards":["nist-800-53"],"teams":["it"]},"name":"Technical Security Testing & Pentest Engagement","nodes":[{"data":{"description":"Agent scopes the engagement, drafts rules of engagement, and locks the executable workplan; human approves scope and confirms signed authorization before any testing starts","instructions":"**Objective** — Scope the engagement, lock the executable test plan and rules of engagement (ROE), and confirm written authorization is on file before any testing begins.\n\n**Inputs**\n- The anchor: the EXISTING Audit item (audit_type: it_audit) this engagement runs on — this workflow enriches it, it never creates a duplicate. Its `scope` and `description` carry the assessment objective and test type (black / grey / white box; external / internal network; web; wireless).\n- The in-scope system boundary as Process items (process_type: security_process or it_general_control) related to the anchor Audit; the detailed asset / IP / URL inventory itself has no native item type and rides as a document on this step (see Record in AssureSwarm).\n- The control baseline being assured (UC-NET-01..04 network trust, UC-CONFIG-04 configuration, UC-SDLC-04/05/14 secure design, UC-VULN-02/04/07) as Control items in the control library (framework contains nist-800-53).\n- Any open POA&M findings to revisit — open Issue items (source: penetration_test or vulnerability_scan) from prior engagements, related to the affected Controls.\n- The signed authorization / engagement letter and authorization-dependency sign-offs (including any third-party hosting provider) as an upload on this step; available testing windows, source-IP constraints, and emergency escalation contacts recorded in the versioned engagement workplan and native results. Grey/white-box credentials are never stored in AssureSwarm (external system); the ROE document records which credentials were provisioned.\n\n**Procedure**\n1. Confirm the in-scope target boundary: enumerate IP ranges, URLs, hostnames, applications, and accounts, and explicitly list out-of-scope assets so nothing is tested without authorization (NIST 800-115 planning).\n2. Define the assessment objectives and test type — black / grey / white box; external or internal network; web application; wireless — and map each to the control baseline it is meant to assure.\n3. Draft the rules of engagement: permitted techniques, prohibited actions (no denial-of-service, no destructive exploitation without explicit sign-off), testing windows, authorized source IPs, data-handling rules, and stop conditions.\n4. Obtain written authorization to test (the signed engagement letter / \"get-out-of-jail\" authorization) from the system owner and any required third parties, and confirm the authorization dependency is cleared.\n5. Lock the executable workplan: final scope, owners, due dates, evidence requirements, review expectations, and the escalation path with emergency contacts.\n\n**Record in AssureSwarm**\n- Enrich the anchor Audit item: set/confirm `audit_type` (it_audit), `scope` (the locked target boundary and objective), `lead_auditor`, and `period_start` / `period_end` (the testing window); the test-type detail rides in `description`. (Enrich the existing record — do not create a second Audit.)\n- Item relationships: link the Control items being assured (framework nist-800-53) and the in-scope Process items to the anchor Audit; link any open prior-engagement Issue items so the engagement revisits them.\n- Step document: attach the scope + ROE document and the asset / IP / URL inventory (the inventory has no native Asset/System item type in the six-type schema, so it lives as a step document here).\n- Step upload (PBC/external): attach the signed authorization / engagement letter and dependency sign-offs before testing starts.\n- Workplan document and native results: record the executor-owned assignments, testing window, source-IP constraints, escalation contacts and evidence requirements. Reuse the approved scope and signed authorization; do not create a collection form for these executors.\n\n**Exit criteria** — The control owner has approved the scope, ROE, and locked workplan, and the signed authorization is on file, before discovery begins.","label":"Plan and authorize test","performedBy":{"primitives":["coach-query-data","coach-form-create","coach-document-upload"]}},"id":"plan-and-authorize-test"},{"data":{"decisionField":"disposition_path","description":"Judge demonstrated findings, calibrated severity/control mappings and redaction, authorize the report’s delivery and select clean, remediation or significant-issue escalation.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Judge demonstrated findings, calibrated severity/control mappings and redaction, authorize the report’s delivery and select clean, remediation or significant-issue escalation.\n\n**Inputs**\nThe locked workplan, scope, and rules of engagement from the plan-and-authorize step, including the ROE stop conditions and prohibited-action list.\n- The in-scope asset inventory and any credentials issued for grey/white-box testing.\n- The control baseline (Control items, framework nist-800-53) and the affected system context: data sensitivity, internet vs. internal exposure, compensating controls.\n- The methodology, tool set, and agreed testing window recorded at the plan step.\n\n**Decision criteria**\n*The agent prepares the combined evidence and performs the recordkeeping below. Control owner reviewing the authorized testing team’s evidence owns the stated judgments and authorizations.*\n\n*Report results.* Enumerate the authorized attack surface, prove which weaknesses are genuinely exploitable, rate and control-map every confirmed finding, and produce the penetration-test report — the human moment being approval of that report as accurate, complete, and appropriately redacted before delivery.\n\n*Authorized technical procedures, finding analysis and report preparation support the control owner’s combined report and disposition judgment.*\n\n1. Passive reconnaissance: OSINT, DNS and certificate-transparency enumeration, and exposed-service discovery for in-scope assets, avoiding any action that touches an out-of-scope system (NIST 800-115 discovery).\n2. Active scanning: port, service and version scans and host discovery; web-application crawling and content/endpoint discovery; network path mapping across in-scope hosts.\n3. Vulnerability identification: authenticated and unauthenticated vulnerability scans plus misconfiguration enumeration against the control baseline (UC-NET-01..04, UC-CONFIG-04), capturing candidate weaknesses.\n4. Build the attack-surface inventory: hosts, open ports, services and versions, application endpoints, and candidate vulnerabilities, each tagged in-scope or out-of-scope.\n5. Run a scope-adherence check: flag anything discovered outside the authorized boundary and exclude it from further testing, escalating if the boundary itself looks wrong. Discovery coverage must be complete before exploitation starts.\n6. Prioritize candidates by likely business impact and exploitability, and sequence tests to minimize disruption to production targets.\n7. Attempt controlled exploitation within the ROE to separate true positives from scanner noise: authentication bypass, injection, access-control and misconfiguration flaws, weak cryptography, and privilege escalation.\n8. For each successful exploit, capture proof-of-concept evidence — request/response pairs, screenshots, commands run, and the access gained — noting lateral-movement potential and secure-design root causes (UC-SDLC-04/05, UC-VULN-02/04/07).\n9. Chain findings where relevant to demonstrate a realistic attack path, and halt immediately at any ROE stop condition, escalating before proceeding.\n10. Discard false positives with a recorded rationale so only demonstrated issues carry forward.\n11. Score each confirmed finding with CVSS (v3.1 or v4.0) base metrics — plus temporal and environmental metrics where the target context justifies them — and record the full vector string.\n12. Adjust to business risk using data sensitivity, exposure (internet-facing vs. internal), and any compensating controls, producing a final rating of Critical / High / Medium / Low / Informational.\n13. Map each finding to the affected unified controls (UC-NET-01..04, UC-CONFIG-04, UC-VULN-02/04/07) and to secure-SDLC design defects (UC-SDLC-04/05/14), identifying the root-cause defect class.\n14. Deduplicate and cluster related findings that share one underlying defect into a single root-cause finding, so the count is not inflated.\n15. Draft specific remediation guidance per finding: the concrete fix, configuration change, or code correction.\n16. Write the executive summary: objective, scope, overall risk posture, headline findings, and business impact in non-technical language.\n17. Compile the technical findings section — per finding: description, affected assets, severity and CVSS vector, PoC evidence, mapped controls/defects, and remediation guidance.\n18. Document the methodology, scope, ROE, tools, and testing window so the assessment is reproducible (NIST 800-115 reporting), and append informational observations and any out-of-scope items noted during testing.\n19. QA the draft: severity consistency across findings, evidence completeness, and no over-exposure of sensitive data — redact captured secrets and personal data where required.\n20. The control owner reads the report against the evidence: every target tested sat inside the authorized boundary and testing stayed within the ROE, each reported finding is reproducibly demonstrated, the severity ratings and control/defect mappings are calibrated and defensible, and the redaction is sufficient for the intended audience. Approve for delivery, or return it naming the specific findings, ratings, or passages to fix.\n\n*Classify disposition.* Classify the delivered result of the engagement so only the relevant closure path continues: no reportable gap, remediation required, or a significant issue needing escalation. Owned by the control owner. Before the decision, the agent prepares the evidence:\n21. Summarize the reported findings by severity and count (coach-query-data), and state the agreed reporting threshold.\n22. Flag any Critical-rated, actively-exploitable, or sensitive-data-exposure finding that would force escalation regardless of count.\n23. Draft the disposition recommendation with evidence references and attach it (coach-document-upload).\n\n\n\n`clean` — no reportable gap: no finding sits at or above the agreed reporting threshold and nothing requires tracked remediation.\n- `remediate` — one or more findings at or above the threshold require an owned, tracked remediation / POA&M plan (the typical outcome when Medium-or-higher findings exist).\n- `escalate` — a significant issue (Critical CVSS, demonstrated active exploitation, or exposed sensitive data) needs immediate escalation and a fix-or-formally-accept-risk decision above the engagement team.\n\n**Record in AssureSwarm**\nStep document: the attack-surface inventory (hosts, ports, services, endpoints, candidate vulnerabilities — XLSX/CSV) with the raw scan output files, plus the confirmed in-scope target list and any out-of-scope exclusions, cross-referenced to the Process items and control baseline linked to the anchor Audit at the plan step. The six-type schema has no native Asset/System item, so the inventory lives here as a document, not as items.\n- Item create: one Issue per confirmed finding — `issue_type: finding`, `source: penetration_test`, `identified_date`, `description` (affected assets + PoC summary). Link each finding Issue to the anchor Audit (provenance).\n- Item field update on each finding Issue: `severity` (critical / high / medium / low — informational findings carry the lowest severity with a note), `root_cause` (the secure-design defect class plus the full CVSS vector string — Issue has no native CVSS field in the six-type schema, so the vector rides in `root_cause`), and `recommendation` (the specific remediation guidance).\n- Item relationships: link each finding Issue to its affected Control item(s) (the impaired baseline controls); clustered duplicates collapse into one root-cause Issue rather than inflating the count.\n- Step document: each finding's PoC evidence (request/response pairs, screenshots, commands, access gained) and the confirmed-vs-false-positive disposition log covering every candidate with its rationale.\n- Step document: the rendered penetration-test report (executive summary + technical findings, PDF/DOCX) and its evidence package (ZIP), with each report finding linked back to its AssureSwarm finding Issue so the narrative and the register stay in sync.\n\nStep form: submit `disposition_path` with the chosen branch, plus the step result (with evidence references to the report and finding Issues) and the step's approver record.\n- Step document: attach the disposition recommendation memo.\n\n**Exit criteria**\nAttack-surface inventory, disposition log, and PoC evidence are attached and show discovery coverage complete inside the authorized boundary with every ROE stop condition honoured; every carried-forward finding exists as a rated, control-mapped Issue linked to the anchor Audit; and the control owner has approved the report as accurate, complete, and appropriately redacted before it is delivered.\n\nThe `disposition_path` form is submitted with the branch, rationale, and decision owner recorded, and the unused branches are prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the report narrative, per-finding evidence, and methodology into a single delivery package.","kind":"decision","label":"Classify disposition","performedBy":{"primitives":["coach-render-package","coach-items-link","coach-document-upload","coach-query-data","coach-item-update","coach-item-create"]}},"id":"classify-disposition"},{"data":{"description":"Agent converts each reportable finding into an owned, dated POA&M with defined closure evidence; human confirms every finding is owned, mitigated, and scheduled","instructions":"**Objective** — Produce owned, dated remediation plans (POA&M entries) for every reportable finding on the remediation path.\n\n**Inputs**\n- The reported findings routed to the remediation branch by the disposition decision (its reviewed output), with severity, mapped controls, and remediation guidance.\n\n**Procedure**\n1. For each finding, capture root cause, remediation owner, and a target date sized to severity (for example, Critical no later than 30 days, High no later than 90 days), plus any interim mitigation to reduce exposure now.\n2. Define the validation evidence required to close each item and the retest method that will be used to confirm the fix when fixes are retested at the final-package step.\n3. Record the plan on the finding Issue itself — the finding IS the POA&M record; no separate POA&M item is created, and its existing links to the source finding are already in place. Confirm the finding stays linked to the affected Control and the anchor Audit.\n4. Set the reporting cadence for open items and the escalation trigger for anything that goes past its due date.\n\n**Record in AssureSwarm**\n- Item field update on each reportable finding Issue (no separate POA&M item): `remediation_plan` (root cause, interim mitigation, and the defined closure evidence), `issue_owner`, `target_remediation_date` (sized to severity — e.g. critical ≤ 30 days, high ≤ 90 days), and `management_response`.\n- Item relationships: confirm each finding Issue stays linked to its affected Control and the anchor Audit.\n- Native results and the finding Issue: record each executor-owned action, owner, due date, interim mitigation and closure evidence. Use native approval for owner commitments; do not issue remediation owners another questionnaire.\n\n**Exit criteria** — The control owner confirms every reportable finding has an owned, dated action plan with defined closure evidence before its fix is retested at the final-package step.","label":"Create action plan","performedBy":{"primitives":["coach-item-update","coach-item-create","coach-items-link","coach-form-create"]}},"id":"create-action-plan"},{"data":{"description":"Agent prepares a decision memo quantifying impact and routes it to the accountable authority; human confirms a documented remediate-or-formally-accept decision with conditions is on file","instructions":"**Objective** — Escalate a significant issue to the accountable authority and record a documented fix-or-formally-accept-risk decision.\n\n**Inputs**\n- The escalate-branch finding(s) from the disposition decision (its reviewed output): affected assets, mapped controls, demonstrated exploitability, and severity.\n\n**Procedure**\n1. Prepare a decision memo stating the issue, the demonstrated impact, the affected assets and controls, and the proof of exploitability.\n2. Quantify business and technical impact and likelihood, state the recommended action, and note any emergency interim mitigation already applied.\n3. Route the memo to the accountable owner — control owner, system owner, or authorizing official — and capture their decision: remediate on an accelerated timeline, or formally accept the risk with stated conditions and an expiry date. Record an acceptance structurally, not as memo text: raise a Risk item and set `treatment: accept` on it, and capture the acceptance as a `policy_exception` Issue carrying the accepting authority and the re-review date.\n4. Define follow-up ownership and the monitoring trigger for any accepted risk so it is revisited rather than forgotten.\n\n**Record in AssureSwarm**\n- Step document: attach the decision memo and the signed disposition on this step.\n- Item create (on a formal risk acceptance): a Risk item — `category: cyber_security`, `treatment: accept`, `residual_rating`, `risk_owner` — linked to the affected Control and the source finding Issue; plus an Issue with `issue_type: policy_exception`, `exception_approver` (the accepting authority) and `exception_expiry_date` (the re-review date), linked to that Risk.\n- Notify the accountable owner and record the decision, conditions, and expiry (coach-notify).\n\n**Exit criteria** — The control owner confirms the issue reached the accountable authority and a documented remediate-or-accept decision with conditions and an owner is on file.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` routes the escalation memo to the accountable owner and records their acknowledgement.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-item-create","coach-notify","coach-document-upload"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Agent retests each claimed fix against its original PoC and assembles the report, findings, retest and escalation outcomes, residual risk, and proposed conclusion into one package; human approves it as complete and consistent","instructions":"**Objective** — Retest every claimed fix against its original proof of concept and assemble the engagement's final evidence and decision package, consistent across whichever closure path reached this step, for the control owner's approval.\n\n**Inputs**\n- Whatever the taken path produced: the approved report alone (clean disposition), the action plan / POA&M items marked claimed-fixed (remediation path), or the escalation decision and risk-acceptance record (escalate path).\n- The original PoC steps and evidence for each finding, and the rules of engagement they were run under.\n- The validated-findings register with its severity and control/defect mappings, and the approved penetration-test report.\n\n**Procedure**\n\n*Retest and package assembly support the control owner’s subsequent judgment of the changed evidence.*\n\n1. For each finding whose fix is claimed, re-run the original exploitation / PoC steps against the fixed target, within the same ROE. (On the clean path there is nothing to retest; on the escalate path retest only what was remediated in the interim.)\n2. Confirm the vulnerability is no longer exploitable, and specifically probe for incomplete fixes (for example, a filter or WAF rule that a small payload change bypasses) and for regressions the fix introduced elsewhere.\n3. Record the retest outcome per finding — verified-closed, partially-remediated, or still-open — and reopen any item whose fix fails.\n4. Recompute residual risk and severity for any finding that is only partially remediated so the final package reflects reality.\n5. Compile the report, the validated-findings register with PoC evidence, the severity and control/defect mappings, the remediation / POA&M status, retest outcomes, and any escalation or risk-acceptance decisions into one package.\n6. Summarize residual risk: what remains open, its owner, and the monitoring plan for any accepted risk.\n7. Note assumptions, constraints, and out-of-scope items so the downstream reader understands the package's limits.\n8. Draft the proposed engagement conclusion and control-assurance statement — which unified controls this test assured and their pass / fail / observation status.\n9. The control owner reviews the assembled package: every claimed fix carries a recorded verified-closed, partially-remediated or reopened outcome with its retest evidence; the residual-risk summary, assumptions and proposed conclusion are consistent with the report and with the retest or escalation evidence; and nothing in the package contradicts the findings register. Approve the package, or return it naming what is incomplete or inconsistent.\n\n**Record in AssureSwarm**\n- Item field update on each retested finding Issue: on a verified-closed fix set `actual_remediation_date` and `verified_date`; a reopened finding is left with `verified_date` cleared and its `severity` updated to the recomputed residual rating (partially-remediated findings recompute residual risk here).\n- Step document: attach the retest log with the re-run PoC evidence per finding.\n- Render and attach the final package (coach-render-package, coach-document-upload).\n- Item field update on anchor Audit: set `rating` (satisfactory / needs_improvement / unsatisfactory — the per-control assurance conclusion rolled up to the engagement) and `report_date`, so the assurance conclusion and report date write back to the anchor record's fields (coach-item-update).\n- Record the residual-risk summary and proposed conclusion (coach-query-data).\n\n**Exit criteria** — Every claimed fix has been retested with a recorded outcome and any failed fix is reopened with its residual severity recomputed; the final package is attached with residual risk, assumptions, and the proposed conclusion; the anchor Audit carries the engagement `rating` and `report_date`; and the control owner has approved the package as complete and consistent with the report and the retest or escalation evidence.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the report, findings evidence, retest results, and assurance conclusion into the deliverable package.","label":"Prepare final package","performedBy":{"primitives":["coach-query-data","coach-render-package","coach-item-update","coach-document-upload"]}},"id":"prepare-final-package"},{"data":{"description":"Agent packages open items and the assurance conclusion for the downstream remediation and assurance workflows, notifies their owners, and archives the engagement record under retention; human confirms both received a clear carry-forward scope and their approval here closes the engagement","instructions":"**Objective** — Hand the final package and open items to the downstream remediation and assurance workflows without duplicating this engagement's work, and close the engagement behind them under retention — the approval recorded on this step is the closure.\n\n**Inputs**\n- The approved final package from the prepare-final-package step (its reviewed output), including open POA&M items, the residual-risk statement, and the control-assurance conclusion.\n- The designated evidence-repository retention configuration and the assessment cadence calendar.\n\n**Procedure**\n\n*Receiving-owner acceptance authorizes the subsequent archive and calendar updates; filing adds no separate confirmation.*\n\n1. Package the open POA&M items, residual-risk statement, and mapped-control results for the Security Control Assessment & POA&M Remediation workflow.\n2. Package the assurance conclusion and per-control pass / fail results for the Cybersecurity Assurance Review workflow.\n3. Create or link the downstream workflow instances and pass each package, stating explicitly what each downstream must NOT repeat — for example, re-scanning already-validated findings or re-authorizing the same scope.\n4. Notify the receiving owners and confirm receipt.\n5. Export the full engagement record — scope, ROE, signed authorization, findings, PoC evidence, report, retest results, and dispositions — and archive it under retention controls, recording the archive location and reference (coach-workflow-export).\n6. Update the linked control-execution and POA&M records with the engagement result and the per-control pass / fail status.\n7. Schedule the next assessment cadence and any monitoring or follow-up for accepted risks and open POA&M items.\n8. Communicate the final decision and closure to stakeholders, then record the closing approval here: the control owner confirms both downstream owners hold a package with a clear scope of what carries forward and what does not, the archived record is immutable and retrievable, the next assessment is scheduled, and nothing remains open without a tracked owner. That approval declares the engagement closed.\n\n**Record in AssureSwarm**\n- Link the downstream workflow instances and items and attach the handoff record (coach-document-link, coach-items-link).\n- Notify the receiving owners and record acknowledgement (coach-notify).\n- Record the archive reference for the exported engagement record.\n- Item field update on anchor Audit: set `fieldwork_end` and `report_date`, and move `status` to complete to close the engagement record; attach the closure record (coach-item-update, coach-document-upload).\n\n**Exit criteria** — Both downstream owners have acknowledged receipt of their package with a clear carry-forward scope; the exported engagement record is archived immutably and retrievably with its reference recorded; the anchor Audit is `status: complete` with `fieldwork_end` and `report_date` set; the next assessment and any accepted-risk monitoring are scheduled; and the control owner's approval on this step stands as the engagement's closure.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` delivers the handoff package to the downstream remediation and assurance workflow owners and captures receipt.","label":"Handoff to related workflow","performedBy":{"primitives":["coach-notify","coach-items-link","coach-document-upload","coach-workflow-export","coach-item-update"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:controls-technical-security-testing-pentest"}