{"description":"Strategic Context & Objectives Alignment Cycle as a decision-aware workflow. Anchor: this recurring governance cycle runs on and enriches the existing \"Strategic Planning & Objectives Alignment\" Process item (process_type business_process, annual frequency) that represents the strategy-refresh process itself; where no such convention item is seeded it runs standalone with every output attached to the workflow instance. No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger, run annually or on an event-driven change such as an acquisition, a new market or regulation, a material risk-profile shift, or a significant incident; its only prior-cycle input is this workflow's own previous run, archived at close-and-archive. It refreshes the mission statement and stakeholder register, builds a bidirectional objectives-and-dependency map, communicates that context to risk-scoping owners, realigns and cascades strategy into a published and monitored roadmap, and closes by documenting mission-essential business processes as Process items with their information-protection needs as the approved basis for risk-assessment scoping. Named deliverables: the refreshed mission statement (DOCX) and stakeholder register (XLSX), the objectives-and-dependency map, the published context package and change summary, the strategy realign-or-reaffirm decision, the realigned enterprise and technology strategy (realign branch), the cascaded objectives and published roadmap, the mission-essential Process definitions, and the archived cycle record. In scope: the mission and stakeholder context refresh, strategy realignment and objective cascade, and the mission-essential process and risk-scoping definitions. Out of scope: executing the risk assessment itself. Downstream handoff: the exported cycle record and the approved mission-essential Process items are the scoping basis consumed by the Enterprise risk-assessment cycle.","edges":[{"id":"e-map-critical-objectives-and-dependencies-communicate-context-to-risk-scoping-owners","source":"map-critical-objectives-and-dependencies","target":"communicate-context-to-risk-scoping-owners"},{"id":"e-map-critical-objectives-and-dependencies-evaluate-strategy-alignment","source":"map-critical-objectives-and-dependencies","target":"evaluate-strategy-alignment"},{"id":"e-evaluate-strategy-alignment-realign-enterprise-technology-strategy","label":"Realign strategy","source":"evaluate-strategy-alignment","target":"realign-enterprise-technology-strategy","whenValue":"realign"},{"id":"e-evaluate-strategy-alignment-cascade-objectives-and-publish-roadmap","label":"Reaffirm strategy","source":"evaluate-strategy-alignment","target":"cascade-objectives-and-publish-roadmap","whenValue":"reaffirm"},{"id":"e-realign-enterprise-technology-strategy-cascade-objectives-and-publish-roadmap","source":"realign-enterprise-technology-strategy","target":"cascade-objectives-and-publish-roadmap"},{"id":"e-cascade-objectives-and-publish-roadmap-monitor-roadmap-execution","source":"cascade-objectives-and-publish-roadmap","target":"monitor-roadmap-execution"},{"id":"e-cascade-objectives-and-publish-roadmap-approve-risk-scoping-basis","source":"cascade-objectives-and-publish-roadmap","target":"approve-risk-scoping-basis"},{"id":"e-approve-risk-scoping-basis-close-and-archive","label":"Approved","source":"approve-risk-scoping-basis","target":"close-and-archive","whenValue":"approved"},{"id":"e-approve-risk-scoping-basis-resolve-risk-scoping-gaps","label":"Revise","source":"approve-risk-scoping-basis","target":"resolve-risk-scoping-gaps","whenValue":"revise"},{"id":"e-resolve-risk-scoping-gaps-close-and-archive","source":"resolve-risk-scoping-gaps","target":"close-and-archive"},{"id":"e-monitor-roadmap-execution-close-and-archive","source":"monitor-roadmap-execution","target":"close-and-archive"},{"id":"e-communicate-context-to-risk-scoping-owners-close-and-archive","source":"communicate-context-to-risk-scoping-owners","target":"close-and-archive"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-02","UC-GOV-12","UC-RISK-04"],"department":"executive","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-strategic-context-objectives-alignment-cycle","contentDigest":"sha256:ef223302fc7834d5c7acb69246e0932c83b66fb891910b7b9da62b7615e9ec4f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:ef223302fc7834d5c7acb69246e0932c83b66fb891910b7b9da62b7615e9ec4f","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-strategic-context-objectives-alignment-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"grc-strategic-context-objectives-alignment-cycle","source":"coworkcanvas-gallery","standards":["nist-csf-2","coso-erm","cobit-2019","nist-800-53"],"teams":["executive","risk-management"]},"name":"Strategic Context & Objectives Alignment Cycle","nodes":[{"data":{"description":"Agent refreshes the mission statement and stakeholder register with needs and expectations and maps the critical objectives, capabilities, and services stakeholders depend on alongside the outcomes and services the organization depends on; human Chief Strategy Officer and CRO validate that the stakeholder inventory is complete and no critical dependency is missing.","instructions":"**Objective** — Refresh the mission statement and stakeholder register and build from them a navigable, bidirectional dependency map — the critical objectives, capabilities, and services stakeholders depend on the organization to deliver, and the outcomes, capabilities, and services the organization itself depends on from others — so the Chief Strategy Officer and CRO can validate in one pass that no material stakeholder, need, or critical dependency is missing.\n\n**Inputs**\n- Prior mission statement, stakeholder register, and any prior needs/expectations documentation (governance context items) — or an explicit note that no prior cycle exists.\n- The trigger context: the scheduled annual strategy refresh, or a specific event-driven change (acquisition, new market or regulation, material risk-profile shift, significant incident). Record the trigger date and source.\n- External signals: customer and regulatory feedback, contractual commitments, market and regulatory scans since the last cycle — uploaded as PBC/external evidence to this step; they live outside AssureSwarm.\n- The four governing standards for this cycle — NIST CSF 2.0, COSO ERM, COBIT 2019, and NIST 800-53 — carried in AssureSwarm as `Control.framework` values on the control library (`nist-csf-2`, `coso-erm`, `cobit-2019`, `nist-800-53`); the framework texts themselves are external references.\n- The third-party / supplier register — `Vendor` items already in the catalog (`category`, `tier`, `data_classification`, `business_owner`, `risk_owner`) — plus cloud and infrastructure inventories and existing service catalogs, uploaded as PBC/external evidence to this step (there is no Asset item type for infrastructure).\n- No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger; the prior mission and register above are this cycle's own previous run, archived at close-and-archive.\n\n**Procedure**\n_Items 1–6 are agent-run (folded from the former \"Refresh mission and stakeholder context\" step); the human moment is the CSO/CRO validation at item 11._\n1. Log why the cycle is running now — scheduled annual refresh or the specific event — with its date and source, so the refresh is traceable in the governance register.\n2. Review the prior mission statement against the current business environment; draft a refreshed statement where the environment has materially changed, or explicitly confirm the existing statement still holds and note the basis.\n3. Compile the internal stakeholder inventory — business units, executive leadership, the board, employees — updating entries for reorganizations since the last cycle.\n4. Compile the external stakeholder inventory — customers, regulators, investors, key suppliers and partners — updating for market and relationship changes.\n5. For each stakeholder, draft or refresh documented needs and expectations, citing the evidence (prior interviews, feedback, contracts, scans) so each entry is defensible rather than asserted, and flag every stakeholder whose needs or expectations changed materially since the last cycle with a one-line note on what changed.\n6. For each stakeholder group in the register, identify the critical objectives, capabilities, and services the organization must deliver to meet their documented needs; link each to that stakeholder group.\n7. In the opposite direction, identify the outcomes, capabilities, and services the organization depends on from others — key suppliers, third-party and cloud providers, partners, infrastructure — so both directions of dependency are captured.\n8. Link each objective and dependency to the specific stakeholder, capability, or service it connects to, producing a navigable graph rather than a flat list.\n9. Identify single points of failure and dependencies with no documented owner; flag each with the risk it poses.\n10. Reconcile the two directions to ensure nothing the organization owes stakeholders and nothing critical it relies on is omitted.\n11. Walk the refreshed mission, the register, and both directions of the map with the Chief Strategy Officer and CRO, who confirm the stakeholder inventory is complete and accurate and that no critical dependency is missing.\n\n**Record in AssureSwarm**\n- **Step documents** — upload the refreshed mission statement (DOCX) and the stakeholder register (XLSX, one row per stakeholder with its documented needs, expectations, evidence citation, and changed-since-last-cycle flag) to this step (coach-document-upload). There is no Stakeholder item type in this schema, so the register document is the system of record for stakeholders and their needs and expectations — do not force-fit stakeholders into another type; flag the materially-changed stakeholders inside the register so the reviewer sees exactly what moved.\n- **Step document** — record the bidirectional objectives-and-dependency map as an XLSX / graph export on this step (coach-document-upload), with single points of failure and owner-less dependencies flagged inside it against the risk each poses. There is no Objective or Dependency item type in this schema, so the map document is the system of record.\n- **Item relationships** — where a dependency is an in-catalog entity, link the real items (coach-items-link): e.g. a mission-essential `Process` to the `Risk` it is exposed to, a `Process` to the `Control` that operates within it, or a `Process` to the `Vendor` it depends on.\n\n**Exit criteria** — Mission statement refreshed or explicitly reaffirmed; every material internal and external stakeholder group present in the register with documented needs, expectations, and an evidence citation, changed entries flagged; dependency map complete in both directions with every entry linked to what it serves or relies on and single points of failure flagged with owners identified; the Chief Strategy Officer has confirmed the register's completeness and accuracy and the CSO and CRO have validated that no critical dependency is missing.","label":"Map critical objectives and dependencies","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"map-critical-objectives-and-dependencies"},{"data":{"decisionField":"strategy_alignment_decision","description":"Agent evaluates the enterprise and technology strategy and alternative options against the refreshed mission and risk profile; human decides whether the strategy is realigned or reaffirmed.","formData":{"fields":[{"key":"strategy_alignment_decision","label":"Strategy alignment decision","options":[{"label":"Realign the strategy","value":"realign"},{"label":"Reaffirm current strategy","value":"reaffirm"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Decide whether the enterprise and technology strategy must be realigned to the refreshed mission and current risk profile, or can be reaffirmed as still sound. Owned by the Chief Strategy Officer.\n\n**Decision criteria**\nBefore routing, the agent prepares the evidence: (a) compare the current enterprise and technology strategy against the refreshed mission, stakeholder context, and dependency map to surface drift or gaps; (b) pull the current risk profile — top enterprise risks, risk-tolerance posture, and material findings since the last cycle; (c) where drift or risk-profile change is material, draft and compare alternative strategy options against mission fit and risk appetite.\n- Choose **Realign the strategy** (`realign`) when the strategy has drifted from the refreshed mission, or the risk profile has changed enough, that a revised enterprise and technology strategy is required — for example a new material risk the current strategy does not address, or objectives that no longer trace to mission.\n- Choose **Reaffirm current strategy** (`reaffirm`) when the strategy still aligns with mission and risk profile and no material drift is found; document the evidence that supports leaving it unchanged.\n\n**Record in AssureSwarm** — Submit the `strategy_alignment_decision` SELECT (realign or reaffirm). Record the rationale with evidence references in the step result, and name the approver in the step's approver record. Attach the comparison and option analysis as a document on this step (coach-document-upload); pull the supporting data via coach-query-data — the current risk profile from `Risk` items (`likelihood`, `impact`, `inherent_rating`, `residual_rating`, `treatment`, `risk_owner`) and material findings since the last cycle from open `Issue` items (`severity`, `issue_type`, `source`).\n\n**Exit criteria** — The SELECT is submitted with a rationale and evidence references; the Chief Strategy Officer owns the decision; the unselected branch is prunable.","kind":"decision","label":"Evaluate strategy alignment","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"evaluate-strategy-alignment"},{"data":{"description":"Agent compiles and publishes the context package to those who scope and prioritize risk work; human confirms risk-scoping owners have received and accepted it as their basis.","instructions":"**Objective** — Publish the refreshed context package to the owners who scope and prioritize risk work, and confirm they have received and accepted it as their current scoping basis.\n\n**Inputs**\n- The refreshed mission, the stakeholder register with needs and expectations, and the bidirectional objectives and dependency map, all from the validated context and dependency stage.\n- The prior cycle's context package, to diff what changed.\n- The named consumers: the CRO, the risk-assessment owners, and the control owners who scope and prioritize risk management activities.\n\n**Procedure**\n1. Compile the context package — refreshed mission, stakeholder register with needs and expectations, and the bidirectional dependency map — into a single referenceable record.\n2. Diff against the prior cycle and write a concise \"what changed\" summary so consumers can assess impact on in-flight or planned risk work.\n3. Publish the package to a dashboard visible to the CRO, risk-assessment owners, and control owners.\n4. Notify each named risk-scoping owner that the refreshed context is available, pointing to the change summary.\n5. Capture acknowledgment as each owner confirms receipt, and record any immediate rescoping requests they raise.\n\n**Record in AssureSwarm**\n- Upload the context package document to this step (coach-document-upload).\n- Create or update the context dashboard (coach-dashboard-create).\n- Log each owner's acknowledgment and any rescoping request, and notify owners on publish (coach-notify).\n\n**Exit criteria** — Context package published and visible to all named owners; change summary attached; every risk-scoping owner has acknowledged receipt; the CRO confirms they accept it as the current basis for scoping and prioritizing risk work.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` — alerts the named risk-scoping owners the moment the refreshed context package is published and tracks their acknowledgments.","label":"Communicate context to risk-scoping owners","performedBy":{"primitives":["coach-document-upload","coach-dashboard-create","coach-notify"]}},"id":"communicate-context-to-risk-scoping-owners"},{"data":{"description":"Agent drafts the realigned enterprise and technology strategy against mission and risk profile; human strategy owner reviews the realigned strategy before objectives are cascaded.","instructions":"**Objective** — Draft the realigned enterprise and technology strategy — the option selected in the alignment decision — stating how it aligns to the refreshed mission and answers the current risk profile, ready to cascade into objectives.\n\n**Inputs**\n- The strategy alignment decision resolved to realign, with its rationale and the evaluated options, from \"Evaluate strategy alignment.\"\n- The refreshed mission, dependency map, and current risk profile.\n- The prior approved strategy document and its change log.\n\n**Procedure**\n1. Draft the realigned strategy, selecting from the evaluated options, and state explicitly how it aligns with the refreshed mission and responds to the current risk profile.\n2. Document the rationale for the chosen option over the alternatives, including the risk trade-offs accepted and the mitigations planned.\n3. Identify the strategic initiatives and technology investments the realigned strategy implies, with indicative sequencing and owners.\n4. Update the strategy document and change log so the revision is traceable against the prior approved strategy.\n\n**Record in AssureSwarm**\n- **Step documents** — upload the realigned enterprise and technology strategy (DOCX) and its change log to this step (coach-document-upload); list the strategic initiatives and technology investments, with indicative owners and sequencing, inside the strategy document. There is no Initiative item type in this schema, so those initiatives live in the strategy document rather than as items.\n\n**Exit criteria** — Realigned strategy drafted with explicit mission and risk-profile alignment; option rationale and trade-offs documented; initiatives identified with owners; change log updated; the Chief Strategy Officer has reviewed it and confirmed it is ready to cascade into objectives.","label":"Realign enterprise and technology strategy","performedBy":{"primitives":["coach-document-upload","coach-item-create"]}},"id":"realign-enterprise-technology-strategy"},{"data":{"description":"Agent cascades business objectives to all levels and publishes the communicated roadmap; human confirms objectives are consistent with the strategy and the roadmap is ready to communicate.","instructions":"**Objective** — Cascade the chosen or reaffirmed strategy into aligned objectives at every organizational level and publish a sequenced, owned roadmap ready to communicate and monitor.\n\n**Inputs**\n- The realigned strategy and its initiatives, from \"Realign enterprise and technology strategy\" — or, on the reaffirm branch, the reaffirmed current strategy carried from the alignment decision.\n- The dependency map, to link objectives to the dependencies they support.\n\n**Procedure**\n1. Cascade the strategy into business objectives at each level of the organization — enterprise, business unit, and team — so every level's objectives visibly align with and support the strategy.\n2. Link each cascaded objective to the strategic initiative or dependency it supports, making the chain from strategy to team-level objective traceable.\n3. Compile the roadmap: translate the strategy and cascaded objectives into a sequenced, owned timeline of initiatives and milestones with target dates.\n4. Publish the roadmap to a dashboard and prepare the communication package for cascading it across the organization.\n\n**Record in AssureSwarm**\n- **Step document** — capture the cascaded objectives (enterprise, business-unit, and team level, each traceably linked to the strategy and to the initiative or dependency it supports) and the sequenced, owned roadmap of milestones with target dates as an XLSX on this step (coach-document-upload). There is no Objective item type in this schema, so the objectives cascade and roadmap live in this document.\n- **Dashboard** — publish the roadmap to a dashboard (coach-dashboard-create) so owners and target dates stay visible between cycles.\n\n**Exit criteria** — Objectives cascaded to every level and each traceably linked to the strategy; roadmap published with owners and target dates; the Chief Strategy Officer confirms the objectives are consistent with the strategy at every level and the roadmap is accurate and ready to be communicated and monitored.","label":"Cascade objectives and publish roadmap","performedBy":{"primitives":["coach-item-create","coach-dashboard-create","coach-document-upload"]}},"id":"cascade-objectives-and-publish-roadmap"},{"data":{"description":"Agent tracks execution against the published roadmap and compiles a status summary; human confirms progress and follow-up owners for slipping milestones.","instructions":"**Objective** — Track execution against the published roadmap between cycles and produce a current status summary that flags on-track, at-risk, and slipped milestones with owners and recovery paths.\n\n**Inputs**\n- The published roadmap with milestones, owners, and target dates, from \"Cascade objectives and publish roadmap.\"\n- Linked workflows, items, and owner status updates that evidence progress.\n\n**Procedure**\n1. Track each roadmap initiative and milestone against its planned date, pulling status from linked workflows, items, and owner updates.\n2. Compare actual progress to plan; classify each milestone as on-track, at-risk, or slipped against its target date.\n3. For at-risk or slipped milestones, identify the responsible owner and capture the reason and a proposed recovery date where available.\n4. Update the roadmap dashboard so it stays a live reference between cycles.\n\n**Record in AssureSwarm**\n- **Dashboard** — update each milestone's status (on-track / at-risk / slipped) on the roadmap dashboard so it stays a live reference between cycles; pull progress from linked workflows and items via coach-query-data and coach-workflow-scan.\n- **Step document** — attach a status-summary document to this step recording, for every at-risk or slipped milestone, the responsible owner, the reason, and a proposed recovery date (coach-document-upload). The roadmap milestones have no native item type, so the summary document is where their status is recorded.\n\n**Exit criteria** — Every milestone classified against plan; slipping milestones have an owner and a credible recovery path; the roadmap dashboard reflects current status; the Chief Strategy Officer confirms the execution status is accurate and that monitoring continues until the next cycle or triggering event.","label":"Monitor roadmap execution","performedBy":{"primitives":["coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"monitor-roadmap-execution"},{"data":{"decisionField":"risk_scoping_approval_decision","description":"CRO and risk committee with process-owner input: Approve complete mission-essential process definitions, ownership, success boundaries and CIA needs as a usable risk-assessment scope, or require specific correction.","formData":{"fields":[{"key":"risk_scoping_approval_decision","label":"Risk-scoping basis approval decision","options":[{"label":"Approved as risk-assessment scoping basis","value":"approved"},{"label":"Revision required before approval","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Document mission-essential processes and information-protection needs with traceable objectives, then obtain CRO/risk-committee approval of the complete scoping basis.\n\n**Decision criteria**\nInputs for preparation: - The cascaded objectives and their strategy linkage, from \"Cascade objectives and publish roadmap.\"\n- The bidirectional dependency map (carried through the cascade) and process-owner input.\n- The organization's data classification and confidentiality/integrity/availability requirement references, if maintained.\n\n*Autonomous preparation incorporates Document mission-essential processes; CRO and risk committee with process-owner input reviews the combined evidence.*\n1. Identify the mission-essential and business processes that carry out the strategy and objectives, drawing on the objectives cascade, the dependencies, and process owners.\n2. For each mission-essential process, document its information-protection needs — the confidentiality, integrity, and availability requirements of the information it handles.\n3. Draft each objective and process definition with enough specificity — clear boundaries, owners, and success criteria — that risk-assessment work can be scoped directly from it without further clarification.\n4. Link each process definition to the business objective and stakeholder dependency it supports, so risk assessment can trace scope back to strategy.\n\nBefore routing, the agent assembles the approval package (process definitions, information-protection needs, linked business objectives, and traceability back to the refreshed mission and strategy), cross-checks completeness (every process has an owner, information-protection needs, and a clear objective definition), flags any gaps, and drafts an approval brief stating the package will be the approved basis for scoping and prioritizing the next risk assessment.\n- Choose **Approved as risk-assessment scoping basis** (`approved`) when every mission-essential process has an owner, documented information-protection needs, and a definition specific enough to scope risk work with no open gaps.\n- Choose **Revision required before approval** (`revise`) when any gap remains — a missing owner, undefined information-protection needs, or a definition too vague to scope from.\n\n**Record in AssureSwarm**\n- **Item create** — create a `Process` item per mission-essential process (`process_type`: business_process or it_general_control as applicable; `process_owner` set) whose `description` holds the definition — boundaries, owner, and success criteria — together with the information-protection (confidentiality, integrity, availability) needs of the information it handles. `Process` has no dedicated CIA fields, so those needs are folded into `description` and the definitions document (coach-item-create).\n- **Item relationships** — link each `Process` to the `Risk` items that concern it and the `Control` items that operate within it, where they exist, so risk assessment can trace scope back to strategy (coach-items-link).\n- **Step document** — upload the mission-essential process and objective definitions package to this step (coach-document-upload); the cascaded business objectives it references have no item type and live in this document.\nSubmit the `risk_scoping_approval_decision` SELECT (approved or revise). Record the rationale and evidence references in the step result, and name the approver in the step's approver record. Upload the approval brief (coach-document-upload) and link the package records (coach-items-link).\n\n**Exit criteria**\nApprove complete mission-essential process definitions, ownership, success boundaries and CIA needs as a usable risk-assessment scope, or require specific correction.\nEvery mission-essential process documented with its information-protection needs and a specific, ownable definition; each linked to its objective and dependency; the CRO confirms the definitions are specific enough to serve as the scoping basis for risk assessment.\nThe SELECT is submitted with a rationale; the CRO and risk committee own the decision; the unselected branch is prunable.","kind":"decision","label":"Approve risk-scoping basis","performedBy":{"primitives":["coach-item-create","coach-document-upload","coach-items-link"]}},"id":"approve-risk-scoping-basis"},{"data":{"description":"Agent applies the CRO and risk committee's requested revisions to the process and objective definitions; human confirms the gaps are resolved.","instructions":"**Objective** — Apply the CRO and risk committee's requested revisions to the process and objective definitions and confirm every raised gap is closed, so the package can serve as the approved risk-scoping basis.\n\n**Inputs**\n- The approval decision resolved to revise, with the committee's specific comments, from \"Approve risk-scoping basis.\"\n- The prior submitted package of mission-essential process and objective definitions.\n\n**Procedure**\n1. Translate each committee comment into a specific revision to the mission-essential process definitions, information-protection needs, or objective definitions.\n2. Apply the revisions and record a change log showing what changed against the version submitted for approval.\n3. Re-run the completeness check to confirm every flagged gap is closed and no new gap was introduced.\n4. Re-circulate the revised package to the CRO for confirmation.\n\n**Record in AssureSwarm**\n- **Step document** — upload the revised mission-essential process and objective definitions package and its change log (against the version submitted for approval) to this step (coach-document-upload).\n- **Item field update** — apply the accepted revisions to the affected `Process` items, updating `Process.description` (definition, boundaries, CIA needs) and `Process.process_owner` where ownership changed (coach-item-update); capture the CRO’s actual approval of the corrected definitions in native approvals with the supporting native result.\n\n**Exit criteria** — Every raised gap resolved; the change log is complete against the prior version; no new gap introduced; the CRO confirms the revised definitions are approved to serve as the risk-assessment scoping basis.","label":"Resolve risk-scoping gaps","performedBy":{"primitives":["coach-document-upload","coach-form-fill","coach-item-update"]}},"id":"resolve-risk-scoping-gaps"},{"data":{"description":"Automatically archive the authorized context, strategy, execution status and approved scoping basis, update downstream references and communicate the next review.","instructions":"**Objective** — Archive the complete cycle record — context, strategy decision, roadmap and its execution status, and the approved risk-scoping basis — as durable, self-contained evidence, and link it to the downstream risk-assessment work it feeds.\n\n**Inputs**\n- The refreshed mission and stakeholder context and the objectives and dependency map, from the context steps.\n- The strategy realignment-or-reaffirmation decision and, if realigned, the realigned strategy.\n- The published roadmap and its current execution status, from \"Monitor roadmap execution.\"\n- The approved mission-essential process and objective definitions, from \"Approve risk-scoping basis\" or \"Resolve risk-scoping gaps,\" and the risk-scoping owners' acceptance, from \"Communicate context to risk-scoping owners.\"\n\n**Procedure**\n1. Assemble the complete cycle record — the refreshed mission and stakeholder context, the objectives and dependency map, the strategy realignment or reaffirmation decision, the published roadmap and its execution status, and the approved mission-essential process and objective definitions.\n2. Archive the record to the retention location with version, approval date, and applicable retention period, and link it to the governance register.\n3. Update linked records — the downstream risk-assessment scoping work, the control inventory, and the roadmap dashboard — so they reference the current approved context and objectives. This cycle produces no separate handoff workflow; the approved scoping basis is the input the risk-assessment cycle consumes.\n4. Communicate the closed cycle, its effective date, and the next scheduled or trigger-based review to stakeholders.\n\n**Record in AssureSwarm**\n- Export and assemble the full cycle record (coach-workflow-export).\n- Link the archived record to the governance register and downstream risk-assessment records (coach-document-link).\n\n**Exit criteria** — Complete cycle record archived with version, approval date, and retention period; downstream risk-assessment, control inventory, and dashboard references updated; closure communicated; the retained record is self-contained enough to serve as evidence to auditors and the board without oral explanation, and the cycle closes automatically under its prior authorized decisions.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-export` — assembles the full cycle record into a single archivable package with version and retention metadata.","label":"Close and archive","performedBy":{"primitives":["coach-workflow-export","coach-document-upload"]},"requiredApprovals":0},"id":"close-and-archive"}],"sourceTemplateId":"workflow-library:grc-strategic-context-objectives-alignment-cycle"}