Learn · SOC 2 & questionnaires

SOC 2 Inheritance in a Vendor Security Questionnaire: What You Can (and Can't) Claim

A look at how SOC 2 reports can support vendor security questionnaire answers, and where inherited controls typically stop covering your own claims.

What "SOC 2 inheritance" means in a questionnaire context

A SOC 2 report describes the controls a service organization has in place, and — for a Type II report — whether those controls operated effectively over a defined review period, typically six to twelve months. When your product runs on top of other vendors (a cloud infrastructure provider, a data-warehouse provider, a payments processor), some of the controls that would otherwise apply to you are actually implemented and tested by that underlying vendor instead. "Inheritance" is the shorthand security teams use for relying on a subservice organization's own SOC 2 report to cover the portion of the control environment that vendor operates, rather than re-documenting and re-testing it yourself.

Auditors formalize this through two methods for handling subservice organizations in a SOC 2 report: the carve-out method, where the subservice organization's controls are excluded from the report's own testing and description, and the inclusive method, where the subservice organization's controls are described and tested directly as part of the report. Most SaaS companies built on major cloud infrastructure providers use the carve-out method — the cloud provider's own SOC 2 report covers its layer, and your report references that reliance rather than repeating it.

Carve-out method

Subservice organization's controls are excluded from your report's scope. Your auditor notes the reliance and lists the specific controls the subservice organization is expected to provide. You cite their report separately, for their layer only.

Inclusive method

Subservice organization's controls are tested directly as part of your own report — less common, typically reserved for closely integrated or wholly-owned subprocessors, since it requires the auditor to test the subservice organization's environment too.

When a questionnaire asks about a control that your infrastructure provider actually implements — physical access to a data center, for example — the accurate answer cites that provider's report for that specific control, not your own attestation.

Controls a SOC 2 report can typically support

The controls a SOC 2 report can credibly support depend entirely on which layer of your stack the report actually tests, and which Trust Services Criteria the report covers (Security is required in every SOC 2 report; Availability, Processing Integrity, Confidentiality, and Privacy are added at the service organization's discretion). Broadly, questionnaire answers that map cleanly to controls your infrastructure provider tests directly tend to be the safest to cite by inheritance.

Physical & environmental

Data center access

Badge access, visitor logging, environmental monitoring, and equipment disposal at the physical facility layer — tested in your cloud provider's own SOC 2 report if you don't operate your own data center.

Infrastructure layer

Host & network controls

Hypervisor patching, host-level network segmentation, and the provider's own vulnerability management program for the underlying platform, as distinct from the application you build on top of it.

Availability

Uptime & disaster recovery

Regional redundancy, backup infrastructure, and the provider's own tested failover procedures for the platform layer — provided the provider's report includes the Availability criterion.

Encryption

Platform-managed key services

Encryption of data at rest using the provider's managed key-management service, where the provider's report tests key rotation, storage, and access controls for that service.

In each case, the report you're citing has to actually test that control, cover the relevant Trust Services Criterion, and have a reporting period that overlaps the period the questionnaire is asking about. A report scoped only to Security doesn't support a Privacy-related answer, regardless of how the vendor markets it.

Where inherited coverage generally ends

Inheritance covers the layer the subservice organization actually operates — it does not extend upward into anything your own team builds, configures, or decides. Application-level authentication and authorization, your SDLC and code review practices, how your employees are onboarded and offboarded, your incident response process, your data retention and deletion practices, and your own vendor management program are yours to document and attest to directly. No infrastructure provider's SOC 2 report speaks to any of these.

Read the complementary user entity controls section. Every SOC 2 report that involves inherited or shared responsibility lists Complementary User Entity Controls (CUECs) — the specific things the report assumes you will implement for the tested controls to actually hold. A cloud provider's report might state, for example, that "user entities are responsible for configuring their own identity and access management policies." If you haven't implemented the control the CUEC describes, you can't rely on the provider's report to cover that gap — the report's assurance is conditional on you doing your part.

Reporting-period alignment is the other common edge. If your questionnaire response covers activity through the current quarter but the subservice organization's report period ended eight months ago, there's a gap between what you're claiming coverage for and what the report actually evidences. A careful reviewer will ask for the bridge letter or the current report before accepting the citation.

Common mistakes when citing a SOC 2 report

Most citation errors in vendor security questionnaires come from treating a report as broader, newer, or more definitive than it actually is. The most frequent ones:

  • Citing a subservice organization's report as your own attestation. "We are SOC 2 compliant" based solely on your cloud provider's report, with no report of your own covering the application layer, overstates what's actually been tested.
  • Treating a Type I report as if it were a Type II. A Type I report evaluates whether controls were suitably designed at a single point in time. A Type II report evaluates whether those controls operated effectively across a review period. They answer different questions, and a questionnaire asking about ongoing operating effectiveness isn't satisfied by a Type I alone.
  • Citing a report against a criterion it doesn't cover. Answering a Privacy or Processing Integrity question by pointing to a report scoped only to Security.
  • Skipping the CUEC section entirely. Assuming full coverage without confirming you've implemented the controls the report assumes you own.
  • Citing an expired or misaligned reporting period. Referencing a report whose period doesn't overlap the period the reviewer is actually asking about, without a bridge letter to close the gap.

These mistakes matter more, not less, once questionnaire drafting is partly automated. A vendor security questionnaire AI tool that drafts an answer citing "SOC 2 coverage" from a stored document still needs a human reviewer to confirm which report, which criterion, which control, and which period the citation actually supports — the drafting step can surface the right source, but it can't decide on its own whether that source actually proves the claim.

A SOC 2 report is not a certification. There is no pass/fail "SOC 2 certified" status issued by the AICPA or any accrediting body. A SOC 2 report is an independent auditor's opinion on a specific set of controls, for a specific period, against a specific scope. Precise citation — which report, which control, which period — is what makes a questionnaire answer defensible.