{"description":"SOX IPE Validation as a modular, decision-aware workflow that runs on — and enriches — the existing relying Control item (a key control, framework⊇sox) whose evidence depends on an Information Produced by the Entity (IPE) report: the report's identity, test history, and C&A test date are recorded onto that control rather than into a separate record. In scope: the completeness-and-accuracy conclusion for one IPE report for one period. It consumes its starting key-control population from the upstream SOX scoping / RCM build — the Control library with its Control ↔ Risk links. Its named deliverables are a reperformable completeness-and-accuracy (C&A) memo attached to the control and a validated-IPE evidence-and-decision package. Out of scope: testing the relying control's own operation — that belongs to the downstream SOX Key Control TOD/TOE Test, which anchors on the control's fiscal-year Control-hosted SOX testing workflow and cites this workflow's C&A package instead of re-validating. It can stand alone, but hands its validated-IPE package to SOX Key Control TOD/TOE Test instead of duplicating repeated work.","edges":[{"id":"e-identify-the-ipe-and-relying-control-validate-the-report-source-and-logic","source":"identify-the-ipe-and-relying-control","target":"validate-the-report-source-and-logic"},{"id":"e-validate-the-report-source-and-logic-test-completeness","source":"validate-the-report-source-and-logic","target":"test-completeness"},{"id":"e-test-completeness-approve-the-ipe-as-reliable","source":"test-completeness","target":"approve-the-ipe-as-reliable"},{"id":"e-approve-the-ipe-as-reliable-classify-disposition","source":"approve-the-ipe-as-reliable","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"action_required"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"clear"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-FIN-09","UC-AUDIT-13"],"department":"internal-audit","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-ipe-validation","contentDigest":"sha256:51cfc7bd7a4f244e2478b5c44f256f648735995ccef48c11995f306b73e6e40f","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:51cfc7bd7a4f244e2478b5c44f256f648735995ccef48c11995f306b73e6e40f","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-ipe-validation"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"sox-ipe-validation","source":"coworkcanvas-gallery","standards":["sox"],"teams":["internal-audit","finance"]},"name":"SOX IPE Validation","nodes":[{"data":{"description":"Complete Identify the IPE and relying control","instructions":"**Objective** — Inventory the key report(s) the in-scope control relies on and pin each report's identity to that control, so every Information Produced by the Entity item is on file as reusable, testable control evidence before validation starts.\n\n**Inputs**\n- The Risk & Control Matrix (RCM) — the Control library as Control items with their Control ↔ Risk links, not a separate object — and every SOX-relevant Control record (`control_id`, `key_control`, `framework`⊇sox, `control_owner`), with each control's evidence records and attached supporting documents.\n- The in-scope Control item's `description` and the account assertion it addresses.\n- Prior-cycle C&A test dates per report, tracked in the report-identity note and prior C&A memos on each Control (no native field).\n\n**Procedure**\n1. Compile the key-report inventory: query the RCM and every SOX-relevant control, and for each control list the system-generated reports it depends on — parsed from the control's evidence record and its attached supporting documents — together with each report's last completeness-and-accuracy (C&A) test date.\n2. Flag any report whose last C&A test is more than 365 days old, or that has never been tested, as due this cycle: C&A must be re-performed at least annually for the report to remain reliable evidence.\n3. For the control in scope, identify the specific report(s) it consumes (for example, an aged-AR report driving the AR reserve estimate) and the account assertion the report supports. A control that \"reviews the report\" is only as strong as that report.\n4. Capture each report's identity on the control: report name, source system, the report or query logic (query, filters, source tables, sort), and the sample period (for example month-end close, or the last business day). Upload the report file itself as a supporting document on the control, so the report and its identity travel with the control it backs. A key report is not a separate record — it lives as evidence attached to the control that depends on it.\n5. Where the same report drives more than one SOX-relevant control, link those controls to each other and note the shared dependency, so a later C&A failure can be routed to every affected control instead of being rediscovered one test at a time.\n6. If the report has its own non-trivial generation workflow (built, peer-reviewed, then scheduled), create a process item modeling that generation and link it to the dependent controls — the generation process is where report-logic changes enter.\n\n**Record in AssureSwarm**\n- In a report-identity note (document) on the relying Control item — Control has no native fields for report metadata, so this note is the honest fallback: report name, source system, report logic, sample period, the relying control's `control_id` and assertion, last C&A test date, and the staleness flag.\n- The uploaded report file as a supporting document on the Control item; Control ↔ Control links between controls that share the report; a Process item (`process_type`: financial_reporting or it_general_control) linked to the dependent Controls where a generation workflow was modeled.\n\n**Exit criteria** — Each in-scope report is recorded on its relying control with its full identity and shared-control links, and stale or never-tested reports are flagged for testing this cycle. The control owner has confirmed — before validation begins — that the report list is complete for the control, the recorded source, logic, and sample period are accurate, and the shared-report links and staleness flags are correct.","label":"Identify the IPE and relying control","performedBy":{"agent":"sox-artist","note":"Inventory key reports on the relying control","primitives":["coach-query-data","coach-document-upload","coach-items-link","coach-item-create"]}},"id":"identify-the-ipe-and-relying-control"},{"data":{"description":"Complete Validate the report source and logic","instructions":"**Objective** — Establish that the report is what it claims to be before its data is tested: its source and generation logic tie out to the specification recorded on the control, so completeness and accuracy testing runs against the right population.\n\n**Inputs**\n- The report identity recorded at identification: source system, report or query logic (filters, source tables, sort), and sample period.\n- The report file to validate — re-pulled fresh or retrieved as run — plus access to the generating system or its report owner.\n- The change log or ticket history for the report, where the source system keeps one.\n\n**Procedure**\n1. Re-pull or retrieve the report and capture its IPE metadata on the pull: source system, report name, run parameters, run timestamp, and record count. A report without captured parameters cannot be tied to any specification.\n2. Where the file comes from the report owner rather than your own pull, request the actual file and retain the owner’s generation facts in native results and source documents: source system/report, parameters as run, generation timestamp, generation method, every post-extraction change, and in-period logic changes with ticket references. Treat the owner’s account as an assertion and corroborate it against the system.\n3. Verify the report's parameters, filters, source tables, and sort match the report logic recorded for the control. Flag any mismatch, changed parameter, or stale as-of date — each would make the report a different population than the one the control relies on, and testing it would validate the wrong thing.\n4. For custom queries, read the logic itself: date clauses (greater-than versus greater-than-or-equal), status filters that silently exclude records (voided, pending, inactive), and joins that drop unmatched rows are the classic places populations quietly lose members.\n5. Confirm the report is system-generated from the authoritative source and was not hand-keyed or edited after extraction, and that its as-of date falls inside the control's period. Note any manual manipulation between extraction and use — spreadsheet sorting, filtering, \"cleanup\" — because that manipulation is itself a reliability concern that must be separately verified or eliminated.\n6. Attach the report-specification tie-out as a supporting document: parameters as run, run timestamp, record count, and the match result against the recorded logic.\n\n**Record in AssureSwarm**\n- On this step: source system, run parameters, run timestamp, record count, the spec-match result, and any manipulation noted.\n- Retain the report file as a document and bind the source, parameters, generation timestamp/method, post-extraction changes and in-period logic changes to that exact version in native results.\n- The source-and-logic tie-out document (PDF/XLSX) attached to this step and linked to the relying Control item.\n\n**Exit criteria** — The report's source and generation logic are tied out to the recorded specification and the metadata is retained; the report owner's generation answers are on file where the file was not pulled first-hand; the reviewer has confirmed the source and logic match the control's report definition and that no undocumented manipulation occurred — or has recorded exactly why the report cannot yet be relied upon.\n\n","label":"Validate the report source and logic","performedBy":{"agent":"sox-artist","note":"Validate report source and generation logic","primitives":["coach-query-data","coach-document-upload"]}},"id":"validate-the-report-source-and-logic"},{"data":{"description":"Prove the report includes every record it should and that its values are correct: the population the relying control consumes is missing no in-scope rows (demonstrated by an independent reconciliation plus a source-to-report trace), and every sampled figure agrees with the authoritative source while every derived field recomputes — so the relying control acts on a complete population of numbers that mean what they say.","instructions":"**Objective**\nProve the report includes every record it should and that its values are correct: the population the relying control consumes is missing no in-scope rows (demonstrated by an independent reconciliation plus a source-to-report trace), and every sampled figure agrees with the authoritative source while every derived field recomputes — so the relying control acts on a complete population of numbers that mean what they say.\n\n**Inputs**\nThe tied-out report from the source-and-logic step, with its record count and run metadata.\n- An independent source total for the same period: a subledger row count, a general-ledger balance, or a system-of-record aggregate — something the report's own generation path does not produce.\n- Access to the system of record for the sampled items' source values.\n- The report's derived-field definitions — aging buckets, subtotals, computed rates — from the recorded report logic.\n- The firm's sampling guidance for completeness testing.\n\nThe source-and-logic tie-out, the completeness worksheet, and the accuracy worksheet with their per-sample logs.\n- The report identity recorded on the control and the shared-report links from identification.\n- The relying control's assertion(s) and exactly which report fields the control consumes.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Document the IPE validation”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Test completeness and accuracy: Prove the report includes every record it should and that its values are correct: the population the relying control consumes is missing no in-scope rows (demonstrated by an independent reconciliation plus a source-to-report trace), and every sampled figure agrees with the authoritative source while every derived field recomputes — so the relying control acts on a complete population of numbers that mean what they say.\n\n2. Establish the expected population independently of the report: reconcile the report's record count and control totals (row count plus a summed key field — amount or hash total) to the source-reported totals, computing any difference. The comparison total must come from outside the report's generation path, or the reconciliation proves nothing.\n3. Work the direction that catches omissions: completeness traces from the source population into the report. The report-to-source direction is the accuracy test below — running only that direction can never find a missing row.\n4. Select a sample for detailed completeness testing — random or judgmental, sized per the firm's sampling guidance — and record the selection method and sample size so the draw is reproducible by a reviewer.\n5. For each sampled item, trace it from the source population into the report to confirm it appears, and confirm no filter or cutoff silently dropped in-scope records — test items near the period boundaries (first and last days) deliberately. Record a per-sample pass or fail naming the specific rows checked.\n6. Treat completeness results asymmetrically: an unreconciled difference or a single missing in-scope record is a completeness failure that cannot be signed off as clean. An explained difference (documented timing or scope exclusion) must be itemized and each component tied out — never waved through as \"immaterial\".\n7. Attach the completeness worksheet: the reconciliation, the sample-selection basis, and the per-sample results.\n8. Reuse or extend the completeness sample and, for each sampled item, retrieve the corresponding source values from the system of record. This direction — report back to source — is vouching: it catches values the report altered, where the completeness trace catches values it omitted.\n9. Spot-verify each sample's key fields in the report against those source values: amounts, dates, account codes, quantities — the fields the relying control actually consumes, not merely the ones easiest to check.\n10. Recompute any derived or aggregated field the report presents rather than accepting it at face value: re-derive an aged receivable's days-past-due from its invoice date and confirm its bucket assignment, re-add subtotals, re-calculate rates. Derived-field logic is where reports are most often wrong while their raw data is right.\n11. Record a per-sample pass or fail with the observed report value, the source value, and the difference, and classify every difference: a report-logic error (systematic — the generation logic transforms data wrongly, so it taints the whole population no matter how few samples caught it), a timing item (the source moved between the report's as-of date and the test), or a data error (the source itself is wrong and the report faithfully reflects it — a source-data problem to route onward, not by itself a report-reliability failure).\n12. Attach the accuracy worksheet with the full per-sample log and classifications.\n\n13. Assessment scope for Document the IPE validation: Convert the test work into a reperformable completeness-and-accuracy memo on the control with a current test date, then weigh the documented results into a supported reliability call — reliable, reliable with stated limitations, or not reliable — so the report stands on file as tested, reusable evidence and the approval step rules on a specific, evidence-cited position rather than an impression.\n\n14. Compile the C&A memo: the report's identity (name, source, logic, sample period), the source-reconciliation result, the sampling basis, the per-sample completeness and accuracy log, and a one-paragraph plain-language conclusion on whether the report is reliable control evidence. Write the conclusion so a reader who was not in the testing can tell exactly what was proven and what was not.\n15. Verify reperformability before calling the memo done: every number in it appears in an attached worksheet, the sample draws carry their selection basis, and a reviewer could re-walk each conclusion from the attachments alone.\n16. Attach the memo and its supporting worksheets to the control and link them into the control's evidence record, so the report's test history travels with the control it backs.\n17. Record the C&A test date so the inventory's staleness flag resets — this date is what next cycle's 365-day check reads.\n18. If validation surfaced any change to the report's source, logic, or sample period, update the report's identity note on the control now, so the recorded specification matches reality for the next tester.\n19. List which other SOX-relevant controls share this report: their reliance is refreshed by this same test rather than re-tested from scratch — and that list is also the blast radius if the conclusion is ever revisited.\n20. Apply the pass conditions — all four must hold for an unqualified \"reliable\": (a) source and logic tie to the recorded specification with no unexplained mismatch; (b) the population reconciles to an independent source, or every difference is itemized and resolved; (c) no unexplained accuracy exceptions; (d) derived fields recompute cleanly.\n21. Weigh exceptions by classification, not by count: one report-logic error fails the report outright — it is systematic and taints the entire population no matter how few samples caught it. An isolated source-data error does not by itself fail the report (the report faithfully reflects its source) but must be routed to the data owner. A timing item resolved by a corrected as-of re-run supports reliance on the re-run version only — name that version.\n22. Consider limited reliance where the evidence supports it: a report can be reliable for one use and not another (amounts tie but the aging-bucket logic is wrong — reliable for existence, not for valuation). If reliance is limited, state precisely which fields and assertions the report can and cannot support; a vague \"use with caution\" transfers nothing.\n23. Check the blast radius before concluding: the same call lands on every control in the shared-report list. Confirm that list is current — a \"not reliable\" call against an incomplete list under-routes the failure.\n24. Draft the reliability call with a rationale citing specific worksheet rows and reconciliation figures, and route it to the independent reviewer named for this validation.\n\n**Record in AssureSwarm**\nOn this step: the source-reconciliation difference, selection method, sample size, per-sample completeness results, and per-sample accuracy results (observed value, source value, difference, and classification).\n- The completeness worksheet and the accuracy worksheet attached to the workflow.\n\nOn the control: the C&A memo and worksheets attached and linked into the evidence record; the C&A test date; the updated report-identity note where anything changed.\n- On this step: the reliability call (reliable / reliable with limitations / not reliable) and its rationale with evidence references; the list of controls whose reliance this test refreshes.\n- Link the C&A memo; comment on the step tagging the approving reviewer with the drafted call.\n\n**Exit criteria**\nThe report population reconciles to an independent source (or every difference is itemized and explained) and the completeness sample is documented and reperformable; every sampled value is verified to source with exceptions classified and documented; and the tester has confirmed the reconciliation, reviewed every completeness and accuracy exception, confirmed each classification, and judged whether the differences — individually or together — undermine reliance on the report. A reperformable C&A memo is attached to the control, the test date is recorded, and shared-control reliance is noted; the memo is reperformable from the attached evidence and the conclusion follows from the test results; and a reliability call with a rationale citing specific test results is recorded and routed to the approver, with any limitations stated in terms of the fields and assertions the report can and cannot support and the dependent-control list confirmed current — before the reliability decision is approved.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` recomputes the reconciliation (row counts, control totals, period boundaries) deterministically and draws the trace sample with a recorded seed, so the completeness working is re-runnable rather than hand-checked.","label":"Test completeness and accuracy","performedBy":{"agent":"sox-artist","note":"Test report completeness and accuracy Record the C&A conclusion on the control","primitives":["coach-query-data","coach-document-upload","sox-python","sox-test"]}},"id":"test-completeness"},{"data":{"description":"Complete Approve the IPE as reliable","instructions":"**Objective** — Turn the drafted reliability call into an accountable, dated decision by the independent reviewer: approval to rely, or a refusal specific enough for the deficiency step to act on.\n\n**Inputs**\n- The drafted reliability call with its rationale; the C&A memo and worksheets; the classified exception log.\n- The independence roles for this validation: report owner, tester, reviewer.\n\n**Procedure**\n1. Reperform the logic, not the testing: does the conclusion follow from the documented results? Spot-walk two or three worksheet rows back to the attached evidence to confirm the package is genuinely reperformable — if a row cannot be re-walked, the memo goes back before any approval.\n2. Verify the independence chain held: the report owner did not test their own report, and the approver is not the tester. Where a small team forced a doubled role, confirm the documented mitigation (a second review) actually happened.\n3. Challenge every exception classification, hardest on the convenient ones: the classic failure is labeling a systematic report-logic error an \"isolated data issue\" to preserve a clean conclusion. A recomputation that disagrees with a derived field is a logic error until proven otherwise.\n4. If approving: record the approval with date, approver, and the scope of reliance — period covered, the exact report version and run timestamp validated, the fields and assertions supported, and any limitations. This approval is the citation the downstream SOX Key Control TOD/TOE Test uses to treat the report as tested evidence without re-validating it.\n5. If refusing: record the refusal with specific grounds — which test failed and which exceptions drive it. Refuse cleanly; never soften a refusal into \"approved with comments\". A report either supports reliance for a stated use or it does not, and the next step logs the deficiency when it does not.\n\n**Record in AssureSwarm**\n- The decision on this step: approve or refuse, date, approver, and the scope of reliance or the grounds for refusal.\n- The step approval recorded; reviewer challenges and their resolutions kept in the step's comments.\n\n**Exit criteria** — A dated approval or refusal by the independent reviewer exists; approvals state the reliance scope (period, version, fields, assertions, limitations); refusals state grounds specific enough to drive the deficiency step; every reviewer challenge is resolved in the comments.","label":"Approve the IPE as reliable"},"id":"approve-the-ipe-as-reliable"},{"data":{"decisionField":"disposition_path","description":"Classify the validation's outcome so only the relevant closure path survives: straight to packaging, or through an owned remediation plan first. Proposed by the tester; owned by the SOX program owner (or the disposition owner named on the deficiency).","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Ready to close","value":"clear"},{"label":"Action required","value":"action_required"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nClassify the validation's outcome so only the relevant closure path survives: straight to packaging, or through an owned remediation plan first. Proposed by the tester; owned by the SOX program owner (or the disposition owner named on the deficiency).\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe approval step's outcome: the refusal grounds and classified exceptions, or a clean approval.\n- The shared-report links recorded at identification — the dependent-control list.\n- The accounts and assertions the report supports, from the relying controls' RCM records.\n\n*Agent retrieval, preparation and filing absorb “Log the IPE deficiency and route”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Log the IPE deficiency and route: Where the report failed completeness or accuracy (or approval was refused), log the deficiency and route it to every control that relies on the report — an unreliable key report cascades into multiple control failures. Where the report was approved as reliable, record that no deficiency arises and pass through.\n\n2. If the report was approved as reliable with no failures, record \"no deficiency to log\" on this step with a pointer to the approval, and move on — do not create an empty deficiency item.\n3. Otherwise create a deficiency item describing the failure concretely: which test failed, the specific missing records or value differences, and the affected report. Link it to the relying control and to the failing evidence.\n4. Identify every other SOX-relevant control whose evidence references the same report — from the shared-report links recorded at identification — and link each to the deficiency: the same report failure likely invalidates their evidence too. List those controls explicitly for follow-up testing; a dependent control left off this list quietly keeps relying on a broken report.\n5. Capture the preliminary severity inputs the program owner will need: the accounts and assertions the report supports, the magnitude of the completeness or accuracy gap (missing rows and their value; the size and direction of value differences), and how many controls depend on the report. Breadth of dependence is itself a severity input — one bad report behind five key controls is not five isolated issues.\n6. Route the deficiency to the SOX program owner for severity evaluation and to the report owner for correction, and attach the deficiency package: defect description, evidence extracts, dependent-control list, and severity inputs.\n\n7. Assessment scope for Classify disposition: Classify the validation's outcome so only the relevant closure path survives: straight to packaging, or through an owned remediation plan first. Proposed by the tester; owned by the SOX program owner (or the disposition owner named on the deficiency).\n\n\n\n**clear** (Ready to close) — the report was approved as reliable for the period with a dated approval and a stated reliance scope, and no deficiency was logged (or this run cleanly re-validated a corrected report and retires a prior deficiency). Limitations, if any, are informational: they narrow the reliance scope but demand no work from anyone — no report fix, no dependent-control re-test, no interim mitigation. Nothing remains but assembling the package and handing off.\n- **action_required** (Action required) — someone still owes work: the report failed completeness or accuracy and a deficiency is logged; approval was refused, or limited such that one or more dependent controls cannot rely on the report as-is; the report owner must correct source or logic and a re-validation must be scheduled; or dependent controls need follow-up testing or interim mitigation while the report is unreliable. An open deficiency without an owned, dated plan always forces this branch — \"we know about it\" is not a disposition.\n\n**Record in AssureSwarm**\nAn Issue item (`issue_type`: deficiency, `source`: sox_testing, `severity`, `description`, `identified_date`, `issue_owner`) capturing the failed test, defect description, affected report, dependent-control list, and severity inputs — with Issue ↔ Control relationships to every dependent control and a link to the failing evidence.\n- On a clean pass instead: the no-deficiency note on this step referencing the approval.\n\nSubmit this step's form: `disposition_path` = the chosen branch; the step result = the reasoning, citing the C&A memo, the approval or refusal record, and the deficiency item where one exists; the step's approver record = who made the call.\n\n**Exit criteria**\nEither a deficiency is logged, linked to every dependent control, and routed to the program and report owners with severity inputs captured — and the SOX program owner has confirmed the affected-control list is complete, agreed the severity inputs are captured, and taken ownership of the disposition (correct the report and re-test, or accept as a deficiency) before the workflow branches to closure — or the step records that validation passed and no deficiency arises. The form is submitted with a rationale that cites the evidence rather than asserting a label, and the unused branch is prunable because the edge value matches the selected option.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"sox-artist","note":"Log deficiency and route across dependent controls","primitives":["coach-item-create","coach-items-link","coach-document-upload"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert the IPE deficiency into an owned, dated remediation plan: fix the report, protect every dependent control in the meantime, and define the re-validation that will prove the fix.\n\n**Inputs**\n- The deficiency item with its defect description, exception classifications, and dependent-control list.\n- The SOX program owner's severity evaluation and disposition (correct and re-test, or accept as a deficiency).\n- The SOX certification calendar — the fix must land in time to re-validate the report and re-test dependent controls before the year-end assertion.\n\n**Procedure**\n1. Establish root cause by the failure's classification: a report-logic error means fixing the query or filters and the change-management gap that let the bad logic ship; a source-data error routes to the data owner and raises whether an upstream input control failed; a process or EUC gap (manual manipulation between extraction and use) is fixed by moving to a system-generated pull or adding a documented integrity check — not by promising to be more careful.\n2. Assign a named owner (normally the report owner for the fix, the control owners for mitigation) and a due date back-planned from the certification calendar: leave room for the corrected report's full re-validation and any dependent-control re-testing, not just the fix itself.\n3. Define interim mitigation for each dependent control while the report is unreliable: alternative evidence, manual verification of the specific fields that control consumes, or a documented workaround by the control operator. \"We will rely on it anyway\" is not mitigation — an unmitigated dependent control is operating on known-bad information.\n4. Define the validation evidence in advance: after a logic error, a full re-run of this workflow's source-and-logic, completeness, and accuracy tests on the corrected report — a spot check cannot clear a systematic defect. State the artifact that will prove closure.\n5. Set the reporting cadence and the escalation trigger: status to the SOX program owner each close cycle until re-validated, and escalation the moment the due date puts year-end reliance at risk.\n\n**Record in AssureSwarm**\n- On the deficiency Issue item: `root_cause`, `issue_owner`, `target_remediation_date` (the due date), and `remediation_plan` carrying the per-control interim mitigation, the defined re-validation evidence, and the reporting cadence.\n- Link the plan to every dependent control (Issue ↔ Control); add the deficiency to a watchlist for due-date monitoring.\n\n**Exit criteria** — The plan has a named owner, a due date compatible with the certification calendar, a root cause matching the failure classification, interim mitigation for every dependent control, and a defined re-validation standard; the deficiency item reflects all of it.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Hand the validated-IPE conclusion to SOX Key Control TOD/TOE Test so each relying control's test treats the report as tested evidence — or knows precisely why it cannot — without duplicating the C&A work, and close the validation on that acknowledgment with the package archived and the next C&A clock set.","instructions":"**Objective**\nHand the validated-IPE conclusion to SOX Key Control TOD/TOE Test so each relying control's test treats the report as tested evidence — or knows precisely why it cannot — without duplicating the C&A work, and close the validation on that acknowledgment with the package archived and the next C&A clock set.\n\n**Inputs**\nEverything produced upstream: the report identity, source-and-logic tie-out, completeness and accuracy worksheets, C&A memo, the approval or refusal record, the deficiency and action plan where they exist, and the submitted disposition form.\n\nThe final package with its reliance envelope and do-not-redo scope, and the submitted disposition form.\n- The dependent-control list; the deficiency and action plan where the disposition was action-required.\n- The downstream test's owner or tester for each relying control.\n- The relying control record(s) and the program's key-report inventory; the retention policy (seven years is the standard SOX anchor).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Prepare final package”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Prepare final package: Assemble the single, internally consistent evidence-and-decision package that lets the downstream control test — and the external auditor — rely on this validation without reperforming it.\n\n2. Assemble in reliance order — the order a skeptical reader checks: report identity, source-and-logic tie-out, completeness worksheet, accuracy worksheet, C&A memo, reliability approval (or refusal), deficiency and action plan, disposition. A package that must be read in discovery order is a package nobody can review.\n3. Verify internal consistency: record counts, reconciliation differences, and sample sizes agree everywhere they appear (worksheets, memo, decision rationale); every conclusion traces to an attached artifact; sample draws carry their selection basis.\n4. State the reliance envelope explicitly at the front: period covered, the exact report version and run timestamp validated, the fields and assertions supported, any limitations, and the C&A test date that anchors next cycle's 365-day staleness clock.\n5. State what downstream must not redo: the SOX Key Control TOD/TOE Test cites this package as its IPE support instead of re-testing completeness and accuracy — provided the report it uses matches the validated version and parameters.\n6. Carry open items visibly: an action-required disposition means the package includes the plan with its owner and due date, and says plainly which dependent controls cannot yet rely. A package that hides its open items invites reliance it cannot support.\n\n7. Assessment scope for Handoff to related workflow: Hand the validated-IPE conclusion to SOX Key Control TOD/TOE Test so each relying control's test treats the report as tested evidence — or knows precisely why it cannot — without duplicating the C&A work, and close the validation on that acknowledgment with the package archived and the next C&A clock set.\n\n8. Create or link the SOX Key Control TOD/TOE Test workflow for each relying control — or attach to the in-flight instance where testing is already underway — and pass the final package.\n9. State what downstream must not repeat: completeness and accuracy of this report for this period are established. The control test samples the control's operation and cites this package's C&A memo and approval as the IPE support in its workpapers.\n10. State the conditions that void the handoff, so the downstream tester can check them cheaply: the control consumes a different report version or different parameters than validated; the test period extends beyond the validated as-of range; or a change ticket touched the report's source or logic after the validated run. Any of these re-triggers this module before reliance resumes.\n11. Where the disposition was action-required, hand off the limitation instead of a false green light: which dependent controls cannot rely on the report as-is, the interim mitigation that applies to each, and the re-validation due date — the downstream test plans alternative evidence for those controls rather than citing this package.\n12. Note the assumptions the downstream tester should verify on receipt: the report is unchanged since the validated run timestamp (compare parameters), and no new dependent controls were added since the shared-report links were recorded.\n13. Verify completeness before closing: every step finished or explicitly dispositioned, the decision form submitted, reviewer challenges resolved, the handoff acknowledged. Closing over an open item is how evidence trails grow the holes the external auditor finds later.\n14. Confirm the linked records tell the final story: the control's evidence record carries the C&A memo, the test date (resetting the 365-day staleness clock), and the reliance scope; shared controls' reliance notes are refreshed; the deficiency item, if any, shows its plan, owner, and due date.\n15. Schedule the forward obligations with owners, not just dates: the next annual C&A re-validation; the action plan's re-validation date on a watchlist with the SOX program owner; and the standing re-trigger — any change ticket touching the report's source or logic re-opens validation early, baseline or not.\n16. Communicate the conclusion to the control owner(s), the report owner, and the SOX program owner: the reliability call, the reliance envelope, and any open plan with its date. Certification-relevant results flow into the program's certification tracking.\n17. Archive the final package under the retention policy and record the archive confirmation; post-archive corrections are new dated addenda referencing the original — never edits to the archived package.\n\n**Record in AssureSwarm**\nThe assembled package attached to the workflow, with a package-inventory list on this step.\n- Links verified: the relying control(s), the deficiency item and plan where they exist, and the submitted disposition form.\n\nLink the downstream workflow(s) to this one; attach the handoff note listing package contents, reliance envelope, do-not-repeat scope, and voiding conditions.\n- Notify the downstream owner in a comment on the handoff step and capture their acknowledgment.\n- The workflow's final status; the archive confirmation with the retention basis; communication recipients and dates in a closing comment on the workflow item.\n- Watchlist entries for the next C&A date and any plan due date; the control's evidence record confirmed current.\n\n**Exit criteria**\nThe package is complete and internally consistent (counts and differences agree across memo and worksheets), the reliance envelope and the do-not-redo scope are stated, and open items are carried with owners and dates. The downstream workflow is linked and its owner has acknowledged receipt; the do-not-repeat scope and voiding conditions are recorded; limitations and interim mitigations, where they exist, are explicitly transferred rather than implied; all steps are dispositioned; the package is archived with the confirmation recorded; the control's evidence record and the key-report inventory are current; the next validation is scheduled with owners; the conclusion is communicated; any later correction exists only as a new dated addendum.","label":"Handoff to related workflow"},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-ipe-validation"}