Confidentiality is two criteria long, which makes it look like the easiest category to add to a SOC 2. Most of the protection work, such as access control and encryption, already sits in the security criteria. What is left seems small.
What is left is the part teams find hardest to evidence: knowing where every copy of confidential information lives, and proving you deleted it when you said you would. Those two jobs are C1.1 and C1.2. This article covers how to do both in a way that survives sampling, and the places where the process usually breaks.
If you are still deciding whether to include the category at all, the trust services criteria explained one by one covers how it differs from privacy and when it fits.
What "confidential" means is your decision, written down
The AICPA's criteria do not define confidential information for you. C1.1 asks you to identify and maintain confidential information to meet your objectives related to confidentiality. C1.2 asks you to dispose of it to meet those same objectives. Your objectives come from your commitments.
For most service organizations, the commitments are in three places:
Customer contracts. Confidentiality clauses, and any terms about how data is handled at the end of the relationship.
Data processing agreements and security addenda. These often state deletion timelines, return-of-data obligations, and restrictions on copies.
Your own requirements. Source code, financial information, and business plans can be confidential because you decided they are.
The artifact that turns this into something testable is a data classification policy. It names a small number of levels, gives examples of what falls into each, and says who decides when something is unclear. An auditor will read it, then look for signs that it is applied: labels in a document system, tags on storage, or an inventory that uses the same levels.
A classification policy with four levels that nobody uses is a common finding waiting to happen. Two or three levels that people apply are better than a detailed scheme that exists only on paper.
C1.1: find every copy before you try to protect it
Identifying confidential information means knowing where it is. Production databases are the obvious answer and rarely the complete one. A useful inventory covers:
Primary data stores, such as databases and object storage.
Backups and snapshots, including any held in a separate account or region.
Logs and traces that capture request bodies or customer identifiers.
Analytics warehouses, search indexes, and caches built from production data.
Support and ticketing tools where customers paste data or attach files.
Non-production environments seeded with production copies.
Vendors that hold copies on your behalf.
Files exported to laptops, spreadsheets, and shared drives.
Items 3 to 8 are where confidentiality quietly goes wrong. A staging database restored from production last year holds the same confidential information as production, often with weaker access controls. Either prohibit production data outside production, and enforce that, or treat those environments as in scope.
If you already keep a GDPR record of processing, it is a head start. How to build an Article 30 record of processing covers a similar inventory exercise, though it is limited to personal data and confidentiality is not.
"Maintain" in C1.1 also means keeping confidential information for as long as you committed to. A contract that promises to retain records for a set period is a confidentiality commitment as well. Accidental early deletion breaks it too.
C1.2: disposal on the timeline you promised
C1.2 is the criterion teams underestimate. Deleting data is easy. Deleting all of it, on time, from every place in your inventory, and keeping a record that you did, is a process.
Start with a retention schedule. For each type of confidential information it states how long you keep it, what event starts the clock, and how it is disposed of. Then build the process for the event that matters most, which is usually a customer leaving:
Trigger. Contract termination is recorded in your billing or CRM system, and that record opens a deletion ticket. Relying on someone remembering is an easy way to delete late.
Export window. If your contract allows the customer time to retrieve their data, the ticket waits for that window to close.
Primary deletion. Data is removed from the primary stores in your inventory.
Derived copies. Search indexes, caches, analytics tables, and logs are handled, or documented as aging out on a stated schedule.
Backups. Many teams let backups expire rather than editing them. That is a defensible approach if your contracts and retention schedule say so plainly.
Vendors. Where a vendor holds copies, you request deletion and keep the confirmation.
Record. The ticket closes with who did the work, when, and what was deleted, with output from the system rather than a checkbox.
Disposal also covers confidential information that is not customer data: retired laptops, decommissioned storage, and printed material. CC6.5 in the security criteria covers removing protections from physical assets only after data on them cannot be recovered. The device wipe records you keep for CC6.5 often serve both criteria.
What an auditor samples
Expect the auditor to test confidentiality the way they test most Type II controls: by requesting a population and choosing items from it. How auditors sample controls covers the mechanics.
Typical requests include:
The data classification policy and retention schedule, approved and dated.
The confidential information inventory, and evidence that it is reviewed.
A list of customers who left during the period, from which the auditor selects a sample and asks for deletion evidence for each one.
Disposal records for devices and media retired during the period.
Agreements with vendors that hold confidential information, showing they are bound to protect and delete it.
If no customer left during the period, the deletion control did not operate. Reports typically state that no instances occurred, which a careful buyer will notice. Ask your auditor early what they will accept as evidence that the process works, such as a documented test deletion.
Where confidentiality goes wrong
The failure patterns are predictable, which makes them preventable:
Custom deletion terms. A sales redline changes the deletion timeline for one customer, and nobody tells the team running the process. Track non-standard terms where the people doing the deletion can see them.
A policy that outran the system. The retention schedule says data is deleted at a point your tooling cannot reach, such as inside immutable logs.
Copies nobody owns. An analyst's export, a support attachment, a forgotten bucket. The inventory exists to find these, so review it.
Deletion with no evidence. The work was done, but the ticket says "done" and nothing else. An auditor cannot test a claim.
The pattern behind all four is the same as elsewhere in SOC 2: the control is usually performed, and the record of it is usually thin. The SOC 2 framework page covers how confidentiality sits alongside the other categories.
How TrustLynce helps
TrustLynce tracks customer commitments, such as contractual deletion timelines, against the controls that meet them, so a non-standard term is visible to the people running the process. Policy management keeps your classification policy and retention schedule versioned, with acceptance tracked.