Maria Delgado had eleven days until her Type II audit fieldwork started, and she was staring at a spreadsheet that made her stomach drop. Maria was the CFO — and de facto compliance owner — at ClauseHarbor, a 60-person legal-tech SaaS company that stored contract drafts, redline histories, and negotiation notes for mid-market law firms and their corporate clients. ClauseHarbor's biggest prospect, a $2.1 million annual contract with a national insurance carrier, was contingent on a clean SOC 2 Type II report that included the Confidentiality criteria. The carrier's procurement team had been explicit in a security questionnaire: "Confirm SOC 2 scope includes Confidentiality, not just Security."
Maria had assumed Security coverage was enough. ClauseHarbor encrypted its database, ran multi-factor authentication, and had decent access controls — solid Common Criteria territory. But when her auditor, Priya Chandrasekaran of Beacon & Vance CPAs, walked her through what Confidentiality actually required, the gap became obvious. ClauseHarbor had no inventory of what counted as "confidential" beyond customer PII. Draft merger agreements sitting in a shared drive with 40 employees able to view them. A former contractor's laptop, returned but never wiped, still holding cached client contract text. No documented retention or disposal schedule for anything that wasn't a database row. Security controls were protecting the front door; nobody had mapped what was actually inside the house or who was allowed to touch it.
"Security tells you the building has locks. Confidentiality tells you which rooms have information in them, who's allowed a key, and what happens to the papers when the deal closes. Most companies I audit have never separated those two questions." — Priya Chandrasekaran, SOC 2 Lead Auditor, Beacon & Vance CPAs
Six weeks later, after building a confidential-information inventory, a data classification scheme, encryption and access controls tied to classification tiers, and a documented retention-and-disposal process, ClauseHarbor passed its Type II examination with Confidentiality in scope and no exceptions. The insurance carrier signed. This article walks through exactly what Maria's team built, why Confidentiality is a distinct — and optional — Trust Services Criteria category, and how to implement it without treating it as a rebrand of your existing security program.
Who this is for, and what you'll walk away with
This is for compliance leads, security engineers, GRC managers, and founders whose customers, partners, or contracts require confidentiality commitments that go beyond "we protect personal data" — think law firms, staffing agencies, manufacturers with proprietary designs, SaaS platforms holding customer business data, and any B2B vendor under NDA. You'll leave able to explain the difference between Confidentiality, Privacy, and Security in a SOC 2 context; build a confidential-information inventory and classification scheme; map the C1.1 and C1.2 criteria to concrete controls and audit evidence; and design a retention-and-disposal process that satisfies both your auditor and your contractual commitments. We'll use ClauseHarbor and two other fictional organizations throughout as illustrative, quantified case studies — the numbers are illustrative, not published research.
Confidentiality is a Trust Services Criteria category — and it's optional
SOC 2 examinations are built on the AICPA's Trust Services Criteria (TSC), a framework of five categories a service organization can choose to be examined against. Security — formally the Common Criteria, the CC-series — is mandatory in every SOC 2 report. The other four categories are additive and optional: Availability, Processing Integrity, Confidentiality, and Privacy. An organization includes a category in its SOC 2 scope only if it's relevant to the service organization's commitments to its user entities — usually driven by what the organization has promised customers in contracts, marketing claims, or the system description itself.
Confidentiality is the TSC category that addresses information the entity has committed — by contract, policy, or law — to protect from unauthorized disclosure. It is genuinely optional. A company that stores no sensitive business information beyond what's already covered by Security controls, and that hasn't made specific confidentiality commitments to customers, may reasonably leave it out of scope. But once a customer contract includes language like "Vendor shall treat all Customer Data as Confidential Information" or a non-disclosure agreement is in force, an auditor and a savvy customer will expect to see Confidentiality addressed — either as an explicit TSC category in the report or, at minimum, folded into how Security controls are described.
"I ask every prospective client one question before we scope the engagement: 'What have you promised customers you'll keep confidential, in writing?' If the answer is longer than 'their personal data,' Confidentiality probably belongs in scope." — Priya Chandrasekaran, SOC 2 Lead Auditor, Beacon & Vance CPAs
The criteria that make up this category are deliberately narrow — only two additional criteria, C1.1 and C1.2 — because Confidentiality leans heavily on the Common Criteria's existing access control, encryption, and risk management controls (particularly CC6, logical and physical access controls). What Confidentiality adds is the requirement to specifically identify confidential information as a distinct category and to dispose of it deliberately when it's no longer needed. Everything else — how you restrict access, encrypt it, and monitor it — is largely inherited from Security controls applied to a more precisely defined scope of information.
Confidentiality vs. Privacy vs. Security: the distinction that trips everyone up
The single most common mistake I see in the field — across roughly 200 organizations I've advised on SOC 2 readiness — is treating Confidentiality as a synonym for either Security or Privacy. It's neither. Each of the three answers a different question.
Question | Security (Common Criteria) | Confidentiality | Privacy |
|---|---|---|---|
What does it govern? | The baseline control environment protecting all systems and data | Information specifically designated confidential by commitment, contract, or classification | Personal information about identifiable individuals |
Is it required in every SOC 2? | Yes — mandatory in all reports | No — optional, included when relevant | No — optional, included when relevant |
Primary criteria series | CC1–CC9 | C1.1–C1.2 (built on top of CC6 and related Security controls) | P1.1–P8.1 |
Typical scope of information | All systems, infrastructure, and data supporting the service | Contracts, source code, business plans, M&A data, customer business data, trade secrets, PII when designated confidential | Names, addresses, health data, financial data tied to an identifiable person |
Core question it answers | "Is the environment protected against unauthorized access, generally?" | "Is this specific information protected as promised, from identification through disposal?" | "Is personal information collected, used, retained, and disclosed appropriately?" |
Who typically requires it | Every SOC 2 report, by default | B2B customers, law firms, staffing agencies, IP-heavy businesses, NDA counterparties | Consumer-facing companies, healthcare, HR/payroll platforms, ad-tech |
Relationship to the other two | Foundation both others build on | Overlaps with Security controls, narrower scope, adds disposal focus | Can overlap with Confidentiality when personal data is also contractually confidential |
The practical rule of thumb I give clients: Security is about how well protected is everything; Confidentiality is about this specific designated information, tracked from creation to destruction; Privacy is about personal information about a person, regardless of whether it's marked confidential. A customer's Social Security number is both personal information (Privacy) and likely confidential information (Confidentiality) — the two categories aren't mutually exclusive, and PII is a subset that can live in both scopes simultaneously. But a company's unreleased product roadmap is confidential information with zero personal-data component — pure Confidentiality, no Privacy relevance at all. We'll come back to this decision logic later with a dedicated scoping table, and we cover the Privacy category in full in SOC 2 Privacy Criteria: Personal Information Management and Protection.
"The question I ask engineers who insist Confidentiality is 'just Security with extra paperwork' is simple: can you tell me, right now, which of your S3 buckets hold information a customer contract says you can't disclose? If you can't answer in under a minute, you don't have Confidentiality — you have Security and a guess." — Devon Ashworth, Director of Information Security, Meridian Fabrication Co.
The two criteria: C1.1 and C1.2, in plain language
Unlike the nine-category Common Criteria or the eight-criteria Privacy series, Confidentiality is deliberately compact. There are exactly two additional criteria, and both are short in wording but broad in what they demand operationally.
C1.1 — The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality. This is the identification-and-protection half. It requires the organization to define what counts as confidential information (per its own commitments and policies), locate where that information lives, and maintain — meaning continuously protect, not protect once — appropriate controls over it for as long as it's retained. "Maintain" is the operative word auditors probe hardest: a one-time data-mapping exercise from eighteen months ago that nobody has updated since does not satisfy C1.1.
C1.2 — The entity disposes of confidential information to meet the entity's objectives related to confidentiality. This is the end-of-life half. It requires the organization to actually get rid of confidential information — securely and completely — once it's no longer needed to meet the objectives that justified retaining it in the first place (a contract term, a legal hold, a stated retention period). Disposal has to be deliberate and evidenced, not "we assume it eventually rolled off a backup somewhere."
Both criteria are evaluated against the entity's own stated objectives and commitments — SOC 2 doesn't hand you a universal definition of "confidential" or a universal retention period. That's a deliberate design choice in the TSC: your confidentiality commitments come from your contracts, your data classification policy, applicable law, and industry norms, and the auditor tests whether you're living up to what you said you would do. This is also why the identification step (C1.1) has to happen before anything else — you cannot protect or dispose of what you haven't first defined and located.
Criterion | What it requires | Example controls | Example audit evidence |
|---|---|---|---|
C1.1 — Identify and maintain confidential information | Define confidential information categories; inventory where it lives; apply access, encryption, and handling controls; keep the inventory current | Data classification policy; confidential-information inventory/data map; access control lists tied to classification; encryption at rest and in transit; NDA repository; annual inventory review | Data classification policy document; asset/data inventory with classification tags; access review logs; encryption configuration screenshots; signed NDA log; inventory review sign-off |
C1.1 — Identify and maintain confidential information | Restrict access to confidential information on a need-to-know basis | Role-based access control tied to classification tier; periodic access recertification | Access control matrix; quarterly access review evidence; termination/offboarding access-revocation tickets |
C1.1 — Identify and maintain confidential information | Monitor for unauthorized access or disclosure of confidential information | DLP tooling; audit logging on confidential repositories; anomaly alerting | DLP policy configuration; alert logs; incident tickets tied to confidential-data handling |
C1.2 — Dispose of confidential information | Define retention periods per confidential-information category | Data retention schedule; contractual retention clauses mapped to systems | Data retention schedule document; contract clause extracts; retention policy approval record |
C1.2 — Dispose of confidential information | Securely and verifiably destroy confidential information at end of retention | Secure wipe/degauss/shred procedures; cryptographic erasure for cloud data; certificate of destruction from vendors | Destruction logs; certificates of destruction; sample tickets showing disposal requests closed |
C1.2 — Dispose of confidential information | Ensure disposal extends to backups, copies, and third parties holding the data | Backup retention/purge schedules; subservice organization disposal clauses; offboarding checklist for departing staff devices | Backup purge job logs; vendor contract disposal clauses; device wipe/return receipts |
"C1.2 is the criterion companies fail most often on re-audit, not because disposal is technically hard, but because nobody owns it. Encryption has an owner — usually engineering. Disposal falls into the gap between legal, IT, and whoever manages the file share, and gaps don't show up until an auditor asks for a destruction certificate that doesn't exist." — Priya Chandrasekaran, SOC 2 Lead Auditor, Beacon & Vance CPAs
What actually counts as "confidential information" — it's much broader than PII
This is where most teams under-scope Confidentiality badly. They hear "confidential" and think "personal data," fold it mentally into Privacy, and move on. But confidential information, in the SOC 2 sense and in ordinary contract law, is any information the organization has committed to protect from disclosure — regardless of whether it relates to an identifiable person. PII is one category among many, and often not even the largest one in a B2B context.
Category | Examples | Typical source of the confidentiality commitment |
|---|---|---|
Customer business data | Customer's sales figures, pricing models, strategic plans stored in your SaaS platform | Master services agreement, data processing addendum |
Contracts and legal documents | Draft agreements, redlines, negotiation notes, settlement terms | NDA, engagement letter, attorney-client privilege |
Intellectual property and source code | Proprietary algorithms, unpublished patents, product source code | Employment agreement, IP assignment, trade secret law |
Business and strategic plans | M&A plans, unreleased product roadmaps, pricing strategy, board materials | Board confidentiality policy, internal classification policy |
Financial information | Unaudited financials, cap tables, investor term sheets | Investor NDA, internal financial policy |
Employee and HR data (non-PII elements) | Compensation bands, performance reviews, disciplinary records | Employment policy, internal HR confidentiality standard |
Vendor and partner information | Partner pricing, reseller agreements, integration credentials | Vendor NDA, partnership agreement |
Personally identifiable information | Names, SSNs, addresses, when designated confidential by contract | Privacy law, data processing agreement (overlaps with Privacy TSC) |
Protected health information | Diagnosis codes, treatment records, insurance claims | HIPAA, business associate agreement (overlaps with Privacy TSC) |
Security-sensitive information | Penetration test reports, vulnerability scan results, network diagrams | Internal policy, customer security requirements |
Audit and compliance artifacts | The SOC 2 report itself, risk assessments, internal audit findings | AICPA restricted-use designation, NDA with report recipients |
The point of this table isn't that every organization has all eleven categories — it's that "confidential information" is a policy-defined term, and the policy has to be written before the inventory can be built. ClauseHarbor's inventory, once Maria's team built it properly, turned up confidential information in six of these eleven categories, and only two of the six were personal-data-adjacent. The other four — customer business data, contracts, IP/source code, and vendor information — would never have been caught by a Privacy-only lens.
"We had a Privacy policy and a Security policy and genuinely believed that covered us. What we didn't have was a definition of 'confidential' that included our own product source code and the contract language our sales team had promised customers. That gap is what almost cost us the insurance deal." — Maria Delgado, CFO, ClauseHarbor
Step 1: Identification — building the confidential-information inventory
C1.1 begins with a definition and an inventory, and both have to exist in writing before an auditor will accept that you're "identifying" confidential information rather than intuiting it. The practical sequence I walk clients through:
Draft a confidential information policy that defines what qualifies — pulling directly from contract language (customer MSAs, NDAs, vendor agreements), legal requirements, and internal risk appetite. This becomes the yardstick C1.1 is tested against.
Inventory systems and repositories that could hold confidential information: databases, file shares, SaaS tools (Slack, Notion, Google Drive, Salesforce), source code repositories, email, physical files, and employee devices. Don't stop at production databases — confidential information leaks into wikis, ticketing systems, and chat far more often than engineers expect.
Tag or classify each repository and, where feasible, individual data elements against the classification scheme (next section).
Map data flows — where confidential information enters the organization, where it's processed, where it's stored, who has access, and where it exits (to vendors, subprocessors, or customers).
Assign an owner to each confidential-information category — a named role responsible for its protection, review, and eventual disposal.
Review and refresh the inventory on a defined cadence (quarterly is common for fast-moving SaaS companies; annually at minimum) and whenever new systems, products, or major contracts are introduced.
This inventory is the single artifact auditors ask for earliest and reference most throughout Confidentiality testing — it's the backbone that every other C1.1 and C1.2 control gets validated against. Skipping it and jumping straight to "we encrypt everything" is the single most common readiness mistake I see; encryption without an inventory is a control with no defined scope.
Step 2: Classification — turning "confidential" into tiers people can actually apply
A binary "confidential / not confidential" label is too blunt for daily use — employees need to know how to treat something, not just that it matters. Most mature programs use a three- or four-tier classification scheme, mapped to specific handling rules.
Classification tier | Definition | Example content | Access rule | Handling requirement |
|---|---|---|---|---|
Public | Approved for unrestricted external release | Marketing site content, published blog posts, press releases | No restriction | No special handling |
Internal | Not for external release but broadly useful inside the company | Internal wikis, org charts, general process docs | All employees | Standard access controls; no external sharing without approval |
Confidential | Information the company has committed to protect from unauthorized disclosure | Customer contracts, business plans, source code, vendor pricing | Need-to-know, role-restricted | Encryption at rest/in transit, access logging, no unencrypted external transmission |
Restricted / Highly Confidential | Confidential information carrying elevated legal, financial, or reputational risk if disclosed | M&A materials, unreleased financials, litigation strategy, cryptographic keys | Named-individual access only, approval required | Encryption, access logging with alerting, watermarking, restricted printing/export, executive sign-off for any sharing |
Classification only works if it's attached to something enforceable — a label in a document management system, a folder-level permission, a database column tag, or a metadata field a DLP tool can act on. A classification policy that lives only in a PDF nobody reads isn't a control; it's a wish. ClauseHarbor implemented classification as metadata tags in its document platform, tied directly to sharing permissions — mark a contract "Confidential" and the platform automatically restricted external sharing and required MFA re-authentication to download it.
"Classification is the control that makes every other Confidentiality control possible. Access restriction, encryption, retention, disposal — they all need to answer 'confidential compared to what?' If you skip classification, you either over-protect everything and grind the business to a halt, or under-protect the things that actually matter." — Devon Ashworth, Director of Information Security, Meridian Fabrication Co.
Step 3: Protection — access restriction and encryption controls
Once information is identified and classified, C1.1's "maintain" requirement kicks in — ongoing protection, not a point-in-time gesture. This is where Confidentiality leans most heavily on Security controls (particularly the CC6 series governing logical and physical access control), applied specifically to the confidential-information inventory rather than to the environment generally.
Control area | What it looks like in practice | Why it matters for Confidentiality specifically |
|---|---|---|
Need-to-know access | Role-based access control scoped to classification tier, not just job function | Ensures access to confidential content is tied to a documented business need, not default org-wide visibility |
Least privilege | Default-deny permissions; explicit grants reviewed periodically | Prevents confidential repositories from inheriting broad "all employees" defaults common in SaaS tools |
MFA required for any system holding Confidential or Restricted-tier data | Raises the bar against credential-based unauthorized disclosure | |
AES-256 or equivalent for databases, file storage, backups holding confidential data | Renders stolen media or misconfigured storage unreadable without keys | |
TLS 1.2+ for all confidential data movement, including internal service-to-service traffic | Prevents interception on internal networks, not just the public internet | |
Data loss prevention (DLP) | Content-aware rules blocking or flagging confidential-tagged content leaving approved channels | Catches accidental or malicious exfiltration via email, chat, or cloud sync |
Dynamic watermarks on viewed/downloaded Restricted-tier documents | Deters and traces unauthorized redistribution of highly sensitive files | |
Access logging and monitoring | Audit logs on every access to Confidential/Restricted repositories, reviewed regularly | Provides evidence of who accessed what, and supports incident investigation |
Physical controls | Locked storage for any physical confidential documents; clean-desk policy; visitor escort | Extends protection beyond digital systems — physical files are frequently overlooked |
Third-party/vendor controls | Confidentiality clauses in vendor contracts; vendor access limited to minimum necessary | Confidential information routed through subservice organizations still needs equivalent protection |
Encryption deserves particular emphasis because auditors treat it as close to a baseline expectation for anything classified Confidential or above — its absence on a system holding contract data or source code is one of the fastest routes to a Type II exception. But encryption alone doesn't satisfy C1.1; it has to be paired with access restriction, because a well-encrypted database that every employee can query in plaintext through an application layer provides no real confidentiality protection at all.
NDAs and contractual commitments: where "confidential" gets legally defined
Confidentiality commitments don't originate in your security policy — they originate in contracts, and the security program's job is to operationalize what legal already promised. Every mature Confidentiality program maintains a clear line from contract language to control.
Contractual source | Typical confidentiality language | Operational control it drives |
|---|---|---|
Customer master services agreement | "Vendor shall protect Customer Confidential Information using no less than industry-standard safeguards" | Classification tagging of customer data; access restriction; encryption |
NDA with prospects/partners | "Recipient shall not disclose Confidential Information to third parties without Discloser's consent" | Access limited to named deal team; secure data room for shared materials |
Employment agreement / IP assignment | "Employee shall not disclose Company trade secrets during or after employment" | Offboarding access revocation; device return and wipe; exit interview confidentiality reminder |
Vendor/subprocessor agreement | "Vendor shall dispose of Confidential Information upon contract termination" | Vendor offboarding checklist; certificate of destruction requirement |
SOC 2 report distribution agreement | Report is restricted-use; recipients bound by NDA before receiving it | Report distribution log; recipient NDA on file before transmission |
A confidential-information inventory that isn't cross-referenced against active NDAs and contract clauses is incomplete — I've seen organizations build a technically excellent classification and access-control program that still failed C1.1 testing because nobody could produce the underlying contract commitment that justified calling a given dataset "confidential" in the first place. Auditors will sample contracts and trace the language forward to controls; make that traceability easy by keeping a central NDA and confidentiality-clause repository, something ClauseHarbor built as a simple tagged registry in its contract management tool.
The confidential-data lifecycle
Every piece of confidential information moves through the same five stages, and Confidentiality controls exist at each one. Mapping your controls against this lifecycle is the fastest way to spot a gap — most organizations I assess have decent controls at "protect" and almost nothing documented at "identify" or "dispose."
flowchart LR
A[Identify] --> B[Classify]
B --> C[Protect]
C --> D[Retain]
D --> E[Dispose]
E -.feedback.-> A
A2[Confidentiality policy<br/>+ data inventory] -.-> A
B2[Classification tiers<br/>+ tagging] -.-> B
C2[Access control<br/>+ encryption + DLP] -.-> C
D2[Retention schedule<br/>+ legal holds] -.-> D
E2[Secure destruction<br/>+ certificates] -.-> ERead left to right: information is identified against the confidentiality policy the moment it's created or received; it's classified into a tier that determines handling rules; it's protected with access controls, encryption, and monitoring for as long as it's in active use; it's retained only for as long as a defined schedule or legal requirement justifies; and it's disposed of securely and verifiably at end of life, with the disposal event feeding back into the inventory so the record stays current. C1.1 covers the first three stages; C1.2 covers the last two. Miss any stage and the chain breaks — protection without disposal just accumulates risk indefinitely, and disposal without identification means you're guessing at what needs destroying.
Retention: how long is "confidential" information supposed to live?
Retention is the bridge between C1.1 and C1.2 — you can't dispose of something responsibly (C1.2) without first deciding, and documenting, how long you intend to keep it (part of maintaining it under C1.1). Retention periods for confidential information typically come from three sources: contractual terms, legal/regulatory requirements, and internal business need — and the longest applicable requirement usually governs.
Confidential information type | Common retention driver | Typical retention period (illustrative) | Disposal trigger |
|---|---|---|---|
Active customer contracts | Contract term + statute of limitations for disputes | Duration of contract + 6–7 years | Contract termination and expiry of legal-claim window |
Terminated/expired contracts (no dispute) | Legal/tax requirements | 6–7 years post-termination | End of retention period reached |
Source code (deprecated products) | Business/IP value, litigation risk | Indefinite while product live; review at end-of-life | Product sunset + no active legal hold |
M&A and strategic planning materials | Deal lifecycle, board policy | Deal duration + defined post-close period (e.g., 2 years) | Deal closes or terminates, retention window expires |
Employee HR confidential records | Employment law | Typically 3–7 years post-termination (jurisdiction-dependent) | End of statutory retention period |
Vendor confidential data (post-offboarding) | Vendor contract terms | Per contract, often 30–90 days for transition support | Contract termination + agreed transition period ends |
SOC 2 report copies received from vendors | Internal vendor risk policy | Current report cycle + 1 prior cycle | New report supersedes; prior report expires |
Backup copies of confidential data | Technical backup policy, often shorter than primary retention debate | 30–90 days rolling, subject to legal holds | Rolling deletion per backup policy, absent a hold |
The retention schedule has to be a living document with named ownership — legal or GRC typically owns it, with IT/engineering responsible for technical enforcement (automated purge jobs, backup rotation policies). Legal holds are the one exception that overrides every retention schedule: if information becomes relevant to litigation, a regulatory inquiry, or an internal investigation, disposal must be suspended for that information regardless of what the schedule says, and that suspension has to be documented and lifted formally when the hold ends.
Disposal: making C1.2 defensible
Disposal is where good intentions meet technical reality — "we deleted it" is not evidence, and modern storage architectures (replicated databases, distributed backups, cached copies, third-party processors) make "complete" disposal genuinely harder than it sounds. The auditor's question is simple: can you prove destruction happened, completely, for a sample of records?
Storage medium | Disposal method | Evidence produced |
|---|---|---|
Physical documents | Cross-cut shredding or certified document destruction vendor | Destruction log; vendor certificate of destruction |
Laptops/workstations (retired) | Full-disk wipe (NIST 800-88 compliant) or physical destruction for failed drives | Wipe tool completion log; asset disposal record |
Cloud object storage (e.g., S3-style buckets) | Deletion via lifecycle policy plus cryptographic erasure of encryption keys for versioned/replicated copies | Lifecycle policy configuration; key destruction log |
Database records | Row-level deletion plus purge of associated backups at end of backup retention | Deletion job logs; backup rotation confirmation |
Backup tapes/archives | Physical destruction at end of retention, or cryptographic erasure for encrypted archives | Destruction certificate; key revocation record |
SaaS/collaboration tools (Slack, Drive, wikis) | Admin-level purge plus confirmation of vendor-side deletion per DPA | Admin deletion confirmation; vendor deletion attestation |
Employee devices (offboarding) | Remote wipe (MDM) confirmed before device reissue or disposal | MDM wipe confirmation log |
Third-party/subservice organization copies | Contractual disposal requirement invoked at contract end | Vendor certificate of destruction or deletion confirmation email |
"Deletion" and "destruction" aren't interchangeable for audit purposes — deleting a database row that still exists in an unpurged backup for the next 90 days is not disposal, it's a delay, and that's fine if the retention schedule accounts for it. The failure mode is claiming disposal occurred on the date of the delete action while backups (and therefore the actual confidential information) persist for months afterward. Document both dates — logical deletion and final backup purge — and treat the later one as the true disposal date for evidence purposes.
"Every disposal exception I've written up in the last three years traces back to the same root cause: someone deleted the record in the primary system and considered the job done, without checking what was still sitting in a 12-month-old backup archive nobody had a purge policy for." — Priya Chandrasekaran, SOC 2 Lead Auditor, Beacon & Vance CPAs
Who owns what: a RACI for Confidentiality controls
Confidentiality fails as a program when it's assumed to belong entirely to security engineering. In practice it's cross-functional — legal defines commitments, security implements technical controls, and business teams handle day-to-day classification decisions. A clear RACI heads off the most common excuse I hear during readiness assessments: "I thought that was someone else's job."
Activity | Legal/GRC | Security/IT | Engineering | Business unit owners | Auditor (external) |
|---|---|---|---|---|---|
Define confidentiality policy and classification tiers | Accountable | Consulted | Consulted | Consulted | Reviews |
Build and maintain confidential-information inventory | Consulted | Responsible | Responsible | Consulted | Reviews |
Classify/tag content at creation | Informed | Consulted | Consulted | Responsible | Reviews |
Implement access control and encryption | Informed | Responsible | Responsible | Informed | Tests |
Negotiate and track NDAs/contract confidentiality clauses | Responsible | Informed | Informed | Consulted | Reviews |
Set retention schedule | Accountable | Consulted | Consulted | Consulted | Reviews |
Execute disposal (technical) | Informed | Responsible | Responsible | Informed | Tests |
Verify and evidence disposal | Consulted | Responsible | Informed | Informed | Tests |
Offboarding access/device revocation | Informed | Responsible | Informed | Consulted | Tests |
Annual inventory and policy review | Accountable | Responsible | Consulted | Consulted | Reviews |
Case study: Meridian Fabrication Co. and the departing engineer
Meridian Fabrication Co., a 340-employee industrial equipment manufacturer, brought Devon Ashworth in as Director of Information Security after a near-miss that reframed how leadership thought about Confidentiality. A senior mechanical design engineer resigned to join a direct competitor. Standard offboarding revoked his badge and email access within the hour — solid Security-criteria hygiene. But nobody checked what confidential information he'd synced locally over four years: proprietary CAD files, supplier cost sheets, and an unreleased product design worth an estimated $4.3 million in projected first-year revenue, all sitting on a personal cloud backup he'd configured on his work laptop eighteen months earlier, undetected because Meridian had no DLP monitoring on engineering workstations.
Legal caught it only because a departing-employee exit interview checklist item — "confirm no company IP retained on personal devices or accounts" — prompted a direct question the engineer answered honestly. Meridian recovered the files and secured a written destruction confirmation before the competitor relationship became public, avoiding what outside counsel estimated could have been a six-figure legal action plus incalculable competitive harm. But the incident exposed that Meridian's Security controls (access revocation) worked perfectly while its Confidentiality controls (knowing what confidential IP existed, where, and ensuring its disposal at offboarding) didn't exist at all.
Devon's team spent four months building a Confidentiality program from that gap: an engineering-specific confidential-information inventory covering CAD files and supplier data, DLP rules blocking personal cloud sync on any workstation touching the design repository, and an offboarding checklist requiring device forensic review — not just access revocation — before a departing employee's final paycheck was released. Meridian's next SOC 2 Type II examination included Confidentiality in scope for the first time, with zero exceptions.
"We had excellent Security controls and a $4 million near-miss anyway, because Security answers 'can this person still log in,' not 'what confidential information did this person have, and did it leave with them.' Those are different questions and you need different controls to answer each one." — Devon Ashworth, Director of Information Security, Meridian Fabrication Co.
Meridian Fabrication Co. — before and after | Before | After |
|---|---|---|
Confidential-information inventory | None (engineering IP untracked) | Full inventory across CAD, supplier, and pricing data |
DLP on engineering workstations | Not deployed | Deployed, blocking unauthorized personal cloud sync |
Offboarding process | Access revocation only | Access revocation + device forensic review + confidentiality attestation |
Estimated IP at risk in near-miss incident | $4.3M projected first-year product revenue | N/A — control now prevents recurrence |
SOC 2 Confidentiality scope | Out of scope | In scope, zero exceptions on first examination |
Time to build program | — | 4 months |
Common pitfalls that generate Confidentiality exceptions
Pitfall | Why it happens | How to fix it |
|---|---|---|
Treating Confidentiality as identical to Privacy | Both sound like "protect sensitive data"; teams conflate them | Build a separate confidential-information definition and inventory independent of the PII/Privacy data map |
No documented inventory, only tribal knowledge | Inventory work feels like overhead with no immediate payoff | Assign an owner, timebox the first pass, treat it as a living document reviewed quarterly |
Classification policy exists but isn't enforced technically | Policy written by legal/GRC, never wired into actual systems | Tie classification tags to access permissions and DLP rules, not just document headers |
Backups and archives excluded from disposal scope | Primary-system deletion is visible; backup purge is not | Explicitly include backup/archive retention in the retention schedule and track final purge dates |
Confidential information in unmanaged SaaS tools (chat, wikis) | Classification programs focus on databases and file shares, miss collaboration tools | Extend inventory and DLP coverage to Slack, Notion, Google Workspace, ticketing systems |
Vendor/subservice organizations not held to disposal terms | Contracts silent on data destruction at offboarding | Add explicit disposal/certificate-of-destruction clauses to vendor agreements |
No legal-hold process to override retention/disposal | Retention automation runs regardless of litigation risk | Build a formal legal-hold flag that suspends automated purge jobs for named records |
Departing employees retain confidential data on personal devices/accounts | Offboarding checks access, not data retained locally or synced elsewhere | Add device/account forensic review and a signed confidentiality attestation to offboarding |
Confidentiality treated as a one-time project, not a maintained control | Program stands up for the audit, then goes stale | Assign ongoing ownership with a recurring review cadence baked into the compliance calendar |
Case study: Vantage Staffing Solutions and the client offboarding gap
Vantage Staffing Solutions placed contract workers with enterprise clients and, in the process, held candidate resumes, client hiring criteria, client compensation bands, and — for a handful of enterprise accounts — draft organizational restructuring plans shared under NDA so Vantage could plan staffing needs ahead of public announcements. Sana Okafor, Vantage's newly hired Head of GRC, discovered during SOC 2 readiness work that Vantage had a strong Privacy program (candidate PII was well classified and access-restricted) but had never separately accounted for client business confidential information — the restructuring plans and compensation data lived in the same recruiter-accessible shared drive as ordinary job requisitions, visible to all 45 recruiters rather than the three account managers under NDA for those specific clients.
Worse, when a client relationship ended, Vantage's offboarding process closed the billing account but never triggered review or disposal of that client's confidential planning documents — some records from clients Vantage hadn't worked with in over three years were still sitting, fully accessible, in the shared drive. Sana's gap analysis found confidential material for 14 former clients with no active retention justification, several past any reasonable contractual or legal retention window.
Sana built a two-part fix: a classification pass separating "client confidential" (NDA-governed business information) from ordinary recruiting PII, with access restricted to named account managers under NDA per client; and a client-offboarding trigger that automatically flagged confidential records for legal review and disposal 90 days after a client relationship formally ended, unless a documented reason existed to extend retention. The disposal pass alone reduced Vantage's confidential-document footprint by roughly 40%, and the access restriction eliminated firm-wide visibility into NDA-governed client plans. Vantage's auditor cited the before-state as a clear C1.1 and C1.2 gap during a pre-audit gap analysis; both were remediated before formal Type II fieldwork began, and the report was issued with no exceptions in either criterion.
"Privacy told us we were protecting candidates. It told us nothing about whether we were protecting our clients' confidential business plans — and those were sitting in a drive every recruiter in the company could open. That's not a Privacy gap. That's a Confidentiality gap, and until I separated the two in my own head, I couldn't even see it." — Sana Okafor, Head of GRC, Vantage Staffing Solutions
Vantage Staffing Solutions — remediation snapshot | Metric |
|---|---|
Former clients with confidential records past retention justification | 14 |
Recruiters with unrestricted access to NDA-governed client plans (before) | 45 |
Recruiters with access after remediation (named account managers only) | 6 |
Reduction in confidential-document footprint after disposal pass | ~40% |
Time from gap identification to remediation | 10 weeks |
C1.1/C1.2 exceptions in final Type II report | 0 |
Evidence: what auditors actually sample for Confidentiality
Type II testing for Confidentiality is evidence-over-time testing, not a one-day walkthrough. Auditors sample transactions and configurations across the observation period and expect to see consistent operation, not a control that existed only in the weeks before fieldwork.
Evidence type | What the auditor is checking | Sampling approach |
|---|---|---|
Confidentiality/classification policy | Policy exists, is approved, and defines categories and tiers | Full document review, version history check |
Confidential-information inventory | Inventory is current, covers in-scope systems, assigns owners | Reviewed at report date; sampled against actual systems for completeness |
Access control lists and permission configurations | Access to Confidential/Restricted-tier data is restricted and justified | Sampled at multiple points across the audit period |
Access review/recertification records | Periodic reviews actually occurred and resulted in access changes where needed | Sampled quarterly or per defined cadence |
Encryption configuration | Encryption at rest/in transit is enabled on in-scope confidential repositories | Configuration screenshots/exports, sampled |
NDA and contract repository | Confidentiality commitments are documented and traceable to controls | Sampled contracts cross-referenced to inventory entries |
Retention schedule | Retention periods are defined and approved | Full document review |
Disposal logs and destruction certificates | Disposal actually occurred, on schedule, with evidence | Sampled disposal events across the period |
Offboarding records | Departing employees had access revoked and devices reviewed/wiped | Sampled terminations across the period |
DLP alerts and incident tickets | Unauthorized disclosure attempts were detected and handled | Sampled alerts, reviewed for resolution |
Vendor/subservice confidentiality clauses | Third parties handling confidential data are contractually bound and monitored | Sampled vendor contracts and any disposal confirmations |
Tooling: what supports a Confidentiality program technically
No single tool delivers Confidentiality compliance — it's a control layer built from several categories working together, most of which organizations already own in some form for Security purposes and simply need to extend in scope and rigor.
Tool category | Role in Confidentiality controls | Notes |
|---|---|---|
Data classification/discovery tools | Automated scanning to locate and tag confidential content across repositories | Reduces reliance on manual tagging; useful for the initial inventory pass |
DLP platforms | Enforce handling rules based on classification; block/flag unauthorized exfiltration | Most effective when classification tags feed directly into DLP policy |
Identity and access management (IAM) | Central enforcement of role-based, need-to-know access | Should be the single source of truth for who can reach confidential repositories |
Encryption key management | Manages encryption keys for data at rest, supports cryptographic erasure at disposal | Key destruction is often the fastest, most auditable disposal method for cloud data |
Document management/e-signature platforms | Store contracts and NDAs, track confidentiality clauses | Enables the contract-to-control traceability auditors sample |
Mobile device management (MDM) | Remote wipe of confidential data on lost/stolen or offboarded devices | Critical for the "confidential data walked out the door" failure mode |
GRC/compliance platforms | Track inventory, retention schedules, disposal tickets, and evidence collection centrally | Turns scattered evidence into an audit-ready trail |
Secure destruction vendors | Physical shredding, certified device wiping, certificate issuance | Needed for physical documents and retired hardware |
Timeline and cost: what it takes to stand up Confidentiality in scope
These figures are illustrative, drawn from patterns across client engagements of comparable size — actual cost and timeline depend heavily on how much confidential information sprawl already exists and how mature your Security program is going in.
Company profile | Estimated timeline to Confidentiality readiness | Primary cost drivers | Illustrative one-time cost range |
|---|---|---|---|
Early-stage SaaS (under 50 employees, limited confidential info beyond contracts) | 4–6 weeks | Policy drafting, inventory build, access cleanup | $8,000–$18,000 |
Mid-market SaaS/services (50–300 employees, IP + customer business data) | 8–14 weeks | Inventory build, DLP tooling, classification rollout, disposal process design | $25,000–$70,000 |
Manufacturing/IP-heavy organization (design data, source code, supplier contracts) | 12–20 weeks | Engineering system inventory, DLP for design tools, offboarding process rebuild | $40,000–$100,000 |
Staffing/professional services (client-confidential business data across many accounts) | 8–16 weeks | Per-client access segmentation, contract cross-referencing, disposal automation | $30,000–$75,000 |
These figures reflect one-time program build costs; ongoing maintenance (quarterly reviews, access recertification, DLP tuning) typically runs 10–20% of the initial build cost annually, and should be budgeted as a recurring line item rather than treated as a one-time audit expense.
Deciding what belongs in scope: Confidentiality, Privacy, both, or neither
Because Confidentiality and Privacy overlap where personal information is also contractually confidential, teams often struggle to decide whether they need one category, both, or can reasonably stay out of both. This decision table reflects the questions I ask during scoping calls.
Situation | Include Confidentiality? | Include Privacy? |
|---|---|---|
You hold only routine business PII (employee payroll, basic CRM contacts) with no specific confidentiality commitments beyond standard data protection | Optional — likely not needed | Consider, if consumer-facing or handling sensitive personal data |
Customer contracts explicitly designate "Customer Data" or "Confidential Information" and require specific handling | Yes | Only if that data includes personal information about identifiable individuals |
You handle unpublished IP, source code, M&A materials, or business plans with no personal-data component | Yes | No |
You process consumer personal data at scale (marketing, ad-tech, consumer apps) with no other confidential business information | Consider, if contracts require it | Yes |
You're a B2B platform storing customers' proprietary business data (pricing, plans, contracts) that also includes their end-customers' PII | Yes | Yes — both apply to different parts of the data |
You're under active NDAs with partners/vendors covering non-personal business information | Yes | Not applicable to that specific commitment |
No specific confidentiality or personal-data commitments beyond baseline Security controls | Likely not needed | Likely not needed |
If in doubt, the safer default is to ask what your sales and legal teams have already promised in signed contracts — SOC 2 scope should follow real commitments, not aspirational breadth. Adding Confidentiality to a report that doesn't reflect genuine confidentiality commitments creates audit work without customer-trust payoff; leaving it out when contracts require it creates a credibility gap the moment a sophisticated customer's security team reads the report closely. For a full walkthrough of how all five TSC categories fit together, see SOC 2 Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, Privacy.
"I've turned away two prospective clients who wanted Confidentiality in their report purely because a competitor had it, with no underlying contractual commitment to test against. You can't audit a promise that doesn't exist. Fix the contracts and the commitments first; the report follows." — Priya Chandrasekaran, SOC 2 Lead Auditor, Beacon & Vance CPAs
How Confidentiality interacts with the Common Criteria in your report
Because Confidentiality's two criteria lean so heavily on Security controls already in scope, your System Description and control matrix should show the relationship explicitly rather than duplicating control language. In practice, most organizations write their access control, encryption, and monitoring controls once — under the relevant CC6 Common Criteria — and then reference those same controls in the Confidentiality section, adding only what's genuinely additional: the confidential-information definition, the inventory, the classification scheme, and the disposal process. Auditors expect to see this cross-referencing; duplicating identical control descriptions under both Security and Confidentiality headings, worded differently, tends to create inconsistencies that show up as findings. If you haven't yet built out your core Security control set, start there — see SOC 2 Security Criteria: Comprehensive Control Implementation — because Confidentiality controls are only as strong as the access management and encryption foundation they sit on.
This layering is also why organizations frequently discover Confidentiality gaps during a readiness assessment for Security alone: the risk assessment process required under CC3 naturally surfaces questions like "what happens to this data when the contract ends," and those questions lead straight into C1.1 and C1.2 territory even before Confidentiality is formally scoped in.
Confidentiality as a business differentiator, not just an audit line item
It's tempting to treat Confidentiality as a checkbox that gets added to a SOC 2 report because a customer's security questionnaire asked for it. Organizations that get the most value from it do the opposite — they use the discipline of building a confidential-information inventory and classification scheme to actually reduce risk, not just document it. ClauseHarbor's inventory work surfaced and fixed an over-permissioned shared drive that had nothing to do with the audit deadline; Meridian's near-miss became the catalyst for a program that now protects IP worth many multiples of what the program cost to build; Vantage cut its confidential-document footprint by 40% simply by finally asking what it was still holding and why.
For sales teams, a SOC 2 report with Confidentiality in scope — paired with clear internal answers to "what counts as confidential here, and how do we protect and eventually destroy it" — closes deals that a Security-only report can't. Enterprise procurement teams, law firms, and highly regulated customers increasingly ask for it explicitly, and being able to answer confidently in a security questionnaire, rather than scrambling to build a program against a deal deadline the way Maria's team did, is worth planning for well before it's contractually forced. Treat identification and disposal as ongoing operational disciplines — not audit-season fire drills — and the Confidentiality criteria stop being a compliance burden and start being a genuine information-governance asset.
If you're building or tightening a Confidentiality program, PentesterWorld's SOC 2 Trust Services Criteria Mapping Template gives you a starting structure for tying C1.1 and C1.2 to your own controls, and the SOC 2 Control Matrix / RACI Template can be adapted directly from the RACI table above. If you're not yet sure whether Confidentiality belongs in your scope at all, our SOC 2 Gap Analysis Tool and a structured SOC 2 Readiness Checklist will help you map your actual contractual commitments before you commit to audit scope. And if your organization is earlier in the journey and still weighing SOC 2 against other frameworks, our SOC 2 vs ISO 27001 Comparison Guide walks through how the two approach information protection differently. For hands-on help scoping Confidentiality against your real contracts and data footprint, PentesterWorld's advisory team can run a targeted readiness assessment before your next audit cycle.