SOX ITGC Evidence Checklist: What Auditors Ask For, by Control Family
The itemised request list an auditor sends for IT general controls, where each population comes from, and how to keep the evidence retrievable all year.
By William Bradshaw | October 12, 2026 | 9 min read
Auditors fail IT controls on evidence, not on design. A well-designed control that ran every month all year, with nothing retrievable to show it, is treated as a control that did not run. The policy can be perfect. If the auditor asks for the approval on change 14 and the answer is "we think it was in an email," the test result is an exception.
The severity ladder matters because it decides who hears about the finding. A control deficiency exists when a control does not allow timely prevention or detection of errors in the normal course of work. A significant deficiency is a deficiency, or a combination, important enough to merit the attention of those overseeing financial reporting. A material weakness is a deficiency, or combination, with a reasonable possibility that a material misstatement will not be prevented or detected in time. A control that ran all year but cannot produce proof lands in the first bucket at best, and it climbs the ladder quickly when the same gap shows up across several controls, or when it sits in an area the financial statements depend on.
This article is the itemised request list: the PBC ("prepared by client") list an auditor sends, organised by control family, with the source of each population. The basics of SOX 404, the four ITGC domains and the common deficiencies are covered in our SOX IT general controls article; read that first if the terms are new. Here the question is narrower and more practical: what, exactly, will you be asked to hand over, and can you retrieve it?
The Request List, by Control Family
Each table below follows the same three columns: the control, what the auditor asks for, and where the auditor will get the full population to sample from. The third column is the one most teams neglect, and the section on population and sample explains why it matters.
Access to programs and data
| Control | What the auditor asks for | Where the population comes from |
|---|---|---|
| New-user provisioning | A sample of new users, each with a ticket showing a manager approval, and system access that matches what was requested (no extra groups or roles). | HR new-hire list or a directory export of accounts created in the period. |
| Terminated users | Evidence that access was removed within the policy window, tested against the HR termination list, not the IT list. | HR system termination report for the full period, compared with directory disable dates. |
| Quarterly user access reviews | Reviewer sign-off with a date, the actual list that was reviewed, and the removals or changes that followed. | Review packages for each quarter, plus the tickets raised from them. |
| Privileged accounts | An inventory of privileged accounts, the owner of each, the justification, and evidence of a periodic review. | Directory export of administrator groups and local administrator memberships on in-scope servers. |
| Password and MFA policy | A configuration export from the directory or identity provider showing the enforced settings, not the written policy. | Live system settings, pulled with a timestamp and the name of who pulled them. |
| Shared and service accounts | An owner and justification for each account, and evidence that passwords are rotated or vaulted. | Service account inventory, password vault or rotation log. |
Program change
| Control | What the auditor asks for | Where the population comes from |
|---|---|---|
| Change tickets | Requester, approver, and an approval dated before deployment. | Ticketing system export of all production changes in the period. |
| Test evidence | A test plan, the results, and a tester who is not the developer. | Linked attachments or test records on each change ticket. |
| Deployment segregation | The deployer is not the developer. Where the team is too small, a compensating review of what was deployed. | Deployment tool log or release records showing the user who deployed. |
| Emergency changes | Retrospective approval within the policy window, and a root-cause note. | Tickets flagged emergency, or changes with no prior approval date. |
| Production deployment log reconciled to tickets | Every deployment traces to an approved ticket. The auditor selects from the log, not from the tickets. | Deployment or server change log, compared line by line against the ticket export. |
Program development and acquisition
This family only applies if you built or bought a system that touches financial reporting during the audit period. If nothing went live, say so in writing, and expect the auditor to check the change log or project list to confirm it.
| Control | What the auditor asks for | Where the population comes from |
|---|---|---|
| Project approval | Business case or charter with an approver and a date before work began. | Project register or PMO records. |
| Requirements sign-off | Signed requirements from the business owner. | Project folder, ticket attachments. |
| User acceptance testing | UAT scripts, results, defects raised, and sign-off from users, not IT. | Test management tool or UAT workbook. |
| Data conversion reconciliation | Record counts and control totals from the old system compared with the new, with differences explained. | Extract and load reports from both systems. |
| Go-live approval | Documented approval to cut over, dated before go-live. | Change ticket or steering committee minutes. |
| Post-implementation review | A review within the planned window that records issues and lessons. | Project closure records. |
Computer operations
| Control | What the auditor asks for | Where the population comes from |
|---|---|---|
| Backup job logs | Logs for the sampled dates, including any failures and the ticket or note showing how each was resolved. | Backup platform job history for the full period. |
| Restore tests | A documented restore with date, scope, outcome, and who ran it. | Restore test records kept by the infrastructure team. |
| Job scheduling | Failed-job reports and the resolution ticket for each failure. | Scheduler or batch tool exception report. |
| Incident and problem tickets | Severity, response, and closure for a sample of incidents, with evidence that high-severity items were escalated. | Ticketing system export filtered to incidents. |
| Batch and interface exceptions | Exceptions from interfaces between systems and how each was investigated and cleared. | Interface monitoring log or reconciliation report. |
A restore test is the item most often missing. A backup log shows a job finished; only a restore shows the data came back. Our backup and disaster recovery article covers how to design the test so it is both auditable and real, and what a defensible record of it looks like.
Population and Sample: Where the Evidence Stops Counting
The auditor does not choose from the evidence you offer. The auditor chooses from a population, and the population has to be complete and accurate. For terminations, that is the HR system, because HR knows who left. For changes, it is the ticketing system export or the deployment log. For access, it is a directory export dated close to the test.
A hand-built spreadsheet fails here. If a person assembled the list of terminated users from memory and email, the auditor cannot establish that it contains every termination, and completeness is the first thing tested. The same is true of a change list typed up after the fact. Pull the population directly from the system of record, keep the export file with its timestamp, and note the report or query that produced it so it can be run again.
The sample size depends on how often the control operates. The ranges below are commonly used, and they vary by audit firm and by the risk rating of the control. They are not a standard.
| Control frequency | Commonly used sample |
|---|---|
| Annual | 1 |
| Quarterly | 2 |
| Monthly | 2 to 5 |
| Weekly | 5 to 15 |
| Daily | 20 to 40 |
Small samples cut both ways. With two quarterly reviews tested, one missed review is half the sample. With 25 terminations tested, two late removals is a reportable exception rate.
The Quarterly Evidence Calendar
Year-end should be retrieval, not reconstruction. Spread the pulls across the quarter so nothing depends on memory.
Pull the populations
Export new hires, terminations and role changes from HR and the directory. Export all production changes and deployments from the ticketing and deployment systems. Save each with its timestamp.
Test and reconcile
Compare terminations to disable dates. Reconcile the deployment log to tickets and chase any deployment with no ticket. Review backup failures and confirm each has a resolution note.
Review and sign
Run the quarterly user access review and capture the reviewer sign-off and resulting removals. Run a restore test and record it. Export privileged account lists.
Assemble the folder
Collect the four quarterly folders, add the annual items (policy review, password configuration export, SOC 1 reports from vendors), and index them against the PBC list.
The same folder can answer more than one auditor. Our compliance framework mapping guide shows how one quarterly vulnerability scan serves CIS, NIST, PCI-DSS and SOC 2 at once, and the same logic applies here: a quarterly access review with a dated sign-off answers the SOX auditor, the SOC 2 auditor and the cyber-insurance questionnaire from one file. Bullium delivered a four-year infrastructure engagement for a major regional power and utility company operating under SOX, where this kind of change, access, backup and recovery discipline ran at scale.
Evidence Hygiene
Screenshots. A screenshot is acceptable evidence only if it shows the system name, the date and time, and who pulled it. If the tool does not display those, record them in the file name. A cropped image of a setting with no context is the most common reason a screenshot is rejected.
Naming. A convention that sorts and explains itself saves hours. For example: 2026-Q3_access_terminations_directory-export_2026-10-02_wbradshaw.csv. Period, control, source, date pulled, and who pulled it. Keep one folder per quarter and one subfolder per control family.
Retention. SEC Rule 2-06 of Regulation S-X, adopted under Section 802 of the Sarbanes-Oxley Act, requires the audit firm to keep its work papers for seven years. That duty is the auditor's, not yours, but aligning your own evidence retention with it means a request about a prior year can still be answered.
SaaS systems. If a hosted application feeds financial reporting, ask the vendor for its SOC 1 Type 2 report. Read the complementary user entity controls (CUECs) in it, which are the controls the vendor assumes you perform, and map each one back to an item on your own evidence list. A SOC 1 report does not cover your user access reviews of the application. Also ask for a bridge letter, which covers the gap between the end of the report period and your fiscal year end.
How These Get Written Up
These are typical findings as an auditor phrases them, and the evidence fix that would have prevented each.
"Terminated user access not removed within policy: 2 of 25 samples."
Compare the HR termination list to directory disable dates every month, and keep the comparison. The exception then becomes a documented, resolved item instead of a surprise.
"User access review performed without evidence of the list reviewed."
Save the exported listing with the sign-off, and record every removal as a ticket that references the review. Sign-off on its own proves nothing about what was reviewed.
"Production changes deployed without documented approval: 3 of 40 samples."
Block deployment from the pipeline unless a ticket number is attached, and reconcile the deployment log to tickets monthly.
"No evidence of a restore test during the period."
Run and document one restore per quarter: date, scope, outcome, who ran it, and any defect found.
Frequently Asked Questions
How many samples will the auditor pull?
It depends on how often the control runs and how the audit firm rates its risk. Commonly used ranges are 1 for annual controls, 2 for quarterly, 2 to 5 for monthly, 5 to 15 for weekly and 20 to 40 for daily. These vary by firm and are not a standard.
What if a quarterly access review was missed?
Do not backdate it. Perform the review now, date it honestly, and document why it was late. The auditor will likely report an exception for the missed quarter, but a late review with the removals it produced is a far better position than no review or a review that appears to be backdated.
Do SaaS systems need our own evidence?
Yes. The vendor SOC 1 Type 2 report covers the vendor controls only. The complementary user entity controls in the report, such as user provisioning, access review and change approval on your side, still need your own evidence.
What counts as segregation of duties in a five-person IT team?
Ideally the person who deploys a change is not the person who wrote it. Where that is not possible, auditors commonly accept a compensating control, such as a second person reviewing the deployed change against the approved ticket, with the review recorded.
Can screenshots be replaced by system reports?
Often yes, and a report is usually stronger. A system-generated report or export carries a timestamp, can be rerun by the auditor, and avoids questions about cropping. Keep the export file and record who ran it and which report it was.
Turn the Request List Into a Folder You Already Have
Bullium's security and vCIO teams help smaller public companies and private companies facing a lender or exit audit build the quarterly evidence routine, map it to the PBC list, and find the gaps before the auditor does. We start with a walkthrough of your current evidence against this checklist. No commitment to engage further.
Related Reading
SOX IT General Controls (ITGC)
The parent article: SOX 404, the four ITGC domains, and the deficiencies that fail audits.
Compliance Framework Mapping Guide
How one quarterly scan serves CIS, NIST, PCI-DSS and SOC 2 at once, the same reuse this checklist applies to access reviews.
Backup and Disaster Recovery
Designing the restore test so the evidence is both auditable and real.
Enterprise Infrastructure at Utility Scale
A four-year engagement built on change, access, backup and recovery discipline.
Related Services
Security Consulting
Control design, evidence routines and readiness reviews ahead of an audit.
vCIO Engagement
A strategic owner for the control program, not just hands.
Managed IT Services
Ticketing, patching, backup and access processes that leave evidence as a byproduct.
Network Assessment
A current inventory of in-scope systems, so no system is missed.