SOC 1 or SOC 2? Start with who reads the report
The choice between a SOC 1 and a SOC 2 report is usually framed as finance versus security. The more useful question is who will rely on the report, and for what decision. Get that right and scope, criteria and type follow.
- Published
- June 10, 2026
- Reading time
- 9 minutes
- Written by
- MarkTillson Assurance Practice
“Our customer has asked for a SOC report.” Few sentences cause more confusion in a growing service company. Which report? Type 1 or Type 2? Which criteria? Covering which systems? The usual shorthand, that SOC 1 is for finance and SOC 2 is for security, is true but not very helpful. It does not tell you what to put in scope or how to explain to a customer why you chose one over the other.
We start from a different question: who will read this report, and what decision will they use it for?
The basics, briefly
Both reports are attestation engagements performed by an independent licensed CPA firm under the AICPA’s attestation standards. Both describe a service organization’s system and the controls it has placed in operation. Both can be issued as Type 1, covering the suitability of control design at a point in time, or as Type 2, which adds the operating effectiveness of those controls over a period. They differ in purpose, criteria and audience.
| SOC 1 | SOC 2 | |
|---|---|---|
| Purpose | Controls relevant to user entities’ internal control over financial reporting | Controls relevant to security, availability, processing integrity, confidentiality or privacy |
| Standard | SSAE 18, AT-C section 320 | SSAE 18, AT-C section 205, with the Trust Services Criteria and description criteria |
| Control objectives | Defined by the service organization, relevant to its customers’ financial statements | Fixed criteria (the 2017 Trust Services Criteria, with points of focus revised in 2022) |
| Primary readers | Customers’ management and their external auditors | Customers, prospective customers, partners and regulators with sufficient knowledge of the system |
| Use restriction | Restricted to user entities and their auditors | Restricted to specified knowledgeable parties; SOC 3 is the general-use summary |
The reader test
If your customer’s auditor will rely on it
If your service affects the numbers in your customers’ financial statements (payroll processing, claims administration, fund administration, loan servicing, revenue or billing platforms, payment processing that feeds the general ledger), your customers’ external auditors may need assurance over your controls in order to rely on them. That is SOC 1 territory. The report is written for an auditor evaluating the risk of material misstatement, and its control objectives are framed in those terms: transactions are authorized, complete and accurately recorded; changes to the programs that process them are controlled; access to them is restricted.
If your customer’s security team will rely on it
If the question is whether you can be trusted with the customer’s data and systems (a SaaS platform holding customer records, a managed service provider with administrative access, a data processor), the reader is a security or vendor-risk team. They want to know how you control access, manage change, monitor for incidents, protect data and keep the service available. That is SOC 2.
If both are true
Some organizations genuinely need both: a payroll platform is part of its customers’ financial reporting and holds sensitive employee data. Many of the underlying IT general controls (logical access, change management, operations) support both reports. Running them on aligned periods, with one evidence set, avoids most of the duplication.
“Is this report for your external auditor or for your security and vendor-risk review?” The answer usually settles the choice in one conversation, and it signals to the customer that you understand what they need.
Scope decisions that matter more than the report type
The system boundary
A SOC report describes a defined system: the services, infrastructure, software, people, procedures and data involved in delivering it. Draw the boundary too wide and you take on controls you cannot evidence; too narrow and the report fails to cover what customers care about. The description is part of what the auditor opines on, so it must be accurate.
Subservice organizations
Almost every modern service relies on others: cloud infrastructure, payment processors, data centers. The report must say how these are handled. Under the carve-out method, the subservice organization’s controls are excluded and readers look to that provider’s own report; under the inclusive method, they are included and tested, which requires the subservice organization’s cooperation. Carve-out is far more common; it means you should hold, and review, your key providers’ reports.
Complementary user entity controls
Some control objectives can only be achieved if customers do their part: managing their own users and reviewing the reports you send them. These complementary user entity controls are listed in the report. They should be real and reasonable; a long list of user controls is a signal to readers that your service shifts risk onto them.
Trust Services Categories for SOC 2
Security (the common criteria) is always included. Availability, confidentiality, processing integrity and privacy are optional. Add a category because customers rely on it and you can evidence it, never to make the report look more complete.
Type 1 or Type 2?
A Type 1 report is a sensible first step when controls are newly implemented and a customer needs something now. It confirms design at a point in time. Most enterprise buyers will expect a Type 2 for ongoing reliance, because operating effectiveness over a period is what demonstrates the controls actually work. Plan the first Type 2 observation period as soon as the Type 1 is complete, and keep reports contiguous: a gap between periods raises questions, and bridge letters can only cover short gaps.
Who does what
The opinion is issued by a licensed CPA firm. Almost everything that decides how that opinion reads happens earlier: gap assessment, control design, description drafting, evidence preparation and mock testing. That is where a strong readiness partner earns its place. It helps you choose the right report, makes the auditor’s fieldwork efficient and keeps exceptions out of your first Type 2.
Key takeaways
- Ask who will rely on the report. Customers’ auditors point to SOC 1; security and vendor-risk teams point to SOC 2.
- Many organizations need both, and can share most IT general controls and evidence.
- Scope decisions on the boundary, subservice organizations and user controls matter more than the label.
- Type 2 is what enterprise buyers rely on; keep periods contiguous.
- The CPA firm issues the opinion; the readiness work decides what it says.
Sources
- AICPA, Statement on Standards for Attestation Engagements No. 18, AT-C sections 105, 205 and 320.
- AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022).
- AICPA, description criteria for a service organization’s system in a SOC 2 report (DC section 200).
Not sure which report you need? Our SOC team will settle the question in one conversation, then take you from readiness to a clean report your customers can rely on.
