{"description":"Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.","edges":[{"id":"e-route-stakeholder-review-approve-policy","source":"route-stakeholder-review","target":"approve-policy"},{"id":"e-approve-policy-classify-disposition","source":"approve-policy","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Complete","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Monitor","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-14","UC-TRAIN-04","UC-CONFIG-09","UC-GOV-29","UC-GOV-30","UC-GOV-31","UC-GOV-32","UC-GOV-34","UC-GOV-35","UC-GOV-36","UC-HR-07"],"department":"compliance-legal","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-policy-lifecycle-management","contentDigest":"sha256:07f7c6423331d5325e268383c0375b4be4b9e74de04d1df3c1d3bb5ecf4dbbaa","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:07f7c6423331d5325e268383c0375b4be4b9e74de04d1df3c1d3bb5ecf4dbbaa","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-policy-lifecycle-management"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-policy-lifecycle-management","source":"coworkcanvas-gallery","standards":["iso-27001","cobit-2019"],"teams":["compliance-legal","executive"]},"name":"Policy Lifecycle Management","nodes":[{"data":{"description":"Policy owner and required control/legal/security/privacy/HR reviewers: Review source-grounded policy commitments, legal boilerplate, feasibility and cross-policy conflicts, and disposition the consolidated redline.","instructions":"**Objective** — Draft the bounded policy with control and authority links and obtain a dispositioned multidisciplinary review of its obligations.\n\n**Inputs**\n- On a refresh cycle, the existing Policy item being revised (policy library) — its `policy_owner`, `policy_type`, `framework`, `domains`, `review_frequency`, `effective_date`, and current obligation text in `description`. A net-new policy has no item yet; it is created here.\n- Policy title, purpose, scope and applicability, and the accountable owner — interview the owner for these intake fields.\n- The controls the policy governs (link targets) — Control items in the control library — and the external authority standards it implements (ISO 27001, SOC 2, NIST, COBIT, GDPR…), which map onto `Policy.framework`; specific Annex A codes or statutes outside that enum are cited in the obligation text.\n- Applicable jurisdictions, effective date, and review cadence (typically annual).\n- The prior policy version being revised (uploaded as a DOCX on this step) plus firm-specific legal boilerplate that must be preserved.\n- Enterprise risk assessment (Risk items) and control-design outputs (Control items), consumed here as read-only inputs when they exist; this workflow does not produce or edit them.\n- The drafted Policy item, its attached policy document, and its Policy ↔ Control links from the policy authoring stage.\n- The reviewer roster: control owners (derived from `Control.control_owner` on the linked governed Controls), plus legal, security, privacy, HR, and any function the policy binds — the full roster and review SLA uploaded as a document on this step.\n- The organization's review SLA (comment window, commonly 10 business days).\n\n**Procedure**\n*Autonomous preparation incorporates Author policy; Policy owner and required control/legal/security/privacy/HR reviewers reviews the combined evidence.*\n1. Lock the workplan first: fix the policy's boundary (what it commits the organization to do and what it explicitly does not cover), the accountable owner, the contributing reviewers, due dates, the evidence the final record must carry, and the review cadence. Freeze these before drafting so reviewers assess a stable target.\n2. Interview the owner for the structured intake fields above (title, scope, applicability, jurisdictions, governed controls, authority standards, effective and review dates).\n3. Draft the policy record: obligation text stating what the policy requires, plus scope, applicability, owner, jurisdictions, and effective and review dates. Write obligations as testable commitments, not aspirations. Obligation text and jurisdictions have no dedicated Policy field — carry them in `Policy.description` and the attached policy document.\n4. Link every governed control to the policy via a Policy ↔ Control relationship, and set the implemented authority standards on `Policy.framework`. Represent standards as `framework` values and specific criteria as citations in the obligation text, never as raw codes pasted into an unrelated field.\n5. Preserve firm-specific legal boilerplate verbatim and flag those sections for legal review rather than rewriting them.\n6. Never invent risk scores or authority citations — capture only owner-provided or source-grounded content.\n7. Identify required reviewers from the policy's scope and linked controls — each governed control's owner reviews the sections that touch their control.\n8. Distribute the draft with a clear comment window and an explicit ask: accuracy of the obligations, operational feasibility, and conflicts with other policies.\n9. Track responses; chase non-responders before the window closes; record who reviewed and who was silent.\n10. Consolidate all comments into one redline, de-duplicating overlaps and flagging conflicts between reviewers for the owner to resolve.\n11. Disposition each comment as accept, modify, or reject with a one-line rationale; route substantive obligation changes back through the owner before proceeding.\n\n**Record in AssureSwarm**\n- Item create/enrich: the Policy item (`policy_type`, `policy_owner`, `framework` = authority standards, `domains`, `review_frequency`, `effective_date`, `next_review_date`); title in the item name, obligation text and jurisdictions in `description`.\n- Step document: attach the drafted policy document (DOCX) and, on a revision, the prior version to this step.\n- Item relationship: Policy ↔ each governed Control.\n- Step document: attach the consolidated redline (DOCX) and the reviewer response log to this step.\n- Item field update: move the Policy item's status to in-review (item status) and note reviewer sign-offs on the step.\n\n**Exit criteria**\nReview source-grounded policy commitments, legal boilerplate, feasibility and cross-policy conflicts, and disposition the consolidated redline.\nA drafted or revised policy exists with obligation text, scope, owner, and cadence plus complete control and authority links; boilerplate is flagged not rewritten; there are no fabricated citations or scores; the record is ready to route for stakeholder review.\nEvery required reviewer has responded or been recorded as non-responding; comments are consolidated and dispositioned; conflicts are resolved or escalated; the redline is ready for approval.","label":"Route stakeholder review","performedBy":{"agent":"grc-artist","note":"scopes the workplan then drafts the policy with obligations, citations, and control links","primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"route-stakeholder-review"},{"data":{"description":"Authorized policy approver: Authorize the reviewed policy and pre-publication conditions; after that approval publish the exact version and launch its one-time acknowledgement campaign.","formData":{"fields":[{"key":"attestation","label":"I have read this policy and understand my responsibilities under it","required":true,"type":"checkbox"},{"key":"questions","label":"Questions or clarifications requested","type":"textarea"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Approve the reviewed policy for publication, then publish only that approved version and launch the scoped workforce acknowledgement campaign.\n\n**Inputs**\n- The consolidated, dispositioned redline from stakeholder review.\n- The governance matrix identifying who is authorized to approve this policy class (owner, GRC lead, executive sponsor, or board delegate).\n- Any conditions attached during review.\n- The approved Policy item with `approved_by`, `effective_date`, and its applicability scope.\n- The workforce or role population that must attest, derived from the applicability scope — the audience list comes from the HRIS and is uploaded as a CSV on this step (the AssureSwarm copy is the evidence).\n- The organization's attestation SLA, reminder cadence, and completion threshold (commonly 95%), captured in a campaign-parameters note on this step.\n\n**Procedure**\n*Autonomous preparation incorporates Publish and trigger attestation; Authorized policy approver reviews the combined evidence.*\n1. Confirm all substantive review comments are resolved, or explicitly waived with a documented rationale.\n2. Present the near-final policy and the comment-disposition log to the authorized approver named in the governance matrix.\n3. Capture the approval decision, the approver's identity, the date, and any conditions the approver attaches (for example, publish only after training material is ready).\n4. If the approver requires changes, return to authoring or review rather than publishing.\n5. Set the effective date consistent with any pre-publication conditions.\n6. Publish the approved version, superseding the prior version and archiving that prior version read-only so the version history stays intact.\n7. Determine the attestation audience from the policy's applicability (all staff, or specific roles and functions).\n8. Create the attestation campaign: one acknowledgement assignment per person or per role, each with a due date driven by the SLA.\n9. Notify the audience with the policy link and the acknowledgement ask; schedule automatic reminders ahead of the due date.\n10. Communicate the publication to affected control owners so dependent procedures are updated.\n\n**Record in AssureSwarm**\n- Item field update: set `Policy.approved_by` and `Policy.effective_date`, and move the item status to approved.\n- Step document: attach the signed approval record with approver, date, and any attached conditions (conditions have no native Policy field — kept on the step).\n- Item field update: move the Policy item to published (item status) and stamp `Policy.version`; attach the published policy document to the item and retain the superseded version as an archived document on the same step.\n- The form on this step, answered by policy audience members outside all workflow executing and approving roles, captures only their personal attestation that they read and understand their responsibilities and any questions; bind each assignment to the published policy/version and retain its submission timestamp — send it with the campaign's form assignments.\n- Step document: the attestation campaign register (CSV, one row per person/role with due date) and the launch notification log — there is no Attestation/Acknowledgement item type, so the per-person acknowledgements live on the step, not as items.\n- Send the launch notification and scheduled reminders to the audience.\n\n**Exit criteria**\nAuthorize the reviewed policy and pre-publication conditions; after that approval publish the exact version and launch its one-time acknowledgement campaign.\nA named, authorized approver has signed off; approver, date, effective date, and conditions are recorded; no unresolved blocking comments remain.\nThe approved policy is published and the prior version archived read-only; the attestation campaign is live with a due date; the audience has been notified.\n\n**Form recipient** — this step's form is answered by policy audience members outside all workflow executing and approving roles, not by the policy owner, reviewers, approvers, action/risk owners or receiving owner. Record those executors’ contributions in native results and approvals. Send it with a form assignment; the owner's own work goes in the step result.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — launches the attestation campaign notifications and scheduled reminders to the target audience.","label":"Approve policy","performedBy":{"primitives":["coach-item-create","coach-notify"]}},"id":"approve-policy"},{"data":{"decisionField":"disposition_path","description":"Policy owner or GRC lead: Judge the frozen acknowledgement population and cited section-level alignment changes, approve only justified refresh edits, and decide complete, action or watch.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Freeze the publication acknowledgement record, perform the scheduled source-grounded alignment review, and decide the cycle’s complete, gap or monitor outcome.\n\n**Decision criteria**\nInputs for preparation: - The live attestation campaign and its audience list from publication.\n- The attestation due date and the escalation path for non-responders.\n- The published Policy item and its sections, its Policy ↔ Control links, its `next_review_date`, and the last-review date.\n- The review cadence (`Policy.review_frequency`, typically annual) and any regulatory-change signal that triggers an off-cycle review.\n\n*Autonomous preparation incorporates Track acknowledgements; Schedule refresh; Policy owner or GRC lead reviews the combined evidence.*\n1. Query acknowledgement status across the audience; compute the completion rate and list the outstanding attestors.\n2. Send reminders to non-responders on the reminder cadence; escalate to managers for anyone past due.\n3. Investigate structural gaps (leavers, role changes, audience-definition errors) and correct the audience rather than counting those as refusals.\n4. When the window closes, freeze the completion record: who attested and when, who did not, and the disposition of each non-completion.\n5. Flag any completion rate below the organization's threshold (commonly 95%) for the disposition decision.\n6. Set or confirm the next-review date and register the policy in the recurring sweep of policies due for review.\n7. When a review runs, pull the policy's linked controls and the recent regulatory or standard changes affecting them.\n8. For each linked control, judge whether the policy text still describes the control's current design; flag misalignments.\n9. For each recent regulatory change, judge whether the policy must be updated to address it; flag gaps.\n10. For each policy section, judge whether it is still relevant or has been superseded.\n11. Propose updates as a section-by-section diff with rationale; classify overall alignment as aligned, drift, or major misalignment, citing the controls and authority sources behind each finding.\n12. Flag firm-specific legal boilerplate for review but do not propose wording changes for it.\n13. Present each proposed change to the owner to accept, edit, or reject; apply only the approved subset and stamp the refresh date. Never fabricate regulatory citations or control designs — every finding must trace to a linked control or a cited source.\n\n- **Complete** (`complete`): the policy is published, attestation is at or above threshold, and the alignment review found the policy aligned — no open actions. Route straight to packaging.\n- **Gaps require action** (`gaps`): attestation is below threshold, or the alignment review found drift or major misalignment, or a control/regulatory gap needs remediation — an owned action plan is required.\n- **Monitor without immediate action** (`monitor`): a residual concern exists that does not warrant a remediation plan now but must be escalated for risk acceptance or watch — for example a known minor drift accepted until the next scheduled refresh.\n\n**Record in AssureSwarm**\n- Step document: update the campaign register and attach the frozen workforce attestation completion record (XLSX — who attested and when, non-responder dispositions, and the completion rate) to this step. Acknowledgements are not items (no Attestation type), so the completion record on the step is the authoritative evidence.\n- Item field update: set `Policy.next_review_date` and `Policy.review_frequency`; on an applied refresh, bump `Policy.version` and `Policy.effective_date`.\n- Step document: attach the section-by-section alignment verdict (memo with the per-section diff, the aligned/drift/major-misalignment classification with citations, and the accept/edit/reject disposition of each proposed change) to this step.\n- Submit the `disposition_path` SELECT with the chosen value; in the rationale note record the decision owner and the rationale, with evidence references to the frozen completion report and the alignment verdict.\n\n**Exit criteria**\nJudge the frozen acknowledgement population and cited section-level alignment changes, approve only justified refresh edits, and decide complete, action or watch.\nThe completion rate is computed against the audience; non-responders are chased and dispositioned; a frozen, dated completion record is attached; sub-threshold completion is flagged.\nThe cadence and next-review date are set; the alignment verdict (aligned, drift, or major misalignment) is recorded with citations; only owner-approved changes are applied; gaps requiring action are routed onward.\n`disposition_path` is submitted with a rationale; unused branches are prunable because the branch edge values match the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","note":"sets review cadence and runs policy alignment review","primitives":["coach-query-data","coach-item-create"]}},"id":"classify-disposition"},{"data":{"description":"Convert identified gaps into an owned, dated remediation plan","instructions":"**Objective** — Convert the identified gaps into an owned, dated remediation plan linked to the policy and affected controls.\n\n**Inputs**\n- The disposition decision's rationale and the specific gaps it named (sub-threshold attestation, alignment drift, or control/regulatory gaps).\n- The accountable owner for each gap.\n\n**Procedure**\n1. For each gap, state the root cause — distinguish a policy-text problem from a control-design problem from an attestation-process problem, because each routes to a different fix.\n2. Assign a single accountable owner, a due date, and interim mitigation where the gap carries live risk.\n3. Define the validation evidence that will prove the gap closed and the reporting cadence until then.\n4. Link each action to the policy and to the affected control so closure is traceable.\n\n**Record in AssureSwarm**\n- Item create: one Issue per gap — `issue_type: deficiency` (or `observation`), `source: compliance_review`, `issue_owner`, `target_remediation_date`, `remediation_plan` (interim mitigation and validation evidence captured in `remediation_plan`/`description` — no dedicated fields).\n- Item relationship: each Issue ↔ the Policy and ↔ each affected governed Control.\n\n**Exit criteria** — Every gap has an owned, dated action with defined validation evidence and a reporting cadence, linked to the policy and affected controls.","label":"Create action plan","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"Escalate the residual concern for a documented risk-acceptance or watch decision","instructions":"**Objective** — Escalate the residual concern to the right authority for a documented risk-acceptance or watch decision.\n\n**Inputs**\n- The monitor-path rationale and the residual concern (for example an accepted minor drift, or sub-threshold attestation for a small population).\n- The governance matrix identifying the risk owner, GRC lead, executive sponsor, or board delegate authorized to accept.\n\n**Procedure**\n1. Prepare a concise decision memo: the concern, why no immediate remediation is proposed, and the exposure if it is left unaddressed.\n2. Quantify impact and likelihood in the organization's risk terms; state the watch trigger that would reopen action.\n3. Route to the authorized acceptor from the governance matrix; capture their decision, conditions, and follow-up ownership.\n4. Set the monitoring trigger and the date the acceptance is revisited (no later than the next scheduled refresh).\n\n**Record in AssureSwarm**\n- Item create: a policy_exception Issue — `issue_type: policy_exception`, `exception_approver` (the acceptor), `exception_expiry_date` (the revisit date, no later than the next scheduled refresh), with the memo rationale in `description`.\n- Item field update: on the linked Risk, set `treatment: accept` and `residual_rating`, with `risk_owner` = the acceptor.\n- Item relationship: the policy_exception Issue ↔ the Policy and ↔ the accepted Risk.\n- Step document: attach the risk-acceptance decision memo (quantified exposure, conditions, watch trigger) to this step — exposure and watch trigger have no native fields.\n\n**Exit criteria** — A named authority has accepted the residual risk or escalated it, with conditions, quantified exposure, a watch trigger, and a revisit date recorded.","label":"Escalate or accept risk","performedBy":{"primitives":["coach-item-create","coach-items-link"]}},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Final governance approver: Judge the final evidence-backed policy-cycle conclusion and acceptably owned open actions, approving or requiring correction.","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Compile the final policy-cycle evidence and obtain the accountable approver’s approve-or-revise decision.\n\n**Decision criteria**\nInputs for preparation: - The published policy, the frozen attestation completion report, and the alignment verdict.\n- The disposition decision and any action plan or risk-acceptance memo produced from it.\n\n*Autonomous preparation incorporates Prepare final package; Final governance approver reviews the combined evidence.*\n1. Assemble the package: the final policy version, its control and authority links, the attestation completion record, the alignment verdict, the disposition, and any action plan or acceptance memo.\n2. Note residual constraints and the proposed conclusion (publish-and-close, or close-with-open-actions).\n3. Cross-check that every conclusion traces to evidence in the package — no unsupported assertions.\n4. Render the package into the format the approver expects and attach it for sign-off.\n\n- **Approved** (`approved`): the package is complete, its conclusions are evidence-backed, and any open actions are acceptably owned and dated — sign off and proceed to record the decision.\n- **Revision required** (`revise`): evidence is missing, a conclusion is unsupported, or an action plan is inadequate — return the package for rework before sign-off.\n\n**Record in AssureSwarm**\n- Step document: attach the compiled approval-ready policy package (PDF/ZIP — the final policy, its control and authority links, the attestation completion record, the alignment verdict, the disposition, and any action plan or acceptance memo) to this step; link it to the Policy item.\n- Submit the `approval_path` SELECT with the chosen value; in the rationale note record the approver's identity and the rationale, with references to the package.\n\n**Exit criteria**\nJudge the final evidence-backed policy-cycle conclusion and acceptably owned open actions, approving or requiring correction.\nA single package exists containing the policy, attestation record, alignment verdict, disposition, and outcomes; every conclusion is evidence-traceable; the package is attached and ready for approval.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` — assembles the linked policy, attestation, and decision artifacts into a single approval-ready package.\n`approval_path` is submitted with a rationale; unused branches are prunable because the branch edge values match the selected form value.","kind":"decision","label":"Approve or revise package","performedBy":{"primitives":["coach-render-package"]}},"id":"approve-or-revise-package"},{"data":{"description":"Address reviewer revision comments so the package can be re-approved","instructions":"**Objective** — Address the reviewer's revision comments so the package can be re-approved.\n\n**Inputs**\n- The revise decision's comments and the deficient package.\n\n**Procedure**\n1. Address each comment: supply the missing evidence, correct any unsupported conclusion, or strengthen the action plan.\n2. Document what changed and why, keeping the prior version for the audit trail.\n3. Re-attach the corrected package and obtain the authorized approver’s final approval, retaining the approver, date and any standing conditions. Do not advance while approval is outstanding.\n\n**Record in AssureSwarm**\n- Step document: re-attach the corrected policy package and a change log documenting what changed and why, retaining the prior version for the audit trail, on this step.\n\n**Exit criteria** — Every revision comment is resolved with a documented change; the corrected package is re-attached and actually approved before its approval decision is recorded.","label":"Resolve approval conditions"},"id":"resolve-approval-conditions"},{"data":{"description":"Regulatory Compliance Attestation receiving owner: Accept the approved policy package, non-duplicated publication campaign and open conditions; retain the existing approval and archive the accepted handoff.","instructions":"**Objective** — Record the policy cycle’s actual approval and obtain downstream acceptance of the package and do-not-repeat boundary, then archive and schedule the next review.\n\n**Inputs**\n- The approved package and the approver's decision from the approval checkpoint (a direct approval, or an approval after conditions were resolved).\n- The recorded approval decision and the final approval-ready policy package.\n- The published Policy item with its control and authority (`framework`) links, and the superseded prior version.\n- The Regulatory Compliance Attestation Cycle as the receiving workflow.\n- The frozen workforce attestation completion record and any open conditions carried out of the cycle.\n\n**Procedure**\n*Autonomous preparation incorporates Record approval decision; Regulatory Compliance Attestation receiving owner reviews the combined evidence.*\n1. Capture the approver's identity, the approval date, and any standing conditions.\n2. Assign follow-up ownership for each condition with a due date.\n3. Set the policy record's governance status to approved-and-current and link the decision record.\n4. Create or link an instance of the Regulatory Compliance Attestation Cycle for this policy.\n5. Pass the final package: the published policy, the attestation completion record, the control and authority links, and open conditions.\n6. State the assumptions the downstream workflow may rely on and the work it should not repeat — for example the acknowledgement campaign just completed here.\n7. Confirm the receiving owner has accepted the handoff.\n8. Archive the final package and lock the cycle's records read-only.\n9. Update linked records: set the policy status to current, confirm the controls' policy links, and confirm the superseded version is archived.\n10. Confirm the next-review date and monitoring triggers are scheduled so the policy re-enters the cadence.\n11. Communicate the closed outcome to the owner and affected stakeholders.\n\n**Record in AssureSwarm**\n- Item field update: set `Policy.approved_by` and move the item status to approved-and-current.\n- Step document: attach the final approval memo (approver, date, standing conditions, and follow-up owners — conditions and follow-up owners have no native Policy field) to this step.\n- Handoff package: attach the handoff note to this step and link the Regulatory Compliance Attestation Cycle instance to the Policy item. The note passes the published policy, the frozen attestation completion record, the Policy ↔ Control and `framework` authority links, and open conditions — and explicitly names the acknowledgement campaign completed here as not-to-be-repeated downstream, so the regulatory attestation cycle does not double-run it.\n- Workflow instance: this run, attached to the Policy item, is the locked audit trail — archive the final package and lock its records read-only.\n- Item field update: set the Policy item status to current, confirm `Policy.next_review_date` and `Policy.review_frequency` are set so the policy re-enters the cadence, and confirm the superseded version is archived.\n- Item relationship: confirm the Policy ↔ Control links stand.\n\n**Exit criteria**\nAccept the approved policy package, non-duplicated publication campaign and open conditions; retain the existing approval and archive the accepted handoff.\nFinal approval is recorded with approver, date, conditions, and follow-up ownership; the policy's governance status reflects the decision.\nThe Regulatory Compliance Attestation Cycle is linked and its owner has accepted the package; the handoff note records the passed artifacts and what not to repeat; the final package is archived and records are locked; linked records are updated; the next review is scheduled; and closure is communicated. This step is the workflow's single terminal sink.","label":"Handoff to related workflow"},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-policy-lifecycle-management"}