“Do we need Privacy or just Confidentiality?” For organizations looking at a SOC 2 Report for compliance reporting, it’s one of the most common questions when companies are scoping their SOC 2 audits. Both categories sound like they protect sensitive information, so what’s the difference?
If you think about the classic security triad (confidentiality, integrity, availability), privacy isn’t even there. It’s confidentiality that’s fundamental to information security. In my view, privacy actually falls within the bounds of confidentiality conceptually. But the AICPA Trust Services Categories treat Privacy and Confidentiality as separate to reflect the business and legal realities outside of the CIA security triad technical concepts.
Choosing the wrong category can either leave gaps in your compliance or likely leave you with unnecessary compliance overhead. Deciding if you need one or both is a choice you will make in the readiness / applicability decisions when engaging with an independent auditor. The decision is yours, but will be driven by your data types, and applicable customer commitments and of course… your legal obligations.
SOC 2 Trust Services Categories: The Quick Context
SOC 2 reports are built around five Trust Services Categories defined in TSP Section 100 of the AICPA Trust Services Criteria (yes, that criteria is different than category, which makes this all the more confusing at times). These are five broad Trust Service Categories where you can scope your SOC 2 compliance report around. Security, Availability, Processing Integrity, Confidentiality, and Privacy.
For a deeper dive into the other five categories and more about SOC 2 compliance reporting, check out our complete SOC 2 guide. The AICPA also has comprehensive details on their SOC suite of services page.
What Confidentiality Actually Covers
For folks looking to obtain a SOC 2 Report, the confidentiality category covers how you protect business secrets, your own or your clients’, from unauthorized access or disclosure. The criteria focus on how sensitive information is secured throughout its lifecycle. You are showing the information designated as confidential is protected, as agreed.
What counts as “confidential” often depends on your services and contracts. Many times it’s spelled out directly in your service commitments or customer agreements. In a SOC 2 examination, confidentiality isn’t limited to two points. It includes the common criteria (governance, risk assessment, access controls, monitoring, change management, etc.) plus the Confidentiality-specific criteria, which address how you identify, protect, and eventually dispose of confidential information.
Auditors evaluate whether your controls reasonably support:
- C1.1 — identifying and classifying confidential information
- C1.2 — protecting it throughout its lifecycle
Before you meet with auditors, ask yourself: How does our company manage the lifecycle of confidential data?
Confidentiality – What it protects:
- Trade secrets and proprietary algorithms
- Customer business data you process on their behalf
- Financial records, pricing strategies, and competitive intelligence
- Intellectual property and development roadmaps
- Any information marked “confidential” in your contracts
Confidentiality – Why it’s simpler:
- Built around contractual obligations, not individual rights
- No consent forms or privacy notices required
- Focused on business-to-business data protection
- Straightforward lifecycle management (collect, protect, dispose)
Go for Confidentiality when:
- (IMPORTANT) You handle business data for clients but don’t collect client consumer personal information directly.
- Your contracts specify confidentiality requirements
- You’re protecting proprietary information or trade secrets
- The data doesn’t trigger privacy regulations like GDPR or CCPA
If you are preparing for a SOC 2 examination, and you choose confidentiality, you should be able to answer questions over:
- How do we define confidential information?
- Is confidential data defined in contracts or service commitments?
- Are employees trained on what data is considered confidential?
- How is confidential data received (APIs, uploads, integrations, email, support tickets)?
- Where is confidential data stored (databases, file storage, backups, logs)?
- Who can access confidential data, and why?
- How do subprocessors/contractors/vendors access or transmit confidential data?
- How is confidential data protected while in use, in transit, and at rest?
- How long is confidential data retained, and how is it securely disposed of?
These above questions are not a checklist. They are ways auditors evaluate whether your controls align with your confidentiality commitments. A SOC 2 is meant to be a tailored report. While, looking at these above questions, you can determine if you have a control that can be written to address the above questions or if there may be a potential gap. Use the guide below to align with the confidentiality commitments tested in a SOC 2 examination.
What Privacy Actually Covers
Privacy may be a Trust Services Category you may want to include in your report when you’re handling personal information about identifiable individuals. Not just confidential data as described above. Privacy is about transparency, individual rights, and lawful processing. A SOC 2 examination that includes the privacy category covers, specific processes, over the in-scope system that address:
- What you tell customers about your privacy practices
- How you keep personal data safe
- How customers know when and how their data is used
- How customers can view or update their personal data
- How customers can raise privacy concerns or complaints
Privacy is generally more complex than confidentiality as the recommended guidance and criteria include components seen in other frameworks. Practically speaking, the privacy category is more consumer and employee-centric, while confidentiality is more B2B focused.
You may need Privacy in your SOC 2 Report if:
You collect personal information directly from individuals
- Your SaaS platform requires users to create accounts with names and email addresses
- You’re collecting employee information for an HR system
- Your app asks for phone numbers, addresses, or payment information
- You track user behavior and tie it to identifiable people (not just anonymous analytics)
GDPR, CCPA, HIPAA, or similar laws apply to your business
- You have customers or users in the EU (GDPR applies)
- You serve California residents and meet CCPA thresholds
- You handle protected health information (HIPAA)
- Your contracts explicitly require compliance with privacy regulations
- You’re in healthcare, finance, or other heavily regulated industries
Your service involves end users, customers’ customers, or employee data
- You’re a B2B2C platform (think payroll software, learning management systems, marketing automation)
- Your client’s employees or customers interact directly with your system
- You provide services where your customer acts as the data controller but you process the personal data
- You manage HR systems, benefits platforms, or employee monitoring tools
You publish a privacy notice describing data practices
- You have a privacy policy on your website explaining how you handle personal information
- Your terms of service describe data collection and use
- You’ve made public commitments about how you protect user data
- Your marketing materials mention privacy protections or certifications
Privacy likely applies at a meaningful level if:
- You collect personal information beyond basic account identifiers (phone numbers, addresses, government IDs, payment data)
- You track user behavior and tie it to identifiable individuals
- You market to, profile, or analyze individuals based on their data
- You handle employee or contractor personal data
- Your service involves end users or consumers, not just business contacts
- Privacy laws like GDPR or CCPA apply to your operations
- You publish a privacy notice describing personal data practices
Privacy may be limited in scope (but not absent) when:
- You only collect names and email addresses
- That data is used solely for authentication, account administration, or support
- You don’t track individual behavior beyond basic security logging
- You don’t sell, share, or market using personal data
- Retention is minimal and purpose-driven
In these cases, Privacy obligations exist but they’re typically lightweight and proportional to what you’re actually doing.
Privacy is often out of scope for a SOC 2 audit when:
- You process only business data
- You don’t collect personal information directly from individuals
- Any incidental personal data is customer-controlled and encrypted
- You have no consumer or employee data
- No privacy laws apply to your operations
Frankly speaking, if you only handle business data and no regulated personal information, Confidentiality alone is often sufficient. Scoping Privacy when it doesn’t apply often creates unnecessary complexity without added assurance value. This is a discussion you should have with your independent auditor if you are considering including it in your SOC 2 examination.
At the time of this writing, current SOC 2 guidance notes that privacy has to be considered where relevant for common criteria (CC1.1-CC5.1) items as well as specific criteria as it relates to privacy.
Are you a Data Controller, a Data Processor, or Both?
A data controller decides why personal data is collected and how it’s used, while a data processor just handles the data on the controller’s behalf. Controllers make the decisions, what data to collect, how long to keep it, and who it’s shared with. Data Controllers have broader privacy obligations.
Processors don’t make those calls, they follow instructions provided by data controllers. For example, a SaaS company using customer data to run its product is usually the controller, while a cloud host or payroll provider processing that data for the SaaS company is acting as a processor.
Additional Criteria for Privacy
- 1. Communicating what you collect and why (P1.1 Notice) You need clear privacy notices that actually match what you’re doing. This isn’t about encryption. It’s about how you manage your. privacy program. It’s focused on being honest and clear with people about your data practices.
- 2. Getting consent and choices (P2 area – Choice and Consent) Depending on the laws that apply to you, you’ll need to show how you obtain consent, let people opt out, and document lawful bases for processing or data transfers. This is one of the biggest differences from Confidentiality.
- 3. How you collect data (P3 area – Collection) You need to limit collection to what’s necessary and be transparent about your methods.
- 4. What you do with it (P4 area – Use, Retention, and Disposal) Personal data gets used only for stated purposes, retained based on legal and business collection requirements, and disposed of securely. Yes, this overlaps with Confidentiality, but the reasoning is different. It’s about individual expectations, not just contracts.
- 5. Handling individual rights (P5 area – Access) People can request to see their data, correct it, or delete it. Even if these requests are rare, you need processes ready to respond to data subject requests or other partners, like data controller requests and how to authenticate and manage them.
- 6. Who you share it with (P6 area – Disclosure and notification) You need to control and document when personal data goes to third parties, and those disclosures must align with your notices and consent. This drives vendor scrutiny way beyond what Confidentiality requires.
- 7. Keeping data accurate (P7 area – Quality) You’re responsible for maintaining accurate personal information. How do you ensure the accuracy and completeness of personal information?
- 8. Enforcement and accountability (P8 area – Monitoring) Privacy isn’t just documented. It’s monitored and enforced internally. Auditors look for oversight, accountability, and remediation when things go wrong. How are users made aware with how to contact you with inquiries, complaints, or disputes? Is a process in place to address this? How is non-compliance addressed and reported? Are there ongoing processes to monitor the privacy program to take timely corrective actions when necessary?
