SOC 1 vs SOC 2: Which Report Do You Need?

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.

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:

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 SOC report do you need?

The service determines which SOC report a company needs. Three questions settle it:

1. 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.
2. 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 the typical B2B SaaS product, the request will be for SOC 2.
3. Both true? Then plan for both reports. The overlap cases are common enough to get their own section, covered below.

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. In our experience this is the point of confusion that comes up most often 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.

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.

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 overlap 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 SOC 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.

Where both SOC reports fit in a security program

The controls behind either SOC 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.

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.