{"description":"Standing operator workflow for the security policy owner's annual (and change-triggered) review, redline, reapproval, and dissemination of the full security policy suite -- secure acquisition/development/configuration-management/maintenance, asset/media/physical protection, access/identity/personnel security, communications/cryptography, security awareness and cyber-hygiene, audit-logging/monitoring/system-integrity, contingency planning and disruption mitigation, and incident response. Anchor: each run is a workflow instance attached to the existing \"Security Policy Management\" Process item (process_type=security_process, process_owner=policy owner, frequency=annual) -- that instance IS the cycle record the tracked review items roll up to; the eight policy families are the existing Policy items the cycle enriches (never recreates). In scope: reviewing each Policy item against current risk and threat inputs, consolidating findings into one suite-level revision disposition, routing redlines to the right stakeholders, reapproving under accountable security leadership (writing Policy.approved_by / version / effective_date / next_review_date back onto each policy), and tracking dissemination and workforce acknowledgment as a single evidence set. Out of scope: authoring net-new policy domains and operating the technical controls the policies govern. The workflow has no upstream feeder workflow -- its inputs are the policy register (the eight Policy items), the prior-cycle workflow instance and its exported operating record, and the annual review calendar carried on Policy.next_review_date -- and no named downstream workflow; open corrective actions (Issue items) carry forward as explicit inputs to the next cycle. The eight domain reviews run in parallel and converge on a single revision-disposition decision.","edges":[{"id":"e-determine-revision-disposition-draft-and-route-policy-revisions","label":"Revise","source":"determine-revision-disposition","target":"draft-and-route-policy-revisions","whenValue":"revise_and_reapprove"},{"id":"e-determine-revision-disposition-obtain-formal-reapproval","label":"Reaffirm","source":"determine-revision-disposition","target":"obtain-formal-reapproval","whenValue":"reaffirm_no_changes"},{"id":"e-draft-and-route-policy-revisions-obtain-formal-reapproval","source":"draft-and-route-policy-revisions","target":"obtain-formal-reapproval"},{"id":"e-obtain-formal-reapproval-assess-suite-compliance-outcome","source":"obtain-formal-reapproval","target":"assess-suite-compliance-outcome"},{"id":"e-assess-suite-compliance-outcome-close-and-archive","label":"Current","source":"assess-suite-compliance-outcome","target":"close-and-archive","whenValue":"fully_current"},{"id":"e-assess-suite-compliance-outcome-log-exceptions-and-corrective-actions","label":"Gaps","source":"assess-suite-compliance-outcome","target":"log-exceptions-and-corrective-actions","whenValue":"gaps_identified"},{"id":"e-log-exceptions-and-corrective-actions-close-and-archive","source":"log-exceptions-and-corrective-actions","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-29","UC-GOV-30","UC-GOV-31","UC-GOV-32","UC-GOV-33","UC-GOV-34","UC-GOV-35","UC-GOV-36"],"department":"it","domains":["controls"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=controls-security-policy-suite-review-protection-domains","contentDigest":"sha256:035bb7044a1c5349f8206936ed2e8f6fedb3a7c54c1dafc75a1679e666df9f4c","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:035bb7044a1c5349f8206936ed2e8f6fedb3a7c54c1dafc75a1679e666df9f4c","schemaVersion":1,"sourceTemplateId":"workflow-library:controls-security-policy-suite-review-protection-domains"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"controls-security-policy-suite-review-protection-domains","source":"coworkcanvas-gallery","standards":["nist-800-53","nis2","nydfs-500","soc2"],"teams":["it","compliance-legal"]},"name":"Security Policy Suite Review","nodes":[{"data":{"decisionField":"revision_disposition","description":"Review all eight policy domains against live practice, risk and threat evidence and decide suite-wide reaffirmation or revision.","formData":{"fields":[{"key":"revision_disposition","label":"Revision Disposition","options":[{"label":"Reaffirm, no changes","value":"reaffirm_no_changes"},{"label":"Revise and reapprove","value":"revise_and_reapprove"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Review all eight policy domains against live practice, risk and threat evidence and decide suite-wide reaffirmation or revision.\n\n**Inputs**\n- The four existing Policy items for this domain -- secure system/services acquisition (SA-1), application development, configuration management (CM-1), and system maintenance (MA-1); each carries policy_owner, framework (nist-800-53, nis2, nydfs-500, soc2), domains (secure_configuration_change_management, secure_development_sdlc), version and next_review_date. Their published text lives in the external policy portal and is pulled in as a step upload.\n- The referenced secure-development standards, baseline-configuration requirements, and externally-developed-application evaluation criteria (no native type -- current versions uploaded at this step as PBC/external evidence).\n- The prior-cycle findings memos for these four policies (documents on the prior workflow instance) plus any open carryover Issue items; the trigger for this cycle (routine annual cadence or a significant-change event such as a new sourcing model or development platform), recorded on the instance at kickoff.\n- This is a parallel entry checkpoint: it depends only on the workflow's existing Policy items and prior-cycle instance, not on any other review node's output.\n- The three existing Policy items for this domain -- asset management, media protection (MP-1), and physical/environmental protection (PE-1); each carries policy_owner, framework, domains (asset_management_inventory, physical_environmental_security) and next_review_date. Published text pulled from the external policy portal as a step upload.\n- A point-in-time extract of the live asset inventory (external asset-inventory system) and the media-sanitization procedure the policies reference (no native type -- uploaded at this step as PBC/external evidence).\n- The data-retention and secure-disposal standard for nonpublic information (NYDFS 500.13); the prior-cycle findings memos and any open carryover Issue items.\n- The three existing Policy items for this domain -- logical access control (AC-1), identification and authentication (IA-1), and personnel/human-resources security (PS-1); each carries policy_owner, framework, domains (access_control_identity, human_resources_personnel_security) and next_review_date. Published text pulled from the external policy portal as a step upload.\n- The credential-management standard and the screening, transfer, and termination procedures the policies invoke (no native type -- uploaded at this step as PBC/external evidence).\n- Recent process changes (new offboarding tooling, new contractor categories); the prior-cycle findings memos and any open carryover Issue items.\n- The two existing Policy items for this domain -- system and communications protection (SC-1) and cryptography; each carries policy_owner, framework, domains (cryptography_key_management, network_communications_security) and next_review_date. Published text pulled from the external policy portal as a step upload.\n- The approved cryptographic-standards list and the remote and privileged-access authentication configuration the policies reference (no native type -- uploaded at this step as PBC/external evidence).\n- Threat inputs on deprecating algorithms and newly enabled access paths; the prior-cycle findings memo and any open carryover Issue items.\n- The existing awareness/training/cyber-hygiene Policy item (policy_owner, framework, domains=awareness_training, next_review_date). Published text pulled from the external policy portal as a step upload.\n- A completion extract from the training-completion tracking system (external LMS), current personnel roster changes, and the incident and threat inputs for this cycle (uploaded at this step as PBC/external evidence).\n- The prior-cycle findings memo and any open carryover Issue items.\n- This is a parallel entry checkpoint: it depends only on the workflow's existing Policy item and prior-cycle instance, not on any other review node's output.\n- The two existing Policy items -- audit-logging and accountability (AU-1) and system and information integrity (SI-1); each carries policy_owner, framework, domains (logging_monitoring_detection) and next_review_date. Published text pulled from the external policy portal as a step upload.\n- The continuous monitoring strategy document and a recent monitoring metric-trend extract (uploaded at this step as PBC/external evidence).\n- The existing contingency planning Policy item and its procedures (CP-1) (policy_owner, framework, domains=business_continuity_disaster_recovery, next_review_date). Published text pulled from the external policy portal as a step upload.\n- The business-disruption Risk items (category=business_continuity / cyber_security, taxonomies incl. operational_resilience, domains incl. business_continuity_disaster_recovery -- including risks to critical infrastructure and essential services), the existing mitigation portfolio, and current insurance and risk-transfer instruments.\n- This is a parallel entry checkpoint: it depends only on the workflow's existing Policy item, Risk items, and prior-cycle instance, not on any other review node's output.\n- Current published text of the incident response policy and procedures (IR-1) from the policy register.\n- The org chart for named roles and authorities; post-incident review records and exercise after-action reports since the last cycle.\n- The prior-cycle review record and any carryover items.\n- This is a parallel entry checkpoint: it depends only on the workflow's initial inputs, not on any other review node's output.\n\n**Procedure**\n_This checkpoint absorbs “Review acquisition, development & maintenance policies”, “Review asset, media & physical protection policies”, “Review access, identity & personnel security policies”, “Review communications & cryptography policies”, “Review awareness and cyber-hygiene policy”, “Review logging, monitoring & integrity policy”, “Review contingency planning & disruption mitigation”, “Review incident response policy & procedures”. The agent runs the preparation, evidence assembly and record updates below; the named owners retain the substantive decisions and approvals stated in the procedure._\n1. Review acquisition, development & maintenance policies: Produce a findings memo per policy that confirms whether the secure system/services-acquisition, in-house application-development, configuration-management, and system-maintenance policies still match current practice, tooling, and standards, and that states a redline direction (no change / targeted edit / substantial rewrite) for each.\n2. Pull the current published text of the acquisition, development, configuration-management, and maintenance policies together with the secure-development standards and baseline-configuration requirements they reference.\n3. Compare each policy against its control mapping — SA-1 system and services acquisition, CM-1 configuration management, MA-1 system maintenance, NYDFS 500.8 application security, and NIS2 Art.21(e) security in acquisition, development, and maintenance — and flag any clause that no longer matches actual practice, tooling, or the evaluation criteria used for externally developed applications.\n4. Identify gaps: missing secure-development standards, outdated baseline-configuration requirements, development platforms in use but unreferenced, or acquisition evaluation criteria that have not kept pace with current sourcing.\n5. For each of the four policies decide a redline direction — no change, targeted edit, or substantial rewrite — with the specific clause citations that drive it.\n6. Draft a findings memo per policy capturing the comparison, the gaps, and the recommended redline direction with its driving control reference.\n7. Review asset, media & physical protection policies: Produce a findings memo per policy confirming that the asset-management, media-protection, and physical/environmental-protection policies remain complete and correct against the live asset inventory and current retention and disposal rules, with a redline direction for each.\n8. Pull the current asset-management, media-protection, and physical/environmental-protection policies together with the live asset inventory and the media-sanitization procedure.\n9. Cross-check the policy's inventory-completeness requirement against actual asset-inventory coverage (MP-1, PE-1) and confirm the media handling, marking, storage, and sanitization procedures it references are still accurate.\n10. Verify the data-retention limits and secure-disposal provisions for nonpublic information no longer required for business or legal purposes, per NYDFS 500.13, are current and correctly cross-referenced.\n11. Flag any physical or environmental protection clause superseded by a facility, hosting, or vendor change since the last cycle.\n12. Draft a findings memo per policy with the comparison result and a recommended redline direction (no change / targeted edit / substantial rewrite) and its driving control reference.\n13. Review access, identity & personnel security policies: Produce a findings memo per policy confirming that the logical access-control, identification-and-authentication, and personnel (human resources) security policies still match current practice for need-to-know, least privilege, credential management, and the personnel security lifecycle, with a redline direction for each.\n14. Pull the current access-control, identification-and-authentication, and personnel-security policies together with the credential-management standard and the screening, transfer, and termination procedures they invoke.\n15. Check that need-to-know and least-privilege authorization language and credential and authenticator management requirements (AC-1, IA-1) still match current practice.\n16. Confirm personnel screening, transfer, and termination requirements (PS-1) reflect the current process and that workforce-communication requirements (NIS2 Art.21(i) human resources security) are met.\n17. Identify any recent process change — new offboarding tooling, new contractor or third-party-access categories — left undocumented in the policy text.\n18. Draft a findings memo per policy with the comparison result, a recommended redline direction, and its driving control reference.\n19. Review communications & cryptography policies: Produce a findings memo confirming that the system-and-communications-protection and cryptography policies keep required encryption, secured channels, and multi-factor authentication expectations aligned with current threats, deployed controls, and cryptographic standards, with a redline direction.\n20. Pull the current communications-protection and cryptography policies together with the approved cryptographic-standards list and the remote and privileged-access authentication configuration.\n21. Check the required-encryption and secured-communication-channel provisions (SC-1) and the multi-factor and strong-authentication expectations for remote and privileged access (NIS2 Art.21(h) cryptography and encryption, Art.21(j) authentication and communications security) against currently deployed controls.\n22. Flag any cryptographic standard nearing deprecation, any newly enabled remote-access path not yet covered, or any privileged-access route missing an MFA requirement in the policy text.\n23. Draft a findings memo with the comparison result, a recommended redline direction (no change / targeted edit / substantial rewrite), and its driving control reference.\n24. Review awareness and cyber-hygiene policy: Operate UC-GOV-32: produce a redlined security awareness, training, and cyber-hygiene policy whose required content, audiences, frequency, and completion tracking stay current with personnel and threat changes, plus a tracked review item.\n25. Query the current policy text, the training-completion tracking system, personnel roster changes, and the incident and threat inputs for the cycle.\n26. Identify gaps: content that no longer reflects current threats or required behaviors, audiences that have grown or changed, delivery frequency that no longer matches risk, or completion tracking that misses populations.\n27. Draft the redlined policy update specifying required content, target audiences, delivery frequency, and the completion-tracking mechanism.\n28. Create a tracked review item as an Issue (coach-item-create) and relate it to the awareness Policy item (coach-items-link) so the redline flows into the consolidated disposition.\n29. Review logging, monitoring & integrity policy: Operate UC-GOV-33: produce redlined audit-logging/accountability and system-integrity policies plus an updated organization-wide continuous monitoring strategy whose metrics and assessment frequencies stay fit for purpose, with a tracked review item.\n30. Query the current logging/accountability policy, the system-integrity policy, the continuous monitoring strategy document, and recent monitoring metric trends.\n31. Evaluate whether the defined metrics, monitoring frequency, and assessment frequency still match current risk exposure and whether monitoring results are demonstrably feeding risk decisions.\n32. Draft the redlined policies and monitoring strategy update, including any revised metrics or frequencies.\n33. Create a tracked review item as an Issue (coach-item-create) and relate it to the AU-1/SI-1 Policy items (coach-items-link).\n34. Review contingency planning & disruption mitigation: Operate UC-GOV-34: produce a redlined contingency planning policy plus a refreshed business-disruption risk analysis and a mitigation portfolio (including insurance and other risk transfer) kept proportionate to identified risk, with a tracked review item.\n35. Query the contingency planning Policy item, the business-disruption Risk items, the existing mitigation portfolio, and current insurance and risk-transfer instruments.\n36. Identify new or changed disruption risks since the last cycle and any resulting gap between risk exposure and the mitigation portfolio's coverage.\n37. Draft the redlined contingency planning policy and the updated mitigation portfolio recommendation, testing each recommended instrument for proportionality to the risk it covers.\n38. Create a tracked review item (coach-item-create) and link it to the workflow's cycle record (coach-items-link).\n39. Review incident response policy & procedures: Operate UC-GOV-35: produce a redlined incident response policy and supporting procedures whose incident criteria, roles, authorities, and detection, reporting, handling, escalation, and post-incident review requirements stay current, incorporating lessons from any incidents or exercises since the last cycle, with a tracked review item.\n40. Query the current incident response policy and procedures, the org chart for named roles and authorities, and the post-incident review records and exercise after-action reports since the last cycle.\n41. Identify changes needed to the incident criteria, roles and authorities, reporting and escalation paths, and post-incident review requirements based on lessons learned.\n42. Draft the redlined incident response policy and procedures, wiring in any regulatory reporting timelines that apply (NIS2 Art.21(b) incident handling).\n43. Create a tracked review item (coach-item-create) and link it to the workflow's cycle record (coach-items-link).\n44. Determine revision disposition: Consolidate the eight domain findings memos into one suite-level revision matrix and resolve, owned by the security policy owner, whether the cycle proceeds as a straight reaffirmation or must draft and route formal revisions.\n\n**Decision criteria**\n- Choose **reaffirm_no_changes** when every one of the eight domain findings memos confirms its policy is current as published — no memo carries a targeted-edit or substantial-rewrite recommendation, and no open carryover item forces a change. The suite skips drafting and goes straight to reapproval.\n- Choose **revise_and_reapprove** when one or more policies carry a targeted-edit or substantial-rewrite recommendation, or a significant-change trigger (new regulatory driver, control failure, incident finding, new technology) mandates a policy change. The suite routes through drafting before reapproval.\n- Before deciding, scan open workflows (coach-workflow-scan) to confirm no other in-flight change already has a revision to this suite in progress, avoiding duplicate drafting.\n\n**Record in AssureSwarm**\n- Step documents: attach the four findings memos (DOCX/PDF), one per policy, to this step (coach-document-upload).\n- Query the four Policy items via coach-query-data -- their framework and domains carry the control mapping (SA-1, CM-1, MA-1, NYDFS 500.8, NIS2 Art.21(e)). This review node reads the policies and produces memos; it creates no Issue item (the consolidated disposition is decided downstream).\n- Step documents: attach the three findings memos to this step (coach-document-upload), each with its inventory-coverage and retention/disposal cross-check.\n- Query the three Policy items and the uploaded inventory extract via coach-query-data (Policy.framework/domains carry the MP-1, PE-1, NYDFS 500.13 mapping). This node produces memos and creates no Issue item.\n- Step documents: attach the three findings memos to this step (coach-document-upload).\n- Query the three Policy items via coach-query-data (Policy.framework/domains carry the AC-1, IA-1, PS-1 and NIS2 Art.21(i) mapping). This node produces memos and creates no Issue item.\n- Step document: attach the findings memo to this step (coach-document-upload).\n- Query the two Policy items and the uploaded standards list and authentication configuration via coach-query-data (Policy.framework/domains carry the SC-1 and NIS2 Art.21(h)/(j) mapping). This node produces the memo and creates no Issue item.\n- Item create + relate: create the tracked review item as an Issue (coach-item-create: issue_type=observation, source=compliance_review, identified_date=review date, description=redline direction and gap summary) and relate it to the awareness Policy item (coach-items-link); the workflow instance on the Process anchor is the cycle record it rolls up to.\n- Step documents: attach the redlined policy and the gap analysis to this step (coach-document-upload); base them on data retrieved via coach-query-data.\n- Item create + relate: create the tracked review item as an Issue (coach-item-create: issue_type=observation, source=compliance_review, identified_date=review date) and relate it to the logging/integrity Policy items (coach-items-link); the workflow instance is the cycle record.\n- Step documents: attach the redlined policies, the monitoring strategy update, and the metric-trend evidence to this step (coach-document-upload); base them on data retrieved via coach-query-data.\n- Create the tracked review item (coach-item-create) and link it to the cycle record (coach-items-link).\n- Attach the redlined policy, the refreshed risk analysis, and the mitigation portfolio to this step (coach-document-upload); base them on data retrieved via coach-query-data.\n- Attach the redlined policy, the procedures, and the supporting lessons-learned summary to this step (coach-document-upload); base them on data retrieved via coach-query-data.\n- Submit the `revision_disposition` SELECT on this step's form (reaffirm_no_changes or revise_and_reapprove).\n- Record the decision rationale and evidence references (the consolidated revision matrix and the driving control references) in the step result, and name the decision owner in the step's approver record.\n- Attach the consolidated revision matrix built from the eight memos (coach-query-data to consolidate, coach-document-upload to attach).\n\n**Exit criteria**\n- A findings memo exists for each of the four policies, each stating a redline direction backed by clause-level citations; the policy owner has confirmed the memos reflect current secure-development, configuration-management, and maintenance practice.\n- A findings memo exists for each policy stating a redline direction; the policy owner has confirmed inventory completeness, media-sanitization accuracy, and retention/disposal correctness.\n- A findings memo exists for each policy stating a redline direction; the policy owner has confirmed the access, identity, and personnel-security text matches current practice and that workforce-communication requirements are met.\n- A findings memo exists stating a redline direction; the policy owner has confirmed encryption, channel-security, and MFA provisions are current against deployed controls and evolving cryptographic standards.\n- A redlined policy and gap analysis are attached and a tracked review item is linked; the policy owner has confirmed content, audience coverage, frequency, and completion-tracking mechanism are complete and reflect current threats.\n- Redlined policies, a monitoring strategy update, and metric-trend evidence are attached and a tracked review item is linked; the policy owner has confirmed the logging, accountability, and integrity policies are current and that the monitoring strategy's metrics and frequencies genuinely inform risk decisions.\n- A redlined policy, refreshed risk analysis, and mitigation portfolio are attached and a tracked review item is linked; the policy owner has confirmed the disruption risk analysis is current and that the mitigation portfolio, including insurance and risk transfer, is proportionate to that risk.\n- A redlined policy, procedures, and lessons-learned summary are attached and a tracked review item is linked; the policy owner has confirmed incident criteria, roles and authorities, escalation paths, and post-incident review requirements are current and reflect recent lessons learned.\n- The routing selector is submitted and the step result contains a rationale and named owner; the chosen branch's edge is active and the unused branch is prunable.","kind":"decision","label":"Determine revision disposition","performedBy":{"primitives":["coach-query-data","coach-document-upload","coach-item-create","coach-items-link","coach-workflow-scan"]}},"id":"determine-revision-disposition"},{"data":{"description":"Agent drafts redlines for every flagged policy and routes them to the right stakeholders; human confirms redlines are complete and feedback is resolved","instructions":"**Objective** — Produce complete, version-controlled redlines for every policy flagged for revision and route each to the correct stakeholder group, resolving their feedback before the suite moves to formal reapproval.\n\n**Inputs**\n- The suite-level revision matrix and the eight domain findings memos from the revision-disposition decision (this step runs only on the revise_and_reapprove branch).\n- The currently published text of each flagged policy, for a version-controlled diff.\n- The stakeholder map: legal/compliance, IT operations, HR, security engineering.\n\n**Procedure**\n1. Draft redlined text for each flagged policy with the specific clause-level changes identified in the domain review, keeping a version-controlled diff against the currently published text.\n2. Create a revision item per policy (coach-item-create) capturing the redline summary, the driving control reference, and the target reapproval date, and link it to the source findings memo (coach-items-link).\n3. Route each redline to its relevant stakeholder group for substantive comments through the existing document review channel: legal/compliance for regulatory language, IT operations for configuration-management and maintenance clauses, HR for personnel-security clauses, and security engineering for cryptography and access clauses — recording requested changes and any required native sign-off.\n4. Incorporate stakeholder feedback into each redline, or explicitly decline it with a recorded reason, and compile the routed redlines and feedback into one package.\n\n**Record in AssureSwarm**\n- Create a revision item per policy and link it to its findings memo (coach-item-create, coach-items-link).\n- Route each redline through the existing document review channel and retain stakeholder comments and native sign-off.\n- Attach the routed redlines and consolidated stakeholder feedback (coach-document-upload).\n\n**Exit criteria** — Every flagged policy has a complete redline routed to the correct stakeholder group; all stakeholder feedback is incorporated or explicitly declined with reason; the policy owner has confirmed the package is ready for reapproval.","label":"Draft and route policy revisions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-form-create","coach-document-upload"]}},"id":"draft-and-route-policy-revisions"},{"data":{"description":"Agent assembles the full approval package for all eight policy families and routes it for signature; human accountable security leadership signs the reapproval on this step form before dissemination","instructions":"**Objective** — Secure formal, dated, named reapproval of the full security policy suite — whether reaffirmed unchanged or revised — under accountable security leadership before dissemination.\n\n**Inputs**\n- On the reaffirm branch: the eight confirmed-current policies and the reaffirmation statement from the revision-disposition decision.\n- On the revise branch: the routed redlines and resolved stakeholder feedback from the draft-and-route step.\n- The full control-reference mapping and the version history for each policy.\n\n**Procedure**\n1. Assemble the final approval package for all eight policy families: the published or redlined text, the consolidated revision matrix or reaffirmation statement, the full control-reference mapping (SA-1, CM-1, MA-1, MP-1, PE-1, AC-1, IA-1, PS-1, SC-1, AU-1, SI-1, CP-1, IR-1, NYDFS 500.8, NYDFS 500.13, SOC 2 CC9.1, NIS2 Art.21(b)/(c)/(e)/(g)/(h)/(i)/(j)), and the version history.\n2. Route the approval package to accountable security leadership — the CISO or delegate — for native approval, retaining the named approver and role, scope, conditions and approval date in the approval record and signed package. A subset approval names each withheld family and its reason; those families do not proceed to dissemination this cycle.\n3. Record each captured approval as an item (coach-item-create) and link it to its policy and the source revision or reaffirmation record (coach-items-link).\n4. On reapproval, write the captured decision back onto each of the eight Policy items (coach-item-update): set Policy.approved_by to the named approver, Policy.version to the reapproved version, Policy.effective_date to the approval date, and Policy.next_review_date to the next annual cadence — so the v3 Policy-lifecycle record on each policy reflects this cycle's reapproval, not the prior one.\n5. Attach the signed approval package (coach-document-upload).\n\n**Record in AssureSwarm**\n- The native approval and signed package capture the accountable security-leadership signatory, role, scope (all families or a named withheld subset), conditions and date. No approval questionnaire is required.\n- Record and link each approval (coach-item-create, coach-items-link).\n- Write Policy.approved_by, Policy.version, Policy.effective_date, and Policy.next_review_date back onto each of the eight Policy items on reapproval (coach-item-update).\n- Attach the signed approval package (coach-document-upload).\n\n**Exit criteria** — The native approval is recorded; every one of the eight policy families carries a dated, named signature from accountable security leadership or is explicitly recorded as withheld with a reason; the signed package is attached.\n\n\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the eight policy families, control-reference mapping, and version history into one signature-ready approval package.","label":"Obtain formal reapproval","performedBy":{"primitives":["coach-form-create","coach-item-create","coach-items-link","coach-item-update","coach-document-upload","coach-render-package"]}},"id":"obtain-formal-reapproval"},{"data":{"decisionField":"compliance_outcome","description":"Agent publishes the reapproved policy suite, runs the workforce acknowledgment campaign, and computes reapproval, mapping, and acknowledgment metrics on a dashboard; human classifies the cycle as fully current or gaps identified","formData":{"fields":[{"key":"compliance_outcome","label":"Compliance Outcome","options":[{"label":"Fully current and acknowledged","value":"fully_current"},{"label":"Gaps identified","value":"gaps_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Publish the reapproved policy suite to every affected workforce segment, track acknowledgment to completion, and then judge — owned by the security policy owner — whether the completed cycle leaves the protection-domain policy suite fully current and acknowledged, or carries gaps that need tracked follow-up.\n\n**Inputs**\n- The signed approval package for all eight policy families from the reapproval step.\n- The workforce-segment mapping per policy (all personnel, privileged users, developers, contractors, physical-facility staff).\n- The prior published version, for supersession and version history.\n- The full control-reference mapping (NIST 800-53, NYDFS 500, NIS2 Art.21) and the acknowledgment-completion threshold defined for the cycle.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from the former \"Disseminate and track acknowledgment\" step, which carried no separate human touch-point); the human moment is the outcome call in item 7._\n1. Publish the approved policy text to the policy portal/repository (coach-document-upload), superseding the prior version and preserving the version history.\n2. Identify every workforce segment subject to each policy (coach-query-data) — all personnel, privileged users, developers, contractors, physical-facility staff — and draft the dissemination communication summarizing what changed and why.\n3. Use the existing policy-portal acknowledgment campaign, assigning the required acknowledgment to every affected individual, and track completion (coach-workflow-scan).\n4. Compile the dissemination log and acknowledgment-completion report; confirm the published suite supersedes the prior version and that an acknowledgment is assigned to every affected individual.\n5. Compute the cycle metrics (coach-query-data): reapproval signatures captured per policy family, acknowledgment-completion rate against threshold, policies still pending stakeholder sign-off, and control references left unmapped after revision.\n6. Build the compliance-outcome dashboard (coach-dashboard-create) showing each metric against its threshold and the trend against prior cycles, and attach the outcome summary.\n7. The security policy owner reviews dissemination reach, the acknowledgment-completion rate, and the dashboard, and submits the outcome against the criteria below — the call rests on the computed metrics, not on impression.\n\n**Decision criteria**\n- Choose **fully_current** when all eight policy families carry a dated reapproval signature, the acknowledgment-completion rate meets or exceeds the defined threshold, no policy is still pending stakeholder sign-off, and no control reference (NIST 800-53, NYDFS 500, NIS2 Art.21) is left unmapped after revision. The cycle drains straight to close.\n- Choose **gaps_identified** when any signature is missing, acknowledgment completion is below threshold, a policy is still pending sign-off, or a control reference is unmapped. Each shortfall must become a tracked corrective action before close.\n\n**Record in AssureSwarm**\n- Submit the `compliance_outcome` SELECT (fully_current or gaps_identified). Record rationale and evidence references in the step result and the decision owner in the step's approver record.\n- Publish the approved policy text and attach the dissemination log, the acknowledgment-completion report, and the outcome summary (coach-document-upload).\n- Segment the workforce and compute the metrics via coach-query-data; launch and track the existing policy-portal acknowledgment campaign (coach-workflow-scan); build the compliance-outcome dashboard (coach-dashboard-create).\n\n**Exit criteria** — The approved suite is published and supersedes the prior version; an acknowledgment is assigned to every affected individual and completion is measured; the `compliance_outcome` routing selector is submitted and the step result contains a rationale and named owner; the chosen branch's edge is active and the unused branch is prunable.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` issues the dissemination communication and the required acknowledgment assignments to each mapped workforce segment.","kind":"decision","label":"Assess suite compliance outcome","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload","coach-form-create","coach-workflow-scan","coach-notify"]}},"id":"assess-suite-compliance-outcome"},{"data":{"description":"Agent converts each identified shortfall into an owned corrective action; human confirms every gap is owned, dated, and escalated where required","instructions":"**Objective** — Convert every shortfall identified at the outcome review into an owned, tracked corrective action so no gap in the protection-domain policy suite goes unaddressed (this step runs only on the gaps_identified branch).\n\n**Inputs**\n- The outcome summary and compliance-outcome dashboard from the outcome decision, listing each shortfall (missing signature, low acknowledgment completion, unmapped control reference, stalled stakeholder review).\n- The owning policy or metric behind each shortfall; escalation routes to accountable security leadership.\n\n**Procedure**\n1. Parse the outcome summary to list each shortfall with its root cause: missing signature, low acknowledgment completion, unmapped control reference, or stalled stakeholder review.\n2. Create a corrective-action item for each shortfall (coach-item-create) capturing root cause, owner, due date, and interim mitigation, and link it to the driving policy or metric (coach-items-link).\n3. Escalate any shortfall tied to a regulatory control reference (NYDFS 500, NIS2 Art.21) directly to accountable security leadership, and raise a capability-level item for any systemic gap such as a chronically low-acknowledgment workforce segment.\n4. Compile the corrective-action register.\n\n**Record in AssureSwarm**\n- Create and link a corrective-action item per shortfall (coach-item-create, coach-items-link).\n- Attach the corrective-action register (coach-document-upload).\n\n**Exit criteria** — Every shortfall has a named owner and due date; regulatory-linked gaps are escalated; the policy owner has confirmed nothing is left untracked before closure.","label":"Log exceptions and corrective actions","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"log-exceptions-and-corrective-actions"},{"data":{"description":"Automatically archive the authorized cycle record and carry open actions into the next cycle.","instructions":"**Objective** — Automatically preserve the authorized cycle record and its carry-forward actions after the preceding decision.\n\n**Inputs**\n- The full operating record: findings memos, revision matrix, approval package, dissemination log, acknowledgment report, and any corrective-action register.\n- The per-policy next annual review dates and any deferred stakeholder feedback.\n- This is the single sink: both the fully_current path and the corrective-action path drain here.\n\n**Procedure**\n1. Export the full operating record (coach-workflow-export) and archive it in the designated evidence repository under retention controls.\n2. Create carry-forward items (coach-item-create) for open corrective actions, the next annual review date per policy, and any deferred stakeholder feedback, and link them to their source (coach-items-link) so they arrive as explicit inputs to the next cycle.\n3. Update the control execution log for UC-GOV-29 through UC-GOV-36 with the cycle result and key metrics, and confirm the next cadence review or change trigger is scheduled.\n4. Attach the closure record (coach-document-upload).\n\n**Record in AssureSwarm**\n- Export and archive the operating record (coach-workflow-export).\n- Create and link carry-forward items (coach-item-create, coach-items-link).\n- Attach the closure record (coach-document-upload).\n\n**Exit criteria** — The archived record is immutable and retrievable; the next review is scheduled; nothing remains open without a tracked owner; the authorized cycle record is complete.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-item-create","coach-items-link","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:controls-security-policy-suite-review-protection-domains"}