SOX IT general controls: the documents your auditor will ask for

For SOX IT general controls, you need a scoping memo for in scope systems, written policies for access, change management and IT operations, a risk and control matrix, procedures for periodic reviews, and dated evidence of each control running. The auditor tests controls over program changes, access to programs and data, and computer operations.

What are ITGCs, and why do auditors care?

Public companies must assess internal control over financial reporting, and an external auditor may test it. Automated controls inside financial applications are only reliable if the controls around the systems hold. PCAOB's auditing standard AS 2201 says that if general controls over program changes, access to programs and computer operations are effective, the auditor can rely on automated application controls without re testing each one every time, subject to conditions. So weak ITGCs spread doubt across everything the system does. (I read AS 2201 through an archived copy; SEC and COSO pages were blocked, so framework details below are general practice you should confirm with your auditor.)

Which documents form the core set?

1. Scoping memo. Lists the financial reporting processes, the applications and infrastructure that support key controls, hosting arrangements and the reasoning for exclusions. Update it when systems change.

2. Risk and control matrix. One row per ITGC: risk, control description, owner, frequency, evidence, and the systems it covers.

3. Access management policy and procedures. Joiner, mover and leaver steps, approval rules, privileged access rules, shared account rules, and the cadence and method of user access reviews. Include a segregation of duties statement, such as developers not holding production deploy rights.

4. Change management policy and procedures. How changes are requested, reviewed, tested, approved and released, plus an emergency change path with after the fact review. Evidence usually comes from the ticket system and source control.

5. IT operations procedures. Job scheduling and monitoring, backup and restore, incident handling and problem tracking.

6. Program development or implementation procedure. Applies when you introduce a new system: requirements, testing, data migration checks and go live approval.

7. Service provider oversight. For hosted or outsourced systems, a list of providers, how you obtain their independent assurance reports, and how you handle the user controls those reports expect from you.

8. Evidence standards. A short note saying what evidence is accepted: date, source, who produced it, and how complete populations are generated from system data.

What do auditors do with the documents?

They compare the written control to practice by sampling. They ask for a complete list of the population, such as all leavers in the period or all production changes, then pick items. If you cannot produce a complete and accurate list, the test stalls. Build the report that generates the population before the audit and keep the query.

How detailed should the documents be?

Short and specific beats long and generic. A good control description names who performs the control, how often, what system they use, what they look at, what counts as an exception and where the evidence is saved. If an outsider could repeat the control from the paragraph alone, the description is detailed enough.

Match the text to practice. If the procedure says leavers lose access within one business day, your leaver report must show that. If you cannot meet a promise, change the promise and the process together, and note the date of the change so the auditor sees a clean before and after.

Who owns what?

IT management owns the policies. System owners own access reviews. Engineering owns change records. Finance owns the scoping memo with IT. Internal audit, if you have it, tests from the outside.

What to do

1. Write the scoping memo with finance and IT.
2. Build the control matrix with owners and evidence sources.
3. Draft short access, change and operations procedures that match what you really do.
4. Create population reports for leavers, changes, access and jobs.
5. List service providers and request their assurance reports.
6. Run each control once and file dated evidence.
7. Ask your auditor which controls and years they will test.

Quick check

How Safeguard helps automate this

ITGC evidence is repetitive: access lists, change records, job and backup results, all dated. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs continuously between audits. For change management, technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically, so a human can stay in the approval path your change policy requires. The audit is carried out by your independent auditor.

Try the framework mapping demo full screen.

Sources

• PCAOB, AS 2201 (read via an archived copy because pcaobus.org blocked direct access)

Last reviewed: 18 October 2026.