Can a SOC 2 report support SOX ITGC reliance

Can a SOC 2 report support SOX ITGC reliance in place of a SOC 1?

A SOC 2 report can inform your SOX reliance on a provider, but it generally does not replace a SOC 1 Type 2 report for the ICFR-relevant controls. A SOC 1 examines controls at a service organization that are likely to be relevant to user entities' internal control over financial reporting, and it is written for user entities and their auditors. A SOC 2 reports on controls relevant to security, availability, processing integrity, confidentiality or privacy, measured against the trust services criteria, and its use is generally restricted. Whether the report helps you depends on what it covers and on how you close the gap. Your organization owns its controls and the conclusion about them. An implementation partner can help you map the provider's SOC 2 controls to your financial reporting risks and prepare the evidence, but only your external auditor decides what it will rely upon.

Start by reading the provider's SOC 2 against your financial systems and reporting risks. Confirm the in-scope system description covers the application, hosting, interfaces and data flows that feed your ledgers, and identify which access, change and operations criteria touch those flows. Then ask whether the provider will issue a SOC 1 Type 2 covering the same period. If it will not, a SOC 2 leaves gaps in the financial-reporting control objectives, such as the completeness and accuracy of processing and the authorization of changes to financially significant configurations. Those gaps are the ones you must test yourself, for example by reconciling provider output to source records and reviewing the provider's exception reports, and you should raise them with your auditor before year end rather than at fieldwork.

Confirm two points with your auditor early. First, whether the SOC 2 report's period and scope are acceptable for reliance, since a Type 2 report covering a period that does not overlap your fiscal year needs additional bridging evidence. Second, whether the service auditor is independent of your own audit firm, because SEC staff guidance allows reliance on a Type 2 report from a firm that also audits you but not where your own audit firm was engaged to prepare that report. Ask the provider for its SOC 2 Type 2 report, its complementary user entity controls section, and any bridge letter it can supply. The AICPA's SOC 1 overview explains the intended audience for each report type, which helps you frame the request to the provider.

What a SOC 1 and a SOC 2 each cover

SOC 1 and SOC 2 are both examinations of a service organization, but they answer different questions for different readers. The cards below separate their purpose, intended users, criteria and report types so you can judge which one, if either, reaches the controls your ICFR depends on.

SOC 1 purpose and users

A SOC 1 examines controls at a service organization that are likely to be relevant to its user entities' internal control over financial reporting. It is intended for those user entities and their auditors. When a provider processes transactions or data that feed your financial statements, this is the report built for your ICFR assessment. Check whether the provider's system description covers the processes you rely on.

SOC 2 purpose and criteria

A SOC 2 examines controls relevant to security, availability, processing integrity, confidentiality or privacy, measured against the trust services criteria. Its subject matter is the service itself, not the financial reporting impact of that service. A SOC 2 can describe strong access and change controls, yet still say nothing about whether a specific financial output was complete and accurate.

Intended users and restricted use

Use of a SOC 1 report is restricted to the service organization's management, its user entities and their user auditors. SOC 2 use is generally restricted as well. Confirm with the provider that you are an authorized recipient before you place either report in your SOX evidence file, and confirm what the report permits you to share with your own auditor.

Type 1 and Type 2 reports

Both SOC 1 and SOC 2 come as Type 1 or Type 2 reports. A Type 1 reports on the design of controls at a point in time. A Type 2 also covers operating effectiveness over a period, which is the element an external auditor needs to rely on controls during the fiscal year. Check the period covered and whether it matches your assessment date.

Where the two reports overlap

Access and change management controls appear in both report types, so a SOC 2 may describe them in detail. The difference lies in the objective. The SOC 1 frames those controls around the financial data they protect, while the SOC 2 frames them around security or availability commitments. Map each control the provider describes to a specific financial reporting risk before you treat it as evidence.

Gaps you still own

Neither report substitutes for your own controls over the provider's output. Management must still confirm the complementary user entity controls the report assumes, such as reviewing user access to the financial application and reconciling processed totals to source records. Document those controls as your own, with evidence, in your ITGC program.

What the PCAOB asks of a service auditor's report

When the external auditor relies on a provider's SOC report, it does not simply accept the report as proof. Under PCAOB AS 2201, paragraph B21, the auditor reviews the report on three points: the period it covers measured against the as-of date of the company's assessment, the scope of the services and the controls the service auditor tested, and the test results and the opinion the service auditor expressed. For a SOC 2 report used as a SOX ITGC input, that means checking whether the access, change and operations criteria that matter to your financial systems fall inside scope, whether the window overlaps your fiscal year end, and whether any exceptions were raised and how they were resolved.

Paragraph B20 contains a note that matters most for SOC 2 reliance. A service auditor's report that does not include tests of controls, the results of those tests and an opinion on operating effectiveness does not provide evidence that the controls operated. A bridge letter, a description of controls or a report that only covers design does not close that gap. Management should confirm with the provider whether the report is a Type 1 or Type 2 report and whether the operating effectiveness testing covers the specific controls the company depends on, rather than assuming the presence of a SOC 2 report settles the question.

Paragraph B20 also lists the three routes for obtaining evidence about controls at a service organization. The first is a service auditor's report that includes tests of operating effectiveness, which is the route a SOC 2 Type 2 can support when its scope fits. The second is testing the company's own controls over the provider's output, such as reconciling processed transactions back to source documents. The third is testing performed at the service organization itself. Most companies combine these routes, and the choice depends on which controls the SOC 2 report does not cover, so the gaps identified during the auditor's review determine where the company must build its own evidence.

How companies close the gap when the report is SOC 2

Some companies start with the provider's SOC 2 Type 2 report and map the trust services criteria it tests to the financial reporting controls that depend on the provider. The mapping is the company's judgment, not the provider's or the service auditor's, and the external auditor must accept it. Only criteria that bear on the completeness, accuracy and authorization of financially significant data are relevant, so a security criterion alone rarely covers a revenue or payroll control.

Criteria mapping: Document which criteria address access, change management and processing that affect each financial control, and explain any gap.
Period coverage: Confirm the Type 2 period spans the assessment period and that a bridge letter covers any remaining time.
Complementary user entity controls: List the controls the report assumes you perform, and evidence that you perform them.
Exceptions and scope: Review every exception and whether the systems and locations behind your financial data fall inside the report's scope.
Auditor acceptance: Agree the mapping with your external auditor before year end, not during fieldwork.

Check whether the report's scope names the specific systems that process your financial data, and whether the mapping shows which criteria you rely on for each control.

Which service auditor and reports the SEC staff allows

The SEC staff FAQ on management's ICFR report sets a clear rule for who may have written the provider's report. Management may rely on a Type 2 service auditor's report even when the same accounting firm audits both the company and the provider. The line is drawn at the registrant's own audit firm: reliance is not available if that firm was engaged to prepare the service organization's report. A SOC 2 report from a provider's independent CPA firm can therefore support ITGC reliance, but a report prepared by your own external auditor cannot be used as the basis for management's assessment of the provider's controls.

Standing matters because the report is only as useful as the examiner's independence and competence. Before accepting a SOC 2 for ITGC use, confirm who engaged the service auditor and who paid for the examination, and check that the firm is not your external auditor. Ask the provider to name the examining firm and confirm it holds a license to practice. Then check whether the report is a Type 2 covering a period, not a Type 1 point-in-time snapshot, since a Type 1 report does not test operating effectiveness and so cannot support ITGC reliance on its own. Also confirm that the report's restricted-use terms allow your management and your auditor to receive it.

Record these checks in your ITGC file so the auditor can see the reliance decision and its basis. Keep a note of the engagement letter or provider confirmation that identifies the service auditor, the report type and period, and the reliance conclusion. Where the examining firm's independence is unclear, treat the report as unusable until management resolves the question, and ask your external auditor early whether it agrees with the position. Your legal or procurement team should confirm the restricted-use language and the provider's consent to share the report with your auditor.

How to decide whether a SOC 2 is enough

This sequence tests whether a provider's SOC 2 report can support SOX ITGC reliance for a specific fiscal year, and it records where the report falls short so the gaps can be closed with the external auditor before testing begins.

Inventory the provider's role in financial reporting
Finance, internal audit and IT list every provider that hosts, processes, calculates or stores data feeding financial statements, including cloud infrastructure, SaaS applications and managed service operations. For each one, record the systems, the financial data flows and the ICFR controls that depend on the provider's output. The step closes when each provider has a named owner and a short description of its financial reporting role. Providers with no financial role drop out of scope here, with the reason written down.
Obtain the SOC 2 and any SOC 1 report
Request the provider's most recent SOC 2 report and, where one exists, its SOC 1 report, along with any bridge letters and the list of complementary user entity controls each report assumes. Confirm that the report is a Type 2 report, because a Type 1 report describes design at a point in time and does not show operating effectiveness. The step closes when the reports and the complementary user entity control lists are in the file. If the provider offers only a SOC 2 Type 1 or no report, log that as an input to the gap analysis.
Check period and scope against the fiscal year end
Compare the period covered by each report with the company's fiscal year and the as-of date the auditor will use. Confirm that the systems, locations and services named in the report match the provider services the company actually uses, including any subservice organizations carved out. Note any period gap and whether a bridge letter covers it. The step closes with a written conclusion for each provider stating whether the coverage period and scope fit the fiscal year or what must be added.
Map trust criteria to ICFR and ITGC areas
Map the relevant trust services criteria tested in the SOC 2 to the company's ICFR controls and to the four ITGC areas: access to programs and data, program changes, program development and computer operations. Many SOC 2 criteria cover security, availability or confidentiality, which may not address the financial reporting risk the company cares about. The output is a matrix showing which provider controls cover which ICFR risks, with blank cells marked as gaps. Areas that depend on company-owned configuration remain the company's responsibility.
Identify gaps and compensating controls
For each uncovered ICFR risk, decide how the company will obtain evidence: a test of its own review control over the provider's output, such as reconciling reports to source documents, a request for additional provider testing, or a different evidence source. Review the exceptions and the opinion in the report, since an exception in a control that matters to financial reporting changes how much reliance is reasonable. The step closes with a gap register listing each gap, its owner and the evidence planned to close it.
Agree the test approach with the external auditor
Share the mapping and gap register with the external auditor before fieldwork and confirm which provider controls the auditor will rely on, which company controls will be tested directly and how the auditor will assess the provider's report under its standard for service auditor reports. Ask the auditor whether the SOC 2 is acceptable for the planned reliance, given that the report was prepared by the service auditor and not by the company's own audit firm. The step closes with written confirmation of the agreed approach, or a list of changes the auditor requires.
Document the reliance decision
Record the final decision for each provider in a reliance memo that states the reports reviewed, the period and scope conclusions, the gaps, the compensating or direct controls, the auditor's agreed approach and the date of review. Assign an owner to the memo and set a review point for when the provider issues its next report. The step closes when the memo is approved by the control owner and filed with the ICFR documentation. Ask the external auditor to confirm which parts of the memo they will need to see at year end.

Gaps that stop a SOC 2 from supporting reliance

A SOC 2 report can support SOX reliance only if it covers the right systems, the right period and the right controls, and if the company has done its own part. Each gap below is a point where an external auditor is likely to stop relying on the report, and each has a specific response the company owns.

No operating effectiveness opinion

A SOC 2 report that describes controls without tests of their operating effectiveness, results and an opinion on that testing does not show the controls worked during the period. Auditors look for a Type 2 report with exceptions disclosed and an opinion. If the provider only has a Type 1 report, reliance usually fails. The company should ask for the Type 2 report, read the test results table and treat any missing test as a gap in its own assessment.

Coverage period that misses the as-of date

The report period must overlap the date the company assesses its controls, and the gap between the period end and that date must be bridged. Illustrative example: a report covering the twelve months ending in March does not cover a December fiscal year end without additional support. The company should map the report period to its assessment date, request a bridge letter from the provider, and document how it covers any remaining time.

Scope that omits the financial application

A SOC 2 examination covers the systems the provider named in its system description. If the general ledger, billing module, payroll engine or the database and hosting layer beneath it is not in scope, the report says nothing about those components. The company should compare the system description against its own list of financially significant applications, databases and infrastructure, and ask the provider to add scope or obtain a separate report for anything missing.

Complementary user entity controls never performed

SOC 2 reports list complementary user entity controls, which are controls the provider assumes the customer runs, such as reviewing user access lists or approving configuration changes. Auditors will ask whether the company performed them during the period. If the company did not, the provider's controls may not operate as the report describes for that company. The company should build each listed control into its own ITGC testing and keep dated evidence that it ran.

Service auditor not acceptable to the external auditor

The SEC staff FAQ says management may rely on a Type 2 service auditor's report even if the same firm audits both companies, but not if the registrant's own audit firm prepared that report. External auditors also assess the service auditor's standing and competence. The company should confirm early with its external auditor which firms are acceptable, confirm the provider's auditor is a licensed independent CPA firm, and avoid relying on a report prepared by its own audit firm.

Questions buyers ask about SOC 2 and SOX reliance

Can a SOC 2 report replace a SOC 1 report for SOX?

No, not by itself. A SOC 1 report is written for user entities' internal control over financial reporting, so it is the report built for SOX reliance. A SOC 2 report covers controls relevant to security, availability, processing integrity, confidentiality or privacy under the trust services criteria, and it is generally restricted in use. Some companies review a provider's SOC 2 to learn about its security environment, and that can inform the risk assessment. But the external auditor usually needs control testing tied to financial reporting risks, and a SOC 2 only supports that if its scope and tested controls match the financially significant processes. Treat it as supporting evidence, then confirm with your auditor whether it closes the gap or whether you need a SOC 1 or additional procedures.

What must our company still do itself when a provider's SOC 2 is in hand?

Management keeps ownership of its own controls and of the evidence that they operate. A provider's report describes the provider's controls, and it usually lists complementary user entity controls that the company must run. Typical examples include reviewing the provider's exceptions, checking that its scope covers the systems and services your financial processes use, and performing your own reconciliations or reviews of the provider's output. Access to your tenant, configuration, interfaces and change approvals also stays with you. Ask your auditor which of these they expect to see documented, and map each complementary control to an owner, a frequency and an artifact before the testing period begins.

Does the external auditor have to accept a SOC 2 report for SOX?

The external auditor makes that call, and it is not a decision management can make alone. Under PCAOB AS 2201, the auditor evaluates a service auditor's report by its period relative to the as-of date, its scope and the controls tested, and its test results and opinion. A report without tests of operating effectiveness does not provide evidence that controls operated. The SEC staff FAQ also notes that management may rely on a Type 2 service auditor's report even when the same firm audits both companies, but not when the registrant's own audit firm prepared that report. Agree the reliance approach with your auditor early, in writing, so the team knows which report and which additional procedures will be accepted.

How do time gaps between the report period and year end get handled?

A report covers a fixed period, and the auditor compares that period with the as-of date of the assessment. If the coverage ends months before year end, or the provider has changed its environment since the period closed, the auditor usually asks for additional evidence. Common approaches include a bridge letter from the provider covering the gap, your own testing of the controls over the provider's output for the uncovered months, and confirmation that no significant changes occurred. The exact expectation depends on the auditor and on how much the financial process relies on the provider. Ask your auditor how they plan to handle any gap before year end, not after fieldwork starts.

Can an implementation partner prepare the control mapping and evidence?

Yes, an implementation partner can help prepare the work, but it cannot own the controls or issue the conclusion. A partner can map the provider's SOC 2 criteria to your financial systems, identify which complementary user entity controls you must run, set up the evidence collection, and document how each control operates. DeployOpen prepares systems, controls and evidence for assessments in the client's own infrastructure, and it does not issue audit reports, attestations or certifications. Management still evaluates ICFR, and the external auditor decides whether the reliance is sufficient. Scope the work in writing so the deliverables are clear: the mapping, the evidence package, and the procedures your auditor has agreed to accept.

What changes if the provider has no usable SOC 1 or SOC 2 report?

The company must find other evidence, and the cost and effort usually rise. Without a service auditor's report that includes tests of operating effectiveness, PCAOB AS 2201 directs the company toward other sources of evidence: tests of its own controls over the provider's work, such as reconciling output to source documents, or tests performed at the service organization. Management should first decide whether the provider's output is material to financial reporting, then document how the company reviews it. Options can include agreed-upon procedures or direct testing at the provider, if the contract allows it. Start these discussions early, because a provider that has never been asked for a report may need contract changes before it can produce one.

How DeployOpen prepares the evidence around a provider report

DeployOpen helps teams prepare the evidence they need when a SOC 2 report is used in place of, or alongside, a SOC 1 for SOX ITGC reliance. We prepare systems, controls and documentation inside your own environment, while the independent auditor and the provider's service auditor issue the reports and opinions.

How we scope

We agree the written scope with you before work starts, listing the provider, systems and periods covered.
We map which provider report sections address your financially significant applications and interfaces.
We identify the complementary user entity controls the provider report assumes you run.

How we build

We set up your own controls over provider output, such as reconciliations of reports to source records.
We document access, change and monitoring procedures you still own for provider-hosted systems.
We configure self-hosted open-source tooling to produce logs and records that show those controls operating.

How we hand over

We deliver control narratives, evidence libraries and a gap list that compares the report period to your as-of date.
We walk your finance, IT and internal audit teams through the evidence so they can answer auditor questions.
We record which items still need a bridge letter, additional procedures or a provider request.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends.
We can refresh evidence each reporting cycle when a new provider report or bridge letter arrives.
Final conclusions on reliance remain with your management and your independent auditor, not with DeployOpen.

Can a SOC 2 report support SOX ITGC reliance