SOX ITGCs vs SOC 1: How Service Organisation Reports Support SOX Reliance

SOX IT general controls and SOC 1 reports are often discussed as alternatives, but a SOC 1 report is only ever evidence about someone else's controls, and it never replaces the ITGCs a company must operate and test itself. When payroll, cloud ERP hosting, claims processing or fund administration is outsourced, part of the access, change and operations control environment moves to a service organisation. The company's management and its auditor then rely on that provider's SOC 1 Type 2 report for those controls, while still testing their own ITGCs and the complementary user entity controls (CUECs) the report assumes. This guide explains how the two fit together: what each covers, how reliance works under PCAOB AS 2201 and AS 2601, how to map a SOC 1 into a SOX ITGC matrix, how to handle carve-outs, period gaps and exceptions, and where service account access falls. It is written for SOX programme leads, IT control owners, internal audit and vendor risk teams. For the basics of each, see the SOX IT General Controls (ITGC) Guide and the SOC 1 Guide.

Key takeaways

• Different subjects, one chain of reliance. SOX ITGCs are the company's own controls over its in-scope systems; a SOC 1 is a CPA's report on a provider's controls relevant to customers' financial reporting. The SOC 1 fills the part of the ITGC picture that sits outside the company.
• Only Type 2 supports reliance. PCAOB AS 2201 says a report without tests of operating effectiveness does not provide evidence that controls operated effectively, and AS 2601 says a Type 1 is not intended to support reducing control risk.
• CUECs are your ITGCs now. When a SOC 1 says its objectives are achieved only if the customer operates certain controls, AS 2201 requires the auditor to evaluate whether the company applies them. Untested CUECs are a common deficiency.
• Period and scope must line up. The report period, carved-out subservice organisations and the gap to the assessment date each need their own procedure: a bridge letter, inquiry and sometimes extra testing.
• Exceptions do not stay at the provider. A SOC 1 exception in logical access or change management has to be assessed for its effect on your automated controls and key reports, just like an internal ITGC deficiency.

The short answer

Use your own SOX ITGCs for systems you operate, and use a provider's SOC 1 Type 2 report as evidence for the control objectives the provider operates on your behalf. Then close three gaps yourself: test the CUECs the report assigns to you, cover any carved-out subservice organisations, and cover the period between the report end date and your fiscal year end. If a provider cannot supply a Type 2 report, you need another way to get evidence, because the SEC's 2007 management guidance states that management cannot issue an ICFR report with a scope limitation.

How SOC 1 reliance works inside a SOX programme

AS 2201 Appendix B says that when a service organisation's services are part of the company's information system, the auditor must understand the provider's relevant controls and the company's controls over those activities, and obtain evidence that the relevant controls operated effectively. AS 2601 sets out how a user auditor evaluates a service auditor's report: inquiring about the service auditor's professional reputation, considering whether the report is sufficient, and where it is not, discussing scope with the service auditor or arranging further procedures. AS 2601 also says the user auditor remains responsible for evaluating the evidence and should not refer to the service auditor's report as a basis for its own opinion.

For management, the SEC's 2007 interpretive guidance expects the same thinking: where a significant process is outsourced, management considers whether it needs evidence of the outsourced controls' operating effectiveness. If a provider will not supply a Type 2 report or access, management must judge whether the inability to assess is significant enough to conclude ICFR is not effective.

1. Inventory outsourced processes: for each significant account, list the services that initiate, process, record or report transactions, or host the systems that do.
2. Obtain the right report: a SOC 1 Type 2 covering the service and systems you use, the relevant locations and a period overlapping your fiscal year. Check the opinion for modifications.
3. Map control objectives to your risks: link each report objective (for example "logical access to the payroll application is restricted to authorised personnel") to the ITGC domain and the automated controls and key reports it supports.
4. Read exceptions and responses: assess each deviation for its effect on your controls, not the provider's conclusion.
5. Test your CUECs: add each relevant CUEC to your control matrix with an owner and a test.
6. Handle subservice organisations: identify any carved out and decide how you will cover them.
7. Cover the gap period: obtain a bridge letter, inquire about changes, and weigh extra evidence by risk.
8. Document conclusions: record why reliance is appropriate, signed off by the control owner and reviewed by internal audit.

Mapping a SOC 1 into the ITGC matrix

PCAOB AS 2110 lists IT risks that map onto the ITGC domains, and a well built SOC 1 has control objectives that line up with the same domains. The mapping shows which ITGCs you rely on the provider for and which remain yours.

Benchmarking depends on this mapping. AS 2201 allows an auditor to conclude that an unchanged automated application control remains effective without repeating the prior year's tests if general controls over program changes, access and computer operations are effective and tested. For a hosted application, those general controls are split between the SOC 1 and your own configuration change controls, so a weak link on either side removes the benchmarking option. See the Change Management Security guide.

Complementary user entity controls

AS 2601 says that when the service organisation's design assumes the user organisation will implement certain controls, those controls should be described in the report. AS 2201 adds that if the report says objectives might be achieved only if the company applies controls contemplated in the system design, the auditor should evaluate whether the company is applying them. In practice a SOC 1 might list 15 to 40 CUECs, and they are the most commonly missed part of reliance.

Do not treat CUECs as a contract term or a reading exercise. Give each one an owner, a frequency and a test, and include it in the SOX control matrix so management testing covers it.

Service account and integration access

The non-human identities that connect your environment to a provider sit across the boundary and are often covered by neither side. A SOC 1 typically covers provider personnel and provider system accounts; the API credentials, SFTP accounts, integration users and robotic process automation identities that your teams create to move data into and out of the service are yours. They usually bypass the joiner and leaver process, are excluded from MFA, and frequently hold broad write access to journals or master data.

• Inventory: list every integration account and key for each in-scope service, with an owner and the data it can change.
• Access review: include them in user access reviews with the same completeness and accuracy evidence as human accounts. See How to Run an Access Review for Service Accounts.
• Change and segregation: confirm that an integration account cannot both post and approve, and that its permissions cannot be changed by the developer who uses it. See the Segregation of Duties Guide.
• Credential handling: rotation, storage in a secrets manager and revocation on staff departure. See the Service Account Security Guide.

Subservice organisations, period gaps and bridge letters

Carve-out versus inclusive: a service organisation that relies on another provider (for example a payroll platform hosted on a cloud infrastructure provider) presents that subservice organisation either by the inclusive method, where its controls are included and tested, or by the carve-out method, where they are excluded and the report lists the controls the provider expects the subservice organisation to perform. Under carve-out, obtain the subservice organisation's own SOC 1 or equivalent, check how your provider monitors it, and map any complementary subservice organisation controls.

Period gap: AS 2201 asks the auditor to assess the time period covered by tests and its relation to the as-of date of management's assessment, and when a significant period has elapsed, to inquire whether management has identified changes in the provider's controls and to evaluate them. AS 2601 notes that the longer the time since a test was performed, the less support it gives. A bridge letter (also called a gap letter) from the provider is a management self-attestation, not an auditor's examination. Microsoft's documentation says this explicitly for its own bridge letters, and AWS describes its monthly SOC Continued Operations Letter covering the period from the last report to the letter date.

The three-month threshold above is a common working rule, not a standard; agree the threshold with your external auditor.

Evaluating SOC 1 exceptions as ITGC deficiencies

A provider's exception is not automatically your deficiency, but you must assess it as if it might be. Ask: does the exception relate to a control objective you rely on; does it affect the integrity of an automated control or key report in your scope; did the provider's management response include remediation with evidence; do you have a compensating control (for example a detective reconciliation of the output) that would catch the consequence; and did the access or change actually lead to misuse. Record the analysis and carry any unresolved item into your deficiency evaluation alongside internal ITGC findings. See the Internal Audit vs External Audit guide for who tests and concludes what.

Decision criteria

• Rely on the SOC 1 when: the report is Type 2, covers the specific service, systems and locations you use, overlaps your fiscal year substantially, has an unmodified opinion or exceptions that do not touch your objectives, and you can evidence the CUECs.
• Add your own procedures when: there is a long gap to year end, a carve-out of a significant subservice organisation, exceptions in access or change, or a change of system during the year.
• Rely on your own controls instead when: no Type 2 exists, or the provider's scope does not match your use. Strong detective controls over the service output (reconciliations, reasonableness reviews, independent recalculation) can sometimes support ICFR without provider testing; agree this with your auditor early.
• Smaller issuers: non-accelerated filers exempt from 404(b) still need management's assessment, so the same reliance logic applies, with less auditor testing.
• Large groups: centralise SOC 1 review in one team with a standard template, so CUEC ownership is consistent across subsidiaries using the same provider.

Worked scenario

A US-listed manufacturer with a 31 December year end moves payroll to a cloud payroll provider in March. The provider issues a SOC 1 Type 2 for 1 October to 30 September, carving out its infrastructure host.

1. Scope: payroll expense and accrued payroll are significant accounts. The SOX team maps provider objectives for access, change and operations to the payroll automated calculations and the payroll register key report.
2. Period: the report covers nine months of the company's use. The team obtains the provider's bridge letter to 31 December, inquires about changes, and keeps its monthly payroll-to-ledger reconciliation as a key control.
3. Carve-out: the team obtains the infrastructure host's SOC 1 and confirms the payroll provider's monitoring of it is described and tested.
4. Exceptions: one exception reports two provider engineers retaining production database access after role change. The provider's response shows removal and a review of activity logs with no unauthorised changes. Combined with the company's reconciliation, management concludes no deficiency at the company.
5. CUECs: of 22 CUECs, 18 are relevant. Testing finds that the HR integration account used to load joiners has never been included in access reviews and is shared by two analysts. The company records a deficiency in its own logical access ITGC, assigns individual accounts, moves the credential into its secrets manager and adds the account to quarterly reviews.

Detection and measurement

• SOC 1 coverage: percentage of in-scope outsourced services with a current Type 2 report reviewed and signed off before the year-end assessment.
• CUEC coverage: percentage of relevant CUECs mapped to an owned, tested control in the SOX matrix.
• Gap length: median months between report end and fiscal year end across providers.
• Exception follow-through: provider exceptions affecting relied-on objectives with a documented impact assessment.
• Integration identity coverage: percentage of integration accounts and keys for in-scope services included in access reviews.

Common failure patterns

• Relying on a report with exceptions without assessing them: the review stops at the opinion page while a logical access exception sits in section four.
• Ignoring CUECs: the CUEC list is filed with the contract and never mapped to owners, so the company relies on a control system it only half operates.
• Accepting a Type 1 or the wrong report: a SOC 2 or a Type 1 is accepted for ICFR reliance, which AS 2601 and AS 2201 say does not evidence operating effectiveness for this purpose.
• Missing the carve-out: the infrastructure host carved out of the report is never covered.
• Treating a bridge letter as audit evidence: it is the provider's own assertion and needs inquiry and risk-based support.
• Forgetting integration accounts: API keys and SFTP users connecting to the provider fall outside both the provider's report and the company's access reviews.

Framework mapping

Practitioner checklist

• Inventory every outsourced service supporting a significant account and the report type held for each.
• Request SOC 1 Type 2 reports early and confirm service, system, location and period coverage.
• Map each relied-on control objective to the ITGC domain and the automated controls and key reports it supports.
• Assess every exception and management response for effect on your controls, and record the conclusion.
• Add each relevant CUEC to the SOX control matrix with an owner, frequency and test.
• Cover carved-out subservice organisations with their own reports and your provider's monitoring.
• Obtain bridge letters, inquire about changes and agree a gap threshold with your external auditor.
• Include integration accounts, API keys and SFTP users for each service in access reviews.

Standards and references

• PCAOB: AS 2201, An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements
• PCAOB: AS 2601, Consideration of an Entity's Use of a Service Organization
• SEC: Release 33-8810, Management's Report on Internal Control Over Financial Reporting (interpretive guidance)
• PCAOB: AS 2110, Identifying and Assessing Risks of Material Misstatement
• AICPA and CIMA: SOC 1, SOC for Service Organizations, ICFR
• Microsoft Learn: System and Organization Controls (SOC) 1 Type 2
• AWS: SOC FAQs

Related NHI Mgmt Group resources: Audit, Assurance and Compliance Guide, Third-Party Risk Management Guide, SOC 2 Guide, AI Agents and SOX Controls. This guide summarises SOX and service organisation reporting requirements and is not legal or audit advice.