{"description":"Runs directly on an existing SOX-applicable Control for the fiscal year, using the approved walkthrough, scope, methodology and evidence. Produces an independently approved TOD memo before sampling, period-specific TOE results and reviewed exception evidence for interim/year-end assessment and deficiency remediation. Require that the Control fields.sox_applicable value is the literal boolean true; use Workflow.customFields.sox.fiscalYear for the cycle. TOD/TOE test periods remain step-level facts.","edges":[{"id":"e-lock-executable-workplan-roll-forward-pbc-request-list","source":"lock-executable-workplan","target":"roll-forward-pbc-request-list"},{"id":"e-lock-executable-workplan-confirm-design-effectiveness","source":"lock-executable-workplan","target":"confirm-design-effectiveness"},{"id":"e-confirm-design-effectiveness-select-samples","source":"confirm-design-effectiveness","target":"select-samples"},{"id":"e-select-samples-execute-attribute-testing","source":"select-samples","target":"execute-attribute-testing"},{"id":"e-roll-forward-pbc-request-list-execute-attribute-testing","source":"roll-forward-pbc-request-list","target":"execute-attribute-testing"},{"id":"e-execute-attribute-testing-reviewer-sign-off","source":"execute-attribute-testing","target":"reviewer-sign-off"},{"id":"e-reviewer-sign-off-classify-disposition","source":"reviewer-sign-off","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"remediate"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clean"},{"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-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":"control","metadata":{"capabilities":[],"controlVerbs":{"UC-AUDIT-21":"operates"},"controls":["UC-AUDIT-21","UC-FIN-02","UC-FIN-03","UC-FIN-04","UC-FIN-09","UC-FIN-06","UC-FIN-07","UC-FIN-08","UC-FIN-10"],"department":"internal-audit","domains":["sox"],"kind":"sox-testing","library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-key-control-tod-toe-test","contentDigest":"sha256:8f06171750e61dd0269bfcc6968910fe46768d003ca2c581fc617c39ef1fff42","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8f06171750e61dd0269bfcc6968910fe46768d003ca2c581fc617c39ef1fff42","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-key-control-tod-toe-test"},"lifecycleContract":{"absorbedNodeIds":{"assign-tester":"lock-executable-workplan","log-exceptions":"execute-attribute-testing","prepare-final-package":"handoff-to-related-workflow","validate-ipe":"select-samples"},"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":"Commit capacity, independent assignments, methodology and achievable dates.","interventions":["approval","expertise"],"nodeId":"lock-executable-workplan","requiredApprovals":1,"role":"IA/SOX testing lead"},{"contribution":"Resolve evidence feasibility, missing generation facts and period/scope mismatches before use.","interventions":["expertise"],"nodeId":"roll-forward-pbc-request-list","requiredApprovals":1,"role":"Tester with named control-owner respondents"},{"contribution":"Approve the exact-version TOD conclusion before sampling or interim TOE.","interventions":["expertise","approval"],"nodeId":"confirm-design-effectiveness","requiredApprovals":1,"role":"Independent design reviewer"},{"contribution":"Approve population/IPE sufficiency, sample basis and exception policy before testing.","interventions":["expertise"],"nodeId":"select-samples","requiredApprovals":1,"role":"Independent testing methodology reviewer"},{"contribution":"Conclude every attribute from evidence and assess exceptions without replacing failed samples.","interventions":["expertise"],"nodeId":"execute-attribute-testing","requiredApprovals":1,"role":"Independent control tester"},{"contribution":"Reperform evidence traces and approve period/version-specific testing with review notes closed.","interventions":["expertise","approval"],"nodeId":"reviewer-sign-off","requiredApprovals":1,"role":"Independent test 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":"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"}],"nativeTestingContract":{"anchor":"control","applicability":"literal boolean true","fiscalYear":"Workflow.customFields.sox.fiscalYear","kind":"sox-testing","preserveInstalledResultFields":true,"resultLocation":"Control-hosted test step and validated sox-results.json document"},"version":1},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"sox-key-control-tod-toe-test","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["internal-audit","finance"]},"name":"SOX Key Control TOD/TOE Test","nodes":[{"data":{"description":"Lock the executable workplan","instructions":"**Objective** — Freeze the who, what, and when of this test — scope, owners, dates, evidence standards, and review chain — so execution starts from commitments instead of moving targets.\n\n**Human contribution** — IA/SOX testing lead (approval, expertise): Commit capacity, independent assignments, methodology and achievable 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 existing Control this workflow runs on — require Control.fields.sox_applicable to be the literal boolean true; take the cycle from Workflow.customFields.sox.fiscalYear, while the test period remains defined in this workplan.\n- Walkthrough facts consumed from the handoff package from SOX Process Walkthrough — documents at sox-walkthrough/handoff-to-related-workflow for this same Control, including the issued Design Request Tracker and received evidence: control frequency, population source, IPE inventory, and evidence artifacts.\n- The Control item's scope drivers — Control.key_control, Control.frequency, Control.control_type, Control.automation, the risk rating on the linked Risk (Control ↔ Risk), prior-period results, any mid-period control change, multiple locations or instances, and external-auditor reliance demands — that determine whether the sample is standard or expanded.\n- The program calendar (certification dates, external-auditor reliance deadlines, close blackout weeks) and the performance-materiality memo — program documents with no native item type, attached or referenced at this step.\n- The sampling, exception, and severity methodology — a Policy item (policy_type: procedure, with policy_owner and version), its governing document attached to that item.\n- Existing annual scope, dates and evidence standards; produce this test’s locked workplan during this checkpoint.\n- The Control item: Control.control_owner, Control.automation (manual / automated / hybrid), Control.control_type, and the subject matter in Control.description (revenue recognition, access management, valuation, and so on).\n- Candidate testers' roles, reporting lines, and prior involvement with this control — staffing context with no native home in AssureSwarm.\n\n**Procedure**\n*Agent preparation and filing absorb “Assign tester”; the role named below owns the substantive review.*\n1. Confirm final scope in one place: control ID and version(s), test period(s), the TOD procedure (design evaluation against the walkthrough baseline), and the TOE approach (attribute testing over a frequency-based sample).\n2. Fix the calendar: PBC issue date, evidence due dates, fieldwork window, review window, and the hard stop imposed by certification or auditor reliance. Work backwards from the hard stop — if the arithmetic does not fit, escalate scope or dates now.\n3. Confirm the review chain: tester, then a reviewer independent of and senior to the tester, plus any QA or PMO layer this control's risk rating requires.\n4. Set evidence standards up front: what each sample item's evidence must show (performer, date, input report with visible parameters, action taken, disposition of flagged items), file naming, and where evidence lives in AssureSwarm. If the external auditor relies on this work, apply their evidence expectations from day one — retrofitting screenshots months later is misery.\n5. State the methodology version being followed — cite the methodology Policy item and its version (sampling policy, exception policy, severity framework) — so a reviewer two years from now can reconstruct the rules of the game.\n6. Lock it: from here, scope or date changes are logged change events with the test lead's concurrence — not quiet edits.\n\n7. Screen for independence: the tester must not perform the control, own it, supervise the performer, or have designed or remediated it. Testing your own remediation is self-review — reassign, or where staffing truly cannot avoid it, document the safeguard (for example, the reviewer independently reperforms a portion of the sample).\n8. Match competence to the control's subject matter: IT-dependent and automated controls need a tester who can read configurations and evaluate ITGC linkage; estimate and valuation controls need someone who can challenge assumptions, not just trace sign-offs.\n9. Confirm capacity against the locked calendar — an overloaded tester defaults to thin evidence exactly when reliance demands thick evidence.\n10. Confirm the reviewer pairing: independent of the tester's work, senior enough to overrule the conclusion, and never the control owner.\n11. Brief the tester: the walkthrough facts, the evidence standards, the reliance posture, and the current PBC list status — so chasing continues without a gap.\n\n12. Review enhancements needed in test procedures and relevant fields against the current control description, prior findings, changed systems and auditor methodology. Produce a versioned procedure/field change register: existing field key or result attribute, missing fact, data type, affected reports and consumers, proposed change, rationale and migration impact.\n13. The methodology owner approves procedure changes before sampling or evidence evaluation. A tenant schema administrator separately reviews any actual field/schema change through the supported change path, validates compatibility and a representative test record, and records the before/after versions and approval evidence. If the current schema lacks the field, attach the change proposal and block only work that depends on it; never invent a field or silently alter the published testing-results contract.\n14. Inspect the stored Control-hosted template and step schema before execution. Preserve metadata.kind=\"sox-testing\", literal Control.sox_applicable=true, Workflow.customFields.sox.fiscalYear and step-level TOD/TOE period/kind. Preserve any installed testing-result fields and publish the supported sox-results.json evidence document on the testing step; its validated grade and evidence matrix feed the tracker. Ordinary approval and analysis do not need collection forms.\n\n**Record in AssureSwarm**\n- Attach the locked workplan to this step as a document (DOCX/PDF): scope, calendar, review chain, evidence standards, and the cited methodology Policy item with its version. The materiality memo and program calendar attach here too — they have no native item type.\n- Set the workflow instance's due dates to match the locked calendar.\n- Assign the tester and reviewer on this step's workflow assignments; record their roles in the locked workplan and this step's result.\n- Record the independence screen result and the competence rationale on this step — there is no native field for them; document any safeguard applied to a residual conflict.\n\n**Exit criteria** — Scope, calendar, review chain, evidence standards, and methodology reference are recorded; the calendar closes against the hard stop; any later change requires a logged concurrence. Tester and reviewer are assigned with documented independence and competence; capacity fits the locked calendar; the handoff briefing (walkthrough facts, evidence standards, PBC status) is complete.","label":"Lock executable workplan","requiredApprovals":1},"id":"lock-executable-workplan"},{"data":{"description":"Agent rolls the prior cycle's Prepared-By-Client request list into the current cycle with advanced period references, refreshed due dates, and a prior-cycle evidence comparison; human tester confirms each request with its owner before the list is issued","instructions":"**Objective** — Stand up the current cycle's Prepared-By-Client (PBC) evidence-request list by rolling the prior cycle's list forward instead of rebuilding it, so every recurring request carries an advanced period reference and a refreshed due date, and each request is paired with the prior-cycle evidence it should resemble — surfacing year-over-year drift before testing starts.\n\n**Human contribution** — Tester with named control-owner respondents (expertise): Resolve evidence feasibility, missing generation facts and period/scope mismatches before use. 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 prior cycle identifier to copy from and the current cycle identifier to populate.\n- The anchor or start date the new due dates offset from.\n- The locked workplan (document on the lock-executable-workplan step) naming the in-scope control and its owner.\n- The prior fiscal year's qualifying sox-testing workflow on this Control, matched by Workflow.customFields.sox.fiscalYear: the PBC request list on its roll-forward step and the evidence documents linked from it.\n\n**Procedure**\n1. *(Agent)* Query the prior cycle's PBC request list (the tracked XLSX on the prior run's roll-forward step), capturing for each request: description, requested file kind, period reference, owner, prior due-date offset, and the linked prior-cycle evidence document(s).\n2. *(Agent)* For each request, advance the period string to the matching current-cycle period (for example, \"Q1 2025\" becomes the current cycle's corresponding quarter) and compute the new due date by applying the prior offset to the current cycle's anchor date. Never carry a stale period label or last cycle's calendar date forward unchanged.\n3. *(Agent)* Build the current-cycle PBC request list as rows in a tracked XLSX on this step — there is no PBC-request item type, so the list on the step is the honest home — one row per request with control, named owner, period reference, due date, and status, carrying the prior-cycle evidence as a \"reference: prior-year evidence\" pointer — referenced, not copied — so reviewers can compare against last cycle's actual file to detect drift.\n4. *(Agent)* Build a prior-cycle-versus-expected comparison table listing, per request, the prior-cycle evidence (file kind, period, owner) beside the expected current-cycle evidence, flagging any request whose owner changed, whose file kind differs, or that had no prior-cycle evidence at all. Attach the table to this step.\n5. *(Human checkpoint)* The tester reviews the rolled-forward list and the comparison table: confirm each request's owner, period, and due date; remove requests no longer in scope; add newly required ones (new evidence artifacts identified by the walkthrough); and confirm each owner can actually produce the requested evidence before the list is issued.\n6. Issue the list to each named owner through the authorized request channel; retain returned evidence, generation facts and the owner’s attributed completeness statement as step documents and native results, then track each open request's aging — days open since issuance, and due-in / overdue against its due date. A request whose submission arrives is done: close its row on receipt, no reminder needed. For requests going stale, send reminder nudges as drafts the tester reviews and sends — never auto-send.\n7. If the roll-forward must be re-run for the same cycle, produce a fresh request batch and retire the superseded batch — never edit an issued batch in place.\n\n8. Consume the issued design requests and received evidence from sox-walkthrough/handoff-to-related-workflow; the initial design batch is produced at sox-walkthrough/walk-the-flow. Label each additional outgoing owner-request batch as design, interim or year-end and bind its Workstream destination, named control-owner respondents, exact period, due dates and authorized sender. Keep incoming external-auditor PBC requests and the response evidence issued to the auditor in a separate register; they cannot substitute for issuing requests to control owners.\n9. Reuse evidence already available for the same request/version/period and ask the owner only for missing evidence or generation facts. Separate received, partially received, unavailable and validated states: receipt alone does not prove completeness or IPE accuracy. Record actual dispatch and receipt evidence; unavailable bindings or outreach authority leave the batch prepared, not issued.\n\n**Record in AssureSwarm**\n- Attach the rolled-forward PBC request list to this step as an XLSX — one row per request with owner, advanced period reference, due date tied to the anchor, status, and prior-year evidence reference. There is no PBC-request item type; this tracked list on the step is where requests live.\n- Attach the prior-versus-expected comparison table (XLSX) to this step.\n- Upload owner-submitted PBC evidence as it arrives and bind it to its request row. Record the actual covered period, file reference, source system/report/query, parameters, run date and generator, submission status, missing evidence and explanation, and the owner’s attributed completeness statement in the PBC tracker and native step result. Receipt changes receipt status only; validation and exception evaluation remain explicit.\n- Note the issuance date and owner-confirmed adjustments on this step; a \"not available\" or partial submission is carried into testing as a potential exception, not quietly dropped from the list.\n\n**Exit criteria** — The issued PBC request list with owner assignments and due dates, plus the prior-cycle comparison table, are attached and referenced; every request carries an advanced period reference, a due date tied to the current anchor, a named owner, and a prior-cycle reference wherever one existed — so control testing begins from an agreed, drift-checked evidence set.\n\n\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` drafts the redaction-gated reminder nudges for open PBC requests — drafts only, the tester reviews and sends; submitted requests auto-close and are never nudged.","label":"Roll forward the PBC evidence-request list","performedBy":{"agent":"sox-artist","note":"rolls prior-cycle PBC requests forward and drafts the year-over-year evidence comparison for tester review","primitives":["coach-query-data","coach-item-create","coach-items-link","coach-document-upload","coach-notify"]},"requiredApprovals":1},"id":"roll-forward-pbc-request-list"},{"data":{"description":"Conclude on test of design (TOD): whether the control, as designed, can catch the mapped risk","instructions":"**Objective** — Conclude on test of design (TOD): whether this control, as it actually operates, is capable of preventing or detecting a material misstatement in the mapped assertion — before any operating-effectiveness sampling is spent on a design that could not succeed even when performed perfectly.\n\n**Human contribution** — Independent design reviewer (expertise, approval): Approve the exact-version TOD conclusion before sampling or interim TOE. 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 walkthrough package handed off from SOX Process Walkthrough (documents at sox-walkthrough/handoff-to-related-workflow): as-performed control description, single-instance trace evidence, IPE inventory.\n- The RCM linkage: the Control ↔ Risk relationship (Risk.category: financial_reporting) for the mapped risk; account, assertion(s), and COSO principle live as prose in Control.description and the walkthrough handoff package — they have no native fields.\n- Materiality context: the performance-materiality memo attached at lock-executable-workplan, and the size of error this control must catch.\n\n**Procedure**\n1. Keep TOD and TOE distinct. TOD asks \"could this design work?\"; TOE (the later sampling steps) asks \"did it actually operate?\". A control can pass TOD and fail TOE — well designed, sloppily performed. It can also fail TOD outright, and no sample can rescue a design that cannot catch the risk.\n2. Test the risk linkage: does the control's action actually address the mapped risk and assertion? A reconciliation control mapped to a valuation risk it never touches is a design gap regardless of how faithfully it runs.\n3. Evaluate precision: at what error size does this control fire? For review and reconciliation controls, compare the investigation threshold to materiality — a review that only chases items above $1M cannot address a risk where $200K errors aggregate to material. Precision includes the level of aggregation reviewed: entity-level totals hide account-level errors.\n4. Evaluate timeliness and frequency: does the control operate soon enough, and often enough, to catch the error before it reaches reporting? A quarterly review over a daily feed leaves a quarter of undetected exposure.\n5. Evaluate the performer: competence and the authority to challenge (a junior preparer \"reviewing\" a CFO entry is design theater), and segregation — the performer must not review their own work.\n6. For management review controls, pin down what the reviewer actually does: the criteria for flagging an item, and the residue a real challenge leaves (annotations, follow-up emails, corrections booked). \"Reviews the report and signs\" with no defined investigation criteria is a design weakness, not a style choice.\n7. For automated and IT-dependent controls: identify the specific configuration that enforces the control, confirm it is covered by effective ITGCs (change management, access), and evaluate the design evidence here: identify source reports, parameters and investigation thresholds; tie the walkthrough report’s completeness to source totals and trace accuracy to underlying records before relying on it for TOD. Attach that design-evidence assessment to this checkpoint. The later select-samples checkpoint separately validates the testing-period population and IPE before TOE; TOD does not depend on that later output.\n8. Conclude: design effective, or design deficiency. A design deficiency generally makes TOE of that control version pointless — record the deficiency now (it flows through the exception log to disposition), state whether a redesigned version exists to test instead, and decide with the test lead whether limited TOE still serves a purpose (for example, supporting a compensating-control argument).\n\n9. The independent design reviewer must approve the TOD memo for the exact control version and period through this step’s native approval before select-samples or any interim TOE begins. Assign a reviewer who did not perform, design, remediate or test the control. Record approval of either effective design or a bounded diagnostic/compensating-control test purpose; a design failure cannot be approved as effective merely to unlock TOE.\n10. For a failed design, attach the deficiency and remediation dependency, keep reliance blocked, and identify any redesigned version requiring fresh TOD approval. Downstream interim and year-end workflows must verify this native approval and version match before consuming test results.\n\n**Record in AssureSwarm**\n- Attach the TOD conclusion memo to this step as a document, with the supporting analysis: risk linkage, precision and threshold arithmetic, timeliness, performer, IPE linkage.\n- Note any design gap on this step as a draft entry — it becomes an Issue (issue_type: exception, source: sox_testing) at the execute-attribute-testing step.\n- Link the walkthrough evidence relied on from this step.\n\n**Exit criteria** — A written TOD conclusion exists, grounded in the walkthrough trace; the precision analysis is explicit (numbers, not adjectives); any design gap is logged and the TOE path forward is a deliberate, recorded decision.","label":"Confirm design effectiveness","requiredApprovals":1},"id":"confirm-design-effectiveness"},{"data":{"description":"Define the population and draw a reproducible, frequency-sized TOE sample with a pre-committed exception policy","instructions":"**Objective** — Define the population and draw the TOE sample so the operating-effectiveness evidence is defensible, reproducible, and sized to the control's frequency and risk.\n\n**Human contribution** — Independent testing methodology reviewer (expertise): Approve population/IPE sufficiency, sample basis and exception policy before testing. 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- Control.frequency and the risk rating on the linked Risk (Control ↔ Risk), plus the walkthrough facts.\n- The population source identified in the walkthrough package (system, report, query) and the locked test period boundaries from the workplan.\n- The program's sampling policy if one exists (else the default buckets below) — the methodology Policy item cited in the locked workplan — plus any expansion multiplier set there.\n- The IPE inventory from the walkthrough package (report names, source systems) plus the population file from the sampling step.\n- The parameters used at report generation, and access to the source system (or its report owner) for reperformance.\n- Prior-period IPE validation or report baselining, if the program maintains one.\n\n**Procedure**\n*Agent preparation and filing absorb “Validate IPE”; the role named below owns the substantive review.*\n1. Define the population before touching a sample: every instance the control should have operated on during the period. Pull it from the source system with parameters visible, then check completeness — row count ties to the source total, and min/max dates sit inside (and fill) the period. A gap of even one day voids the draw. The population file is IPE: validate it within select-samples using the completeness and accuracy procedure below before drawing the sample or relying on results.\n2. Size the sample from frequency and risk. Standard buckets: daily or more frequent → 25; weekly → 5–10; monthly → 2–5; quarterly → 2; annual → 1. Apply the locked workplan's expansion multiplier at elevated risk (+25–50%). Event-driven controls: size against the actual population — if it is smaller than the bucket, test the lesser of the bucket or all instances. Automated controls: test one instance per configuration variation and rely on ITGCs for the period, rather than sampling repetitions of the same code path. Record which bucket applied and why.\n3. If the plan splits interim and roll-forward, allocate now (for example, 20 of 25 at interim, 5 covering the roll-forward window) and record the split.\n4. Choose the selection method: random for homogeneous populations; monetary-unit or stratified when items carry values and misstatement risk scales with size; judgmental only with a documented reason (for example, all manual entries above a threshold); haphazard never.\n5. Draw reproducibly: record the seed or the exact selection mechanics so a reviewer can regenerate the identical sample from the same population file. Save the draw parameters with the sample list.\n6. Pre-commit the exception policy before any evidence arrives: on the first exception, either expand (state the increment now — daily 25 → 40 total; monthly 2 → 5 total) or stop and evaluate as a deficiency. Deciding after seeing results is outcome-shopping and voids the workpaper's integrity. Pre-commit two more rules: missing evidence counts as an exception, and sample items are never swapped for \"better\" ones.\n\n7. Inventory each IPE item this test touches, in both directions: reports the control consumes to operate (its input data) and files the tester uses to test (the population, exports). Both are IPE; both need validation.\n8. Capture generation evidence per item: source system, report or query name, parameters as run (screenshot or saved parameter set), run date, and who ran it. A report without visible parameters is a report you cannot rely on.\n9. Test completeness: tie a control total from the report to its source — record count against the system's own count, or a summed total (amount or hash total) reconciled to the GL or module total for the same period. Confirm period boundaries: the earliest and latest records bracket the full test period.\n10. Test accuracy: trace a few rows' key fields back to source records, and one source record forward into the report to cover item-level completeness. For a standard system report already baselined under the program with ITGCs effective, current-period validation can be lighter — parameter check plus the completeness tie — and must cite the baseline.\n11. Custom queries and scripts: inspect the logic (filters, joins, date clauses) or independently reperform the extraction. An undocumented WHERE clause is where populations quietly lose rows.\n12. Lock each validated file: attach the exact validated version to this workflow and treat it as read-only from here — testing against a file that kept changing after validation is testing nothing. If an IPE item feeds multiple key controls, or needs deep source-query reperformance beyond this tester's access, note it now — the shared SOX IPE Validation workflow can validate such a report once for reuse across controls; coordinate that separately rather than blocking this test.\n\n**Record in AssureSwarm**\n- Attach the locked population file and the sample list to this step as documents (XLSX/CSV), with draw parameters (population size, sample size, bucket applied, method, seed).\n- Record the sample basis and the pre-committed exception policy on this step, timestamped.\n- Note the interim/roll-forward allocation on this step if the sample is split.\n- Attach each validated IPE file to this step as a locked document, with its parameter evidence and the completeness/accuracy tie-out working (XLSX).\n- Record IPE status per item on this step: validated, validated-via-baseline, or open (with what is blocking).\n- Note on this step any report better validated once via the shared SOX IPE Validation workflow.\n\n**Exit criteria** — Population completeness is documented; the sample size traces to the frequency/risk bucket and the workplan's expansion multiplier; the draw is reproducible from recorded parameters; the exception policy is pre-committed and timestamped before any testing began. Every IPE item this test relies on is validated in-line (or, where a report feeds multiple controls, noted for the shared SOX IPE Validation workflow) with parameters, a completeness tie, and an accuracy trace documented; validated files are attached and locked; no testing conclusion will rest on an unvalidated report.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans the control's test and draws this sample with a recorded seed; `/sox-python` makes the draw and any threshold checks deterministic and re-runnable. `/sox-python` recomputes the completeness ties (row counts, control totals, period boundaries) deterministically, so the tie-out is re-runnable rather than hand-checked.","label":"Select samples","performedBy":{"primitives":["coach-query-data","coach-document-upload","sox-testing","sox-python"]},"requiredApprovals":1},"id":"select-samples"},{"data":{"description":"Evaluate every sample item against the control's attributes — agent drafts the pass/fail, the human tester concludes","instructions":"**Objective** — Execute the test of operating effectiveness (TOE): evaluate every sample item against the control's defined attributes and produce an annotated, reperformable workpaper with a draft pass/fail per attribute — drafted by the agent, concluded by the human tester.\n\n**Human contribution** — Independent control tester (expertise): Conclude every attribute from evidence and assess exceptions without replacing failed samples. 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 locked sample list with draw parameters, and the validated population and IPE files.\n- Evidence received through the PBC list, mapped to sample items.\n- The as-performed control description (the source of the attributes) and the pre-committed exception policy.\n- Create the attribute-testing results matrix and annotated workpaper during this checkpoint; use them for exception evaluation after completing the attributes.\n- The pre-committed exception policy from the sampling step (expansion increment or stop-and-evaluate; missing evidence counts as an exception).\n- The control performer and owner, for root-cause inquiry and management response.\n\n**Procedure**\n*Agent preparation and filing absorb “Log exceptions”; the role named below owns the substantive review.*\n1. Define the attributes before opening evidence — each one an independently testable assertion of the control's operation, taken from the as-performed description. For a monthly reconciliation control, for example: (A) prepared by the assigned role within 5 business days of month-end; (B) preparer and approver are different people; (C) reconciling items above the stated threshold investigated, with resolution documented; (D) approver sign-off dated after preparation and before close. Every attribute must be observable in evidence — an attribute you cannot see, you cannot test.\n2. Map evidence to sample items one-to-one before evaluating anything. Missing or unresponsive evidence is not a hole to wait on indefinitely: once the chase has run its course, a sample item without evidence is an exception under the pre-committed policy — never quietly replace the item.\n3. Evaluate each attribute per item as pass, fail, or N/A. Apply the evidence-of-performance standard: a signature or checkbox proves existence, not performance. Review-type attributes need the residue of a real review — annotations, follow-up threads, corrections booked, items cleared. N/A must carry its reason (\"no reconciling items above threshold this month\"); N/A without a reason is a fail waiting for review.\n4. Check evidence timing and provenance: evidence must be contemporaneous with the control's operation in the period. A screenshot recreated during fieldwork shows today's state, not April's operation — usable only for attributes about current configuration, and an exception for period-specific performance attributes.\n5. Where the control involves a computation (thresholds, totals, aging), recompute it independently rather than accepting the on-paper result.\n6. Annotate as you go: tickmarks on each evidence file tying it to sample item and attribute, with a tickmark legend, so the workpaper reads without the tester in the room. No partial credit — a \"pass with comment\" that conceals a deviation is a fail; record what actually happened.\n7. The agent drafts the attribute-level pass/fail determination per sample item; the human tester reviews each draft against the annotated evidence and owns the final call on every line. Zero exceptions is a finding too — record \"no exceptions noted\" affirmatively, with the coverage that supports it.\n\n8. For each failed attribute — including missing-evidence items — create one exception record capturing: control ID and version, sample item, attribute failed, condition (what the evidence shows happened versus what the control requires), and the evidence reference.\n9. Run the root-cause inquiry with the performer and owner: isolated slip, or systematic (performer turnover, volume spike, missing guidance, system change)? Capture management's response verbatim — severity arguments later live or die on whether the cause was isolated.\n10. Hold the line on what clears an exception: it stops being an exception only if investigation shows it never was one — the evidence existed and is now located, or the item was outside the control's stated scope. \"The reviewer says they looked at it,\" with no residue, clears nothing.\n11. Apply the pre-committed policy exactly as written. If expand: draw the stated increment from the same locked population with the same method, test it, and log those results — a clean expansion over an isolated, remediated cause may still support effectiveness; a second exception in the expansion almost never does. If stop-and-evaluate: close testing and carry the exceptions to disposition. If circumstances genuinely force a policy change, it needs the reviewer's written concurrence, and the original policy stays visible in the record.\n12. Compute the deviation rate (exceptions over items tested, per attribute) and face the small-sample reality: in monthly (2–5) or quarterly (2) samples, a single deviation generally cannot support \"operating effectively\" without expansion.\n13. If there are no exceptions, record that affirmatively — \"no exceptions noted across N items × M attributes\" — so silence reads as a conclusion, not an omission.\n\n14. Evaluate every exception’s cause, extent, affected population, period, controls, financial-statement lines and assertions. Apply the precommitted expansion rule above; attach a Control Impact Assessment documenting likelihood, magnitude, related exceptions and evidenced compensating controls.\n15. Submit each testing exception and its supporting facts to accountable management for feedback and agreement through the authorized channel. Record the exact package/version, recipients, dispatch and response evidence, disputed facts and IA disposition. Silence remains unresolved; management disagreement does not remove an exception.\n16. Draft reportable control deficiencies with condition, criteria, cause, effect, recommendation and severity rationale. Link the supporting Issue and hand the package to sox-deficiency-remediation/open-and-grade-the-deficiency; related deficiencies proceed to sox-deficiency-aggregation-evaluation/evaluate-severity-by-group. These are downstream completion obligations, not prerequisites for drafting the source testing exceptions.\n\n**Record in AssureSwarm**\n- Attach the annotated attribute-testing workpaper to this step as an XLSX: the results matrix (sample item × attribute), tickmarked evidence files, recomputation support.\n- Record per-item, per-attribute results on this step with the draft-versus-final trail (what the agent drafted, what the tester concluded).\n- Update the document links on this step so every sample item points at its supporting evidence files.\n- Create one Issue per exception — issue_type: exception, source: sox_testing, severity, description (the condition and evidence reference), root_cause, management_response, identified_date — linked Issue ↔ Control and back to this workflow's evidence package.\n- Record the policy application (expansion draw parameters and results, or the stop decision) and the deviation rate on this step.\n\n**Exit criteria** — Every sample item has mapped evidence or a logged exception; every attribute has a concluded pass, fail, or N/A-with-reason; computations are reperformed; the workpaper is tickmarked and legible standalone; the human tester has explicitly confirmed every drafted determination. Every failed attribute maps to a linked exception Issue with condition and root cause; the pre-committed policy was applied verbatim, or its change carries reviewer concurrence; deviation rates are computed; a zero-exception result is affirmatively recorded.\n\n> **⚡ Audit Artist accelerator:** `/sox-test` runs this testing step in-AssureSwarm end-to-end; `/sox-testing` does the mechanical tick-and-tie (evidence-to-sample mapping, annotated extraction, workpaper assembly), `/sox-evidence` stamps the tickmark annotations into the evidence workbooks, and `/sox-python` reperforms every computation deterministically — the process, judgments, and sign-offs stay with this workflow.","label":"Execute attribute testing","performedBy":{"agent":"sox-artist","note":"drafts the attribute-level pass/fail determination for human reviewer sign-off","primitives":["coach-document-upload","sox-test","sox-testing","sox-evidence","sox-python","coach-item-create","coach-items-link"]},"requiredApprovals":1},"id":"execute-attribute-testing"},{"data":{"description":"Independent reviewer reperforms a slice, clears review notes, and records a dated, scoped sign-off","instructions":"**Objective** — Obtain an independent reviewer's evidenced conclusion that the testing is complete, supported, and reperformable — the quality gate between fieldwork and any severity or certification consequence.\n\n**Human contribution** — Independent test reviewer (expertise, approval): Reperform evidence traces and approve period/version-specific testing with review notes closed. 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 full working set: TOD conclusion, sample basis with draw parameters, IPE validation, annotated workpaper, exception records with the policy application.\n- The locked workplan (evidence standards, methodology reference) to review against.\n\n**Procedure**\n1. Confirm reviewer independence: not the tester, not the control owner, and senior enough to overrule the tester's conclusion.\n2. Review structure first: the sample size traces to the policy bucket and the workplan's expansion multiplier; population completeness is documented; IPE was validated before results were relied on; the exception policy was pre-committed before testing.\n3. Reperform a slice: re-open one or two sample items, follow the tickmarks from evidence to conclusion, and independently re-derive the pass/fail. If the reviewer cannot reproduce the tester's conclusion from the workpaper alone — without asking the tester anything — the workpaper fails the reperformability standard and goes back.\n4. Challenge the judgments, not just the arithmetic: the attributes actually cover the control's risk; N/A reasons hold; the evidence-of-performance standard was applied (no sign-off-only passes on review attributes); root causes are supported, not asserted; and the effectiveness conclusion is consistent with the exception record — no \"effective\" sitting on unresolved exceptions.\n5. Raise review notes on this workflow; the tester clears each with evidence; the reviewer — never the tester — closes each note. Unresolved notes block sign-off.\n6. Give native approval with name, date, and the scope of the sign-off (TOD, TOE, period, control version); the reviewer is neither the tester nor the control owner. Partial sign-offs — interim only, one version of a changed control — say so explicitly.\n\n**Record in AssureSwarm**\n- Record review notes and their clearance trail on this step.\n- Record the sign-off on this step: reviewer, date, scope, and the conclusion endorsed.\n\n**Exit criteria** — The reperformance slice succeeded from the workpaper alone; all review notes are closed by the reviewer; a dated, scoped sign-off is recorded by someone independent of the testing.","label":"Reviewer sign-off","requiredApprovals":1},"id":"reviewer-sign-off"},{"data":{"decisionField":"disposition_path","description":"Classify the result of SOX Key Control TOD/TOE Test 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 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**Objective** — Classify the tested control's result — clean, remediation-track deficiency, or escalation — using the severity framework, so the right closure path runs and certification stakeholders see the issue at its true size. Proposed by the tester; owned by the reviewer or test lead per the program's severity authority.\n\n**Decision criteria**\nSeverity comes first for any gap: assess magnitude (could the misstatement this control fails to catch be material? size it from the account balance and exposure, not just the errors observed) and likelihood (is recurrence reasonably possible?), then adjust for compensating controls — which mitigate nothing unless they were themselves tested — and aggregate with other known deficiencies hitting the same account or assertion.\n- **clean** (No reportable gap) — TOD effective AND TOE produced no exceptions, or every logged exception was resolved as not-a-deviation with documented basis (the evidence was located; the item was out of the control's scope). Expansion samples, if drawn, came back clean. Nothing to remediate; the affirmative conclusion is the output.\n- **remediate** (Remediation required) — a real gap exists, but preliminary severity lands at deficiency or significant deficiency: a design gap with a workable fix, or operating exceptions whose magnitude and likelihood — after tested compensating controls — do not reach a reasonable possibility of material misstatement. Significant deficiencies still ride the audit-committee reporting track; say so in the rationale. Route to the action-plan step.\n- **escalate** (Escalate significant issue) — indicators of material weakness or issues beyond this workflow's authority: an ineffective control over a material account with no effective compensating control; any fraud involving senior management, regardless of amount; a restatement or identified material misstatement traced to this control; aggregation across deficiencies reaching material-weakness territory; or external-auditor disagreement with the severity call. Route to the escalation step for the PMO and certification chain.\n\n**Record in AssureSwarm** — Submit this step's form: `disposition_path` = the chosen branch; the step result = the magnitude and likelihood reasoning, the compensating controls considered (with their own test status), and the aggregation checked; the step's approver record = the severity authority making the call.\n\n**Exit criteria** — Form submitted; the rationale shows the severity arithmetic rather than asserting a label; unused branches are prunable.","kind":"decision","label":"Classify disposition","requiredApprovals":1},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Produce an owned, dated, verifiable remediation plan that fixes the cause of the deficiency — not its symptom — inside the certification calendar's re-test window.\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 exception Issues (issue_type: exception, source: sox_testing) with root_cause and management_response, created at execute-attribute-testing.\n- The severity classification and rationale from the classify-disposition form.\n- The certification calendar (document at lock-executable-workplan): the as-of date and the re-test lead time this control's frequency requires.\n\n**Procedure**\n1. Restate the root cause past the first answer: \"the reviewer missed it\" is a symptom — keep asking why until the answer changes what you would fix (no threshold guidance, an untrained new performer, volume outgrew a manual control, the report arrived too late to review). The action must attack that answer.\n2. Define the remediation concretely: what changes (procedure, threshold, system configuration, staffing, automation), who performs the change, and what evidence its completion will produce.\n3. Assign ownership to the control owner — never the tester. The tester validates the fix later; owning it would be self-review at the re-test.\n4. Set the due date against re-test arithmetic: the remediated control must operate enough times before the as-of date to be testable. A monthly control remediated in November offers at most two instances by year-end — that supports only a thin conclusion; flag the risk now or accelerate the fix.\n5. Define interim mitigation while the fix lands — a compensating control or heightened monitoring, with its own owner — and note that it must be tested if anyone intends to rely on it.\n6. State the closure standard: what the remediation re-test will require (evidence of the new design operating, an expanded sample over the post-remediation period), so \"done\" is verifiable rather than declared.\n7. Set the reporting cadence: status to the SOX PMO until closure, plus the audit-committee track for significant deficiencies.\n\n**Record in AssureSwarm**\n- Create the deficiency Issue — issue_type: deficiency (or significant_deficiency, per the disposition's severity call), source: sox_testing, severity, root_cause, issue_owner, target_remediation_date — linked Issue ↔ Control, linked back to this workflow, and to the exception Issues sharing its root cause.\n- Record the remediation action, interim mitigation, closure standard, and reporting cadence in the Issue's remediation_plan.\n\n**Exit criteria** — The action plan attacks the stated root cause; it has a named owner and a due date that survives re-test arithmetic; interim mitigation exists with an owner; the closure standard defines the evidence that will end it.","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 a significant issue in front of the people accountable for certification — with quantified impact and options — and land a documented decision: escalate for treatment as a potential material weakness, or accept a bounded risk with authority, conditions, and an expiry.\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 disposition rationale and severity arithmetic (magnitude, likelihood, compensating controls, aggregation).\n- The affected accounts and assertions with their balances; the exception and deficiency records.\n- The escalation chain: SOX PMO, control owner, certifying officers; external-auditor communication obligations.\n\n**Procedure**\n1. Draft the decision memo: the issue in one paragraph; quantified impact (accounts and assertions affected, exposure size, periods); how it was found; the severity assessment with the compensating-control and aggregation analysis shown; the options (remediate-and-retest timeline, reliance on tested compensating controls, disclosure implications); and a recommendation.\n2. Route by severity. Potential material weakness, or fraud involving management: to the SOX PMO and certifying officers immediately, with external-auditor communication coordinated — they will learn of it, better by design than by discovery. Significant deficiency: to the PMO now, on the audit-committee reporting track. Do not sit on it pending \"one more check\" — escalation timing is itself examined later.\n3. Risk acceptance is available only below the significant-deficiency line and never for fraud indicators. It requires: a named acceptor with actual authority over the exposure, tested compensating controls named in the acceptance, an expiry or re-review date, and the conditions that void it (account growth, a repeat exception).\n4. Capture the decision: who decided, what was decided, the conditions attached, and follow-up ownership — who re-tests, who reports to the audit committee, who tracks the acceptance to its expiry.\n5. Feed the decision back into the disposition record so the final package reflects the outcome, not just the recommendation.\n\n**Record in AssureSwarm**\n- Attach the decision memo to this step as a document (DOCX/PDF); record the decider, date, decision, and conditions on this step.\n- If risk is accepted: create an Issue — issue_type: policy_exception, exception_approver (the named acceptor), exception_expiry_date (the expiry/re-review date), description (the conditions and the tested compensating controls) — linked to the mapped Risk and the Control, and set treatment: accept on that Risk.\n- Link the follow-up items (re-test task, acceptance-expiry review) with owners and dates.\n\n**Exit criteria** — A dated decision by someone with authority exists — escalated with certification-chain visibility, or accepted with named authority, tested compensating controls, conditions, and an expiry — and follow-up ownership is assigned.","label":"Escalate or accept risk","requiredApprovals":1},"id":"escalate-or-accept-risk"},{"data":{"description":"Handoff outputs to SOX Deficiency Remediation and close the test on the receiving owner's acknowledgment, preserving the audit trail","instructions":"**Objective** — Hand the deficiency work to SOX Deficiency Remediation with a package complete enough that it starts executing instead of re-investigating — with explicit boundaries on what it must not redo — and close the test on that acknowledgment 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- Everything produced upstream: TOD conclusion, sample basis, IPE validation, annotated workpapers, exception records, action plan or escalation decision, reviewer sign-off.\n- The disposition decision and its severity rationale.\n- The final package: conclusion, exceptions, root causes, severity rationale, action plan or escalation decision, and the reviewer sign-off.\n- The deficiency/action items created at the action-plan or escalation steps.\n- This workflow — the Control's per-fiscal-year test-status record identified by Workflow.customFields.sox.fiscalYear — and the program's retention policy.\n\n**Procedure**\n*Agent preparation and filing absorb “Prepare final package”; the role named below owns the substantive review.*\n1. Compile in workpaper order: (1) control identification and test period(s); (2) TOD conclusion with the precision analysis; (3) population and sample basis with draw parameters; (4) IPE validation evidence; (5) the annotated results matrix and tickmarked evidence; (6) exception records, expansion results, and the policy application; (7) severity rationale; (8) action plan or escalation memo; (9) reviewer sign-off with its scope.\n2. Run the reperformability check on the assembled whole: a competent stranger, given only this package, reaches the same conclusions — the sample regenerates from recorded parameters, every tickmark resolves, every conclusion cites its evidence.\n3. State the conclusion once, precisely scoped: control, version, period, TOD result, TOE result, exceptions and their disposition, severity. Ambiguity here becomes someone else's certification problem.\n4. List unresolved constraints honestly — evidence never produced, thinly covered periods, assumptions inherited from the walkthrough — so the downstream reader inherits the caveats instead of rediscovering them.\n5. Verify the links: the Control item, the exception Issues, the deficiency Issues — all navigable from the Control and this workflow.\n\n\n6. If the disposition was clean, record \"no deficiencies — no handoff required\" on this step and continue to the closing items; items 2–7 apply when deficiencies exist.\n7. Create or link one SOX Deficiency Remediation workflow per deficiency — not per exception: exceptions sharing a root cause travel together as one deficiency.\n8. Pass the package: the deficiency statement, root cause, severity classification with rationale, the action plan (owner, due date, interim mitigation, closure standard), the exception evidence references, and the re-test window arithmetic.\n9. State what downstream must not repeat: severity was classified here (remediation validates the fix — it does not re-litigate the rating unless new facts emerge); root-cause analysis is done (refine it if implementation reveals more, do not restart it); and the full-control TOE is not re-run — the remediation re-test scopes to post-fix instances per the closure standard.\n10. State what downstream owns: implementing the fix, evidencing it, the re-test at the stated standard, closure, and status reporting until closed.\n11. Transfer the caveats: unresolved constraints from the final package that touch remediation (for example, evidence the owner never produced — the fix may need to address evidence retention itself).\n12. Confirm receipt: the remediation owner acknowledges the package and its dates. That acknowledgment — or the clean-path note from item 1 — is what closes this test.\n13. Verify completion honestly: every step in this workflow is finished or explicitly dispositioned (skipped-with-reason), all decision forms are submitted, review notes are closed, handoffs are acknowledged. Closing over an open step is how audit trails grow holes.\n14. Archive the final package as the immutable record: attached versions are final, superseded drafts are marked as superseded, and nothing lives only in an inbox or on a laptop. SOX workpapers follow the program's retention policy — seven years is the standard anchor — and must stay retrievable, not merely retained.\n15. Confirm this workflow is the finished test record: its customFields.sox.fiscalYear cycle, assigned tester, scoped Test-step result, final evidence package, and links to exception and deficiency Issues. The Control remains the shared control record; this workflow is the cycle-specific status record that next cycle's roll-forward and the external auditor's reliance assessment will read.\n16. Schedule the forward obligations with owners, not just dates: remediation re-test, risk-acceptance expiry review, and next cycle's test.\n17. Communicate closure: the conclusion and severity (if any) to the control owner and SOX PMO; certification-relevant results into the certification tracking. Fold the PBC learnings — owner changes, chronically late evidence — into the notes the next roll-forward will read.\n18. Lock the workflow record: post-closure edits, if ever needed, happen as documented amendments — never silent changes.\n\n**Record in AssureSwarm**\n- Attach the compiled final evidence package (or an index document pointing at each attached component) to this step.\n- Record the scoped conclusion (operating_effectively | exceptions_noted | not_operating_effectively) in this workflow's Test-step result and final evidence package; do not write a cycle-specific conclusion onto the Control.\n- Record the open-constraints list on this step.\n- Link each SOX Deficiency Remediation instance — anchored on its deficiency Issue — to this workflow and its Control host.\n- Record on this step the handoff date, the do-not-repeat boundaries, and the receiving owner's acknowledgment — or the clean-path \"no handoff required\" note.\n- Close and archive the workflow instance — the run itself is the durable audit trail; record the retention basis and the communication recipients with dates on this step.\n- Confirm the workflow reflects the final result, tester, fiscal-year cycle, and Control/Issue links.\n\n**Exit criteria** — The package reads standalone and reperformable; the conclusion is scoped to control, version, and period; constraints are explicit; every referenced record is linked. Each deficiency has a linked remediation workflow with an acknowledged package, explicit do-not-repeat boundaries, and dates aligned to the certification calendar — or the clean-path note is recorded and nothing is handed off; all steps are dispositioned; the package is archived and immutable; the workflow result is updated; follow-ups are scheduled with owners; closure is communicated; the record is locked against silent edits.","label":"Handoff to related workflow","requiredApprovals":1},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-key-control-tod-toe-test"}