{"description":"SOX Deficiency Remediation carries one control deficiency's full lifecycle — grade, root cause, remediation, validation, and closure. The workflow runs on the deficiency **Issue item** it opens at grading — `issue_type` set to the exact SOX grade (deficiency / significant_deficiency / material_weakness) and `severity` on the mapped AssureSwarm scale — linked to the affected Control(s), the source Control-hosted SOX testing workflow (template kind: sox-testing), and the current-year SOX audit (Audit, `audit_type: sox_testing`); the remediation actions and the validation retest live as steps on this Issue's own workflow. In scope: a single deficiency triggered by a failed test or unresolved exception. It **consumes** the concluded, reviewed failed-test workpaper handoff package owned upstream (SOX Key Control TOD/TOE Test and SOX ITGC Testing) and **hands off** the closed-or-carried deficiency outcome — with its intact severity history and any triggered communication obligations — to Quarterly Board & Audit-Committee GRC Reporting, which aggregates the full deficiency population into the period's ICFR conclusion and audit-committee materials. It exchanges handoff packages with those related workflows rather than duplicating their work.","edges":[{"id":"e-open-and-grade-the-deficiency-draft-remediation-plan","source":"open-and-grade-the-deficiency","target":"draft-remediation-plan"},{"id":"e-draft-remediation-plan-validate-after-fix","source":"draft-remediation-plan","target":"validate-after-fix"},{"id":"e-validate-after-fix-classify-disposition","source":"validate-after-fix","target":"classify-disposition"},{"id":"e-classify-disposition-create-action-plan","label":"Action","source":"classify-disposition","target":"create-action-plan","whenValue":"gaps"},{"id":"e-classify-disposition-handoff-to-related-workflow","label":"Clear","source":"classify-disposition","target":"handoff-to-related-workflow","whenValue":"complete"},{"id":"e-classify-disposition-escalate-or-accept-risk","label":"Escalate","source":"classify-disposition","target":"escalate-or-accept-risk","whenValue":"monitor"},{"id":"e-create-action-plan-handoff-to-related-workflow","source":"create-action-plan","target":"handoff-to-related-workflow"},{"id":"e-escalate-or-accept-risk-handoff-to-related-workflow","source":"escalate-or-accept-risk","target":"handoff-to-related-workflow"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-RISK-14","UC-AUDIT-17"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-deficiency-remediation","contentDigest":"sha256:8b3fcc0e9ec08f3b44dfc9cfbb44cf2d57ce6a0729c257e1de8142822e4212df","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8b3fcc0e9ec08f3b44dfc9cfbb44cf2d57ce6a0729c257e1de8142822e4212df","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-deficiency-remediation"},"lineOfDefense":"monitor","mappingStatus":"mapped","risks":[],"slug":"sox-deficiency-remediation","source":"coworkcanvas-gallery","standards":["sox","coso-ic"],"teams":["finance"]},"name":"SOX Deficiency Remediation","nodes":[{"data":{"description":"Complete Open and grade the deficiency","instructions":"**Objective** — Turn a single failed SOX key-control test — or a single test exception — into a graded, tracked, and defensible deficiency record: the entry point that converts a testing failure into an issue the remediation lifecycle can carry. The data model is deliberate: a SOX deficiency is an **Issue item** with `issue_type` set to the exact grade (deficiency / significant_deficiency / material_weakness) and `severity` set to the mapped AssureSwarm scale — there is no separate deficiency item type — and the corrective actions drafted in later steps live as steps on this Issue's own workflow, not as a separate task type.\n\n**Inputs**\n- Consumes the handoff package from SOX Key Control TOD/TOE Test and SOX ITGC Testing: the concluded, reviewed failed-test workpaper — result narrative, exception schedule, population and sample basis, evidence references, and sign-offs.\n- The failed test reference and its result narrative — or the single test exception it starts from — from that concluded failed-test package.\n- The linked SOX-relevant control(s) and their designed behavior.\n- The affected FSLIs and assertions.\n- Prior-year deficiency history for the same control.\n- The overall and performance-materiality thresholds from the current ICFR scoping, and any customer-specific severity rubric in force.\n- Candidate compensating controls.\n- The current-year SOX audit record to link against.\n\n**Procedure**\n1. Pull the failed test and its exceptions (or the starting exception), the linked control(s), the related FSLIs, and the prior-year deficiency history for the control.\n2. Short-circuit check: if the deficiency already arrived drafted and operator-confirmed from an upstream failed-control-test finding, do not re-capture its fields or re-grade it — carry the confirmed grade and CCCER text forward and continue at step 6.\n3. Otherwise draft the finding in CCCER format. Condition: what actually failed, taken from the test result narrative. Criteria: the control's designed behavior plus the COSO principle and SOX standard it supports. Cause: the root cause from tester observations, or explicitly marked [NEEDS INFO] when the tester did not establish it — never invent a cause; the root-cause step downstream resolves the marker. Effect: the financial-statement misstatement risk, quantified wherever the population and exposure allow. Recommendation: the corrective action implied by the control design and any prior-year remediation.\n4. Propose a severity classification by working the SOX grading procedure: compare potential and actual magnitude against the materiality threshold; assess likelihood — systemic versus isolated, recurrence, duration, transaction volume and complexity, fraud susceptibility; weigh any compensating control that has itself been tested effective (an untested one weighs nothing); consider aggregation with related deficiencies affecting the same account or assertion; then land the proposed grade on the canonical vocabulary — control deficiency, significant deficiency, or material weakness — with a two-to-three-sentence rationale and a structured factor record. Keyword signals in the narrative (\"material misstatement\", \"pervasive\", \"management override\" versus \"isolated instance\", \"minor finding\") corroborate the proposal or flag it for a harder look — they never replace the worked magnitude-times-likelihood grade, and no source-based severity default applies to a deficiency the way it can in general issue intake. The agent only proposes the grade; it never sets severity on its own — the SOX lead confirms or overrides every grade before it is written.\n5. Record the confirmed grade in two places on the Issue: `issue_type` carries the exact SOX grade (material_weakness / significant_deficiency / deficiency), and `severity` carries the mapped AssureSwarm scale — material_weakness maps to critical; significant_deficiency maps to high; a control deficiency maps to medium; an observation below control-deficiency maps to low with `issue_type: observation` (an observation is not a SOX deficiency grade). Because `issue_type` holds the exact grade, the severity mapping loses nothing.\n6. Find the current-year SOX audit, then create the deficiency as an **Issue** with a descriptive title, `issue_type` = the confirmed grade, `severity` = the mapped scale, `source: sox_testing`, `issue_owner` = the routed owner, `identified_date` = the identification date, `root_cause` combining the condition, criteria, cause, and effect, and `description` carrying the full CCCER finding text; leave status at its default and put the SOX lead on the watchlist. Owner routing follows control affinity: the linked control's owner is the default and strongest candidate; where several controls are affected, propose the owner of the control whose failure drives the grade.\n7. Link the issue to every affected control and to the SOX audit, and link it back to the source test so traceability is bidirectional.\n8. Keep the granularity default: one deficiency per failed test; collapse clustered failures across multiple tests of the same control into a single deficiency that references all of those tests.\n9. Human checkpoint: the SOX lead confirms or overrides the proposed severity and signs off the CCCER finding text before the issue is written. When the confirmed grade is a material weakness (critical), surface a one-line reminder that board or audit-committee notification is typically required and that the operator owns that communication outside this workflow — and escalate that notification decision before the deficiency proceeds.\n\n**Record in AssureSwarm**\n- **Item create** — Issue: `issue_type` = deficiency|significant_deficiency|material_weakness (the exact grade), `severity` = the mapped scale (critical|high|medium|low), `source: sox_testing`, `description` = the full CCCER finding, `root_cause` = condition/criteria/cause/effect (or [NEEDS INFO]), `issue_owner`, `identified_date`.\n- **Traceability** — use item relationships for Issue ↔ affected Control(s) and Issue ↔ the current-year SOX Audit (`audit_type: sox_testing`); keep the Issue as a linked item on the source workflow's Test step so the Control-hosted result remains traceable.\n- **Step record** — the grading factor record and severity rationale, the proposed-versus-confirmed grade, the affected FSLIs and assertions, and the materiality thresholds and compensating-control test status relied on, captured on this step (no native FSLI/assertion or materiality field exists — they ride in the CCCER text and on the step).\n\n**Exit criteria** — A graded deficiency issue exists — carrying the CCCER finding, the confirmed severity with its rationale and factor record, and the root-cause field — linked to its control(s), the current-year SOX audit, and its source test. The grade was proposed by procedure and confirmed by the named SOX lead, never auto-set; the deficiency-to-AssureSwarm severity mapping is applied correctly; an unestablished cause reads [NEEDS INFO] rather than a guess; completeness-and-accuracy support for the finding is retained and the work is reperformable; any material-weakness notification reminder is surfaced and its escalation decision recorded — ready for the root-cause step.","label":"Open and grade the deficiency","performedBy":{"agent":"sox-artist","note":"drafts the CCCER finding, proposes the severity grade for SOX-lead confirmation, maps it to the AssureSwarm severity scale, and opens the graded issue linked to its controls, the SOX audit, and the source test","primitives":["coach-query-data","coach-item-create","coach-items-link"]}},"id":"open-and-grade-the-deficiency"},{"data":{"description":"Capture the remediation plan for the deficiency as owned, dated corrective actions that attack the evidenced root cause and land inside the year-end retest window.","instructions":"**Objective**\nCapture the remediation plan for the deficiency as owned, dated corrective actions that attack the evidenced root cause and land inside the year-end retest window.\n\n**Inputs**\nThe graded deficiency issue: CCCER finding, factor record, confirmed severity.\n- The exception schedule from the source test: which samples failed, when, performed by whom, at which location or entity.\n- The control's design documentation and walkthrough narrative; access to the performer(s) of the failed instances.\n- Prior-year deficiency history — repeat status and what last year's fix claimed to solve.\n\nThe confirmed root cause and failure-mode class from the preceding procedure.\n- The control owner — the default remediation owner.\n- Each specific corrective action being proposed, with a target completion date per action.\n- The certification calendar: the as-of date and the post-fix operating window the control's frequency requires before a retest.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Identify root cause”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Identify root cause: Establish the evidenced root cause of the control failure at a depth a fix can act on — replacing any [NEEDS INFO] marker in the CCCER Cause with a corroborated answer that will drive the remediation design.\n\n2. Read the exception pattern before interviewing anyone: clustering by period (quarter-end crunch), by performer (one untrained person versus everyone), by location, by transaction type or size. Random-and-isolated points at execution slip; systematic clustering points at design, capacity, or inputs.\n3. Classify the failure mode — it routes the fix: design gap (the control as designed cannot prevent or detect the misstatement — threshold too high, review scope missing the risky population); execution failure (adequately designed, performed wrong, late, or not at all); input failure (the control operated on incomplete or inaccurate IPE — the cause lives with the report, not the performer); ITGC knock-on (an access or change-management failure undermines an automated or IT-dependent control — the fix belongs at least partly in the ITGC space).\n4. Run five-whys until the answer changes what you would fix: \"the reviewer missed it\" → why → \"no threshold guidance for unusual items\" → why → \"the procedure was never updated after the system migration\". Stop at the answer a corrective action can attack. \"Human error\" is never a root cause, and a repeat deficiency whose cause reads like last year's is evidence the prior fix treated a symptom.\n5. Corroborate with at least two independent sources: the performer interview plus examination of the actual failed artifacts, adding system configuration or report logic where the failure mode implicates them. An uncorroborated interview answer is a hypothesis, not a cause.\n6. Test the cause against the full exception set: it must explain every failed sample. If it explains only some, the finding hides two distinct causes — document both and confirm with the SOX lead that the grading step's aggregation logic still holds.\n7. Note the look-across now: the same cause plausibly operating in sibling controls, other locations, or other processes. The disposition step decides whether it becomes an action plan; this step's job is to not lose it.\n8. If the evidenced cause materially shifts magnitude or likelihood — systemic where isolated was assumed — flag the SOX lead to revisit the confirmed grade before remediation planning proceeds on a stale severity.\n\n9. Assessment scope for Draft remediation plan: Capture the remediation plan for the deficiency as owned, dated corrective actions that attack the evidenced root cause and land inside the year-end retest window.\n\n10. Match the fix to the failure-mode class: design gap → redesign the control (threshold, scope, timing, automation); execution failure → training, capacity, checklist, or accountability change; input failure → fix the report logic or add an input-validation step; ITGC knock-on → coordinate the fix with the ITGC owner rather than patching around it at the application layer. A fix that does not attack the recorded root cause is a symptom patch and will fail its retest eventually — usually next year.\n11. Remediation actions are steps on the deficiency issue's workflow — there is no separate remediation-task item type. If the issue has no remediation workflow yet, create one on the issue.\n12. For each corrective action, add a step carrying a one-line title, instructions describing what the owner must do, the assigned owner, a due date, and status not-started.\n13. Set each due date against retest arithmetic: the remediated control must operate enough post-fix instances before the as-of date to support a fresh operating-effectiveness conclusion — a monthly control fixed in November offers at most two year-end instances, which supports only a thin conclusion. Accelerate the fix or flag the thin window to the SOX lead now.\n14. Define interim mitigation while the fix lands — a compensating control or heightened monitoring, with its own named owner — and note that it must itself be tested if anyone intends to rely on it in a severity or certification judgment.\n15. State the validation evidence the later retest will require (the closure standard): post-fix instances only, the sample bucket the control's frequency dictates, and the artifacts the remediated control will produce — so \"done\" is verifiable rather than declared.\n16. Human checkpoint: the control owner and SOX lead agree the actions and target dates are realistic and address the root cause before the plan is committed.\n\n**Record in AssureSwarm**\n**Item field update** — Issue.root_cause: replace [NEEDS INFO] with the evidenced cause, and record the failure-mode class and the five-whys chain in the same field.\n- **Step documents** — attach or link the corroborating evidence (interview notes, examined artifacts, configuration extracts) to this step.\n- **Step record** — note look-across candidates and any re-grade flag raised on this step (a confirmed re-grade updates Issue.issue_type and Issue.severity back at the grading step).\n\n**Item field update** — Issue.remediation_plan (RICHTEXT): the root cause the plan attacks, the interim mitigation with its named owner, and the closure standard (the validation evidence the later retest will require); set Issue.target_remediation_date to the latest corrective-action due date.\n- **Workflow steps** — each remediation action as an assigned, due-dated step on the Issue's remediation workflow (no separate remediation-task type).\n\n**Exit criteria**\nThe issue's root-cause field carries an evidenced, corroborated cause at fix-actionable depth; the failure-mode class is recorded; the cause explains the full exception pattern (or the split is documented); look-across candidates and any re-grade flag are recorded for the plan and disposition steps. All remediation steps are drafted, assigned, and dated on the issue's workflow; every action has a named owner and a target date that survives the retest arithmetic; the set of actions plausibly resolves the stated root cause; interim mitigation and the closure standard are recorded.","label":"Draft remediation plan","performedBy":{"agent":"sox-artist","note":"Draft remediation steps","primitives":["coach-workflow-build","coach-workflow-assign","coach-item-update"]}},"id":"draft-remediation-plan"},{"data":{"description":"Complete Validate after fix","instructions":"**Objective** — Validate that the remediation actually fixed the control: once the owner reports the plan steps complete, run a fresh operating-effectiveness retest of the remediated control and propose its disposition.\n\n**Inputs**\n- Confirmation that all remediation steps on the issue's workflow are complete, with the fix's effective date.\n- The linked control(s) and the closure standard recorded in the remediation plan.\n- The sampling plan and test procedure for the retest.\n\n**Procedure**\n1. Confirm the seasoning window before drawing anything: the remediated control must have operated long enough post-fix to test — roughly 25 available instances for a daily control, five or more weekly, two to three monthly instances, at least two full quarterly instances. A retest drawn before the fix has genuinely operated proves nothing; wait, or flag the thin window to the SOX lead.\n2. Add a validation step on the issue's workflow — its title names the test period (for example, a year-and-quarter) — and record the sampling plan and test procedure on it.\n3. Assign a tester independent of the remediation: never the fix's implementer, the control owner, or the control's performer — the fix's author validating the fix is self-review.\n4. Define the population as post-fix instances only, from the fix's effective date; never blend pre-fix instances into the retest. Size the sample from the standard frequency buckets (daily → 25; weekly → 5–10; monthly → 2–5; quarterly → 2; annual → 1).\n5. Run the retest as a fresh test of the remediated control's operating effectiveness against the plan's closure standard; link the resulting test evidence back to this validation step, then record the per-sample outcome on it.\n6. Disposition on outcome: if all samples pass, propose closing the deficiency. If any sample fails, keep the deficiency open, return to the remediation-plan step for the next remediation cycle, and re-grade severity if circumstances warrant — a failed remediation late in the year often raises likelihood, and the deficiency may stand at a higher grade in the as-of assessment.\n7. Human checkpoint: the tester records the outcome and the SOX lead reviews it before disposition.\n\n**Record in AssureSwarm**\n- **Workflow step** — a validation step on the Issue's workflow carrying the validation test period, sampling plan, tester, and per-sample retest result.\n- **Step document** — the retest workpaper (XLSX) attached to this validation step, with the underlying test evidence linked back to it.\n- **Step record** — the proposed close-or-reopen disposition (a failed sample routes back to the remediation-plan step and may re-grade Issue.issue_type / Issue.severity).\n\n**Exit criteria** — The retest is complete and reperformable as a test of the remediated control, with completeness-and-accuracy support retained; its outcome is recorded and linked back to the deficiency; a close-or-reopen disposition is proposed and SOX-lead reviewed.\n\n> **⚡ Audit Artist accelerator:** `/sox-testing` plans the retest, draws the post-fix sample with a recorded seed, and does the mechanical tick-and-tie of evidence to samples for the validation workpaper.","label":"Validate after fix","performedBy":{"agent":"sox-artist","note":"Validate remediation retest","primitives":["coach-workflow-execute","coach-form-fill","sox-testing","coach-document-upload"]}},"id":"validate-after-fix"},{"data":{"decisionField":"disposition_path","description":"Classify this remediation's overall result — clean completion, residual gaps needing owned action, or exposure carried under escalation or acceptance — so only the relevant closure path runs. Proposed by the remediation coordinator; owned by the SOX lead under the program's severity authority.","formData":{"fields":[{"key":"disposition_path","label":"Classify disposition","options":[{"label":"Complete","value":"complete"},{"label":"Gaps require action","value":"gaps"},{"label":"Monitor without immediate action","value":"monitor"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nClassify this remediation's overall result — clean completion, residual gaps needing owned action, or exposure carried under escalation or acceptance — so only the relevant closure path runs. Proposed by the remediation coordinator; owned by the SOX lead under the program's severity authority.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe passing validation result and the reference to the validating test step.\n- The closure date, and the certification calendar's as-of date to read it against.\n\n*Agent retrieval, preparation and filing absorb “Close the deficiency”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Close the deficiency: Close the deficiency on the strength of a passed validation retest and preserve its full audit trail: severity history intact, closure traceable to the validating evidence.\n\n2. Human checkpoint first: the SOX lead confirms the validation passed — against the plan's closure standard, on post-fix instances, by an independent tester — before the deficiency is closed.\n3. Update the issue to status closed and stamp the closure date.\n4. Record a one-line closure note citing the validating test step and the date it passed.\n5. Leave the severity history alone: the issue's field history preserves every severity change automatically — the initial grade, any post-remediation re-grade, and the post-validation grade — do not overwrite or restate it. That history is what an external auditor reads to see the deficiency was graded honestly while open, not back-rated at closure.\n6. Read the closure against the as-of date: a deficiency closed before fiscal year-end on a seasoned, passed retest supports assessing the control effective as of year-end; a closure after the as-of date does not cure that year's assessment — the deficiency is evaluated as open for it, and the fix benefits the next one. Note which side of the line this closure lands on; the disposition step consumes it.\n7. Remember what closure does not end: a deficiency that spent time graded significant deficiency or material weakness keeps its audit-committee and external-auditor communication trail — closure ends remediation, not the reporting obligations already triggered.\n\n8. Assessment scope for Classify disposition: Classify this remediation's overall result — clean completion, residual gaps needing owned action, or exposure carried under escalation or acceptance — so only the relevant closure path runs. Proposed by the remediation coordinator; owned by the SOX lead under the program's severity authority.\n\n\n\n**complete** (Complete) — the deficiency closed before the as-of date on a seasoned, passed retest; the root cause is fully addressed with no look-across candidates left undispositioned; interim mitigations are retired or formalized; and the aggregation re-check shows no related open deficiencies keeping combined severity elevated on the same account or assertion. Nothing remains but packaging and reporting.\n- **gaps** (Gaps require action) — this deficiency closed, but owned work remains: the root cause implicates sibling controls, locations, or processes not yet fixed; validation passed on a thin post-fix window and next cycle needs an early retest; interim compensating controls still run and need decommissioning or formalizing into the control population; or improvements surfaced during remediation are uncommitted. Route to the action-plan step to convert every residual into an owned, dated action.\n- **monitor** (Monitor without immediate action) — exposure is consciously carried rather than actioned now: closure landed (or will land) after the as-of date, so the year-end assessment still carries the deficiency at its confirmed grade; the full fix is scheduled beyond the current cycle with interim reliance on compensating controls; or management proposes accepting residual risk. Route to the escalation step — exposure carried at significant-deficiency level or above always requires certification-chain visibility, and any acceptance needs authority, conditions, and an expiry.\n\n**Record in AssureSwarm**\n**Item field update** — Issue status → CLOSED; `actual_remediation_date` = the closure date; `verified_date` = the date the validation passed.\n- **Step record** — the one-line closure note citing the validating test step and its pass date, recorded on this step.\n- **Item field history** — the final `severity` and `issue_type` remain with the full severity-change history intact in the platform field history; never overwritten or restated at closure.\n\nSubmit this step's form: `disposition_path` = the chosen branch; the step result = the closure-versus-as-of-date position, the look-across and aggregation checks performed, and the specific residuals or carried exposure driving the call; the step's approver record = the SOX lead or severity authority making it.\n\n**Exit criteria**\nThe deficiency is closed with a validation-referenced closure note; closure is supported by a passed validation retest; the severity-change audit trail is intact; the closure's as-of-date position is noted for the disposition step. Form submitted; the rationale shows the residual and exposure analysis rather than asserting a label; unused branches are prunable because the recorded value matches one branch edge.","kind":"decision","label":"Classify disposition","performedBy":{"agent":"sox-artist","note":"Close deficiency","primitives":["coach-form-fill","coach-item-update"]}},"id":"classify-disposition"},{"data":{"description":"Create an owned action plan for gaps","instructions":"**Objective** — Convert every residual identified at disposition into an owned, dated, verifiable action — or an explicit, documented acceptance — so look-across exposure and thin spots do not wait for next year's failed test to resurface.\n\n**Inputs**\n- The disposition rationale's residual list: look-across candidates, thin validation windows, running interim mitigations, uncommitted improvements.\n- The root-cause record and failure-mode class; the control population inventory for sibling controls, locations, and processes.\n- The certification calendar and next cycle's test plan.\n\n**Procedure**\n1. Run the look-across concretely: for each sibling control, location, or process sharing the root cause, disposition it — test now, fix now, or accept with a written rationale. Silence is not a disposition, and a shared design flaw across locations is one systemic deficiency in the making, not several small ones.\n2. Define each action at fix depth: what changes, who performs the change, and what evidence completion will produce. Assign an owner with actual authority over the item, and set a due date that survives the same retest arithmetic used for the primary fix.\n3. Disposition running interim mitigations: retire each with a dated decommission action, or formalize it as a control in its own right — which puts it in next cycle's test population with an owner and documentation.\n4. Schedule the early next-cycle retest explicitly for any thin validation window: period, tester, and the sample the fuller window will support.\n5. State each action's closure standard and its reporting cadence into Quarterly Board & Audit-Committee GRC Reporting until closed.\n6. Confirm with the SOX lead that no residual, aggregated with the open deficiency population, changes a severity conclusion — if one does, that is a grading conversation, not an action-plan line.\n\n**Record in AssureSwarm**\n- **Workflow steps** — actions tied to this deficiency added as owned, due-dated steps on the Issue's remediation workflow, each carrying its closure standard (no separate action/task type exists).\n- **Item create** — look-across residuals that outlive this instance as child Issue items (`issue_type: observation`, `source: sox_testing`, `issue_owner`, `target_remediation_date`), linked Issue ↔ Control to the sibling Control and Issue ↔ Audit to the SOX audit so they stay trackable and reportable into quarterly reporting.\n- **Step record** — the look-across dispositions, including the explicit accept-with-rationale entries, and the reporting cadence into Quarterly Board & Audit-Committee GRC Reporting.\n\n**Exit criteria** — Every residual from the disposition rationale is either an owned, dated action with a closure standard or an explicit accepted-with-rationale record; look-across dispositions are complete; the reporting cadence into the quarterly reporting workflow is set.","label":"Create action plan"},"id":"create-action-plan"},{"data":{"description":"Escalate to SOX PMO, control owner, reviewer, or certification owner or document risk acceptance","instructions":"**Objective** — Put the carried exposure in front of the people accountable for certification — quantified, with options — and land a documented decision: escalate through the SOX PMO and certification chain, or accept a bounded residual risk with authority, conditions, and an expiry.\n\n**Inputs**\n- The disposition rationale: why exposure is being carried (post-as-of closure, deferred fix, proposed acceptance).\n- The deficiency's confirmed severity and factor record; the affected accounts and assertions with balances; compensating controls and their test status.\n- The escalation chain: control owner, SOX PMO, certifying officers, the audit-committee reporting track, and the external-auditor communication obligations.\n\n**Procedure**\n1. Draft the decision memo: the deficiency in one paragraph; the quantified exposure — accounts and assertions affected, magnitude against materiality, and the period the exposure stays open; the severity at which it is carried; the compensating controls relied on, with their own test status stated (an untested mitigation mitigates nothing); the options — accelerate the fix, rely on tested compensating controls, or accept for a bounded period — and a recommendation.\n2. Route by severity. Exposure carried at material-weakness level, or any fraud indicator: to the SOX PMO and certifying officers immediately, with external-auditor communication coordinated — an open material weakness at year-end drives an adverse ICFR opinion, and the disclosure consequences are theirs to manage by design, not by discovery. A carried significant deficiency: to the PMO now, on the written audit-committee and external-auditor communication 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 against fraud indicators. It requires: a named acceptor with actual authority over the exposure, tested compensating controls named in the acceptance, an expiry or re-review date, and the conditions that void it — balance growth, a repeat exception, a compensating-control failure.\n4. Acceptance changes accountability, not arithmetic: an accepted deficiency keeps its confirmed grade and stays in the aggregation analysis and the 302 and 404 evaluations until genuinely remediated. Write that into the memo so nobody reads acceptance as erasure.\n5. Capture the decision: decider, date, decision, conditions, expiry — and follow-up ownership: who drives the deferred fix, who retests, who tracks the acceptance to its expiry, who reports status into quarterly reporting.\n6. Feed the decision back into the disposition record so the final package reflects the outcome, not just the recommendation.\n\n**Record in AssureSwarm**\n- **Step document** — attach the decision memo (DOCX/PDF) to this step; record the decider, date, decision, and conditions on the step.\n- **Item field update (risk-acceptance case)** — on the deficiency Issue, `exception_approver` = the named acceptor with authority over the exposure and `exception_expiry_date` = the acceptance expiry / re-review date (the filterable expiry index); `issue_type` and `severity` stay at the confirmed grade — acceptance changes accountability, not the grade, so it is never restated to policy_exception and the deficiency stays in the aggregation and the 302/404 evaluations until genuinely remediated.\n- **Workflow steps** — the follow-up items (deferred-fix action, retest, acceptance-expiry review) as owned, due-dated steps on the Issue's workflow.\n\n**Exit criteria** — A dated decision by someone with authority exists: escalated with certification-chain and external-auditor visibility, or accepted below the significant-deficiency line with tested compensating controls, conditions, and an expiry; the deficiency's grade and aggregation treatment are unchanged by acceptance; follow-up ownership is assigned.","label":"Escalate or accept risk"},"id":"escalate-or-accept-risk"},{"data":{"description":"Hand this deficiency's outcome to Quarterly Board & Audit-Committee GRC Reporting with a package complete enough that reporting aggregates and presents it without re-deriving anything, with explicit boundaries on what it must not redo — and close the remediation on that acknowledgment with an immutable audit trail.","instructions":"**Objective**\nHand this deficiency's outcome to Quarterly Board & Audit-Committee GRC Reporting with a package complete enough that reporting aggregates and presents it without re-deriving anything, with explicit boundaries on what it must not redo — and close the remediation on that acknowledgment with an immutable audit trail.\n\n**Inputs**\nEverything produced upstream: the concluded failed-test package reference, the CCCER finding, the grading factor record and confirmed severity, the root-cause analysis, the remediation plan and completed steps, the validation retest evidence, the closure note — plus the residual action plan or the escalation and risk-acceptance records where those branches ran.\n\nThe final package with its scoped conclusion and the SOX lead's sign-off; the residual action plan or the escalation and acceptance records where those branches ran.\n- The reporting calendar: the next quarterly cycle's cut-off and audit-committee meeting date.\n- The control record and the deficiency issue; the program's 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 evidence-and-decision package for this deficiency's lifecycle — what the SOX lead signed, what quarterly reporting will consume, and what an external auditor could reperform the grading and closure conclusions from.\n\n2. Compile in lifecycle order: (1) deficiency identification — control, period, source test; (2) the CCCER finding; (3) the severity assessment — magnitude and likelihood factors, compensating controls with their own test status, the aggregation analysis, the confirmed grade and its AssureSwarm severity mapping; (4) the root cause with its corroboration; (5) the remediation plan and completed steps with the fix's effective date; (6) the validation retest — period, sampling plan, tester, per-sample results, linked evidence; (7) the closure note with its as-of-date position; (8) the residual action plan or the escalation and acceptance memo, per the disposition; (9) the SOX lead's sign-offs at grade, plan, validation, and closure.\n3. Run the reperformability check on the assembled whole: a competent stranger, given only this package, reaches the same grade and the same closure conclusion — every severity factor cites its evidence, the retest sample regenerates from its recorded parameters, every reference resolves.\n4. State the conclusion once, precisely scoped: control, deficiency, confirmed severity and its history, remediation outcome, closure date, and the as-of-date position. This sentence is what the 302 and 404 evaluations and the quarterly roll-up will quote — ambiguity here becomes someone else's certification problem.\n5. List unresolved constraints honestly: thin windows, accepted residuals, actions still open — the downstream reader inherits the caveats, not the archaeology.\n6. Verify the links: source test, control(s), SOX audit, the issue's remediation workflow, validation evidence, action and acceptance records — all navigable from this workflow.\n\n7. Assessment scope for Handoff to related workflow: Hand this deficiency's outcome to Quarterly Board & Audit-Committee GRC Reporting with a package complete enough that reporting aggregates and presents it without re-deriving anything, with explicit boundaries on what it must not redo — and close the remediation on that acknowledgment with an immutable audit trail.\n\n8. Create or link the Quarterly Board & Audit-Committee GRC Reporting workflow for the period this closure — or carried exposure — falls in.\n9. Pass the reporting-relevant facts: the deficiency's identity and control linkage; the confirmed severity and its full history; the remediation outcome and closure date, or the open status and carried grade; the as-of-date position; residual actions with owners and dates; any acceptance with its expiry and conditions; and the communication obligations already triggered — the significant-deficiency and material-weakness written communications, and the material-weakness board-notification reminder from the grading step.\n10. State what downstream must not repeat: severity was graded and confirmed here — reporting aggregates it, it does not re-grade; closure was validated here — reporting cites the validation, it does not retest; the CCCER text is final — reporting summarizes it, it does not redraft.\n11. State what downstream owns: aggregating the whole deficiency population (this one included) into the period's ICFR conclusion; the audit-committee presentation; and tracking residual actions and acceptance expiries at the cadence set upstream.\n12. Transfer the caveats: thin validation windows, accepted residuals, actions still open — reporting inherits them explicitly, with the open-constraints list from the final package.\n13. Confirm receipt: the reporting owner acknowledges the package and its dates.\n14. Verify completion honestly before archiving: every step in this workflow is finished or explicitly dispositioned (skipped-with-reason), decision forms are submitted, the validation evidence is linked, and the handoff is acknowledged. Closing over an open step is how audit trails grow holes.\n15. Archive the final package as the immutable record: attached versions are final, superseded drafts are marked as superseded, and nothing lives only in an inbox. 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 are new dated addenda, never edits.\n16. Update the control record: link this remediation workflow and the validation evidence, and record the deficiency outcome — closed on a passed retest, carried open at its grade, or accepted with an expiry — so next cycle's test planning and the external auditor's reliance assessment read the current state.\n17. Schedule the forward obligations with owners, not just dates: the early next-cycle retest for any thin window, acceptance expiry reviews, residual-action due dates, and the control's next regular test.\n18. Communicate closure and feed the lessons back: the outcome and final severity to the control owner and SOX PMO; the certification-relevant facts into the 302 and 404 evaluation trail; confirmation that the quarterly-reporting handoff carries the audit-committee items; and a note into the program record where this is a repeat deficiency, a root-cause class trending across controls, or a chronically slow fix owner, so next cycle's planning reads it.\n\n**Record in AssureSwarm**\n**Step document** — attach the compiled package (or an index document pointing at each attached component, PDF/DOCX) to this step.\n- **Step record** — the scoped conclusion statement and the open-constraints list recorded on this step.\n\n**Handoff package** — a package (document plus summary) attached to this step carrying the severity history, the closure-or-carried status, the as-of-date position, the residuals, and the triggered communication obligations — consumed by Quarterly Board & Audit-Committee GRC Reporting's first step.\n- **Workflow relationships** — link the reporting workflow instance to this workflow, to the deficiency Issue, and to the affected Control(s).\n- **Step record** — the handoff date, the do-not-repeat boundaries, the receiving owner's acknowledgment, the archive confirmation, the retention basis (the 7-year SOX anchor), and the communication recipients with dates, all recorded on this step.\n- **Workflow instance** — set the workflow's final status.\n- **Item relationship** — confirm the Control ↔ Issue link carries the final outcome (Control has no native deficiency-outcome field, so next-cycle planning reads the outcome via this relationship to the closed-or-carried Issue), and that the deficiency Issue reflects its final status and links.\n\n**Exit criteria**\nThe package reads standalone and reperformable; the conclusion is scoped to control, deficiency, severity history, and as-of-date position; constraints are explicit; every referenced record is linked. The reporting workflow is linked and its owner has acknowledged a package carrying severity history, closure or carried status, as-of-date position, residuals, and triggered communication obligations; the do-not-repeat boundaries are recorded; all steps are dispositioned; the package is archived with confirmation recorded (post-archive corrections are new dated addenda); the control record and deficiency issue are updated; follow-ups are scheduled with owners; closure is communicated.","label":"Handoff to related workflow"},"id":"handoff-to-related-workflow"}],"sourceTemplateId":"workflow-library:sox-deficiency-remediation"}