Walk through the security section of almost any SaaS company's website and you will see the badge: "SOC 2 Certified." It appears on landing pages, in security portals, on trust pages, and in sales decks. It is used by founders, by marketing teams, and by the companies that earned the credential doing legitimate, hard work to get there.
It is also wrong. SOC 2 is not a certification. There is no SOC 2 certificate. There is no body that certifies anything. The correct term is SOC 2 attested, or more precisely, that the organization has received a SOC 2 Type 2 attestation report from a licensed CPA firm.
This is not pedantry. When you are in a procurement conversation with a large enterprise and their security team asks you whether you are SOC 2 certified, and you say yes, and they follow up by asking who your certification body is, the distinction becomes immediately relevant. Understanding what SOC 2 actually is makes you more credible to sophisticated buyers and helps you present the credential accurately.
What SOC 2 Is
SOC 2 is an attestation engagement governed by the American Institute of Certified Public Accountants. The AICPA's attestation standards, specifically AT-C Section 205, define how the examination must be conducted. A licensed CPA firm examines your controls against the AICPA's Trust Services Criteria and issues a professional opinion in the form of a written report.
That report does not certify anything. It attests that, in the opinion of the CPA firm, your controls were suitably designed and operating effectively during the audit period. The firm's opinion is their professional judgment, backed by the evidence they gathered during fieldwork. The opinion can be unqualified (clean), qualified (with exceptions), or adverse.
The report has several components: the service auditor's report (the opinion itself), management's assertion, the system description, and for a Type 2 report, the description of the auditor's tests of controls and the results of those tests. The entire document can run from thirty pages to several hundred depending on scope and complexity.
What SOC 2 Is Not
SOC 2 is not a pass or fail. There is no passing score. There is an auditor's opinion, and the opinion can range from clean to qualified to adverse. A clean opinion does not mean your controls are perfect. It means the auditor found that your controls were suitably designed and operating effectively within the scope of the report.
SOC 2 is not an ongoing status. The report covers a specific time period, and once that period ends, the report is historical. Your SOC 2 Type 2 report from last year tells customers something about your controls during that period. It tells them nothing about today unless they can see that you have maintained a continuous audit program.
SOC 2 is not a government regulation. It is an industry standard created and maintained by the AICPA. There is no legal requirement to have SOC 2 in most industries (HIPAA is a different matter). The pressure to obtain it comes from customers, primarily enterprise procurement and security teams, who require it as a condition of doing business.
SOC 2 vs. ISO 27001: The Certificate Comparison
The confusion between SOC 2 and certification often arises because ISO 27001 does produce a certificate. This makes it useful to compare the two frameworks directly.
SOC 2
Governed by the AICPA. Produces an attestation report signed by a licensed CPA firm. No certificate. No expiry date on a credential. Covers a defined audit period, typically six to twelve months. Dominant in North America, widely accepted globally. Organized around Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy).
ISO 27001
Governed by the International Organization for Standardization. Produces a certificate issued by an accredited certification body. Certificate has a three-year validity period with annual surveillance audits. Organized around a risk-based Information Security Management System. Dominant in the UK, EU, Australia, Middle East, and Asia Pacific.
Both frameworks provide meaningful assurance about an organization's information security controls. They differ in structure, governance, and the form of the output. Many enterprise customers in the US require SOC 2. Many enterprise customers in the UK and EU require ISO 27001. Companies selling into both markets often pursue both.
Type 1 vs. Type 2: What the Difference Means
Within SOC 2, there are two types of report. Type 1 covers design effectiveness only: the auditor examines whether your controls are suitably designed as of a specific point in time. Type 2 covers both design and operating effectiveness: the auditor examines whether your controls operated as designed throughout a defined period, typically a minimum of six months.
Type 1 is useful as a first step for companies that have recently built out their control environment and want to demonstrate that the controls are in place. Most enterprise customers, however, require Type 2 because it demonstrates that controls actually operated over time. A Type 1 says the controls exist. A Type 2 says the controls worked.
If a customer asks whether you are SOC 2 Type 1 or Type 2, and you have a Type 1, do not represent it as equivalent to Type 2. Procurement teams and CISOs read SOC 2 reports. They know the difference. Misrepresenting the type of report you have creates a trust problem that is worse than not having Type 2 yet.
What the Report Covers and What It Does Not
SOC 2 covers the controls in scope at the time of the audit. It does not cover controls that are out of scope, even if those controls are relevant to your security posture. A SOC 2 report scoped to your production SaaS environment tells a customer nothing about your development environment, your HR systems, or your vendor management practices unless those are explicitly included in scope.
SOC 2 is also period-specific. A report covering January through December 2025 tells a customer about your controls during that period. A customer asking you about your current security posture in July 2026 is asking about something your 2025 report does not directly address. This is why enterprise security teams increasingly ask for your most recent report and want to understand the gap between the report period and today.
How to talk about your SOC 2 report accuratelySay: "We have a SOC 2 Type 2 attestation report from [CPA firm name], covering [period]. The report was issued under AICPA AT-C 205." Avoid: "We are SOC 2 certified." The second formulation implies a credential that does not exist and triggers follow-up questions you may not be prepared to answer.
What Enterprise Buyers Actually Want to Know
When an enterprise security team asks for your SOC 2 documentation, they typically want answers to four questions. Which Trust Services Categories are in scope? What was the audit period? Who issued the report? What findings or exceptions, if any, are noted in the auditor's opinion?
The answer to the first question tells them what they are trusting you with. A report that covers only Security is different from one that covers Security, Availability, and Confidentiality. The answer to the second question tells them whether the report is current. Most enterprise procurement policies require a SOC 2 report no more than twelve months old. The answer to the third question tells them whether they can rely on the CPA firm's professional judgment. And the answer to the fourth question is the one that most sales teams are least prepared to address.
Findings and exceptions in a SOC 2 report are not disqualifying by themselves. A report with a few minor exceptions and a clear remediation narrative is often more credible than a report that appears too clean. What matters is whether the exceptions have been addressed, whether the remediation is documented, and whether the control environment today is stronger than it was during the audit period. Having a clear answer to that question before a customer asks it is a material advantage in enterprise deals.
The Bridge Between Report and Ongoing Assurance
One of the structural limitations of SOC 2 is that the report is historical. The most rigorous version, a Type 2 covering twelve months, still tells your customer nothing about the thirteen months after the period ends. In practice, companies that have a strong continuous monitoring and evidence program can speak with confidence about their control environment today, not just during the last audit period.
This is precisely what the market is moving toward. Enterprise customers increasingly want not just a SOC 2 report but ongoing evidence of control effectiveness: access review records, incident response documentation, vulnerability management evidence, and vendor management records from the current period. The report becomes the foundation. The ongoing program is the actual assurance.
Understanding that SOC 2 is a report rather than a certificate reframes the question from "did you pass?" to "what does your current control environment look like?" That is a stronger position to be in, and it is the accurate one.