{"description":"Adopt or refresh a security/compliance framework (for example NIST CSF 2.0, ISO/IEC 27001:2022, or SOC 2) by scoping the target framework, rating the current profile, defining the target profile, crosswalking requirements to existing controls and adjacent frameworks, prioritizing gaps, and maintaining a live mapping table. The workflow instance runs on an Audit item created at the start of each adoption cycle (audit_type: readiness, or compliance) — its scope/period fields carry the assessment boundary and cycle window, and every step document versions against it. No upstream workflow feeds this one; it consumes the organization's own existing inventory: the risk register (Risk items), the control library / RCM (Control items and their Risk links), the in-scope Process inventory, and any prior Audit items for this or adjacent frameworks. Named deliverables: the framework mapping table (the crosswalk), the risk-ranked prioritized gap list, the coverage/gap dashboard, and the versioned adoption package. In scope: profile construction, crosswalk mapping, gap prioritization, and the closure disposition. Out of scope: authoring the policies and designing the new controls the gaps demand — those are handed off downstream to TWO workflows, Policy Lifecycle Management (policy-driven gaps) and Control Design (control-build gaps).","edges":[{"id":"e-define-target-profile-classify-disposition","source":"define-target-profile","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-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","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-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-GOV-16","UC-RISK-14"],"department":"compliance-legal","domains":["grc"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=grc-framework-adoption-cross-mapping","contentDigest":"sha256:1a62dedf9c3fd637b88064ca3f0909b6746b8c23914c060731d9c9c4acef0250","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:1a62dedf9c3fd637b88064ca3f0909b6746b8c23914c060731d9c9c4acef0250","schemaVersion":1,"sourceTemplateId":"workflow-library:grc-framework-adoption-cross-mapping"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"grc-framework-adoption-cross-mapping","source":"coworkcanvas-gallery","standards":["nist-csf-2","iso-27001","soc2"],"teams":["compliance-legal","risk-management"]},"name":"Framework Adoption & Cross-Mapping","nodes":[{"data":{"description":"Framework owner and risk-appetite concurrence authority: Fix the framework/version and boundary and approve mandatory or aspirational target levels from obligations and risk appetite, including below-default exceptions.","instructions":"**Objective** — Fix the framework scope and common rubric and obtain owner/risk-appetite concurrence on targets that are independent of the current profile.\n\n**Inputs**\n- The target framework and exact version, and the driver (new customer/contract requirement, certification renewal, regulatory change, board directive). Example targets: NIST CSF 2.0, ISO/IEC 27001:2022, SOC 2 (2017 TSC, revised). The framework name maps to a `Control.framework` option value (nist-csf-2 / iso-27001 / soc2).\n- The organization's risk universe — the existing **Risk items** (category, likelihood, impact, inherent/residual rating) — and the existing control inventory / risk-and-control matrix (RCM) — the existing **Control items** (control_id, framework, domains, control_owner) and their Control ↔ Risk links.\n- Any prior assessment of this or an adjacent framework: prior **Audit items** (rating, opinion, report_date) and their linked Issue items.\n- The boundary inputs: in-scope legal entities, systems, environments, and data classifications (the in-scope **Process items** are the systems/processes the boundary is drawn over), plus named owners (framework owner, per-category control owners, GRC lead).\n- No upstream workflow feeds this step — scope is built from the organization's own Risk, Control, and Process inventory. This step CREATES the anchor Audit item for the cycle; everything above is an existing input it links to, not something it recreates.\n- The requirement register XLSX and the locked scoring rubric (step documents from the approved scope/target package).\n- Risk appetite thresholds, contractual and regulatory obligations (uploaded as an appetite/obligation statement on this step — no native obligation type), and the business criticality of the systems each requirement protects (proxied by existing `Risk.impact` and the linked in-scope Process items).\n\n**Procedure**\n*Autonomous preparation incorporates Scope target framework; Framework owner and risk-appetite concurrence authority reviews the combined evidence.*\n1. Confirm the exact framework and version and enumerate its structure so the register is complete: CSF 2.0 has 6 Functions / 22 Categories / 106 Subcategories; ISO 27001:2022 Annex A has 93 controls across 4 themes; SOC 2 covers the 5 Trust Services Criteria. Record the counts you expect to map.\n2. Draw the boundary: list the entities, systems, environments, and data classifications in scope, and state every exclusion with a one-line rationale (e.g., \"dev sandbox excluded — no production data\").\n3. Seed the requirement register: create one row per framework requirement (subcategory/Annex A control/TSC point of focus), each carrying the authoritative framework reference id and a short requirement statement. This register is the spine every later step writes onto.\n4. Assign accountability: the framework owner is accountable for the cycle; assign a responsible owner to each Function/Category so profiling and crosswalk work can be parallelized.\n5. Lock the executable workplan: confirm final scope, owners, and due dates for each parallel stream (current profile, target profile, crosswalk), the evidence expectations, the review cadence, and the disposition-review date. Attach the locked plan so scope changes after this point are change-controlled.\n6. Fix a single scoring rubric to be reused by both profiles so they are comparable — e.g., a 0–5 implementation-maturity scale (0 none, 1 ad hoc, 2 defined, 3 managed, 4 measured, 5 optimized) or CSF Tiers 1–4. Record it on the workflow.\n7. For each requirement, set a target score on the same rubric used for the current profile so the two are directly comparable. Base the target on appetite and obligation, not on current capability — this step must not be anchored to the as-is rating.\n8. Apply risk-based tiering: crown-jewel systems and high-impact data warrant higher targets than low-criticality assets. Justify any target set above or below the framework's default expectation.\n9. Classify each target as mandatory (a contractual, certification, or regulatory floor that cannot be traded away) or aspirational (a maturity ambition that can be phased). This flag drives how gaps are prioritized later.\n10. Set a target date or phasing for each requirement so the eventual action plan has a timeline to align to.\n11. Obtain owner and risk-appetite concurrence on the target levels, especially where a target is set below the framework default (an implicit risk acceptance that needs sign-off).\n\n**Record in AssureSwarm**\n- **Item create** — the anchor **Audit** item for this cycle (`audit_type: readiness`, or `compliance`); set `Audit.description` (framework, version, driver) and `Audit.scope` (boundary + exclusions); set `Audit.period_start`/`Audit.period_end` to the cycle window. Record the framework owner in `Audit.lead_auditor`.\n- **Item relationship** — link the anchor Audit ↔ the in-scope **Process** items (the boundary the assessment is drawn over).\n- **Step document** — seed the requirement register as an XLSX attached to this step: one row per requirement (subcategory / Annex A control / TSC point of focus) carrying its framework-ref id and requirement statement. There is no native Requirement item type, so the register is the versioned working spine that lives as a step document, not queryable items.\n- **Step document** — attach the locked workplan + scoring rubric as a DOCX/PDF on this step; the rubric has no native field. Category owners live in `Control.control_owner` / `Risk.risk_owner` on the linked items.\n- **Step document** — record the target score, its justification, the mandatory/aspirational flag, the target date, and captured owner concurrence in each row of the requirement register XLSX, and re-version it on this step. Target scores have no native item field.\n\n**Exit criteria**\nFix the framework/version and boundary and approve mandatory or aspirational target levels from obligations and risk appetite, including below-default exceptions.\nFramework and version fixed; boundary documented with exclusions; requirement register seeded with every in-scope requirement as a row; owners assigned; scoring rubric recorded; workplan locked with due dates and a disposition-review date.\nEvery requirement has a target score justified against appetite and obligation; mandatory vs aspirational is flagged on each row; owner concurrence on target levels is recorded.","label":"Define Target Profile","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-items-link","coach-document-upload","coach-item-update"]}},"id":"define-target-profile"},{"data":{"decisionField":"disposition_path","description":"Framework owner/GRC lead with mapping specialists: Judge actual implementation evidence and crosswalk equivalence/confidence, rank net gaps against the fixed target and select complete, action or monitor disposition.","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** — Assess the current profile and mapping claims, compute and rank net gaps, publish the maintained crosswalk and decide how the adoption cycle proceeds.\n\n**Decision criteria**\nInputs for preparation: - The requirement register XLSX and the locked scoring rubric (step documents from the approved scope/target package).\n- The existing **Control items** / RCM and prior **Audit items** and their linked Issue items.\n- KRI/KPI data and the evidence repositories (ticketing, config exports, policy docs) that substantiate current operation — pulled as extracts and uploaded to this step (there is no native metric type; these repositories live outside AssureSwarm).\n- The requirement register XLSX from the approved scope/target package.\n- The catalog of other frameworks already in force — inferred from the `Control.framework` MULTISELECT tags across the existing **Control** library (which frameworks each control already serves) — and the existing control inventory (Control items).\n- Authoritative crosswalk references as a starting point — NIST OLIR informative references, published CSF-to-ISO/SP 800-53 mappings, and the Secure Controls Framework (SCF) — attached as working-copy extracts (XLSX/CSV) on this step.\n- The current-profile scores (from current-profile assessment in this checkpoint), the target-profile scores (from the approved target profile), and the crosswalk coverage (from crosswalk validation in this checkpoint) — all carried in the requirement register XLSX. Complete current-profile and crosswalk validation against the approved target before computing gaps.\n- Risk appetite thresholds and system criticality ratings (proxied by `Risk.impact` on the linked Risk items).\n- The completed requirement register carrying current, target, crosswalk, and gap fields (prepared through the profile, crosswalk and gap stages in this checkpoint).\n- Stakeholder reporting expectations (board/committee, certification body, control owners).\n\n*Autonomous preparation incorporates Rate Current Profile; Crosswalk requirements; Prioritize gaps; Report and maintain crosswalk; Framework owner/GRC lead with mapping specialists reviews the combined evidence.*\n1. For each requirement row, identify the existing controls, processes, or tooling that currently address it and link them to the row. Where nothing exists, mark the row explicitly rather than leaving it blank.\n2. Score current implementation on the locked rubric, citing the evidence that supports the score (control test result, config export, owner attestation, last-review date). Do not score on assertion alone.\n3. Distinguish three states clearly: implemented-and-evidenced, partial (design exists but coverage or operation is incomplete), and absent. Separately flag implemented-but-unevidenced — a real risk to certification even when the control exists.\n4. Record each evidence reference with its date and source so a reviewer can re-pull it; a score with no traceable evidence is not defensible.\n5. Note compensating controls that partially satisfy a requirement even if the primary control is absent, and reflect that in the score with a rationale.\n6. Reconcile against any prior assessment: for every changed score, record why it moved (new control, decommissioned system, re-scoping) so deltas are explainable.\n7. For each requirement, find equivalent or related requirements in the adjacent frameworks and record the relationship type: equivalent, subset, superset, or partial. A subset/superset mismatch means coverage is not one-for-one and cannot be assumed complete.\n8. Seed the mapping from an authoritative reference (NIST OLIR, SCF) but validate each row — published mappings are informative, not binding, and often over-claim equivalence. Downgrade any relationship you cannot substantiate.\n9. Map each requirement to the existing internal control id(s) that satisfy it, so already-operating controls are credited rather than rebuilt.\n10. Flag many-to-one and one-to-many relationships explicitly (one control covering several requirements, or one requirement needing several controls) so the gap math later does not double-count or under-count.\n11. Identify requirements with no adjacent-framework equivalent and no existing control — mark these net-new; they are the true build candidates.\n12. Record a mapping confidence (high/medium/low) per row so low-confidence mappings can be re-examined before gaps are closed on their strength.\n13. Compute gap = target score − current score for each requirement and keep only the positive gaps (target exceeds current). Zero or negative gaps are already met.\n14. Net out crosswalk coverage: where an existing control already satisfies the requirement via a validated crosswalk mapping, close or downgrade the gap and record which control covers it — do not double-count work already done.\n15. Risk-score each remaining gap: likelihood × impact, weighted by the criticality of the systems affected and whether the target is mandatory. A mandatory-target gap on a crown-jewel system outranks a large aspirational gap on a low-criticality asset.\n16. Rank the gaps and group them into remediation waves or severity tiers (e.g., Wave 1 = mandatory + appetite-breaching; Wave 2 = high-value aspirational; Wave 3 = long-tail).\n17. Estimate effort per gap to separate quick wins from multi-quarter builds, so sequencing is realistic.\n18. Flag every gap that breaches risk appetite; these are the ones that will drive the disposition decision and any escalation.\n19. Assemble the live mapping table: one view joining each requirement to its adjacent-framework references, mapped controls, current/target scores, gap, and priority. This is the durable artifact the organization consults between cycles.\n20. Build the summary report or dashboard: coverage percentage overall and per Function/theme, gap counts by severity, and the status of every mandatory-target gap.\n21. Define the refresh cadence and the change triggers that force a re-map before the cadence elapses: a framework version revision, a control decommission or redesign, or a new in-scope system.\n22. Assign a table owner and a review cycle so the crosswalk does not silently rot.\n23. Version the table and record this publication as the baseline, so future changes are diffable.\n24. Publish to stakeholders in the format each expects.\n\n- **complete** — Choose when no positive gaps remain, or every remaining gap is closed through validated crosswalk coverage, and every mandatory target is met. The cycle proceeds straight to packaging with no remediation or acceptance work.\n- **gaps** — Choose when one or more gaps require remediation with owners and dates, especially any mandatory-target or appetite-breaching gap. This routes to building an owned action plan before packaging.\n- **monitor** — Choose when residual gaps exist but sit within risk appetite and do not warrant immediate remediation; the right response is a documented risk acceptance and a monitoring trigger rather than a build.\n\n**Record in AssureSwarm**\n- **Step document** — record the current score, the implemented/partial/absent/unevidenced flag, and any compensating-control note in each row of the requirement register XLSX, and re-version it on this step. These per-requirement scores have no native item field.\n- **Item relationship** — link the anchor **Audit** ↔ the existing **Control** items that currently address each requirement, so operating controls are credited rather than rebuilt.\n- **Step document** — attach the KRI/KPI extracts and evidence pulls (config exports, ticket exports, policy docs) as evidence documents on this step; cite each in the register row with its date and source.\n- **Item field update** — for each mapped internal **Control**, add the target framework to `Control.framework` (MULTISELECT) so the control library natively credits the target-framework coverage.\n- **Item relationship** — link the anchor **Audit** ↔ the existing **Control** items that satisfy each requirement.\n- **Step document** — record the mapped adjacent-framework reference ids, the relationship type (equivalent/subset/superset/partial), the mapping confidence (high/medium/low), and the net-new flag in the crosswalk rows of the requirement register XLSX. Item fields cannot express relationship type, confidence, or per-requirement granularity, so the authoritative mapping table stays this versioned document.\n- **Step document** — record gap-size, gap-risk, priority-rank, and remediation-wave in each row of the requirement register XLSX (these have no native item field), and produce the named **prioritized gap list** as an XLSX attached to this step.\n- **Dashboard** — build the coverage/gap dashboard (coverage % overall and per Function/theme, gap counts by severity, and the status of every mandatory-target gap).\n- **Step document** — publish the live framework **mapping table** as an XLSX versioned as the baseline, and attach the summary report on this step.\n- **Step document** — record the refresh cadence, change triggers, the named table owner, and the version on the mapping table itself; there is no native Framework item type to hold these fields.\nSubmit the `disposition_path` SELECT with the chosen value. Write the justification and evidence references in the step result, and name the accountable approver in the step's approver record.\n\n**Exit criteria**\nJudge actual implementation evidence and crosswalk equivalence/confidence, rank net gaps against the fixed target and select complete, action or monitor disposition.\nEvery in-scope requirement carries a current score with cited, dated evidence; unevidenced and absent requirements are flagged distinctly; deltas from any prior assessment are explained.\nEvery requirement is mapped to adjacent-framework references and/or internal controls with a relationship type and confidence, or is explicitly marked net-new; many-to-many relationships are flagged.\nEvery positive gap is risk-scored and ranked; crosswalk-covered requirements are netted out with the covering control noted; appetite-breaching gaps are flagged; remediation waves are defined.\nLive mapping table published and versioned as a baseline; summary dashboard built; refresh cadence, change triggers, and a named owner assigned.\n\n> **⚡ Audit Artist accelerator:** `/coach-query-data` pulls the joined requirement, control, and gap dataset and `/coach-dashboard-create` renders the coverage and gap dashboard so the mapping table stays a live view rather than a static export.\nThe SELECT is submitted with a rationale that cites the gap evidence, and the unused branches are prunable because each branch edge value matches the selected form value.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"grc-artist","primitives":["coach-item-update","coach-items-link","coach-query-data","coach-document-upload","coach-render-package","coach-dashboard-create"]}},"id":"classify-disposition"},{"data":{"description":"Produce an owned, dated remediation plan for the prioritized gaps that require action","instructions":"**Objective** — Produce an owned, dated remediation plan for the prioritized gaps that the disposition decision routed to action.\n\n**Inputs**\n- The prioritized gap list and remediation waves (from the gap analysis in the disposition checkpoint) and the disposition decision selecting the gaps branch.\n- Owner availability and any dependency on the downstream Policy Lifecycle Management and Control Design workflows that will do the actual policy authoring or control build.\n\n**Procedure**\n1. For each actionable gap, record the root cause (why the requirement is unmet — no control, weak design, or unevidenced operation), since the remediation differs by cause.\n2. Assign a single accountable owner and a due date aligned to the requirement's target date and remediation wave.\n3. Define an interim mitigation for gaps that cannot be closed before their due date, so residual exposure is managed in the meantime.\n4. State the validation evidence that will prove the gap is closed (a passed control test, a signed policy, a config attestation) so closure is verifiable, not asserted.\n5. Flag which gaps require downstream policy work versus control-design work, so the handoff can route them correctly.\n6. Set a reporting cadence and escalation path for slipping items.\n\n**Record in AssureSwarm**\n- **Item create** — one **Issue** per actionable gap (`issue_type: deficiency`, `source: self_assessment`) with `issue_owner`, `identified_date`, `target_remediation_date`, `root_cause`, and `remediation_plan` (the remediation_plan carries the interim mitigation, the validation criteria, and the policy-vs-control routing flag).\n- **Item relationship** — link each Issue ↔ the covering **Control** and ↔ the anchor **Audit**. The gap rows live in the register document, so each Issue anchors to its Control and the Audit rather than to a register row.\n\n**Exit criteria** — Every actionable gap has an owner, a due date, an interim mitigation where needed, and explicit validation criteria; a reporting and escalation cadence is set.","label":"Create action plan","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-items-link"]}},"id":"create-action-plan"},{"data":{"description":"For gaps not being remediated now, prepare the escalation or risk-acceptance decision with a monitoring trigger","instructions":"**Objective** — For gaps the disposition decision routed to monitor, prepare the escalation or formal risk-acceptance decision, with a monitoring trigger and expiry, so unremediated exposure is governed rather than forgotten.\n\n**Inputs**\n- The prioritized gap list and appetite flags (from the gap analysis in the disposition checkpoint) and the disposition decision selecting the monitor branch.\n- The organization's risk-acceptance authority matrix (who may accept residual risk at which magnitude).\n\n**Procedure**\n1. Draft a concise decision memo per residual gap: the requirement, the residual exposure, why immediate remediation is not warranted, and the recommended acceptance or escalation.\n2. Quantify the residual impact so the accepting authority sees magnitude, not just a label.\n3. Capture the acceptance conditions and an explicit expiry date — an acceptance with no expiry is an ungoverned open risk.\n4. Route to the correct authority per the acceptance matrix and appetite: within-appetite residuals to the risk owner; appetite-breaching residuals up the chain to the GRC lead, executive sponsor, or board delegate.\n5. Define the monitoring trigger and KRI that will force a re-review (threshold breach, control failure, new system, or the expiry date), and set the re-review date.\n\n**Record in AssureSwarm**\n- **Item create** — a **policy_exception Issue** (`issue_type: policy_exception`) recording the risk acceptance: `exception_approver` (the named accepting authority), `exception_expiry_date` (the acceptance expiry / forced re-review date — the filterable expiry index), `issue_owner`, and `description` (the residual exposure, quantified impact, acceptance conditions, and the monitoring trigger/KRI). The monitoring trigger has no native field, so it lives in the Issue description and the acceptance memo.\n- **Item field update** — on the accepted **Risk**, set `treatment: accept` and confirm `residual_rating` and `risk_owner` so the register reflects the governed acceptance.\n- **Item relationship** — link the policy_exception Issue ↔ the accepted **Risk** and ↔ the anchor **Audit**.\n- **Step document** — attach the acceptance / escalation decision memo (DOCX) on this step for the full rationale.\n\n**Exit criteria** — Each residual gap is either formally accepted with a named authority, expiry, and monitoring trigger, or escalated to a named decision-maker; nothing is left as an untracked open exposure.","label":"Escalate or accept risk","performedBy":{"agent":"grc-artist","primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload","coach-notify"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"Receiving Policy Lifecycle and Control Design owners: Accept ownership of each policy or control gap subset and its authoritative crosswalk/profile evidence before the adoption cycle closes.","instructions":"**Objective** — Assemble and deliver the decided adoption record and owned gaps, retaining the immutable mapping baseline and maintenance schedule.\n\n**Inputs**\n- The mapping table and gap report (from the published crosswalk in the disposition checkpoint).\n- Depending on the disposition branch that reached this join: the action plan (from Create action plan), the risk-acceptance record (from Escalate or accept risk), or neither when the disposition was complete.\n- The final package and its version (from Prepare final package) and the action plan's policy-vs-control routing flags, which say which gaps need policy work and which need control-design work.\n- The published mapping table and its version, and the refresh cadence and change triggers set during crosswalk publication.\n\n**Procedure**\n*Autonomous preparation incorporates Prepare final package; Receiving Policy Lifecycle and Control Design owners reviews the combined evidence.*\n1. Assemble the package: the current and target profiles, the crosswalk, the prioritized gaps, the disposition decision with rationale, and whichever of the action plan or risk-acceptance record applies.\n2. Include unresolved constraints and open assumptions so the downstream owners inherit an honest picture, not a sanitized one.\n3. QA the traceability chain: every conclusion should trace back to a requirement row, an evidence reference, and an accountable owner. Fix any break before packaging.\n4. State the proposed conclusion for the cycle (adopted / adopted-with-remediation / monitored) and the residual position.\n5. Version the package and record the baseline so downstream and archive copies are identifiable.\n6. Split the actionable gaps into two streams: policy-driven (needs a new or revised policy/standard) and control-design-driven (needs a control built or redesigned).\n7. Create or link the downstream workflow instances — Policy Lifecycle Management for the policy stream and Control Design for the control stream — and attach the final package to each.\n8. Write a handoff note stating the assumptions carried in and, explicitly, what the downstream workflow should NOT repeat: the crosswalk, the profiles, and the gap prioritization are done and authoritative.\n9. Confirm the downstream owners have received the package and acknowledged ownership of their gap subset.\n10. Archive the final package and the current mapping-table version to a read-only, retention-governed location so the cycle is reproducible for auditors, and confirm the archive is immutable.\n11. Update the linked control and framework records with the outcome — mapped coverage, accepted residuals, and open action items — so the enterprise inventory reflects this cycle.\n12. Schedule the next refresh per the maintenance cadence and register the change triggers so an interim event forces an early re-map.\n13. Communicate the final decision and residual position to the framework owner and stakeholders; the acknowledged handoff recorded on this step closes the run, and the workflow record is marked closed on that basis.\n\n**Record in AssureSwarm**\n- **Step document** — attach the final versioned **adoption package** (PDF/DOCX) on this step.\n- **Item field update** — summarize the cycle conclusion on the anchor **Audit**: set `Audit.rating` and `Audit.report_date`. The residual position and package version have no native Audit field, so they live in the package document.\n- Record each receiving owner’s actual acceptance in native approvals, with scope and limitations in the native result. Retain the source owner’s closure sign-off where the procedure requires it.\n- **Handoff package** — attach the final adoption package + the handoff note to each downstream workflow instance (Policy Lifecycle Management for the policy stream, Control Design for the control stream); the note states what is authoritative and must NOT be re-derived — the crosswalk, the profiles, and the gap prioritization.\n- **Item relationship** — link the downstream Policy Lifecycle Management and Control Design workflow instances to the anchor **Audit**.\n- **Step document** — record the scope-of-work note and each downstream owner's acknowledgement on this step, along with the archive location, the next-review date, and the closure note (these have no native Audit field).\n- **Workflow instance** — the closed run on the anchor **Audit** is the durable audit trail; mark it closed and archive it read-only.\n- **Item field update** — reflect the cycle outcome on the anchor **Audit** and the linked **Control** items (mapped coverage, accepted residuals, open action items).\n\n**Exit criteria**\nAccept ownership of each policy or control gap subset and its authoritative crosswalk/profile evidence before the adoption cycle closes.\nPackage assembled with profiles, crosswalk, gaps, disposition, and any action plan or acceptance; traceability QA passed; conclusion and residual position stated; version recorded and ready for handoff.\n\n\nDownstream Policy Lifecycle Management and Control Design workflows are created or linked with the package attached and the scope-of-work note recorded; downstream owners have acknowledged ownership of their gaps. The package and mapping-table version are archived read-only and immutable; linked records are updated; the next refresh is scheduled with its triggers registered; stakeholders are notified; and the acknowledged handoff on this step closes the workflow.\n\n> **⚡ Audit Artist accelerator:** `/coach-workflow-build` instantiates the linked downstream Policy Lifecycle Management and Control Design workflows and `/coach-notify` alerts their owners with the attached package; `/coach-workflow-export` then snapshots the closed run and `/coach-export-package --raw` archives the mapping table and package as retention-governed records.","label":"Handoff to related workflow","performedBy":{"agent":"grc-artist","primitives":["coach-render-package","coach-document-upload","coach-item-update","coach-workflow-build","coach-notify","coach-workflow-export","coach-export-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:grc-framework-adoption-cross-mapping"}