{"description":"Runs on the fiscal year’s existing SOX Audit, using financial balances, prior-year RCM and deficiency history, business changes, and the approved IA plan. Produces the Fiscal Year Audit Scope Memo, Risk & Control Matrix, approved workplan, kickoff records and recipient-specific annual communications for process walkthroughs and control testing.","edges":[{"id":"e-confirm-auditor-reliance-strategy-lock-executable-workplan","source":"confirm-auditor-reliance-strategy","target":"lock-executable-workplan"},{"id":"e-calculate-materiality-map-accounts-to-processes","source":"calculate-materiality","target":"map-accounts-to-processes"},{"id":"e-map-accounts-to-processes-select-key-controls-and-itgcs","source":"map-accounts-to-processes","target":"select-key-controls-and-itgcs"},{"id":"e-select-key-controls-and-itgcs-obtain-scoping-concurrence","source":"select-key-controls-and-itgcs","target":"obtain-scoping-concurrence"},{"id":"e-lock-executable-workplan-obtain-scoping-concurrence","source":"lock-executable-workplan","target":"obtain-scoping-concurrence"},{"id":"e-obtain-scoping-concurrence-publish-rcm","source":"obtain-scoping-concurrence","target":"publish-rcm"},{"id":"e-publish-rcm-classify-disposition","source":"publish-rcm","target":"classify-disposition"},{"id":"e-classify-disposition-approve-or-revise-package","label":"Clear","source":"classify-disposition","target":"approve-or-revise-package","whenValue":"clean"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"escalate"},{"id":"e-create-action-plan-approve-or-revise-package","source":"create-action-plan","target":"approve-or-revise-package"},{"id":"e-escalate-or-accept-risk-approve-or-revise-package","source":"escalate-or-accept-risk","target":"approve-or-revise-package"},{"id":"e-approve-or-revise-package-resolve-approval-conditions","label":"Revise","source":"approve-or-revise-package","target":"resolve-approval-conditions","whenValue":"revise"},{"id":"e-approve-or-revise-package-handoff-to-related-workflow","label":"Approved","source":"approve-or-revise-package","target":"handoff-to-related-workflow","whenValue":"approved"},{"id":"e-resolve-approval-conditions-handoff-to-related-workflow","source":"resolve-approval-conditions","target":"handoff-to-related-workflow"}],"isPublic":true,"itemTypeSlug":"audit","metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-06","UC-RISK-07","UC-RISK-12","UC-ACCESS-15"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-annual-icfr-scoping-risk-assessment","contentDigest":"sha256:720fdf4885654c51fb5721af67579fe7802d3bcf7a01e685870295affd52d58e","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:720fdf4885654c51fb5721af67579fe7802d3bcf7a01e685870295affd52d58e","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-annual-icfr-scoping-risk-assessment"},"lifecycleContract":{"absorbedNodeIds":{"freeze-scoping-baseline-for-walkthrough-and-testing-waves":"approve-or-revise-package","prepare-final-package":"approve-or-revise-package","record-approval-decision":"handoff-to-related-workflow"},"approvalPolicy":"Independent reviewers cannot be the preparer, tester or control owner for the reviewed work. Required approval counts alone do not establish actor independence; verify assignments and exact versions at execution.","bindingRequirements":["Resolve named human roles to actual users and configure native step approvals before execution.","Workstream and Narrative Module are tenant communication/document destinations; verify a supported connector or record manual dispatch by the authorized sender.","EY is the tenant-bound external auditor; preserve its independent methodology and reliance judgments."],"bindingStatus":"requires-tenant-configuration","checkpoints":[{"contribution":"Agree reliance and methodology responsibilities, including unresolved auditor judgments.","interventions":["expertise","variance"],"nodeId":"confirm-auditor-reliance-strategy","requiredApprovals":1,"role":"IA/SOX lead with external-auditor counterpart"},{"contribution":"Commit capacity, independent assignments, methodology and achievable dates.","interventions":["approval","expertise"],"nodeId":"lock-executable-workplan","requiredApprovals":1,"role":"IA/SOX testing lead"},{"contribution":"Approve materiality and qualitative scope judgments against the financial balances.","interventions":["expertise","approval"],"nodeId":"calculate-materiality","requiredApprovals":1,"role":"Controller or CFO"},{"contribution":"Challenge account/assertion/process coverage and identified misstatement mechanisms.","interventions":["expertise"],"nodeId":"map-accounts-to-processes","requiredApprovals":1,"role":"Financial-reporting risk specialist"},{"contribution":"Judge control precision, IT dependencies and fraud-risk coverage.","interventions":["expertise","variance"],"nodeId":"select-key-controls-and-itgcs","requiredApprovals":1,"role":"SOX lead and IT audit specialist"},{"contribution":"Approve the versioned scope memo and resolve scope objections.","interventions":["approval"],"nodeId":"obtain-scoping-concurrence","requiredApprovals":1,"role":"Accountable management and IA scope approver"},{"contribution":"Resolve missing risk/control pairs before the RCM drives fieldwork.","interventions":["expertise"],"nodeId":"publish-rcm","requiredApprovals":1,"role":"SOX scope reviewer"},{"contribution":"Choose the supported clean, remediation or escalation disposition; no adverse evidence is hidden.","interventions":["expertise","variance"],"nodeId":"classify-disposition","requiredApprovals":1,"role":"Accountable IA/SOX lead"},{"contribution":"Commit corrective actions, resources, deadlines and acceptance evidence.","interventions":["approval"],"nodeId":"create-action-plan","requiredApprovals":1,"role":"Accountable remediation owner"},{"contribution":"Decide the bounded exposure and follow-up obligations within delegated authority.","interventions":["approval"],"nodeId":"escalate-or-accept-risk","requiredApprovals":1,"role":"Authorized risk acceptance or escalation authority"},{"contribution":"Approve the supported conclusion and package or require specified revisions.","interventions":["approval","expertise"],"nodeId":"approve-or-revise-package","requiredApprovals":1,"role":"Independent IA/SOX package approver"},{"contribution":"Judge evidence resolving each requested revision before reapproval.","interventions":["expertise","approval"],"nodeId":"resolve-approval-conditions","requiredApprovals":1,"role":"Original independent package approver"},{"contribution":"Resolve residual caveats and accept the next phase’s commitments, required coverage and dates.","interventions":["approval","expertise"],"nodeId":"handoff-to-related-workflow","requiredApprovals":1,"role":"IA/SOX accountable lead and receiving owner"}],"version":1},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"sox-annual-icfr-scoping-risk-assessment","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["finance"]},"name":"Annual ICFR Scoping & Risk Assessment","nodes":[{"data":{"description":"Build the prior-year RCM and deficiency baseline, then confirm the external auditor's reliance strategy","instructions":"**Objective** — Reconcile the prior RCM and deficiencies to current controls and agree the external auditor’s reliance, evidence standard and timing.\n\n**Human contribution** — IA/SOX lead with external-auditor counterpart (expertise, variance): Agree reliance and methodology responsibilities, including unresolved auditor judgments. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The anchor engagement: the fiscal year's already-open SOX Audit item (Audit, audit_type=sox_testing, period_start/period_end = the fiscal year). Every artifact this workflow produces enriches and links back to it.\n- The prior-year RCM: the published workbook, uploaded to this step (typically retrieved from last year's archived instance), plus the underlying Control items in AssureSwarm (control_id, description, control_owner, frequency, control_type, automation, key_control).\n- The deficiency register: the prior-year Issue items (issue_type deficiency, significant_deficiency, or material_weakness; source sox_testing or external_audit; target_remediation_date and actual_remediation_date) — every control deficiency, significant deficiency, and material weakness from prior-year management testing and the external audit, with remediation status.\n- Prior-year test results by control: the prior-FY Control-hosted SOX testing workflows (cycle from Workflow.customFields.sox.fiscalYear, with tester assignment and Test-step conclusion), each hosted directly on its Control — pass or fail, exception counts, sample sizes.\n- The organizational and system change log since the prior assessment date, uploaded to this step.\n- The external auditor's planning communications: identified risk areas, inspection-driven focus topics, and requested timing.\n- The SOX team's competence-and-objectivity documentation — the auditor's basis for using management's work.\n- Preliminary views on materiality and significant accounts (finalized in later steps).\n\n**Procedure**\n1. Pull the prior-year RCM and reconcile it to the live control library: controls added, retired, or re-owned since publication. A control whose owner left and was never reassigned is a scoping flag, not a bookkeeping fix.\n2. Build the deficiency picture: for each open or recently remediated deficiency, capture the affected account and assertion, severity classification, remediation status, and whether the remediated control has operated long enough to be tested this year — a control remediated in Q4 typically cannot show a sufficient operating period for the current assessment.\n3. Flag carry-forward scope pressure: an unremediated significant deficiency forces its accounts in-scope regardless of the quantitative screen to come; areas with repeated exceptions warrant expanded samples or earlier test timing, and both belong in the workplan step's inputs.\n4. Assemble the reliance history: which controls the external auditor relied on management's testing for last year, and where reliance was withdrawn or reduced — those areas need stronger evidence this year, and the negotiation below opens with that list.\n5. Summarize into a prior-year baseline memo: control counts by process, a deficiency roll-forward table (opened, remediated, still open), and the specific accounts and processes where history alone forces scope.\n6. Meet the external auditor before scope is locked, with the baseline memo in hand. Confirm the reliance model per process area: full reliance on management testing, re-performance of a sample of management's work, or auditor-performed testing. Expect little or no reliance in higher-risk and judgmental areas — revenue, significant estimates, management override — and plan management's own coverage there accordingly.\n7. Capture the evidence bar wherever reliance is planned: sample-size conventions, workpaper standards, IPE completeness-and-accuracy documentation, tester independence from the control performer, and roll-forward expectations — interim testing is typically bridged to year-end by roll-forward or update procedures, and the auditor's tolerance for the interim-to-year-end gap drives test timing.\n8. Agree the calendar: when interim testing must complete, when the auditor reviews management's workpapers, and what update procedures cover fourth-quarter changes.\n9. Record disagreements honestly: where the auditor will not rely in an area management planned to lean on, the workplan must absorb the auditor's own testing footprint — PBC volume, walkthrough attendance, and management time.\n10. Write the reliance strategy memo: per-process reliance level, evidence bar, timing commitments, and named auditor contacts. Items the auditor has not yet confirmed are listed as open with a follow-up date, not assumed.\n\n11. Hold the preliminary planning session with the external auditor and IA leadership before the annual plan is locked. Record the agenda, attendees by role, planning assumptions, disagreements, and action owners with due dates in the reliance memo. EY is a tenant binding for the external auditor; obtain the current firm and engagement contacts from the engagement record.\n12. Agree the fiscal-year methodology, scope, responsibilities and timeline for controls work, substantive procedures, and year-end efforts with the external auditor. Record separate substantive-work coverage, evidence dependencies and auditor-owned judgments; management’s testing agreement cannot approve the auditor’s opinion or replace the auditor’s own methodology. Carry unconfirmed points as open dependencies.\n\n**Record in AssureSwarm**\n- Attach the prior-year RCM, the baseline memo, and the reliance strategy memo (document upload).\n- Link the open deficiency items to this workflow and record the roll-forward status of each prior-year deficiency on this step.\n- Record per-process reliance levels and timing commitments in this step’s result.\n- Note open items awaiting auditor confirmation, each with a follow-up date.\n\n**Exit criteria** — Baseline and reliance memos reconcile the prior RCM, control library and deficiency dispositions; each process has an evidence bar, timing commitments or dated open questions for the SOX PMO.","label":"Confirm auditor reliance strategy","requiredApprovals":1},"id":"confirm-auditor-reliance-strategy"},{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Freeze the season's execution plan — who scopes, walks through, and tests what, by when, to what evidence standard — so the downstream waves start from commitments instead of intentions.\n\n**Human contribution** — IA/SOX testing lead (approval, expertise): Commit capacity, independent assignments, methodology and achievable dates. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The current-year change inventory: new entities, systems, and revenue streams entering scope this year, so the plan covers them deliberately.\n- The reliance strategy memo: timing commitments and evidence bars.\n- The prior-year baseline memo and deficiency roll-forward.\n- Team capacity: testers and reviewers, with the independence constraint that no one tests a control they perform or own.\n\n**Procedure**\n1. Hold an internal IA team planning session with the CAE or IA manager, SOX program lead, process leads and testing/review leads. Review prior-year findings, changes, risk coverage, independence and available capacity; record the agenda, named participants, scope challenges, decisions, assigned actions and dates.\n2. Draft the annual IA plan, scope, milestones and team capacity from that session and the approved audit-plan/resource package from audit-annual-internal-audit-planning-resource-management. Reconcile people-days by skill and review role to the SOX workplan; bring unresolved coverage or resource shortages to the CAE before committing dates.\n\n3. Sequence the waves backward from the filing calendar: scoping concurrence, walkthroughs, interim TOD/TOE testing, the remediation window, roll-forward and update testing, year-end conclusion. Preserve a real remediation window — commonly 60–90 days before year-end — because a plan with no time to fix what testing finds is a plan to report deficiencies.\n4. Assign owners and due dates per process: scoping analyst, walkthrough lead, tester, reviewer. Enforce independence structurally: the tester is never the control performer, and the reviewer is never the tester.\n5. Set the evidence conventions once, for everyone: the workpaper template, the IPE completeness-and-accuracy documentation standard, sampling conventions by control frequency, and where deliverables live in AssureSwarm so the external auditor's review finds one canonical set.\n6. Encode the review gates: what a reviewer checks before a scoping conclusion or test result is final, and the escalation path when a gate fails.\n7. Publish the workplan and brief the owners. Capture each named owner's acceptance — an unacknowledged assignment is not a commitment, and it is the assignments nobody acknowledged that slip.\n\n**Record in AssureSwarm**\n- Attach the locked workplan (document upload).\n- Record wave dates, per-process owners, and the evidence conventions on this step.\n- Link the reliance memo and the prior-year baseline memo.\n\n**Exit criteria** — Every in-scope process has a named scoping analyst, tester, reviewer, and due dates; independence conflicts resolved; the remediation window is preserved in the calendar; owner acknowledgments recorded.","label":"Lock executable workplan","requiredApprovals":1},"id":"lock-executable-workplan"},{"data":{"description":"Complete Calculate materiality","instructions":"**Objective** — Set the SOX materiality threshold, screen every financial-statement line item (FSLI) for quantitative in-scope status, overlay the qualitative significance judgment, record the resulting scope on the SOX audit, and tag the SOX-relevant controls for the year being scoped.\n\n**Human contribution** — Controller or CFO (expertise, approval): Approve materiality and qualitative scope judgments against the financial balances. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The fiscal year being scoped.\n- The customer's financials workbook: P/L and balance-sheet line items with prior-year, current-year, and forecast values.\n- The materiality percentage (default 5%) and its base — pre-tax income, revenue, or total assets.\n- The anchor SOX Audit item this scope attaches to: the already-open Audit whose audit_type is sox_testing for the year (drafting one is only a fallback if none was opened).\n- The population of Control items that could be relevant (the live control library).\n\n**Procedure**\n1. Compute the quantitative screen. The contract is deterministic: derive the materiality threshold as the chosen percentage times the base value (threshold = pct × base), and mark an FSLI quantitatively in-scope when its absolute value meets or exceeds the threshold in any of the three years — prior, current, or forecast. Record the driving value and year per FSLI so the basis is reproducible. This mechanical computation and the per-FSLI scope workpaper are produced by the materiality and scope-workpaper engine; capture its output as the starting point.\n2. Know the workpaper's fixed layout — one row per FSLI: FSLI name; prior, current, and forecast values; threshold; quant-in-scope (yes or no, computed by the screen); qual-in-scope (yes or no, left blank for this step's overlay); final scope conclusion (in or out, left blank for the overlay); a tickmark column left blank for the operator; and basis-for-decision, prefilled with the quantitative basis (driving value versus threshold and the year), to which the overlay appends any qualitative flags.\n3. Apply the qualitative overlay. For every FSLI the quantitative screen did not already pull in-scope, evaluate four qualitative flags: significant or unusual transactions run through the account; the account is a regulator focus area; the account is fraud-prone; a material change in the underlying process or system occurred this year. Any single flag that applies flips the FSLI to in-scope on qualitative grounds. Confirm each flag with the responsible owner rather than assuming it.\n4. Write the basis for each decision: driving value versus threshold for quantitative calls, and the specific flag triggered for qualitative ones. Complete the qual-in-scope and final-conclusion columns accordingly.\n5. Roll the decisions into a scope memo. Compile the FSLI list (values, threshold, quantitative and qualitative in-or-out flags, final conclusion, and basis) into a markdown scope memo and record it on the anchor Audit item's scope field (Audit.scope) so the conclusion lives with the engagement for the year — this enriches the existing SOX Audit, it does not create one. Cite the governing Sarbanes-Oxley Act Section 404 and Section 302 authorities in the memo text itself, since there is no authority-source item type to link. Fallback only: if no SOX Audit was opened for the year, draft one first (audit_type sox_testing, status PLANNED, period_start/period_end = the fiscal year) and record the memo on its scope field.\n6. Tag the SOX-relevant controls. For each in-scope FSLI, find the Control items that address that account (by title or slug), confirm them with the control owner, and mark each in SOX scope: set its key_control to true and include sox in its framework list. Set Control.sox_applicable to the literal boolean true for applicable controls; key_control and framework tags do not substitute for this field. Perform these as Control item updates after scope approval. Link each tagged Control to the anchor Audit (Control ↔ Audit relationship) so the audit carries its in-scope control set.\n7. Attach the per-FSLI scope workpaper the engine produced to the SOX audit item as supporting evidence, leaving its tickmark column blank for the operator to sign.\n8. Human checkpoint: before finalizing, the accountable owner (SOX PMO or control owner) reviews the FSLI in-or-out conclusions, the qualitative flags applied, and the list of controls tagged SOX-relevant, and signs the scope workpaper. Do not tag controls or publish the scope memo without that concurrence.\n\n**Record in AssureSwarm**\n- The materiality threshold and its base — recorded in this step’s result.\n- The per-FSLI quantitative and qualitative decisions with their basis — carried in the scope workpaper (there is no FSLI item type, so the per-line screen lives only in the workpaper XLSX and the scope memo).\n- The scope memo on the anchor Audit item's scope field (Audit.scope).\n- The controls tagged in scope — each selected Control item updated to key_control=true with sox added to its framework list — and linked to the anchor Audit (Control ↔ Audit relationship).\n- The attached, owner-signed scope workpaper (step document, XLSX), linked to the anchor Audit.\n\n**Exit criteria** — Signed scope workpaper supports a reproducible quantitative and qualitative screen, every selected Control traces to an in-scope FSLI, and Audit.scope records the memo and governing Sections 404/302 authorities.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` runs the deterministic materiality math — the threshold, the three-year absolute-value screen per FSLI, and the scope-workpaper xlsx emission — with source, output, and exit code captured in a Procedure tab so the screen is reproducible.","label":"Calculate materiality","performedBy":{"agent":"sox-artist","note":"materiality + scope-workpaper engine","primitives":["coach-query-data","coach-item-create","coach-document-upload","coach-item-update","coach-items-link","sox-python"]},"requiredApprovals":1},"id":"calculate-materiality"},{"data":{"description":"Map in-scope accounts to processes/systems and identify the risks of material misstatement","instructions":"**Objective** — Map in-scope financial-statement line items (FSLIs) to processes, transaction streams, systems and assertion-level risks of material misstatement (RMMs).\n\n**Human contribution** — Financial-reporting risk specialist (expertise): Challenge account/assertion/process coverage and identified misstatement mechanisms. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The signed scope workpaper and scope memo: the in-scope FSLI list with basis.\n- The process inventory: order-to-cash, procure-to-pay, hire-to-retire, record-to-report, inventory and cost, treasury, tax, and the financial close.\n- The application inventory: which systems initiate, record, process, and report each transaction stream, including interfaces and end-user computing (EUC) tools.\n- Prior-year process narratives and account-to-process mapping, where they exist.\n- The deficiency history baseline: where misstatements and control failures actually occurred.\n- The current-year change inventory: new systems, newly adopted accounting standards, new transaction types.\n- The fraud considerations that the fraud-risk work will formalize (revenue recognition, management override) — seeded here, deepened during control selection.\n\n**Procedure**\n*Account-to-process mapping*\n1. For each in-scope FSLI, identify every transaction stream feeding it and type each one: routine (recurring, systematic), non-routine (period-end, unusual), or estimation (judgment-driven — reserves, impairments, fair values). The type matters: estimation streams carry higher inherent risk and different control expectations than routine processing.\n2. Map each stream end to end through the process and the applications that carry it: initiation, authorization, recording, processing, reporting — including interfaces between systems and any spreadsheet or EUC step in the chain. An FSLI produced partly in an unmanaged spreadsheet is a scoping fact, not a footnote.\n3. Assign the relevant assertions per FSLI-process pair — existence or occurrence, completeness, valuation and accuracy, rights and obligations, presentation — anchored on where the account's risk actually lives: completeness for liabilities, occurrence and cutoff for revenue, valuation for reserves and inventory.\n4. Catch the shared and cross-cutting elements: the financial close touches everything; shared-services centers and outsourced processes (payroll is the classic) enter scope with their SOC 1 reports and the complementary user entity controls those reports assume.\n5. Verify coverage in both directions: every in-scope FSLI maps to at least one process, and every mapped process traces back to an in-scope FSLI. A process with no account linkage either hides a missing account or does not belong in scope — resolve it before proceeding.\n6. Record the account-process-system matrix with assertions and stream types as the register the RMM identification below builds on.\n*RMM identification*\n7. For each FSLI-process-assertion combination, write the what-could-go-wrong statements: specific, mechanism-level risks — \"shipments near period end are recorded in the wrong period, overstating revenue occurrence and cutoff\" — never category labels like \"revenue risk\". One RMM per distinct failure mechanism, so controls map cleanly.\n8. Rate each RMM's inherent risk from likelihood and magnitude drivers: transaction volume, complexity and subjectivity of the accounting (estimates and non-routine entries rate higher), susceptibility to fraud, history of error, degree of manual intervention, and change in the period. Apply the program's scale (typically High, Medium, Low) consistently — the rating drives control-selection intensity and test timing downstream.\n9. Type each risk: error versus fraud-susceptible; routine versus non-routine versus estimation. Estimation RMMs must name the assumption at risk — the discount rate, the loss ratio, the obsolescence percentage — because that is what the addressing control must constrain.\n10. Include IT-origin RMMs wherever the matrix shows automated dependence: interface failures dropping transactions (completeness), logic changed without testing (accuracy), and report-generation risk on the key reports controls consume.\n11. Sanity-check against history: every prior-year deficiency and known misstatement must map to an RMM on the list. One that does not is proof the list is incomplete — add the missing risk before moving on.\n12. Number the RMMs — they become the Risk IDs the RCM carries — and stage the register for control mapping.\n\n**Record in AssureSwarm**\n- Attach the account-process-system matrix (step document, XLSX).\n- Link the Process items touched to the anchor Audit (Process ↔ Audit relationship).\n- Record the per-FSLI assertions and the systems and EUC inventory in the matrix document — there is no native FSLI or Application item type, so they live in the document, not on item fields.\n- Create or update the RMM register as Risk items: one per RMM, category=financial_reporting, with likelihood, impact, inherent_rating, and risk_owner set, and the what-could-go-wrong statement plus its assertion and error/fraud type in the description.\n- Link each RMM to its Process (Risk ↔ Process) and to the anchor Audit (Risk ↔ Audit); there is no FSLI item to link, so the FSLI trace stays in the matrix document.\n- Attach the numbered RMM register export (step document, XLSX).\n\n**Exit criteria** — The matrix covers all in-scope FSLIs, processes, systems and assertions. Each assertion has a rated, typed RMM or a documented exclusion basis; prior deficiencies trace to numbered, linked RMMs.","label":"Map accounts to processes and identify RMMs","requiredApprovals":1},"id":"map-accounts-to-processes"},{"data":{"description":"Select key controls and ITGCs for each RMM and assess fraud risk","instructions":"**Objective** — Select key controls and dependent ITGCs for each RMM; assess fraud schemes, improper revenue recognition and management override.\n\n**Human contribution** — SOX lead and IT audit specialist (expertise, variance): Judge control precision, IT dependencies and fraud-risk coverage. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The numbered RMM register with inherent ratings.\n- The control library: candidate controls with descriptions, owners, frequency, preventive-or-detective type, and automation classification.\n- The application inventory and key-report list from the process mapping.\n- The prior-year key-control list and the reliance strategy — where the auditor tests or relies, precision expectations rise.\n- Incentive and pressure indicators: compensation metrics tied to earnings or covenants, analyst expectations, covenant headroom, pending transactions.\n- Whistleblower and hotline history, prior fraud or investigation history, and any journal-entry analytics already run.\n- The close-process map: who can post entries, adjust estimates, or bypass approvals.\n\n**Procedure**\n*Key-control and ITGC selection*\n1. Map candidate controls to each RMM and select key controls on precision: would this control, operating as designed, actually catch a misstatement of a magnitude that matters? Test precision concretely — the review threshold versus materiality, the level of aggregation reviewed, the reviewer's authority and access to the underlying information. A monthly fluctuation review run at a $5M threshold is not a precise answer to a $1M materiality.\n2. Prefer the control closest to the risk: one precise preventive control usually beats three loose detective ones. Resist labeling everything key — over-scoping doubles testing cost and dilutes attention. A control is key only if its failure plausibly leaves a material misstatement undetected by the remaining set.\n3. Classify each selected control: preventive or detective; manual, automated, or IT-dependent manual; frequency; and the IPE it consumes. Every key report, query, or spreadsheet feeding a key control enters the IPE inventory with a completeness-and-accuracy expectation attached.\n4. Chain the IT dependence: for every automated control, calculation, or key report, identify the application and pull its ITGCs into scope — logical access (provisioning, deprovisioning, privileged access, periodic review), change management (authorization, testing, segregated migration), and IT operations (job scheduling, backup, incident handling) for the platforms those applications run on. An automated control without effective ITGCs cannot be relied on at reduced testing.\n5. Cover the entity level: map entity-level controls across the COSO components and classify each as direct (precise enough to address an RMM alone) or indirect (contributes but does not answer an RMM by itself). Management-override and period-end close controls — journal-entry approval, estimate reviews — are mandatory inclusions, not candidates.\n6. Verify the lattice: every RMM has at least one key control; every automated dependence has ITGC coverage; every key report has a completeness-and-accuracy plan; controls covering no RMM are explicitly de-designated as key with a note. An RMM with no addressing control is a design gap — log it now for the disposition decision rather than papering over it.\n*Fraud-risk assessment*\n7. Run a structured fraud brainstorm with the SOX team and finance leadership: for each significant account, ask who benefits from misstatement, in which direction, and by what mechanism — fictitious revenue, cutoff manipulation, cookie-jar reserves, improper capitalization of expenses, undisclosed related-party arrangements.\n8. Apply the presumptions explicitly: treat improper revenue recognition as a fraud risk unless rebutted with a documented basis, and treat management override as a fraud risk that cannot be rebutted. Both must appear in the register with their answering controls.\n9. For management override, verify the specific answers exist and are designated key: journal-entry controls targeting risk-profiled entries (manual and top-side entries, period-end postings, round-dollar amounts, seldom-used accounts, entries by unexpected posters); review of estimates for bias in the aggregate — are the misses always income-favorable?; and scrutiny of significant unusual transactions outside the normal course of business.\n10. Map each fraud risk to its anti-fraud controls and evaluate them against collusion and override: a control performed by the person holding the incentive is not an answer. Where segregation is impossible in a small team, name the compensating monitoring that substitutes.\n11. Rate fraud-tagged RMMs consciously: fraud risks are treated as significant risks, which drives walkthrough depth, test timing closer to year-end, larger or targeted samples, and an element of unpredictability in procedures.\n12. Document the fraud-risk assessment memo: factors considered across incentive, opportunity, and rationalization; schemes evaluated; risks identified; controls mapped; and gaps escalated to the disposition decision.\n\n**Record in AssureSwarm**\n- Update the selected Control items: key_control=true, control_type (preventive/detective), automation (manual/automated/hybrid), and frequency; link each to the RMM it answers (Control ↔ Risk relationship).\n- ITGCs are Control items too (framework includes sox; linked to their it_general_control Process items) — update or create them and link Control ↔ Process. There is no Application item type, so the per-application ITGC scope stays in the selection-matrix document.\n- Attach the control-selection matrix and the IPE inventory (step documents; the IPE inventory has no native item type and lives in the document).\n- Create or update the fraud risks as Risk items (category=financial_reporting), linked to their Process (Risk ↔ Process) and to their anti-fraud Control items (Risk ↔ Control).\n- Mark the fraud-tagged RMMs on their Risk items.\n- Attach the fraud-risk assessment memo (step document, DOCX/PDF).\n\n**Exit criteria** — The selection matrix reconciles to tagged Controls; every RMM and fraud risk has coverage or a logged gap. ITGC/IPE scope, de-designations, revenue-recognition rebuttals and management-override coverage are evidenced in the attached matrices and fraud memo.","label":"Select key controls, ITGCs, and assess fraud risk","requiredApprovals":1},"id":"select-key-controls-and-itgcs"},{"data":{"description":"Complete Obtain scoping concurrence","instructions":"**Objective** — Put the complete scoping package in front of the people who must stand behind it — management, the SOX steering or audit committee, and the external auditor — and convert their review into documented concurrence or tracked objections.\n\n**Human contribution** — Accountable management and IA scope approver (approval): Approve the versioned scope memo and resolve scope objections. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The concurrence package: materiality and scope workpaper, scope memo, account-process-system matrix, RMM register, control-selection matrix with ITGC scope and IPE inventory, fraud-risk memo, and the workplan.\n- The reliance strategy memo: what the auditor already signaled.\n- A change log versus prior-year scoping — adds, drops, rating changes — because reviewers concur faster with a delta than with a fresh read.\n\n**Procedure**\n1. Assemble the package with the delta view first — what changed from last year and why — then the full support behind it. A reviewer should be able to trace any conclusion to its workpaper in one hop.\n2. Route internal concurrence in order: Controller or CFO on materiality and the FSLI scope; process owners on their control selections (an owner discovering at test time that their control is key is a planning failure); SOX steering or the audit committee on the overall plan and resourcing. Assign the accountable reviewers through native approvals and preserve their comments in the step result.\n3. Present to the external auditor: scope conclusions, key-control counts by process, the ITGC perimeter, fraud-risk treatment, and testing timing. Solicit specific objections — accounts they consider significant that management excluded, controls they consider imprecise, locations they expected covered.\n4. Disposition every comment one of three ways: accept (change the scope and record the change), rebut (document the basis and confirm the reviewer accepts it), or defer (record the trigger that will resolve it and its owner). Silence is not concurrence — chase each reviewer to an explicit position.\n5. Capture the concurrence record: who reviewed which package version, what they said, what changed as a result. The auditor's position on management's scope is an acknowledgment, not a certification — record it as what it is.\n\n6. Compile a separately named Fiscal Year Audit Scope Memo with fiscal year, entities, significant accounts and assertions, processes, key controls, ITGC perimeter, materiality, inclusions/exclusions and their basis, changes from prior year, reliance, methodology and planned milestones. Version it and attach it alongside the RCM and materiality workpaper for management and IA concurrence.\n7. Record accountable management and IA approvals of the exact scope memo version through native approvals; collect comments in the step result and attached correspondence. Request only facts still missing from the named process owners; do not collect sign-off in a questionnaire.\n\n**Record in AssureSwarm**\n- Attach the package version reviewed and the comment-disposition log (document upload).\n- Native approvals record the accountable reviewers and exact scope-memo version; record each position, disputed account/location, control-selection comment and resolution in the step result with correspondence attached.\n- Record each reviewer, role, date, and outcome on this step; route sign-offs as step approvals where reviewers work in AssureSwarm.\n- Fold accepted scope changes back into the register and matrix items before proceeding.\n\n**Exit criteria** — Every named reviewer holds an explicit recorded position; every comment is dispositioned as accepted, rebutted-and-accepted, or deferred with a trigger; scope changes from concurrence are reflected in the records; the concurred baseline is identified by version.","label":"Obtain scoping concurrence","requiredApprovals":1},"id":"obtain-scoping-concurrence"},{"data":{"description":"Complete Publish RCM","instructions":"**Objective** — Assemble and publish the Risk and Control Matrix (RCM) that anchors fieldwork for this audit: with scoping concurrence secured, compile every in-scope risk and its controls into one matrix and publish it as the workbook downstream testing works from.\n\n**Human contribution** — SOX scope reviewer (expertise): Resolve missing risk/control pairs before the RCM drives fieldwork. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The agreed audit scope — in-scope processes, regions, and reporting period — and the audit objectives.\n- The significant accounts, RMMs, and key controls selected earlier in this workflow.\n- The entity's existing risk register and control library.\n\n**Procedure**\n1. Query the audit scope and objectives so you know which processes, regions, entities, and period the matrix must cover.\n2. Pull the existing risks that apply to that scope — matched by process tag and by audit-universe entity — and, for each risk, the controls already linked to it in the control library and risk register.\n3. De-duplicate the pulled risks and controls so each risk-control pair appears once.\n4. Assemble the matrix as one row per risk-control pair, carrying the standard 15-column RCM schema in this exact order: Risk ID, Risk Description, Risk Category, Inherent Likelihood, Inherent Impact, Control ID, Control Description, Control Owner, Frequency, Type P/D, Manual/Automated, Test Approach, Sample Size, Tester, Notes. The schema is fixed — never reorder, add, or drop columns. Tester stays blank at build time; Test Approach and Sample Size carry record values or stay blank. The same layout every run is what makes year-over-year and cross-audit comparison mechanical.\n5. Auto-fill each cell only from an existing record. Never invent a risk or a control: where a new risk or control belongs but no record exists yet, leave the slot blank for the auditor to complete, and append a few blank \"add new\" stub rows (three is typical) after each risk category so the auditor has room to extend the matrix in place.\n6. Render the assembled matrix to a spreadsheet workbook — the same columns and layout every run — and publish it as this audit's RCM document.\n7. Where a consumer needs less than the whole matrix, cut a filtered slice — by process, by system, by FSLI, or all — and export it as its own workbook for offline review or external-auditor delivery. The slice is a pure export that never modifies the underlying records, and its testing-oriented layout (FSLI, assertion, key-control flag, last test date and result, open deficiencies) complements the build-time 15-column layout rather than mirroring it — point each consumer at the right artifact.\n8. Never-invent discipline: the matrix reflects only what the records actually contain. If it comes back mostly blank, that is the signal the risk register for this scope is thin — pause and build out the risk register first rather than filling gaps with invented risks or controls, then reassemble.\n9. Human checkpoint: the auditor reviews the published matrix, completes the blank new-risk and new-control slots, and confirms the populated pairs are accurate and in scope before the matrix drives fieldwork.\n\n**Record in AssureSwarm**\n- The source records the rows were pulled from, and the count of populated versus blank rows.\n- Any scope areas that came back under-populated.\n- The RMM linkage for each populated row.\n- The published workbook (document upload, linked to the SOX audit), plus any filtered export slices delivered and to whom.\n\n**Exit criteria** — The published 15-column RCM and delivered slices trace to source records, retain blank auditor stubs and completeness/accuracy support, and are ready for fieldwork design.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` serializes the assembled matrix to the fixed 15-column xlsx with the add-new stub rows per category, and cuts the filtered export slices, deterministically — source, output, and exit code land in a Procedure tab.","label":"Publish RCM","performedBy":{"agent":"sox-artist","note":"Risk & Control Matrix xlsx serializer engine","primitives":["coach-query-data","coach-document-upload","sox-python"]},"requiredApprovals":1},"id":"publish-rcm"},{"data":{"decisionField":"disposition_path","description":"Classify the result of Annual ICFR Scoping & Risk Assessment so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"No reportable gap","value":"clean"},{"label":"Remediation required","value":"remediate"},{"label":"Escalate significant issue","value":"escalate"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Human contribution** — Accountable IA/SOX lead (expertise, variance): Choose the supported clean, remediation or escalation disposition; no adverse evidence is hidden. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Objective** — Classify what scoping found so only the relevant closure path stays live: a clean baseline, gaps management will remediate in-cycle, or an issue that must go up before the baseline can stand. The SOX PMO owns the call.\n\n**Decision criteria**\n- **No reportable gap (`clean`)** — the lattice is whole: every RMM, fraud risks included, maps to at least one key control with adequate precision; ITGC scope covers every automated dependence; the IPE inventory is complete; no unremediated prior-year deficiency alters a scope conclusion; and concurrence produced no unresolved objection. Blank RCM stubs awaiting auditor-added rows are workflow mechanics, not gaps.\n- **Remediation required (`remediate`)** — scoping surfaced closable defects: RMMs with no addressing control or with imprecise controls (design gaps), missing ITGC coverage on an in-scope application, key reports without a completeness-and-accuracy plan, controls without current owners or accurate descriptions, or an under-populated risk register slice flagged at RCM assembly. Choose this branch when management can realistically design and implement fixes inside the season's remediation window, so remediated controls still accumulate an operating period before year-end.\n- **Escalate significant issue (`escalate`)** — the finding exceeds in-cycle repair or the PMO's authority: an indicator of a possible material weakness (a significant account or a fraud risk with no effective control answer), pervasive ITGC failure across platforms, an unresolved scope disagreement with the external auditor, a resource shortfall that makes planned coverage impossible, or a proposed risk acceptance only senior management can own. The escalation-or-acceptance decision itself is made on that path, not here.\n\n**Record in AssureSwarm**\n- Submit the decision form: `disposition_path` (the branch), the step result citing the specific coverage checks, concurrence outcomes, and RCM-assembly evidence behind the classification, and the step's approver record.\n\n**Exit criteria** — Form submitted with a rationale that references the evidence; unused branches are prunable because branch edge values match the selected option.","kind":"decision","label":"Classify disposition","requiredApprovals":1},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert each scoping gap into an owned, dated remediation item with interim risk cover, so gaps close inside the season instead of resurfacing as year-end deficiencies.\n\n**Human contribution** — Accountable remediation owner (approval): Commit corrective actions, resources, deadlines and acceptance evidence. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The gap list from the disposition rationale: design gaps, ITGC coverage holes, IPE plan gaps, ownership lapses.\n- The season calendar: the remediation window and the walkthrough and testing dates each fix must precede.\n- The control owners and process owners for the affected areas.\n\n**Procedure**\n1. Write a root cause per gap, not a symptom: \"control never redesigned after the ERP migration\" drives a different fix than \"owner left and the control lapsed\". A gap without a root cause gets reopened by the same force that created it.\n2. Define each fix at control precision: the new or changed control's description, owner, frequency, and the RMM it will address — specific enough that the walkthrough team can evaluate design the day it lands.\n3. Date each fix backward from testing: the implementation date plus enough operating instances to test. A monthly control implemented in November cannot demonstrate an operating period for the year — flag timing casualties to the disposition owner now, while substantive alternatives can still be arranged.\n4. Set interim mitigation for the exposure until the fix operates: monitoring, secondary review, or targeted substantive procedures — named, owned, and dated like the fix itself.\n5. Assign a validation step per item: who confirms the fix is designed and implemented (normally the walkthrough), and what evidence proves it.\n6. Put the plan on the reporting cadence: open items reviewed on the SOX status rhythm with the steering group until closed.\n\n**Record in AssureSwarm**\n- Create one Issue item per gap (issue_type deficiency or finding, source sox_testing or self_assessment) carrying issue_owner, root_cause, remediation_plan (fix description and interim mitigation), and target_remediation_date; link each to its RMM (Issue ↔ Risk), its Control (Issue ↔ Control), and the anchor Audit (Issue ↔ Audit).\n- Attach the consolidated action plan (step document).\n- Record the reporting cadence and the next review date on this step.\n\n**Exit criteria** — Every gap in the rationale has a remediation item with owner, root cause, dated fix, interim mitigation, and a validation plan; timing casualties are flagged; the plan is attached and on the status cadence.","label":"Create action plan","requiredApprovals":1},"id":"create-action-plan"},{"data":{"description":"Escalate to SOX PMO, control owner, reviewer, or certification owner or document risk acceptance","instructions":"**Objective** — Put the significant issue in front of the authority that can decide it — SOX PMO, control owner, reviewer, or certification owner — and land a documented decision: fund the fix, change the scope, or formally accept the risk with conditions.\n\n**Human contribution** — Authorized risk acceptance or escalation authority (approval): Decide the bounded exposure and follow-up obligations within delegated authority. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The escalation basis from the disposition rationale: the specific gap or disagreement and its evidence.\n- Quantified exposure: the affected accounts and their magnitudes against materiality, the RMMs left unanswered, and the severity the issue could become at year-end on the deficiency ladder (control deficiency, then significant deficiency, then material weakness).\n- An options analysis: remediation cost and time, scope alternatives, compensating controls, substantive-procedure fallback.\n\n**Procedure**\n1. Write the decision memo decision-first: the issue, the exposure stated in dollars against materiality, the year-end severity it could become (a scoping-stage gap in a significant account that survives to testing is a probable significant deficiency), two or three options with cost and residual risk, and a recommendation.\n2. Match the deciding authority to the exposure: control-owner level for single-control issues; SOX PMO or steering for process-level exposure; CFO and audit committee where a material weakness indicator or an auditor disagreement is on the table. Section 302 certification owners must see anything that could touch their quarterly certification.\n3. Present, and capture the decision verbatim: what was decided, by whom, on what date, on what information.\n4. If the decision is risk acceptance, record it as a policy_exception Issue: issue_type=policy_exception, exception_approver = the accountable acceptor, exception_expiry_date = the re-review date, with the accepted exposure and its conditions (compensating monitoring, substantive coverage, disclosure considerations) in the description and remediation_plan; link the Issue to the affected Risk (and Policy where one governs), and set treatment=accept plus the residual_rating on that accepted Risk. The acceptor named in exception_approver must be the risk owner with authority over the exposure — never the person who found the issue.\n5. Define follow-up ownership either way: remediation flows back into the action plan with owners and dates; acceptance conditions are tracked to the policy_exception's exception_expiry_date re-review.\n\n**Record in AssureSwarm**\n- Attach the decision memo and the recorded decision with decider, date, and conditions (step document).\n- For an acceptance: the policy_exception Issue (exception_approver, exception_expiry_date) linked to the affected Risk, and treatment=accept + residual_rating set on that Risk.\n- For remediation or condition follow-ups: Issue items with issue_owner and target_remediation_date, linked to the affected Risk and Control items.\n- Link the affected RMMs (Risk) and Controls to the decision record.\n\n**Exit criteria** — Decision recorded with named authority and date; any risk acceptance carries explicit exposure, conditions, expiry, and an owner; follow-ups exist as dated items; the affected scope conclusion is updated to reflect the decision.","label":"Escalate or accept risk","requiredApprovals":1},"id":"escalate-or-accept-risk"},{"data":{"decisionField":"approval_path","description":"Capture approval from SOX PMO, control owner, reviewer, or certification owner","formData":{"fields":[{"key":"approval_path","label":"Approve or revise package","options":[{"label":"Approved","value":"approved"},{"label":"Revision required","value":"revise"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Capture the accountable approval of the frozen scoping baseline from the SOX PMO, control owner, reviewer, or certification owner — or send it back with specific, closable conditions.\n\n**Human contribution** — Independent IA/SOX package approver (approval, expertise): Approve the supported conclusion and package or require specified revisions. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- Every artifact produced upstream: the baseline memo, reliance strategy memo, locked workplan, signed scope workpaper and scope memo, account-process-system matrix, RMM register, control-selection matrix with ITGC and IPE inventories, fraud-risk memo, concurrence record with comment dispositions, the published RCM and any export slices, and the action plan or escalation record where those branches ran.\n- The decision-form records from the disposition decision point.\n- The final package with the proposed conclusion.\n- The disposition-path outputs folded in: the action plan or the escalation decision record.\n- The RCM workbook and the tagged SOX-relevant control set on the audit item.\n\n**Procedure**\n*Agent preparation and filing absorb “Prepare final package”, “Freeze scoping baseline for walkthrough and testing waves”; the role named below owns the substantive review.*\n1. Index the package in workflow order and link every artifact to the step that produced it, so the narrative order is the evidence order.\n2. Test it against the re-performance bar: could a reviewer holding only this package re-derive materiality, the FSLI screen, the RMM coverage, and the key-control lattice? Any external reference — \"see the shared drive\" — fails the bar; pull the artifact in.\n3. Reconcile the numbers across artifacts: the FSLI count in the memo equals the rows in the workpaper; the RMM count in the register equals the distinct Risk IDs in the RCM; the key-control count in the selection matrix equals the controls tagged on the audit. Unexplained deltas are your findings before they become the approver's.\n4. Summarize unresolved constraints honestly: open remediation items with dates, deferred concurrence comments with triggers, escalations pending decision. An approver signing a package that hides open threads is approving something untrue.\n5. Draft the proposed conclusion for approval: the scope baseline (accounts, processes, key controls, ITGC perimeter), its effective date, and the conditions that ride with it.\n\n6. Cut the baseline: the definitive in-scope FSLI list, process map, RMM register, key-control and ITGC lists, and the RCM version — each identified by version and date, so \"the baseline\" names a specific set of artifacts rather than a moving folder.\n7. Reconcile the baseline against AssureSwarm state one last time: the Controls flagged key_control=true (with sox in framework) match the key-control list; the anchor Audit item's linked-control set matches; remediation Issue items reference baseline control IDs.\n8. Establish the season's change-control rule and record it with the baseline: post-freeze scope changes — a new account crossing materiality at Q3, an acquired process, a control replaced mid-year — enter through a logged scope-change record with SOX PMO approval and re-concurrence where the change is significant. Baseline artifacts are never edited in place.\n9. Publish the freeze declaration: baseline version, effective date, the change-control rule, and the open items that ride along (remediation due dates, acceptance re-reviews), so downstream waves know exactly what is moving inside the frozen frame.\n10. Notify the walkthrough and testing leads that the baseline is live and where it lives.\n\n**Decision criteria**\n- **Approved (`approved`)** — the package is complete and internally consistent: cross-artifact counts reconcile; every concurrence comment is dispositioned; gaps are covered by an owned action plan or a recorded escalation decision; open constraints are visible with owners and dates; and the approver is satisfied the baseline supports the year's Section 404 assessment plan and the Section 302 certification chain. Conditions that do not change scope conclusions (for example, \"confirm the Q3 remediation date\") may ride with approval as tracked items.\n- **Revision required (`revise`)** — any of: evidence missing or failing the re-performance bar; an unresolved reviewer or auditor objection touching a scope conclusion; reconciliation deltas without explanation; a gap with no owner or date; a risk acceptance missing its conditions or its authorized acceptor; or the approver disputes a materiality, significance, or key-control judgment. State each condition specifically — the revision step executes from that list, and vague send-backs just recycle.\n\nApproval here is of the scoping baseline, not of the year's ICFR effectiveness — that conclusion belongs to year-end, after testing.\n\n**Record in AssureSwarm**\n- Attach the indexed package and the reconciliation notes (document upload).\n- Link every source artifact to its producing step (document link).\n- Record open constraints with owners and dates on this step.\n- Attach the freeze declaration with the artifact version list (step document).\n- Record the effective date and the change-control rule in this step’s result.\n- Start the scope-change log as a living document on this step, ready to receive in-season changes — there is no native log item type, so it is an addenda-only document, not an item.\n- Submit the decision form: `approval_path` (the branch), the step result citing what was reviewed and enumerating any conditions, and the step's approver record naming the approver and role.\n\n**Exit criteria** — Artifact counts and versions reconcile; the indexed package, freeze declaration, effective date and change log are attached. Native approval identifies the scope memo version, branch and conditions; downstream leads have the approved baseline.","kind":"decision","label":"Approve or revise package","requiredApprovals":1},"id":"approve-or-revise-package"},{"data":{"description":"Resolve reviewer comments or approval conditions","instructions":"**Objective** — Clear every condition the approver attached, change only what the conditions require, and document the delta so re-approval is a check against a list rather than a fresh review.\n\n**Human contribution** — Original independent package approver (expertise, approval): Judge evidence resolving each requested revision before reapproval. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- the step result: the enumerated conditions.\n- The frozen baseline artifacts and the final package.\n- The owners of each affected artifact.\n\n**Procedure**\n1. Restate each condition as a closable work item with an owner and the artifact it touches. If a condition is ambiguous, clarify it with the approver before working it — guessing produces a second revision cycle.\n2. Execute the fixes: pull missing evidence into the package, re-run the reconciliations, obtain the missing disposition or sign-off, and correct scope conclusions where the approver's challenge stands. Where a challenged judgment is defended rather than changed, write the rebuttal and obtain the approver's explicit acceptance of it.\n3. Route every change through the change-control rule established at freeze: baseline artifacts are not edited in place — corrected versions are issued, and the scope-change log records what moved and why.\n4. Keep the package index current: superseded artifacts marked replaced, new versions linked, so exactly one authoritative set exists and nobody re-reviews a stale file.\n5. Write the resolution summary mapping each condition to the action taken and its evidence reference, and route the package back to the approver.\n\n**Record in AssureSwarm**\n- Attach the corrected artifact versions and the condition-resolution summary (document upload).\n- Update the scope-change log with each change and its reason.\n- Mark superseded documents as replaced so one authoritative set remains.\n\n**Exit criteria** — Every condition maps to a completed action with evidence or an approver-accepted rebuttal; versioning is clean with one authoritative set; the resolution summary is attached; the package is back with the approver.","label":"Resolve approval conditions","requiredApprovals":1},"id":"resolve-approval-conditions"},{"data":{"description":"Handoff outputs to SOX Scoping Decision, SOX Process Walkthrough and SOX Key Control TOD/TOE Test, and close the cycle with the record archived under retention","instructions":"**Objective** — Deliver the approved scope to SOX Scoping Decision, SOX Process Walkthrough and SOX Key Control TOD/TOE Test; resolve receiving leads’ commitments and retain the scoping record.\n\n**Human contribution** — IA/SOX accountable lead and receiving owner (approval, expertise): Resolve residual caveats and accept the next phase’s commitments, required coverage and dates. Assign this role to native approval; record the exact version and decision. Independent reviewers cannot be executors.\n\n**Inputs**\n- The approval decision (direct, or reached after condition resolution) with its rationale and owner from the decision form.\n- The approved package and baseline version identifiers.\n- Any conditions riding with the approval, and their owners.\n- The approved baseline: scope memo, signed scope workpaper, RMM register, key-control and ITGC lists, RCM workbook, and the freeze declaration with its change-control rule.\n- The approval record with any riding conditions.\n- The workplan dates and the receiving leads for the downstream waves.\n- The records-retention schedule — SOX assessment workpapers are commonly retained seven years, aligned to the external auditor's retention rule.\n- The open items: remediation due dates, acceptance re-reviews, approval conditions, and the scope-change log.\n\n**Procedure**\n*Agent preparation and filing absorb “Record approval decision”; the role named below owns the substantive review.*\n1. Record the approval tuple precisely: approver name and role (SOX PMO, control owner, reviewer, or certification owner), decision date, the exact baseline and package versions approved, and the conditions attached. An approval that does not name the version approves nothing.\n2. Verify the approver's authority matches the decision: the scoping baseline for the 404 program is typically approved at SOX PMO or management level with audit-committee visibility; where the signer acts under delegation, note the delegation in the record.\n3. Convert each riding condition into a tracked follow-up item with an owner and due date, linked to this approval so its closure is auditable against the approval it conditions.\n4. Confirm the Section 302 chain: certification owners who rely on this baseline for quarterly certifications are notified of the approval and of any conditions touching their certification basis.\n5. Consolidate the decision record: the native approval record, the conditions register, and the approved-version pointer live together where the handoff step will package them.\n\n6. Assemble the handoff per consumer: walkthrough teams get the process maps, RMM register, and per-process control lists — their job is design evaluation, not re-scoping; TOD/TOE testing gets the RCM with its Test Approach and Sample Size columns plus the IPE inventory — their sampling starts from these controls, not from the whole library; scoping-decision consumers get the materiality basis and FSLI screen for in-season re-checks when facts change.\n7. State the assumptions the package carries: the materiality base and percentage, the as-of financials used, the reliance levels agreed with the auditor, and the open remediation and condition items with dates — downstream teams must know what is provisional.\n8. State explicitly what downstream must not repeat: re-computing materiality, re-selecting key controls, re-rating RMMs. Changes go through the scope-change log under the freeze rule, never through downstream improvisation.\n9. Create or link the downstream workflow instances, attach the package to each, and assign the receiving leads per the workplan.\n10. Confirm receipt: each receiving lead acknowledges the package and its assumptions. An unacknowledged handoff is a gap the season will find at the worst possible time.\n11. Verify closability before archiving: approval recorded, handoffs acknowledged, and every open item existing as an owned, dated AssureSwarm item. Scoping legitimately closes with open remediation items — that is what the season is for — but never with unowned ones.\n12. Export the full workflow record (steps, decisions, forms, approvals) and archive it with the final package in the 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 archived artifacts.\n13. Update the SOX audit item: scoping phase complete, the baseline version pointer, and the archive reference — the year's assessment record builds from this entry.\n14. Seed next year and communicate closure: write the roll-forward note naming what next year's baseline build should pick up first — this year's gaps and their outcomes, deferred concurrence comments, and open acceptance re-review triggers — schedule the monitoring that any risk-acceptance conditions require, and tell the stakeholders on the concurrence list that the baseline is approved, where it lives, what remains open, and who owns each open thread.\n\n15. Hold the integrated external-auditor and IA audit-team kickoff using the approved Fiscal Year Audit Scope Memo and workplan. Include IA management, SOX and process leads, testing/review leads and external-auditor counterparts. Walk through controls and substantive methodology, scope, milestones, responsibilities, PBC conventions, escalation and year-end dependencies; attach the agenda, attendance, decisions and action record.\n16. Schedule the business-process kickoffs with each business leader, process/control owners and IA lead, including external-auditor participants where required. Send calendar invitations through the tenant-approved channel only under recorded outreach authority; log session dates, participants, responses, conflicts and unresolved scheduling actions.\n17. Issue the fiscal-year audit announcement email to leadership and control owners after scope approval. Tailor leadership’s copy to scope, milestones, commitments and escalation; tailor control owners’ copy to their controls, evidence expectations, due dates and contacts. Issue annual planning materials to business leaders and control owners: the exact approved scope memo, relevant RCM slice, workplan, kickoff schedule and evidence guidance. Record actual dispatch and receipts; drafts remain pending until an authorized sender supplies dispatch evidence.\n18. Bind external-auditor, Workstream and Narrative Module labels to the tenant’s approved firm/contact and communication/document destinations. Verify access to exact versions before sending; if no supported connector exists, stage files and messages for the authorized sender and record the unresolved binding.\n\n**Record in AssureSwarm**\n- Record approver, role, date, approved versions, and conditions in this step’s result; capture the sign-off as a step approval where the approver acts in AssureSwarm.\n- Create the condition follow-ups as Issue items (issue_owner, target_remediation_date), linked to the anchor Audit and to the approval.\n- Attach the consolidated approval record (step document).\n- Create or link the three downstream workflows and attach the handoff package to each.\n- Record the assumptions, the do-not-repeat list, and each receiving lead's acknowledgment on this step.\n- Keep condition items with dates visible to their owners across the handoff.\n- Attach the closure record with the archive location and reference (step document).\n- Update the anchor Audit item: append the baseline-version pointer and the archive reference to Audit.scope (there is no dedicated phase field, so scoping-phase-complete is carried in the scope text and the item status).\n- Create the roll-forward note (step document) and any monitoring follow-ups as Issue items with owners and dates.\n- The archived workflow instance itself is the durable audit trail.\n\n**Exit criteria** — All three downstream workflows have the approved versioned package and acknowledged commitments. Owned conditions remain visible; announcement/materials dispatch and kickoff records are attached. Audit.scope carries baseline/archive pointers, retrievability is checked and next-cycle follow-ups are dated.","label":"Handoff to related workflow","requiredApprovals":1},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-annual-icfr-scoping-risk-assessment"}