ITGC Computer Operations: Backups, Job Scheduling and Incident Controls

Computer operations is one of four IT general control areas the SEC's interpretive guidance gives as examples (program development, program changes, computer operations, and access to programs and data). It is also where many financial reporting errors begin: an overnight job fails and nobody notices, an interface drops half its records, or a backup turns out to be unusable when needed. This post sets out a control set and a test program for this area.

What the guidance says about scope

The SEC guidance says management evaluates only those ITGCs that are necessary for the proper and consistent operation of other controls that address financial reporting risks, and that ITGCs which primarily pertain to efficiency or effectiveness of operations, and are not relevant to financial reporting risks, need not be evaluated. That sets the scope for computer operations: jobs, interfaces and backups that carry financial data or support financial applications.

Control set

NIST CSF 2.0 mapping

NIST CSF 2.0 includes outcomes that match these controls. PR.DS-11 says backups of data are created, protected, maintained and tested. RC.RP-03 says the integrity of backups and other restoration assets is verified before using them for restoration. PR.PS-04 says log records are generated and made available for continuous monitoring. RS.MA-02 and RS.MA-03 cover triage and validation of incident reports and the categorization and prioritization of incidents. The framework does not prescribe how to achieve these outcomes. It links to resources on practices and controls that could be used.

Test program

1. Inventory the jobs and interfaces that matter. List batch processes and interfaces that post to the general ledger, subledgers or the bank files. Rank by financial effect; Standard 13.2 Engagement Risk Assessment requires evaluating the significance of risks and prioritizing them for review.
2. Failure monitoring. Obtain the job log for the period and the incident tickets. For failures in the log, trace each to a ticket and a resolution. Failures with no ticket show the monitoring gap.
3. Reruns and manual overrides. Review how failed jobs are rerun; a rerun can double-post. Confirm approval.
4. Interface reconciliation. Reperform record counts and control totals for sample runs.
5. Backups. Obtain backup logs, compare to schedule, check for failed backups and how they were addressed. Confirm offsite or separate storage and access restrictions.
6. Restore testing. Obtain restore test records. A backup that has never been restored has not been tested.
7. Incidents. Review the incident register for financial system incidents, trace to root cause analysis and see whether the same incident type recurs.
8. Hosted environments. Obtain the provider's service organization report if available, and review complementary user entity controls. See /us/blog/reviewing-soc-reports-complementary-user-entity-controls.

Worked example

A company's nightly interface moves cash receipts from the lockbox bank file into the receivables subledger. Internal audit tests OP-02, OP-03, OP-04 and OP-05.

• Job log. Twenty-three failures in the year on that interface. Eleven had incident tickets. Twelve did not; operators reran the job and moved on. In four of the twelve, the rerun double-posted receipts that were later reversed manually by AR staff at the cost of two days of reconciliation effort each.
• Interface reconciliation. The control total of the bank file was compared with the subledger posting only monthly. A $146,000 mismatch had persisted for 19 days.
• Backups. Logs showed daily backups succeeded except on three days, with no follow-up. Backups were stored in the same data center.
• Restores. No restore had been tested in the past two years.

Findings: OP-02 not effective (monitoring without ticketing); OP-03 not effective in design (reconciliation too infrequent for the risk); OP-04 and OP-05 not effective. The cash application issue affects revenue and receivables, so it is evaluated for ICFR effect with the other deficiencies in that area. See /us/blog/control-deficiency-aggregation-memo-sec-guidance-and-written-conclusion.

Recommendations

Automate failure alerts that create tickets; require approval for reruns of financial jobs; reconcile interface control totals daily; store backups in a separate location; test restores on a schedule; and review the incident register monthly for patterns. See /us/blog/it-audit-guide-itgc-program-and-checklist.

Linking to financial reporting

Where an automated control or key report depends on a job running correctly, a failure in operations can invalidate the control for that period. See /us/blog/ipe-and-it-dependent-controls-testing-reports-used-in-key-controls for testing the reports, and /us/glossary/it-general-controls.

Mistakes to avoid

• Counting the existence of backups as a control without restore tests.
• Relying on monthly interface reconciliation for daily postings.
• Treating job failures as operational noise.
• Omitting vendor-hosted systems from the scope.

CORAA prepares ready-to-review audit files for US CPA firms from client books; the firm keeps the client, the review and the signature. See /us.

Sources

• SEC, Release No. 33-8810, Section II.A.1.d, Role of Information Technology General Controls: https://www.sec.gov/rules/interp/2007/33-8810.pdf
• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29 (February 26, 2024), PR.DS-11, RC.RP-03, PR.PS-04, RS.MA-02, RS.MA-03: https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
• The IIA, Global Internal Audit Standards (2024), Standard 13.2 Engagement Risk Assessment: https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/

AU-C references are to AICPA Professional Standards, paraphrased here; read the standard itself before relying on a requirement. This page is guidance, not professional advice. Report an error