SOC 2 Confidentiality Criteria

Confidentiality is the criterion customers request but rarely understand

The confidentiality Trust Services Criterion is one of the more commonly misunderstood parts of SOC 2. Customers ask for it during due diligence — "we need a report that includes confidentiality" — without always knowing how it differs from security or privacy. This page clears that up, walks through the C1 series controls, and explains the evidence auditors expect.

Confidentiality applies when information has been designated confidential — by contract, NDA, policy, or regulation. It is distinct from personal information, which falls under the privacy criterion. If your customers entrust you with intellectual property, business plans, negotiation data, source code, or other sensitive non-personal information, the confidentiality criterion belongs in your audit.

What the confidentiality criterion covers

The Trust Services Criteria define confidentiality as "information designated as confidential is protected to meet the entity's objectives." Confidentiality has two dedicated control categories in the C1 series, plus heavy overlap with the Common Criteria, especially CC6 (access control).

• C1.1 — The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.
• C1.2 — The entity disposes of confidential information to meet the entity's objectives related to confidentiality.

These two controls frame the confidentiality lifecycle: identify what is confidential, handle it appropriately, and dispose of it securely when the obligation ends.

C1.1 — Identification and handling of confidential information

C1.1 requires that the organization knows what is confidential and handles it consistently with that designation. The core expectations are classification, access restriction, and protection.

Data classification

A data classification policy defines the sensitivity tiers used by the organization. A common structure:

The tiers are not prescribed by SOC 2. What matters is that the policy is documented, tiers have handling requirements, and employees know how to classify their work. See data classification.

Access restrictions aligned to classification

Access controls must enforce the classification scheme. Typical controls:

• Role-based access with least-privilege defaults
• Additional review or approval for highly confidential data
• Periodic access reviews scoped to confidential systems
• Logging of access to confidential data
• Segmentation or tokenization where possible

These overlap with CC6 access control requirements but must be tested against the classification policy. Auditors may request a sample of users with access to confidential systems and verify that the access aligns with documented roles.

Technical protection of confidential data

Specific technical controls include:

• Encryption at rest: confidential data encrypted on storage media, with managed keys
• Encryption in transit: TLS for all confidential data moving between systems
• Key management: keys rotated, access to key management restricted and audited
• DLP and monitoring: detection for unauthorized movement of confidential data
• Endpoint protections: disk encryption on devices that may hold confidential data

See encryption and key management for related glossary terms.

Contractual and policy protections

Technical controls sit on top of policy and contract. The organization must have:

• Confidentiality agreements with employees
• Confidentiality agreements with contractors and vendors
• Customer contracts that designate data as confidential and set handling obligations
• An acceptable use policy that addresses confidential information

C1.2 — Secure disposal of confidential information

C1.2 addresses what happens when confidential information is no longer needed or the confidentiality obligation ends. Secure disposal is often overlooked until audit time.

Disposal methods

• Logical deletion with cryptographic erasure: encryption keys destroyed so encrypted data becomes unrecoverable
• Data purging: secure deletion from databases, storage, and caches
• Physical destruction: for media that cannot be sanitized digitally (old disks, paper)
• Vendor certificates of destruction: when third parties destroy data on your behalf

Retention and decommissioning procedures

Disposal requires that you know when to dispose. Retention schedules specify how long different data types are kept. Decommissioning procedures specify what happens to data when:

• A customer terminates their contract
• An employee leaves the organization
• A system is retired
• A vendor relationship ends

A decommissioning runbook reduces the risk that confidential data lingers in deprecated systems.

Overlap with other Trust Services Criteria

Confidentiality depends heavily on Common Criteria controls.

• CC6 (access control) — classification drives access decisions
• CC7 (system operations) — monitoring detects unauthorized confidentiality events
• CC9 (risk mitigation) — vendor relationships involving confidential data
• Privacy — personal data is a subset; controls overlap significantly with privacy criteria

A mature SOC 2 program maps each control to every criterion it satisfies, so a single encryption control contributes to security, confidentiality, and privacy without duplicating work.

How this fits into SOC 2

Confidentiality is a natural addition when customers share sensitive data under NDA or when the organization processes intellectual property. It also pairs with the security criterion almost mechanically — most security controls contribute to confidentiality. Adding confidentiality to scope rarely requires dramatic new work; it requires deliberate mapping, classification, and disposal discipline.

The challenge during Type II is demonstrating operation across the observation period. Classification must be applied consistently, access reviews must include confidential systems, and disposal must be documented. See policies and procedures for how to anchor the program in written commitments.

Evidence auditors expect

Typical fieldwork requests for the confidentiality criterion:

• Data classification policy and examples of classified assets
• Confidentiality agreements (sample of executed NDAs)
• Access control configuration for confidential systems
• Encryption configuration (algorithms, key management)
• Disposal procedures and records of disposals during the period
• Customer contract samples showing confidentiality obligations
• Vendor contracts with confidentiality clauses where relevant

Common mistakes

• Classification without enforcement. Policy defines tiers but systems treat everything the same. Auditors will notice.
• Missing disposal records. Data is deleted but no record is kept. Without evidence, the disposal did not happen from the audit's perspective.
• NDA-only approach. Relying on contracts without technical controls leaves confidential data exposed.
• Vendor gaps. Confidential data flows to vendors without corresponding contract language or monitoring.
• Overly narrow scope. Confidential data lives in systems that are excluded from SOC 2 scope. Include them.

Implementation tips

• Classify data in the tools where it lives — databases, document stores, file shares. Centralized classification tags drive downstream controls.
• Tie confidentiality to your vendor management process. High-tier data flows require vetted vendors.
• Automate secure deletion when possible. Scheduled jobs that purge expired data produce cleaner evidence than ad hoc deletions.
• Include confidentiality acknowledgment in employee onboarding and annual training.
• Run a quarterly review of who has access to the most sensitive classification tier. Tighten aggressively.

How episki helps

episki maps C1.1 and C1.2 controls to your data classification, access, encryption, and disposal tooling, collecting evidence continuously so the confidentiality story is always current. Start a free trial or explore the broader SOC 2 framework guide to see how confidentiality integrates with security and privacy.