{"description":"Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. \"Production Batch Operations & Processing Integrity\"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.","edges":[{"id":"e-triage-and-resolve-processing-exceptions-manage-batch-processing-incident","label":"Escalated to incident","source":"triage-and-resolve-processing-exceptions","target":"manage-batch-processing-incident","whenValue":"escalated_to_incident"},{"id":"e-triage-and-resolve-processing-exceptions-certify-and-file-evidence","label":"Cleared within shift","source":"triage-and-resolve-processing-exceptions","target":"certify-and-file-evidence","whenValue":"cleared_within_shift"},{"id":"e-manage-batch-processing-incident-certify-and-file-evidence","source":"manage-batch-processing-incident","target":"certify-and-file-evidence"},{"id":"e-monitor-events-triage-and-tune-capacity-manage-monitoring-incident","label":"Incident identified","source":"monitor-events-triage-and-tune-capacity","target":"manage-monitoring-incident","whenValue":"incident_identified"},{"id":"e-monitor-events-triage-and-tune-capacity-certify-and-file-evidence","label":"Routine monitoring","source":"monitor-events-triage-and-tune-capacity","target":"certify-and-file-evidence","whenValue":"routine_monitoring"},{"id":"e-manage-monitoring-incident-certify-and-file-evidence","source":"manage-monitoring-incident","target":"certify-and-file-evidence"},{"id":"e-validate-and-release-authorized-outputs-certify-and-file-evidence","source":"validate-and-release-authorized-outputs","target":"certify-and-file-evidence"}],"isPublic":true,"metadata":{"capabilities":[],"controlVerbs":{},"controls":["UC-ACCESS-17","UC-ACCESS-18","UC-ACCESS-20"],"department":"it","domains":["sox"],"library":{"aliases":[],"canonicalUrl":"https://workflow-library.com/all/?w=sox-production-operations-processing-integrity-cycle","contentDigest":"sha256:8dd7743ee60dc1390b3fc9610358d4d11a39542f3ef83c52bf6892a9312df2f3","prerequisites":{"status":"undeclared"},"provenance":[],"releaseId":"sha256:8dd7743ee60dc1390b3fc9610358d4d11a39542f3ef83c52bf6892a9312df2f3","schemaVersion":1,"sourceTemplateId":"workflow-library:sox-production-operations-processing-integrity-cycle"},"lineOfDefense":"operate","mappingStatus":"mapped","risks":[],"slug":"sox-production-operations-processing-integrity-cycle","source":"coworkcanvas-gallery","standards":["soc1","nist-csf-2","iso-27001","sox"],"teams":["it","finance"]},"name":"Production Operations & Processing Integrity Cycle","nodes":[{"data":{"decisionField":"exception_disposition","description":"Investigate every flagged batch failure or exception to a documented root cause and disposition, and decide whether the cycle proceeds with all failures verified clear or any item requires formal incident tracking. The shift operator owns the call, consulting the on-call lead for anything unresolved near shift end. (UC-ACCESS-17)","formData":{"fields":[{"key":"exception_disposition","label":"Processing exception disposition","options":[{"label":"Cleared within shift","value":"cleared_within_shift"},{"label":"Escalated to incident","value":"escalated_to_incident"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective**\nInvestigate every flagged batch failure or exception to a documented root cause and disposition, and decide whether the cycle proceeds with all failures verified clear or any item requires formal incident tracking. The shift operator owns the call, consulting the on-call lead for anything unresolved near shift end. (UC-ACCESS-17)\n\n**Decision criteria**\nInputs and preparation before selecting the branch:\nThe authorized job population from the job scheduler and operations run book: job, authorized window, owner, authorizing change record. AssureSwarm has no native Job/Asset type, so attach the authorized-population extract as a document on this step — the honest fallback for a reference register re-attached each cycle.\n- Scheduler run logs for the cycle: actual start and end, exit status, triggering event per instance — the run-log extract with generation metadata, attached as a document on this step.\n- Approved change tickets covering any ad hoc or on-request executions (external ITSM; referenced in the anomaly notes).\n- Prior-cycle carry-forward Issue items (issue_type: exception, source: management_identified) linked to the anchor Process, plus prior-cycle run history, for repeat-offender comparison.\n- The unified control this leg evidences: Control item UC-ACCESS-17 (framework containing soc1|nist-csf-2|iso-27001).\n\n*Agent retrieval, preparation and filing absorb “Execute and monitor batch schedule”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Execute and monitor batch schedule: Establish that every authorized batch job ran to a clean completion inside its authorized window this cycle, and surface every failure, late run, missed run, and unauthorized execution into a confirmed anomaly list for triage. (UC-ACCESS-17)\n\n2. Pull the run log for every job in the population, capturing per instance: scheduled versus actual start and end, exit code, and trigger (calendar, dependency, manual). Reconcile in both directions — every authorized job shows an instance or a documented skip, and every executed instance maps back to an authorized definition. The second direction is what catches unauthorized runs; checking only the first proves nothing about what else executed.\n3. Classify each anomaly: failed (nonzero exit or abend); late (start or end outside the authorized window, measured against the window boundary, not \"roughly on time\"); missed (no instance where the schedule demanded one, including jobs held by a failed upstream dependency); unauthorized (a manual or ad hoc run with no approved change ticket, or an execution whose schedule differs from the authorized definition). Treat unauthorized as the highest-severity class — it evidences a change-control bypass, not an operational hiccup.\n4. Separate \"failed then rerun clean inside the window\" from \"failed and abandoned\" — a successful auto-restart is still a logged anomaly. Restart storms that self-heal are how capacity and data problems stay invisible until they stop healing.\n5. Cross-reference anomalies against prior-cycle history: the same job failing three or more times in a rolling 30 days is a repeat offender and a candidate for problem-level root cause, not another rerun.\n6. Build the run-status dashboard — on-time, late, failed, missed, unauthorized — with drill-down to instance detail, and attach the full run log so every anomaly traces to its specific job instance.\n\n7. Assessment scope for Triage and resolve processing exceptions: Investigate every flagged batch failure or exception to a documented root cause and disposition, and decide whether the cycle proceeds with all failures verified clear or any item requires formal incident tracking. The shift operator owns the call, consulting the on-call lead for anything unresolved near shift end. (UC-ACCESS-17)\n\n\n\nBuild the evidence before branching, per flagged item: a tracker item linked to the run-log evidence that surfaced it; a root-cause category — data issue, resource contention, code defect, upstream dependency failure, or environment change; the resolution applied (rerun, manual correction, dependency fix); and verification that the resolution actually cleared it, meaning a clean completion of the re-run — not a resubmission still executing at review time. Cross-reference recurring failures against prior-cycle root causes: the same job failing for the same reason across consecutive cycles is a systemic problem that shift-level reruns will not fix, and belongs on the incident branch even if today's rerun worked.\n\n- **Cleared within shift (`cleared_within_shift`)** — every flagged item shows a verified clean completion inside the current shift; reruns finished within the batch window or with a documented, accepted window deviation; any manual correction touching financial data carries a second-person check; no failure recurred after its fix during the shift; downstream dependents ran or were explicitly released. The rationale cites the rerun or correction evidence for each item.\n- **Escalated to incident (`escalated_to_incident`)** — any item meets one of: it cannot be cleared before shift end; the rerun failed again; the fix requires a code change, vendor engagement, or infrastructure change (anything beyond a rerun or parameter correction is by definition not shift-clearable); suspected data corruption or financial-reporting impact, regardless of whether a rerun \"worked\"; or a repeat offender needing problem-level root cause. Escalating some items does not reopen the rest — cleared items stay cleared; the rationale names each escalated item individually.\n\nThe escalated branch routes to formal batch-incident management; the cleared branch proceeds directly to backup verification.\n\n**Record in AssureSwarm**\nBuild or refresh the run-status dashboard for the cycle (dashboard).\n- Attach the run-log extract with its generation metadata — source system, query, run time, row count — since this is system-generated evidence a SOX tester will later rely on (step document, XLSX/CSV).\n- Record on this step: population count, instances executed, anomaly counts by class, repeat offenders flagged. The anomaly list is the input to triage — no tracker Issue items are created here; they are created downstream once dispositioned.\n\nSubmit the decision form on this step: `exception_disposition` (the branch), the step result citing per-item root cause and verification evidence and naming every escalated item, and the step's approver record (step form).\n- Attach the exception register — item, root-cause category, resolution, verification reference (step document, XLSX).\n- Create one Issue item per flagged failure (`issue_type: exception`, `source: management_identified`, `issue_owner`, `identified_date`, `target_remediation_date`), linked to its run-log evidence and related to Control UC-ACCESS-17 (item create + item relationship).\n\n**Exit criteria**\nEvery authorized job dispositioned clean, anomalous, or documented-skip; every executed instance traced to an authorized definition; the anomaly list confirmed by the shift operator as the input to exception triage; run log attached with generation metadata. Form submitted; every flagged exception carries a root-cause category, a disposition, and a verification reference; escalated items individually named in the rationale; no exception left undispositioned.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` scripts the two-way reconciliation between the scheduler run log and the authorized job definitions with recorded parameters, so the anomaly classification is deterministic and reperformable.","kind":"decision","label":"Triage and resolve processing exceptions","performedBy":{"note":"","primitives":["coach-item-create","coach-items-link","coach-query-data","coach-document-upload","coach-dashboard-create","sox-python"]}},"id":"triage-and-resolve-processing-exceptions"},{"data":{"description":"Agent opens a tracked incident for each escalated failure and tracks the fix to a verified re-run; human incident lead approves each resolution","instructions":"**Objective** — Resolve every escalated batch failure through a formal incident record — corrective action tracked to completion, the affected job re-run and verified clean, each resolution individually approved — leaving nothing open except incidents explicitly accepted with a named owner and target date. (UC-ACCESS-17)\n\n**Inputs**\n- The escalated-item list from triage, as the Issue items (issue_type: exception) created there with their linked run-log evidence.\n- The incident procedure — a Policy item (policy_type: procedure, framework containing iso-27001): severity scale, on-call escalation path, communication expectations for financially significant jobs.\n- The batch dependency map, to establish downstream impact (external; referenced on the step).\n- Change records for any code, data, or infrastructure fix applied (external ITSM).\n\n**Procedure**\n1. Open an incident record per escalated failure, linking the triggering job, run-log evidence, and exception-register entry. Rate severity by impact, not noise: a failure blocking financial close or a regulatory feed outranks an internal reporting job. Record the rating and its basis.\n2. Establish downstream impact before fixing: which dependent jobs are held, which interface windows will be missed, whether the day's processing completes without this job. If a workaround is needed while the fix lands — manual processing, deferred posting — any workaround touching financial data requires a named approver, recorded on the incident.\n3. Track the corrective action to completion — code fix, parameter or data correction, vendor escalation, infrastructure change — with actor and timestamp. A production fix applied under emergency change must reference its change record; an untracked fix converts an operations incident into a change-control deficiency.\n4. Re-run the affected job after the fix and verify properly: clean completion within (or with an approved deviation from) its authorized window, output totals consistent with expectation, downstream dependents released and completing. \"It ran\" is not verification; \"it ran and its outputs reconcile\" is.\n5. Judge one-off versus systemic per incident: repeat offenders, shared root causes across jobs, and capacity-driven failures get a problem record or carry-forward action; anything suggesting a control gap — an unauthorized change, a monitoring blind spot — goes to the SOX program owner now, not at certification.\n6. Compile the incident resolution log: incident, severity, root cause, corrective action with actor and timestamp, re-run evidence, approver.\n\n**Record in AssureSwarm**\n- Create one Issue item per escalated failure (`issue_type: exception`, `severity`, `source: management_identified`, `root_cause`, `remediation_plan`, `issue_owner`, `target_remediation_date`), linked to the triggering job, run-log evidence, and the exception register, and related to Control UC-ACCESS-17 (item create + item relationship).\n- Attach the incident resolution log and re-run evidence (step document).\n- Record each resolution's individual approval by the on-call lead or operations manager on this step; raise each systemic flag as its own Issue linked to the SOX program owner.\n\n**Exit criteria** — Every escalated failure has an incident record with root cause and corrective action; every applied fix verified by a clean re-run; each resolution individually approved; any incident not fully resolvable this cycle carries a named owner, target date, and the operations manager's explicit acceptance; systemic risks escalated before the cycle proceeds.","label":"Manage batch-processing incident","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"manage-batch-processing-incident"},{"data":{"decisionField":"alert_disposition","description":"Agent evaluates performance, capacity, and security telemetry against thresholds and projects capacity-tuning needs; human analyst triages alerts and approves tuning actions","formData":{"fields":[{"key":"alert_disposition","label":"Monitoring alert disposition","options":[{"label":"Routine monitoring","value":"routine_monitoring"},{"label":"Incident identified","value":"incident_identified"}],"required":true,"type":"select"}],"resultType":"form","submittedAt":null,"values":{}},"instructions":"**Objective** — Confirm log and telemetry coverage is intact, triage every performance, capacity, and security threshold breach, tune capacity ahead of projected demand, and decide whether anything crossed from routine operations into a formal incident. The monitoring analyst owns the call. (UC-ACCESS-18)\n\n**Decision criteria**\n\nThree evidence sets exist before branching. First, log-pipeline health: every in-scope source emitting within its expected interval, records tamper-evident and access-restricted, retention covering the continuous-monitoring window (NIST CSF 2.0 DE.CM expects monitoring to be continuous — a silent log source is itself a finding, because the absence of alerts is only good news while the pipeline is alive). Second, the breach register: every threshold breach with metric, threshold, observed value, duration, and proposed severity. Third, the capacity projection: utilization trend per resource — compute, storage, queue depth — against current headroom, with a proposed tuning action (scaling, quota change, schedule shift) for anything projected to breach within the planning horizon; sustained utilization above roughly 80% or projected exhaustion inside the horizon are the usual triggers. Every tuning action that modifies production carries a change reference and the analyst's approval.\n\n- **Routine monitoring (`routine_monitoring`)** — every breach is explained and within operating tolerance: transient spikes that self-cleared inside the alert-hold window; breaches with a known benign cause (month-end batch load, a scheduled data conversion) handled by standing procedure; capacity drift covered by an approved tuning action. No security-relevant signal — authentication anomaly, unexpected privileged activity, integrity alert on the log stores — remains unexplained, and any log-coverage gap was restored within the cycle with the blind window reviewed.\n- **Incident identified (`incident_identified`)** — any alert meets incident criteria: a security signal that cannot be shown benign (suspected unauthorized access, indication of log tampering, malware or endpoint detection); an availability breach past tolerance on a financially significant system, such as sustained outage or degradation beyond its service objective; a capacity exhaustion already impacting processing; or a log source dark long enough that the blind window itself requires investigation. When a security signal is ambiguous, take this branch — a false positive costs an investigation; a missed true positive costs the period.\n\nThe incident branch routes to formal monitoring-incident management; the routine branch proceeds to input-control verification.\n\n**Record in AssureSwarm**\n- Submit the decision form on this step: `alert_disposition` (the branch), the step result — naming each incident-branch alert, or summarizing the tolerance evidence for routine — and the step's approver record (step form).\n- Build or refresh the monitoring dashboard: coverage status, breaches by severity, and the capacity projection in one view (dashboard); attach the breach register and projection detail (step document).\n- Record approved tuning actions with owners and change references on this step — capacity tuning has no native item home, so it lives as a step record.\n\n**Exit criteria** — Form submitted; every alert dispositioned with severity confirmed or adjusted by the analyst; log coverage verified intact or gaps dispositioned; tuning actions approved with owners and change references; incident-branch alerts individually named in the rationale.","kind":"decision","label":"Monitor events, triage, and tune capacity","performedBy":{"primitives":["coach-query-data","coach-dashboard-create","coach-document-upload"]}},"id":"monitor-events-triage-and-tune-capacity"},{"data":{"description":"Agent opens a tracked incident for each identified alert and tracks remediation to a verified re-check; human responder approves each resolution","instructions":"**Objective** — Contain, remediate, and verify every alert identified as a security or availability incident through a formal record — remediated incidents demonstrably back within threshold, anything still open contained, scoped, and owned — and never release the cycle while an incident's scope is unknown. (UC-ACCESS-18)\n\n**Inputs**\n- The incident-branch alert list from the monitoring decision, with linked log and telemetry evidence.\n- The incident response procedure — a Policy item (policy_type: procedure, framework containing iso-27001): severity scale, containment playbooks, and the notification matrix — security program owner for security incidents, SOX program owner where a financially significant system is touched.\n- Threshold definitions for the affected metrics, to define \"back within threshold\" (attached as a document on the monitoring step).\n- Access to the protected log stores covering the investigation window.\n\n**Procedure**\n1. Open an incident record per identified alert and link the triggering telemetry or log evidence. Set severity from confirmed impact and blast radius, not the alert's default rating — an authentication anomaly on identity infrastructure outranks a CPU breach on a reporting server.\n2. For security incidents, sequence deliberately: contain first (isolate the host, disable the credential, block the indicator); preserve evidence second — export the relevant log slices into the incident record before remediation so the forensic trail survives log rotation; then remediate. Record actor and timestamp for every action.\n3. For availability and capacity incidents: restore service (fail over, scale, restart) and record what processing was impacted during the outage window. Missed batch runs and interface transfers during the outage feed back into this cycle's processing-integrity checks — they do not silently disappear into \"service restored\".\n4. Re-check after remediation over a sustained observation window, not a single sample: the affected metric back within threshold, the log source flowing, no recurrence of the triggering signal. For security incidents, verify the attack path is actually closed — credential rotated, vulnerability patched, rule deployed — not merely that alerting went quiet.\n5. Judge scope honestly: indicators of wider exposure — multiple hosts, credential reuse, signs of data egress — escalate to the security program owner immediately; impact to financially significant processing is flagged to the SOX program owner for deficiency evaluation. An incident whose scope is unknown holds the cycle; an incident whose remediation extends beyond the cycle may release it only once contained and scoped, carried as an owned open item.\n6. Compile the incident resolution log: trigger, severity, containment and remediation actions with actors and timestamps, re-check evidence, approver, onward escalations.\n\n**Record in AssureSwarm**\n- Create one Issue item per identified alert (`issue_type: exception`, `severity`, `source: management_identified`, `root_cause`, `remediation_plan`, `issue_owner`), linked to the triggering telemetry and log evidence and related to Control UC-ACCESS-18 (item create + item relationship).\n- Attach the incident resolution log and the preserved evidence exports (step document).\n- Record each resolution's individual approval by the responder or operations manager on this step; raise each onward escalation as its own Issue linked to the security or SOX program owner.\n\n**Exit criteria** — Every identified alert has a formally tracked incident; contained-and-remediated incidents show re-check evidence within threshold over a sustained window; any incident still open is contained, scoped, owned, and escalated to the right program owner; each resolution individually approved.","label":"Manage monitoring incident","performedBy":{"primitives":["coach-item-create","coach-items-link","coach-workflow-scan","coach-query-data","coach-document-upload"]}},"id":"manage-monitoring-incident"},{"data":{"description":"Reconcile every in-scope interface, confirm the cycle's processing posted complete and in the proper period, and release only outputs that are provably accurate and routed exclusively to authorized recipients; the human moment is the operator's release decision — anything failing a totals, cutoff, or recipient check is held. (UC-ACCESS-20)","instructions":"**Objective**\nReconcile every in-scope interface, confirm the cycle's processing posted complete and in the proper period, and release only outputs that are provably accurate and routed exclusively to authorized recipients; the human moment is the operator's release decision — anything failing a totals, cutoff, or recipient check is held. (UC-ACCESS-20)\n\n**Inputs**\nEdit-check and validation results per in-scope system: pass and fail counts by check type, with the trailing baseline for comparison.\n- Batch control totals: per-batch record counts and value totals at submission versus posting.\n- Every exception queue's contents: item, failure type, entry date, value where applicable.\n- The clearance-age threshold from the operations run book (same-day for financial feeds and, commonly, two to three business days otherwise) and the authorization matrix for input sources and channels.\n\nThe interface inventory: sending and receiving systems, documented reconciliation method, delivery window per interface. AssureSwarm has no native Interface/Asset type, so this reference register is attached as a document on this step — the honest fallback.\n- Transfer logs and control records from both ends of each interface for the cycle (external; extracts attached on the step), plus the interfaces' automated error-handling and alert logs.\n- The processing calendar: period boundaries and posting cutoff times.\n- The cycle's scheduled outputs — reports, extracts, files — with their specifications: key totals, format, parameters; and source-system data sufficient to recompute each output's key totals.\n- The distribution list per output and the authorized-recipient registry — no native Registry type, so the registry is attached as a document on this step (the honest fallback).\n- Recent leaver information and data-classification guidance for outputs carrying sensitive or financial data.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Verify input controls and clear exception queues”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Verify input controls and clear exception queues: Evidence that the cycle's inputs were validated for completeness, accuracy, and authorization — edit checks demonstrably operating, batch totals tying — and clear every exception queue down to items that each carry a named owner and target clearance date. (UC-ACCESS-20)\n\n2. Confirm the edit checks operated, not merely that nothing failed: a normal-volume day showing zero failures across all checks warrants suspicion that validation was bypassed or misconfigured, not celebration. Compare failure rates to the trailing baseline and investigate step-changes in either direction — a spike means a data problem upstream; a sudden silence means a control problem here.\n3. Tie batch totals per batch: submitted count and value versus accepted-plus-rejected count and value. Quantify every break in both records and value and trace it to the specific transactions. A break \"under investigation\" is an open item with an owner — never an explained one.\n4. Verify authorization of inputs: submissions arrived from expected sources, accounts, and channels only. Anything entering outside the authorized channel — a direct table update, an unapproved manual upload — is an authorization exception regardless of whether its content proves accurate, and routes to the operations manager because it may also be an access or change-control finding.\n5. Inventory every exception queue — failed edit checks, unauthorized submissions, batch-total breaks — with age measured from first entry, not last touch, and a proposed disposition by failure type: correct-and-resubmit, reject-to-source, or escalate.\n6. Disposition the queue: verify cleared items actually reprocessed successfully (a resubmission that failed again is still open); create an individual tracker item, with named owner and target clearance date, for every item breaching the clearance-age threshold. Aged exceptions buried in a queue count are how errors survive to period end.\n7. Draft the input-control and exception-queue status report: check results against baseline, batch tie-out results, the queue aging profile, dispositions.\n\n8. Assessment scope for Validate and release authorized outputs: Reconcile every in-scope interface, confirm the cycle's processing posted complete and in the proper period, and release only outputs that are provably accurate and routed exclusively to authorized recipients; the human moment is the operator's release decision — anything failing a totals, cutoff, or recipient check is held. (UC-ACCESS-20)\n\n9. Execute each interface's documented reconciliation between sender and receiver: record counts for completeness, control totals over the value fields for accuracy, hash or checksum where the method specifies. Reconcile at the level the method defines — a file-count match with a value mismatch is a break, not a pass.\n10. Quantify every break in records and value, and classify it: lost in transit, duplicated, rejected at the receiver, or transformed incorrectly. Trace each break to its specific records, and verify the correction by re-running the reconciliation — noting that a correction was made is not verification that it worked.\n11. Test the detective layer against your findings: for every break you found, did the interface's own alerting fire? A break the reconciliation caught that the automated alerting missed is a second, separate finding — the monitoring control failed — and gets its own remediation item rather than riding along with the data fix.\n12. Verify timeliness: every transfer inside its delivery window. A late file that arrives after dependent processing has already run creates a silent completeness gap — flag any late delivery whose downstream consumer executed without it, and confirm the consumer was re-run or corrected.\n13. Confirm period integrity: the cycle's processing ran to completion and postings carry dates inside the proper period. Work the cutoff edges — items processed near the boundary, stale items sitting in suspense or holding accounts, anything re-dated — and flag any item positioned to post to the wrong period. Near a period end, this check escalates from routine hygiene to the difference between a clean cutoff and a misstatement.\n14. Build the interface-and-period reconciliation dashboard — per-interface result, breaks with quantification, alert-verification results, cutoff status — and attach the detailed reconciliation output.\n15. Recompute each output's key totals against source — row counts and the primary value totals at minimum — and confirm parameters match specification: period, entity, filters. A report that is accurate for the wrong period is wrong. For outputs feeding financial reporting or external parties, tie the totals to the reconciled interface and processing results from items 9–14 so the whole chain agrees end to end.\n16. Verify format and completeness: expected sections and columns present, no truncation — compare file size and row count to the output's own trend — and rendering intact. Truncated extracts pass casual review while understating the population.\n17. Check every recipient on every list against the authorized-recipient registry. Flag: recipients absent from the registry; stale entries — cross-check recent leavers, because a terminated user still on a distribution list is an access finding, not a typo; personal or external addresses where the registry authorizes internal delivery only; and group aliases whose membership cannot be verified — an alias is only as authorized as its current membership.\n18. Apply hold-and-release discipline: any output with a totals mismatch, a specification deviation, an unresolved interface break or cutoff exception in its chain, or a flagged recipient is held in full — no partial release of a flagged output. Corrections are made and re-verified before release, and every recipient removal records who approved it.\n19. Release the passing outputs and log each release: output, validated totals and version, the recipient list as released, releaser, timestamp. This release log is the evidence that distribution matched the authorized registry at the moment of release.\n\n**Record in AssureSwarm**\nAttach the input-control and exception-queue status report, with generation metadata for the underlying extracts (step document).\n- Create one Issue item per aged exception (`issue_type: exception`, `source: management_identified`, `issue_owner`, `target_remediation_date` = target clearance date), related to Control UC-ACCESS-20 (item create + item relationship).\n- Record on this step: batches tied versus broken, exceptions cleared versus remaining, the oldest open item's age.\n\nBuild or refresh the interface-and-period reconciliation dashboard (dashboard).\n- Attach the reconciliation outputs with generation metadata, plus break and correction evidence (step document), and the output validation and distribution log; package each released output with its recipient-authorization check (item export).\n- Record on this step: breaks found, corrected, and open plus cutoff exceptions; outputs validated, held, and released; recipients flagged and corrected.\n- Create one Issue item per open break or detective-alerting failure and per stale or unauthorized recipient (`issue_type: exception`, `source: management_identified`, `issue_owner` — the registry owner for recipient findings — `target_remediation_date`), related to Control UC-ACCESS-20 (item create + item relationship).\n\n**Exit criteria**\nEdit-check operation evidenced against baseline; every batch-total break quantified and dispositioned; every item still queued carries a named owner and target clearance date, with age-threshold breaches existing as individual tracker items; the operator has confirmed the queue position. Every in-scope interface reconciled by its documented method, with every break quantified, traced, and either re-verified corrected or individually tracked with an owner; alerting verified fired per break or logged as a detective-control failure; deliveries checked against windows with impacted consumers re-run; period-cutoff exceptions resolved or owned; every scheduled output either released with validation evidence and an authorized-only recipient check on record, or held with a tracked correction; no release carrying an open totals mismatch or unresolved recipient flag; registry corrections routed with owners.\n\n> **⚡ Audit Artist accelerator:** `/sox-python` executes the record-count, control-total, and hash reconciliations and the output total recomputations as reproducible scripted checks with recorded parameters, so every tie-out can be reperformed exactly.","label":"Validate and release authorized outputs","performedBy":{"note":"","primitives":["coach-query-data","coach-export-package","coach-document-upload","coach-dashboard-create","sox-python","coach-item-create"]}},"id":"validate-and-release-authorized-outputs"},{"data":{"description":"Assemble a self-contained evidence package, indexed by unified control, proving the cycle's operations and processing-integrity controls operated, and secure the IT operations manager's certification with metrics and every open item disclosed — that certification is the cycle's closure, after which the package is archived under retention and the open items seed the next cycle. (UC-ACCESS-17, UC-ACCESS-18, UC-ACCESS-20)","instructions":"**Objective**\nAssemble a self-contained evidence package, indexed by unified control, proving the cycle's operations and processing-integrity controls operated, and secure the IT operations manager's certification with metrics and every open item disclosed — that certification is the cycle's closure, after which the package is archived under retention and the open items seed the next cycle. (UC-ACCESS-17, UC-ACCESS-18, UC-ACCESS-20)\n\n**Inputs**\nBackup job results for the cycle: status, duration, backup size, target per system.\n- The backup policy — a Policy item (policy_type: standard or procedure, framework containing iso-27001): schedule per system, retention duration, required protection attributes — immutability or WORM lock, restricted access, an isolated or off-site copy (the 3-2-1 pattern where adopted; ISO 27001 A.8.13 makes the protected-copy and test expectations explicit).\n- The restore-test calendar with each due system's defined RTO and RPO (attached as a document on this step).\n- Prior-cycle backup gaps carried forward as Issue items (issue_type: exception) linked to the anchor Process from the previous cycle's closure.\n\nEvery artifact this cycle produced: run-status dashboard and run log, exception register, both incident resolution logs, backup-and-recovery status report with restore-test evidence, breach register and capacity projection, input-control and exception-queue report, interface-and-period reconciliation output, output validation and distribution log.\n- The confirmed in-scope population for the cycle — the completeness yardstick the package is verified against — and prior-cycle metrics for trend comparison.\n- The records-retention schedule — SOX-relevant operations evidence is commonly retained seven years; ISO 27001 evidence per the ISMS schedule — and the designated evidence repository.\n- The operations calendar: the next daily bridge and weekly review dates.\n\n**Procedure**\n*Agent retrieval, preparation and filing absorb “Verify backups and recovery testing”; the responsible roles retain their judgments and all independent sign-offs within this checkpoint.*\n\n1. Assessment scope for Verify backups and recovery testing: Verify every backup due this cycle completed with a protected, retained copy — gaps logged and owned — and execute any restore test due, measured against the system's defined recovery objectives with a real integrity check. (UC-ACCESS-17)\n\n2. Reconcile backup results to the policy schedule per system, checking completion, duration, and size against trend. A \"successful\" job whose backup size dropped materially against its own trend — 20% or more without a known data change is a reasonable trigger — is suspect, not clean: partial backups pass job-status checks and fail restores.\n3. Verify protection on the retained copy itself, not just the job result: immutability or WORM where required, access restricted to the backup service identities, and the isolated or off-site copy present with retention meeting policy. A backup that an administrator — or ransomware holding an administrator's credential — can delete does not satisfy the control.\n4. Classify gaps precisely: missed (never ran), partial (ran incomplete), unprotected (ran without required protection attributes), out-of-retention (copy expiring before policy). Each gets an owner and a fix-by date. Re-running the backup today closes the exposure, not the record — the miss stays logged.\n5. For each restore test due: stage the target environment and designated data set, execute the restore, and measure elapsed restore time against RTO and the restored copy's data currency against RPO. Verify integrity with a real check — record counts or checksums against source, or an application-level open of the restored data — never a directory listing. Record measured-versus-objective explicitly: a restore that completes in six hours against a four-hour RTO is a failed test that happened to work.\n6. A failed or missed restore test raises a tracked remediation item; where the system is financially significant, flag it to the SOX program owner — recoverability never demonstrated within objective is a deficiency in waiting.\n7. Draft the backup-and-recovery status report: per-system completion, protection verification, gaps with owners, restore-test measurements against objectives.\n\n8. Assessment scope for Certify and file evidence: Assemble a self-contained evidence package, indexed by unified control, proving the cycle's operations and processing-integrity controls operated, and secure the IT operations manager's certification with metrics and every open item disclosed — that certification is the cycle's closure, after which the package is archived under retention and the open items seed the next cycle. (UC-ACCESS-17, UC-ACCESS-18, UC-ACCESS-20)\n\n9. Index every artifact to its unified control by linking each document to the control's tracker item: UC-ACCESS-17 (batch execution, processing incidents, backup and recovery), UC-ACCESS-18 (monitoring, capacity, monitoring incidents), UC-ACCESS-20 (inputs, interfaces, outputs). An artifact supporting no control is either mis-scoped or padding; a control with no artifact is a gap to close before certification, not after.\n10. Verify completeness against the confirmed in-scope population, not memory: every in-scope job, interface, monitored threshold, due backup and restore test, and output shows a result, a named reviewer, and linked evidence. Verify evidence quality in the same pass: system-generated extracts carry their generation metadata — source, query, run time, row count — the completeness-and-accuracy attributes a SOX tester will demand of system-generated evidence.\n11. Compute the cycle metrics: jobs on time versus escalated, failures cleared in shift, incidents opened and closed, backups completed-and-protected, restore tests passed against objective, alerts by disposition, exception-queue aging, interface breaks found and corrected, outputs released clean. Compare to the prior cycle and explain material movement — a metric that improved because scope shrank is not an improvement.\n12. Draft the certification statement: period and shift covered, scope, metrics with trend, and every open item disclosed with owner and due date. Disclosure beats silence — an open item disclosed at certification is a control operating as designed; the same item surfaced later by a tester is a finding. Confirm the cycle is actually closable before routing it: every open item disclosed with owner and due date, no incident with unknown scope. A cycle holding an unscoped security incident does not close — it stays open until scope is established.\n13. Route the statement and package to the IT operations manager for review and signature as this step's approval. Gaps found in review are resolved or explicitly disclosed before signing — the certification asserts that the controls operated and that exceptions are stated, not that the cycle was perfect. That signature closes the cycle; the remaining items file it.\n14. Export the workflow record and archive it with the certified package in the designated evidence repository under retention and immutability controls, recording the archive location and reference identifier against each control id. Verify retrievability by opening the archived copy — never by trusting the upload confirmation. Any post-archive correction is a new, dated addendum, never an edit to the archived package.\n15. Update the control execution log for UC-ACCESS-17, UC-ACCESS-18, and UC-ACCESS-20 with the cycle period, result, completion date, and key metrics. This log is the population internal audit, SOX testers, and external audit sample from to establish the controls operated on cadence — a cycle missing from it is, for testing purposes, a cycle that never ran.\n16. Create carry-forward items, each with named owner and due date, for everything still open: unresolved incidents, exception-queue items past threshold, missed or unprotected backups and failed restore tests, open tuning actions, recipient-registry corrections. These arrive as explicit inputs to the next cycle.\n17. Issue the closure notice to the IT operations manager and the SOX program owner, and confirm the next cycle sits on the calendar at the daily-bridge and weekly-review cadence.\n\n**Record in AssureSwarm**\nAttach the backup-and-recovery status report and restore-test evidence — timings, integrity checks (step document).\n- Create one Issue item per gap and per failed restore test (`issue_type: exception`, `source: management_identified`, `issue_owner`, `target_remediation_date`), related to Control UC-ACCESS-17 (item create + item relationship).\n- Record on this step: backups due, completed, and protected; restore tests due, executed, and passed against RTO and RPO.\n\nLink every artifact to its Control item, indexed by unified-control id — UC-ACCESS-17/18/20 (document link / item relationship).\n- Attach the assembled evidence package, the signed certification statement, and the closure record with the archive location and reference identifier (step document); archive the workflow instance against the anchor Process item as the cycle's audit-trail record (workflow instance).\n- Record the cycle metrics, the disclosed open items, and the control-execution-log update on this step — Control has no native execution-log field, so per-cycle results are recorded here and via document links to Control items UC-ACCESS-17/18/20 — plus the next cycle's scheduled dates.\n- Create carry-forward Issue items (`issue_type: exception`, `source: management_identified`, `issue_owner`, `target_remediation_date`), one per open thread, linked to the anchor Process so the next instance picks them up as existing items.\n- Capture the manager's sign-off as the step approval; it is the closure declaration, so no separate confirmation is recorded.\n\n**Exit criteria**\nEvery due backup dispositioned complete-and-protected or logged as an owned gap; every due restore test executed with measured recovery time and point against objectives and a real integrity check; the operations manager has validated results and confirmed ownership of every gap. Every scope line shows a result, reviewer, and linked evidence; the package is indexed by control id with no unmatched artifacts or uncovered controls; metrics computed with prior-cycle comparison; certification signed with every open item disclosed; the archived package verified retrievable under retention and immutability controls with references recorded per control id; execution log updated for all three controls; every open thread exists as a carry-forward item with owner and due date; the next cycle is scheduled.\n\n> **⚡ Audit Artist accelerator:** `/coach-render-package` assembles the control-indexed artifacts into the reviewer-ready evidence package with a coverage index.","label":"Certify and file evidence","performedBy":{"note":"","primitives":["coach-document-upload","coach-query-data","coach-render-package","coach-workflow-export","coach-item-create"]}},"id":"certify-and-file-evidence"}],"sourceTemplateId":"workflow-library:sox-production-operations-processing-integrity-cycle"}