Your client’s procurement team has asked for a SOC report. The problem is that “SOC report” is not one thing. SOC 1 and SOC 2 are fundamentally different audits, built for different audiences, and covering different controls. Choosing the wrong one wastes months of preparation and audit fees, and still leaves the original request unanswered. This guide breaks down the differences between SOC 1 vs SOC 2, explains what each report covers, and gives you a clear framework for deciding which one your organisation actually needs.
What Are SOC Reports?
SOC reports are independent attestation reports issued by a licensed CPA (Certified Public Accountant) firm. They are governed by the American Institute of Certified Public Accountants (AICPA) under the SSAE 18 (Statement on Standards for Attestation Engagements No. 18) framework.
The purpose is straightforward: a service organisation hires an auditor to examine its controls, and the auditor produces a report that the organisation can share with clients, prospects, and regulators. The report gives those parties independent assurance that specific controls are in place and functioning.
There are three SOC report types. SOC 1 covers controls relevant to financial reporting. SOC 2 covers controls relevant to security, availability, processing integrity, confidentiality, and privacy. SOC 3 is a public-facing summary of a SOC 2 audit, without the detailed control descriptions. For most organisations, the real decision sits between SOC 1 and SOC 2.
Financial institutions evaluating service providers will often require one or both of these reports as part of their audit requirements for due diligence.
What Is a SOC 1 Report?
A SOC 1 report examines the internal controls at a service organisation that are relevant to the financial reporting of its clients. In plain terms: if your service touches your client’s financial statements, SOC 1 is likely what their auditors will request.
The standard that governs SOC 1 is SSAE 18, and the specific guidance sits in AT-C Section 320 (Reporting on an Examination of Controls at a Service Organization Relevant to User Entities’ Internal Control Over Financial Reporting).
Who typically needs SOC 1:
- Payroll processors that calculate wages, deductions, and tax withholdings reported in client financial statements
- Payment processing platforms that handle transaction settlement and revenue recognition data
- Fund administrators that calculate net asset values and process investor transactions
- Loan servicing companies that manage payment schedules, interest calculations, and escrow accounts
- Claims processing firms that determine liability amounts recorded in client accounts
The defining question is: does your service produce, process, or modify data that ends up in a client’s audited financial statements? If yes, their external auditor will want to see a SOC 1.
What the auditor examines:
The scope is defined by the service organisation itself, in a document called the “Description of the Service Organization’s System.” The auditor tests the controls described in that document. These are typically controls around transaction processing, data input validation, reconciliation, and output reporting.
What Is a SOC 2 Report?
A SOC 2 report examines the controls at a service organisation relevant to security and operational commitments. It is the report most commonly requested in enterprise sales cycles, security questionnaires, and procurement reviews.
SOC 2 is governed by the AICPA’s Trust Services Criteria (TSC), which define five categories of controls that an organisation can be evaluated against.
The Five Trust Services Criteria
- Security (required for every SOC 2). Controls that protect the system against unauthorised access. This is the baseline criterion and is sometimes referred to as the “Common Criteria.”
- Availability. Controls that ensure the system is available for operation and use as committed. Relevant for SaaS platforms with uptime SLAs.
- Processing integrity. Controls that ensure system processing is complete, accurate, timely, and authorised. Important for platforms that transform or calculate data.
- Confidentiality. Controls that protect information designated as confidential. Applies when the organisation handles proprietary client data, intellectual property, or business-sensitive information.
- Privacy. Controls over the collection, use, retention, disclosure, and disposal of personal information. Relevant when the service handles end-user personal data.
An organisation does not need to include all five criteria. Security is mandatory. The remaining four are selected based on what is relevant to the service and what clients expect. Most first-time SOC 2 audits cover Security and Availability; organisations handling personal data typically add Confidentiality and Privacy.
Organisations that also hold ISO 27001 certification will find significant overlap with the Security criterion, though the two frameworks differ in structure and audit methodology.
SOC 1 vs SOC 2: Key Differences at a Glance
The core distinction is what each report is designed to assure. SOC 1 is about financial reporting accuracy. SOC 2 is about data security and operational integrity.
| SOC 1 | SOC 2 | |
|---|---|---|
| Purpose | Assurance over controls affecting client financial reporting | Assurance over security, availability, processing integrity, confidentiality, and privacy |
| Governing standard | SSAE 18, AT-C Section 320 | SSAE 18, AT-C Section 205, using AICPA Trust Services Criteria |
| Who requests it | Client’s external financial auditor | Client’s security team, procurement, risk, or compliance function |
| Control scope | Defined by the service organisation (transaction processing, reconciliation, reporting) | Defined by the Trust Services Criteria selected |
| Industries | Payroll, payment processing, fund administration, loan servicing, claims processing | SaaS, cloud infrastructure, data analytics, managed services, any technology provider |
| Report audience | Restricted (client management, client auditors, regulators) | Restricted (SOC 2) or public summary (SOC 3) |
A practical way to think about it: SOC 1 answers the question “Can we trust this provider’s impact on our financial numbers?” SOC 2 answers the question “Can we trust this provider with our data and systems?”
Type 1 vs Type 2: What the Distinction Means
Both SOC 1 and SOC 2 come in two variations, and the distinction is identical for both.
A Type 1 report evaluates the design of controls at a specific point in time. The auditor looks at whether the controls, as described, are suitably designed to achieve their objectives. It is a snapshot.
A Type 2 report evaluates the design and operating effectiveness of controls over a defined period, typically between three and twelve months. The auditor not only confirms that controls are designed properly but also tests whether they actually operated as intended throughout the observation window.
Which one matters more?
Type 2 is the standard that enterprise buyers, auditors, and regulators expect. A Type 1 is useful as a first step, particularly for organisations that have never undergone a SOC audit before, because it validates the control design before committing to a full observation period. Many organisations start with a Type 1 and move to a Type 2 within six to twelve months.
In practice, if a client’s security questionnaire asks for a “SOC 2 report” without specifying the type, they almost always mean a SOC 2 Type 2.
Where Does SOC 3 Fit In?
A SOC 3 report is a public-facing version of a SOC 2. It uses the same Trust Services Criteria and the same audit process, but the final report is a general-use summary that omits the detailed control descriptions and test results.
SOC 3 exists for organisations that want to demonstrate their SOC 2 compliance publicly, on a website or in marketing materials, without sharing the full audit detail. It is not a substitute for SOC 2 in procurement or security review processes. Clients and auditors who request a SOC report will expect the detailed SOC 2, not the SOC 3 summary.
For organisations operating across both US and EU frameworks, understanding how NIS2 and SOC 2 requirements intersect is increasingly relevant, particularly for service providers selling into regulated European markets.
How to Decide Which SOC Report You Need
Start with what your clients are asking for. In most cases, the request itself tells you which report is appropriate.
You need a SOC 1 if:
- Your service processes, records, or modifies data that flows into a client’s financial statements
- Your client’s external auditor has specifically requested a SOC 1 or an “ICFR controls report”
- You are in payroll, payment processing, fund administration, loan servicing, or a similar financial operations role
You need a SOC 2 if:
- Your service stores, processes, or transmits client data, and the client wants assurance over your security posture
- You are responding to enterprise security questionnaires that ask for SOC 2 Type 2
- You are a SaaS, cloud, analytics, or managed services provider
- You want to demonstrate compliance with recognised security standards to accelerate sales cycles
A simple decision test: Ask yourself whether your client’s CFO and external auditor care about your service (SOC 1), or whether the client’s CISO and procurement team care about your service (SOC 2). Often, the answer is both.
When You Need Both
Some organisations need both a SOC 1 and a SOC 2 report. This is not uncommon, and it happens when the service has two distinct risk surfaces.
Consider a billing platform that processes invoices for enterprise clients. The invoice calculations feed directly into the client’s revenue recognition and accounts payable, which is a SOC 1 concern. At the same time, the platform stores customer payment data, contract terms, and usage records, which is a SOC 2 concern.
In these cases, attempting to address both concerns with a single report does not work. SOC 1 and SOC 2 have different scopes, different criteria, and different audiences. Running both audits in parallel is more efficient than running them sequentially, because the auditor can coordinate fieldwork and reduce duplication in testing overlapping controls.
Organisations in financial services that also need to demonstrate compliance with SOC 2 alongside other frameworks often benefit from a compliance platform that maps controls across multiple standards, reducing the documentation burden for each additional audit.
Frequently Asked Questions
What is the main difference between SOC 1 and SOC 2?
SOC 1 reports focus on internal controls over financial reporting. They are relevant when a service organisation processes transactions or hosts data that directly affects a client’s financial statements. SOC 2 reports focus on information security and operational controls, evaluated against the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The distinction comes down to what your clients need assurance over: the accuracy of their financial reporting, or the security of their data.
Can an organisation need both SOC 1 and SOC 2?
Yes. An organisation that processes financial transactions for clients and also stores or handles sensitive non-financial data may need both reports. A payroll platform that handles salary calculations (affecting client financial statements) and stores employee personal data (a security and privacy concern) is a common example. Each report addresses a different audience: SOC 1 for the client’s external auditor, SOC 2 for the client’s security and procurement teams.
Is SOC 2 more common than SOC 1?
In most sectors, yes. Enterprise security questionnaires overwhelmingly ask for SOC 2 Type 2 reports. Any SaaS, cloud infrastructure, analytics, or data processing company selling to enterprise buyers will encounter SOC 2 requests before SOC 1. SOC 1 remains essential in financial services, payroll, and any sector where the service directly touches a client’s general ledger.
What is the difference between Type 1 and Type 2 SOC reports?
A Type 1 report evaluates whether controls are properly designed at a single point in time. A Type 2 report evaluates both the design and operating effectiveness of those controls over a period, typically three to twelve months. Type 2 is the stronger report because it proves that controls actually worked over time, not just that they existed on paper. Most enterprise buyers and auditors require Type 2.
How Copla Supports SOC Compliance Programmes
SOC readiness involves defining your control environment, mapping it to the relevant criteria, building the evidence base, and coordinating with your audit firm. Copla supports organisations through this process with a combination of platform automation and hands-on consultancy. The platform handles control tracking, evidence collection, and policy documentation, while Copla’s consultants help scope the engagement, identify gaps, and prepare teams for auditor fieldwork. For organisations pursuing SOC 2 alongside ISO 27001 or other frameworks, Copla’s cross-mapping capability means controls documented once can satisfy multiple standards without duplicating effort.
Schedule a call with Copla to walk through how this would look for your team.
