Does a SOC 1 report satisfy our SOX IT general controls?
A SOC 1 report from a service organization is evidence that management and the external auditor can use when they test SOX IT general controls. It is not a substitute for the issuer's own controls. Under Section 404, the public company owns its internal control over financial reporting, and management must assess it every year, whether or not the systems that process financial data run in someone else's environment. The service organization's service auditor issues the SOC 1 report, and the company decides how much of that report it can rely on. Where the provider's services are part of the company's information system, PCAOB AS 2201 (paragraph B18) treats them as part of the company's ICFR, so the auditor plans the evidence needed with them in view.
Reliance depends on the report itself. The auditor reads the period the report covers and asks whether it reaches the company's assessment date, the scope of systems and control objectives included, and the test results and opinion (AS 2201, paragraph B21). If the report assumes that the user company performs certain complementary controls, such as reviewing access lists or approving changes before they are sent to the provider, the auditor checks that the company actually applies them (paragraph B22). The auditor also inquires about the service auditor's reputation, competence and independence (paragraph B23). Ask the provider for the report now and read the carve-out and complementary user entity control sections before anyone builds a reliance argument on them.
A report that covers a different period than your fiscal year is not automatically unusable. SEC staff FAQ says management may rely on a provider's report as of a different year-end, but management stays responsible for the controls over the flow of information to and from the provider. When significant time has passed between the service auditor's test period and management's assessment date, AS 2201 (paragraph B24) calls for added procedures, starting with inquiry of management about changes at the provider. Your team should map which feeds, interfaces, reconciliations and user access reviews stay inside the company, then confirm each one with evidence. External parties, including DeployOpen, can prepare systems and evidence for those internal controls, but the company owns the controls and the independent service auditor issues the SOC 1 report.
How auditors assess a service auditor's report
The first check compares the period the service auditor's report covers with the as-of date that management uses for its ICFR assessment. Under PCAOB AS 2201 paragraph B21, the auditor looks at the period covered, the scope of the report, the controls tested, and the test results and opinion. A report that covers only part of the year, or that tests controls the company's financial systems do not use, gives less support than the company may assume. The auditor expects the report's period and the company's assessment period to line up closely enough that the gap can be explained and bridged.
- Period covered: Check the start and end dates of the testing window in a Type 2 report against the company's fiscal year.
- Scope: Confirm the services, locations and systems described match the ones that process financially significant transactions.
- Controls tested: Map the service auditor's tested controls to the company's own control objectives, not only the provider's headline list.
- Test results and opinion: Read any exceptions, qualifications or deviations and record how management addressed each.
Ask the provider for the exact testing dates and the system description before the auditor asks for them.
The second check concerns the service auditor itself. Under AS 2201 paragraph B23, the external auditor inquires about the service auditor's reputation, competence and independence. The question is whether the firm that wrote the report is qualified to test the controls it describes and free from conflicts with the provider or the company. The auditor does not re-perform the service auditor's work, but it does decide whether the report is a reliable basis for evidence.
- Reputation and competence: Ask whether the service auditor has experience with the provider's type of service and with SOC 1 engagements of this kind.
- Independence: Confirm the service auditor is independent of the provider and does not hold a role that compromises its opinion.
- Own audit firm: Under the SEC staff FAQ, management cannot rely on a report prepared by the registrant's own audit firm. A firm that also audits the company may issue the report to a service provider only in certain cases, so confirm which firm signed the report.
- Documentation: Keep the written inquiry and the answers in the ICFR evidence file.
Confirm the service auditor's identity and independence with the provider in writing, and file that confirmation with the report.
The third check applies when significant time has passed between the end of the service auditor's test period and management's assessment date. AS 2201 paragraph B24 requires additional procedures, starting with inquiry of management about changes at the service organization. The gap matters because a control that worked during the test window may have been replaced, reconfigured or dropped afterward. The auditor needs evidence that the controls still operate, or that the company has covered any period the report does not reach.
- Inquiry of management: Ask the company's own team about system, personnel, location and process changes at the provider since the test period ended.
- Provider notices: Collect release notes, change notices and bridge letters that describe updates to the service.
- Bridge letters: Request a written statement from the provider covering the gap between the report period and the assessment date.
- Additional testing: Where the gap is material, plan procedures over the company's own controls that depend on the provider's output.
The length of the gap that triggers these procedures is a judgment for the auditor, so agree the approach with the auditor early.
The SEC staff FAQ on management's ICFR report adds two points that can change the reliance analysis. First, management may rely on a Type 2 report even when the same firm audits both the company and the service organization, but it may not rely on a report that the registrant's own audit firm was engaged to prepare. Second, management may rely on a provider's report covering a different year-end, but it remains responsible for controls over the flow of information to and from the service organization. Together these points define whose work counts and whose work the company must still do.
- Type 2 reports: Reliance depends on the report testing operating effectiveness over a period, not only the design of controls at a point in time.
- Auditor independence: A report prepared by the registrant's own audit firm does not provide the reliance management needs.
- Different year-end: A report with a different fiscal year-end can still support the assessment, but only with the bridging work described above.
- Information flow: Management owns the controls over data sent to the provider and the results it receives back, such as interfaces, reconciliations and report reviews.
Confirm the flow-of-information controls with your own team before deciding how much weight the provider's report will carry.
Which SOX ITGC controls you still own when a provider runs the system
A SOC 1 report describes the provider's controls, but management still assesses its own ICFR and must show that the provider's controls work for its financial reporting. The cards below cover the areas that stay with the issuer, each with the evidence to keep and the check to run before management relies on the report.
User access on the issuer side
Your organization still approves, provisions, reviews and removes access for its own users of the provider's platform, including administrators and approvers who post or release financial transactions. A SOC 1 report does not cover who in your company holds those roles. Keep access request tickets, approval records and periodic review sign-offs, and confirm that terminated staff lose access on time.
Configurations you control
Many financially significant settings, such as approval thresholds, user roles, posting parameters and interface mappings, are set by your team inside the provider's system. Those settings often fall outside the provider's shared control set. Keep change records for each setting you change, the approver, and the reason, and confirm that changes go through the same review as your other program changes.
Complementary user entity controls
A SOC 1 report often assumes that user organizations perform certain controls, usually listed as complementary user entity controls. Under AS 2201 paragraph B22, the auditor evaluates whether your company actually applies them. Map each listed control to an owner and a recurring operating process, then keep the evidence that it ran during the period.
Interfaces and flow of information
Data moves between your systems and the provider through file transfers, APIs and reconciliations. SEC staff guidance says management stays responsible for controls over the flow of information to and from the service organization, even when the provider's report covers a different year-end. Keep reconciliation records, interface logs, transmission approvals and exception reports that show completeness and accuracy.
Monitoring of provider reports
Your team must read the SOC 1 report, check its period against your assessment date, review the scope and any exceptions, and document how each finding affects your controls. Under AS 2201 paragraph B24, significant time between the service auditor's test period and your assessment date calls for inquiry about changes at the provider. Keep a dated review memo, the bridge letter if one is used, and a record of follow-up on exceptions.
How to build a reliance file for the SOC 1 report
This sequence gathers the service provider's SOC 1 report, ties its controls to your own ITGCs and in-scope applications, and documents the gap between the report period and your as-of date. The result is a file the external auditor can review, though the auditor decides whether it is sufficient.
Obtain the current SOC 1 report
Request the service auditor's SOC 1 report from each provider that runs a financially significant application, database or infrastructure layer for you. Confirm it is a Type 2 report covering an operating period, not only a point-in-time description, and record the report period, the service auditor's name and the list of controls tested. Ask the provider to confirm the report is current. The output is a dated copy of each report stored in the reliance file, with a note on which systems and processes each report covers.
Map provider controls to your ITGCs
Match each control in the SOC 1 report to the access, program change, program development and computer operations controls you maintain for the same applications. Mark which of your in-scope systems the provider serves, which of your controls depend on the provider's controls, and which parts of the financial process the provider does not touch. The output is a mapping table linking each in-scope application to the provider controls relied on and to your own control IDs, with gaps listed explicitly.
Assess the report's scope and test results
Review the report period against your as-of date, the systems and control objectives in scope, the controls the service auditor tested, the test results and any exceptions. Check the service auditor's opinion and whether any exception affects a control you rely on. Document the service auditor's reputation, competence and independence as you understand them. The output is a written assessment for each report that states whether its scope and results support reliance, and what residual risk remains.
Confirm complementary user entity controls operate
Identify every complementary user entity control the SOC 1 report assumes you apply, such as reviewing provider reports, approving access requests or confirming data transfers. Test each one at your company to confirm it operated during the period. If the report assumes a control that you do not apply, the reliance gap must be addressed before the report can support your assessment. The output is a list of complementary user entity controls with the evidence that each one operated and the owner who performed it.
Document the bridge period to the as-of date
Compare the end of the SOC 1 report period with management's as-of date and record any period that is not covered by the report. Note any changes you are aware of at the provider during that gap, including system changes, personnel changes or new exceptions reported by the provider. Obtain a bridge letter or similar confirmation from the provider where your procedures call for one. The output is a bridge period memo that states the uncovered dates, the changes identified and the evidence reviewed for the gap.
Perform inquiry and additional procedures
Where significant time has passed between the service auditor's test period and management's assessment date, ask management to inquire of the provider about changes to its systems, controls and personnel. Expand procedures where the answers suggest a change could affect your controls, for example by reviewing provider change notices or re-performing a sample of controls. Record who was asked, what was said and what additional evidence was reviewed. The output is a dated inquiry log with supporting evidence attached to each answer.
Hand the file to the external auditor
Assemble the reliance file with the SOC 1 reports, the control mapping, the scope and results assessment, the complementary control evidence, the bridge memo and the inquiry log. Ask the external auditor which items they need, and walk them through the file before they begin testing. The auditor decides what evidence is sufficient and whether additional procedures are needed. The output is a signed-off reliance file in the auditor's hands and a list of follow-up requests from the auditor.
Relying on a SOC 1 report versus testing directly
This table compares relying on a provider's SOC 1 report with the issuer testing the provider's controls itself. Read each row as a condition that points toward one approach, and use the takeaway that scope and evidence drive effort more than the choice of approach.
| Situation | Rely on a Type 2 SOC 1 report | Test the provider's controls directly |
|---|---|---|
| Provider runs a financially significant application | Fits when a Type 2 report covers the application and the controls that matter to your reporting | Needed when the provider's controls are not in the report or the application is not covered |
| Report scope and controls tested | Check that the system, locations and control objectives match your financial reporting risks | Fits when the report omits relevant controls, such as change management or access reviews |
| Period covered versus as-of date | Fits when the test period is close to your assessment date and bridges are documented | Needed when the report is dated too far from your as-of date and no bridge letter closes the gap |
| Significant time since test period | Inquire of management about provider changes and document the response before relying on the report | Test or obtain additional evidence when changes are unknown or the gap is large |
| User entity controls in the report | Confirm your company actually operates the complementary controls the report assumes | Owns the gap if those controls are not operating, since reliance alone will not cover them |
| Report type or auditor | Type 2 reports carry operating effectiveness over a period; Type 1 reports only describe design at one date | Needed when only a Type 1 report exists or the service auditor's competence and independence are unclear |
| Cost and effort drivers | Driven by reviewing the report, mapping its scope and documenting bridge work | Driven by the number of controls, sample sizes, provider cooperation and evidence formats; confirm scope in writing before work starts |
What to check before management relies on a SOC 1 report
A SOC 1 report from a service organization can support management's ICFR assessment, but it does not transfer responsibility. Each check below asks whether the report covers the right period, systems and controls, and whether the issuer has done its own part. Every item here sits with the issuer, not the service provider or the service auditor.
Report period and as-of date gap
Compare the period the service auditor's report covers with management's assessment date. A report covering a window that ends months before the as-of date leaves a gap in evidence. Where significant time has passed, the external auditor expects inquiry of management about changes at the service organization, so ask the provider for a bridge letter or equivalent confirmation of changes since the test period ended. Confirm the gap before management signs off.
Carve-out and subservice organization review
Check whether the report excludes any service the provider outsources to other vendors, such as a hosting partner or a payroll processor. Carved-out services are not tested by the service auditor, so their controls need separate evidence from the issuer or the subservice vendor. Map each carve-out to the financial processes it touches and confirm that someone owns the evidence for each one.
Complementary user entity controls list
Most SOC 1 reports list controls the issuer must run on its own side, such as approving user access requests or reviewing outbound file transfers. Each listed control becomes an issuer control to design, operate and evidence. Where the report assumes a control applies, the external auditor evaluates whether the company actually applies it, so map every item to a named owner and a recurring review.
Service auditor standing
Ask who issued the report and whether that firm is independent of both the provider and the issuer. The SEC staff FAQ allows reliance on a Type 2 report from a firm that also audits the issuer, but not where the registrant's own audit firm prepared the report. The external auditor inquires about the service auditor's reputation, competence and independence, so gather that information early and document it in the ICFR file.
Exceptions and management's response
Read the test results section, not only the opinion. Each exception shows a control that did not operate as described during the test period, and the provider's written response shows whether remediation is complete. Determine whether any exception touches a control the issuer relies on for financial reporting, and record how the issuer weighed it. An unresolved exception on a relied-upon control needs compensating work of the issuer's own.
Issuer controls over information flow
Management remains responsible for controls over the flow of information to and from the service organization, even when the provider's report is current. Check that the issuer has its own controls over the completeness and accuracy of data sent to the provider, such as reconciliations of batch totals, and over reports returned from it. Keep reconciliation evidence in the same ICFR file as the SOC 1 review.
Who owns what in the SOC 1 and SOX ITGC relationship
The public company's management owns its internal control over financial reporting. That includes the IT general controls that support automated controls over financial reporting, whether the financial systems run in the company's own data center or at a provider. A SOC 1 report from a provider does not transfer this duty. Management decides which provider controls it can rely on, documents that reliance, and evaluates its own controls over the flow of information to and from the provider.
- Assessment ownership: Management performs and documents the annual ICFR assessment under Section 404(a), including any reliance on provider controls.
- Complementary user entity controls: Management identifies and operates the controls a SOC 1 report assumes the user company applies.
- Information flow: Management controls data sent to and received from the provider, such as interface files, reconciliations and report extracts.
- Reliance file: Management keeps evidence of which SOC 1 report, period and scope it relied on and why.
Before relying on any SOC 1 report, confirm which of these user-entity controls your team must run and who owns each one.
The service organization operates the systems or processes described in its SOC 1 report. It designs and runs the controls in its own environment, and it decides what is in scope for the examination. The provider does not own the issuer's ICFR and cannot certify it. Its obligations run to the contract and to the accuracy of its own description of controls, which the service auditor then tests.
- Own controls: The provider runs the controls within its system description, such as access administration and change management in its hosted platform.
- System description: The provider writes the description of its system that defines what the SOC 1 report covers.
- Change notices: The provider tells customers about material changes to its controls or environment during the period.
- Contract terms: Reporting frequency, report access and exception notification are set by contract, not by the SOC 1 standard.
Check whether the provider's description covers the applications, databases and infrastructure that feed your financial reporting, not just the front-end product.
The service auditor is the independent CPA firm that examines the provider's controls and issues the SOC 1 report. Only the service auditor issues that report, and it does so for the provider and its user entities. The service auditor's opinion covers the controls it tested over the period stated in the report. Its work is not an attestation of the issuer's ICFR, and it does not replace the issuer's own testing.
- Report type: A Type 1 report covers controls as of a point in time, while a Type 2 report covers operating effectiveness over a period.
- Scope and exceptions: The report lists tested controls, the test results and any exceptions.
- Independence: The service auditor must be independent of the provider, which is a point the issuer's auditor evaluates.
- Subservice organizations: The report may carve out or include subservice providers, and each choice affects what the issuer can rely on.
Confirm which firm issued the report, its opinion type, and its period before you rely on it.
The issuer's external auditor tests the issuer's ICFR under PCAOB AS 2201 when Section 404(b) applies. The external auditor reads the service auditor's report as one input. It assesses the period covered, the scope and controls tested, and the results, and it decides what additional procedures are needed. The external auditor also considers the reputation, competence and independence of the service auditor. The external auditor does not issue the service auditor's report, and it does not become responsible for the provider's controls.
- Report evaluation: The auditor compares the SOC 1 period with the company's as-of date and the controls tested with the controls the company relies on.
- Gap procedures: When significant time passes between the service auditor's test period and management's assessment date, the auditor asks management about changes at the provider and performs additional work.
- Complementary controls: The auditor checks whether the company actually applies the user entity controls the report assumes.
- Own testing: Where the report does not cover a control the company depends on, the auditor requires evidence from elsewhere.
Ask your external auditor early which SOC 1 reports it will accept and what gap procedures it expects.
An implementation partner such as DeployOpen prepares the systems, controls and evidence that the company needs for its own SOX ITGC testing. In the self-hosted case, the partner works inside the client's infrastructure to configure access, change and logging processes and to organize the evidence they produce. The partner does not issue a SOC 1 report, does not attest to ICFR, and does not replace the external auditor or the service auditor. Ownership of the controls stays with the company.
- Preparation: The partner configures the systems, documents the control design and sets up evidence collection for the company's own ITGC testing.
- Fixed scope: Work is defined in a written scope with agreed deliverables before it starts.
- Evidence handover: The company receives the evidence, documentation and runbooks, and decides how to use them.
- Limits: The partner cannot sign management's assessment or issue any audit report or attestation.
Agree in writing which deliverables support management's own testing and which decisions remain with your team and auditors.
Common questions about SOC 1 reports and SOX ITGC
Can we rely on a SOC 1 report instead of testing our own ITGCs?
Partly. A SOC 1 report can be evidence about controls at a service provider, but it does not replace your own SOX assessment. Management stays responsible for ICFR, and under PCAOB AS 2201 the service organization's services that form part of your information system are part of your ICFR. Your external auditor decides how much of the evidence it can use, based on the report's period, scope, the controls tested and the test results. Your team still owns the controls over the flow of information to and from the provider, the access you grant, and any controls the report assumes you perform. Confirm the reliance approach with your external auditor before you plan testing.
What if the SOC 1 report period does not cover our fiscal year end?
The gap does not automatically disqualify the report, but it adds work. SEC staff guidance says management may rely on a service provider's report with a different year-end, while remaining responsible for the controls over the flow of information. Under AS 2201, the auditor compares the report's period with your as-of date and, when significant time has passed, performs additional procedures starting with inquiry of management about changes at the provider. Expect to document what changed, request bridge letters or interim evidence where the provider offers them, and test your own controls over the provider relationship for the uncovered months. Ask your auditor which bridge evidence it will accept before the period closes.
Is it a problem if the provider's auditor also audits our company?
It can be acceptable, but the answer depends on who engaged the service auditor. SEC staff guidance says management may rely on a Type 2 report even when the same firm audits both companies, but not when your own audit firm was engaged to prepare that report. Your external auditor also inquires about the service auditor's reputation, competence and independence under AS 2201. Confirm three things with your auditor: who engaged the service auditor, whether the firm is independent of your audit, and whether the report's scope matches the financial systems you depend on.
What do complementary user entity controls mean for our team?
Complementary user entity controls, often called CUECs, are controls the service auditor assumes your company performs. They are part of the provider's control design, so the report is only as strong as your performance of them. Under AS 2201, if a report assumes controls applied by the user company, your auditor evaluates whether you apply them. In practice, your team needs a list of each CUEC from the report, an owner, evidence that the control operated during the period, and a link to the relevant ICFR process. Common examples include reviewing the provider's user access listings, approving changes to configurations you own, and reconciling data sent to and returned from the provider. Map each CUEC to your own control inventory so none falls outside SOX scope.
How much effort does relying on a SOC 1 report take?
The effort is driven by the number of providers, the scope of each report, and how many of the report's assumed controls your team must perform. Reliance is usually less work than testing the same controls directly, but it is not zero work. Recurring tasks include obtaining each year's report, reviewing its opinion and exceptions, mapping complementary user entity controls, testing your own controls over the provider, and tracking changes at the provider between reports. The total depends on your filer status, the provider's report type, and how your external auditor plans its work. Ask your auditor and your provider for a written estimate of each step before the engagement begins, and do not treat any single report as the whole answer.
Can we manage SOC 1 reliance and ITGC evidence ourselves?
Often yes, if your team has staff who understand both the ICFR process and the systems involved. Management owns its assessment and the evidence supporting it, and a company can perform that work with internal resources. Many teams find the hardest parts are mapping the report to their own control inventory, keeping evidence for CUECs and the provider relationship current, and explaining the reliance decision to the external auditor. An implementation partner can prepare systems, document controls and assemble evidence in your environment, but only your independent auditor issues the attestation. Some organizations keep ownership internally and use outside help only for scoping, evidence design or testing support. Decide the split in writing, and confirm the approach with your external auditor.
How DeployOpen prepares the issuer's side of the reliance file
DeployOpen prepares the issuer's side of the reliance file: the company's own ITGC controls over the self-hosted open-source platforms it runs in its own cloud accounts, data centers or air-gapped networks, the mapping between those controls and any SOC 1 coverage, and the evidence the client's auditor will ask for. The first step is a written scope that names each financially significant application, database, operating system, network component and job that the company's IT general controls must cover. For each in-scope platform, we identify which controls the company keeps itself (for example, production access approvals, change tickets and backup restores run by the company's own staff) and which controls a service organization's SOC 1 report might cover. Where a SOC 1 report exists, we document the boundary explicitly so the issuer knows which user entity controls, often labeled complementary user entity controls in the report, it must operate itself.
The mapping is where most reliance files fail. DeployOpen builds a control-by-control table that shows the SOC 1 control objective, the period the service auditor covered, the scope of systems tested, and the company's own control that picks up any gap, including the period between the service auditor's test window and management's assessment date. We prepare the internal evidence that supports the company's side of each boundary: access review records, change approvals, job monitoring logs and records of the company's review of the service auditor's report. The client's management decides whether each mapping is adequate. DeployOpen does not issue SOC 1 reports, attestations or certifications, and it does not guarantee the external auditor's conclusion, which depends on the auditor's own testing and judgment under PCAOB standards. Before work starts, confirm with your auditor which evidence formats and sampling periods they expect, and ask for that requirement in writing in the fixed-scope agreement.
How DeployOpen scopes and documents SOX ITGC evidence
DeployOpen is a Chainscore Labs company that implements self-hosted open-source platforms inside the client's own infrastructure. For SOC 1 vs SOX ITGC, we prepare the systems and evidence that management and the external auditor rely on, while the company keeps ownership of its controls and the service auditor or independent auditor issues any report.
How we scope
- The written scope lists which financially significant applications, databases and infrastructure sit inside the ITGC boundary.
- We map which service provider reports cover those systems and which complementary user entity controls the company must still operate.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We configure access, change, development and operations controls on self-hosted platforms within the client's own cloud or data center.
- We set up logging and ticketing so that evidence of control operation is generated as work happens, not reconstructed later.
- Controls over the flow of information to and from any service organization are documented and tested as part of the build.
How we hand over
- Each control gets a written description, owner, frequency and the evidence it produces, so management can assess its own ICFR.
- We provide walkthrough material and evidence packages that help internal audit and the external auditor test design and operating effectiveness.
- Documentation is delivered to the client, who keeps ownership of the controls, records and assessment conclusions.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Retainers can cover updates to control documentation when a service provider changes its SOC 1 report period or scope.
- Clients should confirm retainer terms, response expectations and service levels in writing as part of the quote.
