SOC 2, ISO 27001, and the audit theater buyers demand

# SOC 2, ISO 27001, and the audit theater buyers demand

A 40-person startup with no security engineer can still get a clean SOC 2 report in three months. A Fortune 500 procurement team will reject a vendor with brilliant security but no report at all. This is the paradox at the center of enterprise SaaS sales: the certificate matters more than the reality it supposedly certifies, at least at the gate.

Why buyers won't sign without it

Enterprise procurement and security teams face a problem of scale. A large company might use 300 to 3,000 SaaS vendors (estimate, varies widely by company size). Nobody has time to audit each one's security practices from scratch.

So they outsource trust to a report. SOC 2 (System and Organization Controls 2) is an attestation report created under standards from the AICPA (American Institute of Certified Public Accountants). It tells a customer: an independent auditor checked this vendor's controls against a defined framework and found them operating as claimed.

ISO 27001 is the international equivalent, a certification (not just a report) against a standard maintained by the International Organization for Standardization. It's more common as a baseline requirement for European and Asian enterprise buyers, while SOC 2 dominates US enterprise sales.

Without one of these, many procurement departments won't even route a vendor to legal review. It's a checkbox that unlocks the rest of the sales process, which is exactly why vendors chase the report before they chase actual maturity.

What SOC 2 actually tests

SOC 2 is built around five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. Almost every vendor includes security (mandatory) and picks a subset of the others based on what they sell.

There are two report types:

• Type I: tests whether controls are designed correctly, at a single point in time. Faster and cheaper, weaker signal.
• Type II: tests whether controls actually operated effectively over a period, typically 3 to 12 months. This is what sophisticated buyers ask for.

An auditor (a licensed CPACPACost Per Acquisition: the total cost to generate one customer or conversion, computed by dividing total spend by the number of acquisitions.Voir la définition complète → firm) samples evidence: did access reviews happen quarterly as documented? Were terminated employees deprovisioned within the stated SLA? Is there a documented incident response process, and was it followed during an actual incident?

Crucially, SOC 2 does not certify that a product is secure. It certifies that the company followed its own stated controls. If your policy says "we review access every 90 days" and you did that, you pass, even if 90 days is too infrequent for the actual risk.

ISO 27001: the same idea, different shape

ISO 27001 requires building an ISMS (Information Security Management System): a documented, risk-based framework covering asset inventory, risk assessment, and a mandatory set of controls drawn from Annex A (a catalog of roughly 93 controls in the 2022 revision, covering areas like access control, cryptography, and supplier relationships).

Key differences from SOC 2:

• ISO 27001 is a certification with a badge and a public certificate number, valid typically 3 years with annual surveillance audits.
• SOC 2 reports are private documents, usually shared under NDA with prospects, not published.
• ISO is more prescriptive about the management system itself; SOC 2 lets the company define its own control set within the trust criteria.

Many mature SaaS vendors hold both, because US enterprise buyers ask for SOC 2 and European or multinational buyers often require ISO 27001. Maintaining both is a real cost center: audit fees, internal compliance headcount, and tooling (like Vanta, Drata, or Secureframe) that automate evidence collection, commonly run into the tens of thousands of dollars annually even for mid-sized vendors (estimate, varies significantly by company size and auditor).

The trust boundary game

Here's where "audit theater" comes in. A SOC 2 report scopes a system boundary: the specific product, environment, or business unit the auditor examines. Vendors have strong incentive to narrow that boundary.

Concrete example: a company sells three products. Only the flagship product, hosted in a single well-managed AWS account, gets included in the SOC 2 scope. The two newer products, hosted in a messier legacy environment acquired via M&A, are excluded. The vendor still markets "we are SOC 2 compliant" company-wide, but the report only covers one-third of what a customer might actually buy.

This is legal. It's disclosed in the report's fine print (the "system description"), which almost no buyer actually reads in full. Sales teams lead with the AICPA logo; the scoping caveats live on page 4 of a 60-page PDF.

Other common gaming patterns:

• Timing games: getting a Type I report right before a big renewal cycle, then taking a year to produce the harder Type II.
• Control minimalism: choosing the fewest Trust Services Criteria possible (just "security") to reduce audit scope and cost.
• Auditor shopping: smaller, faster, cheaper CPACPACost Per Acquisition: the total cost to generate one customer or conversion, computed by dividing total spend by the number of acquisitions.Voir la définition complète → firms exist alongside the Big Four and mid-tier firms, and quality of scrutiny varies. There's no single public rating system for auditor rigor.
• Subservice organization carve-outs: if the vendor runs on top of AWS or GCP, those cloud providers' own controls are excluded from the vendor's report and covered separately (AWS and Google both publish their own SOC 2 and ISO reports). A weak vendor can lean on "our cloud provider is certified" while its own application-layer practices are thin.

None of this means the reports are worthless. It means they're a floor, not a ceiling, and a sophisticated buyer reads the system description and the exceptions noted by the auditor, not just the cover page.

For a primer on how the underlying framework is structured, the AICPA publishes an overview here: AICPA SOC 2 guide.

What good procurement actually checks

Security-mature buyers don't stop at "do you have SOC 2." They ask for:

1. The full report, not just a summary letter, and they read the auditor's exceptions section (noted deviations are common and not automatically disqualifying, but unexplained ones are a red flag).

2. The system boundary, to confirm it covers the actual product being purchased.

3. Sub-processor lists and whether critical vendors (cloud hosting, payment processing, customer support tooling) are in scope or carved out.

4. Evidence of penetration testing (third-party security testing of the live application), which SOC 2 does not always require but serious buyers expect annually.

5. For EU-linked deals, alignment with GDPR (General Data Protection Regulation) requirements around data processing agreements, which sit alongside, not inside, SOC 2 or ISO 27001.

This is also where vendor risk management platforms and questionnaires like SIG (Standardized Information Gathering) or CAIQ (Consensus Assessments Initiative Questionnaire, from the Cloud Security Alliance) come in, layering additional scrutiny on top of the base certification.

🎬 [VIDEO: "SOC 2 Explained" - https://www.youtube.com/results?search_query=soc+2+explained+audit - search for a current walkthrough of SOC 2 report structure and Trust Services Criteria; choose one from a recognized compliance automation vendor or auditor, since exact top results change over time]

The economics behind the theater

Why does this system persist despite its flaws? Because it's cheaper than the alternative for everyone involved.