What Confidentiality actually requires
The AICPA Trust Services Criteria for Confidentiality define the controls that demonstrate confidential information designated as such is protected as committed or agreed. The criterion is published as part of the AICPA TSP Section 100 framework available at aicpa.org and covers four domain areas: data classification (identifying which information is classified as confidential), encryption requirements both at rest and in transit, access controls restricting confidential data to authorised users, and secure data deletion procedures with verification. The control set is layered on top of the Security Common Criteria; a Confidentiality scope means the auditor tests the Common Criteria plus the Confidentiality-specific criteria during the same engagement.
The reason Confidentiality is the second-easiest of the four optional criteria to add (after Availability) is that 60 to 80 percent of the controls are already covered by the Security Common Criteria. Encryption at rest, encryption in transit, access controls, and secure data handling are all part of the baseline Security work. The marginal audit work for Confidentiality is the explicit data classification scheme (which most SaaS does not have formally documented even when it operates implicit classification through engineering practice) and the confidentiality-specific evidence that demonstrates the classification scheme is being applied consistently.
What the marginal cost actually depends on
There is no published figure for what Confidentiality adds, because no CPA firm publishes a SOC 2 rate card of any kind and a criterion add-on is one component of a fee set per engagement. Anyone quoting a precise Confidentiality add-on split by firm tier is quoting a number nobody published. The mechanism, though, is knowable, and for this criterion it points somewhere specific.
On the audit side the increment is usually modest, because Confidentiality overlaps heavily with the Security Common Criteria you are already being tested against: much of the encryption, access-control and data-handling evidence does double duty. The cost that surprises people is not the audit fee at all. It is the data classification scheme, which is frequently an artifact the company does not yet have and has to design, document, socialise and then operate. That work lands in readiness, and it has to happen before the observation period opens rather than during it. To get your real number, ask one firm to quote Security only and Security plus Confidentiality against the same written scope, then budget the classification-scheme work separately, because no auditor quote will price it for you.
When to scope Confidentiality in
The clearest scoping decision is whether the customer Master Services Agreements include data confidentiality classifications. If the SaaS receives customer data that the MSA designates as confidential (which is typical for B2B SaaS handling enterprise customer data), Confidentiality scope is typically the right call because the customer's procurement team will see the Confidentiality TSC in the SOC 2 report as objective evidence that the SaaS has tested controls protecting the data classified as confidential. Without Confidentiality scope, the customer has the contractual confidentiality commitment but no third-party-attested operational verification.
The secondary scoping driver is the customer base composition. SaaS selling primarily into late-stage enterprise procurement (where data confidentiality classifications are deeply tracked through vendor risk reviews) benefits more from Confidentiality scope than SaaS selling into smaller customers. The third driver is the SaaS's existing data handling practices. Companies that already operate explicit data classification through engineering practice (e.g. data lifecycle management with explicit policies for customer data, source code, financial data, and employee data) find Confidentiality scope nearly free in marginal effort terms; companies that operate implicit classification need to formalise the scheme before the audit.
When to skip Confidentiality and stay with Security only
Consumer SaaS, internal-tool SaaS, and pure aggregated-analytics SaaS without confidentiality classifications can typically skip Confidentiality and stay with Security only. The criterion does not provide additional procurement signal for buyers who do not handle data with explicit confidentiality classifications. SaaS at very early stage where the data handling practices are still maturing can defer Confidentiality scope to a later year when the operational practices are formalised.
The other case for skipping is when the SaaS handles customer data but the customer base does not specifically require confidentiality controls in vendor risk reviews. This is increasingly rare in B2B enterprise procurement but still common in SMB-focused SaaS where vendor risk reviews are less formal. Adding Confidentiality scope without the customer-facing demand for it is over-spend.
Specific controls to implement or formalise
The control set that satisfies Confidentiality TSC requirements is consistent across audit firms. Document the following: data classification scheme with classification levels (typically Public, Internal, Confidential, Restricted) and handling procedures for each level; encryption at rest for confidential data using AES-256 or equivalent (most managed cloud database services provide this by default); encryption in transit using TLS 1.2 or higher (TLS 1.3 preferred); access controls restricting confidential data to authorised users with documented authorisation procedures and periodic access reviews (typically quarterly or semi-annual); documented secure data deletion procedures with verification (cryptographic deletion of encryption keys for confidential data is the simplest implementation); confidentiality agreements signed by all employees and contractors with access to confidential data, plus vendor confidentiality agreements where applicable; documented data retention schedule with explicit confidential-data retention rules; key management procedures for encryption keys including rotation schedule. Most B2B SaaS at Series A and beyond already has these; the SOC 2 work is documenting the data classification scheme and the confidentiality-specific access controls.
How Confidentiality fits with the other optional criteria
For most B2B SaaS handling enterprise customer data, the typical scoping order is Availability plus Confidentiality together, both layered onto Security Common Criteria. Together they give the broadest procurement-team coverage for typical B2B SaaS vendor risk review questions, and because both overlap substantially with Security, scoping them into the same engagement is less than twice the marginal work of either one alone. Processing Integrity is rarely scoped except for SaaS where data processing accuracy is core to the value proposition. Privacy is the highest-cost add-on and is typically scoped only for GDPR / CCPA-regulated SaaS, healthcare, AdTech, or edutech where the privacy-control overlay is editorially required.
The other practical consideration is that adding Confidentiality scope requires the data classification scheme to be in place before the audit observation period begins (3 to 12 months before the report date). If the SaaS does not have a documented data classification scheme today, plan to develop and implement it during the readiness phase before the audit observation period begins, not during fieldwork.