As organizations outsource more of the processes that touch their financial statements, from payroll and benefits administration to transaction processing and ERP hosting, the question of how to verify those vendors’ controls becomes central to audit planning. That’s exactly what SOC 1 reports are built for.

This guide covers what a SOC 1 report is, what’s inside it, how it connects to the audit process, and what accounting and audit teams need to do with one. It’s written for practitioners who want a clear, grounded understanding of SOC 1, not just the definition but the practical responsibilities that come with it.

What Is a SOC 1 Report?

SOC stands for System and Organization Controls, and the “1” signals its focus: internal control over financial reporting (ICFR).

A SOC 1 report is an independent examination of a service organization’s internal controls, focused specifically on the controls that could affect a client’s financial reporting. 

For example, when a company outsources something that touches its financial statements, like payroll processing or transaction reconciliation, the company’s auditors need to know that those outsourced processes have proper controls in place. A SOC 1 report is how the service provider demonstrates that.

SOC 1 reports are issued by an independent CPA firm under SSAE 18 (Statement on Standards for Attestation Engagements No. 18), the AICPA auditing standard that has governed SOC 1 examinations since May 2017. Older contracts may reference predecessor standards like SAS 70 (replaced in 2011) or SSAE 16 (replaced in 2017), but the examination itself has been called a SOC 1 throughout each of those transitions.

What Does a SOC 1 Report Include?

SOC 1 reports follow a consistent structure. Three components show up in every one:

  • Management’s description of the system. The service organization describes its processes, the boundaries of what’s covered, and the control objectives it has defined. Think of this as the “here’s how we operate” section.
  • Control objectives and control activities. This is where the report gets specific. It maps out what the organization is trying to achieve with its controls (the objectives) and the specific activities it performs to get there, like reconciliations, approvals, access restrictions, and error-handling procedures.
  • The CPA firm’s opinion. The auditor weighs in on whether those controls are suitably designed. In a Type II report, the opinion also covers whether the controls actually operated effectively over the examination period.

A SOC 1 report does not cover data privacy, cybersecurity, system availability, or confidentiality. All of that belongs in a SOC 2 report.

SOC 1 Type I vs. Type II

SOC 1 reports come in two types. The difference comes down to depth and time.

  • Type I is a snapshot. It looks at whether controls are suitably designed as of a specific date. It’s faster to obtain and works well for organizations going through their first SOC 1 examination or providing initial assurance to clients.
  • Type II covers a period of time, typically six to twelve months. It looks at whether controls were designed well and whether they actually worked throughout that period. This is the report that carries real weight during a financial statement audit, because it provides evidence that the controls didn’t just exist on paper but were operating day to day.

Practically, a Type I report shows what the controls look like on paper. A Type II report shows whether they held up over time. For audit teams relying on vendor reports, Type II is almost always what’s needed.

Who Needs a SOC 1 Report?

SOC 1 reports matter on both sides of the relationship: the organizations that obtain them and the organizations that rely on them.

Service organizations get SOC 1 reports when their work could affect a client’s financial reporting. Payroll processors, benefits administrators, loan servicers, insurance claims processors, fund administrators, and ERP hosting providers are all common examples. 

The threshold is whether a provider’s processes could introduce errors or omissions into the client’s financial statements. A cloud storage provider that simply holds files probably doesn’t need one. A provider that runs the general ledger or processes journal entries almost certainly does.

User entities, the companies that rely on those providers, are required to read and act on the SOC 1 reports they receive. That means evaluating whether the controls described in the report address the right risks, and identifying any responsibilities that fall back on their own teams. 

For public companies subject to SOX, auditors will specifically ask about this. But even private companies benefit from a structured review process, especially when multiple vendors are handling different pieces of the financial reporting chain.

Internal audit teams use SOC 1 reports when evaluating third-party service providers as part of a broader vendor risk or ICFR program. As organizations grow and rely on more outsourced services, building a repeatable process for collecting, reviewing, and acting on these reports becomes critical.

SOC 1 vs. SOC 2: What’s the Difference?

Both SOC 1 and SOC 2 are AICPA-governed. Both are issued by independent CPA firms. But they answer different questions for different audiences.

  • SOC 1 is about financial reporting. “Can this vendor affect the accuracy and completeness of our financial statements?” is the question it answers, and it’s built for external auditors and finance teams.
  • SOC 2 is about security, availability, processing integrity, confidentiality, and privacy, organized around the AICPA’s Trust Services Criteria. “How does this vendor protect our data?” is the key question, and it’s built for IT and security teams.

A service organization can hold both, and many do. The two reports cover different risk domains, and having one doesn’t replace the other.

The simplest rule of thumb: financial statements question = SOC 1. Data protection question = SOC 2.

To make it concrete: if a payroll processor handles salary calculations and tax withholdings for a company’s employees, auditors will want to see a SOC 1 because those calculations flow directly into the financial statements. If that same processor also stores sensitive employee data, the IT and security team will want to see a SOC 2 to understand how that data is protected. Different concerns, different reports.

How Does a SOC 1 Audit Work?

The SOC 1 audit examination follows four main phases.

  • Scoping and control objectives. The service organization defines which controls are in scope based on what could affect client financials. Getting scoping right matters. It sets the boundaries for everything that follows.
  • Management’s description. The service organization writes a formal description of its system: what services it provides, how it operates, and what controls are in place. This is the foundation the auditor tests against.
  • Control testing. For a Type I engagement, auditors assess whether controls are properly designed as of a specific date. For a Type II, they test whether those controls actually operated effectively over the audit period.
  • The auditor’s report and opinion. The CPA firm issues one of four opinions: unqualified (clean), qualified (effective with noted exceptions), adverse (not effective), or a disclaimer (not enough evidence to form an opinion).

One thing worth knowing: SOC 1 reports are typically valid for twelve months. When there’s a gap between report periods, service organizations often issue bridge letters to cover the interim. These letters describe any significant changes to the control environment since the last report and confirm that controls continued to operate as described. They’re not a substitute for a full report, but they help audit teams bridge the coverage gap without leaving a hole in their documentation.

What Accounting and Audit Teams Need to Know When Reviewing a SOC 1 Report

Receiving a SOC 1 report from a vendor isn’t the finish line. It’s actually where the real work starts.

Under AS 2601 (PCAOB) and AU-C 402 (AICPA), auditors must consider how a service organization affects a user entity’s internal controls when planning and performing a financial statement audit. That means actually evaluating the report, not just filing it.

Complementary user entity controls

Complementary user entity controls (CUECs) are the piece that gets overlooked most often. These are controls the user entity has to maintain on its end for the service organization’s controls to work as intended. SOC 1 reports typically list them, but too many teams skip past that section. Here’s a real-world example: if a payroll processor’s controls assume the client reviews and approves payroll registers before submission, that review step is a CUEC. It’s on the user entity to perform it, and the audit team needs to test it.

Documentation matters here. Audit teams need to show how they reviewed the report, mapped it to relevant ICFR areas, and addressed any CUECs or exceptions. This is a core part of the workpapers, and regulators expect to see it.

When a report includes exceptions (instances where a control didn’t operate effectively), the audit team needs to evaluate how severe they are. Not every exception is material, but each one needs a documented assessment. Does it affect the audit’s reliance on the vendor’s controls? Are there compensating controls at the user entity level?

And if a vendor doesn’t have a SOC 1 at all? The audit team may need to perform direct testing or design alternative procedures. That’s significantly more time and cost, which is exactly why audit teams push vendors to get one.

Timing matters too. SOC 1 reports typically cover a specific period, and external auditors need coverage that aligns with the fiscal year under audit. If a vendor’s report period ends three months before the client’s year-end, the audit team needs to address that gap, either through a bridge letter from the vendor, through additional testing, or both. Building this into the audit planning timeline early prevents last-minute surprises during busy season.

How Trullion Supports SOC 1 Readiness

SOC 1 readiness comes down to organized, traceable documentation of the control environment. That’s true for service organizations preparing for an examination and for user entities managing their vendor control obligations and CUECs.

Trullion’s Audit Suite helps internal audit teams document control testing, track evidence, and maintain structured workflows that support both SOC 1 preparation and ongoing compliance. With Trullion’s Knowledge Room, teams can pull the latest SOX guidelines and relevant standards directly into control testing workflows, keeping documentation current and connected to what actually matters.

For teams managing SOC 1 readiness across multiple vendor relationships, or preparing their own organization for examination, the difference between a connected workflow and a collection of spreadsheets is the difference between confidence and scrambling.

See how Trullion’s Audit Suite supports control testing and compliance workflows. Book a demo today.

 

Author

Katie Cavanaugh