{"description":"Runs on the existing Process item for the one business process under decision — it enriches that Process item and the Control and Risk items in its RCM, never creating a duplicate. Determine whether the process is SOX-relevant and, if so, scope its key controls — otherwise document the exclusion. Consumes the Annual ICFR Scoping & Risk Assessment handoff package (accepted materiality set, scoping thresholds, aggregation floor). Named deliverables: the assessment worksheet, the SOX-relevance determination memo, the resulting Risk & Control Matrix (RCM) scope (Control and Risk items with live links), and the exclusion memo — compiled into a signed scoping decision package. Hands that signed package off to the downstream SOX Process Walkthrough for the in-scope slice, or routes a full exclusion into the annual monitoring/refresh cycle. Out of scope: entity-level materiality, significant accounts, and fraud-risk assessment, which are owned by the upstream Annual ICFR Scoping & Risk Assessment, and process understanding and control verification, which are owned by the downstream SOX Process Walkthrough.","edges":[{"id":"e-sox-relevant-classify-disposition","source":"sox-relevant","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"action_required"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clear"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-08","UC-RISK-11"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-scoping-decision","contentDigest":"sha256:998fa0fa624dc515ce92355a407983ccc609a84b1a5d73bfdd40f6d63f6db11f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:998fa0fa624dc515ce92355a407983ccc609a84b1a5d73bfdd40f6d63f6db11f","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-scoping-decision"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"sox-scoping-decision","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["finance"]},"name":"SOX Scoping Decision","nodes":[{"data":{"description":"Convert the assessment into the documented SOX-relevance determination for this process — relevant, not relevant, or relevant in part with the in-scope slice named — agreed by the accountable approver before any control scoping happens.","instructions":"**Objective**\nConvert the assessment into the documented SOX-relevance determination for this process — relevant, not relevant, or relevant in part with the in-scope slice named — agreed by the accountable approver before any control scoping happens.\n\n**Inputs**\nThe anchor **Process item** this workflow runs on — its `Process.description`, `Process.process_owner`, and `Process.frequency`, plus the narrative/flowchart documents, system inventory, journal-entry sources, and volume metrics attached to it. This is the subject that already exists; the workflow enriches it, it does not create it.\n- The **handoff package** from the upstream Annual ICFR Scoping & Risk Assessment — the accepted materiality set, scoping thresholds, and aggregation floor this decision screens against (a document on that workflow's close/handoff step; re-attach it here for self-containment). The candidate significant-accounts list with assertions and the entity-level fraud-risk-assessment document live inside this package (no Account item type exists — accounts stay in documents).\n- The trial balance by account — by entity where relevant — for the current period plus prior-year comparatives, covering balances and annual activity, not balances alone: a finance-system extract **uploaded (PBC/external) at this step** (XLSX/CSV).\n- The entity-level fraud-risk exposure also carried as **Risk items** in the register (`Risk.category` = financial_reporting, `taxonomies` including financial_reporting).\n- The **service organizations** the process outsources any part of, carried as **Vendor items** in the third-party register (`Vendor.category`, `Vendor.tier`, `Vendor.monitoring_status`), with their available SOC 1 reports attached to those items or **uploaded at this step** (the reports themselves have no native field).\n- Where they already exist for this or adjacent processes: the current **Control items** and **Risk items** (WCGWs) with their `Control ↔ Risk` and `Control ↔ Process` links — the RCM rows this scope extends rather than rebuilds.\n\nThe assessment worksheet: quantitative screen, qualitative scores, fraud-lens result, assertion candidates, dependency inventory.\n- The entity's written **SOX scoping methodology** — the decision rules this determination applies — carried as a **Policy item** (`Policy.policy_type` = procedure or standard, `Policy.policy_owner`, `Policy.framework` including sox + coso-ic), with the methodology document attached to it; the prior-year determination for this process.\n- The external auditor's scoping position for the year, where known.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Assess the process”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Assess the process: Build the evidence base for the relevance call: map the process to the accounts, disclosures, and assertions it can misstate, and score its quantitative significance and qualitative risk so the determination is a reading of evidence rather than an opinion.\n\n2. Map the financial-statement touchpoints: every account and disclosure the process initiates, authorizes, processes, records, or reports — including feeder effects (sub-ledger postings into GL accounts) and any role in the period-end close. List the journal-entry sources the process generates, manual and automated.\n3. Run the quantitative screen per touched account against the entity thresholds — on both the balance and the annual flow through the account. A clearing account with a near-zero balance and nine figures of throughput is significant on flow. Where the methodology gives no bands, use these defaults and say so: at or above planning materiality → presumptively significant; in the judgment band below it → decide on qualitative factors; below the aggregation floor → exclusion candidate pending the aggregation check. Compute the aggregate of all touched accounts as well — the process-level view, not just account-by-account.\n4. Score the qualitative factors (the AS 2201.29 and SEC-guidance list): susceptibility to misstatement through error or fraud; volume, complexity, and homogeneity of transactions; estimates and management judgment (valuations, reserves, impairments); accounting or reporting complexity, including newly adopted standards; related-party exposure; loss and contingency exposure; changes from the prior period; and the history — prior misstatements, audit adjustments, or deficiencies in the touched accounts.\n5. Apply the fraud lens separately: management-override opportunity, revenue recognition (a presumed fraud risk), or custody and movement of cash and assets convertible to cash. A fraud-risk touchpoint can make a quantitatively small process relevant — size does not descope fraud exposure.\n6. Identify the relevant assertions per touched account — existence/occurrence, completeness, accuracy/valuation, cut-off, rights and obligations, presentation — and note how this process could misstate each: the seed what-could-go-wrong list the control-scoping step will expand.\n7. Inventory the dependencies the scope would inherit: applications (ITGC scope implications), key reports the process produces or consumes (IPE — including reports that controls in other processes rely on), service organizations (SOC 1 coverage and complementary user-entity controls), and spreadsheets or EUCs doing computational work.\n\n8. Assessment scope for SOX-relevant?: Convert the assessment into the documented SOX-relevance determination for this process — relevant, not relevant, or relevant in part with the in-scope slice named — agreed by the accountable approver before any control scoping happens.\n\n9. Apply the decision rules in order and record which one fired: (a) any touched account or disclosure is significant and the process could materially misstate one of its relevant assertions → relevant; (b) the process carries a fraud-risk touchpoint or participates in the period-end financial reporting process → relevant regardless of size — under the top-down approach the close process is in scope per se; (c) the process produces key reports that controls in other in-scope processes rely on → at minimum the report-producing slice is relevant; (d) every touchpoint stays below the thresholds after aggregation and no qualitative factor elevates it → not relevant; (e) mixed results → relevant in part, with the in-scope sub-processes, entities, or account slices named precisely — \"partially in scope\" without a boundary is not a determination.\n10. Test the conclusion against the external auditor's view. The auditor scopes independently under AS 2201; management's assessment under the SEC guidance may legitimately differ — but a difference discovered in Q4 costs the testing calendar. Where they diverge, document the difference and schedule the discussion now, before walkthroughs are booked.\n11. Check period-over-period consistency: a flip from last year's conclusion requires the driver named — volume growth, reorganization, threshold movement, new system. A flip supported by \"no change\" impeaches one of the two years' conclusions.\n12. Draft the determination section of the scoping memo: the conclusion, the rule applied, the specific worksheet lines that drive it, and how near-miss considerations were weighed.\n13. Route it to the approver named at the first step and capture their agreement — an approval on this step, or their recorded concurrence in the step's comments. Management owns this call; auditor input informs it but does not make it.\n\n**Record in AssureSwarm**\nAttach the **assessment worksheet** as a document on this step (XLSX): touchpoint map, quantitative screen with figures and trial-balance date, qualitative scoring, assertion analysis, dependency inventory.\n- Link the anchor **Process item** to the touched **Risk items** — `Process ↔ Risk`. Touched accounts have no item type; they stay named in the worksheet document, not as links.\n- Record the headline numbers on the step: largest single-account exposure versus planning materiality, aggregate exposure, fraud-lens result.\n\nRecord the determination, effective date, rule applied, and approver on the step — this is not a decision-form step; the record is the step's approval and comment thread.\n- Attach the **determination memo section** as a document on this step (DOCX/PDF); link the archived prior-year run's memo where a delta exists.\n- Capture the approver's agreement (step approval or comment thread).\n\n**Exit criteria**\nEvery touched account has a quantitative result against stated thresholds, on balance and flow; qualitative factors are scored with evidence, not adjectives; the relevant-assertion candidates and dependency inventory are complete; the worksheet cites its sources so the screen is reperformable. Determination recorded with the approver's agreement captured; the conclusion traces to named worksheet evidence; any relevant-in-part boundary is named precisely; prior-year deltas carry their drivers; the auditor-alignment position is stated.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` recomputes the quantitative screen — balances and flows against thresholds, aggregation totals — deterministically, so the significance math is re-runnable rather than hand-checked.","label":"SOX-relevant?","performedBy":{"note":"","primitives":["coach-query-data","coach-document-upload","coach-items-link","sox-python"]}},"id":"sox-relevant"},{"data":{"decisionField":"disposition_path","description":"Classify how the scoping decision landed so exactly one closure path remains: straight to the final package when everything is complete and agreed, or through an owned action plan when open work exists. The SOX PMO lead owns the call.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Ready to close","value":"clear"},{"label":"Action required","value":"action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nClassify how the scoping decision landed so exactly one closure path remains: straight to the final package when everything is complete and agreed, or through an owned action plan when open work exists. The SOX PMO lead owns the call.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe determination — and its boundary, for a relevant-in-part conclusion.\n- The assessment worksheet's assertion candidates, what-could-go-wrong seeds, and dependency inventory.\n- Existing RCM rows for this and adjacent processes; process narratives; the control inventory; SOC 1 reports for outsourced slices.\n\nThe determination and the assessment worksheet — the quantitative figures do the heavy lifting here.\n- The entity's scoping thresholds and aggregation floor.\n- Prior-year exclusion memos for this process or its accounts; the auditor-alignment notes.\n\n*Agent retrieval, preparation and filing absorb “Scope the controls”, “Document the exclusion”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Scope the controls: For the slice determined relevant, land the top-down control scope: expand what could go wrong per relevant assertion and designate the key controls that address each one, with their dependencies, so walkthrough and testing inherit a complete RCM instead of rebuilding it.\n\n2. If the determination was not relevant, record on this step that no controls enter scope and continue — the parallel Document the exclusion checkpoint carries the exclusion documentation.\n3. Expand the what-could-go-wrongs: for each relevant assertion, walk the process at the level of hand-offs, calculations, judgments, system interfaces, and recording points, asking what could go wrong for that assertion (completeness of revenue → shipments that never invoice; accuracy of payroll → stale master-data rates). Every relevant assertion ends with at least one WCGW or an explicit \"no plausible source of material misstatement\" note.\n4. Designate key controls per WCGW. Key means: if this control failed, a material misstatement could occur and nothing else in scope would reasonably prevent or detect it. Prefer precise controls over broad reviews, and automated controls over manual ones for repetitive matching and calculation. For management review controls, capture precision now — the threshold the reviewer investigates at and the evidence follow-up leaves — because MRC precision is where auditors push hardest.\n5. Classify each key control: preventive or detective; manual, automated, or IT-dependent manual; frequency; owner and performer; and the COSO component and principle it supports.\n6. Map dependencies onto the scope: applications behind automated controls → ITGC scope additions; the key reports each control consumes → the IPE inventory; outsourced steps → SOC 1 coverage check plus complementary user-entity controls mapped to named internal controls; spreadsheets doing control work → EUC controls.\n7. Gap-check: a relevant assertion with no key control is a design gap. Log it as a candidate deficiency and action item feeding the disposition decision — do not paper over it by promoting a non-key control.\n8. Rationalize: where two key controls cover the same WCGW with no distinct risk, flag one for de-designation. Over-scoping is a permanent tax — every key control implies a walkthrough and TOD/TOE every year thereafter.\n\n9. Assessment scope for Document the exclusion: Produce exclusion documentation that survives external-auditor and PCAOB-inspection scrutiny for everything this decision leaves out of scope — the whole process, or the excluded remainder around an in-scope slice.\n\n10. Enumerate every exclusion this decision creates: the whole process (a not-relevant determination), out-of-scope sub-processes or entities (relevant in part), accounts screened out on the quantitative screen, assertions judged not relevant, and any control de-designated from key. If everything was scoped in and nothing excluded, record \"no exclusions\" explicitly — silence is not a record.\n11. Support each exclusion twice. Quantitatively: the balance and flow figures against the stated threshold, with the trial-balance date. Qualitatively: which AS 2201.29 and SEC-guidance factors were considered and why none elevates the item. \"Immaterial\" without figures is an assertion, not documentation.\n12. Run the aggregation test: sum the excluded accounts that flow through this process and compare the total to the aggregation floor. Individually small exclusions that aggregate above the threshold is the classic inspection finding — if the aggregate breaches, something comes back into scope and the determination must be revisited before proceeding.\n13. Apply the override check: confirm nothing excluded carries a fraud-risk touchpoint, a related-party flow, or a period-end close role. Those attributes do not descope on size.\n14. Set re-evaluation triggers per exclusion: the conditions that void it — volume growth past a stated level, a new system, reorganization, a misstatement or audit adjustment in the account — plus the standing re-affirmation in every annual scoping refresh.\n15. State the auditor position per exclusion: aligned, to be discussed, or a known difference with its handling plan.\n\n16. Assessment scope for Classify disposition: Classify how the scoping decision landed so exactly one closure path remains: straight to the final package when everything is complete and agreed, or through an owned action plan when open work exists. The SOX PMO lead owns the call.\n\n\n\nVerify four things before branching: the determination is approved; the RCM reflects the scope with links live; the exclusion memo is complete with the aggregation test passed; and the auditor-alignment position is stated.\n\n- **clear** (Ready to close) — determination approved with no pending dissent; every relevant assertion has a designated key control with no design gaps logged; RCM items and links updated and confirmed by their owners; the exclusion memo complete with figures and the aggregation result; auditor alignment confirmed or no reliance difference outstanding; nothing waiting on promised data. Clear means no scoping work remains for anyone — a pending RCM confirmation disqualifies this branch.\n- **action_required** (Action required) — any of: design gaps logged at control scoping (a relevant assertion without a key control); RCM updates pending owner confirmation; an unresolved scoping difference with the external auditor; an exclusion resting on data promised but not delivered (an entity trial balance, a volume report); a relevant-in-part boundary still imprecise; or approvals outstanding. Name each open item in the rationale with its evidence reference — the action plan is built from that list, item for item.\n\n**Record in AssureSwarm**\nCreate or enrich **Control items** and **Risk items** (WCGWs); link `Control ↔ Risk`, `Control ↔ Process`, and `Risk ↔ Process`. Assertions and accounts have no item type — they stay named in the RCM extract, not as links.\n- Set on each Control item: `key_control` (true/false), `control_type` (preventive/detective), `automation` (automated/manual/hybrid), `frequency`, `control_owner`, and `framework` (including sox + coso-ic); set `Risk.category` = financial_reporting on each WCGW. ITGC, IPE, and SOC 1 dependencies have no native field — capture them in the RCM extract document on this step.\n- Attach the **RCM extract** as a document on this step. Log each design gap as an **Issue item** (`issue_type` = deficiency, `source` = management_identified, `issue_owner`, `target_remediation_date`), linked to the relevant Control/Risk/Process items and to this workflow.\n\nAttach the **exclusion memo** as a document on this step (DOCX/PDF) with figures, factors, and the aggregation computation.\n- Link the excluded **Process** and **Risk items**; excluded accounts have no item type (they stay in the memo). There is no native watchlist construct — record the re-evaluation triggers as text on this step and on the excluded items so the annual refresh re-reads them.\n- Record the re-evaluation triggers and the auditor position on the step — or the explicit no-exclusions note.\n\nSubmit this step's form: `disposition_path` = the chosen branch; the step result = the named open items (or the affirmed clean checks) with evidence references; the step's approver record = who made the call.\n\n**Exit criteria**\nEvery relevant assertion carries at least one key control or a logged design gap; every key control is classified with owner, frequency, and dependencies; the RCM links live in AssureSwarm; redundancy candidates are dispositioned — or, for a not-relevant determination, the no-controls note is recorded. Every exclusion carries figures, qualitative factors, and an aggregation result below the floor (or was pulled back into scope); re-evaluation triggers are set; the auditor position is stated; the memo is attached — or the explicit no-exclusions record exists. Form submitted; every open item named or all four checks affirmed; the unused branch is prunable because the recorded value matches one branch edge.","kind":"decision","label":"Classify disposition","performedBy":{"note":"","primitives":["coach-item-create","coach-item-update","coach-items-link","coach-document-upload"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every open item from the disposition into an owned, dated action with interim risk cover defined, so the scoping decision can close while remediation runs on its own tracked cadence.\n\n**Inputs**\n- The disposition rationale's open-item list.\n- The design-gap action items and the control and risk records from the control-scoping step.\n- Process-owner and SOX PMO contacts; the testing-cycle calendar.\n\n**Procedure**\n1. For each design gap — a relevant assertion with no key control — identify the root cause: the control never existed, exists but was never documented, or recently broke (departed performer, decommissioned report). The remediation owner sits in the business, not the SOX PMO; the PMO tracks, the process owner fixes.\n2. Set the due date against the assessment calendar: a new control needs enough operating runway before period end to be tested for operating effectiveness — a control implemented in December cannot demonstrate a year of operation. Where the runway is already gone, say so, and note that the gap likely lands as a deficiency to evaluate at year end regardless of remediation speed.\n3. Define interim mitigation per gap: the compensating or monitoring cover that limits exposure while remediation runs — or the explicit statement that none exists, which itself feeds the deficiency evaluation.\n4. For non-gap items — pending RCM confirmations, the auditor-alignment discussion, promised data — assign an owner, a due date, and the specific artifact that closes the item: confirmed RCM rows, a documented meeting outcome, the delivered trial balance.\n5. Pre-define validation evidence per action — what proves it done — so closure is verifiable rather than declared.\n6. Set the reporting cadence: where progress is reviewed (the SOX status dashboard or meeting) and the escalation path when a due date slips.\n\n**Record in AssureSwarm**\n- Create one **Issue item** per open item (no generic Task/Action type exists): `issue_type` = deficiency for design gaps, observation for administrative items (pending RCM confirmation, auditor meeting); set `issue_owner` and `target_remediation_date`, and carry the interim mitigation and validation evidence in `remediation_plan` (there are no dedicated mitigation/validation-evidence fields). Link each to the relevant Control/Risk/Process items and to this workflow.\n- Record the cadence and escalation path on the step.\n\n**Exit criteria** — Every disposition open item exists as an action with a named owner, due date, and defined validation evidence; each design gap carries a stated interim risk position; cadence and escalation are recorded. Actions need not be complete — they run on their cadence after this workflow closes.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Put the decided scope into motion — hand the package to SOX Process Walkthrough for the in-scope slice, or route a full exclusion into the monitoring cycle, with what downstream must not repeat and must verify stated explicitly — and close the workflow on that acknowledgment with the signed package preserved and the position propagated.","instructions":"**Objective**\nPut the decided scope into motion — hand the package to SOX Process Walkthrough for the in-scope slice, or route a full exclusion into the monitoring cycle, with what downstream must not repeat and must verify stated explicitly — and close the workflow on that acknowledgment with the signed package preserved and the position propagated.\n\n**Inputs**\nThe assessment worksheet, determination memo section, RCM extract and links, exclusion memo, action plan, and the disposition decision-form rationale.\n- The upstream baseline from the Annual ICFR Scoping & Risk Assessment handoff package: materiality set, version, date.\n\nThe signed final package and walkthrough annex.\n- The walkthrough calendar and owner; the RCM links created at control scoping.\n- The action plan and its cadence, for items downstream will surface evidence on.\n- The records-retention schedule — SOX assessment evidence is commonly retained seven years by policy, aligned to the auditor workpaper retention rules.\n- The closure distribution list: process owner, SOX PMO, audit liaison.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare final package: Compile the decision-grade package a reviewer, successor, or auditor can consume standalone: the determination, the evidence behind it, the resulting control scope and exclusions, and where every artifact lives.\n\n2. Assemble the scoping decision memo as the spine: process and boundary; trigger; the upstream baseline used; the determination, rule applied, and approver; the control-scope summary — key-control count by type (preventive/detective, automated/manual/IT-dependent manual, MRCs) plus ITGC, IPE, and SOC 1 dependencies; exclusions with the aggregation result; and open actions with owners and dates.\n3. Cross-check internal consistency: memo figures tie to the worksheet; every control the memo claims exists as a linked RCM row; every exclusion in the memo appears in the exclusion memo; the decision-form values match the memo's conclusion. Fix discrepancies at the source record and regenerate — never by editing the memo alone.\n4. Apply the reperformability test: a new reviewer must be able to redo the quantitative screen from the package alone — sources cited (trial-balance date, forecast version, threshold provenance), sign-offs present, and the assumptions and caveats from the acceptance step carried forward.\n5. Stage the walkthrough handoff annex: the in-scope control list with owners and frequencies, the IPE inventory, the WCGW list, and the known as-performed uncertainties the walkthrough must verify on the ground. State in the annex the field mapping for standing up **Control-hosted SOX testing workflows** (template metadata kind sox-testing, one per key control per fiscal year) at walkthrough/testing kickoff — record the scoping rationale on each workflow's setup/scoping step when that Control-hosted workflow is created.\n6. Route the assembled package to the decision owner for final sign-off — they approved the determination; this signature covers the package as a whole.\n\n7. Assessment scope for Handoff to related workflow: Put the decided scope into motion — hand the package to SOX Process Walkthrough for the in-scope slice, or route a full exclusion into the monitoring cycle, with what downstream must not repeat and must verify stated explicitly — and close the workflow on that acknowledgment with the signed package preserved and the position propagated.\n\n8. Where controls entered scope: create or link a SOX Process Walkthrough workflow for each in-scope process or sub-process, attach or link the package and annex, and assign it to the walkthrough owner with the date the testing calendar requires it done by.\n9. State what the walkthrough must not repeat: the significance math, account mapping, and threshold rationale are decided — the walkthrough verifies operation; it does not re-litigate scope. State what it must verify: the as-performed control descriptions against the RCM text, the completeness of the IPE inventory, and WCGW coverage at ground level. A walkthrough that finds an unmapped hand-off feeds a scope addendum, not a silent fix.\n10. Transfer the open items downstream will encounter: action-plan items whose evidence the walkthrough will surface, and boundary notes for relevant-in-part scopes.\n11. Where the whole process was excluded: no walkthrough is created. Instead confirm the exclusion sits on the annual scoping refresh's re-affirmation list, the excluded items are on the watchlist with their triggers, and the process owner and audit liaison are notified of the final position.\n12. Capture acknowledgment: the downstream owner confirms receipt — a comment on this step, or acceptance recorded in the downstream workflow. An unacknowledged handoff is not a handoff, and it is this acknowledgment (or the routed exclusion) that closes the workflow.\n13. Confirm the workflow is closable: package signed; the disposition path completed — either clear, or every open item exists as an owned action on its cadence (open actions do not block closure; unowned ones do).\n14. Export the workflow record and archive it with the package in the designated evidence repository under retention controls; record the archive location and reference identifier; verify retrievability by opening the archived copy, not by trusting the upload confirmation. Post-archive corrections are new dated addenda, never edits to the archived package.\n15. Propagate the position: control and risk items carry the final in-scope designations and links; the process item shows the scoping status, decision date, and memo reference; excluded items show their re-evaluation triggers.\n16. Seed the future and communicate: create the carry-forward item for the next annual scoping refresh to re-affirm this determination (owner: SOX PMO, due at the next cycle); confirm action-plan monitoring continues on its stated cadence with owners intact and the exclusion-trigger watchlist is live; send the final position to the process owner, the SOX PMO, and — per the engagement protocol — the external audit liaison.\n\n**Record in AssureSwarm**\nAttach the compiled package and link every component document to this step.\n- Record the sign-off (approver, date) and any unresolved constraints carried into the handoff.\n\nLink the downstream walkthrough workflow(s), or record the exclusion routing: refresh list, watchlist, notification.\n- Record the assignee, due date, the do-not-repeat and must-verify lists, the transferred open items, and the acknowledgment on this step.\n- Attach the closure record with the archive location and reference as a document on this step, and record the distribution.\n- Note the final scoping position in `Process.description` (in scope / out of scope / in part) with the decision date and memo reference — Process has no dedicated scoping-status field; finalize `key_control` on the in-scope Control items.\n- Create the refresh carry-forward as an **Issue item** (`issue_type` = observation, `source` = self_assessment, `issue_owner` = SOX PMO, `target_remediation_date` = next scoping cycle), linked to the Process item — there is no native Task type.\n\n**Exit criteria**\nPackage attached and signed; internal cross-checks pass; the quantitative screen is reperformable from citations alone; the walkthrough annex is staged. Downstream workflow linked, assigned, and acknowledged with the package — or the exclusion is routed to monitoring with stakeholders notified; the do-not-repeat and must-verify lists are recorded; transferred items keep their owners; the archived package is verified retrievable with its reference recorded; the RCM and process item reflect the final position; the refresh carry-forward exists with owner and due date; the closure position is communicated. Open actions remain permitted — they are tracked on their own cadence.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the package from the linked AssureSwarm records and flags memo claims that lack a backing record, making the consistency check mechanical.","label":"Handoff to related workflow","performedBy":{"note":"","primitives":["coach-workflow-export","coach-item-create","coach-item-update","coach-document-upload","coach-render-package"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-scoping-decision"}