SOC 2 for B2B SaaS companies selling to enterprise
Updated
For a B2B SaaS company, SOC 2 often starts with a deal: an enterprise prospect's security team sends a questionnaire and asks for the report. This page covers why enterprise buyers ask, which Trust Services Categories they commonly request, which other frameworks come up in the same reviews, and which of the 22 Policyseed policies reviewers read first.
Why enterprise buyers ask for SOC 2
- Enterprise procurement commonly includes a vendor security review, and a SOC 2 report is one of the standard documents requested in it.
- Large customers have their own audits and need evidence about the vendors that hold their data; your report is that evidence for their auditors.
- A report can shorten security questionnaires, because reviewers can map many of their questions to controls an independent auditor has already examined.
- Enterprise contracts commonly include security obligations, such as incident notification, uptime commitments and return or deletion of data at termination, that your policies and controls need to match.
Trust Services Categories commonly requested
Security is in every SOC 2 report. The other categories are optional and are added when customers ask for them or your contracts make commitments they cover. What follows is what enterprise buyers commonly request, not a rule; agree on the scope with your auditor before the examination period starts.
| Category | Why it comes up | In the generator |
|---|---|---|
| Security | Included in every SOC 2 examination. The common criteria cover governance, risk assessment, access, change management, monitoring, incident response and vendor risk. | Always |
| Confidentiality C1.1, C1.2 | Commonly requested because enterprise customers store business data in the product that their contracts define as confidential. | Yes |
| Availability A1.1, A1.2, A1.3 | Commonly requested when your contracts include uptime commitments or service level agreements. | Yes |
Other frameworks that come up, and how they relate to SOC 2
Each framework below is published by its own standards body or regulator; the links go to them. This is a general description, not legal advice: whether a law or contract applies to you is a question for counsel.
Standard security questionnaires
Enterprise reviewers use standard questionnaires, such as the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), or their own. A SOC 2 report does not remove the questionnaire, but many answers can point to a policy or to a section of the report.
Keep in mind: Answer what is true today. A questionnaire answer becomes a representation in the deal, and reviewers compare it with your report.
Sources: CSA STAR and the CAIQ (Cloud Security Alliance) · Draft questionnaire answers from your policies
ISO/IEC 27001
Customers outside the US commonly ask for ISO/IEC 27001 instead of, or as well as, SOC 2. ISO 27001 is a management system standard; an accredited certification body audits it and issues a certificate. The controls overlap substantially with SOC 2, so the same policies can support both.
Keep in mind: A SOC 2 report is not an ISO 27001 certificate, and an ISO 27001 certificate is not a SOC 2 report. Ask which one each customer accepts.
Sources: ISO/IEC 27001 (ISO) · SOC 2 to ISO 27001 mapping
Data processing agreements under the GDPR
If you process personal data on behalf of customers subject to the GDPR, they will ask you to sign a data processing agreement that covers the terms Article 28 sets out, including sub-processors and assistance with data subject requests.
Keep in mind: A data processing agreement is a contract, separate from SOC 2. A SOC 2 report can support the security commitments in it but does not replace it.
The 6 policies that matter most
All 22 policies apply to every company that uses them. These are the ones enterprise buyers read most closely, so review them first and make sure every statement matches how you actually operate. The template index lists the full set.
- P01 Information Security Policy: The first document reviewers commonly ask for; it names the owner, the scope and how the program is governed and reviewed.
- P03 Access Control Policy: Enterprise reviewers ask about single sign-on, multi-factor authentication, least privilege and access reviews for everyone with access to production and customer data.
- P16 Vendor and Third-Party Risk Management Policy: Your subprocessors become your customers' fourth parties; reviewers ask for the list and how each one was assessed.
- P13 Incident Response Policy: Enterprise contracts commonly set a notification window; this policy holds the process for meeting it.
- P14 Business Continuity and Disaster Recovery Policy: Backs uptime commitments with recovery objectives, documented procedures and tested restores.
- P07 Data Retention and Disposal Policy: Covers returning and deleting customer data at the end of a contract, a common clause in enterprise agreements.
What to select in the generator
These answers change the policy text for B2B SaaS companies. The other questions (company, product, tools, owners, review cadence) are the same for everyone.
| Question | Answer | What it changes |
|---|---|---|
| Trust services categories in scope | Confidentiality | Add it if your auditor has scoped it. The policies then add rules for identifying, protecting and disposing of information customers have shared under confidentiality terms. |
| Trust services categories in scope | Availability | Add it if your auditor has scoped it, typically because contracts include uptime commitments. The business continuity, logging and monitoring, and network policies, among others, then gain uptime, capacity and recovery wording. |
| Sensitive data handled | Personal data (PII) | Select it if the product stores your customers' users' names, emails or other personal data. It adds data processing agreement, retention and breach notification wording. |
| Key vendors and subprocessors | Your subprocessors: hosting, email delivery, support, analytics and error tracking | Named vendors appear in the vendor, incident response and privacy policies, matching the subprocessor list enterprise customers ask for. |
Questions an auditor may ask
Walkthrough questions in a SOC 2 examination follow the criteria, but the examples an auditor picks depend on what your product does. These are the kind that come up for B2B SaaS companies; the auditor interview prep sheet lists the questions per criterion with the sentences in your policies that answer them.
- Who has access to production and customer data today, and when was that access last reviewed?
- Can you walk through a recent production change from ticket to deployment, with its review and approval?
- How are employees onboarded and offboarded, and how quickly is access removed when someone leaves?
- Which subprocessors handle customer data, and how did you review each one?
- What are your recovery objectives, and when did you last test a restore?
- How do you meet the incident notification commitments in your customer contracts?
Free tools for this
- Trust page generator: A public security page that tells reviewers what you do and how to request the report.
- Security questionnaire answers: Free draft answers to a standard vendor security questionnaire from your policies.
- Questionnaire answering (Audit Kit): Upload a customer's own questionnaire and get draft answers with citations to your policies.
- SOC 2 timeline planner: A dated plan to line the report up with your sales pipeline.
- SOC 2 readiness self-assessment: A quick score and a prioritized list of gaps.
- System description template: A first draft of the section of the report enterprise reviewers read first.
Other industries
- SOC 2 for fintech startups
- SOC 2 for healthtech and digital health companies
- SOC 2 for AI and machine learning companies
- SOC 2 for developer tools and API companies
Frequently asked questions
- Do we need SOC 2 before selling to enterprise customers?
- Not always. Some buyers proceed with a completed questionnaire, a trust page and a date for your report; others will not sign without a report. Ask prospects early in the sales cycle so the SOC 2 timeline fits the deal.
- Should we get a Type I or a Type II report?
- A Type I report describes your controls as of a single date and can be available sooner. A Type II report also tests whether the controls operated over a period, such as six or twelve months. Enterprise buyers commonly ask for Type II, and some accept Type I for a first year.
- Should we add Availability and Confidentiality to the scope?
- Add them if customers ask for them or your contracts make commitments they cover. Each category adds criteria and evidence, so agree on the scope with your auditor before the examination period starts.
- Can we publish our SOC 2 report?
- SOC 2 reports are intended for users with enough knowledge of your system to understand them, such as customers and prospects, so companies commonly share them under a nondisclosure agreement. A SOC 3 report is a general-use summary designed to be published. A trust page can say how to request the SOC 2 report.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.