What Are the Trust Services Criteria?

The Trust Services Criteria are the control criteria an independent CPA firm evaluates your organization against in a SOC 2 examination, and as of August 2026 the current version is TSP section 100, the 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy, revised in 2022 to update its points of focus (AICPA & CIMA). Underneath the five categories sit 61 numbered criteria: 33 common criteria, plus 3 for availability, 2 for confidentiality, 5 for processing integrity and 18 for privacy, counted from the criteria table in that document. Here is the part almost every explainer gets wrong, including some auditors in casual conversation: the five are categories, not criteria. Nobody tests five things. They test the 61 that apply to the categories in your scope, and "we are doing three of the five criteria" is a sentence that describes nothing anyone can audit.

This article gives the AICPA's own definitions of the five categories, breaks the 61 criteria down by where they come from, explains why the points of focus underneath them are not requirements, and works through the single scoping decision that actually moves the size of your engagement.

Key takeaways

• The Trust Services Criteria are published by the AICPA's Assurance Services Executive Committee as TSP section 100. The edition distributed today is the 2017 criteria with points of focus revised in 2022; the criteria still run on their 2017 numbering.
• Five categories, 61 criteria. The 33 common criteria apply to every category, so they are the bulk of any SOC 2 regardless of what else you select.
• The first 17 common criteria (CC1 through CC5) restate the 17 COSO internal control principles. CC6 through CC9 are the AICPA's supplemental technology criteria: logical and physical access, system operations, change management and risk mitigation.
• Points of focus are not criteria. TSP section 100 says use of the criteria "does not require an assessment of whether each point of focus is addressed". Treating them as a checklist is the most common way a first control set gets inflated.
• Adding a category is not a uniform cost. Confidentiality adds 2 criteria; privacy adds 18. Those two decisions are not the same size and should not be made in the same meeting.

What the document actually is

TSP section 100 is a criteria document, not a control framework and not a checklist of things to implement. The AICPA describes it as presenting "control criteria established by the AICPA's Assurance Services Executive Committee (ASEC) for use in attestation or consulting engagements to evaluate and report on controls over the security, availability, processing integrity, confidentiality, or privacy of information and systems used to provide products or services".

Two consequences follow from that wording and they explain a lot of the confusion in the market.

First, the criteria describe outcomes, not mechanisms. No criterion says "use multi-factor authentication" or "run a penetration test annually". Management selects the controls; the criteria are the yardstick they are measured against, which is why two companies with genuinely different architectures can both hold clean SOC 2 reports.

Second, the AICPA is a source with an interest here worth naming: it publishes the criteria, licenses the SOC brand, and sells the guides and continuing education around them. That does not make the criteria wrong, and TSP section 100 is the authoritative text whether or not the publisher benefits from it. It is simply a reason to read the primary document rather than a vendor's summary of it.

The 2022 revision is also narrower than its billing. What the AICPA distributes today is the 2017 criteria with points of focus revised in 2022, which is what the document's own title says, and the criteria still run on their 2017 identifiers. If a vendor tried to sell you a remediation project on the strength of "the 2022 update", ask which criterion changed.

The five categories, in the AICPA's own definitions

Each category is one sentence in TSP section 100, and the sentence is worth having in front of you because the popular paraphrases drift.

Security. "Information and systems are protected against unauthorized access, unauthorized disclosure of information, and damage to systems that could compromise the availability, integrity, confidentiality, and privacy of information or systems and affect the entity's ability to achieve its objectives."

Availability. "Information and systems are available for operation and use to meet the entity's objectives." The document adds a caveat that is regularly missed: the availability objective "does not, in itself, set a minimum acceptable performance level". Availability in scope does not mean your uptime number is being audited. It means the controls supporting accessibility, monitoring and maintenance are.

Processing integrity. "System processing is complete, valid, accurate, timely, and authorized to meet the entity's objectives." The AICPA notes this is usually addressed at the system or functional level rather than across a whole entity.

Confidentiality. "Information designated as confidential is protected to meet the entity's objectives." Note the word designated. If nothing in your contracts or classification scheme designates information as confidential, this category has very little to bite on.

Privacy. "Personal information is collected, used, retained, disclosed, and disposed of to meet the entity's objectives." The document draws the line between this and confidentiality directly: "Although confidentiality applies to various types of sensitive information, privacy applies only to personal information."

Categories are not criteria, and the difference is the work

The 61 criteria break down like this, counted from the criteria table in TSP section 100:

• Common criteria (CC series): 33. CC1 control environment (5), CC2 information and communication (3), CC3 risk assessment (4), CC4 monitoring of controls (2), CC5 control activities (3), CC6 logical and physical access controls (8), CC7 system operations (5), CC8 change management (1), CC9 risk mitigation (2).
• Availability (A1 series): 3.
• Confidentiality (C1 series): 2.
• Processing integrity (PI1 series): 5.
• Privacy (P1 through P8 series): 18.

Two structural facts hide in that list.

The first is that CC1 through CC5 come to 17 criteria, and that is not a coincidence. They are the 17 principles of the COSO Internal Control, Integrated Framework, restated as criteria. TSP section 100 presents COSO-derived material in a normal font and the AICPA's own supplemental material in italics, precisely so a reader can tell which is which. If your SOC 2 readiness work feels like a governance exercise rather than a security exercise for the first several weeks, that is why: more than half the common criteria are about the control environment, communication, risk assessment and monitoring, not about firewalls.

The second is that CC6 through CC9 are where the technology lives: 16 of the 33 cover logical and physical access, system operations, change management and risk mitigation. When someone says a SOC 2 is "mostly access control and change management", they are describing CC6 and CC8 and forgetting the 17 that came before.

Points of focus are not requirements

Underneath each criterion, TSP section 100 lists points of focus: characteristics that "may assist both management and the practitioner when they are evaluating whether the controls were suitably designed and operated effectively to achieve the entity's objectives based on the trust services criteria".

The document then says the thing that saves programs: "Use of the trust services criteria does not require an assessment of whether each point of focus is addressed." The same passage allows that some points of focus "may not be suitable or relevant to the entity or to the engagement to be performed", in which case management may customize a point of focus or consider other characteristics that fit the entity.

We raise this in nearly every readiness engagement because the failure mode is so consistent. A team pulls the criteria into a spreadsheet, expands every point of focus into a row, and ends up with several hundred obligations, most of which nobody owns and some of which do not apply. The criterion is the requirement; the points of focus are a prompt for thinking about how to meet it. A control set built one-to-one against points of focus is not more rigorous, just larger, and every extra control is evidence you produce every period for the life of the program.

The scoping decision that actually costs money

Choosing categories is the one moment in a SOC 2 where a decision made in an hour changes the size of every later audit cycle. Get the arithmetic in front of the people making it.

Adding confidentiality adds 2 criteria, the cheapest addition on the list and the one enterprise buyers request most often when they want contractual confidentiality obligations reflected in the report. Adding availability adds 3, and is worth doing when you carry uptime commitments customers actually enforce.

Adding processing integrity adds 5 criteria and is genuinely relevant to a narrow set of businesses: payments, payroll, clearing, calculation engines, anything where the output being wrong is the risk rather than the data leaking.

Adding privacy adds 18 criteria across eight series, covering notice, choice and consent, collection, use and retention, access, disclosure and notification, quality, and monitoring and enforcement. That is more than a quarter of the entire criteria set in one decision. It is also the category with the most overlap with obligations you may already carry under privacy law, which cuts both ways: some of the work is done, and some of it is now being audited.

Our default advice is the same one in our SOC 2 startup playbook: add a category when a signed contract or an active deal names it, and not before. What that scoping does to the price of the engagement is covered in the SOC 2 cost breakdown, and we are not going to restate a number here that page already owns.

Where the "security is always required" shorthand is loose

Everyone says security is mandatory in a SOC 2. In practice, treat that as true. But the underlying text is more careful than the shorthand, and this article exists to be precise.

TSP section 100 never declares the security category compulsory. It frames selection the other way round, saying the practitioner "may report on any of the trust services categories of security, availability, processing integrity, confidentiality, or privacy, either individually or in combination with one or more of the other trust services categories". What makes security look mandatory is structural: it is the one category with no additional category-specific criteria, because "the common criteria are suitable for evaluating the effectiveness of controls to achieve an entity's system objectives related to security; no additional control activity criteria are needed". Every other category stacks its criteria on top of the same 33.

So the accurate statement is that the common criteria are unavoidable and the compulsion around security is a market fact rather than a rule in the text. Scoping security out would not save you anything, because the 33 arrive with whatever category you did select. The document is also strict inside a category: its criteria "are considered complete only if all the criteria associated with that category are addressed by the engagement", so half a category is not a scoping option.

The same care applies to the report. A SOC 2 engagement is an attestation examination producing an opinion, with no certificate and no pass mark, which is why our piece on SOC 2 exceptions exists and why how to read a SOC 2 report walks the sections in order.

Where Top Floor fits

Our SOC 2 practice starts scoping at the criteria level rather than the category level: which of the 61 apply, what evidence each one will need every period, and which category requests from your sales pipeline are worth accepting. That conversation usually removes work rather than adding it, because the most common finding is a control set built against points of focus instead of criteria.

Where an organization is running SOC 2 alongside other frameworks, our audit and assurance team maps the common criteria once and reuses the evidence, which is the same logic covered in reusing compliance evidence across frameworks. And an independent readiness partner cannot also issue your opinion; that separation is not a preference, it is what makes the opinion worth anything.

How to decide this week

Open your last three enterprise contracts and your two largest open deals, and search them for the words availability, confidentiality, processing integrity and privacy. That search, not an internal maturity discussion, is what should set your category scope.

Then take whatever control matrix your team or your compliance platform has produced and count the rows. If it is materially above 61 for a security-only scope, find out whether the extra rows trace to criteria or to points of focus. If they trace to points of focus, you are carrying evidence obligations the AICPA never imposed.

Finally, write the category decision down with the contract clause that justifies it, and date it. In year two somebody will ask why privacy is in scope, and "a customer asked once" does not survive a renewal conversation.

Frequently asked questions

Are there five Trust Services Criteria or 61?

Five categories, 61 criteria. Security, availability, processing integrity, confidentiality and privacy are categories; the numbered items beneath them (CC1.1 through CC9.2, A1.1 through A1.3, C1.1 and C1.2, PI1.1 through PI1.5, and the P series) are the criteria an auditor evaluates controls against. The count of 61 comes from the criteria table in TSP section 100. The loose usage is harmless in conversation and expensive in a scoping document, because a scope written in categories does not tell anyone how much evidence is coming.

Is the security category mandatory for SOC 2?

Treat it as mandatory in practice. The 33 common criteria apply to every category, so they are in scope whatever you select, and TSP section 100 says of security that "the common criteria are suitable for evaluating the effectiveness of controls to achieve an entity's system objectives related to security; no additional control activity criteria are needed". The document itself describes category selection neutrally, as reporting on any category "either individually or in combination with one or more of the other trust services categories", so the compulsion is a market fact rather than a rule in the text: no enterprise buyer asking for a SOC 2 report means one without security. Omitting it would also not reduce the work, because the common criteria come with every other category anyway.

Do we have to address every point of focus?

No. TSP section 100 states that use of the criteria "does not require an assessment of whether each point of focus is addressed", and the same passage acknowledges that some points of focus "may not be suitable or relevant to the entity or to the engagement to be performed". Points of focus are illustrative characteristics that help management and the practitioner think about whether a control meets a criterion. Building one control per point of focus is the single most reliable way to end up maintaining a control set two or three times larger than the criteria require.

Did the 2022 revision change what we have to do?

Not at the criteria level. The document the AICPA distributes today is published as the 2017 Trust Services Criteria with points of focus revised in 2022, and the criteria still carry their 2017 identifiers: CC1.1 through CC9.2, A1.1 through A1.3, C1.1 and C1.2, PI1.1 through PI1.5, and the P series. Points of focus are not requirements in the first place, which is what makes a revision to them a smaller event than the noise around it suggested. If someone proposed a remediation project because of the 2022 revision, ask which criterion changed.