Scoping is the most consequential decision in a mid-market SOX programme. Get it right and the controls work covers what matters with reasonable effort. Get it wrong - too narrow and you miss material risks; too broad and you exhaust the team on controls that do not affect the financial statements - and the entire programme suffers for the duration. This checklist explains how to scope IT general controls for a mid-market business preparing for or running through SOX compliance.

This article assumes you understand the basics of SOX compliance and IT controls. If you do not yet, start there. This is the practical follow-on: how to do the scoping work in a mid-market business where the IT estate is messier than the enterprise textbooks assume.

Why scoping matters most

The financial statements are the destination. Internal controls over financial reporting (ICFR) are the apparatus that supports the financial statements. IT general controls (ITGCs) are the foundation that allows the IT-supported financial controls to be relied upon by the external auditor. Scoping is the decision about which IT systems matter enough to that apparatus that they need to be controlled, evidenced, and tested.

Three things follow from a well-scoped programme:

  • Auditor confidence. If the scope is defensible - clearly anchored to financial reporting risk - the auditor accepts the boundary. Audit time and cost stay reasonable.
  • Manageable effort. A scope that is too broad consumes team capacity on controls that do not actually affect the financial statements. The team burns out and material controls suffer.
  • Defensible exclusions. A scope that is too narrow leaves material risks uncontrolled. The auditor either expands the scope unilaterally (more cost, less control of timing) or qualifies their opinion.

The single most common reason a first-time mid-market SOX programme suffers is scoping done badly. The second is documentation done late. Get scoping right and the rest of the programme is manageable.

Why mid-market is different from enterprise SOX

Mid-market SOX programmes face four specific challenges that enterprise SOX guidance often does not address well.

1. The IT estate is messier

Enterprise IT estates have catalogues, defined ownership, and documented architecture. Mid-market estates often do not. Spreadsheets are doing things that should be in the ERP; integrations exist that no one fully understands; access models drifted years ago. Scoping starts with discovery, not selection.

2. The team is smaller

Enterprise SOX programmes have dedicated control owners, an internal audit function, and specialist IT-audit liaison. Mid-market programmes are typically run by a finance manager part-time, an IT manager part-time, and a CFO sponsor who is also doing ten other things. The scope must be realistic about the capacity to execute.

3. Auditor expectations are calibrated to size

External auditors apply professional judgement scaled to the entity. A mid-market business is not expected to have the same ITGC maturity as a Fortune 500 company. But there is a floor below which controls cannot be relied upon, regardless of size. Knowing where that floor is - in the context of your auditor - is essential to scoping well.

4. The systems landscape evolves faster

Mid-market businesses change systems more often than large enterprises. A scope set this year may be partially obsolete by next year if an ERP migration, finance system swap, or M&A integration is in progress. Scoping has to anticipate change.

The single most-important framing for mid-market SOX scoping: scope from the financial statement line items backwards, not from the IT estate forwards. Identify the accounts and disclosures that matter; trace them back to the IT systems that produce them; control those systems. The reverse direction - listing all IT systems and asking which are in scope - produces over-scoping every time.

How to identify in-scope systems

A six-step process to identify which IT systems are in scope for ITGC testing.

Step 1: Map the significant financial statement accounts

Start with the financial statements. List the accounts and disclosures that are material - the ones where a misstatement would meaningfully affect the financial statements. Materiality thresholds are set by the auditor; the list of significant accounts follows.

Step 2: Identify the business processes that produce those accounts

For each significant account, identify the business processes that generate, classify, and report the underlying transactions. Revenue accounts trace to order-to-cash; purchase accounts trace to procure-to-pay; payroll traces to its own process; close, consolidation, and reporting are typically scoped together.

Step 3: Identify the IT systems that support each process

For each significant process, list every IT system that initiates, processes, records, or reports the transactions. Include the obvious systems (ERP, finance system, payroll system) and the less obvious ones (spreadsheets that do month-end allocations, integrations that move data between systems, reporting tools that produce financial outputs).

Step 4: Apply the in-scope test to each system

A system is in scope for ITGCs if it produces, transports, calculates, or reports data that flows to a significant account, and the financial controls relying on that system would be ineffective if the IT controls failed. Systems that only hold reference data, that are not used for financial reporting, or whose output is independently re-validated by a manual control are not in scope.

Step 5: Decide on end-user computing (EUC)

Spreadsheets and end-user-developed tools used in financial reporting are a perennial mid-market scoping question. The auditor's view is what matters. The defensible approach is: spreadsheets that calculate or summarise data flowing to significant accounts are in scope; spreadsheets used only for ad-hoc analysis are not. Document the inventory and the scoping rationale.

Step 6: Document the scoping decision

Produce a written scoping document that lists every IT system considered, states whether it is in scope or out of scope, and gives the rationale. The auditor will review this. Pages of evidence are better than no evidence; the scoping document is one of the first things an auditor asks for.

The four ITGC domains

Once scoping is settled, each in-scope system is tested across four ITGC domains. These are the four areas the auditor expects to see controlled, and where the bulk of the ITGC work happens.

Domain What it covers Why it matters to financial reporting
Access management Who can log in to financial systems, what they can do, and how access is granted, reviewed, and removed. If unauthorised users can access financial systems, controls that depend on user identity (segregation of duties, approval workflows) cannot be relied upon.
Change management How changes to financial systems are requested, tested, approved, and deployed. If unauthorised or untested changes can be made to financial systems, the system may calculate or report incorrectly without the financial controls catching it.
Operations & availability Backup, recovery, monitoring, batch processing, and the operational reliability of financial systems. If financial systems are unreliable or data can be lost, the financial statements cannot be reconstructed and the controls that depend on system output fail.
Segregation of duties (SoD) Whether system access permits the same person to perform incompatible activities - typically initiating and approving a transaction. SoD failures allow fraud and error to go undetected. Mid-market businesses often have material SoD gaps because the team is small and people wear multiple hats.

The next four sections give the practical scoping checklist for each domain. Use these to assess your current ITGC posture before the audit, to drive remediation, and to brief auditors on what is in place.

Access management checklist

Access management - what to check

  • Inventory of users with access to each in-scope system, by role
  • Process for granting new access - who approves, how it is evidenced
  • Process for removing access when someone leaves - timing, evidence
  • Process for changing access when someone changes role - approvals, timing
  • Periodic user access reviews - frequency, who performs them, how they are evidenced
  • Privileged access management - inventory of admin accounts, monitoring, segregation
  • Generic and shared accounts - inventory, justification, supplementary controls
  • Password policy enforcement on financial systems - complexity, expiry, MFA
  • Multi-factor authentication on remote access and privileged access
  • Documentation: written access policy, role definitions, approval matrix

The most common access-management deficiency in mid-market is the user access review. Many businesses do a manager-sign-off once a year that is not evidenced beyond a verbal confirmation. The auditor will look for a written list, reviewer initials or sign-off, and evidence of what was changed as a result. The auditor will also check that terminations and role changes are reflected in the system within a reasonable window - typically 24-48 hours for terminations, the same week for role changes.

Change management checklist

Change management - what to check

  • Written change management policy covering all in-scope systems
  • Change request inventory - all changes made, with classification
  • Approval evidence for each change - business owner, IT owner where required
  • Testing evidence for each change - what was tested, by whom, with what result
  • Deployment evidence - who deployed, when, with what authorisation
  • Segregation between development and production - developers cannot deploy to production
  • Emergency change process - how break-fix changes are made and retrospectively approved
  • Configuration changes - inventory of business-rule changes (not just code changes)
  • Vendor patches and updates - inventory of vendor-driven changes and how they are evidenced
  • Change-management for spreadsheets and EUCs - version control, approval, testing

Change management is the domain where mid-market businesses most often have to professionalise. Small teams have historically made changes informally - especially configuration changes that nobody thinks of as "changes". The auditor will look at the inventory of changes for a sample period and check that each has an approval, evidence of testing, and deployment record. If the inventory is incomplete, the conclusion is that some changes are happening outside the controlled process - which is a finding.

Operations and availability checklist

Operations & availability - what to check

  • Backup policy covering in-scope systems - frequency, retention, location
  • Backup evidence - logs showing backups completed successfully
  • Recovery testing - evidence that backups can be restored
  • Monitoring of financial systems - what is monitored, alerting, escalation
  • Incident management - log of incidents affecting financial systems, response evidence
  • Batch job management - inventory of financial batch jobs, monitoring, error handling
  • Job scheduling - approvals for new or changed scheduled jobs
  • Service-level monitoring - uptime tracking for in-scope systems
  • Disaster recovery plan - documented, tested, with named owners
  • Vendor management for hosted systems - SLAs, monitoring, vendor SOC reports

The auditor is checking whether the financial systems are operationally reliable enough that the data they produce can be trusted. The key evidence is backup logs (proving backups happen), recovery test results (proving they work), and incident logs (proving that operational issues are detected and resolved). Where systems are hosted by a third party, the auditor will look at vendor SOC reports - particularly SOC 2 Type II reports - to take comfort on the vendor-managed controls.

Segregation of duties checklist

Segregation of duties - what to check

  • SoD matrix for in-scope systems - which activities are incompatible
  • Configuration of system roles to enforce SoD
  • Inventory of users with SoD conflicts - violations against the matrix
  • Compensating controls where SoD cannot be enforced - what they are, how they work
  • Evidence that compensating controls operate effectively
  • Process for handling exceptions - approvals, review
  • SoD review in change management - new roles do not introduce conflicts
  • Privileged access SoD - segregating system administration from financial operation
  • Cross-system SoD - controlling conflicts that span multiple systems (e.g., AP and bank)
  • Documentation: SoD policy, matrix, exceptions log

Mid-market SoD is the hardest domain to get right because the team is small. The same person who creates a vendor in the ERP may need to be able to pay it. The honest position is that perfect SoD is often impossible at mid-market scale; the right answer is compensating controls - typically detective controls where a second person reviews the transaction after the fact. The auditor will accept this approach if the compensating controls are documented, evidenced, and operating effectively. They will not accept it if the SoD policy claims segregation that the system configuration does not enforce.

Common scoping mistakes

Five mistakes account for most mid-market ITGC scoping failures. Each has a counter-pattern.

1. Scoping from the IT estate forwards rather than the financial statements backwards

The estate-first approach starts with a list of all IT systems and asks "which of these support financial reporting?". This over-scopes because it includes systems that touch financial data tangentially but are not relied upon for control. The financial-statement-backwards approach traces from significant accounts to the systems that materially affect them.

2. Missing the spreadsheets

End-user computing is the area auditors most often expand mid-audit. If the scoping document does not address EUC explicitly, the auditor will add it. Inventory the spreadsheets that calculate or report data to significant accounts; bring them into scope deliberately; document the scoping rationale.

3. Treating hosted systems as out-of-scope by default

Hosted financial systems - SaaS ERPs, hosted finance platforms - are not out of scope. They are in scope; the testing approach differs. The business retains responsibility for user-managed controls (access, change requests it initiates, configuration changes); the vendor's controls are evidenced via SOC 2 reports. Failing to address the user-managed controls on hosted systems is a common gap.

4. Scoping decisions that the auditor has not seen

A scope set internally and never validated with the auditor is a scope that will be challenged. Walk the scoping decisions through the external auditor before the testing period begins. Document the discussions. This is faster than discovering scope disagreements during fieldwork.

5. Not updating scope when the IT estate changes

A new ERP, a finance system swap, an M&A integration, a new business line - all of these change the scoping. Treat the scoping document as a living artefact, reviewed annually and after every material IT change. A scoping document that has not been updated in two years is a red flag to the auditor.

What auditors actually look for

The PCAOB sets the standards for SOX audits, but the practical experience of an audit is shaped by what the auditor asks for in fieldwork. Five things consistently feature.

1. A defensible scoping document

The auditor's first ITGC test is to read your scoping document and form a view on whether the boundary is reasonable. Pages of well-reasoned scoping documentation, with named systems and rationale, are easier to defend than a one-page summary.

2. Walkthroughs for each significant process

The auditor walks through a sample transaction from initiation to financial statement, identifying the IT controls that operate along the way. Walkthroughs surface scoping mistakes - if the auditor identifies a control point at a system you have not scoped, the system gets added to scope.

3. Evidence quality for each control

Evidence is the unit of audit. Each control claimed must have evidence of operation - logs, sign-offs, screenshots, documented review. Evidence that is incomplete, late, or inconsistent suggests the control is not operating reliably. Evidence quality is often the difference between a clean audit and one with findings.

4. Exception handling

The auditor will look at exceptions - terminations that took longer than policy, changes that bypassed the approval process, SoD violations, failed backups. The question is not whether exceptions happen; it is whether they are detected, escalated, investigated, and resolved.

5. Year-over-year consistency

For a repeat audit, the auditor will look at whether the controls operating this year are consistent with last year. Material changes to the control environment that have not been clearly documented and walked through become findings.

Realistic scoping timeline

Three timeline patterns are common, depending on starting position.

Starting position Total timeline to first scoped programme Notes
First-time SOX - no prior controls programme 6-9 months Includes IT estate discovery, scoping, controls design, evidence framework, walkthroughs. The largest hidden cost is usually access-management remediation.
Second-time scoping - refining an existing programme 2-3 months Annual scoping refresh after material change in the IT estate. Focuses on what is new, not the whole estate.
Post-acquisition - integrating a target into the SOX programme 3-6 months Target estate discovery, scoping decisions, evidence framework alignment with the acquirer's controls. Often runs in parallel with broader integration work.

The single largest predictor of timeline overrun is starting documentation late. Scoping decisions made without supporting documentation produce auditor challenges that re-open settled topics. Document as you scope, not after.

Conclusion

SOX ITGC scoping for a mid-market business is the single most consequential decision in the controls programme. Done well - financial-statement-backwards, with explicit treatment of end-user computing, hosted systems, and segregation of duties - the rest of the programme runs at reasonable effort and cost. Done badly, the entire programme suffers for the duration of the audit cycle.

The checklists in this article are the working tools. The underlying principles are: scope from financial reporting risk, not IT estate inventory; document everything as you go; validate decisions with the auditor before fieldwork; treat scoping as a living artefact that updates with material change.

If your business is preparing for first-time SOX, integrating a target post-acquisition, or recovering from a previous audit cycle that surfaced gaps, the lowest-cost first step is an independent SOX readiness assessment - 4 to 6 weeks of structured work that produces the scoping document, identifies the gaps, and outputs a remediation plan ahead of the audit cycle.

SOX readiness or remediation?

Independent SOX ITGC readiness assessment for mid-market businesses. Scoping document, gap analysis, remediation plan. Fixed scope, senior-led, no surprises.