SOC 1 reports for IT service providers: SOX ITGC evidence

How a SOC 1 report from an IT provider fits into your SOX ITGC evidence

If your general ledger, payroll or financial close runs on a provider's platform, that provider's SOC 1 report can support your ICFR evidence, but it does not transfer management's responsibility for the controls that touch financial reporting. Management still has to show that the provider's controls operate, that they cover the period the company relies on, and that the company's own controls over data sent to and received from the provider work. The PCAOB's AS 2201 makes the point directly: when a service organization's services are part of the company's ICFR, the auditor includes the provider's activities when deciding what evidence is needed (paragraph B18). The SEC staff FAQ on management's ICFR report adds that management may rely on a service auditor's Type 2 report even when its year-end differs from the company's, but remains responsible for controls over information flowing to and from the provider.

The risk is a blind spot. A provider can run job scheduling, access administration, backups or change deployment for a financially significant application, and nobody on your side reads its report. Under AS 2201 paragraph B21, the auditor evaluates the service auditor's report by the period it covers relative to your as-of date, the scope and controls tested, and the results and opinion. Those three checks are where the work is hard. A Type 2 report may cover a window that ends months before your fiscal year end, leaving a bridge period with no provider evidence. The report may exclude a sub-service organization such as a hosting facility. And the report often assumes controls at the user company, which AS 2201 paragraph B22 requires the auditor to test whether you apply. Confirm the report period, the carve-out providers and each complementary user entity control with your provider and your auditor before the fiscal year starts.

Start by listing every provider that touches an IT-dependent control, then request the current SOC 1 report, its bridge letter or equivalent gap statement, and the list of complementary user entity controls. Map each complementary control to an owner, a recurring evidence artifact and a test date, such as an access review of provider administrator accounts or a reconciliation of interface files against the provider's output. The *SOC 1* framework is an AICPA & CIMA examination of controls at a service organization that are likely relevant to user entities' internal control over financial reporting, so the report is a starting point for your evaluation, not a substitute for it. Where the period or scope falls short, decide early whether to request additional provider testing, perform your own procedures or document a compensating control.

Which providers and processes bring SOC 1 reliance into SOX scope

Not every vendor touching the close belongs in SOX scope. The providers that matter are those whose services form part of the company's internal control over financial reporting, and the scoping levers below help separate them from vendors that only support operations. Each decision should be documented before the auditor asks for a SOC 1 report.

Providers that host the ledger

Hosted general ledger, ERP and consolidation platforms are the clearest candidates for SOC 1 reliance, because the provider runs the system where balances are recorded and adjusted. Confirm which modules, environments and databases the provider operates, and whether your own administrators keep any direct database or application access. Those retained responsibilities belong in your ITGC scope even when the provider's report covers the platform.

Payroll and billing processors

Payroll and billing providers calculate, record or transmit amounts that flow directly into the financial statements. Their outputs often feed journal entries, accruals and receivables, so auditors commonly treat them as part of ICFR. Check whether the provider initiates transactions, computes balances or only delivers files, because that distinction drives how much reliance the audit team will place on the report.

Data feeds and interfaces

Feeds from banks, card processors, payment networks and sub-ledgers move financial data into your systems without manual keying. A provider that transforms, filters or reconciles that data affects completeness and accuracy of reported amounts. Map each feed to the account balances it populates, and confirm whether the feed provider's controls cover transmission, mapping and error handling, or only file availability.

Managed infrastructure under financial applications

Managed hosting, database administration and backup services can sit beneath financial applications without touching transactions directly. Their controls over access, change and recovery still determine whether the application data is complete and unaltered. Ask whether the infrastructure provider's SOC 1 scope includes the physical and logical layers you rely on, and whether any administrative access to the application environment is retained by you.

Operational-only vendors

Some vendors support efficiency without storing, processing or transmitting financial data, such as collaboration tools or general productivity software. SEC guidance says management need not evaluate ITGCs that only affect operational efficiency, so these providers may fall outside SOX scope. Document the rationale in the scoping memo, and revisit it if a vendor's role expands into financial data handling.

Type 1 versus Type 2 report coverage

A Type 1 report describes controls at a point in time, while a Type 2 report tests whether those controls operated over a period. Auditors generally need evidence of operating effectiveness across the fiscal year, so a Type 1 report alone rarely covers the full period. Confirm the report type, the audit period and the controls tested, then compare the period against your fiscal year to identify any gap that needs bridge letters or additional procedures.

Three ways to rely on a provider's controls

Under this option, management uses a service auditor's Type 2 SOC 1 report as the main evidence that the provider's controls operated during the period. The external auditor evaluates the report under AS 2201 paragraph B21, checking the period it covers relative to your as-of date, the scope and controls tested, and the results and opinion. The SEC staff FAQ confirms management may rely on a Type 2 report even when the provider's year-end differs, but management stays responsible for controls over the information flowing to and from the provider.

Period coverage: Confirm the report's examination window overlaps your fiscal year, and identify any bridge letter needed for the remaining months.
Scope match: Check that the systems, locations and services in the report include the ones that feed your financial statements.
Complementary user entity controls: Map each control the report assumes you perform, and evidence that your team operates it (AS 2201 paragraph B22).
Exceptions: Read every tested exception and document whether it affects your reliance.
Who performs the work: Your team reads and files the report, and the external auditor evaluates it.

Ask the provider to confirm the exact report scope, period and carve-out services in writing before you rely on it.

How the external auditor evaluates a SOC 1 report

This table walks through the steps an external auditor takes when a service provider's SOC 1 report supports the company's ICFR, from the first read of the report to the gaps that commonly surface. Read each row as a question the auditor will ask and the evidence the company should have ready before fieldwork starts.

Auditor step	What the auditor checks	Common finding or gap
Obtain the service auditor's report	Confirms the company holds the provider's SOC 1 report and the service auditor's opinion, and that the report covers the services that feed financial reporting (AS 2201, paragraph B21).	Report requested only after fieldwork begins, or the company holds a summary letter instead of the full report.
Check the period covered against the as-of date	Compares the report period with the company's fiscal year end and the date ICFR is evaluated, considering how far the report period falls from that date (AS 2201, paragraph B21).	Report period ends months before the as-of date with no bridge letter or other evidence for the gap.
Check scope and controls tested	Confirms the systems, processes, locations and control objectives in the report match the financial processes the company relies on.	Relevant application or hosting environment is outside the report scope, or a product line the company uses is not listed.
Review results and exceptions	Reads the tested controls, the service auditor's test results and any exceptions, then assesses whether exceptions affect the company's reliance (AS 2201, paragraph B21).	Exceptions noted without a documented assessment of their effect on the company's own controls.
Evaluate complementary user entity controls	Identifies controls the report assumes the company performs and tests whether the company actually operates them (AS 2201, paragraph B22).	Complementary user entity controls are listed in the report but no owner, procedure or evidence exists inside the company.
Assess carve-out of sub-service organizations	Determines whether the provider's own subservice providers are carved out of the report and, if so, whether those providers have their own assurance.	Hosting or infrastructure provider is carved out and no assurance over that provider has been obtained.
Confirm information flows to and from the provider	Tests whether data sent to and received from the provider is complete and accurate, since the company keeps responsibility for it under SEC staff guidance.	Interfaces, file transfers or reconciliations to the provider are not reviewed by the company, so gaps go unnoticed.
Include the provider in the audit evidence plan	Decides how much reliance to place on the provider's controls and what additional procedures are needed (AS 2201, paragraph B18).	Provider activities left out of the audit plan, which forces late requests for evidence near year end.

Steps to build SOC 1 reliance into your ITGC program

This sequence turns a list of outsourced IT services into a documented reliance position: each provider's SOC 1 report is read against its coverage period, the controls the report assumes you operate are assigned owners and evidence, and gaps are closed before the annual review. The result is a file the external auditor can test without rebuilding your provider picture from scratch.

Inventory providers in the financial reporting process
Start with the applications, data flows and reports that feed the financial statements, then list every hosted, cloud, SaaS or managed service that runs, stores, transmits or supports them. Include providers that only touch the data path, such as payroll processors, hosting companies, data center operators and managed backup services. Management owns this list and confirms it with finance and IT. The output is a provider inventory that names each service, the financial process it supports and the internal owner, and it is ready for review when the list is signed off.
Obtain and read each SOC 1 report
For each provider in the inventory, request the most recent SOC 1 report from the provider and confirm with the service auditor that it is a genuine report from an independent CPA firm. Read the description of the system, the list of controls, the testing performed and the opinion. Note whether the report is a Type 1 (design at a point in time) or a Type 2 (design and operating effectiveness over a period), because only Type 2 reports support reliance on operating effectiveness. The output is a short review memo for each report that records scope, period, exceptions and the opinion.
Extract complementary user entity controls into a register
Within each report, find the complementary user entity controls, which are the controls the service auditor assumes your organization operates for the service to work. Typical examples include reviewing provider access requests, approving changes to user access and reconciling outputs. Copy each one into a single register with the provider name, the control description and the report section it came from. The output is a complementary user entity controls register that covers every provider in scope and can be compared against your own control inventory.
Assign owners and evidence for each control
For every entry in the register, name an internal owner who has the authority and knowledge to perform the control, and define the evidence that will show it operated, such as a signed access review, a ticket, a reconciliation or a report sign-off. Check each entry against the controls you already run under your ITGC program, and mark any that are not yet in place. The output is a register where every line has an owner, a defined evidence type and a status, so that the auditor can trace each assumed control to a working process.
Document the coverage period and bridge gaps
Compare each report's coverage period with your fiscal year end, because a report that ends before the year end leaves a gap. Document the period each report covers and any portion of your fiscal year it does not, then define how that gap will be bridged, for example through a bridge letter from the provider, additional testing of your complementary controls or an interim review of provider exceptions. Confirm the bridge approach with your external auditor before relying on it. The output is a coverage analysis that shows, for each provider, which periods are covered, which are bridged and who is responsible for the bridge evidence.
Connect reliance to ICFR testing and management review
Map each provider's reliance position to the financial reporting controls it supports, and record which provider exceptions or qualifications could affect those controls. Feed the results into management's ICFR evaluation and into the walkthroughs and testing your auditor performs, so that the provider evidence is considered alongside your own controls. Where an exception affects a financial control, evaluate it with the same rigor as an internal control deficiency. The output is a linked record showing which financial controls depend on which provider reports and how exceptions were assessed.
Set an annual review of reports and register
Calendar a yearly review that refreshes the provider inventory, requests each new SOC 1 report as it is issued, updates the complementary controls register and confirms that owners still perform their controls. Record changes in providers, services, reports and contacts, and retire entries for providers no longer in the financial process. The output is a dated review record signed by the control owner that shows the reliance file was current at the fiscal year end.

Mapping complementary user entity controls to your own controls

Complementary user entity controls (CUECs) are the controls a service auditor's SOC 1 report assumes the customer company performs itself. The provider's report only holds if those controls operate on the customer side, so the company must identify each one, assign it to an internal owner and show recurring evidence that it runs. Under PCAOB AS 2201 (paragraph B22), the external auditor evaluates whether the company applies the controls a service auditor's report assumes, which means the mapping is tested, not just documented. Typical CUECs cover who may request user access to the provider's platform, who approves changes to job schedules or interfaces the provider runs, and who checks that provider output agrees with the general ledger.

Build the mapping as a table with one row per CUEC, listing the provider report reference, the internal control ID, the control owner, the frequency and the evidence retained. Examples of evidence include a quarterly access review of provider portal accounts with sign-off, a log of provider change notices reviewed and acknowledged by a named person, and a monthly reconciliation of provider-generated totals to the ledger with the reconciler's and reviewer's initials. Illustratively, if the report lists a CUEC about approving user access requests, the internal row should name the identity administrator as owner and point to the access review file. Confirm with the provider's report exactly which controls it assumes at the user entity, because some reports state them in a section separate from the tested controls.

This mapping is where many SOC 1 reliance efforts fail. Teams file the report, record that the provider is SOC 1 compliant, and never link the assumed controls to anything the company actually performs. The gap usually surfaces during walkthroughs, when the auditor asks who reviews provider change notices and the answer is that nobody is named. Before the year end, check that every CUEC has an owner who can explain the control, that the evidence covers the whole period being relied on, and that any CUEC the company does not perform is escalated as a gap, since the company then remains responsible for the risk the provider was supposed to address.

Evidence that shows provider oversight is working

Auditors rarely accept a provider's SOC 1 report on its own. They look for a file of records showing that management read the report, mapped the controls it expects to run itself, and watched the provider between report dates. The six artifacts below are what that file usually contains, and each needs a named owner and a refresh routine.

Current SOC 1 report on file

Keep the provider's most recent SOC 1 report, with its period, scope, controls tested and opinion, in a location the audit team can retrieve. Record who reviewed it and when. Check that the services your financial processes use appear in the system description and that the report covers the period your fiscal year needs. Check the calendar too: a report that ends months before your as-of date leaves a gap you must document. Refresh it on each new report release and confirm the report still matches the services you purchase.

Complementary user entity control register

Complementary user entity controls, often called CUECs, are controls the provider's report assumes you run. Typical examples include reviewing access lists for provider-hosted applications and approving changes you request. Maintain a register that lists each CUEC, the internal control that satisfies it, the owner, and the evidence produced. Auditors test whether you actually apply these controls, so an unmapped CUEC is a gap even when the provider is clean. Review the register whenever the report or your service scope changes.

Exception and carve-out review log

Read every exception the service auditor noted and every carved-out subservice organization, such as a hosting or data center provider covered only by its own report. For each exception, record whether it affects a control your financial processes depend on, what compensating action you took, and whether the provider has a remediation date. For carve-outs, obtain the subservice provider's report or confirm the provider's monitoring of it. Update the log at each new report, since exceptions often recur or change in severity.

Bridge letter or gap analysis

When the SOC 1 period ends before your fiscal year end, request a bridge letter from the provider covering the remaining months. The letter should state whether controls changed, whether any exceptions or incidents occurred, and the period it covers. Where no bridge letter is available, prepare a gap analysis that documents the uncovered months and your own procedures to fill them, such as reviewing provider change logs. Ask for these documents in your contract renewal so they are not an afterthought at year end.

Provider change and incident notices

Collect every notice the provider sends about changes to systems, platforms, processing schedules, security incidents or outages that could affect financial data. Log each notice with its date, the affected service, and your assessment of impact on reporting. Compare notices against the period the SOC 1 report covers, because a major change after the report period may need its own review. Confirm the provider's notice obligations in the contract, since the notice terms define what you can expect to receive.

Access records for provider-facing accounts

Provider staff and integration accounts that touch your financial systems need the same scrutiny as your own users. Keep a current list of provider accounts, their roles and approval records, and periodic reviews confirming that access is still needed. Retain logs of provider logins and privileged actions where your systems produce them. The aim is to show that provider access is limited, approved and reviewed, which is the evidence auditors ask for when they test whether controls at the provider are operating for your data.

What SOC 1 provider oversight costs in money and staff time

This table compares the main cost components of overseeing IT service providers that feed financial reporting, who is paid for each, and whether the cost is one-time or recurring. Read it as a checklist for a quote or internal budget, since most amounts depend on your provider count and report scope. The main takeaway is that the provider's report is often the smallest visible cost, while internal review and complementary control mapping recur every cycle.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Provider SOC 1 report	The provider charges its customer relationship; confirm any fee with the provider before assuming one	Recurring each reporting cycle	Number of providers, report type, and whether the provider issues bridge letters on request
Internal review of the report	Your internal controls or SOX team reads the service auditor's opinion, period covered and exceptions	Recurring	Report length, number of complementary user entity controls, and how many exceptions need follow-up
Complementary user entity control mapping	Your process owners and IT staff confirm each control the report assumes you perform	One-time setup, then recurring updates	Number of complementary controls and frequency of changes to provider services
Provider register upkeep	Your vendor management or IT governance team maintains the inventory of in-scope providers and report dates	Recurring	Provider count, contract changes, and how often reports arrive out of sync with your year end
Bridge testing for coverage gaps	Your internal team or an assessor tests controls for periods the report does not cover	Recurring when gaps occur	Length of gaps between report periods and your fiscal year end, and whether the provider can supply a bridge letter
Auditor sampling of provider evidence	Your external auditor samples evidence about provider activities and your own controls over provider data	Recurring each audit cycle	Number of provider-dependent controls, sample sizes, and quality of the evidence you already hold
External review if used	A co-sourced advisor or consultant, paid under a written scope	Varies by engagement	Scope of review, number of providers, and whether the advisor reviews reports only or also mapped controls

Common questions about SOC 1 reports and SOX ITGC

Can we rely on a SOC 1 report alone for SOX ITGC?

Not on its own. A SOC 1 report is evidence about a provider's controls, and under PCAOB AS 2201 your auditor evaluates it against the period it covers relative to your as-of date, the scope of the controls tested, and the results and opinion. Management still owns the controls over information that flows to and from the provider, such as user access requests, data uploads and report review. The SEC staff FAQ says reliance on a Type 2 report does not remove that responsibility. Confirm with your auditor early which parts of the report they will accept and which they will test themselves.

What is a bridge letter and when do we need one?

A bridge letter is a statement from the provider covering the gap between the end of the period in its SOC 1 report and your fiscal year end. It is typically needed when the report's period does not reach your as-of date, which is common when a provider's year end differs from yours. The letter usually confirms whether controls changed, whether any exceptions or incidents occurred, and whether the provider is aware of issues affecting the report. Ask your auditor what content they expect before you request one, because a letter that omits changes or incidents may not close the gap.

What if our IT provider has no SOC 1 report?

You still need evidence over the services that affect financial reporting. Without a SOC 1, you can ask the provider for other assurance, such as a SOC 2 report, certifications or direct evidence, but none of these automatically substitutes for a SOC 1 in the auditor's eyes. The practical path is usually to test the controls yourself: review the provider's access reports, change records and job outputs, and perform your own review of key reports. The effort and cost depend on how much of the financial process runs through the provider and how many of its controls you must test directly. Ask your auditor whether the scope changes before you commit to a provider.

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

Generally no. SOC 1 is an examination of controls at a service organization that are likely relevant to user entities' internal control over financial reporting, so it is the report designed for SOX purposes. A SOC 2 report addresses trust services criteria such as security, availability and confidentiality, and it may contain useful information about the provider's general controls, including access and change management. Some auditors accept SOC 2 content as supporting evidence, but whether it satisfies a specific ICFR test is a judgment your auditor makes. Ask both the provider and your auditor which report covers the controls you depend on.

How much effort is complementary user entity control mapping?

The effort depends on how many controls the service auditor's report assumes you perform and how many financial processes depend on them. Each complementary user entity control, often called a CUEC, must be identified, mapped to your own control, and tested for operation, which is what PCAOB AS 2201 (paragraph B22) requires your auditor to check. Work usually recurs every year as the provider's report and your processes change, so budget for annual updates and not just a one-time mapping. Ask any partner to show how they will record each CUEC, its owner, its evidence source and the test frequency. Those four fields determine most of the workload.

What should we ask a partner to prepare for SOC 1 coverage?

Ask for a written scope that names each provider, service and financial application covered, and for a deliverable list that includes a CUEC register, a coverage-period analysis showing the gap to your fiscal year end, and a request template for bridge letters. Also ask how the partner will collect and store provider reports, record the date each report was reviewed, and document your own compensating checks where coverage is missing. A partner can prepare systems, controls and evidence, but only your independent auditor decides whether the coverage is sufficient. Confirm that the deliverables, timelines and fees are set out in a written, fixed-scope quote before work begins.

How DeployOpen prepares provider evidence for SOX ITGC

DeployOpen implements and hardens self-hosted open-source platforms inside your own infrastructure, so the systems and controls you run are ones you can document and evidence yourself. For IT service providers and SOC 1 reports, we prepare the systems, controls and records that management needs to show how provider coverage fits its own ICFR. Independent auditors, not DeployOpen, issue reports and conclusions.

How we scope

Agree in writing which provider services feed financially significant processing and which controls are in scope.
Identify which SOC 1 report periods and scope statements must be matched to your fiscal year.
List the complementary user entity controls your organization must perform and assign each to an owner.
Confirm with your auditor which provider evidence they will request before work begins.

How we build

Configure internal controls, access and change records so your own user entity controls can run and leave evidence.
Set up logging and review workflows for the information you send to and receive from providers.
Document the boundary between provider-operated controls and controls you still own, with named owners.
Test that each mapped control produces the records an assessor would sample, before the audit period starts.

How we hand over

Deliver a provider control map linking each SOC 1 control objective to your complementary controls and evidence locations.
Provide written runbooks and a gap register listing any coverage periods where a current SOC 1 report is missing.
Store evidence in version-controlled, role-restricted systems so reviewers can see what changed and who approved it.
Transfer administration and documentation to your team with a walkthrough agreed in the written scope.

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, which can cover updates to your provider map.
Ask us to confirm the scope of any support retainer in writing, including how provider report changes are handled.
Your auditor remains responsible for evaluating SOC 1 reports and the controls you rely on.

IT service providers and SOC 1 reports