SOC 2 Confidentiality Criteria: What Counts as Confidential Data (And What Doesn't)

A SaaS founder once told me his team spent three weeks preparing evidence for the wrong criterion entirely — they built an elaborate data classification scheme for customer PII, thinking that was what "Confidentiality" meant under SOC 2. Their auditor pointed out, gently, that most of what they'd just classified actually fell under Privacy, a separate criterion they hadn't even scoped into their audit.

This mix-up happens constantly. Confidentiality is one of the five Trust Services Criteria under the AICPA SOC 2 framework, and it's also the one people misunderstand most — usually by assuming it means "keep customer data safe" in some general sense, when it actually has a much narrower, specific definition.

Where Confidentiality Fits Inside the SOC 2 Framework

SOC 2 audits are built around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory for every SOC 2 audit report; the other four are optional add-ons you select based on what your business actually promises customers.

Confidentiality gets added when a company has made specific contractual or policy commitments to protect certain categories of information from unauthorised disclosure. That "specific commitment" part matters — it's not a blanket promise to be careful with data in general. It's about information you've explicitly agreed to keep confidential, usually because a customer, partner, or contract requires it.

This is different from Security, which covers protecting systems from unauthorised access broadly. Confidentiality asks a narrower question: for the specific pieces of information you've designated as confidential, do you actually control who sees them, how they're stored, and how they get destroyed when no longer needed?

What Actually Counts as Confidential Data

The AICPA doesn't hand you a fixed list — confidentiality is defined by what your organisation has agreed to protect, not by a universal category of "sensitive" information. That said, in practice, confidential data under SOC 2 usually falls into a few recognisable buckets:

• Business and trade secrets — pricing models, proprietary algorithms, unreleased product roadmaps, internal financial projections

• Customer contractual data — anything a customer's contract specifically labels confidential, which can be broader or narrower than you'd assume

• Third-party and partner information — data shared under an NDA with vendors, resellers, or integration partners

• Internal strategic information — M&A discussions, unannounced hiring plans, legal matters not yet public

• System configuration details — network architecture, security control specifics, credentials — information that isn't personal but could enable an attack if exposed

Notice what's missing from that list: personal information about individuals. Names, health records, biometric data, and similarly personal identifiers are the domain of the Privacy criterion, not Confidentiality. This is the exact distinction that trips people up, and it's worth sitting with for a moment.

Confidentiality vs. Privacy: The Line Most Companies Get Wrong

Privacy governs personal information — data that identifies or relates to a person, collected, used, retained, and disclosed in line with your stated privacy commitments. Confidentiality governs information — often business or organisational in nature — that you've agreed to protect regardless of whether it relates to a specific person.

Here's a way to hold the distinction: if the information is about a person (their health record, their address, their behaviour on your platform), it likely falls under Privacy. If the information is about your business, a partner's business, or a third party's proprietary interests (a contract's financial terms, a vendor's source code shared for integration purposes, an unreleased feature spec), it likely falls under Confidentiality.

The overlap gets genuinely messy in specific cases. A customer's usage analytics might contain both — personal usage patterns (Privacy) sitting inside a dataset the customer's contract has separately designated as confidential (Confidentiality). Many companies handling this kind of data end up scoping both criteria into the same SOC 2 audit report rather than trying to force a clean separation.

How Auditors Actually Test the Confidentiality Criterion

A SOC 2 auditor doesn't just check whether you have a confidentiality policy sitting in a folder somewhere. The SOC 2 process for this criterion typically examines:

• Data identification and classification — can you actually point to what information your organisation has designated confidential, and is there a documented, consistently applied classification scheme? A policy that exists but isn't followed is worse than no policy at all, from an audit perspective — it shows a gap between what you say and what you do.

• Access restriction — is access to confidential information limited to people who genuinely need it, and is that access reviewed periodically rather than granted once and forgotten?

• Encryption and secure handling — is confidential data encrypted at rest and in transit, and are there controls preventing it from being copied into unprotected locations, like a spreadsheet on someone's laptop?

• Retention and disposal — do you have a defined retention period for confidential information, and can you demonstrate secure destruction once that period ends? This is a step companies frequently skip entirely — they're good at protecting data while they hold it, and terrible at proving they actually deleted it when they should have.

• Third-party disclosure controls — when confidential information does leave your organisation (shared with a vendor, a partner, or during due diligence), is there a documented process — usually an NDA plus a defined approval chain — governing that disclosure?

If your audit is a SOC 2 Type 2 engagement rather than Type 1, your SOC 2 auditor won't just confirm these controls exist on paper — they'll sample specific instances across your audit period and ask you to produce evidence that the control was actually followed on that date, for that piece of data.

Common Mistakes Companies Make With This Criterion

• Treating "confidential" as a permanent label. Information's confidentiality status can change — a product roadmap becomes public once launched, financial results become public after an earnings call. Companies that never revisit their classifications end up either over-restricting information that no longer needs it, or under-protecting something that should still be locked down.

• Confusing internal sensitivity with contractual confidentiality. Just because your team treats something as sensitive doesn't automatically make it "Confidential" under SOC 2 — the criterion is really about commitments you've made to external parties. Internal culture around discretion is good practice, but it's not what an auditor is testing here.

• No clear ownership of the classification process. In a lot of smaller companies, nobody is explicitly responsible for deciding what counts as confidential — it's assumed, informal, and inconsistent between teams. Auditors notice this immediately when different employees give different answers to the same question about a piece of data.

• Skipping the destruction step. Encryption and access controls get attention because they're visible and easy to demonstrate. Secure disposal at the end of a data's lifecycle gets ignored because it's less visible — until an auditor asks for proof that a specific dataset, past its retention window, was actually deleted rather than just forgotten about in a backup somewhere.

Building a Confidentiality Program That Actually Holds Up

A workable approach starts with an honest inventory: what information has your company specifically agreed — through contracts, NDAs, or written policy — to protect? That inventory becomes the scope of your Confidentiality controls, rather than trying to protect everything equally.

From there, the practical building blocks are consistent: a written classification policy that people actually reference, access controls tied to that classification, encryption for data at rest and in transit, a retention schedule with an enforced deletion process, and a documented approval chain for any third-party disclosure. None of this is exotic — the difficulty is almost always in consistency, not in any single control being technically hard to implement.

Where This Fits Into Your Broader SOC 2 Compliance Picture

Confidentiality rarely stands alone in a real audit. It usually sits alongside Security as a baseline pairing, and often alongside Privacy when personal and business-confidential data overlap in the same systems. Getting clear on this one criterion early — rather than discovering the Confidentiality-versus-Privacy confusion mid-audit, like the founder in the opening story — saves real time when you're mapping evidence and preparing for your SOC 2 compliance review.

The criterion isn't complicated once the scope is clear. What actually counts as confidential, who's allowed to see it, how long you keep it, and how you get rid of it when you're done — that's the whole test. Companies that can answer those four questions specifically, with evidence, tend to sail through this part of the audit without much drama at all.