SOC 2 in Due Diligence: What Reviewers Check

Published July 26, 2026· Updated November 1, 2026·9 min read

The pattern worth noticing: the request list grows monotonically, and it grows fastest in the artifacts that take longest to produce. An observation period cannot be compressed. That is the entire argument for starting earlier than feels necessary, which we cover in SOC 2 readiness for fundraising startups.

Key Takeaways

•The pattern worth noticing: the request list grows monotonically, and it grows fastest in the artifacts that take longest to produce.
•The short version: reviewers check six things in a predictable order, and each one has a specific failure mode you can fix before anyone looks.
•For the next operating decision, compare SOC 2 before Series A with when a startup should start SOC 2.

The short version: reviewers check six things in a predictable order, and each one has a specific failure mode you can fix before anyone looks. A current Type II report with a clean opinion, no scope gaps around your core product, and exceptions that each carry a documented remediation will clear diligence.

A report with an expired observation window, a core product excluded from scope, or the same exception appearing two years running will not — not because it kills the deal, but because it changes the terms.

For the next operating decision, compare SOC 2 before Series A with when a startup should start SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.

For the operating scope, review SOC 2 system descriptions and SOC 2 management assertions. Use these resources to confirm responsibilities and the support included in a proposal.

How do investor and customer diligence differ?

SOC 2 gets scrutinized in two situations that feel similar and are not.

Enterprise procurement. A security or vendor-risk team reviews you as a prospective vendor. They are gate-keeping: the question is whether you can be approved, and the consequence of failure is a stalled or lost deal. Timelines are short, the reviewer is often junior, and the review is heavily checklist-driven — which means a missing artifact can block you even when your actual security is fine.

Investor and acquirer diligence. A fund's diligence team, or an acquirer's technical diligence workstream, reviews you as an asset. They are pricing risk rather than gate-keeping. The consequence of a weak finding is rarely a dead deal — it is a lower number, an escrow holdback, or a remediation covenant. Reviewers here are more senior and more willing to look past a checklist item if the underlying story is coherent.

The practical implication: procurement rewards completeness of artifacts, and investor diligence rewards coherence of the program. You need both, but if you are optimizing under time pressure, know which room you are in.

What gets requested, by stage?

What gets requested, by stage? — comparison
Stage	Typically requested	What is usually accepted instead
Pre-seed / Seed	Security questionnaire, policy set, pen test summary	Documented policies and a stated roadmap; SOC 2 rarely required
Series A	SOC 2 Type I or Type II, pen test report, policy set, subprocessor list	Type I plus a dated Type II plan
Series B+	SOC 2 Type II, pen test, incident history, BCDR test evidence, vendor-risk program	Type II with a bridge letter if the window has lapsed
Enterprise procurement	SOC 2 Type II, completed DDQ or SIG/CAIQ, pen test attestation, insurance certificates, DPA	Type I only in narrow, low-data-sensitivity cases
M&A technical diligence	All of the above, plus multi-year report history and exception trend	Nothing — this is the least flexible reviewer

The six things reviewers check, in order

1. Report type and scope

What they look at: The cover page and the system description boundary — Type I or Type II, which Trust Services Criteria are in scope, and which systems and products are covered.

How it fails: Security-only scope when the buyer cares about Availability or Confidentiality. Or a scope boundary that covers your primary application but excludes a newer product the buyer is actually purchasing.

Fix it first: Align scope to what you sell, not to what was cheapest to audit. If you have a legitimate exclusion, name it proactively and explain it. For the Type I versus Type II decision, see our comparison.

2. Observation period freshness

What they look at: The period covered, and the gap between its end date and today.

How it fails: The window closed months ago and there is no bridge letter covering the interval. This is the most common finding in the entire category, and the cheapest to prevent.

Fix it first: Keep a current bridge letter on hand as a standing artifact. Do not wait to be asked.

3. The auditor's opinion

What they look at: The opinion paragraph — unqualified, qualified, adverse, or a disclaimer.

How it fails: A qualified opinion with no accompanying explanation or remediation plan.

Fix it first: A qualified opinion is survivable when it arrives with context. Prepare a one-page explanation of what was qualified, why, and what has changed since.

4. Exceptions in the testing results

What they look at: The tables at the back that most sellers hope nobody reads. Reviewers read them.

How it fails: Exceptions with no management response. Worse, the same exception across consecutive reports — the clearest available signal that a control was documented rather than fixed.

Fix it first: Every exception gets a management response, a remediation owner, and evidence of closure. Track exception trend across years yourself, before an acquirer does it for you.

5. System description alignment

What they look at: Whether the narrative describes the company they are buying from. Reviewers cross-check it against your architecture docs, your marketing, and in M&A, engineering interviews.

How it fails: A description written eighteen months ago that no longer matches the product. Newly added infrastructure or a migrated data store that the narrative does not mention.

Fix it first: Treat the system description as a living document reviewed each cycle, not boilerplate carried forward.

6. Subservice organization monitoring

What they look at: How you manage your own vendors — the ones your controls depend on. Increasingly the most scrutinized item on this list.

How it fails: No vendor inventory, no evidence you review your critical subprocessors' own SOC 2 reports, and carve-outs that shift material risk to a subservice organization you cannot demonstrate oversight of.

Fix it first: Maintain a real vendor inventory with risk tiering and evidence of periodic review. Our vendor risk management guide covers the mechanics.

Sample due diligence questionnaire items

This is the part founders most want to see in advance. Below is representative DDQ language, grouped as reviewers group it. The phrasing varies by buyer, but the substance is remarkably stable — and a current Type II report answers a large share of it by reference, which is most of the commercial value of holding one.

Governance and program

Describe your information security program, including governance structure and the individual accountable for security.
Do you have a current SOC 2 Type II report? Provide the report and the period covered.
How frequently are security policies reviewed and approved, and by whom?
Describe your risk assessment process and provide the date of your most recent assessment.

Access control

Describe your authentication requirements, including MFA coverage across production systems and administrative interfaces.
How is privileged access granted, reviewed, and revoked? What is your offboarding process, and what is the maximum time between termination and access revocation?

Data protection

Is customer data encrypted in transit and at rest? Specify algorithms and key management.
Describe data segregation between tenants in your multi-tenant environment.
What is your data retention and secure deletion policy, and how is deletion verified?

Secure development

Describe your SDLC, including code review requirements and pre-production security testing.
When was your most recent third-party penetration test? Provide the report or an attestation letter.
How are dependencies and container images scanned for known vulnerabilities, and what are your remediation SLAs by severity?

Incident response and resilience

Describe your incident response plan and the last date it was tested.
If so, describe it and the remediation.
What are your RTO and RPO commitments, and when did you last test recovery?

Third parties

Provide a list of subprocessors with access to customer data and the purpose of each.
How do you assess the security posture of critical vendors, and how often?

Compliance and insurance

Which regulatory frameworks apply to your processing, and how do you demonstrate compliance?
Provide evidence of cyber liability coverage, including limits.

Standardized formats exist precisely because answering this repeatedly is expensive — the SIG and CAIQ are the two you will meet most often, and our guide to security questionnaires covers how they differ and how to build a reusable answer library. If questionnaire volume is already slowing your deals, fast-passing security questionnaires is the operational fix.

What reprices a deal rather than killing it?

In investor and acquirer diligence, weak security posture usually gets priced rather than used as a reason to walk. The four findings that most reliably move terms:

What reprices a deal rather than killing it? — comparison
Finding	Why it moves the number
Expired observation period, no bridge letter	Reads as an unmanaged program, not just a stale document
Qualified opinion with no remediation plan	Signals a known problem nobody owns
Core product excluded from scope	The thing being valued was never actually audited
Same exception across consecutive reports	Strongest available evidence that controls are documented, not operating

Each of these is preventable at close to zero cost with a few months of lead time. That asymmetry — trivial to fix in advance, expensive to explain under diligence — is the whole reason to treat this as standing work rather than a fire drill.

Build the standing folder before you need it

Companies that clear diligence quickly maintain a security folder the same way they maintain a financial data room: continuously, not on request. It contains the current SOC 2 report, a current bridge letter, the most recent penetration test report and attestation letter, the approved policy set with review dates, the vendor and subprocessor inventory, the most recent access review evidence, incident history, BCDR test results, and insurance certificates.

The reason this works is not organization for its own sake.

If diligence has already started and you do not have SOC 2

This is more common than the fundraising advice ecosystem admits, and it is workable. The sequence that holds up:

Disclose immediately, with a date. Discovered gaps are punished far more heavily than declared ones. A dated commitment is credible; a discovered absence is not.

Scope and start the observation period now. The clock is the only part you cannot accelerate, so start it before anything else.

Assemble interim evidence. Approved policies, a completed penetration test, and a control implementation status report demonstrate that the program exists even though the attestation does not yet. This is frequently enough for a buyer to proceed under a contractual commitment.

Consider Type I as a milestone, not a substitute. It shows controls are designed appropriately and gives the reviewer something dated to point to. Present it as a step toward Type II, with the Type II date named.

For what this looks like executed under real deal pressure, see our B2B SaaS enterprise deal case study, and for the regulated end of the spectrum, what enterprise banks expect.

AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.

Frequently Asked Questions

What do investors actually check in a SOC 2 report?

Reviewers work through six things in roughly this order: the report type and whether it is Type I or Type II, whether the observation period is current, the auditor's opinion, the exceptions listed in the testing results, whether the system description matches the product actually being sold, and how you monitor your own subservice organizations. Most reviewers spend more time on the exceptions section than on anything else, because that is where the report stops being marketing.

Is a SOC 2 Type I report enough for due diligence?

Sometimes, but it is treated as a milestone rather than an answer. Enterprise procurement teams and later-stage investors generally want Type II, and will accept Type I with a credible, dated plan to complete Type II. Leading with Type I and no such plan reads as a gap.

What happens if our SOC 2 observation period has expired?

You need a bridge letter — a signed statement from management covering the period between the end of your report's observation window and today, affirming that no material changes or control failures occurred. An expired observation period with no bridge letter is one of the most common diligence findings and one of the easiest to fix in advance. Reviewers read its absence as a sign that nobody is actively managing the program.

Do exceptions in a SOC 2 report kill a deal?

Rarely on their own. Exceptions are normal and reviewers expect them — what matters is whether each one has a management response, a remediation plan, and evidence the fix happened. What does damage a deal is the same exception recurring across consecutive reports, which reads as a control that was never really fixed. Disclose exceptions early with the remediation already documented rather than letting a reviewer find them.

What is a vendor due diligence questionnaire and how does it relate to SOC 2?

A vendor due diligence questionnaire, or DDQ, is a structured set of security and operational questions a buyer sends before signing. A current SOC 2 Type II report answers a large share of a typical DDQ by reference, which is most of its commercial value — instead of answering a hundred questions individually, you point to the relevant sections of your report. Standardized formats like the SIG and CAIQ exist to make this mapping easier.

What if enterprise diligence starts and we do not have SOC 2 yet?

Disclose it immediately with a dated plan rather than letting it surface later. In practice the workable path is to scope the audit, start the observation period, and give the buyer a documented timeline plus interim evidence — policies, penetration test results, and your control implementation status. Buyers routinely proceed on a credible commitment; what they react badly to is discovering the gap themselves after weeks of diligence.

Tyler Carbone

Managing Director and Cofounder

Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.