How SOX ITGCs apply across multiple locations and shared service centers
When finance and IT run across several subsidiaries or a shared service center, SOX ITGC testing is matched to the risk at each location, not spread evenly across all of them. Under PCAOB AS 2201 (paragraph B10), the external auditor adjusts its attention to each location or business unit based on risk and may drop locations that, alone or in aggregate, present no reasonable possibility of material misstatement. For lower-risk locations, paragraph B11 lets the auditor first ask whether testing entity-level controls gives sufficient evidence, including controls that confirm appropriate controls exist throughout the organization. Management follows the same logic: the organization owns its controls and decides how they are scoped, while an implementation partner, if one is used, prepares systems and evidence. Only the external auditor issues the attestation.
The right mix depends on three things. The first is location count, since each additional ledger, instance or entity adds scope unless it can be excluded on risk grounds. The second is how much financial processing is centralized. A shared service center that runs access, change and operations for many entities concentrates both the ITGCs and the risk, so one well-tested environment may support several entities. The third is how mature the entity-level controls are, including the control environment, internal audit and self-assessment programs that SEC Release 33-8810 asks management to consider. Confirm with your auditor early which entities they expect to test directly and which they expect to rely on through entity-level evidence, because that decision drives the rest of the location plan.
How to select locations for ITGC testing
Auditors match testing effort to the risk each location or business unit adds to financial reporting. The factors below decide whether a unit needs full ITGC testing, a lighter entity-level approach, or no separate testing at all, and each one changes the footprint across access, program changes and computer operations.
Share of revenue and assets
Start with how much of revenue, assets and transaction volume each location contributes to the financial statements. A unit that alone or in aggregate presents no reasonable possibility of material misstatement can be dropped from ITGC testing. A large unit keeps full access and program change testing for its ledgers and interfaces. Ask finance for a location-level breakdown of significant accounts so the threshold is documented before testing begins.
Own ledger or shared instance
A location running its own ERP instance needs access, change and operations testing for that instance. A location posting into a shared instance usually inherits those ITGCs from the central environment, so the question shifts to whether its users, roles and interfaces are controlled there. Confirm which entity owns each ledger and where its access and change logs are kept.
Automated controls the unit depends on
Count the automated application controls, such as three-way matching, configured approval limits and interface reconciliations, that a location relies on. Each one depends on access and program change controls over the configuration, and benchmarking only works if those ITGCs are effective. A unit with many automated controls needs deeper ITGC testing even when its revenue share is modest.
Manual adjustments and journal entries
Manual journal entries, top-side adjustments and spreadsheet-driven postings bypass automated controls. Locations that post heavy manual activity raise the risk of unauthorized access and inaccurate processing, which pushes testing toward privileged access and computer operations. Pull journal entry volumes by location and by user role to see where manual intervention concentrates.
History of control deficiencies
Prior-year deficiencies, unresolved remediation and self-assessment findings at a location raise its risk. Management and the auditor should treat a unit with recent failures as higher risk until it shows sustained operation. Review the deficiency log, internal audit reports and management's self-assessments, then vary the nature and timing of testing from year to year so the location cannot predict which controls will be tested.
Shared service center processing
When a shared service center processes transactions for several entities, the ITGCs over its systems and access model apply to every entity it serves. Test the service center as one unit rather than repeating the same work at each client location, and confirm that its controls cover the transactions each entity records. Coordinate with internal audit, which may already test the center's operations, to reduce duplicate location visits.
Coordinating ITGC testing with internal audit
PCAOB AS 2201, paragraph B12, lets the external auditor coordinate with internal audit's planned work at locations and reduce the number of locations it would otherwise test itself. The benefit is real only if the two teams agree on the work before fieldwork starts. Management decides the internal testing plan, including which shared service center, subsidiary or region internal audit covers each year, which ITGCs it tests there, and how it samples. The external auditor then evaluates whether that work is planned, performed and documented well enough to rely on. Confirm with your auditor early in the year what they expect to see before they will reduce their own testing.
In practice, coordination rests on four things. First, a shared testing plan that lists each location, the in-scope ITGCs (access, program changes, program development and computer operations) and the planned timing, so no area falls between the two teams. Second, consistent control descriptions, so that a control such as user access review at a shared service center is described the same way in management's documentation, internal audit's workpapers and the auditor's walkthroughs. Third, timely access to internal audit workpapers, including populations, samples, test steps and exceptions, so the auditor can judge the quality of the work. Fourth, objectivity: internal audit should not design or operate the controls it tests, and its reporting line should be independent of the function it reviews.
Where internal audit lacks specialized IT audit skills or capacity, an outside co-source provider can help execute planned tests under management's direction. That provider can prepare workpapers and evidence, but it does not issue the auditor's report or the management assessment, and it cannot take over the decisions that belong to management. Ask any provider to document who approved the plan, who performed each test and who reviewed the results, and confirm the arrangement with your external auditor before the work begins.
How testing rotates from year to year
This sequence turns a list of locations and shared centers into a multi-year testing plan that concentrates effort where misstatement risk is highest, keeps lower-risk units covered, and varies the testing so it stays unpredictable. Each step produces a record that an auditor or internal reviewer can follow.
Inventory locations and shared service centers
Start with a complete list of every subsidiary, region, plant, business unit and shared IT or finance service center that processes, records or supports financial transactions. For each one, record what it does, which financially significant applications it uses, who runs its IT and which finance processes it feeds. Finance and IT leads own the list, and internal audit checks it against the legal entity structure and the general ledger. The step closes when the inventory is signed off and every in-scope application appears against at least one location or shared center.
Build the location risk register
Score each location or center on factors tied to misstatement risk: the size of the accounts it affects, the complexity of its transactions, the degree of manual intervention, the number of local system changes, prior deficiencies and staff turnover. Record the score and the reason for each rating in a location risk register. Include shared centers as their own rows, because a single center may process transactions for many entities. The register is complete when each row has a rating, an owner and a short rationale that a reviewer can challenge.
Screen out locations with no reasonable misstatement risk
PCAOB AS 2201 allows the auditor to drop locations that, alone or in aggregate, present no reasonable possibility of material misstatement. Management can apply the same logic when it sets its own testing population. Confirm the exclusion against the accounts and assertions each location touches, and check that the excluded units together do not reach a material share of the affected balances. The output is a screening memo listing each excluded location and the reason it was excluded, reviewed by the controller and the ICFR lead.
Assign testing depth by risk tier
Match the attention each remaining location receives to its risk rating, as AS 2201 paragraph B10 describes. Higher-risk locations and shared centers receive detailed ITGC testing of access, program changes and computer operations. For lower-risk locations, first consider whether testing entity-level controls, including controls that confirm appropriate controls exist across the organization, provides sufficient evidence, as paragraph B11 describes. Where internal audit already plans work at a location, coordinate with it to reduce duplicate procedures, as paragraph B12 allows. The output is a testing depth matrix showing, for each location, whether it receives full testing, reduced testing or entity-level reliance.
Design the multi-year rotation schedule
Lower-risk locations that receive reduced testing should rotate so that different units get detailed testing in different years. AS 2201 paragraph B13 says the auditor should vary the nature, timing and extent of testing at locations or business units from year to year, and paragraph 61 requires variation in control testing to introduce unpredictability. Map each location to a rotation cycle, vary the control selections and test dates, and keep high-risk units on an annual basis. The rotation schedule is complete when it shows each location's test year, the procedures planned and the coverage of every in-scope application over the cycle.
Document the scoping rationale
Write a scoping memo that explains the selections made in this cycle. It should cite the risk register scores, the screening conclusions, the testing depth chosen for each unit, any reliance on entity-level controls and the reason each location was placed in its rotation slot. Management owns the memo, and the ICFR steering committee or audit committee reviews it before fieldwork starts. The memo is finished when a reviewer who did not build the plan can trace every location to a documented decision.
Refresh the plan when conditions change
Reopen the risk register and rotation schedule when a location is acquired, a shared center takes on new processing, a financially significant system changes hands, or testing shows a deficiency. Re-score the affected rows, update the scoping memo and record the change with its date and approver. Confirm with the external auditor that the revised plan still meets its expectations before fieldwork. Ask the auditor which events it treats as triggers for re-planning, because those expectations vary by engagement.
What to have in place before the first multi-location test
Multi-location testing only holds up when the scoping decisions behind it can be traced. Each item below gives the auditor a fact base for choosing locations, relying on entity-level controls and coordinating with internal audit. Check each one before the testing period opens, not during fieldwork.
Current entity and system inventory
Build a list of every legal entity, site, region and shared center that records or processes financially significant transactions, and map which applications, databases and interfaces each one uses. Include locally run systems and spreadsheets that feed reports. Check the inventory against the general ledger entity structure and the prior year scope memo. Gaps usually sit in acquired units and local tools nobody reviewed centrally.
Documented control ownership at shared centers
For each control a shared service center performs or supports, record who designs it, who operates it, and which entity's financial statements it protects. Ownership of access reviews, change approvals and job monitoring often splits between the center and local finance teams. Ask for a responsibility matrix signed by both sides. Without it, a deficiency at the center can be assigned to nobody.
Written scope rationale for each location
Document why each location is tested, relied on through entity-level controls, or excluded. The rationale should tie to the location's share of significant accounts, its risk factors and any aggregate exclusion judgment. Illustrative: a small subsidiary with a single feeder interface may be excluded alone but kept in the aggregate. Review the memo against the risk assessment before the auditor asks for it.
Evidence that entity-level controls operate
Gather proof that the controls above the locations work: management review of location results, the code of conduct and policy acknowledgments, internal audit reports and self-assessment results. Confirm each review has a date, a reviewer and a documented follow-up. Auditors can only reduce location testing if they can rely on these controls, so an untested review process will not carry the scoping decision.
Access to location-level logs and change records
Confirm that IT and finance can pull access logs, privileged activity records, change tickets and job logs from every in-scope location, including systems hosted locally or by a third party. Test one sample pull per location before fieldwork. Retention periods and export formats differ by system, so a location that cannot produce logs for the full period will need a different testing approach.
Rotation plan approved by management
Draft a plan that shows which locations receive detailed testing each year, how the nature, timing and extent of tests will change, and which locations are covered by internal audit work. Management should approve it before the year starts and keep the approval on file. Ask whether the plan leaves the auditor room to vary procedures, since fixed patterns make testing predictable.
Questions about multi-location SOX ITGC testing
Does every subsidiary need its own SOX ITGC testing each year?
No. Auditors match the attention given to each location or business unit to its risk, and they may drop locations that alone or in aggregate present no reasonable possibility of material misstatement. The decision depends on how much of the financial reporting a unit produces, whether its systems feed significant accounts, and whether it runs its own applications or relies on central ones. Management and the external auditor should document the risk basis for each location selected or excluded, and the list should be revisited when the business changes, such as after an acquisition or a reorganization. Ask the auditor early which locations it expects to test so that the IT evidence for those units is ready before fieldwork begins.
Can entity-level controls alone cover a lower-risk business unit?
Sometimes. For lower-risk locations, the auditor may first assess whether testing entity-level controls gives sufficient evidence. These include controls that confirm appropriate controls exist throughout the organization, such as the control environment, internal audit activity, audit committee oversight and self-assessment programs. SEC guidance also asks management to consider these entity-level controls when identifying financial reporting risks. If they are strong and cover the unit's risks, the auditor may need less direct ITGC testing there. If they are weak or the unit runs significant automated processing, direct testing of access, change and operations controls is still likely. Confirm with the auditor what evidence it will accept before relying on this approach.
How are shared service centers tested for SOX ITGCs?
Shared service centers are usually tested where the systems and the people operating them sit, because that is where access, change and operations controls are performed. A central team that manages an ERP instance used by several subsidiaries may need to be tested once for all of them, with the results applied to each entity that depends on those controls. Management should map which entities rely on which centrally performed controls, collect evidence from the service center for the period, and confirm that local teams do not hold conflicting access. If a service center is operated by a third party, the organization still owns the controls and must obtain evidence about the provider's controls.
How does internal audit reduce the external auditor's testing?
The external auditor may coordinate with internal audit's planned work at locations and reduce the number of locations it would otherwise test. For this to help, internal audit's work must be planned, documented and performed with appropriate objectivity and competence, and the auditor must be able to evaluate it. Internal audit's test procedures, samples and results should be shared early so the external auditor can decide how much reliance is appropriate. Coordination works best when both teams agree on the locations, controls and timing in advance. Ask the auditor which internal audit documentation it will review and how it will record reliance.
Why must SOX ITGC testing change from year to year?
Auditors must vary the nature, timing and extent of testing at locations or business units from year to year. The purpose is unpredictability: if the same units are always tested the same way at the same time, staff can know which controls will be examined and adjust their behavior around them. In practice this means rotating which locations receive full testing, changing the sample sizes or procedures for some controls, and moving test dates within the period. Management should keep the rotation plan documented and be prepared to explain why a location was selected or excluded in a given year.
What must the organization do itself and what can an outside partner do?
The organization owns its controls and the conclusions about them. Management must define the locations in scope, document the risk basis, operate and evidence the ITGCs, and evaluate any deficiencies. An implementation partner can help prepare systems, access and change records, operating logs and evidence packages across locations, and can support internal audit or management testing. Only the independent external auditor performs the ICFR attestation under Section 404 for applicable companies. Ask any partner for a written scope that states which locations, systems and evidence it will prepare, and make sure management keeps the final judgments on scope and results.
How DeployOpen prepares multi-location ITGC evidence
DeployOpen helps organizations prepare the systems, controls and evidence their SOX ITGCs need across subsidiaries, regions and shared service centers. We plan and implement self-hosted open-source platforms inside your own infrastructure, and the independent auditor performs the testing and issues any opinion.
How we scope
- We agree a written scope listing the locations, entities and service centers whose systems we will prepare.
- We map in-scope applications and infrastructure at each location to the financial reporting risks they support.
- We record which locations we leave out, so the reasoning can be shown to management and the auditor.
How we build
- We configure access, change and operations controls consistently across locations while keeping local owners accountable.
- We set up logging and reporting so access reviews and change approvals can be pulled for each location separately.
- We document each control's owner, frequency and evidence source so testers can sample it at any site.
How we hand over
- We deliver control narratives, evidence checklists and a location-by-location map of systems and owners.
- We walk your internal audit and finance teams through the evidence so they can reproduce it for rotation testing.
- We document the handover in writing, so the organization retains ownership of its controls and evidence.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer if your location footprint changes.
- A quote follows from the written scope, so ask us to itemize the locations and service centers it covers.
