Priya Nandakumar had the term sheet open in one browser tab and the AICPA's 2022 Trust Services Criteria document open in another, and she was fairly sure the two were not going to reconcile themselves. Priya was VP of Security and Compliance at Ledgerly, a 140-person accounts-payable automation platform that had just landed a letter of intent from a Fortune 500 procurement team worth $3.8 million in first-year contract value — contingent, the letter said, on Ledgerly producing "a current SOC 2 Type II report covering security and availability" within two quarters.
Two quarters was tight. But the phrase that actually stopped Priya cold wasn't the deadline — it was "covering security and availability." Her auditor's discovery call the week before had asked a question she hadn't fully prepared for: which Trust Services Criteria did Ledgerly want in scope? Security, she knew, wasn't optional — every SOC 2 report includes it. But availability, processing integrity, confidentiality, and privacy were each a separate decision, each with its own control set, its own evidence burden, and its own effect on the audit timeline and the invoice at the end of it. Ledgerly moved money — its platform routed vendor payment instructions and approval workflows for its customers' accounts payable teams. Did that make processing integrity mandatory in spirit, even if it was optional on paper? Did the fact that some customer contracts touched employee banking details pull privacy into scope, or was that a confidentiality question instead?
Priya's mistake, common enough that her auditor barely blinked at it, was assuming the Trust Services Criteria were a menu she could pick from based on what sounded impressive. They aren't. They're a scoping decision anchored to what your system actually does, what you've promised your customers, and what risks a reasonable user of your service would care about. Adding a criterion you don't need burns audit budget and stretches your control-implementation timeline for no customer-facing benefit. Skipping one you do need means your report doesn't answer the question your biggest prospect is actually asking. Getting this right, before the audit starts rather than during it, is the single highest-leverage decision in the entire SOC 2 process — and it's the decision this article exists to help you make.
Who This Is For and What You'll Walk Away With
This is for founders, CTOs, security leads, and compliance managers at service organizations who have decided SOC 2 is happening and now need to answer the harder question: SOC 2 covering what, exactly. You'll get a clause-by-clause walk through the nine Common Criteria series (CC1–CC9) that make up the mandatory Security criterion, a mapping of those series to the COSO framework's 17 principles, and a practical breakdown of Availability, Processing Integrity, Confidentiality, and Privacy — what each one actually tests, the controls auditors expect to see, and the signals that tell you whether your organization needs it. By the end, you should be able to sit in your own scoping conversation and make the call yourself, instead of guessing.
The Five Trust Services Criteria, At a Glance
Every SOC 2 report is built on the Trust Services Criteria (TSC), a set of five criteria categories published and maintained by the AICPA (American Institute of Certified Public Accountants). One category — Security — is required in every single SOC 2 engagement, no exceptions. The other four are optional additions selected based on the nature of the service organization's system and the commitments it has made to its customers. Table 1 gives you the full picture before we go deep on each one.
Table 1: The Five Trust Services Criteria — Overview
Criterion | Required or Optional | What It Tests | Typical Adopters |
|---|---|---|---|
Security (Common Criteria) | Required in every SOC 2 | Protection against unauthorized access, both logical and physical, that could compromise the system | Every service organization pursuing SOC 2 |
Optional | Whether the system is available for operation and use as committed or agreed | SaaS platforms, hosting/infra providers, anything with an uptime SLA | |
Optional | Whether system processing is complete, valid, accurate, timely, and authorized | Payment processors, e-commerce, billing engines, workflow/transaction platforms | |
Confidentiality | Optional | Whether information designated as confidential is protected as committed or agreed | B2B SaaS handling client business data, trade secrets, contracts |
Optional | How personal information is collected, used, retained, disclosed, and disposed of | Consumer-facing platforms, HR tech, healthtech, anything processing PII at scale |
The mandatory criterion is formally titled "Security," but nearly everyone in the industry — including AICPA's own supporting materials — calls it the Common Criteria, abbreviated CC. That's because it's built from nine series, CC1 through CC9, each mapped back to the internal-control components of the COSO framework. We'll walk all nine in detail below. If you take away nothing else from this section, take this: Security is not a choice. Everything else is.
The Shape of a SOC 2 Scope
Before diving into the CC series, it helps to see the whole structure in one view. Every report is Security plus zero-to-four optional additions, and the optional additions sit alongside — not underneath — the Common Criteria; they don't replace or absorb any part of CC1–CC9.
flowchart TD
A[SOC 2 Report Scope] --> B[Security / Common Criteria — REQUIRED]
B --> B1[CC1 Control Environment]
B --> B2[CC2 Communication & Information]
B --> B3[CC3 Risk Assessment]
B --> B4[CC4 Monitoring Activities]
B --> B5[CC5 Control Activities]
B --> B6[CC6 Logical & Physical Access]
B --> B7[CC7 System Operations]
B --> B8[CC8 Change Management]
B --> B9[CC9 Risk Mitigation]
A --> C[Availability — OPTIONAL]
A --> D[Processing Integrity — OPTIONAL]
A --> E[Confidentiality — OPTIONAL]
A --> F[Privacy — OPTIONAL]
C -.selected if.-> C1[Uptime/SLA commitments exist]
D -.selected if.-> D1[System processes transactions or data for customers]
E -.selected if.-> E1[System stores confidential business data]
F -.selected if.-> F1[System processes personal information]Notice that the four optional boxes attach directly to the top-level scope, not to Security. A common misconception — one I hear on almost every readiness call — is that adding Availability or Confidentiality means auditing "more security controls." It doesn't. It means adding an entirely separate set of criteria with their own points of focus, and in a Type II engagement, their own body of evidence collected across the audit period.
"Clients come to me wanting to know which box to check. I tell them SOC 2 scoping isn't a checkbox exercise — it's a mirror held up to your customer contracts. If your MSA promises 99.9% uptime, Availability isn't a nice-to-have, it's already implied. The report just needs to catch up to what you already promised." — Marcus Webb, CPA, Managing Partner, Webb Assurance Partners
Why Security Is Non-Negotiable: The Common Criteria
The Security criterion exists because every other trust promise a service organization makes — availability, accurate processing, confidentiality, privacy — is worthless if an unauthorized party can walk in and change the system underneath it. That's why AICPA built Security as the floor: nine criteria series, CC1 through CC9, that together examine whether an organization has the governance, risk management, and technical controls in place to prevent, detect, and respond to unauthorized access. Table 2 previews all nine before we go series by series.
Table 2: The Nine Common Criteria Series at a Glance
Series | Name | Core Question It Answers |
|---|---|---|
CC1 | Control Environment | Does leadership set the tone, structure, and accountability for internal control? |
CC2 | Communication and Information | Does the organization generate and share the information people need to run controls? |
CC3 | Risk Assessment | Does the organization identify and analyze risks to its objectives? |
CC4 | Monitoring Activities | Does the organization check that its controls are actually working? |
CC5 | Control Activities | Does the organization select and deploy controls that address risk? |
CC6 | Logical and Physical Access Controls | Who can get to systems and facilities, and how is that restricted? |
CC7 | System Operations | How are systems operated, detected for anomalies, and recovered? |
CC8 | Change Management | How are changes to systems authorized, tested, and deployed safely? |
CC9 | Risk Mitigation | How does the organization manage risk from vendors and business disruptions? |
Every one of these series will appear in your report, in every SOC 2 engagement you ever run, for as long as SOC 2 exists in its current form. Let's take them one at a time.
CC1 — Control Environment
CC1 asks whether the organization has built the governance foundation that everything else rests on: a functioning board or governance body, a defined organizational structure, documented lines of authority and responsibility, a commitment to integrity and ethical values, and accountability mechanisms that actually get enforced rather than sitting in a handbook nobody reads. Auditors testing CC1 aren't looking at firewalls — they're looking at your org chart, your code of conduct, your background-check policy, your board meeting minutes, and whether your HR process actually terminates system access when someone is fired.
This is the series where I see the most first-time SOC 2 candidates stumble, not because the controls are technically hard, but because they're organizational habits that have to exist before the audit period starts. You cannot backfill six months of board oversight evidence in the final week.
Table 3: CC1 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Ethics and integrity | Documented code of conduct, acknowledged annually by all staff | Signed acknowledgment records |
Board/governance oversight | Governance body reviews security posture at defined intervals | Meeting minutes, board deck excerpts |
Organizational structure | Documented org chart with clear reporting lines | Current org chart, role descriptions |
Competence | Role-based hiring criteria and onboarding training | Job descriptions, training completion logs |
Accountability | Performance reviews include security/compliance responsibilities | HR performance review templates |
Background screening | Pre-employment background checks for relevant roles | Background check vendor reports |
CC2 — Communication and Information
CC2 tests whether the organization identifies, captures, and communicates the information people need to do their jobs and run internal controls — both internally (to employees) and externally (to customers, regulators, and other stakeholders). It also covers whether the organization communicates its security commitments and responsibilities clearly enough that everyone, including customers, understands what's expected of them.
In practice, this is where your security policies, your incident communication plan, your customer-facing trust documentation, and your internal security awareness materials all get evaluated. A company can have excellent technical controls and still fail CC2 if nobody can explain, in an interview, what the incident escalation policy actually says.
Table 4: CC2 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Internal communication | Security policies published and accessible to all staff | Policy repository, intranet screenshots |
Security awareness training | Annual security awareness training for all employees | LMS completion reports |
External communication | Published trust/security page describing commitments to customers | Public trust center URL |
Incident communication | Documented incident communication and notification procedure | Incident response plan excerpt |
Objective communication | System description accurately reflects boundaries and responsibilities | Approved system description document |
CC3 — Risk Assessment
CC3 examines how the organization identifies risks to its objectives — including fraud risk — and how it analyzes those risks to decide what to do about them. This series also covers how the organization identifies and assesses the impact of significant changes, whether organizational, technological, or environmental, that could affect its control environment.
This is risk assessment in the classic sense: a documented process, run on a defined cadence, that produces a risk register with likelihood, impact, and treatment decisions — not a one-time spreadsheet built the week before the audit kickoff call.
Table 5: CC3 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Risk identification | Formal risk assessment performed at least annually | Risk register, assessment methodology doc |
Fraud risk | Fraud risk explicitly considered within the risk assessment | Risk register entries tagged for fraud |
Objective-setting | Documented business/security objectives risks are measured against | Strategic objectives documentation |
Change-driven risk | Process to reassess risk when significant changes occur | Change-triggered risk review records |
Risk treatment | Documented risk treatment decisions (accept/mitigate/transfer/avoid) | Risk treatment plan |
CC4 — Monitoring Activities
CC4 asks a deceptively simple question: how does the organization know its controls are actually working? This covers both ongoing monitoring (built into daily operations) and separate evaluations (like internal audits or periodic control testing), and it requires that deficiencies get evaluated and communicated to the people who can fix them — not discovered and quietly forgotten.
A readiness assessment itself is a form of CC4 evidence. So is a management review cadence where control owners report status, a vulnerability management program that tracks remediation to closure, and a documented process for escalating control failures.
Table 6: CC4 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Ongoing monitoring | Automated compliance monitoring tooling continuously checks control status | Monitoring platform dashboards/alerts |
Separate evaluations | Internal control self-assessments or internal audits performed periodically | Internal audit reports |
Deficiency evaluation | Documented process to triage and prioritize identified deficiencies | Deficiency/finding tracker |
Deficiency communication | Findings routed to accountable owners with remediation deadlines | Ticketing system records |
Management review | Recurring management review of control performance | Meeting cadence records, review notes |
CC5 — Control Activities
CC5 covers the selection and development of control activities that mitigate risk to acceptable levels — both the general controls over technology (access provisioning tooling, configuration management systems) and the policies and procedures that put controls into action. If CC3 is "what could go wrong," CC5 is "what specifically did we build to stop it."
Table 7: CC5 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Control selection | Controls mapped explicitly to identified risks | Risk-to-control mapping matrix |
Technology general controls | Standardized configuration baselines for infrastructure | Configuration management records |
Policies and procedures | Documented, approved, version-controlled policy set | Policy management system exports |
Control ownership | Named owner assigned to each control | Control matrix with owner field |
Deployment | Controls implemented consistently across the in-scope system | Implementation evidence per control |
CC6 — Logical and Physical Access Controls
CC6 is usually the largest, most evidence-heavy series in the entire report, and it's the one most people picture when they hear "SOC 2 security controls." It covers how the organization restricts logical access (who can log into systems, applications, and data) and physical access (who can walk into data centers, offices, or facilities housing in-scope systems), how it provisions and deprovisions that access, and how it protects data through its lifecycle — including at rest and in transit.
This is where access control, authentication, and encryption live. Auditors will sample user access lists, termination tickets, multi-factor authentication (MFA) enforcement settings, and badge-access logs for your office or data center. If your joiner-mover-leaver process has gaps — an ex-employee whose SSO account stayed active three weeks past their last day — CC6 is where it surfaces.
Table 8: CC6 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Logical access provisioning | Access requests require documented approval before granted | Access request/approval tickets |
Access deprovisioning | System access revoked within a defined window of termination | Termination checklist, access removal logs |
Authentication strength | MFA enforced for all access to production systems | Identity provider MFA configuration |
Least privilege | Role-based access aligned to job function | Role-based access control matrix |
Physical access | Badge access and visitor logs for facilities housing in-scope systems | Badge system reports, visitor logs |
Data protection | Encryption at rest and encryption in transit for sensitive data | Encryption configuration evidence |
Access review | Periodic access recertification by system/data owners | Access review sign-offs |
CC7 — System Operations
CC7 examines how the organization detects and responds to security events, manages vulnerabilities, and operates its systems day to day. This series covers threat and vulnerability detection, incident response, logging and monitoring, and — importantly — recovery from security incidents once they've occurred.
Auditors testing CC7 want to see that detection tooling exists and generates real alerts (not a SIEM sitting unconfigured), that there's a documented incident response plan that's been tested, and that vulnerabilities identified through vulnerability scanning or penetration testing get tracked to remediation.
Table 9: CC7 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Threat detection | Endpoint detection and network monitoring tooling deployed | EDR/monitoring tool configuration |
Vulnerability management | Regular vulnerability scans with defined remediation SLAs | Scan reports, remediation tracking |
Penetration testing | Annual (or more frequent) third-party penetration test | Pen test report and remediation evidence |
Incident response | Documented, tested incident response plan | IR plan, tabletop exercise records |
Log management | Centralized logging with defined retention | SIEM/log aggregation configuration |
Recovery | Documented recovery procedures following a security incident | Post-incident recovery records |
CC8 — Change Management
CC8 asks whether changes to infrastructure, software, and configurations are authorized, designed, developed, tested, approved, and implemented in a controlled way that avoids introducing unintended risk. This is change management in the classic ITSM sense, applied to a security lens: no unreviewed code reaching production, no infrastructure change happening outside a tracked process.
Table 10: CC8 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Change authorization | All production changes require documented approval | Change request tickets |
Segregation of duties | Developer cannot deploy their own code to production unreviewed | Code review + deployment pipeline logs |
Testing | Changes tested prior to production deployment | Test results, staging environment logs |
Version control | Source code maintained in version-controlled repositories | Repository access/commit history |
Emergency changes | Documented emergency change process with retroactive review | Emergency change records |
Rollback | Documented rollback procedure for failed changes | Rollback runbook |
CC9 — Risk Mitigation
CC9 is the newest addition to the Common Criteria structure and covers two things auditors increasingly probe hard: how the organization manages risk from business disruptions (feeding into business continuity and disaster recovery) and how it manages risk introduced by vendors and business partners — vendor risk management, in other words.
With the rise of cloud dependencies, this series has become a genuine differentiator between mature and immature security programs. An organization that can show a vendor risk assessment process, subservice organization monitoring, and a tested business continuity plan clears CC9 comfortably. One relying on "we trust our cloud provider" as a control statement does not.
Table 11: CC9 — Example Controls
Control Area | Example Control | Typical Evidence |
|---|---|---|
Business continuity | Documented and tested business continuity plan | BCP document, tabletop test results |
Disaster recovery | Documented DR plan with defined RTO/RPO | DR plan, recovery test evidence |
Backup | Regular backups with periodic restoration testing | Backup logs, restoration test records |
Vendor risk assessment | Third-party/vendor risk assessments performed before onboarding | Vendor risk assessment records |
Subservice monitoring | Ongoing monitoring of critical subservice organizations | SOC reports collected from vendors, review notes |
Insurance/risk transfer | Cyber insurance or other risk-transfer mechanisms in place | Insurance policy documentation |
Mapping the Common Criteria to COSO's 17 Principles
None of this was invented from scratch by the AICPA. The Common Criteria are built directly on top of the COSO Internal Control – Integrated Framework, the same internal-controls framework auditors have used for financial reporting engagements for decades. COSO organizes internal control into five components — Control Environment, Risk Assessment, Control Activities, Information and Communication, and Monitoring Activities — expressed through 17 principles. CC1 through CC5 map directly onto those five COSO components and their 17 principles. CC6 through CC9 are TSC-specific additions layered on top, written to address the technology and security risks that a purely financial-reporting-oriented framework like COSO doesn't fully anticipate on its own — logical/physical access, system operations, change management, and risk mitigation.
Understanding this lineage matters practically: if your organization already has a mature internal-controls program built for other purposes (financial audit readiness, SOC 1 work, enterprise risk management), you likely already satisfy a meaningful chunk of CC1–CC5 without additional build work. CC6–CC9 is almost always where the real security-program build happens.
Table 12: Common Criteria Series to COSO's 17 Principles
CC Series | COSO Component | COSO Principles Covered |
|---|---|---|
CC1 | Control Environment | 1. Commitment to integrity and ethical values · 2. Board independence and oversight · 3. Structure, authority, and responsibility · 4. Commitment to competence · 5. Accountability enforcement |
CC2 | Information and Communication | 13. Uses relevant, quality information · 14. Communicates internally · 15. Communicates externally |
CC3 | Risk Assessment | 6. Specifies suitable objectives · 7. Identifies and analyzes risk · 8. Assesses fraud risk · 9. Identifies and analyzes significant change |
CC4 | Monitoring Activities | 16. Conducts ongoing and/or separate evaluations · 17. Evaluates and communicates deficiencies |
CC5 | Control Activities | 10. Selects and develops control activities · 11. Selects and develops general controls over technology · 12. Deploys through policies and procedures |
CC6–CC9 | TSC-specific supplemental criteria | Not directly COSO-numbered — operationalize COSO's principles for logical/physical access, system operations, change management, and risk mitigation in a technology context |
"I walk every client through this mapping in the kickoff meeting, because it changes how they think about the audit. CC1 through CC5 isn't 'IT security' — it's the same internal-controls DNA their finance team already has evidence for. Once they see that, the Common Criteria stop feeling like a foreign language." — Dana Ferreira, Director of Information Security, a mid-market healthtech SaaS company
The Four Optional Trust Services Criteria: Choosing What to Add
With Security handled, the real scoping conversation starts. Availability, Processing Integrity, Confidentiality, and Privacy are not ranked by importance — none of them is "more advanced" than another — they're selected based on a single question: what has your organization actually committed to, and what does your system actually do? A report scoped too narrowly leaves your biggest customer's contractual question unanswered. A report scoped too broadly means paying your auditor to test controls nobody asked about, on a timeline that didn't need to stretch.
The trigger for each optional criterion is usually visible in your own customer contracts, marketing claims, and system architecture before you ever talk to an auditor. Availability is implied by uptime SLAs. Processing Integrity is implied by any system that transacts, calculates, or moves something on a customer's behalf. Confidentiality is implied by any system holding a customer's non-public business information under an NDA or MSA confidentiality clause. Privacy is implied by any system that collects personal information directly from individuals, particularly at consumer scale.
Availability: Is the System There When Customers Need It
Availability tests whether the system is available for operation and use to meet the organization's committed or agreed-upon objectives — usually expressed as an uptime SLA, a recovery time commitment, or an operational-hours promise. It is the most commonly added optional criterion, largely because so many SaaS and infrastructure businesses put an uptime number in their contracts without necessarily connecting that promise to an audit obligation.
Availability controls overlap meaningfully with CC7 (System Operations) and CC9 (Risk Mitigation) but go further: where CC7 asks "do you detect and respond to operational issues," Availability asks "do you actually meet the uptime and recovery commitments you made." That distinction shows up in the evidence — Availability testing pulls actual uptime monitoring data, incident postmortems tied to SLA breaches, and capacity planning records, not just the existence of a monitoring tool.
Table 13: Availability — Focus, Example Controls, When to Include
Dimension | Detail |
|---|---|
Focus | System uptime, performance monitoring, capacity planning, environmental protections, backup/recovery meeting commitments |
Example controls | Uptime monitoring against SLA thresholds; documented capacity planning process; environmental controls (power, cooling, fire suppression) for owned data centers; tested backup restoration; documented incident postmortems tied to availability events |
Example evidence | SLA uptime reports, incident timeline records, capacity utilization trend reports, DR test results |
When to include | You have a contractual or marketed uptime/SLA commitment; customers depend on continuous or scheduled system access; downtime has direct customer-facing business impact |
When to skip | System is a low-frequency internal tool with no uptime commitments; customers don't depend on real-time access |
Processing Integrity: Did the System Do the Right Thing, Correctly
Processing Integrity tests whether system processing is complete, valid, accurate, timely, and authorized. It is not about data confidentiality or system uptime — it's specifically about whether the processing itself produces correct outcomes. Did the invoice calculate the right total? Did the transaction post to the right account? Did the batch job that ran overnight process every record it was supposed to, with no duplicates and no silent drops?
This is the criterion most often underestimated by companies whose systems calculate, transact, transform, or route something. Payment processors, billing platforms, e-commerce checkout systems, payroll engines, and workflow-automation tools (like Priya's Ledgerly, from our opening story) are the classic candidates. Processing Integrity controls typically include input validation, reconciliation processes, error-handling and exception queues, and quality assurance testing tied specifically to data accuracy — not just security.
Table 14: Processing Integrity — Focus, Example Controls, When to Include
Dimension | Detail |
|---|---|
Focus | Completeness, validity, accuracy, timeliness, and authorization of system processing |
Example controls | Input validation on data entry points; reconciliation between source and output records; exception/error queue with defined resolution SLA; authorization checkpoints before transaction execution; automated testing of calculation logic |
Example evidence | Reconciliation reports, exception log with resolution timestamps, QA/test coverage for processing logic, transaction authorization audit trail |
When to include | System performs calculations, transactions, or data transformations on behalf of customers; errors in processing would have material customer/financial impact; customer contracts reference processing accuracy or completeness |
When to skip | System is primarily a data storage/retrieval service with no meaningful transformation or calculation logic |
Confidentiality: Protecting What's Been Designated Confidential
Confidentiality tests whether information designated as confidential — under an NDA, an MSA confidentiality clause, or an internal data classification scheme — is protected in accordance with the organization's commitments. This is broader than personal data; it covers customer business information, trade secrets, source code shared under contract, pricing data, and any other information both parties have agreed to treat as non-public.
The key distinguishing test for Confidentiality versus general Security controls is designation. The CIA triad concept of confidentiality as a security property is embedded throughout the Common Criteria already (access controls exist to protect confidentiality among other things). The Confidentiality criterion asks something more specific: has the organization identified what counts as confidential, and does it have a defined lifecycle — from receipt through secure disposal — for handling it as such.
Table 15: Confidentiality — Focus, Example Controls, When to Include
Dimension | Detail |
|---|---|
Focus | Identification, protection, and lifecycle management (including secure disposal) of information designated confidential |
Example controls | Data classification policy identifying confidential categories; confidentiality clauses embedded in customer and vendor contracts; access restrictions specific to confidential data classes; secure disposal/destruction procedures; NDA management process |
Example evidence | Data classification scheme, contract language samples, access control mapping to classification tiers, disposal/destruction logs |
When to include | System stores customer business data, trade secrets, or source code under contractual confidentiality obligations; B2B customers expect their non-public data protected beyond generic security |
When to skip | System handles only public or already-disclosed information with no confidentiality commitments in contracts |
Privacy: How Personal Information Is Collected, Used, and Disposed Of
Privacy (TSC) is the most detailed and most frequently misunderstood of the four optional criteria. It covers the full lifecycle of personal information — notice, choice and consent, collection, use and retention, access, disclosure to third parties, quality, monitoring and enforcement, and disposal. Unlike the other criteria, Privacy has its own distinct set of criteria (sometimes still referenced by their legacy label, the Generally Accepted Privacy Principles, which the current TSC structure absorbed), and it is tested against the organization's own published privacy notice and commitments, not against an external law like GDPR or CCPA directly.
This last point trips people up constantly: a SOC 2 Privacy criterion engagement doesn't certify GDPR or CCPA compliance. It tests whether you do what your own privacy notice says you do. That said, most organizations that need Privacy in scope are also navigating those regulations, so the practical control set overlaps heavily — consent management, data subject access request handling, retention schedules, and breach notification processes.
Table 16: Privacy — Focus, Example Controls, When to Include
Dimension | Detail |
|---|---|
Focus | Notice, choice/consent, collection, use/retention, access, third-party disclosure, and disposal of personal information, tested against the organization's own privacy notice |
Example controls | Published, accurate privacy notice; consent capture and management mechanism; data subject access/deletion request process; documented retention and disposal schedule for PII; third-party data-sharing agreements with privacy terms |
Example evidence | Privacy notice version history, consent logs, data subject request tracker, retention schedule, data processing agreements with subprocessors |
When to include | Consumer-facing product collecting personal information at scale; contracts or regulations (GDPR, CCPA, HIPAA-adjacent) require privacy commitments; customers ask specifically about personal data handling in due diligence |
When to skip | System is purely B2B with no direct collection of consumer personal information; only employee data is processed, and that's covered adequately under Confidentiality/Security |
"The question I ask every prospective client isn't 'do you want Privacy in your report.' It's 'does your own privacy notice make promises a stranger could hold you to in front of a regulator.' If yes, we scope it. If your privacy notice is three boilerplate paragraphs nobody's read since 2019, we fix that first, separately from the audit." — Tom Alavi, Senior Audit Manager, a regional CPA and assurance firm
Confidentiality vs. Privacy: The Distinction Everyone Confuses
Of all the scoping confusions I untangle on discovery calls, "aren't Confidentiality and Privacy basically the same thing" is the most frequent. They're related — both concern protecting sensitive information — but they test fundamentally different obligations, and conflating them is how organizations end up under-building one while over-building the other.
Confidentiality is about designation: information that both parties have agreed, usually contractually, to treat as non-public — trade secrets, source code shared under an NDA, a customer's internal pricing model, unreleased product roadmaps. The obligation comes from a contract or an internal classification decision, and it can apply to information about organizations just as easily as information about people. Privacy, by contrast, is about personal information specifically — data that identifies or relates to an individual human being — and the obligation is framed against the organization's own published privacy notice, covering the full lifecycle from collection and consent through disclosure and disposal. A company can need Confidentiality without ever touching consumer data (a B2B analytics platform holding a client's proprietary algorithms, for instance), and a company can need Privacy while having almost no "confidential business data" in the traditional sense (a consumer app that only stores names and email addresses, none of it contractually confidential in the NDA sense).
Table 17: Confidentiality vs. Privacy — Side by Side
Dimension | Confidentiality | Privacy |
|---|---|---|
What's protected | Information designated confidential by contract or classification | Personal information relating to an identifiable individual |
Source of obligation | NDAs, MSA confidentiality clauses, internal classification policy | The organization's own published privacy notice |
Applies to | Business data, trade secrets, source code, pricing, contracts | Names, contact details, health data, financial data tied to individuals |
Lifecycle tested | Protection and secure disposal | Notice, choice/consent, collection, use, retention, disclosure, disposal |
Typical adopter | B2B SaaS with sensitive client business data | Consumer-facing platforms, healthtech, HR tech |
Common overlap point | Both may apply to the same dataset (e.g., an HR platform's employee records are both confidential business data and personal information) | Same as left |
The practical implication: don't assume choosing one substitutes for the other. If your due-diligence questionnaires are asking about both how you protect proprietary client data and how you handle personal information about end users, you may genuinely need both criteria in scope — they're not redundant with each other any more than Availability is redundant with Processing Integrity.
Which Criteria Do You Need? A Decision Matrix
By this point the pattern should be clear: each optional criterion answers a specific question about your system, and the answer usually already exists somewhere in your contracts, your architecture, or your go-to-market claims. Table 18 turns that into a working decision tool — walk down the "signal" column and see how many boxes your organization checks for each criterion.
Table 18: Which Trust Services Criteria Do You Need?
Signal in Your Business | Security | Availability | Processing Integrity | Confidentiality | Privacy |
|---|---|---|---|---|---|
Every SOC 2 report, no exception | Required | — | — | — | — |
Contract includes an uptime/SLA commitment | — | Include | — | — | — |
System calculates, transacts, or transforms customer data | — | — | Include | — | — |
System stores customer business/trade-secret data under NDA | — | — | — | Include | — |
System collects personal information directly from individuals | — | — | — | — | Include |
Enterprise prospects ask about data accuracy/completeness in due diligence | — | — | Include | — | — |
Marketing claims "bank-grade confidentiality" or similar | — | — | — | Include | — |
Consumer-facing app with sign-up/account creation | — | — | — | — | Include |
Payment or billing functionality | — | Consider | Include | — | Consider |
Purely internal tool, no external SLA, no PII, no transactions | Required only | — | — | — | — |
A useful rule of thumb from years of scoping calls: if you can't point to a specific contract clause, product claim, or system function that a criterion tests, don't add it. Auditors will ask "why is this in scope" during planning, and "it seemed thorough" is not an answer that survives that conversation — it just adds cost and testing burden without adding customer value.
Questions Auditors Ask During Scoping Discovery Calls
Before an engagement letter gets signed, most reputable CPA firms run a discovery call specifically to pressure-test your proposed scope — not to sell you more criteria, but to make sure the report you're paying for actually answers your customers' questions. Knowing these questions in advance lets you walk in with answers instead of guesses, which shortens the discovery process and avoids scope surprises after the engagement letter is signed.
Table 19: Common Discovery-Call Questions by Criterion
Criterion Under Discussion | Typical Auditor Question | What They're Testing For |
|---|---|---|
Availability | "What uptime or SLA commitments appear in your customer contracts?" | Whether Availability is contractually implied even if not explicitly requested |
Processing Integrity | "Does your system calculate, transact, or transform data on a customer's behalf?" | Whether processing accuracy is a material risk worth testing |
Confidentiality | "What categories of information have you classified as confidential, and where does that obligation come from?" | Whether a real classification scheme exists or needs to be built |
Privacy | "Do you collect personal information directly from individuals, and does your privacy notice reflect what you actually do?" | Whether Privacy is a genuine business function or an afterthought |
All optional criteria | "Which of your vendors or subprocessors touch data relevant to this criterion?" | Whether subservice organization coverage (carve-out vs. inclusive) needs to be resolved before fieldwork starts |
All optional criteria | "What does your largest customer's contract actually say about this?" | Whether the criterion is driven by real commercial commitment rather than assumption |
Answering these well before the call — pulling the relevant contract language, privacy notice, and vendor list in advance — is usually the single biggest time-saver in the entire pre-audit process. Auditors price and staff engagements based on scope clarity; a vague scoping conversation tends to produce a padded estimate simply because the firm has to budget for the uncertainty.
Industry Patterns: What Similar Companies Typically Scope
Every scoping decision should still be made from your own contracts and system function — never copy a competitor's scope blindly — but seeing the patterns other organizations in your industry land on is a useful sanity check. Table 20 summarizes the criteria combinations I see most often by industry vertical, based on years of readiness engagements.
Table 20: Illustrative Industry Scoping Patterns
Industry / Business Model | Security | Availability | Processing Integrity | Confidentiality | Privacy | Typical Driver |
|---|---|---|---|---|---|---|
B2B SaaS (workflow/productivity) | Required | Common | Sometimes | Common | Rare | Uptime SLAs, confidential client workflows |
Payments / fintech | Required | Common | Common | Common | Sometimes | Transaction accuracy, financial data sensitivity |
Healthtech / health data analytics | Required | Sometimes | Sometimes | Common | Common | Health-adjacent personal data, HIPAA-adjacent terms |
Infrastructure-as-a-Service / hosting | Required | Common | Sometimes | Rare | Rare | Uptime commitments, metering/billing accuracy |
HR tech / people-data platforms | Required | Sometimes | Sometimes | Common | Common | Employee PII plus confidential compensation data |
Marketing/analytics SaaS (consumer data) | Required | Sometimes | Rare | Sometimes | Common | Consumer data collection at scale |
Internal enterprise tooling (no external SLA) | Required | Rare | Rare | Sometimes | Rare | No customer-facing commitments beyond security |
Notice how rarely all five criteria appear together, even among data-intensive businesses. Comprehensive scope isn't a badge of maturity — it's a response to a specific combination of commitments that most organizations, even sophisticated ones, simply don't all carry at once.
Case Study: Ledgerly Scopes Security, Availability, and Processing Integrity
Back to Priya. Ledgerly's discovery call resolved the way most well-run scoping conversations do: by working backward from actual commitments. The procurement team's LOI named Security and Availability explicitly — that answered two-fifths of the question immediately. The harder call was Processing Integrity. Ledgerly's platform routed vendor payment approval workflows; it didn't move money directly (a banking partner handled settlement), but it did generate the payment instructions banks acted on. Priya's auditor made the case that if a processing error in Ledgerly's system produced an incorrect payment instruction, the customer's financial exposure would be real and immediate — that's exactly the risk Processing Integrity is built to test.
Ledgerly scoped Security, Availability, and Processing Integrity, and explicitly left out Confidentiality and Privacy for the Type II engagement — the platform held business data under standard MSA confidentiality terms already substantially covered by CC6 access controls, and it processed minimal consumer PII (only employee names tied to expense approvals, not consumer data at scale). The readiness build took eleven weeks, focused heavily on CC6 access review cadence and building out reconciliation controls for Processing Integrity that hadn't previously been documented as controls even though the engineering team was already doing the reconciliation work informally. The Type II report landed nine days before the procurement deadline. The $3.8 million contract closed six weeks later.
Table 21: Case Study Outcomes
Organization (illustrative) | Criteria Scoped | Primary Driver | Readiness Timeline | Business Outcome |
|---|---|---|---|---|
Ledgerly (AP automation SaaS) | Security, Availability, Processing Integrity | Payment-instruction accuracy exposure named directly by prospect | 11 weeks | $3.8M enterprise contract closed |
Northfield Health Analytics (healthtech data platform) | Security, Confidentiality, Privacy | Consumer health-adjacent data + HIPAA-adjacent contractual terms | 16 weeks | Cleared two hospital-system vendor reviews previously stalled on data handling questions |
Cascade Cloud Infrastructure (IaaS provider) | Security, Availability, Processing Integrity | 99.95% SLA plus billing-metering accuracy disputes from a prior incident | 14 weeks | Reduced SLA-credit disputes; retained a $1.2M enterprise account at renewal |
Case Study: Northfield Health Analytics Adds Confidentiality and Privacy
Northfield Health Analytics processed de-identified and, in some data-sharing arrangements, identifiable patient encounter data for hospital-system customers performing population-health analytics. Two separate hospital-system prospects had stalled Northfield's sales cycle at the security-review stage, each asking nearly identical questions: how is patient data classified, who can access it, and what happens to it when a contract ends. Those are Confidentiality and Privacy questions dressed up as generic "security review" friction, and Northfield's existing SOC 2 (Security only) didn't answer them directly enough to satisfy either hospital's assessors.
"We had a clean SOC 2 report and we were still losing deals to 'data handling concerns.' The report just wasn't answering the question being asked. Once we added Confidentiality and Privacy and could point to specific tested controls — data classification, retention schedules, subprocessor agreements — the same reviewers who'd stalled us for two quarters cleared us in three weeks." — Sarah Kim, Chief Compliance Officer, Northfield Health Analytics
Northfield's build work centered on formalizing a data classification scheme that already existed informally in engineering documentation, standing up a documented data subject request process even though most of its data flowed through B2B contracts rather than direct consumer relationships, and negotiating updated data processing terms with two subprocessors who hadn't previously provided their own SOC 2 reports. The sixteen-week timeline was longer than Ledgerly's, largely because Privacy required net-new process — not just formalization of existing practice.
Case Study: Cascade Cloud Infrastructure Resolves a Billing Dispute Pattern
Cascade Cloud Infrastructure, an infrastructure-as-a-service provider, had carried a Security-and-Availability SOC 2 for two audit cycles without incident. A billing-metering bug — usage hours miscounted for a subset of customers during a deployment migration — triggered a wave of SLA-credit disputes and one enterprise customer's threat to walk at renewal. The bug wasn't a security failure; it was a processing-accuracy failure that no criterion in Cascade's existing report scope actually tested.
Cascade's next audit cycle added Processing Integrity specifically to address metering and billing accuracy, building automated reconciliation between usage-collection systems and invoicing output, plus a documented exception-handling process for metering discrepancies. The following renewal cycle, the at-risk enterprise account's own procurement team cited the expanded report scope directly as a factor in renewing a $1.2 million contract rather than moving to a competitor.
Cost and Timeline Impact of Adding Optional Criteria
Every optional criterion you add expands the audit scope, and every expansion has a real cost in auditor hours, internal build effort, and evidence-collection burden — particularly for a Type II report, where evidence has to be collected consistently across the entire audit period, not just captured once. Table 22 gives illustrative ranges based on patterns I've seen across readiness engagements; treat the specific numbers as directional, not a quote.
Table 22: Illustrative Cost and Timeline Impact of Adding Each Optional Criterion
Criterion Added | Typical Additional Readiness Effort | Typical Additional Audit Fee Impact | Common Build Gaps |
|---|---|---|---|
Availability | Low–Moderate (often partially covered by existing CC7/CC9 controls) | 5–10% above Security-only baseline | Formal SLA monitoring reports, capacity planning documentation |
Processing Integrity | Moderate–High (often requires new reconciliation/QA controls) | 10–20% above baseline | Reconciliation processes, exception-handling documentation, processing-specific QA evidence |
Confidentiality | Low–Moderate (often overlaps with existing CC6 access controls) | 5–15% above baseline | Formal data classification scheme, contract language audit, disposal procedures |
Privacy | High (often requires net-new processes) | 20–35% above baseline | Privacy notice accuracy, consent management, data subject request handling, subprocessor DPAs |
The pattern worth internalizing: Availability and Confidentiality frequently ride on the coattails of controls you're already building for the Common Criteria, so the marginal cost is modest. Processing Integrity and especially Privacy tend to require genuinely new processes, which is exactly why they deserve the most scrutiny in your scoping decision — the cost of getting them wrong (either omitting a needed criterion or adding an unneeded one) is highest.
How TSC Scope Tends to Expand Over Time
Scope is rarely static across a company's SOC 2 lifecycle, and it's worth setting the expectation early that this is normal, not a sign the first scoping decision was wrong. Most organizations I've worked with follow a recognizable pattern: they start with Security alone, or Security plus the one optional criterion their first big enterprise deal explicitly demanded, and then add criteria in subsequent audit cycles as the product surface area grows, as new customer segments raise new questions, or as an incident (like Cascade's billing bug) exposes a gap the original scope didn't cover.
This is healthy scope evolution, not scope creep, as long as each addition is still tied to a real commitment or risk — the same discipline covered throughout this article. What separates healthy evolution from padding is whether you can name, for each criterion in your current report, the specific contract clause, product function, or customer segment that justifies it. A report that has quietly accumulated Availability, Processing Integrity, Confidentiality, and Privacy over four audit cycles without anyone revisiting whether all four are still needed is just as much a scoping problem as an under-built first report — it's simply a slower-moving one. Build a habit of revisiting scope at each renewal, not just adding to it.
Common Scoping Mistakes
I've sat in enough scoping calls to see the same handful of mistakes recur across industries. Table 23 catalogs the ones worth avoiding before you sign an engagement letter.
Table 23: Common Trust Services Criteria Scoping Mistakes
Mistake | Why It Happens | Consequence |
|---|---|---|
Adding every optional criterion "to be safe" | Founders assume more criteria signals more maturity | Inflated audit cost and timeline with no customer-facing benefit |
Skipping Availability despite a stated SLA | Team doesn't connect contract language to TSC scope | Report doesn't answer the exact question a customer's procurement team is asking |
Treating Privacy as "the same as Confidentiality" | Surface-level similarity between the two criteria | Under-built consent/retention/disposal processes that fail testing |
Assuming Processing Integrity only applies to "fintech" | Narrow mental model of what counts as "processing" | Missed scope for any system that calculates, transforms, or routes data |
Scoping criteria without checking subservice organization coverage | Overlooking how vendors' own SOC reports affect your evidence | Gaps in CC9/vendor risk evidence discovered mid-audit |
Changing scope mid-audit-period for a Type II | Sales team promises a criterion not originally scoped | Evidence gap for the portion of the period before the criterion was added |
Confusing "we have good security" with "criterion X is satisfied" | Security controls feel like they cover everything | Missed criterion-specific points of focus (e.g., reconciliation for Processing Integrity) |
How Auditors Actually Test These Criteria
It helps to demystify what happens once scope is set. For each criterion in scope, your auditor maps the AICPA's published "points of focus" to your specific control environment, then designs tests appropriate to a Type I report (testing whether controls are suitably designed, evaluated at a single point in time) or Type II report (testing whether controls operated effectively across the full audit period, commonly three to twelve months).
Testing methods include inquiry (interviewing control owners), observation (watching a control operate, like an access-review meeting), inspection of audit evidence (reviewing tickets, logs, and reports), and reperformance (independently redoing a control activity, like recalculating a reconciliation, to confirm the result matches). A single control might be tested with two or three of these methods depending on risk. The auditor then forms an opinion — unqualified, qualified, adverse, or disclaimer — and documents any exceptions found in the "tests of controls and results" section that's unique to Type II reports. None of this differs mechanically between Security and the optional criteria; what changes is which points of focus and which evidence get pulled into the sample.
Type I vs. Type II Considerations, Criterion by Criterion
The Type I report versus Type II report decision applies to your entire report — you don't run a Type I on Security and a Type II on Availability within the same engagement — but the practical burden of each optional criterion shifts depending on which type you're pursuing. A Type I only has to show controls were suitably designed as of a point in time; a Type II has to show they operated effectively across the whole audit period, which is a materially heavier evidentiary lift for criteria that depend on recurring, sampled activity.
Table 24: Type I vs. Type II Burden by Criterion
Criterion | Type I Burden | Type II Burden |
|---|---|---|
Security (Common Criteria) | Show access control, change management, and monitoring controls are designed correctly | Show they operated consistently across the full period — access reviews actually happened on schedule, changes were actually approved every time |
Availability | Show monitoring and capacity-planning controls exist | Show actual uptime data and incident records across the full period, tested against SLA thresholds |
Processing Integrity | Show reconciliation and validation controls are designed | Show reconciliations actually ran on schedule with documented exception handling throughout the period |
Confidentiality | Show classification and access-restriction controls exist | Show consistent enforcement and any disposal events handled correctly across the period |
Privacy | Show privacy notice, consent mechanism, and request-handling process exist | Show actual consent records, data subject requests, and their resolutions across the full period |
Most first-time SOC 2 candidates start with a Type I to prove design maturity quickly, then move to a Type II once they have enough operating history to demonstrate consistency — a sequencing decision covered in depth in our Type I vs Type II comparison. Whichever path you choose, the criteria-selection decision itself doesn't change; only the depth of evidence required to support it does.
Subservice Organizations and Your Criteria Selection
CC9's vendor-risk-management focus has a direct effect on how you scope the other four criteria, and it's easy to miss. If a meaningful part of your Availability, Processing Integrity, Confidentiality, or Privacy commitments actually depend on a subservice organization — a cloud hosting provider responsible for your uptime, a payment processor handling the transaction integrity your customers actually care about, a subprocessor storing personal data on your behalf — your auditor needs to know whether you're using the carve-out method (excluding the subservice organization's controls from your report and relying on their own SOC report as separate evidence) or the inclusive method (bringing their controls directly into your report's scope).
This matters most for Availability and Processing Integrity, where infrastructure and payment dependencies are common, and for Privacy, where subprocessors handling personal data are almost universal. A practical habit: before finalizing scope, inventory every subservice organization touching an in-scope criterion and confirm you can obtain their own SOC 2 report (or equivalent assurance) to support the carve-out method — or budget the additional time the inclusive method requires if their report isn't available.
Documenting Your Scope Decision in the System Description
Whatever criteria you land on, that decision has to be reflected precisely in your system description — the narrative document, prepared by management and reviewed by your auditor, that describes your system's boundaries, the criteria in scope, and the controls addressing each one. This is the document a prospect's security team will actually read closely, often before they read the control-testing results, so vague or inconsistent scope language here undermines the value of even a well-executed audit.
A well-written system description states the criteria in scope explicitly, describes why each optional criterion was included (tying back to the same commitments-and-system-function logic covered throughout this article), and defines the system boundary clearly enough that a reader understands exactly what was and wasn't tested. Auditors will push back hard on system descriptions that claim broad criteria coverage without a coherent narrative connecting that coverage to the business — which is, again, why starting the scoping conversation from your actual contracts rather than a generic template pays off well before the fieldwork begins.
Preparing for the Scoping Conversation: What to Bring to Your Auditor
The single best thing you can do before your first scoping call is arrive with source documents instead of impressions. Auditors can move a discovery call from a multi-week back-and-forth to a single productive session when the service organization shows up with the right artifacts already pulled together, rather than trying to recall contract language from memory or promising to "circle back" on details that determine the entire engagement scope.
Table 25: What to Bring to a Trust Services Criteria Scoping Conversation
Document | Why It Matters | Criterion It Informs |
|---|---|---|
Your top 3–5 customer MSAs or contracts | Reveals actual SLA, confidentiality, and data-handling commitments in writing | Availability, Confidentiality, Privacy |
Current published privacy notice | Baseline for what Privacy testing would actually be measured against | Privacy |
System architecture diagram | Shows what the system actually does — calculates, transacts, stores, transmits | Processing Integrity, Confidentiality |
List of subprocessors and subservice organizations | Determines carve-out vs. inclusive method decisions up front | All optional criteria |
Recent security questionnaires from prospects | Surfaces the questions customers are actually asking, independent of what you assume they care about | All optional criteria |
Data classification policy (if one exists) | Shows whether Confidentiality controls already exist informally | Confidentiality |
Prior SOC 2 report, if any | Establishes what's already been tested and what changed since | All criteria |
Walking in with these seven artifacts turns the scoping conversation from a guessing exercise into a verification exercise — the auditor confirms your read of your own commitments rather than having to extract that information from scratch, which is faster and cheaper for everyone involved.
Security vs. the Other Four: Relationship, Not Redundancy
A question I get often enough to address directly: if Security already covers access control, encryption, and incident response, why would Availability, Processing Integrity, Confidentiality, or Privacy ever be needed on top of it? The answer is that the Common Criteria protect the system from unauthorized interference — they don't test whether the system does what it promises when nothing has gone wrong from a security standpoint. A perfectly secured system can still miss its uptime SLA due to poor capacity planning (an Availability gap, not a security failure), still miscalculate a customer's invoice due to a logic bug (a Processing Integrity gap), still leave a data retention promise unmet because nobody built a disposal schedule (a Confidentiality or Privacy gap). The four optional criteria test operational and functional promises that sit adjacent to, not underneath, the security promise.
"I tell engineering leaders: Security tells your customer 'nobody unauthorized can get in.' Processing Integrity tells them 'and when the system runs, the numbers come out right.' Those are different promises. A customer that got burned by a billing error doesn't care how good your access controls are." — James Okoro, CTO, a logistics-technology SaaS platform
Coordinating TSC Scope with ISO 27001 and Other Frameworks
If your organization is also pursuing or holding ISO 27001 certification, there's real leverage available in how you scope both simultaneously. ISO 27001's Annex A controls and the SOC 2 Common Criteria overlap substantially on access control, change management, and incident response, which means evidence built for one often satisfies a large share of the other with light adaptation. Our guide on running ISO 27001 and SOC 2 together walks through building a shared control environment rather than maintaining two parallel compliance programs, and the ISO 27001, SOC 2 & NIST CSF crosswalk maps specific Annex A controls to specific CC series so you can see exactly where the overlap sits and where each framework asks something the other doesn't.
The decision of which optional TSC to add doesn't change based on ISO 27001 status — that decision is still driven by your contracts and system function, as covered above — but the effort to satisfy whichever criteria you choose drops meaningfully if your ISO 27001 ISMS is already mature, because CC1 through CC6 draw on largely the same governance and access-control evidence ISO 27001's Clause 5–10 and Annex A controls already require. If you're earlier in the decision of which framework to pursue at all, ISO 27001 vs. SOC 2: which one do you need walks through that upstream question directly, and our complete guide to the AICPA Trust Services Criteria covers the broader SOC 2 process this article's criteria fit inside. If you're still deciding between a Type I and Type II engagement for whichever criteria you land on, our Type I vs Type II comparison breaks down that separate decision in detail.
Scoping as a Business Decision, Not Just a Compliance One
It's worth stepping back from the mechanics of CC1–CC9 and the four optional criteria to name what's actually happening when you scope a SOC 2 report correctly: you're translating your product's real value proposition into a language your customers' procurement and security teams can verify independently. Priya's $3.8 million deal didn't close because Ledgerly had a SOC 2 report — plenty of vendors have one. It closed because Ledgerly's report answered the exact three questions that prospect's own risk team had already decided to ask: is this vendor secure, is it available when we need it, and can we trust the numbers it produces. Get the scope right, and the report becomes a sales asset that shortens due-diligence cycles instead of a compliance artifact that sits in a shared drive nobody reads.
The inverse is just as real. Under-scoping costs you the deal that hinges on the criterion you left out. Over-scoping costs you budget and calendar time on evidence nobody asked to see, and — subtly — it can make your program look less disciplined to a sophisticated auditor or customer, not more. The organizations that get the most durable value out of SOC 2 are the ones that treat the Trust Services Criteria decision the way they'd treat any other resourcing call: what does the business actually need, backed by what the evidence in our own contracts already tells us.
If you're heading into your own scoping conversation, start where Priya did — pull your customer contracts, your SLAs, your privacy notice, and your product's actual data-processing footprint, and match them against Table 18 before your first call with an auditor. You'll walk into that conversation as the person setting the agenda, not the person being scoped.
To make that first pass faster, run your commitments through the SOC 2 Trust Services Criteria Mapping Template, which walks the same contract-to-criterion exercise used in Table 18 in a structured worksheet. Pair it with the SOC 2 Readiness Checklist to see how far your existing controls already reach into CC1–CC9 before you sign an engagement letter. If you want a quick, low-commitment gut check before a formal readiness engagement, the SOC 2 Gap Analysis Tool flags likely control gaps by criterion in minutes rather than weeks.
Get Expert Help Scoping and Preparing for Your SOC 2
Scoping the Trust Services Criteria correctly the first time saves months of rework and thousands of dollars in avoidable audit fees — but it requires an honest, evidence-based read of your own contracts, architecture, and customer commitments, which is hard to do from inside the organization making the call. PentesterWorld's compliance and security team works with service organizations at exactly this stage: mapping customer commitments to the right Trust Services Criteria, running readiness assessments against the Common Criteria and whichever optional criteria your business needs, and closing control gaps before your auditor ever sees them. If you're staring down a SOC 2 scoping conversation of your own, reach out to PentesterWorld and let's get the scope right before the clock starts.