SOC 1 vs SOC 2 vs SOC 3: what is the difference?

SOC 1, SOC 2, and SOC 3 are three different audit reports defined by the American Institute of Certified Public Accountants (AICPA). They are not tiers of the same report, and a higher number does not mean a stronger report. They answer different questions for different audiences. SOC 1 reports on controls that affect a customer's financial reporting. SOC 2 reports on controls related to security, availability, processing integrity, confidentiality, and privacy. SOC 3 is a short, public summary of a SOC 2 audit that you can hand to anyone without an NDA. The number identifies the subject matter and the audience, not the quality or rigor of the work.

For technical leaders and executives at regulated companies, the practical question is rarely "which report is best." It is "which report does my buyer's procurement team actually require, and what will it cost me to produce a clean one." Most B2B software and infrastructure vendors need SOC 2. Companies that touch their customers' financial statements, such as payroll processors and payment platforms, often need SOC 1. SOC 3 is a marketing and trust-page artifact that sits on top of an existing SOC 2. This post explains each report, how the audits work, what you get, and where the real effort and money go. We run this work as part of our GRC practice, so the guidance below reflects what we see on actual engagements rather than the textbook version.

What a SOC report actually is

A SOC report is an independent attestation produced by a licensed CPA firm. The CPA does not test your product the way a penetration tester does. The CPA tests whether the controls you claim to have are designed correctly and, in a Type 2 report, whether they operated as described over a period of time. The output is a formal report with the auditor's opinion, a description of your system, the controls you defined, and the tests the auditor performed against each control. SOC stands for System and Organization Controls. The reports exist because customers cannot send their own auditors into every vendor they use, so a trusted third party does the audit once and shares the result under controlled conditions.

This is the first thing leaders get wrong. A SOC report is a statement about your control environment, not a security guarantee and not a certificate. Unlike ISO 27001 certification, which results in a certificate issued by an accredited body, a SOC engagement produces a report and an opinion. There is no logo you earn and no pass or fail stamp. The auditor can issue an unqualified (clean) opinion, a qualified opinion with noted exceptions, an adverse opinion, or a disclaimer. Buyers read the report, including the exceptions, to decide whether they trust you.

SOC 1: controls over financial reporting

SOC 1 covers Internal Control over Financial Reporting, abbreviated ICFR. It exists because your service might sit inside your customer's accounting process. If you run payroll, process payments, host a general ledger, or handle claims that flow into a customer's financial statements, then your controls affect the accuracy of their numbers. Their auditors need assurance about your controls so they can sign off on their financial audit. SOC 1 is governed by the SSAE 18 attestation standard and is written for two narrow audiences: your customer's management and your customer's financial auditors.

The control objectives in a SOC 1 are defined by you, the service organization, based on what matters to financial reporting. There is no fixed catalog of criteria. A payroll provider might define objectives around the completeness and accuracy of payroll calculations, the authorization of changes to employee records, and the timeliness of tax remittance. The auditor tests the controls you put forward against those objectives. This makes SOC 1 scopes vary widely from one company to the next, which is by design.

• SOC 1 is the right report when your service feeds data into your customer's financial statements, such as billing, payroll, payments, or fund administration.
• The control objectives are self-defined and tied to financial reporting risk, not to a standard security framework, so two SOC 1 reports can look very different.
• The primary readers are your customer's auditors, who use it to reduce their own audit testing, not your customer's security team.
• A SOC 1 says little about your cybersecurity posture, so a clean SOC 1 does not satisfy a buyer asking about data protection.
• If procurement asks for SOC 1 and your product has nothing to do with their books, push back, because they likely meant SOC 2.

SOC 2: controls over security and the Trust Services Criteria

SOC 2 is the report most technology buyers mean when they say "send us your SOC report." It assesses your controls against the AICPA Trust Services Criteria, a defined set of criteria organized into five categories. Security is mandatory and forms the common baseline, often called the Common Criteria. The other four are optional and you include them based on the promises you make to customers. You do not earn points for adding categories you cannot support, so most companies start with Security alone and expand later.

• Security, the only required category, covers protection against unauthorized access, including access controls, change management, network defenses, and incident response.
• Availability addresses whether the system is available for operation and use as committed, covering monitoring, capacity, and disaster recovery.
• Processing Integrity addresses whether system processing is complete, valid, accurate, timely, and authorized, which matters most for transaction processing platforms.
• Confidentiality addresses how information designated as confidential is protected, covering encryption, retention, and disposal.
• Privacy addresses how personal information is collected, used, retained, disclosed, and disposed of in line with your stated privacy notice, and it is the most demanding category to add.

The Security criteria map closely to the controls our offensive and defensive teams test every day. The Common Criteria expect change management, logical access controls, vulnerability management, and monitoring. An auditor will ask whether you run regular vulnerability scans and penetration tests, but the auditor will not perform them. That gap is where many companies stumble. They produce a clean SOC 2 while carrying exploitable flaws, because the report confirms a control exists, not that the control is effective against a real attacker. We wrote more about that disconnect in SOC 2 is not security, and it is worth reading before you treat a report as proof of resilience. For the full readiness path, see our SOC 2 readiness guide.

SOC 3: the public summary

SOC 3 reports on the same Trust Services Criteria as SOC 2, but the report is short and general use. It contains the auditor's opinion and a brief system description, and it omits the detailed control descriptions and test results that make a SOC 2 sensitive. Because it does not expose the inner workings of your control environment, you can publish it on your website or hand it to a prospect without an NDA. There is no standalone SOC 3 audit in practice. You commission a SOC 2 and ask the auditor to also produce a SOC 3 from the same work.

SOC 3 is useful when you want a public trust signal. A SaaS company might post a SOC 3 on its security page so that early-stage prospects see evidence without a sales conversation. It does not replace SOC 2. Serious procurement teams will still request the full SOC 2 under NDA, because they need to read the exceptions and the auditor's specific tests. Treat SOC 3 as a top-of-funnel asset, not as the report that closes enterprise deals.

Type 1 versus Type 2: the distinction that matters most

The number after SOC tells you the subject. The word "Type" tells you the rigor. This distinction matters more to your buyer than SOC 1 versus SOC 2. A Type 1 report evaluates whether your controls are suitably designed at a single point in time. It is a snapshot. A Type 2 report evaluates whether those controls operated effectively over a period, usually three to twelve months. It is a movie. Both SOC 1 and SOC 2 come in Type 1 and Type 2 forms.

• A Type 1 report says your controls are well designed on a given date, which is fast to produce but carries limited weight with experienced buyers.
• A Type 2 report says your controls actually worked across a defined window, and it is the report enterprise procurement teams treat as credible.
• Many companies start with a Type 1 to enter the market, then move to a Type 2 to cover the following period, which is a reasonable sequencing.
• A Type 2 requires you to retain evidence continuously across the whole period, so you cannot fix a broken control the week before the audit and pass.
• If a prospect does not specify, assume they want a Type 2, because that is the default expectation in regulated B2B sales.

The number tells your buyer what you audited. The Type tells them whether to believe it.

How a SOC 2 engagement actually runs

The process is more predictable than most first-timers expect, but it is longer. From the decision to a clean Type 2 report, plan on six to twelve months, depending on how mature your controls already are. The CPA firm performs the attestation. A separate readiness partner, which is the role we play, prepares you so the audit goes smoothly. Keeping those roles separate matters, because the firm that audits you cannot also build your control environment without impairing independence.

• Scoping defines which systems, products, and Trust Services categories the report covers, and a tight scope keeps both cost and risk down.
• Readiness assessment, sometimes called a gap analysis, compares your current controls against the criteria and produces a remediation list.
• Remediation is the real work, where you implement access reviews, formalize change management, deploy logging, and write the policies the auditor expects to see.
• The observation period for a Type 2 begins once controls are in place, and you operate normally while collecting evidence for three to twelve months.
• Fieldwork is when the auditor samples your evidence, interviews your team, and tests each control, after which they draft the report and issue an opinion.

During remediation we often find that the technical controls a SOC 2 references have never been validated against an attacker. Logging exists but no one watches it. A patch policy exists but the external attack surface tells a different story. This is the point to run real testing rather than wait for an incident. Our offensive testing and managed detection and response work plug directly into the Security criteria, and a clean external attack surface review often surfaces issues that a control checklist never would.

What you actually receive

The deliverable is the report itself, typically thirty to one hundred pages. It contains five parts that buyers learn to read in a specific order. Understanding the structure helps you read your own report critically and helps your sales team answer questions during deals.

• The independent auditor's report states the opinion, and a clean unqualified opinion with no exceptions is what you want.
• Management's assertion is your formal statement that the system description is accurate and the controls are in place.
• The system description explains your services, infrastructure, software, people, and data flows in enough detail for a reader to understand scope.
• The controls and test results section lists each control, the auditor's test procedure, and the result, and this is where exceptions appear.
• Optional additional information lets you respond to exceptions or add context, and it is clearly marked as not covered by the auditor's opinion.

How SOC reports relate to other frameworks

SOC reports do not exist in isolation. If you sell into Europe or operate critical services, you are likely also navigating NIS2 and, in financial services, DORA, which has applied since January 2025. A SOC 2 will not satisfy those regulations on its own, because they impose specific obligations such as incident reporting timelines and third-party risk management that a SOC 2 does not cover. The control work overlaps, though, so a mature SOC 2 program gives you a head start.

The closest comparison buyers ask about is SOC 2 against ISO 27001. ISO 27001:2022 defines an information security management system and 93 Annex A controls across four themes, and it produces a certificate recognized internationally. SOC 2 produces a detailed report favored in North American B2B sales. Many companies pursuing global deals end up doing both, and the underlying controls overlap heavily. We compared them in detail in SOC 2 versus ISO 27001, which is the right next read if you are choosing between them. For the broader European picture, NIS2 explained sets out what regulated entities now owe.

Common mistakes and red flags

We see the same avoidable errors on most first SOC engagements. They cost time and money, and a few of them produce a report that is technically clean but commercially weak. Watch for these before you commit.

• Scoping the entire company instead of the relevant product, which inflates the audit, slows remediation, and produces a report buyers find hard to read.
• Treating the report as a security guarantee, when an unqualified opinion only confirms controls were designed and operated as described.
• Buying automation tooling and assuming the tool produces the report, when the tool only collects evidence and the auditor still tests and opines.
• Letting the same firm both build and audit your controls, which compromises auditor independence and can invalidate the engagement.
• Choosing a Type 1 to move fast, then being surprised when enterprise buyers ask for the Type 2 you have not started.
• Ignoring the exceptions section in your own report, which is exactly the section a sophisticated buyer reads first.

Cost and effort, honestly

Costs vary with scope, company size, and how much remediation you need, so treat ranges as directional rather than quotes. The auditor's fee is only part of the bill. The larger cost is internal time spent on remediation and evidence collection, plus the readiness partner and any tooling. A focused SOC 2 Type 2 for a small product is meaningfully cheaper than a multi-product, multi-region scope with Privacy included. The single biggest cost driver is the maturity of your controls on day one, because a company that already runs access reviews and change management has far less to build.

The way to control cost is to scope tightly, fix the technical gaps early, and not pay for a Type 1 you will immediately have to repeat as a Type 2. Spending on real testing during readiness usually saves money later, because finding an exploitable flaw before the observation period is far cheaper than handling an incident during it.

SOC 1, SOC 2, and SOC 3 are tools for different jobs, and choosing the right one starts with knowing what your buyer requires and what your controls can support. The harder work is making the controls real, not just documented, so the report reflects a system that holds up against actual attack. That is the work we do. Our GRC practice runs SOC 2 readiness, gap analysis, and evidence preparation, and our offensive and detection teams validate that the controls behind the report actually work. If you are scoping a SOC 2 or weighing it against ISO 27001, book a scoping call and we will map the shortest credible path to a clean report.