Service organization reports for SOX: period gaps and auditor checks

How do you review a service organization report for SOX use?

A finance or compliance leader whose general ledger or billing system runs at a provider needs comfort before the assessment date, and that comfort comes from reviewing the provider's SOC 1 report on purpose rather than filing it. The company reviews the report's coverage period, scope, controls tested, exceptions and opinion, checks the standing of the service auditor, and adds its own procedures when time has passed. The company owns its controls and its conclusion about them. Only the independent service auditor issues the SOC 1 report. DeployOpen can prepare systems, configuration evidence and control documentation for that review, but it does not issue reports or attestations. Start with the period. Compare the report's coverage window with management's as-of date and with the fiscal period the company is assessing. A gap at either end needs a documented answer. Next, read the system description and the list of controls tested to confirm the services and locations your financial data touches are inside the scope. Then go to the test results: each exception needs a note on whether it affects a control you rely on, and an opinion that is modified or carves out a control is a finding you must address, not a footnote. Also confirm the service auditor is independent and experienced enough to perform the engagement. Your external auditor will ask about these points under PCAOB AS 2201, so record your answers in the same file.

Effort depends mostly on three things: the number of providers in the financial reporting process, the number of provider controls you rely on, and the age of each report. A fresh report covering most of the year with clean results needs a short review and a few inquiries. A report that ends several months before the as-of date, or that contains exceptions in access or change controls, requires written inquiry of the provider about changes, the company's own complementary controls and possibly additional evidence about the provider's processing. Ask your provider and your service auditor for the report's exact coverage dates, the list of carved-out subservice organizations, and the names of the complementary user entity controls the report assumes. Those items are the starting point for any scoping conversation with an outside consultant or an implementation partner.

What to check in the report, step by step

This sequence turns a provider's SOC 1 report into a documented judgment about whether you can rely on it for your SOX assessment, and it shows exactly which gaps you must close yourself.

Confirm the coverage period against the assessment date
Start by reading the period the report covers and comparing it with your fiscal year end and the date management performs its ICFR assessment. Under PCAOB AS 2201, the auditor weighs the period covered relative to the as-of date, so the first output is a short note recording the report period, the assessment date and the calendar gap between them. If the report ends well before your assessment date, record that gap as an open item for the next step. Someone on the SOX team, usually the ITGC lead, owns this check, and it is complete when the gap is written down with a date range.
Confirm systems, locations and services in scope
Compare the systems, applications, infrastructure, data centers and services named in the report's description of the provider's system with the systems that feed your financial reporting. Look for applications, interfaces or hosting locations your organization uses that the report does not describe. The output is a scope mapping table that links each in-scope financial system to a section of the report, with any system missing from the description listed as a gap. Confirm with the provider in writing when the description is ambiguous, and do not assume coverage from a general product name.
Check which controls the service auditor tested
Review the control objectives and the individual controls the service auditor tested, and map them to the ITGC areas your program relies on: access, program changes, program development and computer operations. Identify where the provider's controls cover what your SOX program needs and where they do not, such as user access reviews for your own application roles or change approvals for your configurations. The output is a list of controls you can rely on, and a separate list of areas the report does not test that must be tested by your own team or by a further procedure.
Read test results and exceptions
Read the testing procedures and results for each control, paying attention to every exception the service auditor recorded. Note the number of samples tested, the nature of each exception, and whether the provider's response describes a remediation and a date. Under AS 2201 paragraph B25, errors found in the provider's processing and changes in its controls increase the evidence you need, so flag any exception and any control that changed during the period. The output is an exception register with a disposition for each item: accepted with rationale, requires additional procedures, or requires a compensating control on your side.
Check the opinion type and the service auditor's standing
Confirm the type of report and the opinion it expresses, and check whether the opinion is unmodified or qualified. Then ask about the service auditor's reputation, competence and independence, as AS 2201 paragraph B23 expects. Record who issued the report, whether the firm is independent of the provider, and any issues you find in its reputation or competence. A qualified opinion or a reliance concern should lead to additional procedures before you rely on the report. The output is a short opinion memo signed off by the ITGC reviewer, stating the conclusion and the basis for it.
Map complementary user entity controls to internal controls
Read the complementary user entity controls section, which lists the controls the report assumes your organization performs, such as reviewing access granted to your users or validating interface files. Map each listed control to a specific internal control you own, name the owner, and record the evidence that will show it operated. Any complementary control without an internal counterpart becomes a design gap. The output is a complementary control matrix with one row per control, its owner, its evidence and its test status. Management remains responsible for the flow of information to and from the provider, so this matrix should be reviewed before the assessment closes.
Document gaps and procedures for elapsed time
Where the report period ends well before the assessment date, or where the scope or controls fall short, consolidate the open items from the earlier steps into one gap list. For each item, record the additional procedure you will perform under AS 2201 paragraph B24, starting with inquiry of management about changes at the provider since the report period. Scale the evidence you request to the time elapsed, the significance of the provider's activities, any errors found and any control changes. The output is a signed gap list with procedures, owners and evidence requests, which becomes the basis for the bridge letter discussion and the ITGC testing plan.

Which procedures fit which report situation?

When the service auditor's test period spans the whole of management's fiscal year, the report usually needs the least supplementary work. The main question is whether the controls tested match the controls your company relies on, and whether the period covered lines up with your as-of date. Even then, the company still owns the controls over information flowing to and from the provider, and that part of the work does not go away.

Confirm the period end: Check that the test period covers your fiscal year and that the as-of date you report against falls inside it.
Map the controls: Match each provider control you rely on to a specific financial reporting risk in your own process documentation.
Review exceptions: Read the test results and any exceptions in the controls you rely on, even when the opinion is unqualified.
Document the handoffs: Keep evidence of the data you send to the provider and the outputs you receive, such as reconciliations or interface logs.
Record the service auditor check: Note the service auditor's standing, reputation and independence in your file, as the auditor will ask.

Confirm with your external auditor which controls they expect you to test yourself, because that decision drives how much of the report you can rely on without further work.

How to check the service auditor's standing

Before relying on a provider's report, the company should look at who wrote it. PCAOB AS 2201 asks the external auditor to inquire about the service auditor's reputation, competence and independence, and the company's own evidence file should show that these checks were made.

Confirm licensing and peer standing

Confirm that the firm issuing the service auditor's report is a licensed CPA firm in good standing with its state board, and that it participates in a peer review program. Ask the firm for its current peer review report or a public letter confirming its status. Record the license number, the issuing state and the date you checked, so the auditor can see the verification in your file. A report from a firm you cannot verify gives you nothing to rely on.

Ask about experience with this report type

Ask how many examinations of this type the firm has performed for providers in the same industry and service line, and whether its engagement team has done prior SOC 1 Type 2 work. A firm that mainly issues SOC 2 reports on security may have less experience with the financial reporting controls a SOX program relies on. Ask who signed the report and whether that partner has supervised similar engagements. Document the answers in writing.

Confirm independence from the provider

Ask the provider to confirm, in writing, that the service auditor has no financial interest in the provider and has not performed non-attest work that would impair its independence, such as designing or operating the controls it tests. Check whether the service auditor and the provider share an owner, board member or former employee in a role that matters. An independence concern can make the report unusable for SOX reliance, even if its opinion is clean.

Check who the service auditor is accountable to

Confirm that the report was issued by an independent practitioner engaged by the provider, not by the provider's internal audit team, and that the report names the firm and the signing partner. Ask whether the provider's management has been asked to restate or withdraw any part of the report. An internal or self-prepared document may describe controls accurately, but it does not meet the independence expectation that makes the report useful as evidence.

Ask your external auditor what it expects

Your external auditor makes the final determination on whether a service auditor's report is adequate for your ICFR testing. Before you spend effort on the provider's file, ask the auditor which reputation, competence and independence evidence it wants in your workpapers, and whether it has a preferred format for the inquiry. Your company owns the request and the documentation, and the auditor decides what is sufficient.

Reading exceptions and the opinion without overreading them

An exception in a service auditor's report is a tested control that did not operate as described, and it matters for your reliance only if the failed control sits in a path your financial reporting depends on. Start by mapping each exception to the control objective it was meant to achieve, then ask whether that objective covers a process whose output flows into your ledger, such as access provisioning, change approval, batch processing or reconciliations. An exception in a control that only affects the provider's internal operations may not change your conclusion, but an exception that touches data integrity, unauthorized access or change to processing logic usually does. Record your reasoning for each exception, because the assessor will ask how you decided.

Next, confirm whether the provider has remediated the exception and whether the fix was tested. The report describes the period tested, so a corrected control may not appear in it at all. Ask the provider in writing what changed, when, and what evidence shows the corrected control has operated since. Where the exception affected a control you depend on, plan your own procedures to cover the gap, such as testing the provider's output against your records for the affected period. Keep the provider's response and your test results in the same file as the report.

A clean opinion is not a substitute for your own controls over the provider's output. The opinion speaks to the service organization's controls as tested by the service auditor, and it does not confirm that your user access, configuration settings, interfaces or review of provider reports are working. Management remains responsible for the controls over the flow of information to and from the service organization, as SEC staff guidance on management's ICFR report explains in its FAQ. Under AS 2201 paragraph B27, the external auditor should not refer to the service auditor's report when expressing its opinion on ICFR, so your own documentation must carry the conclusion that the provider's controls are relied upon and that your complementary controls operate.

What stays with your company even with a clean report

A clean service auditor's report covers the provider's controls, not yours. The cards below cover the parts of SOX ITGC coverage that remain with your company, and they are the parts auditors most often ask you to show.

Complementary user entity controls

Every service auditor's report assumes that certain controls run at the customer. These complementary user entity controls might cover approving user access requests, reviewing provider invoices or confirming configuration settings. Read the report's section listing them and map each one to a named owner and a recurring control in your own program. A control the report assumes but you do not perform leaves a gap that the report cannot fill.

Information flow to and from the provider

Your company controls the data it sends to the provider and the output it receives back. Feeds, interfaces, batch uploads and report extracts can be incomplete or altered before the provider's controls ever touch them. Confirm which inputs and outputs are in scope for the report, then test completeness and accuracy on your side for anything that flows into the financial statements.

User access on your side

The provider manages its own staff, but your users, administrators and integrations still need access you grant and review. Access to the provider's application, approval workflows and any admin roles assigned to your team sits outside the provider's tested controls unless the report states otherwise. Review who holds these roles, remove access when people change jobs, and keep the review evidence for the assessment period.

Configuration and change requests you submit

Many financial systems at a provider are configured by the customer, through parameters, workflow rules or requested changes. A change you request is your change to authorize, test and approve before it reaches production in your environment. Keep request tickets, approvals and post-change checks, since the provider's change controls do not prove that your requested configuration was appropriate.

Risk you accepted by requesting the report

Asking for a service auditor's report is a way to assess a provider's risk, not a transfer of that risk. The Journal of Accountancy's 2016 explanation of SOC reports makes the point that a user entity requesting a report is not relieved of its own responsibility for the risk. Document your vendor risk assessment, the decision to rely on the report, and the residual risk you accepted, and have the approving owner sign it.

Which path fits a report that is incomplete or outdated?

This table compares four responses when a provider's report does not cover the full period, is out of date, or shows relevant exceptions. Read each row against your own gap: the length of the uncovered period, the significance of the service, and whether the exceptions touch controls your financial reporting depends on.

Option	When it fits	Evidence it produces
Bridge letter from the provider	The report covers most of the period and the gap is short, with no known changes or exceptions at the provider since the test period ended	A signed statement from the provider on whether controls operated and whether anything changed. It supports inquiry but does not replace testing, so ask whether it addresses the specific controls you rely on
Inquiry and additional testing at your company	Significant time has passed, or the provider reports changes or exceptions that bear on your reliance, and you can test your own controls over the provider's output	Your management inquiries about provider changes, reconciliations and review evidence, and test results on your side of the interface. This is usually the core procedure when the provider's gap cannot be closed from documents alone
Current or more recent provider report	The provider has issued a later report, or the existing report is stale and the provider can commission a new examination that covers your assessment date	A newer service auditor report with a test period closer to your as-of date. Confirm its scope still includes the systems and controls your financial reporting uses, not only the same services by name
Moving the control in-house	The provider will not supply a usable report, the exceptions are material to your processing, or the service is too significant to rely on a third party's testing alone	Your own control design, operating evidence and testing records for the activity. Expect more work and ownership of the control, and plan a walkthrough before relying on it

What to ask the provider before the assessment date

Send your provider a written request list well before management's assessment date, because the report you rely on is only as useful as the documents that accompany it. Start with the current SOC 1 Type 2 report covering the services that feed your financial statements, then ask for the scope description, the list of carved-out subservice organizations, and the complementary user entity controls the report assumes you operate. Confirm in writing which systems, locations and transaction types the report covers, since a report that omits a payroll module or a billing interface leaves that flow untested. Ask for the same details for any subservice organization whose output you depend on, and request that provider's own report list so you can see where the chain of assurance ends.

Next, ask for the documents that close the gap between the report period and your assessment date. If the period ends before your as-of date, request a bridge letter from the provider that states whether controls changed and whether any known exceptions occurred after the period. Ask for the status of each exception noted in the report, including the remediation date, the control owner and whether the fix has been tested. Also ask for written notice of significant changes to controls, systems, hosting locations, key personnel or subservice organizations since the period closed. Treat a vague answer or a refusal to provide a letter as a finding that needs more evidence under your own procedures, and confirm the provider's exact commitments with its contract or service documentation.

The provider owns its controls, but your company owns the conclusion it draws about internal control over financial reporting. Before the assessment date, record each request, the date sent, the response and any follow-up in your SOX file, and decide who on your side reviews each answer. Ask the provider to confirm each item in writing, and note any item it cannot provide so you can plan compensating procedures or additional testing of your own controls over the provider's output. Your auditor will ask how you reached your view, so the written trail should show that you reviewed the report, not that you simply filed it.

Common questions about SOC 1 reports for SOX

Is a SOC 1 Type 1 report enough for SOX reliance?

Usually not on its own. A Type 1 report describes whether a provider's controls were suitably designed as of a single date, while a Type 2 report also tests whether those controls operated effectively over a period. For SOX, the period matters because management needs evidence that controls worked during the fiscal year under assessment, not only that they existed on one day. A Type 1 report can help with design understanding, but most teams need a Type 2 report whose coverage period lines up with their year end or can be bridged to it. Confirm the report type, period and scope with the provider before relying on it.

How much effort does reviewing a SOC 1 report take?

The effort depends on how many providers feed financial reporting, how complex each service is, and how far the report's coverage is from your assessment date. A review typically covers the period, the scope of the services and systems included, the controls the service auditor tested, the exceptions and the opinion, plus a check of the complementary user entity controls the report assumes you run. Each additional provider, each exception and each gap in period multiplies the work. Ask your auditor which reports they expect to see and how they want the review documented before you start.

Can our own team review a SOC 1 report without outside help?

Often yes, if the team understands SOX, the provider's services and the financial processes those services support. The review is a management responsibility because the organization owns its ICFR conclusion, even when a provider performed the controls. Internal audit, finance controllers and IT staff can work through the checklist together. Outside help is most useful when the team lacks SOC 1 experience, when several complex providers are involved, or when exceptions need analysis. Any outside firm prepares your review and evidence; only the independent auditor concludes on your controls.

How long should we allow when a SOC 1 report is old?

There is no fixed number of days in the standard, so treat the time gap as a risk factor. The longer the time since the service auditor's test period, the more evidence you need, and the auditor will expect procedures such as inquiring of management about changes at the provider, reviewing bridge letters and checking for errors or control changes. The need rises with the significance of the provider's activities, any processing errors found and any changes to its controls. Confirm with your external auditor how they will treat your specific gap and what evidence they require, and allow time for provider responses.

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

In most cases it cannot replace a SOC 1 report on its own. A SOC 1 report is designed around controls relevant to user entities' internal control over financial reporting, while a SOC 2 report addresses the Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy. The two reports overlap in places, but the scope and control objectives differ. Some companies use a SOC 2 report as supporting information and close the remaining gaps with their own controls over the provider's output. Ask your auditor whether they will accept that approach for your specific service.

What does DeployOpen do and not do in a SOC 1 review?

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, and it can prepare systems, controls and evidence for compliance assessments. For SOC 1 review, that can include organizing the evidence you hold, mapping your complementary user entity controls to your own systems and documenting how you handle provider reports. DeployOpen does not issue audit reports, attestations or certifications, does not conclude on your controls and does not replace the service auditor or your external auditor. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts, and the quote follows from that scope.

Do we need a SOC 1 report for every vendor in the financial process?

Not necessarily. Start with a top-down risk assessment of which providers produce or process information that feeds financial statements, and which of their controls your own controls depend on. Providers whose services have no effect on financial reporting usually fall outside this need, while those that host ledgers, calculate balances or move cash typically require closer review. Where a provider has no usable SOC 1 Type 2 report, you will need alternative procedures. Confirm your scoping decisions with your external auditor before you rely on them.

How DeployOpen prepares evidence for provider reviews

DeployOpen works on the systems and evidence side of provider reviews: the documents you collect, the period and scope they cover, and the gaps you need to close yourself. We prepare systems, controls and evidence for your assessment, while your auditors and the service auditor issue their own conclusions.

How we scope

Engagements are fixed-scope, with the providers, reports and financial systems in the review agreed in writing before work starts.
The written scope lists each service auditor report, its period, its tested controls and the in-house controls that must cover the gap.
We agree which assessment date applies, so period coverage is checked against the date management evaluates ICFR.
Scope is set with your auditor's expectations in mind, and you confirm them before we start.

How we build

We build a review file per provider that records coverage period, scope, controls tested, exceptions and the opinion type.
We map each complementary user entity control in the report to an owner, a procedure and a dated piece of evidence.
Where time has passed since the test period, we prepare the inquiry log and change register that the additional procedures call for.
We document how information flows to and from the provider, since that remains your responsibility under the SEC staff FAQ.

How we hand over

You receive the review file, the control-to-evidence map and a list of open gaps with an owner for each item.
Documentation states which conclusions belong to management, which belong to your independent auditor and which belong to the service auditor.
Walkthrough notes and sample evidence are organized so your internal audit or external auditor can re-perform the review.
Handover includes a short list of questions to confirm with the provider before the assessment date.

How we support

Ongoing support, updates to the review file and re-review after each new provider report are available as a retainer.
When a provider's report changes scope, exceptions or opinion, we update the review file and the affected evidence.
Continuous testing of systems your financial applications depend on can be added under a separate written scope.
Your team keeps ownership of the ICFR conclusion, and we support the evidence behind it.

Service organization reports for SOX: period gaps, opinions and auditor checks