SOC 2 standardized security reporting, but it left the vendor in control of the system boundary and auditor selection. Understanding that structural gap helps vendors and buyers get the most value from the framework.

In 2010, I wrote about companies placing too much trust in providers’ SAS 70 reports. At the time, Gartner called the widespread misuse “deceptive and harmful.” Chris Schellman, who had led over 500 SAS 70 audits, clarified that the industry had been using it for something it was never built for. Turns out the AICPA was already building a replacement; SOC 2 was born.

SOC 2 introduced prescribed trust criteria, required management accountability, and gave buyers a basis for risk-informed decisions. Fifteen years later, familiar patterns have resurfaced.

SAS 70 wasn’t meant for security.

The AICPA issued SAS 70 in 1992 as a framework for auditors to report on controls at service organizations that could affect customers’ financial statements. Then Sarbanes-Oxley arrived in 2002. Public companies needed their vendors to demonstrate control effectiveness, and SAS 70 became the default.

Organizations began requesting and marketing SAS 70 reports for security assurance, well beyond the standard’s original design. SAS 70 had no prescribed control criteria. The provider chose which controls to include, and the auditor evaluated only what the provider put forward.

By the late 2000s, the market had turned “SAS 70 certified” into marketing language for something that was neither a certification nor a security standard. The gap between what SAS 70 was and how the market used it had grown too wide to ignore.

SOC 2 introduced the missing structure.

The AICPA issued SSAE 16 in 2010 (superseded by SSAE 18 in 2017), replacing SAS 70 with three distinct report types. SOC 2 addressed the security gap the market had tried to cover with SAS 70. SOC 1 continued financial controls reporting, and SOC 3 provided a public-facing summary of SOC 2.

Where SAS 70 let providers choose which controls to include, SOC 2 introduced the Trust Services Criteria for security, availability, processing integrity, confidentiality, and privacy. Unlike SAS 70, the new report required a written management assertion, making organizations formally accountable for the report’s claims.

SOC 2 became table stakes.

Enterprise buyers needed evidence of vendor security controls, and SOC 2 filled that gap as the cloud market grew. The framework’s adoption accelerated when compliance automation tools such as Vanta and Drata made it accessible to startups and smaller companies that previously couldn’t afford it.

Lower barriers changed what SOC 2 meant in practice. The report appeared in vendor questionnaires and RFPs as a checkbox, and for many companies the goal shifted from demonstrating a strong program to passing a binary check.

As a result, merely having a SOC 2 report no longer distinguishes a company. It’s the baseline expectation for SaaS providers selling to enterprises.

SOC 2 concerns start to surface.

Broader adoption put more weight on SOC 2’s structural gaps. Despite the improvements over SAS 70, the audited organization still defines the system boundary and selects the auditor. These choices drive the concerns I hear from fellow CISOs:

• The Trust Services Criteria prescribe what to evaluate, but the provider decides which systems and services the report covers and how controls address each criterion. Organizations have an incentive to optimize for controls that produce favorable evidence.
• The rigor of examinations varies across auditors. Auditors who work quickly and keep clients satisfied win repeat business at the expense of examination rigor. As a result, promises of “fast and easy” threaten SOC credibility.

The AICPA has responded by cataloging common examination deficiencies and requiring peer reviewers to examine firms’ SOC work. However, I’m not aware of any firm that has faced disciplinary action for lax examinations.

Use SOC 2 intentionally.

SOC 2 addressed real weaknesses in how the market used SAS 70, but the old pattern of treating reports as checkboxes persists.

SaaS companies have an incentive to draw scope boundaries that exclude their weakest processes and time observation windows to avoid known-bad periods. Controls might exist during the examination and atrophy once the report ships. These practices are the predictable result of letting the vendor define the scope and select the auditor.

Vendors that want their SOC 2 to carry weight should design controls around their actual product and threat model, not a default compliance template. And they should hold their auditors to high standards and avoid misrepresenting where the program actually stands.

From a buyer’s perspective, a SOC 2 report from a trusted audit firm offers visibility into a vendor’s security program. But due diligence requires not only reading control statements, but also asking which systems and processes were excluded from scope. If that boundary doesn’t match what you actually rely on, the assurance doesn’t either.