A customer asks for your SOC report. You send your SOC 2. A week later their controller replies that they needed a SOC 1, and their external auditor will not accept the SOC 2 in its place. Nobody did anything wrong. The two reports answer different questions, for different readers, and the request did not say which question it was asking.
This article explains what each report examines, who reads it, and how to tell from a request which one is wanted. It also covers when a service organization needs both, and how to run them without doubling the work.
Two reports, two questions
Both are attestation reports issued by a CPA firm under the AICPA's attestation standards. Both come as a Type I or a Type II. Beyond that, they are built for different purposes.
SOC 1 reports on controls at a service organization that are relevant to its customers' internal control over financial reporting. It is performed under AT-C section 320. The question it answers is: can a customer's financial auditor rely on the way you process transactions that end up in your customer's financial statements?
SOC 2 reports on controls relevant to security and, if included, availability, processing integrity, confidentiality, or privacy. It is performed as an examination under AT-C section 205, against the AICPA's trust services criteria. The question it answers is: does this vendor protect the system and the data we are trusting it with?
The difference that matters most in practice is where the yardstick comes from. In a SOC 2, the criteria are published by the AICPA and are the same for every service organization. In a SOC 1, management of the service organization defines its own control objectives, and the auditor tests the controls against them. Those objectives should cover what customers' auditors need, which is why writing them well takes care.
Who reads each report
| SOC 1 | SOC 2 | |
|---|---|---|
| Primary readers | Customers' finance teams and their external auditors | Customers' security, risk, and procurement teams |
| What it is measured against | Control objectives defined by the service organization | The AICPA's trust services criteria |
| Typical focus | Transaction processing and the IT general controls behind it | Security of the system, plus any optional categories |
| Typical use | Evidence for a customer's financial statement audit, including SOX work | Vendor due diligence and security review |
| Distribution | Restricted to the service organization, its customers, and their auditors | Restricted to specified parties with enough knowledge to understand it |
Neither report is meant for the general public. That is the role of a SOC 3, which is a different report again.
The SOC 1 audience is the important one to recognize. When a customer's external auditor reviews that customer's financial statements, and part of the customer's process runs on your system, the auditor needs evidence about your controls. For public companies subject to the Sarbanes-Oxley Act, section 404 requires management to assess internal control over financial reporting, and for many companies the external auditor attests to it. A SOC 1 Type II is the standard way for a service organization to supply that evidence once, to all customers, rather than hosting each customer's auditor separately.
How to tell which one a request means
Requests are often written as "SOC report" or "SOC 2 or equivalent." Look at who is asking and what they are trying to do.
Signs a customer needs a SOC 1
The request comes from the controller, the finance team, internal audit, or the customer's external auditor.
Your service calculates, processes, or records amounts that appear in the customer's financial statements: payroll, payments, billing, revenue, claims, or investment transactions.
The request mentions SOX, internal control over financial reporting, or user auditor reliance.
The customer asks about complementary user entity controls in terms of their close process or reconciliations.
Signs a customer needs a SOC 2
The request comes from security, IT risk, vendor management, or procurement.
It arrives with a security questionnaire, or as part of onboarding a new vendor.
Your service stores or processes the customer's data, but the outputs do not feed their financial statements.
If you are unsure, ask the requester directly what the report will be used for. It is a reasonable question, and the answer saves both sides a round trip.
What overlaps, and what does not
A SOC 1 typically has two kinds of control objectives.
Business process objectives. Controls over the transactions themselves: that they are authorized, processed completely and accurately, and recorded in the right period. These have no direct equivalent in a security-only SOC 2. The closest SOC 2 category is processing integrity, and the two are not interchangeable.
IT general control objectives. Logical access to programs and data, changes to programs, and computer operations. These overlap heavily with the SOC 2 common criteria for access (CC6), system operations (CC7), and change management (CC8).
The IT general controls are where doing both reports pays off. One access review, one change process, and one incident process can be tested for both, often in the same fieldwork. If you want background on these controls from the financial audit side, SOX IT general controls explained covers the categories.
What does not overlap is the business process work, and the system description. A SOC 1 description is written around the transactions and reports your customers rely on. A SOC 2 description is written around the system and its boundaries. Each needs its own careful drafting.
When you need both
A service organization needs both when it serves both audiences. That is common for platforms that handle financial transactions and also hold sensitive data: payroll and HR systems, payment processors, billing and subscription platforms, and financial data aggregators.
If you are in that position, a few practical points apply.
Align the periods. Running both reports over the same period lets the auditor test shared controls once. Mismatched periods mean separate sample pulls.
Use one firm if it fits. Many firms perform both. One firm testing both reports can usually reuse work on shared controls.
Write SOC 1 objectives with your customers' auditors in mind. Objectives that are too narrow leave those auditors without the assurance they need. Objectives that are too broad add testing that nobody relies on.
Expect different complementary controls. In a SOC 1, user entity controls often involve the customer reviewing reports or reconciling outputs. In a SOC 2 they are more often about managing their own users. Complementary user entity controls, explained covers what belongs in that list.
When you need neither yet
Some companies are asked for a SOC 1 before any customer actually needs one. If your service does not touch amounts in a customer's financial statements, a SOC 1 has little to report on. Say so, and explain what your service does and does not affect. Equally, a company with no SOC report yet can still answer a security review well, with a clear security page and accurate questionnaire answers, while it prepares.
Whichever report you issue, the reader still has to interpret it. How to read a SOC 2 report as a buyer covers what your customers will look at first, and the SOC 2 framework page summarizes the report itself.
How TrustLynce helps
TrustLynce maps controls across frameworks and reuses evidence between them, so an access review or a change sample collected once can support each report that tests it. Commitments you make to customers, including which reports you provide, can be tracked against the controls that support them.