{"description":"SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.","edges":[{"id":"e-lock-executable-workplan-apply-controls-owned-scripts","source":"lock-executable-workplan","target":"apply-controls-owned-scripts"},{"id":"e-apply-controls-owned-scripts-evaluate-deficiencies","source":"apply-controls-owned-scripts","target":"evaluate-deficiencies"},{"id":"e-evaluate-deficiencies-retest-and-coordinate-reliance","source":"evaluate-deficiencies","target":"retest-and-coordinate-reliance"},{"id":"e-retest-and-coordinate-reliance-classify-disposition","source":"retest-and-coordinate-reliance","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,"metadata":{"capabilities":[],"controlVerbs":{"UC-AUDIT-21":"operates"},"controls":["UC-AUDIT-21","UC-ACCESS-01","UC-ACCESS-02","UC-ACCESS-04","UC-CONFIG-02","UC-ACCESS-17","UC-ACCESS-05","UC-ACCESS-16","UC-ASSET-12","UC-BCDR-12","UC-CONFIG-03","UC-BCDR-03","UC-GOV-08","UC-SDLC-06","UC-SDLC-07"],"department":"internal-audit","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-itgc-testing","contentDigest":"sha256:eaebf4d5b6fbbc31ce2e6cc4908a6af39aeb6d2a3e5494135f364962e96fd19a","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:eaebf4d5b6fbbc31ce2e6cc4908a6af39aeb6d2a3e5494135f364962e96fd19a","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-itgc-testing"},"lineOfDefense":"assure","mappingStatus":"mapped","risks":[],"slug":"sox-itgc-testing","source":"coworkcanvas-gallery","standards":["sox","nist-800-53"],"teams":["internal-audit","it","finance"]},"name":"SOX ITGC Testing","nodes":[{"data":{"description":"Freeze the ITGC test matrix — control by system by period segment, with owners, dates, evidence standards, and the review chain — so execution starts from commitments instead of moving targets.","instructions":"**Objective**\nFreeze the ITGC test matrix — control by system by period segment, with owners, dates, evidence standards, and the review chain — so execution starts from commitments instead of moving targets.\n\n**Inputs**\nConsumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment (a document on that workflow's handoff step): significant accounts, processes, applications, and their automated-control, key-report, and interface dependencies — the applications already exist as scoped entities, not net-new here.\n- IT's configuration and asset records for the platform stack under each application (database, operating system, hosting model, job scheduler, middleware) — uploaded to this step (PBC/external); there is no native System/Asset item type.\n- The SOC 1 reports and CUEC mappings for outsourced and SaaS platforms — the platforms themselves are Vendor items (category: saas_software / cloud_infrastructure, tier, data_classification, business_owner, risk_owner), each SOC 1 PDF uploaded to this step and attached to its Vendor item.\n\nThe in-scope system inventory from the preceding procedure.\n- The controls-owned unified control catalog with its NIST 800-53 mappings and test scripts — the Control items linked to this workflow (access provisioning, deprovisioning, review, privileged access, and authentication; configuration and change management; SDLC testing and approval; backup and recovery) are the anchor set; each Control's test script lives as a document attached to (or in the description text on) that Control item.\n- The RCM's ITGC objectives per system — uploaded here as an XLSX extract (PBC/external); no native RCM structure, partially reflected in Control.domains / Control.description.\n\nThe ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment — a document attached by that workflow's close/handoff step: significant accounts, in-scope applications, and their automated-control, key-report, and interface dependencies. The entities behind it already exist as Process items (significant financial processes) and on the anchor Audit item's `scope` field, linked Audit to Process.\n- This cycle's coverage posture — standard, or expanded where a new system or migration splits the test period at the cutover date, prior-year deficiencies enlarge samples, external-auditor reliance layers interim and roll-forward, or newly outsourced platforms add SOC 1 review.\n- The unified control catalog linkage: the Control items (framework containing nist-800-53 and sox, with control_owner, frequency, automation) whose catalog test scripts are expected to carry which matrix cells.\n- The program calendar: certification dates, auditor reliance deadlines, close blackout weeks, IT change-freeze windows.\n- The governing methodology and policies — the sampling policy, exception policy, and ITGC severity framework — held as Policy items (policy_type: procedure or standard, framework containing sox) where they exist, or their version references otherwise.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Scope the ITGC system stack”, “Map ITGC objectives”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Scope the ITGC system stack: Extend the upstream scoping handoff into the definitive ITGC system inventory — the in-scope applications already identified by Annual ICFR Scoping & Risk Assessment, now decomposed to the infrastructure layers beneath them — so every layer that could corrupt financial data is covered and nothing financially irrelevant burns hours. The applications arrive from upstream; the ITGC stack decomposition, hosting classification, and shadow-scope sweep are the net-new work here.\n\n2. Start from dependencies, not from the IT asset list: an application is in ITGC scope because it hosts automated controls, generates key reports, initiates, records, or processes transactions for significant accounts, or moves such data over interfaces. Record the dependency justifying each inclusion — it later sizes any deficiency.\n3. Walk down the stack per application: the database (direct data access can bypass every application control), the operating system (privileged OS access can alter data and configurations), and financially relevant supporting tools — job schedulers running close jobs, interface middleware, RPA touching journal entries. Include a layer where a failure there could reach financial data unmitigated; document the rationale wherever you stop.\n4. Classify the hosting model per system, because it moves the ITGC boundary: on-prem (full stack in-house), IaaS (hypervisor down is the provider's SOC report; OS up is yours), SaaS (most layers ride the SOC 1; in-house scope concentrates on user access administration, configuration options you control, and CUECs).\n5. Sweep for shadow scope: end-user computing promoted into key reports (spreadsheets or desktop databases with material account impact), direct-database reporting that bypasses the application, and service accounts moving financial data between systems.\n6. Confirm exclusions explicitly: financially irrelevant systems stay out with a one-line reason. \"We test everything\" is scope creep that starves the systems that matter.\n7. Reconcile the final inventory with IT and the SOX PMO — this inventory is the denominator every later completeness claim divides by.\n\n8. Assessment scope for Map ITGC objectives: Map every in-scope system's ITGC objectives to the unified controls in the controls-owned 800-53 catalog that answer them, so testing reuses catalog scripts, one control's evidence serves many frameworks, and gaps become explicit catalog requests instead of bespoke procedures.\n\n9. Enumerate the four ITGC domains per system: access to programs and data (provisioning, timely deprovisioning, periodic access review, privileged access, authentication configuration, segregation of duties within IT — 800-53 AC and IA family territory); program changes (authorization, testing, approval, developer-versus-migrator segregation, emergency changes — CM family); program development (SDLC gates, data conversion — SA and CM families); and computer operations (job scheduling and monitoring, incident handling, backup and restoration — CP family and operations controls).\n10. For each cell, select the unified control that operates it and confirm fit on four axes: the control's stated scope covers this system; its frequency matches the SOX period's needs; its population source is defined; and its catalog test script actually evidences the SOX objective. Read the script, not the title — a script verifying \"access reviews happen\" does not evidence \"revocations were executed timely\".\n11. Record the SOX overlay per mapping — what SOX adds to the catalog baseline: the financially relevant sub-population (users with access to financial applications, not all users), the test period and segments, IPE requirements on the population pull, and reliance-grade evidence standards.\n12. Flag gaps and misfits: an ITGC objective with no unified control, or a script that under-evidences the objective, becomes a catalog change request to the controls team — raise it as a suggested change on the unified control record — plus a documented interim procedure so the cell is still tested this cycle. Never fork a private copy of the script; that recreates the duplication this workflow exists to kill.\n13. Confirm completeness: every matrix cell from the locked workplan now points at exactly one unified control and script, or a flagged interim procedure. Cells whose control was already tested under another program this period reuse those results — link, do not retest.\n\n14. Assessment scope for Lock executable workplan: Freeze the ITGC test matrix — control by system by period segment, with owners, dates, evidence standards, and the review chain — so execution starts from commitments instead of moving targets.\n\n15. Assemble the matrix: one row per ITGC control instance — unified control by application (or platform layer) by period segment — each with tester, control owner, PBC due date, fieldwork window, and reviewer. Rows, not intentions: \"change management\" is not a row; \"change-approval control on the ERP application layer, interim period\" is.\n16. Fix the calendar working backwards from the hard stop (certification date or auditor reliance deadline): PBC issue, evidence due, fieldwork, review, and a deficiency-evaluation buffer. ITGC results feed the reliance decision for every automated control and key report — they are needed earlier than business-process testing, not later. If the arithmetic does not fit, escalate scope or dates now.\n17. Confirm the review chain and independence: no tester covers a domain they administer; the reviewer is independent of and senior to the tester; add the QA or PMO layer the program's risk rating requires.\n18. Set evidence standards up front: system-generated evidence shows visible parameters and generation timestamps; screenshots capture the system banner and date; population pulls record source, query, and row counts. Where auditor reliance is expected, apply their evidence standards from day one — retrofitting screenshots months later is misery.\n19. State the methodology version being followed (sampling policy, exception policy, ITGC severity framework) so a reviewer two years from now can reconstruct the rules of the game.\n20. Lock it: from here, scope or date changes are logged change events with test-lead concurrence — not quiet edits.\n\n**Record in AssureSwarm**\nStep document: attach the in-scope system inventory as an XLSX on this step — one row per application and layer with its dependency justification, stack decomposition, hosting model, and owner. There is no native System/Application item type, so this inventory is a workpaper, not items (honest fallback); do not force applications into Process.\n- For each in-scope ITGC control this scope implies, record the per-control system context on the setup/scoping step of the directly hosted SOX testing workflow created at mapping; the direct host supplies the Control association.\n- Vendor items: for each outsourced/SaaS platform, create or link a Vendor item (category, tier, data_classification, business_owner, risk_owner, monitoring_status), attach its SOC 1 report, and link the Vendor to the Control items whose CUECs it carries.\n- Record the exclusion list with reasons on this step.\n\nCreate one SOX testing workflow directly on each in-scope ITGC Control; set Workflow.customFields.sox.fiscalYear, record the tester assignment and dependency rationale on its setup step, and require template metadata.kind = sox-testing.\n- Record per mapping the SOX overlay (sub-population, period, IPE requirement, evidence standard) on that workflow's setup/scoping step and on this step.\n- Log catalog gap requests as suggested changes against the affected Control items (a change request on the Control record), linked from this step, with this cycle's interim procedure documented alongside.\n- Step document: attach the completed objective-to-control map as an XLSX on this step.\n\nStep document: attach the locked test matrix as an XLSX workpaper on this step, with the calendar, review chain, and evidence standards recorded alongside it.\n- Enrich the anchor: set Audit.period_start / Audit.period_end to the locked test period and Audit.lead_auditor to the test lead.\n- Reference the governing methodology as the Policy items (policy_type: procedure or standard) that hold the sampling, exception, and severity policies; where the program keeps a methodology version not yet a Policy item, record the version reference on this step (no native methodology field — honest fallback).\n- Workflow instance: set the run's step due dates to match the locked calendar.\n\n**Exit criteria**\nEvery in-scope system carries a financial-reporting dependency justification, stack decomposition, hosting classification, and owner; layer stop-points and exclusions are reasoned; the inventory is reconciled with IT and the PMO. Every system-by-domain cell maps to one unified control and script or a flagged interim procedure; SOX overlays are recorded; catalog gaps are raised to the controls team with this cycle's fallback documented; reuse of other programs' current results is linked, not duplicated. The matrix enumerates every control-by-system-by-segment cell with owner and dates; the calendar closes against the hard stop; evidence standards and the methodology version are recorded; any later change requires a logged concurrence.","label":"Lock executable workplan","performedBy":{"note":"","primitives":["coach-item-create","coach-items-link","coach-document-upload","coach-item-update"]}},"id":"lock-executable-workplan"},{"data":{"description":"Execute each mapped unified control's catalog test script against the SOX populations, with SOX-grade sampling and the recorded overlay, producing per-attribute results a reviewer can reperform — without rebuilding procedures the controls team already owns.","instructions":"**Objective**\nExecute each mapped unified control's catalog test script against the SOX populations, with SOX-grade sampling and the recorded overlay, producing per-attribute results a reviewer can reperform — without rebuilding procedures the controls team already owns.\n\n**Inputs**\nThe locked matrix with PBC due dates and control owners.\n- Per mapping: the population source (identity platform, HR system, ITSM, deployment pipeline, scheduler, backup tool) and the catalog script's evidence list.\n- The SOX overlay's IPE standards.\n- For populations flagged for heavyweight validation: the completeness/accuracy conclusion handoff from SOX IPE Validation (its conclusion document), recorded against the flagged population here.\n\nThe objective-to-control map with SOX overlays, and the catalog scripts at their current versions.\n- Validated populations and configuration evidence from the preceding procedure.\n- The sampling and exception policies from the locked workplan.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Collect ITGC evidence”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Collect ITGC evidence: Issue the PBC requests and pull the populations and configuration evidence every mapped test consumes — complete, parameter-evidenced, and tied to the locked period — so fieldwork starts from validated evidence instead of stalling mid-test.\n\n2. Issue one PBC list per control owner, itemized by matrix cell: what to produce, from which system, for which period, in what form, by when. Bind each requested item to the PBC tracker and retain the returned evidence, extraction parameters, generation date, generator and attributed completeness statement in native results and documents. Ask for populations, not samples — the tester draws the samples; owners who pre-select items void the draw.\n3. Pull or receive the standard ITGC populations with completeness support: all-users-with-entitlements extracts per in-scope application (source, parameters, generation date visible); the HR termination list for the period — the authoritative deprovisioning population comes from HR, not from IT's ticket queue, which only shows terminations IT knew about; the full change population from the ITSM and deployment pipeline including emergency changes; job-failure and backup-completion logs; and the access-review artifacts for each cycle in period.\n4. Validate each population before anything is drawn from it: row counts tie to source-system totals, min and max dates sit inside the period boundaries, and the extraction query and parameters are captured. The owner's completeness statement is an assertion, not the check — reperform it. Cross-check populations against each other — changes deployed with no ITSM record surface by diffing the deployment log against tickets; terminations missing from IT's list surface from the HR join. Flag heavyweight completeness-and-accuracy validations — populations feeding multiple consumers or needing source-system query reperformance — for deeper validation under SOX IPE Validation, and confirm the in-line checks otherwise stand.\n5. Capture point-in-time configuration evidence where scripts test settings: authentication and password or MFA configuration, developer access to production, migration-tool segregation settings, backup schedules — export or screenshot with system banner and timestamp.\n6. Chase to the calendar: reminder before the due date, escalation to the IT control owner's manager after it, and a blocked-cells list to the test lead. Late evidence compresses fieldwork — surface it, do not absorb it.\n7. Index everything received against matrix cells so coverage holes are visible at a glance.\n\n8. Assessment scope for Apply controls-owned scripts: Execute each mapped unified control's catalog test script against the SOX populations, with SOX-grade sampling and the recorded overlay, producing per-attribute results a reviewer can reperform — without rebuilding procedures the controls team already owns.\n\n9. Size samples by control nature. Recurring manual ITGCs use frequency buckets (daily → 25; weekly → 5–10; monthly → 2–5; quarterly → 2; annual → 1; +25–50% at elevated risk). Event-driven populations (terminations, changes, new-access grants) size from the event count — a common convention: 250+ events → 25; 50–249 → 10–15; under 50 → 10% with a floor of 2–5, or the whole population when small. Automated and configuration controls: test of one plus the configuration evidence — valid only while change management over that system tests effective, so record the dependency explicitly.\n10. Draw each sample from the validated population with a recorded seed or documented picker, and pre-commit the exception policy (expand by a stated increment, or stop and evaluate) before any result exists.\n11. Run the script as written, applying the SOX overlay: script attributes stay intact; the overlay narrows population and period and raises evidence standards. Typical attribute sets the catalog scripts carry — deprovisioning: termination date versus access-removal date within the policy SLA, evidenced from the system, not the ticket; provisioning: documented approval predating the grant, approver authorized, access granted matches access approved; change: approval before deployment, test evidence, deployer distinct from developer, emergency changes ratified after the fact within policy; access review: reviewer independence, all-lines coverage, revocations actually executed in the system; backup: completion logs for the sampled dates plus a successful restoration test in period.\n12. Where a script needs tailoring to evidence the SOX objective, record the tailoring in the workpaper and raise it to the catalog owner as a suggested change on the unified control record — never run a silent local variant.\n13. Record per sample item, per attribute: pass or fail, the evidence reference, and the tickmark. Conclusions cite evidence, not assertions. Any attribute failure is an exception — log it neutrally now (item, attribute, facts); evaluation happens at the next step, not in this workpaper's margins.\n14. Apply the pre-committed policy when exceptions appear (expand or stop) and document the application.\n\n**Record in AssureSwarm**\nStep documents: attach populations, configuration captures, and completeness support to this step, indexed by matrix cell (populations have no native item field — they live as workpapers on the step).\n- Retain per request the matrix-cell reference, source system, evidence type, actual extraction parameters and generator, generation date, attributed completeness statement and any exclusions/caveats in the PBC tracker and native result. Attach the exact source file; do not substitute the owner’s assertion for independent validation.\n- Record per population on the step: source, parameters, row count, period boundaries, validation result, and any open flag for deeper IPE validation carried by SOX IPE Validation.\n- Log the PBC chase trail and the blocked-cells list on this step.\n\nStep document: attach per-cell workpapers as XLSX — sample list with draw parameters, attribute grid with results and tickmarks, and evidence references.\n- Enrich the cell's Control-hosted SOX testing workflow: the workflow tester assignment = the tester and the workflow Test-step conclusion = operating_effectively | exceptions_noted | not_operating_effectively; record script version, overlay applied, tailorings raised, and sample basis on the workpaper.\n- Create one Issue per failed attribute (issue_type: exception, source: sox_testing, severity, identified_date, description = the neutral exception facts), link the Issue to the cell's Control and add it as a linked item on the workflow's Test step.\n- Log each script tailoring as a suggested change against the affected Control item.\n\n**Exit criteria**\nEvery matrix cell's populations and configuration evidence are received and indexed, or the missing cells are escalated with owners and dates; each received population carries parameter evidence, the owner's completeness statement, and an independent completeness check; cross-population diffs are run with anomalies flagged.\n\n Every matrix cell has an executed script with a reproducible sample draw, a complete attribute grid, and evidence-cited results; tailorings are documented and raised to the catalog owner; exceptions exist as linked records, not prose; the exception-policy application is documented.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the per-owner PBC requests, deadline reminders, and escalation notices with a logged chase trail.","label":"Apply controls-owned scripts","performedBy":{"note":"","primitives":["coach-document-upload","coach-item-create","coach-items-link","coach-item-update","sox-test","sox-testing","sox-python","coach-notify"]}},"id":"apply-controls-owned-scripts"},{"data":{"description":"Complete Evaluate deficiencies","instructions":"**Objective** — Convert test exceptions into evaluated ITGC deficiencies using the dependency lens — what automated controls, key reports, and financial data the failed ITGC could have let go wrong — with a preliminary severity that survives auditor challenge.\n\n**Inputs**\n- The exception records from script execution.\n- The dependency inventory: automated controls, key reports, and interfaces per affected system.\n- Business-process test results for dependent controls where available, and the program's severity framework.\n\n**Procedure**\n1. Confirm each exception is a real deviation: evidence located late, an item outside the control's scope, or a compensating path within the control itself resolves it as a non-deviation with documented basis. Everything else is a deficiency — in operation, or in design if the script exposed the control as incapable even when performed as designed.\n2. Group exceptions by root cause into deficiencies: five late deprovisioning cases traced to one broken HR-to-IT feed are one deficiency, not five.\n3. Evaluate through dependencies, not directly: an ITGC failure rarely misstates an account by itself — it undermines the automated controls and key reports riding on the system. For each deficiency, list the dependent controls and reports; determine whether they actually failed or kept operating (direct testing of them counts); and where inappropriate access existed, check whether it was used — activity logs for the users in question turn \"could have\" into \"did or did not\". Size magnitude from the accounts flowing through those dependencies, not from the count of exceptions.\n4. Assess likelihood — is recurrence reasonably possible given how long the condition existed and why — and apply compensating controls only if they were themselves tested effective this period.\n5. Aggregate within domain and system: individually minor access deficiencies on the same platform can jointly defeat the access objective. Evaluate the pile, not just the pieces.\n6. Assign preliminary severity per the framework — deficiency, significant deficiency, or material-weakness indicator — and write the rationale showing the arithmetic: dependency map, used-versus-unused analysis, magnitude, likelihood, compensating controls, aggregation.\n\n**Record in AssureSwarm**\n- Item field update: update each exception Issue with its disposition (a non-deviation with documented basis, or rolled into a deficiency).\n- Create one deficiency Issue per root-cause group (issue_type: deficiency | significant_deficiency | material_weakness, severity, source: sox_testing, root_cause, description = the dependency analysis and severity rationale, identified_date), use item relationships for Issue ↔ Issue (grouping its exceptions), Issue ↔ the affected Control, and Issue ↔ the anchor Audit; add the deficiency Issue as a linked item on the source workflow's Test step.\n- Record per deficiency the preliminary severity in Issue.severity and the arithmetic in Issue.root_cause / Issue.description.\n\n**Exit criteria** — Every exception is dispositioned; deficiencies are root-cause-grouped with dependency-based severity rationales; aggregation across the domain is assessed and documented; non-deviations carry documented basis.","label":"Evaluate deficiencies","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update"]}},"id":"evaluate-deficiencies"},{"data":{"description":"Complete Retest and coordinate reliance","instructions":"**Objective** — Close the loop on remediated items with in-period re-tests and package the cycle's results so the external auditor can rely on them — timing, samples, and reperformance support aligned — protecting the reliance and benchmarking strategy for every dependent automated control.\n\n**Inputs**\n- Deficiency records with remediation status and effective dates.\n- Interim test results and the roll-forward plan from the locked calendar.\n- The auditor's reliance requests: sample expectations, reperformance selections, timing.\n\n**Procedure**\n1. Re-test remediated ITGCs against post-fix instances only: confirm enough instances exist between the remediation effective date and the as-of date to support a conclusion — a quarterly access review fixed in November offers one testable instance; say so and state what that thins out. Use the same catalog script; the re-test workpaper references the original and covers only the new period.\n2. Execute roll-forward for controls tested at interim: a corroborated change inquiry (did the control, system, performer, or configuration change since interim?) plus a refreshed sample over the stub period sized to its length. Inquiry alone rolls nothing forward.\n3. Maintain the automated-control benchmark chain: where the program benchmarks automated application controls under AS 2201's benchmarking concept, this cycle's change-management conclusion is the license — effective change management lets automated-control conclusions carry forward; a change-management deficiency breaks the benchmark and forces re-testing of the dependent automated controls. Notify the business-process test leads either way.\n4. Coordinate the reliance mechanics: share the test matrix, workpapers, and severity rationales; support the auditor's reperformance selections — they will re-draw from your populations, and the recorded seeds and parameter evidence are what earn the reliance; log scope and evidence requests with their resolution.\n5. Track auditor disagreements explicitly — a severity challenge or a rejected workpaper is a program-level event for the disposition step, not a private note.\n\n**Record in AssureSwarm**\n- Attach re-test and roll-forward workpapers linked to the originals; record per deficiency the re-test result.\n- Record the benchmark determination and the notifications sent to dependent-control owners.\n- Log the reliance coordination: what was shared and when, reperformance support provided, open auditor requests.\n\n**Exit criteria** — Every remediated item has a post-fix re-test or a documented instance-count limitation; roll-forwards are corroborated and sampled; the benchmark license is affirmed or revoked with notifications sent; the reliance log shows no unanswered auditor request.","label":"Retest and coordinate reliance"},"id":"retest-and-coordinate-reliance"},{"data":{"decisionField":"disposition_path","description":"Classify the result of SOX ITGC Testing 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":"**Objective** — Classify the cycle's ITGC result — clean, remediation-track, or escalation — using the dependency-based severity work, so the right closure path runs and certification stakeholders see the exposure at its true size. Proposed by the test lead; owned by the severity authority the program designates.\n\n**Decision criteria**\nSeverity rests on the dependency analysis from deficiency evaluation: magnitude from the accounts flowing through dependent automated controls and key reports, likelihood from exposure duration and recurrence, compensating controls only if themselves tested, and aggregation across the domain.\n- **clean** (No reportable gap) — every matrix cell concluded effective: no exceptions, or every exception resolved as a non-deviation with documented basis; re-tests of prior-year items passed; the benchmark license for dependent automated controls holds. The affirmative conclusion is the output — nothing to remediate.\n- **remediate** (Remediation required) — real deficiencies exist but preliminary severity stops at deficiency or significant deficiency: dependent controls kept operating, or the usage analysis shows the exposure was never exercised; 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) — material-weakness indicators or issues beyond this workflow's authority: a pervasive access or change deficiency on the primary financial system with dependent controls undermined and no tested compensating control; evidence of unauthorized changes to financial data, or of inappropriate access actually used; fraud involving IT or senior management, regardless of amount; aggregation 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 dependency, usage, magnitude and likelihood, compensating-control, and aggregation reasoning; 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"},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Produce an owned, dated, verifiable remediation plan per ITGC deficiency that fixes the cause — not the symptom — inside the re-test window the certification calendar leaves.\n\n**Inputs**\n- The deficiency records with root causes and dependency analyses.\n- The disposition rationale from the previous step.\n- The certification calendar and each control's frequency, for re-test arithmetic.\n\n**Procedure**\n1. Push each root cause past the first answer: \"the ticket was missed\" is a symptom — keep asking why until the answer changes what you would fix (no HR-to-IT feed for contractor terminations; migration-tool permissions never re-baselined after the reorg; emergency-change ratification had no owner). The action must attack that answer.\n2. Define the remediation concretely: what changes (feed, configuration, procedure, staffing, automation), who implements it, and what evidence completion will produce. Prefer fixes that harden the unified control for every framework it serves — the catalog is shared, and a SOX-only patch that forks behavior creates the drift this program exists to prevent.\n3. Assign ownership to the IT control owner — never the tester, who must independently re-test the fix later.\n4. Set due dates against re-test arithmetic: the fixed control must operate enough times before the as-of date to be testable. A quarterly review fixed in November leaves one instance by year-end — flag the thinness now or accelerate the fix.\n5. Define interim mitigation with its own owner — heightened monitoring, temporary manual checks — and note it must itself be tested if anyone intends to rely on it.\n6. State the closure standard: what the remediation re-test will require (post-fix instances, expanded sample, which catalog script), 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- Item field update on each deficiency Issue: Issue.remediation_plan = the remediation action, interim mitigation, and closure standard; Issue.issue_owner = the IT control owner (never the tester); Issue.target_remediation_date = the due date set against re-test arithmetic; Issue.management_response = management's commitment and reporting cadence.\n- Record the catalog-hardening note, wherever the fix changes the shared Control, as a suggested change against that Control item.\n\n**Exit criteria** — Every deficiency has a plan attacking its stated root cause, a named owner, a due date that survives re-test arithmetic, interim mitigation with an owner, and a closure standard defining the evidence that ends it.","label":"Create action plan","performedBy":{"primitives":["coach-item-update"]}},"id":"create-action-plan"},{"data":{"description":"Escalate to SOX PMO, control owner, reviewer, or certification owner or document risk acceptance","instructions":"**Objective** — Put the significant ITGC issue in front of the people accountable for certification — with dependency-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**Inputs**\n- The disposition rationale and dependency analysis: affected systems, dependent automated controls and key reports, accounts and balances exposed, usage analysis.\n- The exception and deficiency records; the escalation chain (SOX PMO, IT control owner, certifying officers) and external-auditor communication obligations.\n\n**Procedure**\n1. Draft the decision memo: the issue in one paragraph; quantified impact — which accounts, through which dependent automated controls and key reports, over what period, with the used-versus-unused access analysis where it exists; how it was found; the severity assessment with the compensating-control and aggregation analysis shown; the options (remediate-and-re-test timeline, reliance on tested compensating controls, expanded substantive or business-process testing to cover the exposed period, disclosure implications); and a recommendation.\n2. Route by severity. Potential material weakness, unauthorized changes to financial data, or fraud touching IT or 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 or unauthorized-change evidence. 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 (system scope growth, a repeat exception, a broken benchmark).\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 outcome back into the disposition record so the final package reflects the decision, not just the recommendation.\n\n**Record in AssureSwarm**\n- Step document: attach the decision memo (DOCX/PDF) on this step.\n- For an escalation: record the decision, decider, date, and certification-chain recipients on this step; link the memo to the deficiency Issues and the anchor Audit.\n- For a risk acceptance (available only below the significant-deficiency line): create an Issue with issue_type: policy_exception, exception_approver = the named acceptor with authority, exception_expiry_date = the expiry/re-review date, description = the bounded scope and the conditions that void it, linked to the accepted Risk item — and set treatment: accept on that Risk; link the acceptance Issue to the deficiency and to the tested compensating Control.\n- Link the follow-up items (re-test task, acceptance review, expanded-testing requests) 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","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update","coach-document-upload"]}},"id":"escalate-or-accept-risk"},{"data":{"description":"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 cycle on that acknowledgment with the package archived and the tested records updated.","instructions":"**Objective**\nHand 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 cycle on that acknowledgment with the package archived and the tested records updated.\n\n**Inputs**\nEverything produced upstream: the system inventory and scoping rationale, the objective-to-control map with overlays, populations with completeness evidence and IPE conclusions, per-cell workpapers, exception and deficiency records, re-test and roll-forward results, the reliance log, and the disposition rationale.\n\nThe final package: conclusions, deficiencies with dependency analyses, severity rationales, action plans or the escalation decision, and the reviewer sign-off.\n- The deficiency and action items created earlier in this workflow.\n- The unified control records and the program's test-status tracking; the retention policy.\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, self-sufficient package for the cycle — scope through severity — that the reviewer signs, the deficiency workflow consumes, and an external auditor could reperform from.\n\n2. Compile in workpaper order: (1) scope and system inventory with layer rationale; (2) the objective-to-control map with SOX overlays and catalog script versions; (3) populations with completeness evidence and IPE conclusions; (4) per-cell test workpapers with sample bases and attribute grids; (5) exceptions, deficiencies, and the dependency-based severity analyses; (6) re-tests, roll-forwards, and the benchmark determination; (7) action plans or the escalation memo; (8) the reliance coordination record; (9) reviewer sign-off with its scope.\n3. Run the reperformability check on the whole: a competent stranger, given only this package, re-draws every sample from recorded parameters, resolves every tickmark, and reaches the same conclusions.\n4. State the conclusion once, precisely scoped: systems covered, period and segments, ITGC domains, results by domain, deficiencies with severities — and the consequence for reliance on dependent automated controls and key reports. That last sentence is the one the business-process leads and the external auditor actually read.\n5. List unresolved constraints honestly: evidence never produced, thin post-remediation instance counts, SOC 1 gaps bridged by letters, assumptions carried by the population IPE conclusions — so the downstream reader inherits the caveats instead of rediscovering them.\n6. Verify the links: unified controls, system items, exceptions, deficiencies, action items — all navigable from this workflow.\n\n7. Assessment scope for Handoff to related workflow: 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 cycle on that acknowledgment with the package archived and the tested records updated.\n\n8. If the disposition was clean, record \"no deficiencies — no handoff required\" on this step and go straight to the closing items below; items 9–14 apply when deficiencies exist.\n9. Create or link one SOX Deficiency Remediation workflow per deficiency — not per exception: exceptions sharing a root cause travel together as one deficiency.\n10. Pass the package: the deficiency statement, root cause, severity classification with the dependency analysis, the action plan (owner, due date, interim mitigation, closure standard), the exception evidence references, and the re-test window arithmetic — including which unified control and catalog script the re-test will reuse.\n11. 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-cycle ITGC test is not re-run — the remediation re-test scopes to post-fix instances per the closure standard.\n12. State what downstream owns: implementing the fix, evidencing it, the re-test at the stated standard, closure, and status reporting until closed — plus coordinating with the controls team wherever the fix alters the shared unified control or its catalog script.\n13. Transfer the caveats that touch remediation: unresolved constraints from the final package (for example, evidence the owner never produced — the fix may need to address evidence retention itself).\n14. Confirm receipt: the remediation owner acknowledges the package and its dates.\n15. Verify completion honestly before archiving: every step 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.\n16. Archive the final package as the record of the cycle: attached versions are final, superseded drafts are marked 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. Record the archive confirmation; post-archive corrections happen as new dated addenda — never silent edits.\n17. Update the tested records: per unified control and system, the test status (effective / deficiency-in-remediation / excluded-with-coverage), test date, period covered, result, and links back here. This is what next cycle's roll-forward, the business-process reliance decisions, and the external auditor read — and what the controls team's catalog metrics count on.\n18. Schedule the forward obligations with owners, not just dates: remediation re-tests, risk-acceptance expiries, next-period SOC 1 re-review, next cycle's test, and the catalog change requests raised during mapping and testing — those must not die in a backlog.\n19. Communicate closure: the conclusion and its reliance consequence to the SOX PMO, IT control owners, and business-process test leads (benchmark status), and to the external auditor per the reliance log.\n20. Fold the PBC learnings — owner changes, chronically late evidence — into the notes next cycle's roll-forward will read.\n\n**Record in AssureSwarm**\nStep document: attach the compiled package (PDF), or an index document pointing at each attached component, to this step — and explicitly re-attach the escalation/risk-acceptance memo from the escalate branch so the accepted-risk decision is carried in the terminal package rather than orphaned.\n- Enrich the anchor Audit: set Audit.rating (satisfactory | needs_improvement | unsatisfactory), Audit.opinion, and Audit.report_date to reflect the cycle's ITGC conclusion.\n- Record the scoped conclusion statement and the open-constraints list on this step.\n\nHandoff package: create one SOX Deficiency Remediation workflow instance on each deficiency Issue; record this source workflow and the relevant Control-hosted SOX workflow/Test-step references in the handoff notes, and link the Issue to the affected Control and anchor Audit.\n- Step document: record the handoff date, the do-not-repeat boundaries, and the receiving owner's acknowledgment on this step — or the clean-path \"no handoff required\" note — plus the archive confirmation, retention basis, and communication recipients with dates.\n- Workflow instance: set the run's final status and archive the package as the record of the cycle.\n- Confirm each Control-hosted SOX testing workflow reflects its final Test-step conclusion (operating_effectively | exceptions_noted | not_operating_effectively) and tester; its direct Control host supplies the association; the per-application system inventory stays as the archived XLSX workpaper (no native System item).\n- Enrich the anchor Audit with the final Audit.report_date; forward obligations persist as next-period Control-hosted SOX testing workflows (Workflow.customFields.sox.fiscalYear = next) and as target_remediation_date deadlines on open deficiency Issues.\n\n**Exit criteria**\nThe package reads standalone and reperformable; the conclusion states the reliance consequence for dependent automated controls and key reports; 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 dispositioned; the package archived with the archive confirmation recorded; control and system records updated; forward obligations scheduled with owners; closure communicated; any later correction is a new dated addendum.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` compiles the linked workpapers, evidence, and conclusions into the reviewable package with an index.","label":"Handoff to related workflow","performedBy":{"note":"","primitives":["coach-render-package","coach-document-upload","coach-item-update"]}},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-itgc-testing"}