{"description":"Financial controls policy and segregation-of-duties governance as a decision-aware workflow covering annual policy-suite reapproval and communication, quarterly SoD conflict-matrix refresh, role and system-access conflict screening, mitigating-control documentation, and owner-assignment confirmation, closed out with a control-indexed certified evidence package. Each run is one workflow instance on the existing Process item \"Financial Controls Policy & SoD Governance\" (process_type: financial_reporting, quarterly cadence), enriching — never recreating — the financial-control Policy suite (entity-wide ITGC and period-end financial reporting oversight policies held as Policy items) and the existing Control items UC-FIN-01 and UC-FIN-05 that the cycle operates. In scope: reapproval and communication of the Policy suite and segregation-of-duties screening across the in-scope entities, finance systems, and personnel, with the cycle running either annual policy reapproval plus the quarterly SoD review or the quarterly SoD review alone; out of scope: access provisioning and remediation execution themselves. As a standing governance control it takes no upstream workflow feed and runs on its own annual/quarterly cadence, but it hands off the remediation and deficiency Issues it raises — elimination-path access conflicts and recorded deficiencies — to the access-management and deficiency-evaluation processes that execute them.","edges":[{"id":"e-route-cycle-type-reapprove-policy-suite","label":"Annual reapproval","source":"route-cycle-type","target":"reapprove-policy-suite","whenValue":"annual_reapproval"},{"id":"e-route-cycle-type-refresh-sod-conflict-matrix","label":"Quarterly SoD only","source":"route-cycle-type","target":"refresh-sod-conflict-matrix","whenValue":"quarterly_sod_only"},{"id":"e-reapprove-policy-suite-refresh-sod-conflict-matrix","source":"reapprove-policy-suite","target":"refresh-sod-conflict-matrix"},{"id":"e-refresh-sod-conflict-matrix-disposition-conflicts","source":"refresh-sod-conflict-matrix","target":"disposition-conflicts"},{"id":"e-disposition-conflicts-document-mitigating-controls","label":"Conflicts identified","source":"disposition-conflicts","target":"document-mitigating-controls","whenValue":"conflicts_identified"},{"id":"e-disposition-conflicts-compile-evidence-and-certify","label":"No conflicts","source":"disposition-conflicts","target":"compile-evidence-and-certify","whenValue":"no_conflicts_identified"},{"id":"e-document-mitigating-controls-compile-evidence-and-certify","source":"document-mitigating-controls","target":"compile-evidence-and-certify"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-FIN-01","UC-FIN-05"],"department":"finance","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-financial-controls-policy-segregation-of-duties","contentDigest":"sha256:6b32637212d2ff1458758420c2f6d3363003ac55edee441699e1cb6d539f45c3","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:6b32637212d2ff1458758420c2f6d3363003ac55edee441699e1cb6d539f45c3","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-financial-controls-policy-segregation-of-duties"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"sox-financial-controls-policy-segregation-of-duties","source":"coworkcanvas-gallery","standards":["sox"],"teams":["finance"]},"name":"Financial Controls Policy & Segregation-of-Duties Governance","nodes":[{"data":{"decisionField":"cycle_type","description":"Agent flags which policies are at their annual reapproval due date; human control owner decides whether this cycle runs full policy reapproval or the standard quarterly SoD review only","formData":{"fields":[{"key":"cycle_type","label":"Cycle type","options":[{"label":"Annual policy reapproval cycle","value":"annual_reapproval"},{"label":"Standard quarterly SoD review only","value":"quarterly_sod_only"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Resolve whether this cycle runs the full annual policy reapproval before the SoD review, or the standard quarterly SoD review alone. The SOX PMO control owner owns the call; the quarterly SoD review runs on either branch — this decision only determines whether policy work precedes it.\n\n**Decision criteria**\n- `annual_reapproval` — the right pick when any of the following holds: at least one Policy item in the suite is at or past its `next_review_date`; the scheduled annual reapproval quarter has arrived on the SOX PMO calendar regardless of individual dates; or a triggering change since the last approval (new ERP module, reorganized close process, revised delegation of authority) has made a policy's text stale ahead of its date. Take this branch off-cycle when such an event occurs — waiting for the calendar leaves an approved policy that no longer describes the control.\n- `quarterly_sod_only` — the right pick only when no policy falls due within this quarter, no triggering change events occurred, and the prior annual cycle is fully closed (every reapproval sign-off and communication record on file). Do not use this branch to defer an incomplete annual cycle: a reapproved policy from last cycle that was never communicated forces the annual branch until closed.\n\nWhen genuinely borderline, route to `annual_reapproval`: the cost of that error is a re-review that confirms currency; the cost of the other error is an expired policy sitting in the SOX evidence.\n\n**Record in AssureSwarm** — **Step form**: submit the decision form's `cycle_type` SELECT. In the step result, cite the due-date comparison against the Policy items' `next_review_date` (count of Policy items due or overdue, and their ids) plus any triggering events; name the approver in the step's approver record.\n\n**Exit criteria** — Form submitted with a rationale that traces to the Policy items' `next_review_date` list; decision owner named; the branch not taken is prunable.","kind":"decision","label":"Route cycle type","performedBy":{"primitives":["coach-query-data"]}},"id":"route-cycle-type"},{"data":{"description":"Produce a dated, owner-signed reapproval for every policy due this cycle so the approved policy suite matches how the control environment actually operates today (UC-FIN-01).","instructions":"**Objective**\nProduce a dated, owner-signed reapproval for every policy due this cycle so the approved policy suite matches how the control environment actually operates today (UC-FIN-01).\n\n**Inputs**\nThe financial-control **Policy items** due this cycle (those whose `next_review_date` is at or before the cycle date), each carrying its approved text as an attached document plus `version`, `policy_owner`, `approved_by`, and prior approval record — the Policy suite already exists as items; this step enriches the due ones.\n- The change log since each policy's last approval (systems added or retired, control-owner changes, revised report thresholds and approval limits, process redesigns): a PBC/external **upload at this step**, sourced from ERP and change-management systems outside AssureSwarm.\n- The current org chart and role directory for owner verification: a dated HRIS **upload at this step**.\n\nThe reapproved **Policy items** with their signed approval records and redlines attached from the preceding procedure.\n- The role and org directory, for deriving per-policy distribution lists (HRIS upload at this step).\n- The policy-governance standard's acknowledgment thresholds, if the org sets them (defaults below otherwise).\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Communicate policy updates”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Reapprove policy suite: Produce a dated, owner-signed reapproval for every policy due this cycle so the approved policy suite matches how the control environment actually operates today (UC-FIN-01).\n\n2. Review each due policy against four staleness tests: (a) the systems, reports, and roles it names still exist under those names; (b) its thresholds and approval limits match the current delegation of authority; (c) the procedure it mandates matches how the process runs today — walk one recent live instance to check rather than taking the process owner's word; (d) the policies and procedures it cross-references are themselves current. Draft a redline for every failure.\n3. Check structural completeness against the house policy standard: purpose, scope (entities and systems covered), roles and authority, the control activities mandated, an exception-handling path, review cadence, and version history. A policy with no exception path invites undocumented workarounds — flag it even when nothing else changed.\n4. Verify each policy names a current, active owner holding the authority the policy assigns. Where the named owner has left the role, route reassignment before review: a departed owner cannot reapprove, and no policy advances without a current owner's signature.\n5. Where the review finds nothing to change, the outcome is still an explicit \"reviewed — no changes required\" reapproval, signed and dated. A silent date rollover is not a review and will not survive an auditor's inspection of UC-FIN-01 evidence.\n6. Match the approval to the required authority level: the entity-wide ITGC policies (access provisioning, change management, backup and recovery) and the period-end financial reporting oversight policy typically carry a controller- or CFO-level approver in addition to the operating owner — follow what each policy's own authority section states.\n7. Stage each policy's package — redline, prior approval record, change rationale — for the owner's review; capture the reapproval as a dated sign-off and increment the version and effective date.\n\n8. Assessment scope for Communicate policy updates: Put every reapproved policy in front of the personnel responsible for executing it, with a dated distribution and acknowledgment trail that evidences the communication for UC-FIN-01.\n\n9. Derive each policy's distribution list from current role assignments, never from the prior cycle's list — movers and joiners make a static list stale within a quarter. Include control owners, process owners, and every role the policy's scope section names. Snapshot the list with a date: the snapshot is evidence.\n10. Draft the change summary in behavioral terms — what changed and what recipients must now do differently (\"journal approvals above the new threshold now require a second approver\"). A redline is not a communication; most recipients will not read one.\n11. For \"no changes\" reapprovals, a suite-level notice that the policy was reviewed and remains in force suffices — forcing full re-reads of unchanged policies trains people to ignore policy mail.\n12. Issue each package with a read-and-acknowledge request and a deadline (10 business days is typical). Acknowledgment means an affirmative per-person response — delivery receipts and \"sent\" timestamps prove nothing about receipt by responsible personnel.\n13. Chase to the thresholds: a reminder before the deadline, manager escalation after it. Before this step closes: 100% acknowledgment from named control and process owners (they execute the controls — no exceptions), and at least 95% from the wider governed population with every residual non-acknowledger named and escalated to their manager.\n14. Route future new hires through the onboarding acknowledgment process; this cycle's obligation covers incumbents as of the snapshot date.\n\n**Record in AssureSwarm**\n**Item field update** on each due **Policy item** (enrich, do not recreate — the suite already exists): set `version` (incremented), `effective_date` (this reapproval's date), `next_review_date` (rolled forward per `review_frequency`), `policy_owner` (current owner), and `approved_by` (the approving authority — controller/CFO where the policy's authority section requires it).\n- **Step document** — attach each policy's redline package and its signed reapproval record to this step, and to the Policy item via document attach, so the reapproval evidence travels with the policy.\n\n**Step document** — attach each policy's communication package (the reapproved policy, its change summary, and the dated distribution snapshot) and the acknowledgment log (XLSX: per-person responses, send date, deadline, final rate) to this step. Per-person acknowledgment has no native Policy field, so the log stays a step document by design.\n- **Comment** on each reapproved **Policy item** with the final acknowledgment rate and any escalated residuals, so the communication result travels with the policy.\n\n**Exit criteria**\nEvery policy due this cycle carries a dated reapproval (including explicit \"no changes\" reapprovals) from a named, current owner at the required authority level; versions and next-review dates rolled forward; no policy left assigned to a departed owner. Every reapproved policy shows a dated distribution to a role-derived list; owner acknowledgment at 100% and population acknowledgment at or above threshold, with residuals named and escalated; the acknowledgment record is included in the approved policy package.\n\n> **⚡ Audit Artist accelerator:** `/coach-notify` sends the per-policy distributions, reminders, and escalation notices with a logged chase trail.","label":"Reapprove policy suite","performedBy":{"note":"","primitives":["coach-query-data","coach-item-create","coach-item-update","coach-document-upload","coach-notify"]}},"id":"reapprove-policy-suite"},{"data":{"description":"Agent rebuilds the incompatible-duty conflict matrix from current role definitions; human control owner confirms the matrix reflects the organization's actual financial processes","instructions":"**Objective** — Approve a current, complete conflict matrix as this cycle's screening baseline, so the access screen tests against incompatible-duty pairings that reflect how the organization's financial processes actually run (UC-FIN-05).\n\n**Inputs**\n- The prior cycle's approved matrix (an XLSX document, rolled forward from the prior refresh and also attached to **Control item UC-FIN-05** as the baseline of record) with its per-pairing rationales.\n- The role catalog and the **Process items** for procure-to-pay, order-to-cash, record-to-report, treasury, and payroll (`process_type`, `description`, `process_owner`) whose duties the matrix pairs.\n- The list of systems and processes introduced since the last cycle, from the org/access change feed (upload at this step).\n\n**Procedure**\n1. Enumerate duties per process under the four-function model — authorization, recording (transaction entry), custody of assets, and reconciliation. Work at the duty level (\"vendor master maintenance\", \"payment release\"), never at job-title level: titles hide composite access.\n2. Rebuild the pairings: any two duties that, combined in one individual, create an unmonitored path to misappropriate assets or misstate the financials. Anchor on the canonical high-risk pairs and extend to local process reality: vendor master maintenance + invoice entry or payment approval (procure-to-pay); customer master maintenance + credit memo or write-off authority (order-to-cash); journal entry + journal approval, and journal posting + bank reconciliation (record-to-report); payment initiation + payment release (treasury); payroll master maintenance + payroll processing (payroll).\n3. Record a one-line rationale per pairing — the specific fraud or misstatement path it blocks — and a risk rank: high where the combination is a direct misappropriation or misstatement path, medium where it enables concealment of another's error or fraud. The rank drives disposition urgency downstream.\n4. Cover every system and process introduced since the last cycle. A system with no defined pairings is a hole in the screen, not a clean result: define its pairings or document explicitly why it carries no SoD-relevant duties.\n5. Diff against the prior matrix and list every added, removed, or changed pairing with its reason. Removals need the strongest justification — deleting a pairing to make a known conflict disappear is the classic matrix-gaming pattern, so the reviewer should specifically test removals against open findings.\n6. Walk the diff with the control owner, who corrects missing or over-broad pairings against actual process knowledge and approves the matrix as this cycle's screening baseline.\n\n**Record in AssureSwarm**\n- **Step document** — attach the refreshed conflict matrix (XLSX) and the diff summary with per-change reasons to this step. There is no ConflictPairing item type, so the pairing counts, risk ranks, and diff live inside the matrix document rather than as queryable items — the honest fallback for this cycle.\n- **Item document** — attach the approved matrix to **Control item UC-FIN-05** as this cycle's baseline of record (document attach) and comment there with the approval date, version, and pairing counts by risk rank, so the screening baseline traces to the control it enforces.\n\n**Exit criteria** — Matrix approved and dated by the control owner; every new system or process either covered by pairings or explicitly excluded with rationale; the diff on file with a reason per change; pairing counts by risk rank recorded.","label":"Refresh SoD conflict matrix","performedBy":{"primitives":["coach-query-data","coach-document-upload"]}},"id":"refresh-sod-conflict-matrix"},{"data":{"decisionField":"sod_disposition","description":"Classify the cycle's screening result so the workflow either documents mitigating controls for confirmed conflicts or proceeds straight to owner confirmation. The control owner owns the call, and it must tie to the triaged finding list, not the raw flag count.","formData":{"fields":[{"key":"sod_disposition","label":"SoD screening disposition","options":[{"label":"Conflicts identified","value":"conflicts_identified"},{"label":"No conflicts identified","value":"no_conflicts_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nClassify the cycle's screening result so the workflow either documents mitigating controls for confirmed conflicts or proceeds straight to owner confirmation. The control owner owns the call, and it must tie to the triaged finding list, not the raw flag count.\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThis cycle's approved conflict matrix with risk ranks.\n- Entitlement extracts per in-scope system (ERP, treasury, payroll, expense): user, roles, underlying permissions, grant dates, and last-used where available — each with recorded IPE parameters (source, run date and time, row count).\n- The joiner/mover/leaver population from the org/access change feed since the last cycle, and the HR termination list as of the extract date.\n\n*Agent retrieval, preparation and filing absorb “Screen role and system access for conflicts”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Screen role and system access for conflicts: Identify every individual whose combined role assignments and system entitlements violate the approved conflict matrix, and hand the disposition decision a triaged finding list where every flag carries evidence (UC-FIN-05).\n\n2. Validate each extract before screening: row count ties to a system-side count, the extract date sits inside this cycle, and users join to HR records. An extract that cannot demonstrate completeness voids the screen — \"no conflicts found in a partial population\" is not a conclusion.\n3. Resolve access to the duty level: map each entitlement — the permission or authorization object, not the role display name — to the matrix's duties. Screening role names misses composite access; an individual holding two individually-clean roles whose combined permissions form a conflict is precisely what this control exists to catch.\n4. Cross-reference every individual's combined duties across all their roles and all in-scope systems against the matrix. Cross-system combinations count: payment initiation in the ERP plus release rights in the banking portal is a conflict no single system's report will show.\n5. Flag access-level conflicts explicitly: transaction entry plus approval rights in the same module, reconciliation plus journal-posting rights, master-data maintenance plus transaction processing.\n6. Sweep the joiner/mover population: every individual in the joiner/mover population must appear in the results, screened clean or flagged. Separately match the extracts against the termination list — a terminated individual with active access escalates same-day to the access-management owner for revocation and is recorded as an access-control exception; it does not wait for this cycle's disposition step.\n7. Triage each flag with the control owner into genuine conflict or false positive. Legitimate false-positive reasons: a role-definition error (display-only permission mapped as transactional), a role assigned but never provisioned, duplicate identity records. Seniority or trust in the individual is never a false-positive reason. Every cleared flag keeps its evidence and stated reason — bulk-clearing is the finding-suppression pattern reviewers test for.\n\n8. Assessment scope for Disposition conflicts: Classify the cycle's screening result so the workflow either documents mitigating controls for confirmed conflicts or proceeds straight to owner confirmation. The control owner owns the call, and it must tie to the triaged finding list, not the raw flag count.\n\n\n\n`conflicts_identified` — the right pick when at least one triaged, confirmed conflict remains after false positives are removed — whether new this cycle, carried forward from a prior cycle, already covered by an existing mitigating control, or resolvable by simple reassignment. Existing mitigation does not remove a conflict from disposition: carried-forward conflicts must re-confirm on the mitigation path that their compensating control still operates. Call out in the rationale any high-rank pairing and any material increase over the prior cycle — as a rule of thumb, more than 20% growth in confirmed conflicts, or any new high-rank conflict, warrants a stated cause (reorg, new system, role redesign).\n- `no_conflicts_identified` — the right pick only when the screen demonstrably ran against the complete population (every extract validated, every joiner/mover swept) and every flag was dispositioned as a documented false positive, with no carried-forward conflict still open. A clean result on a partial population is not clean — fix the population and re-screen before choosing this branch. Treat a first-ever zero-conflict quarter with skepticism: in an organization with stable team sizes it usually means the screen lost granularity (role-name matching, a missing system), not that conflicts vanished.\n\n**Record in AssureSwarm**\n**Item create** — one **Issue** per confirmed flagged individual: `issue_type: exception`, `source: self_assessment`, `severity` from the matrix risk rank (high-rank pairing → `high`), `description` (systems, roles, the duty pairing violated, and the triage result with its reason), `issue_owner`, `identified_date`. **Item relationship** — link each conflict Issue to **Control item UC-FIN-05** (`Issue ↔ Control`). Cleared false positives are NOT items — they keep their evidence and stated reason in the screening result document.\n- **Item create** — for each terminated-with-active-access case, a separate **Issue** (`issue_type: exception`, `severity: high`, `source: self_assessment`) escalated same-day to the access-management owner outside this cycle's disposition path.\n- **Dashboard** — the conflict findings dashboard over the conflict Issue items, grouped by individual, process, and conflict type.\n- **Step document** — attach the entitlement extracts (with their IPE parameters) and the screening result file to this step.\n\n**Step form**: submit the decision form's `sod_disposition` SELECT. In the step result, state the confirmed-finding count, the carried-forward count, the prior-cycle comparison, and references to the conflict **Issue items** from the screening step; name the approver in the step's approver record.\n\n**Exit criteria**\nEvery in-scope individual screened at entitlement level across all systems; the joiner/mover population fully swept; terminated-with-access cases escalated and recorded; every flag triaged with a documented reason; finding items and the dashboard reflect the final triaged list. Form submitted with a rationale whose counts tie to the conflict Issue items from the screening step; decision owner named; the branch not taken is prunable.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` scripts the entitlement-to-duty mapping and the matrix cross-reference so the screen is deterministic and reperformable from the same extracts.","kind":"decision","label":"Disposition conflicts","performedBy":{"note":"","primitives":["coach-query-data","coach-dashboard-create","coach-item-create","coach-items-link","sox-python","coach-document-upload"]}},"id":"disposition-conflicts"},{"data":{"description":"Agent drafts a mitigating-control record for each conflict that cannot be resolved by reassignment; human approves each mitigating control as sufficient","instructions":"**Objective** — Leave every confirmed conflict on exactly one documented path: elimination via a dated remediation action, an approved mitigating control that genuinely compensates, or — where neither lands this cycle — a recorded deficiency routed for evaluation (UC-FIN-05).\n\n**Inputs**\n- The confirmed conflict **Issue items** (`issue_type: exception`) with their duty pairings and matrix risk ranks.\n- Existing mitigating **Control items** from prior cycles (`control_type: detective`, `key_control: false`) with their most recent operating evidence attached.\n- Team-size and system-constraint context for impracticability judgments.\n\n**Procedure**\n1. Apply the preference order: eliminate before mitigate. If reassigning or removing access resolves the conflict without breaking the process, that is the answer — a mitigating control is the fallback for genuine impracticability (a three-person finance team; a system that cannot split the permission), and the impracticability must be documented wherever mitigation is chosen.\n2. For elimination-path conflicts, create a remediation item naming the exact access to remove, the target system, the executor, and a due date. Set the SLA by risk rank: high-rank pairings 30 days, medium 60–90. These carry forward into the next cycle as tracked carry-forward items until closed.\n3. Design each mitigating control against the four-part sufficiency test: (a) performed by someone independent of the conflicted individual — not the individual, not their direct report; (b) frequency matched to transaction velocity — daily conflicted activity needs at least monthly review, not an annual look; (c) precision sufficient to detect an error or misappropriation of the size the conflict enables — \"manager scans the report\" fails, \"reviewer traces the conflicted user's transactions above a set threshold to supporting documents\" passes; (d) evidenced each time it operates — a dated sign-off, a reviewed listing, or a log extract.\n4. Draw on the standard mitigation patterns: independent detailed review of transactions the conflicted individual entered; audit-log or activity review over master-data changes; an access-restriction change with logging; rerouting approvals to an independent delegate; a compensating reconciliation performed outside the conflicted person's reporting line. Name who performs it and at what frequency — an unowned mitigating control is a wish, not a control.\n5. Re-verify carried-forward mitigating controls by pulling their last two operating-evidence instances. A mitigating control with no evidence it ran is not a mitigating control: treat that finding as unmitigated and re-disposition it.\n6. Any high-rank conflict ending this step with neither an approved mitigation nor a dated remediation is a control deficiency: record it as one and route it into the deficiency-evaluation process rather than letting it ride as an open task.\n\n**Record in AssureSwarm**\n- **Item create** — one **Control item** per approved mitigating control: `control_type: detective`, `automation: manual`, `key_control: false`, `frequency` (matched to transaction velocity), `control_owner` (the independent performer), `framework` including `sox`, `description` (the precision statement + evidence expectation). **Item relationship** — link each mitigating Control to its conflict **Issue** (`Control ↔ Issue`) and to **Control UC-FIN-05**, so each compensating control traces to the pairing it addresses.\n- **Item field update** — for elimination-path conflicts, update the conflict **Issue** in place (not a second item): `remediation_plan` (the exact access to remove, target system, executor), `target_remediation_date` (30 days for high-rank pairings, 60–90 for medium), `issue_owner`.\n- **Item field update** — any high-rank conflict ending this step with neither an approved mitigation nor a dated remediation: set the conflict **Issue** `issue_type: deficiency` and route it into the deficiency-evaluation process.\n- **Step document** — attach the mitigating-control register and the remediation list to this step.\n\n**Exit criteria** — Every confirmed finding links to exactly one path — an owner-approved mitigating control, a dated remediation item, or a recorded deficiency; impracticability documented wherever mitigation was chosen; carried-forward mitigations re-verified with operating evidence; the control owner's sufficiency approval captured per mitigating control.","label":"Document mitigating controls","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-item-update","coach-document-upload"]}},"id":"document-mitigating-controls"},{"data":{"description":"Assemble a control-indexed evidence package a reviewer could reperform the cycle from, secure the control owner's signed certification that UC-FIN-01 and UC-FIN-05 operated this cycle, and close the cycle on that signature with the package archived and every open item carried forward.","instructions":"**Objective**\nAssemble a control-indexed evidence package a reviewer could reperform the cycle from, secure the control owner's signed certification that UC-FIN-01 and UC-FIN-05 operated this cycle, and close the cycle on that signature with the package archived and every open item carried forward.\n\n**Inputs**\nThe current org chart and HR role data as of the cycle date (HRIS upload at this step).\n- The current owners: `policy_owner` on every **Policy item**, `control_owner` on **Control UC-FIN-05** (which carries the SoD matrix baseline), `control_owner` on each open mitigating **Control item**, and `process_owner` on the anchor **Process item**.\n- This cycle's joiner/mover/leaver feed from the org/access change system, to catch mid-cycle departures.\n\nEvery artifact the cycle produced: reapproved policies with sign-offs; communication packages and acknowledgment logs (annual path); the approved matrix and diff; entitlement extracts and screening results; finding, mitigating-control, and remediation items; the owner-confirmation record.\n- The prior cycle's metrics for trend comparison.\n- Open remediation items, mitigating controls with next re-verification dates, and the forward policy due-date list.\n- The organization's records-retention schedule for SOX evidence.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Confirm owner assignments”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Confirm owner assignments: Verify a live, accepting, authorized owner behind every policy in the suite, the SoD conflict matrix, and every open mitigating control, so accountability survives org churn between cycles (UC-FIN-01, UC-FIN-05).\n\n2. Cross-check every named owner against active employment and current role. Ownership means a named individual: a shared mailbox, \"the finance team\", or a job title with no incumbent all fail the check.\n3. Apply the authority test: the owner must hold the authority the assignment requires — a policy owner can approve changes to the policy; a mitigating-control owner can compel its performance. An owner who moved to an unrelated function keeps the name but loses the authority; flag the assignment even though HR still shows them active.\n4. For mitigating controls, also re-test performer independence after any reorg: if the independent reviewer now reports to — or is — the conflicted individual, the control's design broke this quarter even though nobody touched the record. Route those findings back through the mitigating-control sufficiency test.\n5. Propose successors from the equivalent current role in the org chart. The default interim owner for an orphaned record is the departed owner's manager, until a successor formally accepts.\n6. Capture affirmative acceptance from every new owner in the native assignment and approval records, with one dated decision per record. Assignment without acceptance is how records go orphan silently: the successor confirms in writing; they are not assumed in. A declined or redirected assignment returns to item 5 for a new candidate, and a \"not independent\" answer on a mitigating control is a design finding, not a paperwork problem.\n\n7. Assessment scope for Compile evidence and certify: Assemble a control-indexed evidence package a reviewer could reperform the cycle from, secure the control owner's signed certification that UC-FIN-01 and UC-FIN-05 operated this cycle, and close the cycle on that signature with the package archived and every open item carried forward.\n\n8. Index the package by control. Under UC-FIN-01: evidence each policy is current (dated reapproval sign-offs), owner-assigned, and communicated (distribution snapshots plus acknowledgment rates). Under UC-FIN-05: the approved matrix with its diff, the population-complete screen (extracts with IPE parameters), triage evidence, and a per-conflict disposition. Apply the reperformance test: an auditor holding only this package can re-run the screen and reach the same finding list.\n9. Run the completeness checks as hard gates: every policy due this cycle shows both a reapproval sign-off and a communication record if the annual path ran; every confirmed conflict links to an approved mitigating control, a dated remediation item, or a recorded deficiency; every cleared flag has a triage reason. A gap goes back to its producing step — a certification signed over a known gap converts a process miss into a false assertion.\n10. Compute the cycle metrics: policies reapproved on time (%), acknowledgment rate, confirmed conflicts versus prior cycle, false-positive rate, mitigating controls newly documented, remediations closed. Write the trend commentary — a rising conflict count against flat headcount points at role-design drift, and that sentence is worth more than the table.\n11. Draft the certification: period covered, scope, the assertion that both controls operated as designed, the metrics, and an explicit disclosure of every open item — carry-forward remediations, escalated non-acknowledgers, recorded deficiencies — each with owner and due date. A disclosed, tracked exception leaves the certification clean; an undisclosed one does not.\n12. The control owner reviews the package, resolves or explicitly discloses each gap, and signs the certification with a date.\n13. Export the certified evidence package and archive it in the designated evidence repository under the SOX retention schedule (seven years is the prevailing standard for ICFR evidence; follow the org's schedule where longer). Record the archive location and retrieval path against UC-FIN-01 and UC-FIN-05.\n14. Verify retrievability by actually retrieving: open the archived package from the recorded location and confirm it matches the certified version. Record the archive confirmation; any post-archive correction is a new dated addendum referencing the original — the archived package itself is never edited.\n15. Roll the baselines forward: update the policy suite index and the SoD conflict matrix of record to this cycle's approved versions, so next quarter's scoping starts from the current state rather than a stale copy.\n16. Carry every open item forward as a tracked record with a named owner and due date — reusing its existing item, not minting a duplicate: every open remediation stays on its conflict Issue (`target_remediation_date`, `issue_owner`), every mitigating Control due re-verification carries its next date, and the next-quarter policy due list is the Policy items whose `next_review_date` falls in the coming quarter. The test is absolute: nothing survives cycle close as an untracked intention.\n17. Draft and send the cycle closure notice to the SOX PMO and finance leadership: cycle result, certification status, headline metrics, and the open-item count with owners; confirm the next quarterly cycle sits on the calendar. The signed certification plus the recorded archive confirmation and carry-forward list are the closure declaration.\n\n**Record in AssureSwarm**\n**Item field update** — set the confirmed current individual into `policy_owner` on each **Policy item**, `control_owner` on **Control UC-FIN-05** and each mitigating **Control item**, and `process_owner` on the anchor **Process item**.\n- The native assignment/approval record and step result capture the record they are being asked to own, their acceptance or decline, their confirmation that they hold the required authority, their independence position where the record is a mitigating control, any alternate owner they name, and the dated response.\n- **Comment** on each reassigned record with the reason (departure, move, authority change) and the successor's dated acceptance.\n\n**Item relationship / document link** — link every artifact (reapproved **Policy items**, the approved matrix document, conflict **Issues**, mitigating **Control items**, the owner-confirmation record) to **Control items UC-FIN-01** and **UC-FIN-05** so the package is control-indexed to the two controls it evidences.\n- **Step document** — attach the indexed evidence package (PDF/ZIP), the signed certification, the closure notice, and the archive confirmation (archive location + retrieval-check date) to this step.\n- Record the cycle metrics inside the certification document (there is no native metrics field) so the trend is available next cycle.\n- **Item field update (baseline roll-forward)** — re-attach this cycle's approved matrix to **Control UC-FIN-05** as next cycle's baseline of record; the reapproved **Policy items** already carry their rolled-forward `version` and `next_review_date`, so the policy suite index is current without a separate copy.\n- **Item (existing/updated) carry-forward** — open conflict **Issues** stay open with their `target_remediation_date` and `issue_owner`; mitigating **Control items** carry their next re-verification date in `description`; the next-quarter policy due list is simply the Policy items whose `next_review_date` falls in the coming quarter.\n- **Workflow instance** — completing this step records the owner's dated certification and closure; the instance on the anchor **Process item** is the cycle's durable audit trail.\n\n**Exit criteria**\nEvery policy, the matrix, and every open mitigating control names a current individual who has affirmatively accepted the assignment in the native assignment/approval record; performer independence re-verified for every mitigating control; zero orphaned records; the control owner's sign-off that nothing lacks a live owner. Completeness gates pass or every residual gap is disclosed inside the signed certification; the package is indexed by control id and passes the reperformance test; the certification is signed and dated by the control owner and the cycle metrics recorded; the archived package retrieved successfully from the recorded location with the archive confirmation recorded; baselines rolled forward to this cycle's approved versions; every open item exists as a carry-forward item with owner and due date; closure notice sent.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the control-indexed evidence package with a coverage index from the cycle's linked artifacts.","label":"Compile evidence and certify","performedBy":{"note":"","primitives":["coach-document-upload","coach-items-link","coach-query-data","coach-render-package","coach-workflow-export","coach-item-create","coach-item-update"]}},"id":"compile-evidence-and-certify"}],"sourceTemplateId":"workflow-library:sox-financial-controls-policy-segregation-of-duties"}