Batch job scheduling and monitoring: SOX ITGC evidence

What SOX auditors expect from batch job scheduling and monitoring

A SOX auditor asks one question about a scheduled job or interface that feeds financial figures: can management show that it ran completely, accurately and only once, on the right data, and that anyone who changed its schedule or logic was authorized to do so? Where the job feeds a balance such as accruals, revenue postings or intercompany settlements, the control has to prove that failures are seen and fixed before the numbers reach the ledger. SEC guidance in Release 33-8810 leaves the specific IT general controls to each company's facts and circumstances, so there is no published checklist for this area. Within the four areas SEC guidance names, job scheduling sits under computer operations. PCAOB AS 2201 treats effective computer operations controls as a condition for an auditor to rely on automated application controls, so a weak scheduler can undermine controls that look sound on paper.

The risk is concrete. A job that fails silently leaves a balance unposted or half-posted. A job that runs twice duplicates entries. A job that runs against stale input files produces figures that look plausible but belong to the wrong period. A schedule or script edited directly in production without approval means the reported output no longer matches what was tested. PCAOB AS 2110 lists reliance on systems that process data inaccurately and inappropriate manual intervention as IT risks to internal control over financial reporting, and both appear in ordinary batch operations. Management should be able to name each financially significant job, its owner, its trigger, its input and output, and the alert that fires when it fails. Confirm with your auditor which jobs they consider in scope before you build that list.

What usually makes this hard is visibility. Overnight jobs often exist only in a scheduler's configuration or in one administrator's memory, and nobody has documented their dependencies. Interfaces that move sales, payroll or treasury data are frequently owned by business teams who change file layouts or timing without telling IT. Schedules are sometimes adjusted directly on the production server to fix an urgent problem, and that change never enters the change process. Start by inventorying every job and interface that touches a financial report, then compare that inventory against what the scheduler actually runs. The gap between the two is usually where the audit finding will come from.

Which jobs, interfaces and teams fall inside SOX scope

Scope for batch jobs follows the financial reporting risk each job carries, not the total number of jobs in the environment. Management only needs to evaluate the controls necessary for other financial reporting controls to operate properly, so the in-scope list should come from the ITGC scoping work and be agreed with the external auditor.

Jobs that produce ledger data

Start with jobs that create, post, transform or summarize ledger, subledger and reporting data, such as period-end accruals, currency revaluation, allocation runs and consolidation extracts. A failed or altered run here can misstate balances without anyone noticing. For each job, confirm which financial statement account or disclosure it feeds, and whether an automated or IT-dependent control downstream relies on its output being complete and accurate.

Interfaces that carry balances

Interfaces move balances between systems, for example from a billing platform into the general ledger or from a payroll system into a consolidation tool. Include the transfer job, the file or message queue, and the reconciliation or control total that proves the receiving system got what the sending system sent. Dropped records, duplicate loads and silent truncation are the failure modes auditors look for in this area.

Jobs on cloud or managed schedulers

Jobs that run on a cloud scheduler, a SaaS platform or a managed provider's job service still belong in scope when they touch financial data. Confirm which parts of the schedule, alerting and job history the provider controls, which ones your team configures, and what the provider's SOC 1 report covers. Document the boundary between provider and company controls before the audit period starts.

Spreadsheet and business-owned jobs

Macros, scheduled spreadsheet refreshes and reports built by finance or operations staff outside IT can feed financial statements without any IT change record. Inventory them through interviews with finance leads and by reviewing scheduled tasks and shared drives. Decide whether each one is an end-user computing control in scope or a manual process, and document who maintains the logic and who can edit the schedule.

Jobs that only affect efficiency

Jobs that only speed up operations, such as log archiving, dashboard refreshes that no one uses for financial decisions or capacity housekeeping, usually fall outside the financial reporting risk. Excluding them is a judgment that should be written down with the reason, reviewed by the auditor during scoping and revisited when a job's purpose changes. Confirm that no downstream report or control depends on the output before excluding it.

People who can change schedules

Map every account that can create, edit, pause or re-run a schedule, including named administrators, service accounts, batch operators and vendor support engineers with emergency access. Each of these can change what processes financial data, so each belongs in the access review. Ask for the list of privileged scheduler roles and confirm who approves a change to a production schedule.

How an assessor tests batch job controls

This table lists each test element an assessor applies to batch job controls, the approach used, the evidence requested and the findings that appear most often. Read it as a checklist for preparing evidence before fieldwork, since each row shows what the assessor will ask to see. The main takeaway is that schedule changes and failure resolution are tested on populations and samples, so the records must exist for the full period under review.

Test element	Test approach	Evidence requested	Common findings
Walkthrough of the job lifecycle	Trace one financially significant job from creation through scheduling, execution, completion and output delivery, asking the owner to explain each step.	Job inventory, schedule definitions, run logs for a selected job and the owner's process narrative.	Jobs that run outside the documented inventory, or owners who cannot describe how failures reach them.
Design of schedule change authorization	Assess whether the approval step for creating or altering schedules is defined, assigned to appropriate people and enforced by system access.	Schedule change policy, approver matrix, access listing for people who can edit schedules and sample approvals showing who signed off.	Approver roles that overlap with the people who edit schedules, or no defined approver for emergency changes.
Design of failure alerting and resolution	Confirm that job failures generate an alert or report, that each alert routes to a named owner and that the expected response is defined.	Alert configuration, routing or escalation rules, on-call or ownership list and the documented response procedure.	Failure alerts with no owner, alerts sent to a shared mailbox nobody monitors, or thresholds that suppress failures.
Operating effectiveness of schedule changes	Request the full population of schedule changes in the period, then select a sample and inspect each for approval, testing and timing relative to the change.	Population report of schedule changes from the scheduler or change tool, with approval records and the sample selected by the assessor.	Changes made without approval, changes approved after the fact or changes that cannot be matched to a ticket.
Operating effectiveness of job completion monitoring	Obtain a population of failed runs and select a sample. Observe the monitoring dashboard, inspect the resolution ticket and re-perform the check that the job completed.	Failed run population, resolution tickets for the sampled failures, rerun logs and evidence of completion checks such as record counts or control totals.	Failed runs with no resolution ticket, reruns not documented, or failures closed without evidence the job completed.
Interface reconciliation	Select interfaces that move financial data between systems and reconcile record counts or control totals at source and destination for sampled periods.	Interface inventory, reconciliation reports for sampled days, exception logs and sign-off by the reviewer.	Reconciliations not performed for some periods, unexplained differences that are not escalated or reviewers who sign without evidence of review.

Implementing batch job control in six steps

This sequence turns scheduled jobs and interfaces that move financial data into a controlled, monitored process with defined owners, restricted schedule changes, reconciliation checks, documented failure handling and a retained test that shows the whole control working end to end. Each step produces an artifact an auditor can inspect.

Inventory in-scope jobs and interfaces
Start by listing every scheduled job, batch file transfer and interface that creates, moves or transforms data feeding financial reporting. For each one, record the job name, the system it runs on, the source and target, the business owner, the technical owner, and the run frequency. Confirm the list with finance and the application owners, since they know which outputs feed the ledger and close. The output is a job inventory that is versioned and approved by its owners, and it becomes the population every later step refers back to.
Restrict schedule creation and edit rights
Pull the access list for the scheduler and for the job definitions, including the accounts that can create, modify, pause, reorder or delete jobs. Remove standing rights from production developers, and grant schedule changes only to a defined operations group through the change process. Separate these rights from development access so that no one can both write code and alter the schedule that runs it in production. The output is a reviewed access list with named approvers and evidence of the removals, which feeds the access and program change areas of your ITGCs.
Define completion and reconciliation checks
For each job in the inventory, write down what a correct run looks like. Typical checks include expected start and completion windows, record counts against source totals, control totals on amounts, rejected-record thresholds, and confirmation that the target received the file. Assign each check to a named person or to an automated comparison, and state what happens when a check does not match. Where a check depends on a manual reconciliation, document the preparer, reviewer and retention location. The output is a check definition for every job, which is the point where a failure becomes something you can detect.
Configure monitoring and alerting
Set up monitoring that reports job status, duration, missed runs and check results, and send alerts to named recipients with an on-call or support route for after-hours failures. Open-source options such as Grafana Alerting, which can build alert rules from queries across multiple data sources, or Prometheus, which collects metrics from instrumented jobs, can carry these signals, but confirm with your own scheduler and interface tools that the metrics you need are exposed. Keep a record of the alert rules, thresholds and recipient lists, and test that an alert actually reaches a person. The output is an alert configuration with a change history.
Document the failure procedure
Write the procedure that governs what happens when a job fails or a check does not reconcile. It should cover how the failure is logged, who is notified and by when, how it is escalated, how the root cause is recorded, how the job is fixed and rerun, and how the rerun is reconciled to the original expected output. Route fixes that change code or configuration through the change process, and link the incident or problem record to the change. A ticketing tool such as GLPI, whose Assistance module supports tickets, problems and changes following ITIL practices, can hold these records, but confirm it fits your approval workflow. The output is an approved procedure and a ticket trail for each failure.
Run a retained failure test cycle
Choose one in-scope job and induce a controlled failure in a non-production environment, such as a missing input file or a control total mismatch. Confirm that monitoring raises the alert, that the right person receives it, that the ticket is logged and escalated according to the procedure, that the fix goes through the approved change path, and that the rerun reconciles to the expected totals. Keep the test plan, screenshots or log extracts, the ticket, the change approval and the reconciliation results together. Auditors test operating effectiveness by inquiry, observation, inspection of documentation and re-performance, so this record is the evidence that the control works end to end. Ask your external auditor which sample and retention they expect before you run it.

Evidence that passes a batch job control test

An auditor testing scheduled jobs will want proof that the right jobs run on the right schedule, that only authorized people change them, and that every failure is caught and resolved. The cards below cover the artifacts that show each of those points and how to keep them current between audits.

Approved job inventory with owners

A complete, dated list of every scheduled job and interface that feeds financially significant processing, with the business owner, technical owner, run frequency and the upstream and downstream systems for each. The inventory is the starting point for the test, because an auditor cannot confirm that a job runs if the population is incomplete. Check that the list was approved by the control owner, that it matches the scheduler's own job table, and that it is reviewed when jobs are added or retired. Confirm the inventory can be exported with a timestamp.

Schedule change records

Each change to a job's timing, parameters, dependencies or enabled status should trace to an approved change ticket that names the requester, the approver and the reason. Auditors typically select a sample of changes and compare the scheduler's history with the ticket, so mismatched dates or missing approvals are common findings. Make sure emergency schedule changes are logged the same way and reviewed after the fact. Link these records to the program change process rather than keeping them in a separate log.

Scheduler administrator access review

The list of people who can create, edit, pause or run jobs is evidence of access restriction, and it should be reviewed on a defined schedule by someone other than the administrators. Compare the list with HR records for leavers and transfers, and check that service accounts used by the scheduler are documented with their owners. Confirm that the review produced a signed record and that any removals were carried out. Ask whether the scheduler logs administrator actions and whether those logs are retained.

Run logs showing completion

Sample run logs demonstrate that scheduled jobs actually completed, including start and end times, return codes and record counts where the job moves financial data. For a sample of dates, the auditor will compare the log entry with the expected run and check that totals or control counts reconcile. Confirm that logs cover the full audit period and that they cannot be edited by the people who run the jobs. Missing days and jobs that completed with warnings need a documented explanation.

Alert records and acknowledgement

Monitoring tools should raise alerts when a job fails, runs late or does not start, and each alert should show who acknowledged it and when. Auditors look for evidence that alerts reach a person who responds, not just that an alert rule exists. Test the alert path during the period, for example by reviewing alerts from a sample of failures and their acknowledgement times. Confirm the alert rules themselves are under change control and that the alerting tool's notification history is retained.

Failure tickets and rerun records

Every failed or late job should have a ticket that records the cause, the impact on financial data, the fix and the confirmed rerun. This is where the control closes, because an auditor will select failures from the logs and follow each one to resolution. Check that reruns were verified against expected results, that any manual intervention was approved, and that recurring failures were escalated to problem management. A failure with no ticket is a gap the auditor will report.

Who owns the job schedule, who builds the monitor and who tests it

Management owns the controls. Your team decides which jobs and interfaces move financial data, keeps the inventory current, and approves every change to a schedule. The partner can configure tools, but the business and IT owners remain accountable for what runs and for proof that failures were handled. Auditors will ask who approved each schedule change and who closed each failure, so those names must be recorded in your own systems.

Job inventory: Maintain a list of every scheduled job and interface that feeds a financially significant report or ledger, with its owner, frequency, dependencies and upstream and downstream systems.
Schedule change approval: Require documented approval before any job is added, removed, retimed or edited, and separate the requester from the approver.
Failure triage: Assign a named owner to each alert, define response times in your own procedures, and record the root cause and fix.
Periodic review: Confirm on a set cadence that the inventory matches what the scheduler actually runs.
Exception handling: Document any manual rerun or intervention, who performed it and why it was needed.

Check that your procedures name owners, not teams, and that every failure leaves a trail a third party can follow.

Which open-source tools can produce batch job evidence

Four open-source tools can generate records that help show batch jobs ran, failed visibly and were fixed under control. Each one covers a different piece of the evidence trail, from alerting and metrics to ticketing and requester intake. None of them replaces the scheduler's own change and access controls, which the organization must test separately.

Grafana Alerting for job failures

Grafana Alerting builds alert rules from queries and expressions across several data sources and alerts on metrics and logs together. For batch jobs, this lets a team define a rule that fires when a nightly interface run stops reporting success or produces an unexpected record count, and keeps the rule history for review. Check that rule definitions are themselves change-controlled, and confirm the license implications of AGPL-3.0-only with counsel before distributing modified versions.

Prometheus for job metrics

Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series on local storage, queryable with PromQL. A job that exposes a last-success timestamp or a duration metric gives auditors a time-stamped record of run behavior that does not depend on the job writing its own log. Gaps remain: Prometheus only sees what jobs expose, so the team must confirm each financial job is instrumented, and it does not show who changed a schedule.

GLPI Assistance for problems and changes

The GLPI Assistance module lets users create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For batch failures, it can hold the ticket that records the failure, the problem record for root cause, and the change record that approves the schedule fix. Confirm that the tool enforces approval steps and that its audit trail is retained for the period auditors sample, since a ticket alone does not prove testing or approval happened.

Zammad for requests and escalations

Zammad is a web-based helpdesk that brings requests from email, chat, telephone and social media into one ticket system. When a business user reports a missing feed or a wrong balance, Zammad can hold that first report and its handoff to operations, giving a dated start point for the incident. It does not manage scheduler permissions or job logic, and teams should confirm how it retains ticket history and who can close or edit tickets once a finance escalation is open.

What meeting batch job controls costs in money and effort

This table breaks down the cost components of running batch job scheduling and monitoring controls, who is paid for each, and what drives it up or down. No dollar figures or durations are supplied for this topic, so use the table to shape a quote request rather than to estimate a budget. The main takeaway is that the number of in-scope jobs and interfaces drives most of the effort.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring (subscriptions or support)	Scheduler license terms, number of monitored systems, and whether monitoring and ticketing are self-hosted	Use self-hosted open-source monitoring and ticketing where it fits; confirm whether the scheduler itself carries a license and its renewal terms
Engineering time for monitors and alert routing	One-time build, then recurring tuning	Number of in-scope jobs and interfaces, and how many failure states each needs to detect	Group jobs by business process and standardize alert templates across similar jobs
Job inventory and check design	One-time, updated as jobs change	Count of jobs, interfaces and owners, and how well the scheduler's documentation matches reality	Start from an inventory tied to financial reporting risks so only relevant jobs carry controls
Evidence upkeep	Recurring, usually per reporting period	Volume of alerts and failures, frequency of schedule changes, and how much evidence must be retained	Automate evidence export from monitoring and ticketing tools and set a fixed review cadence
External testing or review	Recurring, per assessment cycle	Scope of the review, number of interfaces covered, and whether tests are performed by an outside firm	Ask for a fixed-scope review limited to a named job list and agreed deliverables
Auditor sampling	Recurring, set by the external auditor	Control frequency, number of jobs in scope, and the auditor's sample sizes and testing approach	Document each control clearly so testing needs fewer follow-up requests; confirm sampling approach early with the auditor
Schedule change volume	Recurring	Frequency of schedule edits and the approvals each one requires	Route schedule changes through the same approved change process used for code changes

Gaps that cause batch job control findings and how to close them

Batch job findings rarely come from one dramatic failure. They come from gaps in how jobs are inventoried, changed, monitored and rerun, and auditors find them by comparing what the scheduler does with what the change and incident records say. The cards below cover six gaps that show up repeatedly and the fix for each.

Jobs running outside the inventory

A job that runs on a schedule but is missing from the approved job inventory cannot be tested as a control, because no one has documented its purpose, inputs or owner. Compare the scheduler's full job list against the inventory at least once per period and investigate any job that appears only on the scheduler, including jobs created by individuals for ad hoc reporting. Each job that feeds financial reporting should map to a named owner and a documented business purpose.

Schedule changes made directly in production

When an administrator edits a job's frequency, dependencies or parameters directly in the production scheduler, the change bypasses the change management process that auditors test under program changes. Restrict schedule edits to the change pipeline or to a break-glass procedure with after-the-fact review. Check that every production schedule change in the period traces to an approved change record.

Failure alerts sent to a shared mailbox

Alerts routed to a distribution list that nobody watches create the appearance of monitoring without a responsible person acting on failures. Route each failure alert for a financially significant job to a named on-call role, and record who acknowledged it and when. Auditors will ask for evidence that a specific person resolved specific failures, so the alert record should show that chain.

Reruns without a link to the original failure

A job rerun that is not tied to the failure that caused it leaves a gap between the error and the corrected output. Require that every rerun reference the original failure ticket, the reason for the rerun and the person who authorized it. Confirm that reruns do not duplicate or skip records, since a rerun that posts transactions twice is a completeness and accuracy issue.

Interfaces without reconciliation

An interface that moves financial data between systems without a control total can drop or duplicate records with no one noticing. Reconcile record counts and monetary totals sent by the source system to those received by the target system, using a control figure that both sides agree on. Document the reconciliation, the threshold for investigating a difference, and the reviewer who signs off on exceptions.

Service accounts that can edit schedules

Shared or service accounts that can modify job definitions let changes occur without an identifiable person behind them. Limit scheduler administration to named individuals with separate duties, and confirm that service accounts used to run jobs have execute rights only. Review the list of accounts with schedule edit permission on a recurring basis and remove any that no current role requires.

Questions buyers ask about batch job controls and SOX

Can we run SOX batch job controls in-house without outside help?

Yes, many companies do, provided the people who own the schedules, approve changes and administer the scheduler can explain and evidence their work. Management owns the controls, so the question is whether your team can design the control activities, keep the evidence and test them on a regular basis. Where the internal team lacks SOX experience or capacity, an implementation partner can prepare the scheduler configuration, job inventories and monitoring evidence, while management still performs and documents the reviews. Ask any outside party to state in writing which tasks it performs and which remain with your staff.

How long does batch job control work take and what drives the timing?

No fixed duration applies to every company, so treat any single number as a claim to verify. The main drivers are the number of jobs and interfaces that touch financially significant data, how mature the scheduler is (for example, whether schedules, dependencies and restart rules are already documented and version controlled), and how many systems feed the general ledger. Organizations with a documented job inventory and centralized scheduling usually need less preparation than those running scripts on individual servers. Ask for a quote built from a written scope listing the job count, schedulers in use and the reporting periods the auditor will test.

What do our staff need to commit to for batch job controls?

Three groups of people carry most of the work. Job owners are accountable for each financially relevant job, its input data and its expected outputs, and they review exceptions. Change approvers authorize changes to schedules, dependencies and job parameters before they reach production. Scheduler administrators control privileged access, maintain the configuration and keep the logs that show who changed what. Each role needs named individuals, a backup for absences and time for recurring reviews. Your quote should identify which of these roles the implementation partner will support and which must come from your own staff.

Can an external consultant design batch job controls while the auditor tests them?

Yes, this is a common split. A consultant can help define the control objectives, document the job inventory, configure alerting and draft the procedures, and an external auditor then tests whether those controls operate effectively during the period. Management remains responsible for the design it adopts and for running the controls day to day. The consultant should not be the person who performs the control reviews the auditor relies on, because that blurs independence. Confirm in the engagement terms who signs off the design and who keeps the evidence.

What is the external auditor not allowed to do for our batch controls?

Under the PCAOB framework, the external auditor tests management's controls and forms an independent opinion. The auditor should not design, operate or take over the controls it is testing, since that would impair its independence. Auditors do test operating effectiveness by combining inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. Management must therefore keep the records themselves, because an auditor cannot create the evidence after the fact. Confirm with your audit firm which requests fall within its independence rules before you agree to any design work.

Does self-hosted open-source monitoring remove the need for an audit-ready scheduler?

No. Monitoring tools can show that a failure was detected and who was notified, but they do not make the scheduler itself controlled. A self-hosted stack such as Prometheus for metrics, Grafana Alerting for rules that span metrics and logs, and GLPI or Zammad for tickets can produce strong evidence of detection and resolution. The scheduler still needs restricted administrative access, documented change control and job definitions that the auditor can inspect. Confirm with your auditor how the monitoring evidence will be retained and whether the tools themselves fall within the scope of your ITGC testing.

How DeployOpen prepares batch job controls and evidence

DeployOpen plans, implements and documents self-hosted open-source monitoring and ticketing platforms inside your own infrastructure, so scheduled jobs and interfaces produce evidence auditors can test. We prepare systems and evidence only. Management owns the controls, and an independent auditor issues any opinion on them.

How we scope

Written scope lists which financial jobs, interfaces and schedulers are in SOX scope.
Scope names who may change schedules and which monitoring and ticketing tools are covered.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure job failure alerting from metrics and logs in a self-hosted Grafana instance.
We set up ticketing workflows so job failures are logged, assigned and resolved with a traceable record.
We test alert rules and escalation paths against simulated job failures before handover.

How we hand over

You receive configuration documentation, alert rule inventories and ticket workflow descriptions for your control owners.
Runbooks explain how to inspect job logs, reproduce failures and record the resolution.
Evidence collection steps show what to retain, where it is stored and how to sample it for the auditor.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover schedule changes, alert tuning and periodic review of job monitoring evidence.
Confirm with your auditor which evidence format and sample periods they expect before the engagement starts.