A SOC 1 report covers the controls at a service organization that are relevant to its customers' financial reporting, known as internal control over financial reporting (ICFR). A SOC 2 report covers how the organization protects the security, availability, confidentiality, processing integrity, and privacy of the systems and data customers entrust to it, measured against the AICPA Trust Services Criteria. Which one a company needs follows from what its service touches: customers' financial statements point to SOC 1, customers' systems and data point to SOC 2, and services that touch both often need both.
SOC 1 vs SOC 2 at a glance
- SOC 1: controls relevant to customers' financial reporting (ICFR), examined under SSAE 18 (AT-C section 320)
- SOC 2: security, availability, confidentiality, processing integrity, and privacy, measured against the Trust Services Criteria
- Who asks for SOC 1: the customer's finance team and its financial statement auditors
- Who asks for SOC 2: the customer's security, procurement, and vendor risk teams
- Type 1 and Type 2 exist for both: Type 1 is a point-in-time design review; Type 2 covers operating effectiveness over an observation period
- Some companies need both: payroll processors, claims processors, and fund administrators are common examples
Both reports come from the same AICPA System and Organization Controls family and both are issued by a licensed CPA firm. The what is a SOC report guide covers the full family, including SOC 3 and how the reports relate to each other.
What is the difference between SOC 1 and SOC 2?
SOC 1 and SOC 2 differ in subject matter, audience, and governing framework, not in rigor. The comparison:
| SOC 1 | SOC 2 | |
| What it covers | Controls relevant to customers' internal control over financial reporting (ICFR) | Security, availability, confidentiality, processing integrity, and privacy of systems and data |
| Who asks for it | The customer's finance team and its financial statement auditors | The customer's security, procurement, and vendor risk teams |
| Governing framework | SSAE 18, AT-C section 320; control objectives defined by the service organization | AICPA Trust Services Criteria (the CC-series common criteria plus optional categories) |
| Typical service organization | Payroll processors, fund administrators, claims processors, transaction processors | SaaS companies, managed service providers, data centers, IT service providers |
| Report types available | Type 1 (point in time) and Type 2 (period of time) | Type 1 (point in time) and Type 2 (period of time) |
The framework difference matters in practice. In a SOC 1, the service organization defines its own control objectives around the processing that affects customer financials, and the auditor examines controls against those objectives. In a SOC 2, the criteria are fixed: every report is measured against the same Trust Services Criteria, with Security (the common criteria, CC1 through CC9) mandatory and the other four categories added by choice.
What is a SOC 1 report?
A SOC 1 report exists so a customer's financial statement auditor can rely on a service organization's controls instead of testing around them. When a company outsources a process that feeds its financial statements, payroll being the classic example, its auditor still has to gain comfort over that process. A SOC 1 report, examined under SSAE 18 (AT-C section 320), gives the auditor that comfort: it describes the service organization's system, states the control objectives relevant to customers' financial reporting, and reports the auditor's opinion on the controls behind them.
This is why SOC 1 requests arrive through a different door than SOC 2 requests. A SOC 2 request comes from a security questionnaire or a procurement portal. A SOC 1 request tends to arrive near a customer's fiscal year end, often relayed from their audit firm, and often specifying a SOC 1 Type 2 covering a period that overlaps the customer's fiscal year.
Which report do you need?
The service determines the report. Three questions settle it:
- Can the service affect customers' financial statements? If the system calculates, processes, or records transactions that flow into customer financials (payroll amounts, fund valuations, claims payments, billing), the customer's auditors will eventually ask for a SOC 1.
- Do customers entrust systems or data to the service? If customers are trusting the organization to keep their data secure and their service available, which describes nearly every B2B SaaS product, the request will be for SOC 2.
- Both true? Then plan for both reports. The overlap cases are common enough to have a pattern of their own, covered below.
A practical shortcut: look at who is asking
A request from a customer's security or vendor risk team means SOC 2. A request from their finance team or external audit firm means SOC 1. When a deal contact forwards a vague request for a SOC report, asking which team it originated from usually resolves the ambiguity in one email.
What is the difference between Type 1 and Type 2?
SOC 1 versus SOC 2 is a question of subject matter; Type 1 versus Type 2 is a question of depth, and both SOC 1 and SOC 2 come in both types. This is the single most common point of confusion in SOC terminology, and it produces phrases like SOC 1 Type 2 and SOC 2 Type 2 that read like typos but describe four distinct reports.
| Type 1 | Type 2 | |
| What the auditor examines | Whether controls are suitably designed and in place at a point in time | Whether controls operated effectively over an observation period |
| Evidence burden | Point-in-time proof of design, mostly policy and process documentation with a handful of operational artifacts | Samples drawn across the whole period, proving the control ran continuously |
| Timeline | Weeks once controls are in place | Observation period of 3 to 12 months, plus audit fieldwork |
| What customers accept | A starting signal; buyers usually want Type 2 to follow | The standard ask from enterprise buyers and financial auditors |
The evidence difference catches teams off guard. In one SOC 2 readiness engagement, a head of IT could show that every server was patched and current, with screenshots on demand. When the conversation turned to proving that patching had happened consistently over the previous six months, there was nothing: no tickets, no timestamps, no historical trail. Type 1 asks whether the control exists today, and current-state screenshots answer it. Type 2 asks whether the control has been operating all along, and evidence that nobody collected at the time cannot be recreated. Teams that grasp this early build lightweight habits into existing workflows, a ticket as a receipt, a timestamped screenshot on a routine task, so the trail accumulates as the work happens.
Choosing the observation period
Three months is the minimum and fastest, but some enterprise buyers view it as thin, particularly in financial services and healthcare. Twelve months delays the report by nearly a year. Six months is the practical default for a first cycle: credible to enterprise buyers, and the Type 2 report lands roughly fifteen months from program kickoff. Subsequent audits typically move to a twelve-month period.
The same trade-off applies to SOC 1 Type 2, with one added constraint: customers' auditors prefer an observation period that covers as much of their fiscal year as possible. The SOC 2 timeline and cost guide walks through the full sequence from kickoff to report.
When does a company need both SOC 1 and SOC 2?
Services that process financially significant transactions through systems customers also depend on for security tend to need both reports. The pattern shows up in specific service types:
- Payroll and benefits processors. The calculations flow into customer financial statements (SOC 1), and the platform holds sensitive employee data that customers expect protected (SOC 2).
- Insurance claims processors. Claims payments affect customer financials; the claims platform holds policyholder data.
- Fund administrators. Valuations and investor accounting are core ICFR territory; the systems carry confidential investment data.
- Billing and transaction platforms. Revenue figures land in customer books; the platform itself is entrusted infrastructure.
Companies in this position rarely commission both reports at once. The sequencing tends to follow the requests: the report the biggest deal is waiting on comes first. The efficiency worth knowing in advance is that the two audits share a large evidence base. Access control, change management, and operations controls appear in both reports, so a program built once can feed both audits, and many firms will scope the two examinations together to test shared controls a single time.
When is neither report the answer?
A SOC report is a significant recurring investment, and some requests that sound like SOC requirements are satisfied by something smaller. Three cases come up in engagements:
- The customer needs a questionnaire response, not a report. Many vendor reviews are satisfied by a completed security questionnaire and evidence of specific controls. If no customer contract requires a SOC report, answering the questionnaire well costs a fraction of an audit.
- The market is outside North America. SOC 2 is a North American convention. Buyers in Europe, the UK, and much of Asia ask for ISO 27001 certification instead, and it travels better internationally. The ISO 27001 vs SOC 2 comparison covers how to choose when both markets matter.
- The request masks a specific control gap. Sometimes a customer asks for a SOC report because one incident or one gap worried them: no MFA on an admin portal, no breach notification terms. Fixing the named gap and evidencing it can unblock the deal without a twelve-month audit program.
Read the request behind the request
Commissioning a SOC 1 because a security team asked for proof of controls, or a SOC 2 because a financial auditor needed ICFR comfort, surfaces months later as a deal blocker with an audit already paid for. Confirming which team is asking, and what their contract requires, protects both the budget and the timeline.
Where both reports fit in a security program
The controls behind either report come from the same place: the roughly 19 security capabilities that make up an effective security program, spanning access control, change management, vulnerability management, incident response, vendor management, and the rest. A program built capability-first produces SOC 2 evidence as a byproduct of normal operation, and where SOC 1 scope overlaps (access to financial processing systems, change control over calculation logic, job scheduling and monitoring), the same program feeds both examinations.
The alternative, building controls backward from an audit checklist, produces the patch-management problem from earlier: work that happens but leaves no trail, controls that exist for the auditor rather than for the organization. Built the right way around, the reports stop being projects and become receipts, and the deals waiting on them stop waiting. What each report costs, and the four factors that drive SOC 2 pricing, follow directly from how much of that program already exists.
Get the Right SOC Report, Faster
An effective security program feeds SOC 1 and SOC 2 from the same evidence. See where yours stands.
Frequently Asked Questions
Can a company have both SOC 1 and SOC 2?
Yes, and companies whose services touch both customer financials and customer data commonly hold both. Payroll processors, claims processors, and fund administrators are typical examples. The two audits share substantial evidence, particularly access control and change management, so many firms scope the examinations together to reduce duplicate testing.
Is SOC 2 harder than SOC 1?
Neither is inherently harder; they demand different things. SOC 2 tests against the fixed Trust Services Criteria, which cover broad security territory. SOC 1 scope is narrower but the service organization must define its own control objectives around financial processing. For either report, Type 2 is the demanding step, because it requires evidence across an entire observation period.
What is SOC 1 Type 2?
A SOC 1 Type 2 is a report on controls relevant to customers' financial reporting, in which the auditor tests whether those controls operated effectively over an observation period, typically 6 to 12 months. Customers' financial statement auditors usually request Type 2 rather than Type 1, with a period covering as much of their fiscal year as possible.
Do investors ask for SOC 1 or SOC 2?
Usually neither directly. Investor due diligence tends to ask about security posture broadly, and a SOC 2 report is a convenient artifact to hand over. SOC 1 comes up in diligence mainly for companies whose product processes customer financial transactions, where acquirers want to know the report exists because enterprise customers will demand it.
How much do SOC 1 and SOC 2 cost?
Audit fees for either report commonly run from the low tens of thousands of dollars per year for a small, single-category scope to six figures for large or multi-report environments. Type 2 costs more than Type 1, and the first year adds readiness work: gap assessment, control build-out, and evidence collection tooling.
Do you need SOC 1 before SOC 2?
No. The reports are independent and neither is a prerequisite for the other. The order follows customer demand: whichever report the pending deals require comes first. Within each report, however, most first-time programs do a Type 1 before a Type 2, since Type 1 confirms control design before the observation period starts accruing.
Ready to Start Your Compliance Journey?
Get a clear, actionable roadmap with our readiness assessment.
Contact Us
About the Author
Former security architect for Bank of Canada and Payments Canada. 20+ years building compliance programs for critical infrastructure.
How Ready Are You for SOC 2?
Score your security program in under 5 minutes. Free.
Take the Scorecard