{"description":"Runs on the existing policy item. Canonical policy-change governance: scope and propose a controlled change, obtain policy-team approval, publish only the approved version, and close with a traceable document and communication record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.","edges":[{"id":"e-propose-approve","source":"propose","target":"approve"}],"isPublic":true,"itemTypeSlug":"policy","metadata":{"capabilities":["policy-change"],"controlVerbs":{"UC-GOV-14":"operates"},"controls":["UC-GOV-14"],"department":"compliance-legal","domains":["grc"],"kind":"policy-change","library":{"aliases":[{"source":"studio-seed","sourceTemplateId":"coworkcanvas:template:policy-change"}],"canonicalUrl":"https://workflow-library.com/all/?w=grc-policy-change","contentDigest":"sha256:4d0bf9ff2cf1ce535e30fcc8df2604156764659d95839402041eaabec9ee0917","prerequisites":{"anchorItemType":{"slug":"policy"},"evidenceDestinations":[{"description":"Restricted native step results, attached documents, durable item fields and native approvals.","id":"review-evidence"}],"handoffs":[{"direction":"output","name":"Reviewed register result and open actions","sourceTemplateId":"workflow-library:grc-policy-lifecycle-management"}],"roles":[{"contribution":"expertise","description":"Policy owner. Confirm the scope and propose the change.","id":"reviewer-1","nodeIds":["propose"]},{"contribution":"approval","description":"Policy governance approval authority. Approve policy change record.","id":"reviewer-2","nodeIds":["approve"]}],"status":"declared"},"provenance":[{"source":"brain/scripts/studio-seed","sourceTemplateId":"coworkcanvas:template:policy-change"}],"releaseId":"sha256:4d0bf9ff2cf1ce535e30fcc8df2604156764659d95839402041eaabec9ee0917","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-policy-change"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-policy-change","source":"coworkcanvas-gallery","standards":["iso-27001","nist-800-53","soc2"],"teams":["compliance-legal"]},"name":"Policy Change","nodes":[{"data":{"controls":[],"instructions":"**Objective**\nConfirm the scope and propose the change. The reviewer decides from the complete package described below.\n\n**Inputs**\n1. Use the current controlled document and Policy item, the triggering review, regulatory change, issue, incident or business change, the authoritative source for the driver, related policies, mapped requirements and controls, stakeholder input and document standards.\n\n**Procedure**\n1. Confirm the request is not a duplicate, define the problem and desired outcome, and identify affected obligations, processes, controls, systems, owners, audiences and any urgent interim instruction. Then draft a redline, explain each substantive change, distinguish consequential edits from cleanup, analyze downstream effects, and define implementation and communication needs.\n\n**Record in AssureSwarm**\n1. Record the change request reference, current version, scope summary, initiator, stakeholders, dependencies, urgency, duplicate search and interim measures; complete the preserved change-summary, driver, sections-affected and proposed-effective-date fields; attach the redline and impact analysis and link the triggering issue, requirement or annual review.\nRecord executor decisions and rationale in the markdown step result. Update Policy.next_review_date, version and effective_date only when the reviewed outcome calls for those fields. Use native approval records for sign-off.\n\nRecord `change_summary` (Proposed change) in Step.result markdown.\n\nRecord `driver` (Reason for the change; values: regulatory_change, audit_finding, incident_lesson, business_change, annual_review, other) in Step.result markdown.\n\nRecord `sections_affected` (Sections affected) in Step.result markdown.\n\nRecord `proposed_effective_date` (Proposed effective date) in Step.result markdown.\n\n**Exit criteria**\nPolicy owner provides expertise: The change boundary and governance route are clear, the exact proposal and rationale are understandable without oral context, affected records and audiences are listed, and the policy team can approve, reject or return the defined change.","kind":"task","label":"Confirm the scope and propose the change","requiredApprovals":1},"id":"propose"},{"data":{"controls":["UC-GOV-14"],"instructions":"**Objective**\nApprove policy change record. The reviewer decides from the complete package described below.\n\n**Inputs**\n1. Review intake, redline, preserved proposal fields, driver evidence, impacted policies and controls, stakeholder and legal input, proposed date, implementation plan, and current document standards.\n2. Use the approved redline and conditions, current controlled document, version convention, effective date, distribution list, training and procedure impacts, archive rules, and owner and approver metadata.\n3. Review intake, proposal and redline, policy-team decision, final comparison, published document, archive record, Policy item metadata, communication evidence, and open follow-up.\n\n**Procedure**\n1. Compare proposed language to authoritative obligations, challenge conflicts and vague responsibilities, verify affected controls and procedures, ensure the approver has authority, and record conditions or reasons for approval, rejection, or return.\n2. Compare the final document to the approved redline, prevent unapproved edits, update version and effective date, archive the superseded copy, refresh related procedures and links, and communicate to affected audiences.\n3. Verify the final version implements exactly the approved change and conditions, reconcile version and effective dates, confirm distribution evidence, and return the workflow if records conflict or work remains unassigned.\n\n**Record in AssureSwarm**\n1. Complete the preserved decision and comments fields, identify the exact redline reviewed, capture approver and date, list conditions, and link any additional evidence or required rework.\n2. Complete the preserved new-version, effective-date, and communicated fields; attach or link the published document, comparison proof, archive reference, distribution evidence, and implementation follow-up.\n3. Record the policy owner’s upstream review and the independent policy authority’s native approval, summary, date, published version reference, effective date, communication completion, linked records, and all remaining owners and due dates. Also record policy change closure summary.\nRecord executor decisions and rationale in the markdown step result. Update Policy.next_review_date, version and effective_date only when the reviewed outcome calls for those fields. Use native approval records for sign-off.\n\nRecord `decision` (Decision; values: approve, reject, return) in Step.result markdown.\n\nRecord `comments` (Policy team comments) in Step.result markdown.\n\nRecord `new_version` (New version) in Policy.fields.version.\n\nRecord `effective_date` (Effective date) in Policy.fields.effective_date.\n\nRecord `communicated` (Affected teams notified) in Step.result markdown.\n\n**Exit criteria**\nPolicy governance approval authority provides approval: The decision is supported and scoped to the submitted proposal, approval conditions are explicit, and publication cannot proceed on a rejected, returned, or subsequently changed draft. The published document matches approval, the superseded version is controlled, Policy metadata is current, communications are evidenced, and unresolved implementation tasks are assigned. The authorized reviewer accepts a traceable controlled-change record, metadata and document references agree, remaining actions are monitored, and closure does not imply certification or an audit conclusion.","kind":"task","label":"Approve policy change record","requiredApprovals":1},"id":"approve"}],"sourceTemplateId":"workflow-library:grc-policy-change"}