Scope SOX IT general controls from the top down. Start with financial reporting risks, find the processes and applications that address them, then include only the IT general controls those applications rely on. SEC guidance says management needs to evaluate only the ITGCs necessary for other controls to operate properly and consistently.
Why does scoping come first?
Teams often start with a list of every system and a standard ITGC checklist. That produces a large scope, a lot of testing and little link to the financial statements. The SEC's 2007 interpretive guidance for management on internal control over financial reporting (ICFR) describes the reverse: a top-down, risk-based approach, with identification of risks and controls in IT as an integral part of it, not a separate evaluation.
The same guidance makes two points that shape scope. First, ITGCs alone ordinarily do not address financial reporting risks, but the proper and consistent operation of automated controls and IT functionality often depends on them. Second, it is unnecessary to evaluate ITGCs that mainly concern operational efficiency and are not relevant to financial reporting risks.
What is the top-down path?
Step 1: financial reporting risks. What could cause a material misstatement? Revenue recognition, inventory valuation, journal entries, payroll and similar areas. Finance leads this step, not IT.
Step 2: controls that address those risks. Some are manual, some automated, some IT dependent. The guidance gives examples: automated matching and edit checks, formulas that calculate consistently, a manual review of a computer generated exception report.
Step 3: applications those controls depend on. The ERP, billing, payroll, the data warehouse that feeds a report, the spreadsheet with a macro. A spreadsheet that drives a number in the financial statements is in scope even though nobody calls it a system.
Step 4: supporting layers. For each in scope application, list the database, operating system, network and cloud hosting that support it, and the identity system that controls access. These come in because the application relies on them.
Step 5: which ITGC areas apply. The guidance gives four examples of areas management might consider: program development, program changes, computer operations, and access to programs and data. A footnote adds that these are examples and do not apply to every situation. Decide per application which areas matter and write down why.
What about vendors and outsourced services?
If a significant process runs at a service organization, you need evidence about its controls. The guidance discusses obtaining a service auditor's report that includes tests of operating effectiveness, and warns that if you cannot obtain evidence by any route, you must consider whether that prevents concluding that ICFR is effective. Identify these vendors in scope now and ask for their reports before the year begins.
What are the boundaries to write down?
Make a scoping memo with these items: the in scope processes and why, the applications and their owners, the supporting infrastructure, the ITGC areas selected for each, the exclusions with reasons, the service organizations, and the period. Date it, have finance and IT leadership approve it, and update it when systems change.
What evidence will you need later?
Evidence of operating effectiveness can come from direct testing and ongoing monitoring. The guidance says to consider not only quantity of evidence, such as sample size, but also its qualities: the nature of the procedures, the time period it relates to, the objectivity of those evaluating the control, and the extent of validation of monitoring. Plan for evidence that covers the whole period, not a snapshot.
Mistakes to avoid
- Scoping from an ITGC checklist instead of the financial risks.
- Leaving out end user spreadsheets and reports that feed the numbers.
- Treating a cloud service as outside scope without a service organization report.
- Changing systems mid year without updating scope.
- Putting IT in charge of scoping without finance.
What to do
- List financial reporting risks with finance, and rank them.
- Map each risk to the controls and the applications behind them.
- For each application, list the database, operating system, network, hosting and identity layers.
- Choose the ITGC areas that apply and write the reason.
- List service organizations and request their reports.
- Write and approve the scoping memo, then set a change trigger to revisit it.
- Confirm with your external auditor and legal counsel, since requirements depend on your filing status.
Quick check
Are all four ITGC areas always in scope?
No. The SEC guidance gives them as examples and says they do not apply to all facts and circumstances. Decide per application and record why.
Does SOX apply to us?
It depends on your filing status and your auditor. Ask your counsel and auditor, because this guide does not decide that.
How Safeguard helps automate this
Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence for change management and access controls can be collected from connected systems instead of screenshots and kept current through the period. Technical evidence comes from your real code and dependencies, which helps show that changes to finance related software went through your defined process. Autonomous remediation 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. Safeguard helps you prepare and keep evidence ready. Management and your external auditor make the SOX conclusions. Book a call.
Sources
- SEC, Commission Guidance Regarding Management's Report on Internal Control Over Financial Reporting (Release 33-8810, 2007), downloaded and read 18 October 2026.
- The PCAOB page for AS 2201 returned an access error on 18 October 2026, so the auditor's standard is not covered here.
Last reviewed: 18 October 2026.
