SOC stands for System and Organization Controls, a suite of attestation reports developed by the AICPA. SOC 1, SOC 2, and SOC 3 are the three you'll encounter most, and SOC 2 is the one security teams almost always request during vendor review. These are CPA-issued attestation reports performed under SSAE 18 and AT-C standards, not certifications, and not the security operations team monitoring alerts down the hall.
TL;DR:
- Most vendors only provide SOC 2 reports, which evaluate controls based on Trust Services Criteria like security, availability, confidentiality, and privacy.
- A Type 2 report covers both control design and operational effectiveness over a recent period, usually six to twelve months, and is preferred for security assessments.
- Vendors often scope controls to only certain criteria, so reviewing the system description and scope is crucial to identify potential gaps in confidentiality or privacy coverage.
- Public SOC 3 summaries do not include detailed control testing and should not replace a full SOC 2 report when detailed evidence is needed.
- Check that the SOC 2 report is recent, covers the correct system, and review the management responses to any testing exceptions before finalizing a vendor review.
Table of Contents
- Who Issues SOC Reports and Why the Framework Exists
- SOC 1 vs SOC 2 vs SOC 3: Which Report Do You Actually Need?
- Trust Services Criteria: What Your Questionnaire Is Actually Asking
- Type 1 vs Type 2: What Each One Actually Proves
- How to Read a SOC 2 Report During Vendor Assessment
- Why the SOC Framework Exists in the First Place
- SOC 2 vs ISO 27001 and PCI DSS: What's Actually Different
- What a SOC Report Doesn't Tell You
- Three Things to Check Before You Close a Vendor Review
- Stop Re-Answering the Same SOC Questions Every Quarter
- Sources
- FAQ
Who Issues SOC Reports and Why the Framework Exists
The AICPA built the SOC framework to solve a specific problem: how do you prove your controls work without letting every customer walk through your data center? Independent CPA firms, not the vendor itself, issue these attestation reports, which is what gives them weight in a vendor review.
The engagements run under SSAE 18 and its related AT-C sections, the auditing standards that dictate how an examiner plans, tests, and opines on a service organization's controls. That governance matters because it means the auditor's opinion carries professional liability behind it. A vendor claiming "we're secure" in a sales deck is a marketing statement. A CPA firm's opinion in a SOC report is a professional attestation.
This is why customers rely on SOC reports at all:
- Direct inspection of a vendor's infrastructure is rarely practical or scalable across hundreds of vendors.
- A licensed CPA firm's opinion substitutes for that inspection with independent, tested evidence.
- The report gives risk teams a paper trail they can defend to their own auditors and regulators.
SOC 1 vs SOC 2 vs SOC 3: Which Report Do You Actually Need?
Procurement teams and auditors don't always ask for the same thing, and mixing these up wastes weeks in a vendor review cycle. Here's how the three break down:
- SOC 1 covers internal control over financial reporting (ICFR). Your finance or internal audit team requests this when a vendor's system touches financial statement data, such as a payroll processor or a billing platform. Security teams rarely need it.
- SOC 2 evaluates controls against the AICPA Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. This is the report security and risk teams ask for in nearly every enterprise vendor questionnaire, because it speaks directly to how a vendor protects data and systems.
- SOC 3 is a public-facing summary of a SOC 2 report, stripped of the detailed control descriptions and testing results. Vendors post SOC 3 reports on marketing pages or trust sites because they can be shared freely, unlike SOC 2 reports, which are typically distributed under NDA.
Two related engagements show up occasionally and confuse people. SOC for Cybersecurity is a broader entity-level report on an organization's overall cybersecurity risk management program, not tied to a specific system. SOC for Supply Chain extends similar attestation logic to manufacturing and supply chain partners. Neither replaces a SOC 2 in a typical SaaS vendor review, but you may see them referenced in larger enterprise due diligence packages.
If a vendor hands you a SOC 3 when you asked for evidence of specific control testing, push back. The SOC 3 tells you a SOC 2 exists and passed, but it won't show you which controls were tested or how, and that's usually what your own risk committee wants to see.
Trust Services Criteria: What Your Questionnaire Is Actually Asking
Every SOC 2 report is built on five Trust Services Criteria, and only one of them is mandatory: security. The other four are optional, and auditors scope them in based on what the vendor's service actually does.
- Security (mandatory): access controls, network defenses, change management, incident response.
- Availability: uptime commitments, disaster recovery, capacity planning.
- Processing integrity: whether the system processes data completely, accurately, and on time.
- Confidentiality: protection of data designated as confidential under contract.
- Privacy: handling of personal information in line with stated notice and consent practices.
Pro Tip: When a questionnaire asks about SLAs or system uptime commitments, that's really an availability question in disguise. When it asks how you handle customer PII, that's confidentiality or privacy. Mapping questionnaire sections back to these five criteria makes it far easier to spot which parts of a SOC 2 report actually answer a given question.
A vendor whose SOC 2 covers security and availability but skips confidentiality isn't necessarily hiding something. It may simply mean their auditor scoped the engagement to match the service they sell. Still, if you're reviewing a vendor that handles sensitive customer data and their report excludes confidentiality entirely, that's worth a follow-up question.
This is also why SOC 2 Type 2 tends to be the more useful artifact for security teams specifically. A Type 1 tells you the controls were designed correctly on a given day. A Type 2 tells you those controls actually operated as designed over a testing window, which is closer to the assurance a security review is trying to get.
Type 1 vs Type 2: What Each One Actually Proves
A Type 1 report evaluates whether a vendor's controls are designed appropriately as of a single point in time, like a snapshot. A Type 2 report goes further: it tests whether those controls operated effectively across a defined period, commonly six to twelve months.
Most enterprise procurement teams expect Type 2, and for good reason. A Type 1 tells you the control design looked right on the day the auditor showed up. It says nothing about whether the vendor actually followed that access review process every month for the rest of the year. Relying on a Type 1 alone often just delays the inevitable, since your security team will likely circle back and ask for a Type 2 anyway once the initial review surfaces gaps.
Watch for these red flags when a Type 2 lands on your desk:
- Mismatched system description. The report's scope doesn't match the product or service you're actually buying.
- Expired reporting period. A Type 2 covering a period that ended more than a year ago tells you little about current control operation.
- Unexplained exceptions. Testing exceptions without a clear management response or remediation timeline.
Pro Tip: Don't just check the report's cover date. Check the reporting period itself. A SOC 2 Type 2 dated last month covering a period from two years ago is a stale artifact wearing a fresh cover page.
How to Read a SOC 2 Report During Vendor Assessment
A SOC 2 report is dense, sometimes 60 or more pages, and most of it isn't relevant to your specific decision. Work through it in this order:
- Confirm the auditor and opinion. Check the CPA firm's name and whether the opinion is unqualified, qualified, or adverse. An unqualified opinion is what you want to see.
- Check the type and period. Type 1 or Type 2, and whether the reporting window is recent enough to matter.
- Read the system description. Does the scoped system actually match the product you're buying, or a different part of the vendor's business?
- Review the criteria and controls tested. Confirm security is included, and check whether availability, confidentiality, or privacy apply to your use case.
- Scan the exceptions section. Note any testing exceptions and read the vendor's management response carefully.
Most SOC 2 reports are distributed under NDA, so expect to sign one before a vendor releases the full document; a public SOC 3 summary is what you'll get otherwise. When a report shows scope gaps or unresolved exceptions, that's the moment to request complementary evidence, such as a recent penetration test report or an ISO 27001 certificate. If exceptions are numerous or the remediation plan is vague and open-ended rather than time-boxed, escalate to your risk committee before signing anything.
Why the SOC Framework Exists in the First Place
The SOC suite didn't appear out of nowhere. It evolved from an older standard, SAS 70, which auditors originally designed for reviewing financial reporting controls at outsourced service providers, think payroll processors and data centers handling financial transactions on behalf of other companies.
As cloud computing and SaaS exploded, businesses needed a way to get assurance about security and operational controls, not just financial reporting. The AICPA responded by building out the modern SOC suite, splitting it into SOC 1 for financial reporting controls and SOC 2 for the broader security and trust criteria that cloud vendors actually needed to prove.
That split matters because it reflects a real shift in what "trust" means in a vendor relationship. Twenty years ago, the main question was whether a service provider's numbers could be trusted for your financial statements. Today, the dominant question is whether a vendor can keep your data safe, available, and handled the way they promised, which is exactly what SOC 2 and the Trust Services Criteria were built to answer.
The practical result for security and risk teams is a report standardized enough that a SOC 2 from one SaaS vendor and a SOC 2 from another follow the same structural logic, even though the specific controls differ. That consistency is what lets a compliance team build a repeatable review process instead of reinventing it for every vendor.
SOC 2 vs ISO 27001 and PCI DSS: What's Actually Different
Security teams frequently ask whether a SOC 2 report can substitute for ISO 27001 certification or PCI DSS compliance. The short answer: not directly, because they measure different things in different ways.
SOC 2 is an attestation report, an auditor's opinion on whether specific controls existed and operated effectively during a period. ISO 27001 is a certification against an international standard for an information security management system, granted by an accredited certification body, and it stays valid until the next surveillance audit rather than being tied to a testing window. PCI DSS is a compliance standard specific to organizations that handle payment card data, with prescriptive technical requirements set by the Payment Card Industry Security Standards Council.
A vendor can hold all three, and large enterprise vendors often do, because each answers a different question a procurement team might ask. SOC 2 answers "did your controls actually work over the last several months?" ISO 27001 answers "do you have a certified management system governing security?" PCI DSS answers "can you legally handle cardholder data?" None of them fully substitutes for another, though a vendor with ISO 27001 already in place often finds readiness for SOC 2 faster, since much of the underlying control documentation overlaps.
What a SOC Report Doesn't Tell You
A SOC 2 report is strong evidence, but it isn't a full security guarantee, and treating it that way is a mistake worth avoiding. The report only covers the systems and controls the auditor scoped in, which means anything outside that boundary, a newly acquired product line, a third subsidiary, an integration launched after the testing period, simply isn't addressed.
A clean Type 2 opinion tells you controls operated as designed during the testing window. It says nothing definitive about next month. Vendors can and do experience control failures or breaches shortly after a clean report, because the report is historical evidence, not a live security posture dashboard.
The Trust Services Criteria are also selectively scoped. If a vendor's SOC 2 only covers security and availability, you have zero attestation on confidentiality or privacy handling, even if the vendor processes sensitive personal data. Reading the system description carefully is the only way to catch that gap before it becomes a problem in your contract.
Finally, exceptions noted in the testing section don't automatically disqualify a vendor, and a report with zero exceptions isn't automatically safer than one with a few well-documented ones. What matters more is whether the vendor's management response addresses the root cause with a specific, time-boxed remediation plan rather than a vague promise to "review the process." A report is one input into a vendor risk decision, not the whole decision.
Three Things to Check Before You Close a Vendor Review
If you take one thing from this, take this: identify which SOC type your contract actually requires, confirm it's a Type 2 covering a recent period, and read the exceptions and management responses word for word. Those three checks catch most of the problems that surface later in a vendor relationship. For deeper guidance on reading and preparing SOC evidence, our breakdown of SOC 2 Type 1 vs Type 2 differences walks through report structure in more detail.
— Gaspard
Stop Re-Answering the Same SOC Questions Every Quarter
Every vendor review eventually comes down to the same request: send your SOC 2, then answer 150 more questions that the SOC 2 already covers. A Questionnaire Automation Tool can pull directly from your existing SOC evidence and prior answers to draft responses across any questionnaire format, so your team stops rewriting the same control descriptions for the fifth procurement team this month.
Beyond automating the questionnaire itself, Skypher's Trust Center gives you a centralized, customer-facing place to host SOC 2 reports, ISO certificates, and pen test summaries under controlled access, so prospects can self-serve the evidence instead of emailing your security team for the fourth time this week. For diligence-heavy reviews with detailed DDQs, the Fiduciary-Grade DDQ Automation tool handles the larger, more granular evidence requests that a standard questionnaire tool isn't built for. Pair that with 24/7 enterprise support, and your compliance team spends less time formatting answers and more time on the exceptions that actually need a human judgment call. Visit Skypher's platform to see how it fits into your current SOC evidence workflow.
Sources
- System and Organization Controls (SOC) suite of services — AICPA/CIMA
- SOC 1 vs SOC 2: Understanding the key differences — Aprio
- SOC reports explained: SOC 1, SOC 2 and SOC 3 — Warren Averett CPAs & Advisors
FAQ
What Does SOC Stand for in Security?
SOC stands for System and Organization Controls, an AICPA attestation framework that includes SOC 1, SOC 2, and SOC 3 reports. It is not the security operations center that monitors threats, a common mix-up in casual usage.
What Is an SOC Report Used For?
An SOC report gives independent, CPA-tested evidence of a vendor's controls, most often used in vendor risk reviews and procurement. Security teams typically request SOC 2, since it addresses the Trust Services Criteria most relevant to data protection.
Is SOC 2 a Certification?
No. SOC 2 is an attestation report issued by a licensed CPA firm, not a certification like ISO 27001. Calling it a "SOC 2 certification" is a common but inaccurate shorthand in vendor conversations.
Why Does SOC Security Software Matter for Compliance Teams?
Tools that centralize SOC evidence and automate questionnaire responses cut down the manual work of repeatedly proving the same controls to different customers. Skypher's Questionnaire Automation Tool and Trust Center are built specifically for that workflow, letting teams reuse SOC 2 evidence instead of rebuilding answers from scratch each time.
How Do I Know if I Need SOC 1 or SOC 2?
If your vendor's system affects your financial statement data, like payroll or billing platforms, finance teams typically need SOC 1. If you're evaluating a vendor's security and operational controls, which covers most SaaS and cloud vendor reviews, SOC 2 is the report to request.