All stories

What SOC 2 and ISO 27001 prove in due diligence

A SOC 2 report proves that a company defined a set of security controls, and that an auditor checked whether those controls existed and operated over a period (Type II) or simply existed on a chosen day (Type I), within a scope the company itself defined. That is useful information, and it says nothing about whether the product is secure, the code sound, or the next incident unlikely. In SOC 2 due diligence, the recurring mistake is treating the badge as the finding.

ISO 27001 earns the same caveat from a different angle: it certifies a management system for information security, the process by which the company assesses and treats risk. A company can run that process sincerely and still ship an exposed admin panel.

What the certifications attest

SOC 2 is technically an attestation rather than a certification: an auditor examines controls against the Trust Services Criteria and writes an opinion. Management picks the scope, the criteria (many reports cover Security only) and the system boundaries. ISO 27001 certifies that an information security management system exists and functions: risk assessments happen, policies exist, internal audits run, management reviews occur.

Both attest to organizational process. Neither examines the codebase the way an attacker or a diligence engineer would. And both have become much cheaper and faster to obtain through compliance automation platforms, which is good for the industry and also means the floor a certificate guarantees is lower than most buyers assume.

How to read a SOC 2 report in due diligence

Ask for the actual report rather than the logo. It belongs in the technical data room, and reluctance to share it under NDA is itself informative. Then read five things:

  • The scope: which product, which entity, which criteria. A report covering one subsidiary or a marketing site attests to very little
  • The period, and any gap between the period’s end and today (bridge letters exist for a reason)
  • The exceptions: auditors record controls that failed testing, and a report with documented exceptions and remediations is often more credible than a spotless one
  • The carve-outs: subservice organizations, typically the cloud provider, whose controls are assumed rather than tested
  • The auditor: who they are, and whether the same firm also sold the readiness consulting

Fifteen minutes with the real report routinely changes what the badge appeared to say.

Where certified companies still fail

Incidents come from what the audit did not scope, or from what practice quietly dropped: secrets sitting in repository history, offboarding that misses contractor accounts, production access that spread to half the company, backups that have never been restored, the internal tool built outside the audited boundary. Controls can exist on paper and be exercised only in audit season.

Certification therefore shifts our expectations without shortening our checklist. We still sample reality: pick three leavers and test their access, ask how long a leaked key takes to rotate, ask for the date of the last backup restore. The method is the one we describe in security due diligence that fits a deal window, and it applies to certified targets unchanged. When the sampled reality matches the report, that is a strong signal about the company’s general honesty. When it does not, that gap is the finding.

When the absence of certification is fine

Certification is a question of stage. A seed-stage company with no enterprise customers and no regulated data does not need a SOC 2, and a rushed Type I bought for a sales logo proves little beyond the invoice. At that stage we would rather see solid security basics and a plan.

The absence stops being fine when the underwritten revenue depends on enterprise, healthcare or financial buyers in the near term. Then the missing certification is a sales blocker with a built-in delay, because a Type II requires an observation window measured in months before the report can exist. That belongs in the value-creation plan with a date and an owner rather than in the risk register as a vague worry. In those deals the adjacent compliance questions deserve their own pass too, starting with the GDPR gaps that surface after closing.

One last habit worth keeping: verify the claim itself. Certificates expire, scopes get described generously, and "SOC 2 compliant" on a website is marketing until the report says otherwise. Reading certifications for what they attest, then testing the ground under them, is standard scope in our technical due diligence, and one line of the full checklist we run on every deal.