{"description":"Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.","edges":[{"id":"e-walk-the-flow-identify-key-controls","source":"walk-the-flow","target":"identify-key-controls"},{"id":"e-identify-key-controls-draft-the-walkthrough-memo","source":"identify-key-controls","target":"draft-the-walkthrough-memo"},{"id":"e-draft-the-walkthrough-memo-classify-disposition","source":"draft-the-walkthrough-memo","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"itemTypeSlug":"process","metadata":{"capabilities":[],"controlVerbs":{"UC-AUDIT-13":"operates","UC-AUDIT-21":"operates"},"controls":["UC-AUDIT-21","UC-AUDIT-13","UC-FIN-01","UC-FIN-05"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-walkthrough","contentDigest":"sha256:4101b1b96bb5de07faf7ed2dca53bb57b8bb08318564ae7f48a0d60671344586","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:4101b1b96bb5de07faf7ed2dca53bb57b8bb08318564ae7f48a0d60671344586","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-walkthrough"},"lifecycleContract":{"absorbedNodeIds":{"frame-the-walkthrough":"walk-the-flow","lock-executable-workplan":"walk-the-flow","map-controls-to-risks":"identify-key-controls","prepare-final-package":"handoff-to-related-workflow","seed-control-records":"classify-disposition"},"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":"Explain and challenge how transactions actually flow and which evidence proves each step.","interventions":["expertise"],"nodeId":"walk-the-flow","requiredApprovals":1,"role":"Process owner with IA walkthrough lead"},{"contribution":"Judge control attributes and whether the risk/control mapping covers the process.","interventions":["expertise"],"nodeId":"identify-key-controls","requiredApprovals":1,"role":"IA control-design specialist"},{"contribution":"Approve the exact narrative version and factual process/control description.","interventions":["approval","expertise"],"nodeId":"draft-the-walkthrough-memo","requiredApprovals":1,"role":"Accountable process management"},{"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":"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":"assure","mappingStatus":"mapped","risks":[],"slug":"sox-walkthrough","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["finance","internal-audit"]},"name":"SOX Process Walkthrough","nodes":[{"data":{"description":"Complete Walk the flow","instructions":"**Objective** — Capture the end-to-end process flow through a structured interview with the process owner, producing a numbered flow that records how the process actually runs — in the owner's own account, not the interviewer's reconstruction.\n\n**Human contribution** — Process owner with IA walkthrough lead (expertise): Explain and challenge how transactions actually flow and which evidence proves each step. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The scoping baseline this workflow consumes as the handoff package (the approved documents at sox-annual-icfr-scoping-risk-assessment/handoff-to-related-workflow): the in-scope process inventory, the significant accounts and relevant assertions, the in-scope locations, the materiality basis, and the risk ratings and fraud-risk flags. Its item-shaped parts already exist as items — the in-scope processes are Process items (the anchor Process item being walked is one of them), and the risk ratings are Risk items (inherent_rating / residual_rating).\n- The set of walkthrough units in scope for this process — one per location/instance or process variant performed differently (different performer, system, or threshold) — together with any elevated-risk, fraud-risk, mid-period-change, or external-auditor-reliance factors that expand the interviewees and transaction traces required.\n- The process owner's and interviewees' calendars (external corporate calendar); and the testing window read from the SOX program Audit item — Audit.fieldwork_start and Audit.fieldwork_end (audit_type=sox_testing).\n- The program's documentation standard for walkthrough memos (the six-section format used at the memo step) — a Policy item (policy_type=standard or procedure) where the program maintains its walkthrough standard as one, otherwise a document attached to this step.\n- The process name and its accountable owner.\n- The in-scope financial-statement assertion(s): completeness, existence/occurrence, accuracy, cutoff/obligations, valuation, presentation/disclosure.\n- The in-scope period and the location/entity covered.\n- The significant accounts the process touches, from the scoping baseline (the SOX Scoping Decision handoff document — there is no Significant Account item type).\n- The risk register — Risk items in AssureSwarm (category, likelihood, impact, inherent_rating), where one is available, for risks related to this process.\n- Current Control descriptions and owner assignments from the approved scope; establish the walkthrough framing during this checkpoint.\n- The owner's step-by-step description of how the process actually runs.\n- Any existing trace documents; request missing transactions and evidence during this checkpoint from the scope and current control facts.\n\n**Procedure**\n1. Schedule the process and controls walkthrough with the accountable process owner, control performers and reviewers, IA walkthrough lead and the external auditor when reliance requires attendance. Use the approved scoping calendar; record invitations, acceptance, session date and unresolved attendance gaps.\n2. Issue the control design request batch to named control owners through the tenant-bound Workstream channel: each request identifies the control/version, traced transaction, design evidence, period, due date and access required. Create the Design Request Tracker as an XLSX document on walk-the-flow from approved scope and current Control facts, before walkthrough completion or Control testing. Reuse available evidence and request only missing documents or generation facts. Record request IDs, exact issued batch/version, authorized sender, actual dispatch and receipt evidence, partial responses and overdue follow-up. An unavailable Workstream binding or sending authority leaves the batch prepared, not issued. This outgoing request batch is separate from responses to incoming external-auditor PBC requests. Pass the tracker and received design evidence forward in the completed walkthrough handoff; later Control testing consumes them and requests only additional missing evidence.\n\n*Agent preparation and filing absorb “Lock executable workplan”, “Frame the walkthrough”; the role named below owns the substantive review.*\n3. Fix the final walkthrough unit list (process × location × version), one unit per location/instance or process variant that is walked and traced separately, and confirm every in-scope variant and expansion factor is covered — \"corporate does it the same way everywhere\" must be verified, not assumed.\n4. Confirm the interview schedule with named participants and their roles — the process owner plus each step performer the plan requires. Book sessions inside the period being walked and outside close blackouts.\n5. Set the evidence expectations up front: request the sample transaction(s) to be traced end-to-end from the owner ahead of the sessions (source documents, approvals, system records, the reports each step consumes), and arrange now any live-observation points that need system access.\n6. Fix the documentation standard: the six-section memo format, the per-control attribute set (description, preventive/detective, manual/automated, frequency, operator, evidence source, related assertion), and the review path — who reviews, who approves.\n7. Set due dates against the SOX calendar: the walkthrough must complete early enough that its identified controls can be design-assessed and tested in the same cycle. Working backward from the testing window is the honest way to set the memo due date.\n8. Baseline the plan on this step. From here, scope or schedule changes are recorded as dated amendments with reasons — not silent edits.\n\n9. Confirm the process name and its accountable owner — a named person who will confirm the captured flow and answer for the process, not a department.\n10. Pin down which specific assertion(s) are in scope for this walkthrough. The assertion focus decides what to probe during the walk: completeness pushes toward capture points and interfaces, existence/occurrence toward authorization and validity checks, cutoff toward period-end timing, valuation toward estimates and review precision.\n11. Confirm the in-scope period and the entity/location covered — the walk must observe the process as it ran inside that period, at that location.\n12. Identify the significant accounts the process affects, tying each back to the scoping baseline.\n13. Gather related risks: where a risk register is available, look up risks related to this process and offer them as walkthrough context; otherwise capture candidate risks free-form for later mapping at the control-to-risk step.\n14. Ask one field at a time and confirm each with the owner rather than assuming it — a framing the owner has not confirmed will unravel mid-interview.\n15. Human checkpoint: the process owner confirms the complete framing before the interview begins.\n\n16. Interview the owner from the initiating trigger through each activity, handoff, system, and output, in order. Ask one step at a time and record the owner's own account.\n17. For every step capture three things: the actor who performs it, the system used, and any documentation or evidence the step produces. These three fields are what control identification and testing will consume.\n18. Do not compress, reorder, or infer steps the owner did not describe. If a gap appears between two steps (\"the invoice is approved\" → \"the payment posts\"), ask what happens in between rather than bridging it yourself — unexplained gaps are where misstatements hide.\n19. Probe beyond the happy path at each handoff and system boundary: what happens when the input is late, wrong, or missing; who performs the step when the usual actor is out; whether anyone can bypass or override the step. Record the answers as part of the flow — exception handling is part of how the process actually runs.\n20. Where the workplan includes a transaction trace, follow the sample transaction's actual documents through the described steps as the owner talks — inquiry corroborated by inspection is what separates a walkthrough from a conversation. Note any point where the documents disagree with the description.\n21. Human checkpoint: the owner reviews the captured numbered flow and confirms it matches how the process actually runs, correcting anything before it is treated as final.\n\n**Record in AssureSwarm**\n- A walkthrough workplan has no native item field — record the locked unit list, the interview schedule with participants, the evidence request list, and the due dates as notes (or a planning document) on this step.\n- Link the anchor Process item this workflow enriches and the SOX program Audit item whose fieldwork_start/fieldwork_end the due dates trace back from; reference the documentation-standard Policy item (or attach the standard as a step document).\n- There is no Significant Account or Assertion item type — the significant accounts and assertions live in the scoping handoff document; record the framing (process name, owner, in-scope assertion(s), period, entity/location, the related significant accounts, and candidate risks) as notes on this step.\n- Link the anchor Process item this walkthrough enriches and any Risk items pulled from the register as context.\n- The numbered flow has no native item type — record it as notes on this step, one entry per step, each carrying the actor, the system, and the documentation/evidence produced.\n- Attach the traced transaction's documents (uploaded by the owner) to this step where a trace was performed; note any description-versus-document discrepancies in the step notes.\n\n**Exit criteria** — Units, participants, dates, evidence requests, and the documentation standard are recorded; due dates trace back from the testing window; the baseline is marked locked with the amendment convention stated. The framing is documented and agreed with the accountable owner; scope is unambiguous; every input was confirmed with the owner rather than assumed, making the framing reperformable; open constraints are noted. The numbered flow is documented and confirmed with the owner; it runs from trigger to final output with no unexplained gaps; each step is reperformable from the notes.","label":"Walk the flow","performedBy":{"agent":"sox-artist","note":"captures each process step","primitives":["coach-item-create","coach-query-data"]},"requiredApprovals":1},"id":"walk-the-flow"},{"data":{"description":"Complete Identify key controls","instructions":"**Objective** — Identify the key controls embedded in the process and document each control's attributes, distinguishing real controls from mere activities and key controls from background ones — without fabricating anything the owner cannot confirm.\n\n**Human contribution** — IA control-design specialist (expertise): Judge control attributes and whether the risk/control mapping covers the process. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The confirmed numbered flow and trace documents at walk-the-flow.\n- The in-scope assertion(s) from the framing.\n- The owner's knowledge of what each step does and why.\n- The key controls and attribute blocks identified in this checkpoint before risk mapping.\n- The risk register in AssureSwarm, or the free-form candidate risks captured at framing.\n- The in-scope assertions per significant account, for the coverage read.\n\n**Procedure**\n*Agent preparation and filing absorb “Map controls to risks”; the role named below owns the substantive review.*\n1. Walk each step of the flow and ask whether it constitutes a control. A control does something that would prevent or detect a misstatement — an authorization, a comparison or reconciliation, a verification against source, a system edit or restriction — performed with enough precision to matter. \"We review the report\" is an activity until the owner can say what the reviewer compares, against what threshold, and what happens on a mismatch.\n2. Judge which controls are key: a control is key when, alone or in combination with others, it addresses the risk of material misstatement for an in-scope assertion — coverage of the assertion, not effort of the performer, is the test. Note non-key controls encountered, but do not build attribute blocks for them.\n3. For every control confirmed, capture its attributes: a plain-language control description, preventive versus detective, manual versus automated (flag IT-dependent manual controls — a manual review of a system report inherits the report's reliability), frequency, the operator who performs it, the evidence source it produces, and the related assertion.\n4. Never invent an attribute. If the owner cannot confirm an attribute (for example whether a control is preventive or detective, or what evidence its operation leaves), record it as an open question rather than guessing — a guessed attribute poisons the memo, the control record, and the eventual test design.\n5. Pay explicit attention to points where management could override: manual journal entries, threshold changes, approvals of unusual transactions. If the flow contains such a point with no control over it, that absence is a finding for the mapping step, not something to paper over.\n6. Human checkpoint: the owner and, where required, a reviewer confirm the control list and attributes.\n\n7. For each control, link it to the risk(s) it addresses. Where a risk register is available, pull the matching risks and link them; otherwise record the risk free-form for later register mapping.\n8. Do not invent a risk linkage beyond what the register or the owner supports — a mapping asserted \"because it seems related\" fails the first reviewer challenge and misleads test design about what the control is for.\n9. Read the mapping control-first: flag any control that maps to no risk. A control mitigating nothing in scope is either mis-described (fix the attribute block) or non-key — a candidate to rationalize out of the testing population, decided by the reviewer, not silently dropped here.\n10. Read the mapping risk-first: flag any in-scope risk with no covering control, checking coverage per relevant assertion — a risk covered for existence but not completeness is uncovered for completeness. Each uncovered risk is a design-gap candidate that will drive the disposition decision and, where confirmed, the action plan.\n11. Human checkpoint: a reviewer confirms the control-to-risk mapping and the flagged gaps.\n\n**Record in AssureSwarm**\n- Record one attribute block per control as notes on this step: description, preventive/detective, manual/automated, frequency, operator, evidence source, related assertion. These map onto Control item fields at the seed step (control_type, automation, frequency, control_owner), except evidence source and related assertion — Control has no field for those, so they are carried in Control.description and the memo (a known type gap).\n- Maintain the open-questions log (step notes) with one entry per unconfirmed attribute, each naming who can answer it.\n- Create the Control ↔ Risk item relationships — this control-to-risk mapping is the Risk & Control Matrix (RCM). (Where controls are not yet seeded as Control items, capture the intended links against the attribute blocks and materialize them at the seed step.)\n- Record the flag lists — unmapped controls and uncovered risks (per assertion) — as notes on this step, each with a one-line statement of why it matters.\n\n**Exit criteria** — Key controls and their attributes are documented; no attribute is fabricated; every unconfirmed attribute appears in the open-questions log; each key control ties to at least one in-scope assertion. The mapping is documented; every key control ties to at least one risk or is explicitly flagged; every uncovered risk is flagged for follow-up; no mapping exists without register or owner support; the reviewer has confirmed the mapping and the gaps.","label":"Identify key controls","performedBy":{"agent":"sox-artist","note":"drafts key controls and attributes for reviewer","primitives":["coach-item-create","coach-items-link","coach-query-data"]},"requiredApprovals":1},"id":"identify-key-controls"},{"data":{"description":"Complete Draft the walkthrough memo","instructions":"**Objective** — Draft — or annually refresh — the walkthrough memo for this process: a single formal, PCAOB-readable document that both records the walkthrough and serves as the standing process narrative, written to outlive personnel changes. A reader must be able to re-walk the process and re-identify every key control from this document alone.\n\n**Human contribution** — Accountable process management (approval, expertise): Approve the exact narrative version and factual process/control description. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The framing: process name, owner, in-scope assertion(s), period, entity/location, significant accounts.\n- The numbered end-to-end flow, the key controls with their full attribute blocks, the control-to-risk mapping, and the open-questions log — all captured earlier in this workflow.\n- The latest walkthrough transcript(s) for this process — use the most recent unless a specific one is named.\n- Any existing narrative or flowchart being refreshed.\n\n**Procedure**\n1. Assemble the memo in formal narrative voice — complete prose, not conversational notes — with six sections, in order.\n2. Section 1, Process Overview: 3–5 sentences stating what the process does, its business purpose, and the period covered.\n3. Section 2, End-to-End Flow: numbered steps; each step names the actor by role (never by an individual's name, so the document survives staffing changes), the system used, the action taken, and the output document produced. Place an inline [control: <id>] marker at each step where a key control operates.\n4. Section 3, Key Controls: one block per control carrying its full attribute set — description, preventive vs detective, manual vs automated, frequency, operator, evidence source, related assertion — matching the attribute blocks captured earlier exactly.\n5. Section 4, Risk Mapping and Risk Callouts: the control-to-risk links, and at the end of each major section state which risks the referenced controls address.\n6. Section 5, Open Questions: carry every unresolved open question forward verbatim.\n7. Section 6, Sign-off.\n8. Trace every narrative claim to its source with an inline [source: walkthrough/<id>, step N] citation and cite the underlying control ids. Invent nothing that is not in the walkthrough.\n9. If refreshing an existing document rather than creating a new one: diff against it, preserve any sections a reviewer has hand-edited (marked with a preserved-section marker), and refresh only the structural sections. A refresh is due annually or whenever the process changes — detectable from the latest walkthrough's update date.\n10. Render the finished memo to a shareable file (for example docx), attach it to the process/workflow record, and link the source walkthrough(s) and every referenced control so the reviewer receives a preview link to approve.\n11. Human checkpoint: a reviewer reads the memo through the preview link and approves it before any control records are seeded.\n\n12. Upload the current-year narrative and flowchart to the tenant-bound Narrative Module destination, or attach them as versioned step documents when that destination is unavailable. Record the document ID, version/date, access location and change log against the prior-year narrative.\n13. Dispatch the exact current narrative version to accountable management via the tenant-bound Workstream channel under recorded outreach authority. Record recipients, version, actual send date, receipt, review deadline, overdue follow-up and any unresolved access problem. A prepared message is not evidence of dispatch.\n14. Obtain accountable management’s native approval of that exact narrative version and its factual process/control description before downstream control records or TOD rely on it. Resolve management comments with evidence; a changed narrative requires approval of the replacement version. IA retains the separate control-design and testing conclusions.\n\n**Record in AssureSwarm**\n- Attach the completed memo (rendered DOCX/PDF), all six sections present, as a document on this step; it is linked to the anchor Process item as its standing narrative at close.\n- Record the referenced control IDs, the source-walkthrough citations, and the evidence references as step notes; link every referenced Control item and the source walkthrough(s).\n- Record the reviewer conclusion once approval lands.\n\n**Exit criteria** — The memo is drafted, rendered, and attached to the process/workflow record; every section is populated; every narrative claim carries a walkthrough source citation; actors are named by role, not individual; each key control appears as an inline [control: <id>] marker at the step where it operates and its attribute block matches what was captured earlier exactly; unresolved open questions carry forward verbatim; on a refresh, hand-edited sections survived; the source walkthrough(s) and every referenced control are linked; open constraints are noted; and the reviewer has a preview link to approve.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` renders the assembled memo to the shareable file and returns the reviewer's preview link — the drafting, citations, and section content stay with this workflow.","label":"Draft the walkthrough memo","performedBy":{"agent":"sox-artist","note":"Draft the walkthrough memo and process narrative from the captured walkthrough","primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-render-package"]},"requiredApprovals":1},"id":"draft-the-walkthrough-memo"},{"data":{"decisionField":"disposition_path","description":"Classify the result of SOX Process Walkthrough so the agent keeps only the relevant closure path","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Classify the walkthrough's result — complete, gaps requiring action, or monitor — so only the relevant closure path runs and coverage gaps surface at their true size. Proposed by the walkthrough performer; owned by the reviewer or walkthrough lead.\n\n**Human contribution** — Accountable IA/SOX lead (expertise, variance): Choose the supported clean, remediation or escalation disposition; no adverse evidence is hidden. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The key-control attribute blocks confirmed earlier in this workflow.\n- The completed, reviewer-approved walkthrough memo.\n- The existing control register records for this process, for de-duplication.\n- The control-to-risk links from the mapping step.\n\n**Procedure**\n*Agent preparation and filing absorb “Seed control records”; the role named below owns the substantive review.*\n1. Query the existing control register for this process before creating anything. A control the walkthrough re-confirmed that already exists in the register gets a proposed update — linking it to this walkthrough and correcting any attribute the walk showed to be stale — not a duplicate record.\n2. Create one draft control record per newly identified control, carrying its attributes: description, preventive/detective, manual/automated, frequency, operator, evidence source, related assertion. Each draft must match its attribute block exactly — the block the owner confirmed is the source of truth, and any \"improvement\" during transcription is fabrication.\n3. Link the walkthrough memo to each draft record as supporting documentation, and carry over the risk links established at the mapping step.\n4. Route every new record and every proposed update as a suggested change for human approval — never write control records directly into the register. A reviewer approves or rejects each one.\n5. Human checkpoint: the reviewer approves each suggested control record before it becomes a live record.\n\n**Decision criteria**\nThe classification hangs on the flag lists from the mapping step, the open-questions log, and what the walk itself revealed:\n- **complete** (Complete) — the flow is owner-confirmed end-to-end; every key control has a full, confirmed attribute block; every in-scope risk is covered by at least one key control for each relevant assertion; the memo is reviewer-approved and the control records are submitted; remaining open questions are administrative only (they do not affect control identification, attributes, or coverage). Nothing needs an action plan.\n- **gaps** (Gaps require action) — the walkthrough surfaced something that must be fixed before or alongside testing: an in-scope risk (or assertion) with no covering control — a design-gap candidate; a key control whose attributes could not be confirmed (unknown operator, no evidence trail — it cannot be tested as-is); the process demonstrably not operating as documented (the trace contradicted the description); or a segregation-of-duties conflict or uncontrolled management-override point observed during the walk. These need owned action items and feed the deficiency-evaluation machinery for severity assessment.\n- **monitor** (Monitor without immediate action) — no gap requires action now, but something warrants a documented watch or an explicit risk acceptance: a system migration will change the process next quarter (re-walk then); open questions await a third party with bounded exposure meanwhile; a single-performer dependency with cross-training underway. Route to the escalation step so the watch gets an owner, an expiry, and — where exposure is being accepted — a signature with authority.\n\n**Record in AssureSwarm**\n- Create one Control item per newly identified key control as a suggested change (never a direct register write): key_control=true, control_id, description (carrying the evidence source and related assertion, which have no dedicated Control field), control_type (preventive/detective), automation (manual/hybrid/automated), frequency, control_owner, framework=sox + coso-ic. For a control the register already holds, propose a Control field update instead of a duplicate.\n- Relate each Control item to the anchor Process item and to its mitigated Risk items (the RCM links), and link the walkthrough memo document as supporting evidence; record the count of drafts proposed (new versus updates) as step notes.\nSubmit this step's form: `disposition_path` = the chosen branch; the step result = cite the specific uncovered risks, unconfirmed attributes, or watch items driving the call (references to the flagged records, not adjectives); the step's approver record = the reviewer or lead making the call.\n\n**Exit criteria** — Draft control records are submitted for approval with the walkthrough memo linked; each draft matches its attribute block exactly; register de-duplication is documented; nothing has reached the control register without reviewer approval. Form submitted; the rationale names the specific items behind the classification; unused branches are prunable.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"sox-artist","note":"drafts control records for reviewer approval","primitives":["coach-item-create","coach-document-upload","coach-query-data","coach-items-link"]},"requiredApprovals":1},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every flagged walkthrough gap into an owned, dated action item with interim mitigation where exposure exists, sized and routed so testing is not blocked by unresolved design questions.\n\n**Human contribution** — Accountable remediation owner (approval): Commit corrective actions, resources, deadlines and acceptance evidence. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The flagged gaps behind the disposition: uncovered risks or assertions, unconfirmed control attributes, trace-versus-description mismatches, segregation-of-duties conflicts, uncontrolled override points.\n- The open-questions log.\n- The SOX calendar, for the testing window the fixes must beat.\n\n**Procedure**\n1. Convert each gap into a discrete action item with a stated root cause. Typical translations: an uncovered risk → design a new control or identify and evidence an existing compensating control; an unconfirmed attribute → a named person answers a named question by a date; a trace-versus-description mismatch → correct the memo if the documents were right, or escalate the process behavior to management if they were not; a segregation-of-duties conflict → re-assign the duty or add a monitoring control.\n2. Route design-gap candidates into the deficiency-evaluation process for severity assessment. The walkthrough team flags and describes; it does not unilaterally rate severity — magnitude and likelihood assessment against the account balance belongs to the deficiency workflow, and a gap that looks minor here may aggregate with others elsewhere.\n3. Assign a named owner and a due date to every item. Due dates must land before testing of the affected controls begins — a control cannot be design-concluded, let alone tested, while its identification questions are open.\n4. Define interim mitigation for any gap that leaves live exposure while the fix is pending, and name who operates the mitigation.\n5. Set the validation standard per item — what evidence closes it and who confirms — and the reporting cadence until closure.\n\n**Record in AssureSwarm**\n- Create one Issue item per gap: issue_type=deficiency (or finding), source=sox_testing, severity, description, root_cause, remediation_plan (carrying the interim mitigation and the validation standard, which have no dedicated field), issue_owner, target_remediation_date. Relate each Issue to the affected Control and Risk items and to this workflow.\n- Note which Issues were routed to the deficiency-evaluation process for severity assessment as step notes.\n\n**Exit criteria** — Every flagged gap has an action item with a named owner, due date, and validation standard; design-gap candidates are routed for severity evaluation; interim mitigations exist wherever exposure is live; no gap is closed by narrative alone.","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** — Turn the monitor disposition into an owned state: escalate each watch item to the authority that can act on it, or document a bounded, time-boxed risk acceptance — never an unowned \"we'll keep an eye on it\".\n\n**Human contribution** — Authorized risk acceptance or escalation authority (approval): Decide the bounded exposure and follow-up obligations within delegated authority. Assign the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The monitor rationale and watch items from the disposition decision.\n- The affected control and risk records, with the accounts and assertions they touch.\n- Account balances and activity, for sizing the exposure.\n\n**Procedure**\n1. Choose the route per watch item. Escalate when the item touches certification-relevant exposure or exceeds this workflow's authority: an uncovered risk on a significant account, a segregation-of-duties conflict, anything touching management override — those go to the SOX PMO, the control owner, the reviewer, or the certification owner as fits the item. Accept only when the exposure is bounded, temporary, and a person with authority over the affected account will sign for it.\n2. For an escalation, prepare a decision memo the recipient can act on: the observation, the accounts and assertions affected, the exposure sized from account balance and activity (numbers, not adjectives), options with a recommendation, and the date a decision is needed by — usually driven by the testing window or the certification calendar.\n3. For an acceptance, document: the exposure quantified, the conditions and compensating factors relied on, an expiry date — acceptance is time-boxed to the period and renews consciously or dies — and the sign-off of the accepter, who must own the affected account or process, not sit on the walkthrough team.\n4. Define follow-up ownership either way: who watches the trigger (the migration date, the third-party answer, the cross-training completion), and what re-opens the work when it fires.\n5. Note the certification impact: accepted risks and pending escalations touching significant accounts feed the sub-certification and 302 disclosure chain — say so explicitly so the certification owner is never surprised.\n\n**Record in AssureSwarm**\n- Attach the escalation decision memo or the risk-acceptance record as a document on this step. For a granted acceptance, set treatment=accept on the affected Risk item; the acceptance approver, sign-off date, and expiry have no Risk field, so record them in the step's acceptance record (a known type gap).\n- Relate the affected Control and Risk items; record the follow-up owner and the certification-chain notification as step notes.\n\n**Exit criteria** — Every watch item is either escalated with a decision-ready memo and a needed-by date, or accepted with quantified exposure, an expiry, and an authorized signature; follow-up ownership is named; certification impact is recorded.","label":"Escalate or accept risk","requiredApprovals":1},"id":"escalate-or-accept-risk"},{"data":{"description":"Handoff outputs to SOX Key Control TOD/TOE Test and Control Design, then close the walkthrough on those acknowledgments and preserve the audit trail","instructions":"**Objective** — Hand the walkthrough's outputs to SOX Key Control TOD/TOE Test — and to Control Design for controls with open design gaps — with packages complete enough that downstream starts executing instead of re-interviewing, and close the walkthrough on those acknowledgments with an immutable audit trail.\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 the named role to this step’s native approval before execution; the executor cannot satisfy an independent review role. Record the reviewed version and decision in the native approval and step result.\n\n**Inputs**\n- The approved walkthrough memo and the traced-transaction evidence.\n- The submitted or approved control records and the control-to-risk mapping with its flag lists.\n- The action plan (gaps path) or the escalation/acceptance memo (monitor path), where those paths ran.\n- The disposition decision form and its rationale from this workflow.\n- The reviewer-signed final package.\n- The approved control records, and the action-plan items where gaps exist.\n- The SOX calendar with the testing window.\n- The process and control records this workflow touched, and the SOX workpaper retention policy.\n\n**Procedure**\n*Agent preparation and filing absorb “Prepare final package”; the role named below owns the substantive review.*\n1. Assemble the package around the memo as its anchor: memo, trace documents, the control records with attribute blocks, the risk mapping with flagged gaps and their action items or acceptance, the decision rationales, and any unresolved constraints.\n2. Verify internal consistency — this is where walkthrough packages usually fail review: the control count in the memo equals the records submitted; every inline [control: <id>] marker resolves to a real record; the open questions in the memo match the open-questions log; every flagged gap has either an action item or a documented acceptance; any scoping assumptions logged when the workplan was locked are visible, not buried.\n3. State the proposed conclusion in three lines: process understanding obtained and documented; key controls identified and recorded (count, with the list linked); gaps flagged with owned plans (count) or none. This is what the downstream test lead reads first.\n4. Reviewer sign-off: the reviewer works the package, raises notes, and signs once notes are resolved. Unresolved review notes do not travel to the handoff — they get resolved or become explicit open constraints with owners.\n\n\n5. Split the control population by destination: controls with confirmed design and complete attributes go to SOX Key Control TOD/TOE Test; controls with open design gaps (an uncovered risk being fixed, unconfirmed attributes, a redesign in flight) go to Control Design first — sending a known-gapped control straight to operating-effectiveness testing wastes a cycle on a foregone conclusion.\n6. Create or link one downstream workflow instance per control and pass the package: the control record with its attribute block, the walkthrough memo (the design baseline downstream TOD starts from), the risk and assertion mapping, the evidence-source and IPE notes from the attribute block, and any open questions touching that control.\n7. State what downstream must not repeat: process understanding is done — the memo is the walkthrough evidence, and TOD begins from it rather than re-interviewing the owner; control attributes are confirmed — downstream extracts them, it does not re-derive them; the risk mapping is set unless new facts emerge.\n8. State what downstream owns: the design-effectiveness conclusion, sampling, TOE execution, exception evaluation, and severity classification.\n9. Check the calendar: handoff dates must leave the testing window reachable; flag any control whose action items must close before its test can start, with the dependency dated.\n10. Confirm receipt: the downstream owner acknowledges each package. Those acknowledgments — together with a verified-complete run (every step finished or explicitly dispositioned with a reason, the classify-disposition decision form submitted, review notes closed) — are what close this workflow. Closing over an open step is how audit trails grow holes.\n11. Archive the final package as the immutable record: attached versions are final, superseded drafts are marked superseded, and nothing lives only in an inbox. SOX workpapers follow the program's retention policy — seven years is the standard anchor — and must remain retrievable, not merely retained. Record the archive confirmation; any post-archive correction happens as a new dated addendum, never a silent edit.\n12. Update the linked records: the process record points at the current memo as its standing narrative; each control record shows the walkthrough date and source.\n13. Set the annual-refresh clock: this walkthrough satisfies the process's annual-refresh obligation — record the next refresh due date (one year out, or earlier upon process change).\n14. Schedule the remaining forward obligations with owners, not just dates: action-item validation dates and acceptance expiries.\n15. Communicate closure: the SOX PMO's tracking shows the walkthrough complete with the counts (controls to testing, controls to design, gaps in remediation); the process owner learns what testing will ask of their team next; certification stakeholders see any accepted risks.\n\n**Record in AssureSwarm**\n- Attach or link the exact issued Design Request Tracker, dispatch/receipt evidence and received design files from walk-the-flow in this handoff package. These precede the Control test workplan and independent TOD approval; walkthrough completion does not require a downstream TOD memo.\n- Attach the assembled package as a document on this step; link the memo document, the Control items, the Issue action items, and the classify-disposition decision form it references.\n- Record the consistency checks performed, the proposed conclusion, and the reviewer conclusion with date as step notes.\n- For each confirmed-design Control, create (or link) the downstream SOX testing workflow directly on that Control; set Workflow.customFields.sox.fiscalYear and record the scoping rationale on its setup step. This is the handoff package SOX Key Control TOD/TOE Test consumes. Route gapped controls to the Control Design workflow instead.\n- Record this walkthrough workflow and memo-document references on each downstream workflow's setup step (and on the design-workflow handoff); the SOX workflow's direct Control host supplies the control association. Record per handoff the date, destination (test versus design), do-not-repeat boundaries, dated dependencies, and the receiving owner's acknowledgment as step notes.\n- Set the workflow instance's final status as the immutable audit trail; record the archive confirmation, retention basis, next annual-refresh due date (Process has no refresh-date field — kept as step notes here), and communication recipients with dates on this step.\n- Confirm the anchor Process item links the current memo as its standing narrative, and that each Control item reflects the memo link and walkthrough date.\n\n**Exit criteria** — The package is attached with every referenced record linked; the internal-consistency checks pass; the proposed conclusion is stated; the reviewer has signed; residual constraints are explicit with owners. Every approved control has an acknowledged handoff to testing or design; do-not-repeat boundaries are explicit; calendar dependencies are dated; no control was handed off with unresolved identification questions left unflagged; all steps are dispositioned; the package is archived with the confirmation recorded; process and control records are updated; the next refresh date and every follow-up have owners; closure is communicated; post-archive corrections are understood to be new dated addenda.","label":"Handoff to related workflow","requiredApprovals":1},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-walkthrough"}