SOC 2 has five Trust Services Criteria: Security, Availability, Confidentiality, Processing Integrity, and Privacy. Only Security is mandatory, and it is delivered through the Common Criteria (CC1 to CC9). The other four are optional categories you add when they match your customer commitments. Most SaaS startups start with Security plus Availability. A penetration test provides evidence for CC7.1 (Vulnerability Detection) and CC4.1 (Monitoring of Controls).
Your enterprise prospect asked for a SOC 2 report, and now your auditor is asking which Trust Services Criteria you want in scope. You nod along, but nobody has explained what these categories actually are or which ones you need. Pick too many and you inflate cost and evidence work for controls you do not have. Pick the wrong ones and you fail to cover a commitment a customer cares about.
This is the map. It covers all five criteria, what each one governs, which a Series A or B SaaS startup usually needs, and where an independent pentest fits in the framework. Once you have decided Type 1 or Type 2 (see our SOC 2 Type 1 vs Type 2 guide), scope is the next decision, and this is the article that gets you there.
Key Findings
- Five Trust Services Criteria exist; only Security is mandatory. Security is delivered through the Common Criteria, CC1 through CC9. Availability, Confidentiality, Processing Integrity, and Privacy are optional add-ons.
- The Common Criteria is nine control families. CC1 (control environment), CC2 (communication), CC3 (risk assessment), CC4 (monitoring of controls), CC5 (control activities), CC6 (logical and physical access), CC7 (system operations), CC8 (change management), CC9 (risk mitigation).
- Most SaaS startups need Security plus Availability. Add Confidentiality if you handle sensitive customer data under contract. Processing Integrity and Privacy are core-function additions, not defaults.
- A pentest maps directly to CC7.1 (Vulnerability Detection) and CC4.1 (Monitoring of Controls). It is independent evidence that you look for vulnerabilities and evaluate whether your controls work.
- More criteria means more cost and evidence. Scope narrow for your first report and expand when a specific customer or regulatory driver requires it.
The Two-Layer Structure You Need to Understand First
The single most common source of confusion is the relationship between “Trust Services Criteria” and “Common Criteria.” They are not two competing lists. They are two layers.
Trust Services Criteria (TSC) is the umbrella. It names five categories: Security, Availability, Confidentiality, Processing Integrity, and Privacy. These come from the AICPA, the body that owns the SOC 2 framework.
Common Criteria (CC1 to CC9) is what the Security category is made of. When you scope a SOC 2 report, Security is not optional, so the Common Criteria are always in your report. The other four categories, if you include them, layer their own additional criteria on top of the Common Criteria.
So the mental model is: every SOC 2 report contains the Common Criteria (that is Security). Then you choose whether to add Availability, Confidentiality, Processing Integrity, or Privacy, each of which brings a small number of extra criteria of its own.
The Common Criteria: What Security Actually Covers
The Common Criteria are nine families, CC1 through CC9. The first five (CC1 to CC5) are borrowed from the COSO internal-control framework and cover governance and organisational controls. The last four (CC6 to CC9) are the technical and operational controls engineers recognise. Here is what each family governs.
| Family | What it governs | Examples relevant to a SaaS startup |
|---|---|---|
| CC1 | Control environment | Board and management oversight, org structure, security responsibilities, background checks |
| CC2 | Communication and information | Security policies communicated internally and externally, objectives documented |
| CC3 | Risk assessment | Identifying and analysing risks to your objectives, considering fraud and change |
| CC4 | Monitoring of controls | Evaluating whether controls operate as intended, including independent testing and audits |
| CC5 | Control activities | Selecting and deploying control activities, technology controls, policy through procedure |
| CC6 | Logical and physical access controls | Authentication, authorisation, provisioning, deprovisioning, encryption in transit, malware protection |
| CC7 | System operations | Vulnerability detection, anomaly monitoring, event evaluation, incident response, recovery |
| CC8 | Change management | Authorising, testing, and approving infrastructure and software changes |
| CC9 | Risk mitigation | Risk mitigation activities and vendor (third-party) risk management |
For most SaaS startups, CC6, CC7, and CC8 are where the auditor spends the most time, because that is where engineering-owned evidence lives: access management, logging and monitoring, vulnerability handling, and the deployment pipeline.
A closer look at CC6 and CC7
These two families come up in almost every technical security conversation, so it is worth naming their sub-criteria precisely.
CC6 (Logical and Physical Access Controls) includes logical access (CC6.1), credential issuance (CC6.2), authorisation rights (CC6.3), physical access (CC6.4), access discontinuation (CC6.5), protection against external threats (CC6.6), transmission and movement of information (CC6.7), and controls against unauthorised or malicious software (CC6.8). A pentest finding like an authentication bypass maps to CC6.1. A missing TLS or CORS control maps to CC6.7.
CC7 (System Operations) includes vulnerability detection (CC7.1), anomaly monitoring (CC7.2), security event evaluation (CC7.3), incident response (CC7.4), and recovery activities (CC7.5). An outdated library with a known CVE that your monitoring did not catch maps to CC7.1, because the detection procedure did not identify the susceptibility.
We keep an internal canonical reference for these labels because getting them wrong in a report is exactly the kind of error that erodes trust with a technical buyer. If you want the auditor’s view of what a pentest report must contain, see SOC 2 pentest requirements.
The Four Optional Categories
Security is mandatory. The remaining four are added only when they match a commitment you make to customers. Here is when each one earns its place in your scope.
Availability
Availability covers your commitments about uptime, performance, and disaster recovery. If your contracts or SLAs promise a certain level of availability, or customers depend on your service being reachable, this category makes your report stronger. It brings criteria around capacity planning, environmental protections, and recovery and backup.
Who needs it: most SaaS startups. If you make any uptime promise, Availability is usually the first optional category to add.
Confidentiality
Confidentiality covers information that you have committed to protect as confidential, typically under NDA or contract. This is not the same as personal data. It is about business information (roadmaps, financials, source code, customer datasets treated as confidential) that you agreed to restrict and dispose of properly.
Who needs it: startups that handle sensitive business data for their customers, or whose contracts include confidentiality obligations beyond ordinary security.
Processing Integrity
Processing Integrity covers whether your system processing is complete, valid, accurate, timely, and authorised. It is about the correctness of what your system does with data, not just protecting it. This matters when your product’s core value is that it processes data correctly.
Who needs it: payments platforms, billing engines, data-transformation products, anything where a wrong output is a direct harm to the customer. Most general SaaS does not need it.
Privacy
Privacy covers how you collect, use, retain, disclose, and dispose of personal information, aligned to your privacy notice and to applicable regulation. It is the most involved optional category because it overlaps with privacy law obligations.
Who needs it: companies that process personal data as a core function and want SOC 2 to speak to that. Note that Privacy under SOC 2 is not a substitute for compliance with a privacy law such as the DPDP Act; for how those relate, see SOC 2, ISO 27001, or DPDP: which first.
Which Criteria Does a SaaS Startup Actually Need?
The honest answer for most Series A and B SaaS startups: Security, plus Availability. That combination covers the mandatory foundation and the uptime commitment nearly every SaaS makes. Add Confidentiality when a customer contract requires it. Reach for Processing Integrity or Privacy only when they are central to what you sell.
The reason to scope narrow is cost and evidence discipline. Each additional category adds criteria, and each criterion needs controls, policies, and evidence that the auditor can test. A Series A startup that scopes all five categories on its first report usually spends the observation period generating exceptions for controls it never operationalised. Start with what you can actually demonstrate, then expand on your next annual report. For how the observation window and annual cycle work, see SOC 2 renewal vs your first SOC 2.
Where a Pentest Fits in the Framework
A penetration test is not a Trust Services Criterion by itself. It is evidence that supports specific criteria. Two mappings matter most.
CC7.1 (Vulnerability Detection). This criterion is about detecting vulnerabilities before they are exploited. An independent pentest is direct evidence that you actively look for vulnerabilities in your system, beyond automated scanning. When an auditor reviews your CC7.1 controls, an independent third-party pentest report is one of the strongest artifacts you can present.
CC4.1 (Monitoring of Controls). CC4 is about evaluating whether your controls are operating as intended. Commissioning an independent assessment is one recognised way an organisation monitors and evaluates its own control effectiveness. A pentest, performed by a party independent of the team that built the controls, is evidence that you evaluate your controls rather than assuming they work.
Beyond those two, individual findings map across the framework: access-control findings to CC6, change-management findings (like a development endpoint reaching production) to CC8, and identified-and-treated vulnerabilities to CC9. The Cybersecify Growth Pentest report includes this per-finding Trust Services Criteria mapping so your auditor does not have to do the mapping work.
One thing to be clear about: a vulnerability scan is not a pentest. Automated scanning supports CC7.1 as ongoing detection, but auditors distinguish it from manual, tool-assisted penetration testing that includes business logic and access-control testing. You generally need both.
Common Scoping Mistakes
- Including all five categories on the first report. More categories, more evidence, more chances for exceptions. Scope to Security plus what you can demonstrate.
- Confusing Privacy (SOC 2) with privacy-law compliance. They overlap but are not the same. SOC 2 Privacy does not certify DPDP Act compliance.
- Treating Confidentiality as automatic. You only need it when you have specific confidentiality commitments beyond ordinary security.
- Assuming Processing Integrity applies to everything. It applies to the correctness of processing. Most SaaS that stores and displays data, rather than transforming it, does not need it.
- Getting CC labels wrong in the pentest report. A report that mislabels CC6.6 as vulnerability management, or CC7.1 as threat detection, signals to a technical auditor that the vendor does not know the framework.
What to Do Next
Decide your scope before you engage an auditor. For nearly every SaaS startup that means Security (the Common Criteria) plus Availability, adding Confidentiality when a contract requires it. Then make sure your independent testing evidence is ready for CC7.1 and CC4.1.
Cybersecify provides the pentest evidence auditors expect for CC7.1, mapped per finding to the Trust Services Criteria, plus SOC 2 and ISO 27001 readiness preparation. We are not an auditor and we do not issue SOC 2 reports; that is the licensed CPA firm’s role. What we do is get your security controls and evidence ready so the audit goes smoothly.
Book a free founder call to map your scope and evidence. Our pentest plans start at INR 74,999, with Trust Services Criteria mapping per finding on the Growth plan. For ongoing preparation, see our Audit and Compliance services. To go deeper on what a pentest report needs to satisfy an auditor, read SOC 2 pentest requirements.
Want to see what the evidence actually looks like? Our sample penetration test report is published in full, no email gate. Its Compliance Evidence Package maps every finding to SOC 2 Trust Services Criteria, which is the part an auditor asks for.