SOC 1 vs SOC 2 Key Differences

SOC 1 and SOC 2 sound like siblings, and they are, in a sense: same governing body, same underlying attestation framework. But they answer two different questions, and I've watched more than one company burn six figures on the wrong exam while the audience that actually needed assurance walked away empty-handed. This piece breaks down what each one tests, who actually needs which, and how the Type I versus Type II decision changes what you're paying for.

Neither report is a certification, and that distinction gets lost constantly. There's no seal, no badge, nothing you slap on a homepage. What you get is an auditor's opinion, built on evidence and testing and professional judgment, the same way a financial statement audit produces an opinion rather than a stamp of approval. Both reports fall under SSAE 18, the standard that replaced SSAE 16 back in 2017 and widened attestation coverage well past SOC 1 alone. From there the governing sections split: SOC 1 runs on AT-C Section 320, SOC 2 runs on AT-C Sections 105 and 205, and both operate at the reasonable assurance level under AT-C 205. Both are genuine opinions, carrying real evidentiary weight. The "SOC" label is where the confusion starts, because it's the same three letters slapped on two fundamentally different exams asking whether controls work, just aimed at different controls, for different people.

What a SOC 1 examination is actually evaluating

SOC 1 asks one narrow question: does this service organization have controls that protect the accuracy of its clients' financial statements? Data encryption and incident response plans sit outside that question entirely. The exam narrows down to one thing: can we trust the numbers flowing out of your systems and into our books?

The exam sits under AT-C Section 320, titled, formally, "Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting." Scope usually covers entity-level controls, process-level controls, and IT general controls like access management and change management. Here's the part that trips up people new to this: the service organization writes its own control objectives. There's no AICPA checklist handed down from above. Management decides what matters, and the auditor tests against those self-defined objectives rather than some universal standard.

Sounds like a loophole. It isn't, really; it's the whole point. Control objectives get built to cover a wide range of client companies at once, so each client doesn't need to send its own auditors in to poke around the vendor's systems. One exam, many downstream audiences. The report also documents Complementary User Entity Controls, or CUECs, which is auditor-speak for controls the service organization assumes the client is handling on its own end. A payroll processor might assume its client reviews reports for accuracy before submission; that assumption gets written into the report as a CUEC.

Then there's the subservice question. What happens when the service organization itself leans on a third party for part of the work? Two ways to handle it: the carve-out method, which excludes the subservice organization's controls from the report entirely, or the inclusive method, which folds them in. Worth saying plainly: SOC 1 isn't a legal requirement anywhere. Nobody's compelled by statute to get one, but contracts and client-side auditors ask for it so often that it becomes functionally mandatory for a lot of vendors, law or no law.

Which service organizations actually need a SOC 1

The threshold question is simple to state, harder to answer sometimes: does what this organization does have the potential to affect how clients prepare or report their financial statements? Yes, SOC 1 territory. No, look elsewhere.

Payroll processors are the textbook case; the data flows straight into payroll expense on a client's income statement, so a control failure on their end means the client's numbers are wrong. Loan servicers and mortgage banking platforms fit the same mold, since their transaction processing touches balances that lenders report directly. ERP and financial application providers matter because their system controls are what keeps general ledger data intact in the first place, and claims processors round it out, since claims payment data feeds straight into a client's liability accounts.

The logic underneath: outsourcing a process doesn't make the financial reporting risk disappear. It just moves the risk outside the company's own walls and into a vendor's systems, and someone still has to test whether the controls protecting that risk actually work. For public companies under SOX, external auditors will ask for SOC 1 reports from relevant vendors as part of ICFR testing. That's a standard request, not an unusual one. Private companies without a SOX mandate get real value out of the same review too, especially once they've got several vendors touching different links in the reporting chain. Internal audit teams lean on these reports heavily for third-party risk work, and there's a newer category worth watching: FinTech and tech-enabled financial services firms that never thought of themselves as "service organizations" in the old IT-and-payroll sense, but functionally are exactly that.

What a SOC 2 examination is actually evaluating

Flip the question. SOC 2 asks whether the service organization protects the data and systems its customers actually depend on, day to day, month to month.

This one runs on AT-C Sections 105 and 205, and the criteria come from the AICPA's Trust Services Criteria, a defined standard rather than management's own definitions the way SOC 1 works. Five criteria total. Security is the only mandatory one, and it contains the nine Common Criteria, CC1 through CC9. Availability covers uptime and performance commitments. Processing Integrity covers whether processing is complete, valid, accurate, timely, and properly authorized. Confidentiality protects information the organization has designated as confidential, and Privacy governs how personal information gets collected, used, retained, and eventually thrown out.

The architecture underneath is worth knowing. CC1 through CC5 map onto the COSO internal control framework, the same foundational structure that shows up in a lot of financial control work. CC6 through CC9 cover access controls, system operations, change management, and risk mitigation. Which of the optional criteria beyond Security actually show up in a given exam isn't the auditor's call, and it isn't the AICPA's either. It comes down to what the organization has promised customers in contracts and SLAs. Promise a specific uptime threshold and Availability probably belongs in the report; never make a processing integrity commitment, and there's no reason to test for one.

One more wrinkle: SOC 2+ extends the base exam to pull in other frameworks at the same time, commonly HIPAA, NIST CSF, or GDPR, so one examination can speak to several regulatory audiences instead of running separate exams for each. And the boundary on the other side is deliberate: SOC 2's design keeps it away from controls that affect financial reporting.

Who the SOC 2 audience actually is and why that shapes the exam

SOC 1's audience is financial auditors, CFOs, audit committees, people trying to figure out whether a vendor's controls protect the integrity of numbers that end up on someone else's financial statements. SOC 2's audience is a different crowd: customers, prospects, partners, procurement teams, regulators, people trying to figure out whether it's safe to hand this vendor their data and trust their systems to stay up.

That difference in audience changes what the report has to do. In vendor security reviews today, a sales rep saying "yes, we take security seriously" doesn't land anymore. Buyers want a third-party examined report behind that claim. Demand for SOC 2 has climbed steadily in industries where data handling and system reliability are the actual product, SaaS, cloud infrastructure, healthcare IT, FinTech. In those sectors a SOC 2 report doesn't just sit in a drawer somewhere; it gets attached to sales proposals and pulled up in due diligence calls. It's a compliance document and a sales asset, both at once.

SOC 1 reports live a quieter life. They circulate inside restricted financial reporting chains, between the service organization, the client's controllership function, and the client's external auditors. Nobody's posting a SOC 1 on a marketing page. Here's where the mismatch bites: hand a financial auditor a SOC 2 report and they still don't have the ICFR evidence they need to sign off on their own audit. Hand a security-conscious customer a SOC 1 and they've learned nothing about whether your systems stay up or your data stays protected. Picking the wrong one wastes the audit fee, sure, but worse, it leaves the actual audience with nothing.

How Type I and Type II apply to both exams — and what the difference costs

Type I and Type II sit independently from the SOC 1 versus SOC 2 choice; both types can be issued either way. A Type I report is a snapshot, an opinion that controls are suitably designed as of one specific date. A Type II report goes further and tests whether those controls actually operated effectively across a stretch of time, usually somewhere between six and twelve months.

Type II carries a lot more weight with sophisticated audiences. Financial auditors and enterprise procurement teams generally expect it, and the reason is straightforward: knowing controls looked good on paper on some Tuesday in March tells you a lot less than knowing they held up for eleven straight months. For SOC 2 specifically, the observation period tends to run continuously, one period ending right as the next begins, which turns evidence collection into a year-round habit instead of a scramble the week before the audit.

That continuity raises a real question: what covers the gap between when one period's observation window closes and the next report actually gets issued? Bridge letters solve exactly that problem. They're management attestations covering the interim gap, keeping the chain of assurance from breaking between cycles. A lot of organizations take a sensible path here: start with a Type I to establish the baseline, then move into Type II on the next engagement. That's reasonable sequencing, giving the organization time to prove design before it has to prove sustained operation.

Organizations that need both reports, and how to scope each one correctly

Some organizations genuinely live in both worlds at once, a real financial reporting impact on one side and a real data security obligation on the other. Neither audience is optional. Neither report covers for the other.

Take a benefits administration platform. It handles payroll deductions, squarely SOC 1 territory, and it also holds employee health information, which pulls in SOC 2's Privacy and Confidentiality criteria. Mortgage banking and loan servicing platforms land in the same dual-report bucket: transaction processing touches client financial statements directly, while borrower data handling touches privacy obligations that have nothing to do with financial reporting at all.

Getting the report type right is only half the job. Scoping each engagement correctly matters just as much. SOC 1 scope should map tightly to the specific processes that actually flow into user entity financial statements, not sprawl across the whole company just because it's easier to draw the line that way. SOC 2's Trust Services Criteria selection should reflect what's actually written into customer contracts and SLAs, not the broadest set of criteria grabbed just in case someone asks later. Over-scoping burns audit budget and piles up controls that need remediating for no real payoff. Under-scoping produces a report that's technically complete and still doesn't answer the question the audience showed up asking. Working with an auditor who understands both the financial reporting chain and the operational trust side, not just one, is what keeps these scoping mistakes from happening in the first place.

How to decide which exam your organization needs right now

Start with the audience. Everything else follows from that one answer. Who's actually asking for assurance, and what are they trying to evaluate? Financial auditors assessing your impact on their client's financial statements: SOC 1. Customers, partners, or regulators assessing your security posture and operational reliability: SOC 2. Genuinely both: plan for both exams, and scope each one on its own terms instead of forcing a single report to do two jobs at once.

A useful second check: look at what your contracts and client security questionnaires actually ask for. Vendor agreements usually name the report type outright, so half the guesswork disappears the moment somebody actually reads the language instead of assuming.

Industry signals help too, though they're not gospel. Payroll processors, loan servicers, claims administrators, and ERP providers point toward SOC 1. SaaS vendors, cloud providers, healthcare IT companies, and FinTech platforms point toward SOC 2. Mortgage banking, benefits administration, and financial data platforms deserve a harder look at both, since they tend to straddle the line.

The cost of guessing wrong isn't abstract. A SOC 2 report does nothing for a financial auditor's ICFR testing requirements, full stop, and a SOC 1 report answers none of a customer's security due diligence questions, no matter how well it's written. That mismatch doesn't just burn the audit fee; it leaves a real gap where assurance was supposed to be, and somebody downstream, an auditor, a customer, a regulator, ends up finding out the hard way, usually at a worse time than anyone would've picked. An experienced SOC examiner who's worked across both financial reporting complexity and operational trust complexity brings a kind of scoping judgment no checklist replicates on its own. Get the choice right and run the exam well, and the result is real trust built with the audience that actually needed it, rather than a technically valid document that just happens to answer a question nobody asked.