It usually starts with a single line in an email. A major prospect is ready to move forward, and their security team or their auditor asks you to send over "a SOC report," with no more detail than that. SOC 1 and SOC 2 sound almost interchangeable, they come from the same standards body, and the same auditors often handle both, so it's easy to chase the wrong one. The two reports prove different things to different people, and sorting out which one a customer means is the first step to answering them with confidence.
Trust is a crucial aspect of business success. Even with high quality products and services and a stellar sales pitch, your prospects still need to trust that you’ll protect their data and provide them with accurate financial information. Getting a SOC 1 or a SOC 2 report shows your potential customers that you’re trustworthy and reduces their risk of working with you.
But which SOC report do you need? In this article, we’ll cover the differences between SOC 1 and SOC 2 reports to help you determine which one is right for you.
Overview of SOC reports
SOC reports were developed by the American Institute of Certified Public Accountants (AICPA) as a way to verify data security or financial reporting practices to ensure that businesses are well-protected as they bring on new vendors. SOC stands for Service Organization Controls — these reports were designed for organizations that provide services to demonstrate their trustworthiness to clients.
A SOC 1 report details the controls your organization has in place for financial reporting. A SOC 2 report details your information security practices to ensure that your customer’s data will be safe under your care. SOC 1 and SOC 2 reports are most often requested from buyers in North America.
What are the different types of SOC reports?
There are three types of SOC reports: SOC 1, SOC 2, and SOC 3. Each one has its own purpose and requirements that must be met to.
A SOC 1 report is an audit of your financial reporting practices and details your controls for keeping accurate financial records. A SOC 2 report is an audit of your information security that details the controls you have in place to protect your user and customer data. A SOC 3 report also covers information security, however a SOC 3 report is designed for public viewing and is less detailed than a SOC 2 report as a result.
{{cta_withimage1="/cta-blocks"}}
What is SOC 1?
A SOC 1 report examines your internal control over financial reporting, often shortened to ICFR. Translated, it covers the controls at your company that could change the numbers on a customer's financial statements. If you run payroll for other businesses, process their payments, handle billing, or administer claims, your work flows into their books, and their auditors need assurance that your controls are sound before they sign off.
Here's what sets SOC 1 apart structurally. There's no fixed checklist of requirements. You and your auditor define the control objectives that fit the service you provide, then the auditor tests whether you meet them. That flexibility makes sense, because the controls that matter for a payroll processor look nothing like the controls that matter for a loan servicer.
The audience tells you a lot. A SOC 1 report exists mostly so your customers and their financial auditors can rely on your controls during their own audits. So when a request for a SOC report comes from a customer's finance or audit team, that's a strong signal SOC 1 is what they're after.
What is SOC 2?
A SOC 2 report measures your controls against the Trust Services Criteria, a set of five categories defined by the AICPA. Only one of them, Security, is required. The other four come into scope when they're relevant to what you've promised customers. Here are the five.
- Security: Protecting information and infrastructure from unauthorized access. This is the required Common Criteria that every SOC 2 includes.
- Availability: Keeping your service up and reachable as committed.
- Processing integrity: Making sure your processing is complete, accurate, and authorized.
- Confidentiality: Restricting access to information meant to stay private.
- Privacy: Handling personal information in line with your stated commitments.
A SOC 2 is an attestation, not a certification you pass or fail. The auditor reports on how well your controls meet the criteria you've scoped in. Its readers are the security, procurement, and risk teams at the companies buying from you, the people who run vendor reviews before a deal closes.
For most software companies, a SOC 2 has become the default ask. If you store, process, or move customer data, expect it to show up in nearly every enterprise security review, usually as a request for the Type 2 version we'll cover next.
What’s the difference between a SOC 1 and a SOC 2?
You've seen what each report covers on its own. The differences between them come down to five things, and once you can name these, it's easy to tell which report a given customer wants.
What they measure
SOC 1 examines your controls over financial reporting, the processes that can affect your customers' financial statements. SOC 2 examines your controls for security and data protection.
What they're measured against
SOC 1 uses control objectives you define with your auditor, with no fixed checklist. SOC 2 measures against the AICPA's five Trust Services Criteria, with Security required and the other four optional.
Who the report is for
A SOC 1 is written mainly for your customers' financial auditors, who rely on it during their own audits. A SOC 2 is written for your customers' security, procurement, and risk teams, who run vendor reviews before a deal closes.
Who typically needs one
SOC 1 fits companies whose work flows into customers' books, like payroll, billing, and payment processors. SOC 2 fits companies that store, process, or move customer data, like SaaS and cloud providers.
The governing standard
SOC 1 falls under SSAE 18, AT-C 320. SOC 2 falls under SSAE 18, AT-C 105 and AT-C 205.
Type 1 versus Type 2 is a common source of confusion here, but it isn't a difference between the two reports. Both SOC 1 and SOC 2 come in a Type 1 and a Type 2 version, so that distinction sits inside each report rather than between them. We'll cover it next.
SOC Type 1 vs. SOC Type 2 report
A SOC Type 1 report details your controls at a single point in time. It shows how your controls were implemented but doesn’t include information on how effective they are.
During a SOC Type 2 audit, your controls will be monitored over a period of time to test how effective they are. The results of these tests will be included in your SOC Type 2 report.
Who gets a SOC report?
What types of organizations get a SOC report? It largely depends on the products and services your organization provides and the type of customers you serve.
A SOC 1 is for organizations that may impact their customers’ financial reporting. This is important for your customers because if they report inaccurate numbers due to your miscalculations, they could face charges of fraud and lawsuits. A SOC 2 audit is intended for organizations that handle user or client data, as the audit ensures that you have the practices in place to keep that data secure.
How to determine if you need a SOC 1 or SOC 2 report
Most explanations of these reports stop at "it depends on your data." That's not wrong, but it's not enough to act on. The faster route to the right answer usually starts somewhere more concrete. Look at who's asking, and why.
Two questions resolve almost every case.
First, who is requesting the report? If the request comes from a customer's finance or audit function, they're worried about their financial statements, which points to SOC 1. If it comes from a customer's security, procurement, or risk team, they're worried about data protection, which points to SOC 2.
Second, what do you do for that customer? If your service can change the numbers on their financial statements, such as running their payroll or processing their payments, SOC 1 is in play. If you store, process, or move their data, SOC 2 is in play.
For most companies, both questions point the same direction. A typical SaaS business touches customer data and gets asked by security teams, so SOC 2 is the answer. A payroll processor touches customer financials and gets asked by auditors, so SOC 1 is the answer. The cases that need more thought are the ones where the two questions disagree, or where different customers ask for different things. That's usually a sign you need both.
A word of caution. A SOC 2 does not cover a SOC 1, and a SOC 1 does not stand in for a SOC 2. They examine different controls for different audiences. When you're unsure, the data question is the better default, since most software companies handle customer data and will need a SOC 2 regardless.
When you need both SOC 1 and SOC 2
If you've landed on "both," the good news is that the two audits share more ground than their separate standards suggest. There's no single combined report. SOC 1 and SOC 2 stay distinct, each with its own scope and opinion. But the underlying controls overlap, and that overlap is where the savings live.
General IT controls show up in both reports. Access management, change management, and monitoring all matter whether the auditor is looking at financial reporting or data protection. The evidence you collect to satisfy one report often satisfies the other, so you're not building two separate piles of documentation from scratch.
The practical move is to run the engagements together. A single CPA firm can scope both at once, reuse the shared evidence, and test the common controls one time. That's faster and less expensive than two sequential audits, and it spares your team from answering the same questions twice. Platforms that cross-map controls across frameworks make this easier still, since one set of evidence can map to several requirements at once. Vanta, for instance, cross-maps controls across more than 35 frameworks, which cuts duplicate work when reports lean on the same underlying controls.
If both reports are on your roadmap within a year, raise parallel scoping with your auditor early. Sequencing them on purpose beats discovering the overlap after you've already paid for one.
How to read a vendor's SOC report
Plenty of readers reach this question from the other side of the table. You're not pursuing a report; a vendor just sent you theirs, and you have to decide whether it holds up. A SOC report can run dozens of pages, and the cover summary is the least useful part. Here's where to look.
Start by confirming it's the right report for your concern. If you're evaluating how a vendor protects your data, you want a SOC 2, not a SOC 1. Then check the type. A Type 2 tells you the controls operated over a period; a Type 1 only tells you they existed on one day, which is weaker assurance for a vendor you're trusting with sensitive data.
Read the scope next. For a SOC 2, see which of the five criteria the report covers, since a report scoped to security alone says nothing about how the vendor handles availability or privacy. Check the period the report covers and how recent it is, because a report from two years ago tells you little about today.
Finally, read the auditor's opinion and any exceptions the auditor noted, not just the headline. A qualified opinion or a list of exceptions is exactly the detail a vendor review should surface. When a report's period ended months ago, ask for a bridge letter, a short statement from the vendor affirming nothing material has changed since. Tools built for vendor risk management, Vanta's among them, are designed to collect and assess these reports so security teams aren't reading hundreds of pages by hand.
How to prepare for a SOC 1 or SOC 2 audit
Getting either report follows the same arc, and most of the work comes early. Start with a readiness assessment, a gap analysis that compares your current controls against what the report requires so you know what to fix before an auditor shows up. Close those gaps, formalize the policies that back your controls, and assign a clear owner to each one so nothing slips.
The heaviest lift is evidence collection. Auditors want proof that your controls ran, and gathering that proof by hand eats weeks. This is where compliance automation earns its keep, by pulling evidence continuously from the tools you already use. Platforms like Vanta automate that collection and run continuous tests across your environment, which shortens prep and keeps you ready between audits rather than scrambling before each one. If you want the full task list, our SOC 2 compliance checklist walks through it step by step.
One planning note. A Type 2 needs a monitoring window, so work backward from the date you need the report. If a customer wants a Type 2 in six months, the clock on your observation period is already running.
How to get a SOC 1 or SOC 2 report
Choosing between SOC 1 and SOC 2 comes down to two things you can settle quickly. Who is asking, and what you do for them. When a customer needs to protect their financial statements, they'll want a SOC 1. When they need to protect their data, they'll want a SOC 2. For most companies both answers line up, and a growing number find they need both reports to satisfy customers who ask for different things.
The harder part tends to come after the decision. Whichever report you pursue, you'll map your controls, close the gaps, formalize the policies, and gather proof that those controls ran, and a Type 2 adds a monitoring window of several months on top. Done by hand, that work stretches across weeks and pulls your team away from building the product. Waiting until a customer asks only tightens the timeline, which is why the companies that move fastest start preparing before the request arrives.
That manual grind is exactly the work Vanta automates. The platform pulls evidence continuously from the tools you already run, cross-maps your controls so the effort behind a SOC 1 carries into a SOC 2 and dozens of other frameworks, and monitors those controls all year so you stay ready for audits instead of scrambling before each deadline. It even reads and assesses the SOC reports your own vendors send, so you're covered on both sides of the trust conversation. See how Vanta can get you to SOC 1, SOC 2, or both faster with a demo.
{{cta_simple1="/cta-blocks"}}
SOC differences and similarities
SOC 1 vs. SOC 2: Which one do you need?
SOC differences and similarities
SOC 1 vs. SOC 2: Which one do you need?
Download the checklist
Looking to automate SOC 2 audit prep?
It usually starts with a single line in an email. A major prospect is ready to move forward, and their security team or their auditor asks you to send over "a SOC report," with no more detail than that. SOC 1 and SOC 2 sound almost interchangeable, they come from the same standards body, and the same auditors often handle both, so it's easy to chase the wrong one. The two reports prove different things to different people, and sorting out which one a customer means is the first step to answering them with confidence.
Trust is a crucial aspect of business success. Even with high quality products and services and a stellar sales pitch, your prospects still need to trust that you’ll protect their data and provide them with accurate financial information. Getting a SOC 1 or a SOC 2 report shows your potential customers that you’re trustworthy and reduces their risk of working with you.
But which SOC report do you need? In this article, we’ll cover the differences between SOC 1 and SOC 2 reports to help you determine which one is right for you.
Overview of SOC reports
SOC reports were developed by the American Institute of Certified Public Accountants (AICPA) as a way to verify data security or financial reporting practices to ensure that businesses are well-protected as they bring on new vendors. SOC stands for Service Organization Controls — these reports were designed for organizations that provide services to demonstrate their trustworthiness to clients.
A SOC 1 report details the controls your organization has in place for financial reporting. A SOC 2 report details your information security practices to ensure that your customer’s data will be safe under your care. SOC 1 and SOC 2 reports are most often requested from buyers in North America.
What are the different types of SOC reports?
There are three types of SOC reports: SOC 1, SOC 2, and SOC 3. Each one has its own purpose and requirements that must be met to.
A SOC 1 report is an audit of your financial reporting practices and details your controls for keeping accurate financial records. A SOC 2 report is an audit of your information security that details the controls you have in place to protect your user and customer data. A SOC 3 report also covers information security, however a SOC 3 report is designed for public viewing and is less detailed than a SOC 2 report as a result.
{{cta_withimage1="/cta-blocks"}}
What is SOC 1?
A SOC 1 report examines your internal control over financial reporting, often shortened to ICFR. Translated, it covers the controls at your company that could change the numbers on a customer's financial statements. If you run payroll for other businesses, process their payments, handle billing, or administer claims, your work flows into their books, and their auditors need assurance that your controls are sound before they sign off.
Here's what sets SOC 1 apart structurally. There's no fixed checklist of requirements. You and your auditor define the control objectives that fit the service you provide, then the auditor tests whether you meet them. That flexibility makes sense, because the controls that matter for a payroll processor look nothing like the controls that matter for a loan servicer.
The audience tells you a lot. A SOC 1 report exists mostly so your customers and their financial auditors can rely on your controls during their own audits. So when a request for a SOC report comes from a customer's finance or audit team, that's a strong signal SOC 1 is what they're after.
What is SOC 2?
A SOC 2 report measures your controls against the Trust Services Criteria, a set of five categories defined by the AICPA. Only one of them, Security, is required. The other four come into scope when they're relevant to what you've promised customers. Here are the five.
- Security: Protecting information and infrastructure from unauthorized access. This is the required Common Criteria that every SOC 2 includes.
- Availability: Keeping your service up and reachable as committed.
- Processing integrity: Making sure your processing is complete, accurate, and authorized.
- Confidentiality: Restricting access to information meant to stay private.
- Privacy: Handling personal information in line with your stated commitments.
A SOC 2 is an attestation, not a certification you pass or fail. The auditor reports on how well your controls meet the criteria you've scoped in. Its readers are the security, procurement, and risk teams at the companies buying from you, the people who run vendor reviews before a deal closes.
For most software companies, a SOC 2 has become the default ask. If you store, process, or move customer data, expect it to show up in nearly every enterprise security review, usually as a request for the Type 2 version we'll cover next.
What’s the difference between a SOC 1 and a SOC 2?
You've seen what each report covers on its own. The differences between them come down to five things, and once you can name these, it's easy to tell which report a given customer wants.
What they measure
SOC 1 examines your controls over financial reporting, the processes that can affect your customers' financial statements. SOC 2 examines your controls for security and data protection.
What they're measured against
SOC 1 uses control objectives you define with your auditor, with no fixed checklist. SOC 2 measures against the AICPA's five Trust Services Criteria, with Security required and the other four optional.
Who the report is for
A SOC 1 is written mainly for your customers' financial auditors, who rely on it during their own audits. A SOC 2 is written for your customers' security, procurement, and risk teams, who run vendor reviews before a deal closes.
Who typically needs one
SOC 1 fits companies whose work flows into customers' books, like payroll, billing, and payment processors. SOC 2 fits companies that store, process, or move customer data, like SaaS and cloud providers.
The governing standard
SOC 1 falls under SSAE 18, AT-C 320. SOC 2 falls under SSAE 18, AT-C 105 and AT-C 205.
Type 1 versus Type 2 is a common source of confusion here, but it isn't a difference between the two reports. Both SOC 1 and SOC 2 come in a Type 1 and a Type 2 version, so that distinction sits inside each report rather than between them. We'll cover it next.
SOC Type 1 vs. SOC Type 2 report
A SOC Type 1 report details your controls at a single point in time. It shows how your controls were implemented but doesn’t include information on how effective they are.
During a SOC Type 2 audit, your controls will be monitored over a period of time to test how effective they are. The results of these tests will be included in your SOC Type 2 report.
Who gets a SOC report?
What types of organizations get a SOC report? It largely depends on the products and services your organization provides and the type of customers you serve.
A SOC 1 is for organizations that may impact their customers’ financial reporting. This is important for your customers because if they report inaccurate numbers due to your miscalculations, they could face charges of fraud and lawsuits. A SOC 2 audit is intended for organizations that handle user or client data, as the audit ensures that you have the practices in place to keep that data secure.
How to determine if you need a SOC 1 or SOC 2 report
Most explanations of these reports stop at "it depends on your data." That's not wrong, but it's not enough to act on. The faster route to the right answer usually starts somewhere more concrete. Look at who's asking, and why.
Two questions resolve almost every case.
First, who is requesting the report? If the request comes from a customer's finance or audit function, they're worried about their financial statements, which points to SOC 1. If it comes from a customer's security, procurement, or risk team, they're worried about data protection, which points to SOC 2.
Second, what do you do for that customer? If your service can change the numbers on their financial statements, such as running their payroll or processing their payments, SOC 1 is in play. If you store, process, or move their data, SOC 2 is in play.
For most companies, both questions point the same direction. A typical SaaS business touches customer data and gets asked by security teams, so SOC 2 is the answer. A payroll processor touches customer financials and gets asked by auditors, so SOC 1 is the answer. The cases that need more thought are the ones where the two questions disagree, or where different customers ask for different things. That's usually a sign you need both.
A word of caution. A SOC 2 does not cover a SOC 1, and a SOC 1 does not stand in for a SOC 2. They examine different controls for different audiences. When you're unsure, the data question is the better default, since most software companies handle customer data and will need a SOC 2 regardless.
When you need both SOC 1 and SOC 2
If you've landed on "both," the good news is that the two audits share more ground than their separate standards suggest. There's no single combined report. SOC 1 and SOC 2 stay distinct, each with its own scope and opinion. But the underlying controls overlap, and that overlap is where the savings live.
General IT controls show up in both reports. Access management, change management, and monitoring all matter whether the auditor is looking at financial reporting or data protection. The evidence you collect to satisfy one report often satisfies the other, so you're not building two separate piles of documentation from scratch.
The practical move is to run the engagements together. A single CPA firm can scope both at once, reuse the shared evidence, and test the common controls one time. That's faster and less expensive than two sequential audits, and it spares your team from answering the same questions twice. Platforms that cross-map controls across frameworks make this easier still, since one set of evidence can map to several requirements at once. Vanta, for instance, cross-maps controls across more than 35 frameworks, which cuts duplicate work when reports lean on the same underlying controls.
If both reports are on your roadmap within a year, raise parallel scoping with your auditor early. Sequencing them on purpose beats discovering the overlap after you've already paid for one.
How to read a vendor's SOC report
Plenty of readers reach this question from the other side of the table. You're not pursuing a report; a vendor just sent you theirs, and you have to decide whether it holds up. A SOC report can run dozens of pages, and the cover summary is the least useful part. Here's where to look.
Start by confirming it's the right report for your concern. If you're evaluating how a vendor protects your data, you want a SOC 2, not a SOC 1. Then check the type. A Type 2 tells you the controls operated over a period; a Type 1 only tells you they existed on one day, which is weaker assurance for a vendor you're trusting with sensitive data.
Read the scope next. For a SOC 2, see which of the five criteria the report covers, since a report scoped to security alone says nothing about how the vendor handles availability or privacy. Check the period the report covers and how recent it is, because a report from two years ago tells you little about today.
Finally, read the auditor's opinion and any exceptions the auditor noted, not just the headline. A qualified opinion or a list of exceptions is exactly the detail a vendor review should surface. When a report's period ended months ago, ask for a bridge letter, a short statement from the vendor affirming nothing material has changed since. Tools built for vendor risk management, Vanta's among them, are designed to collect and assess these reports so security teams aren't reading hundreds of pages by hand.
How to prepare for a SOC 1 or SOC 2 audit
Getting either report follows the same arc, and most of the work comes early. Start with a readiness assessment, a gap analysis that compares your current controls against what the report requires so you know what to fix before an auditor shows up. Close those gaps, formalize the policies that back your controls, and assign a clear owner to each one so nothing slips.
The heaviest lift is evidence collection. Auditors want proof that your controls ran, and gathering that proof by hand eats weeks. This is where compliance automation earns its keep, by pulling evidence continuously from the tools you already use. Platforms like Vanta automate that collection and run continuous tests across your environment, which shortens prep and keeps you ready between audits rather than scrambling before each one. If you want the full task list, our SOC 2 compliance checklist walks through it step by step.
One planning note. A Type 2 needs a monitoring window, so work backward from the date you need the report. If a customer wants a Type 2 in six months, the clock on your observation period is already running.
How to get a SOC 1 or SOC 2 report
Choosing between SOC 1 and SOC 2 comes down to two things you can settle quickly. Who is asking, and what you do for them. When a customer needs to protect their financial statements, they'll want a SOC 1. When they need to protect their data, they'll want a SOC 2. For most companies both answers line up, and a growing number find they need both reports to satisfy customers who ask for different things.
The harder part tends to come after the decision. Whichever report you pursue, you'll map your controls, close the gaps, formalize the policies, and gather proof that those controls ran, and a Type 2 adds a monitoring window of several months on top. Done by hand, that work stretches across weeks and pulls your team away from building the product. Waiting until a customer asks only tightens the timeline, which is why the companies that move fastest start preparing before the request arrives.
That manual grind is exactly the work Vanta automates. The platform pulls evidence continuously from the tools you already run, cross-maps your controls so the effort behind a SOC 1 carries into a SOC 2 and dozens of other frameworks, and monitors those controls all year so you stay ready for audits instead of scrambling before each deadline. It even reads and assesses the SOC reports your own vendors send, so you're covered on both sides of the trust conversation. See how Vanta can get you to SOC 1, SOC 2, or both faster with a demo.
{{cta_simple1="/cta-blocks"}}
Explore more SOC 2 articles
Introduction to SOC 2
Preparing for a SOC 2 audit
SOC 2 reporting and documentation
Streamlining SOC 2 compliance
SOC differences and similarities
Additional SOC 2 resources
Get started with SOC 2
Start your SOC 2 journey with these related resources.
The SOC 2 Compliance Checklist
Speed up SOC 2 audit prep with automation. This checklist shows how to simplify compliance, reduce audit friction, and unlock enterprise deals.
Vanta in Action: Compliance Automation
Demonstrating security compliance with a framework like SOC 2, ISO 27001, HIPAA, etc. is not only essential for scaling your business and raising capital, it also builds an important foundation of trust.
