What a trust services criterion is, and what it is not

"Criterion" and "control" get used interchangeably — in buyer emails, in readiness tooling, and often inside the company being audited. The same list ends up carrying both labels, and the question of whether a particular criterion is met stops being clear about which of the two things it is asking.

They are not the same word. The difference decides who writes what, what your auditor is forming an opinion about, and which evidence has to exist before the question can be answered at all.

Where the criteria actually come from

The first thing to know about a trust services criterion is that it reaches you from outside your company. In our view that is where the confusion starts: the benchmark and the controls offered against it come from two different places, and only one of them is yours to describe.

NIST's privacy engineering resources include a page titled "American Institute of Certified Public Accountants (AICPA) 2017 Trust Services Criteria Crosswalk", and that page names the criteria document as the "2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus – 2022)".

Two things in that title are worth slowing down for.

The first is the list of subjects it names: security, availability, processing integrity, confidentiality and privacy. Those words are the vocabulary a buyer is using when they tell you which parts of a SOC 2 they expect to see covered, and they are the vocabulary your scope will be written in.

The second is the phrase "With Revised Points of Focus", which sits in the published document's name alongside the criteria themselves. What points of focus are, and how a particular firm treats them when forming an opinion, is a question worth putting to your auditor directly, early, and in writing — the answer affects what they will ask you to produce.

A criterion is the question; a control is your answer

In our view this is the one distinction worth being fussy about.

A criterion states something that has to hold true about a system. It does not name your tooling, your vendor, your ticket queue or your review cadence, because it was written to apply to organisations that share none of those things. A control is the specific thing you do, in your environment, that you are putting forward as satisfying the criterion.

Federal security vocabulary has a clean definition for the control side of that pair. NIST's glossary gives "security control" as "A safeguard or countermeasure prescribed for an information system or an organization designed to protect the confidentiality, integrity, and availability of its information and to meet a set of defined security requirements." That definition comes from NIST's own publications rather than from the trust services world, so it is not a definition of anything in a SOC 2. But the shape of it is the shape we mean: a measure you put in place, which exists in order to meet requirements that were defined somewhere other than inside the measure.

A criterion is that "somewhere else". Which is why three sentences you hear often are all category errors:

• "We built a control, so the criterion is met." In our view two separate questions are hiding in that sentence: whether the control genuinely addresses the criterion, and whether it operated. The second one is evidence work, and it is the one that takes time.
• "That criterion does not apply to us." Applicability is a scoping conversation with your auditor about categories and about your system boundary, not a judgement you record in a spreadsheet.
• "We need one control per criterion." In our view this is the most expensive misunderstanding of the three, because it produces control inventories nobody can maintain. One well-described control can be offered against several criteria, and one criterion can need several controls before it is honestly answered.

The category names tell you less than you think

Availability is where this bites most often. In our view it is the category most often mistaken for an uptime commitment: the word reads as a promise about service levels rather than as a property of a system.

The words themselves have settled meanings in security practice. NIST's glossary gives "availability" as "Ensuring timely and reliable access to and use of information," and "confidentiality" as "Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information." Those are federal security definitions rather than trust services criteria, and that is exactly why they are useful here: they show you the register the words sit in without telling you what any criterion inside a category requires.

Only the criteria themselves do that. So the practical move, in our view, is to ask your auditor to walk you through the criteria in a category before you agree to include it. A category added on instinct is more to describe and more evidence to retain across the whole observation period — and the period is the part that cannot be rebuilt afterwards, as the Type 2 observation window covers in more detail.

Mapping from a framework you already run

If you already operate a recognised framework, some of the mapping work has been done in public.

NIST's crosswalk page sets out a mapping between its Privacy Framework and the trust services criteria, and a contributor note on that page gives the contributor's stated purpose for it: "The purpose of mapping the NIST Privacy Framework to the 2017 Trust Services Criteria (inclusive of October 2022 updates) is to support SOC compliance efforts for organizations aligned with the NIST Privacy Framework."

That is a real head start, and it is worth being clear-eyed about what it is. In our view a crosswalk is an inventory of where to look, not a conclusion about whether anything is satisfied. It can tell you which parts of a programme you already run are likely to be relevant to a given area. It cannot tell you that a control was designed appropriately, that it operated, or that you kept the records showing it did.

The same note points to a second use for the mapping: "This mapping may be leveraged by privacy and GRC teams to perform a SOC readiness assessment and by service auditors to evaluate whether the NIST Privacy Framework may be considered suitable criteria in an attestation examination." In our view that sentence is worth noticing for what it says about the measuring stick itself: which document supplies the criteria in a given examination is something a practitioner evaluates, not a constant you can assume from the outside. Which is one more reason to ask early, and in writing, which criteria your engagement will be measured against.

Who is actually reading against the criteria

The criteria are the auditor's measuring stick. The report, once issued, goes to somebody with a different job.

For banking organizations, the 2023 interagency guidance on third-party relationships from the Federal Reserve, the FDIC and the OCC says that "when relevant and available, a banking organization may consider reviewing System and Organization Control (SOC) reports and any conformity assessment or certification by independent third parties related to relevant domestic or international standards." The same guidance frames the underlying interest in terms of the reviewer's own decision, saying that "understanding potential information security implications, including access to a banking organization's systems and information, can help a banking organization decide whether or not to engage with a third party." Both passages are written permissively, and whether any of it reaches a particular buyer is a question for that buyer and their counsel.

Our own observation about reviewer behaviour, rather than anything those sentences say: reviewers rarely ask about criteria by identifier. They ask whether the report covers the subject that worries them and whether its dates are recent enough. That is a conversation about categories and periods, which is why both are worth settling before anyone scopes an engagement. What a request like that is really reaching for is covered in a security questionnaire is not a SOC 2 report.

Where to start

1. Get the category list in writing from the buyer who asked. Security, availability, processing integrity, confidentiality, privacy — which ones does their policy actually expect? This is usually a short written request, and the answer sets the size of everything downstream.
2. Work from criteria to controls, not the other way round. Starting from your existing control list produces a tidy document with holes in it. Starting from the criteria in scope shows you the holes while there is still time to close them.
3. For each control you intend to offer, name the evidence first. Not the policy that describes it — the artefact a reviewer could be handed. The access review an auditor will accept is a worked example of the difference between a control that exists and a control you can prove ran.

If you are working against a customer's date, the SOC 2 timeline calculator lays the sequence out against it, and the readiness scorecard will give you an ordered view of which gaps would surface first.

This is general information, not audit, security or legal advice. Confirm what applies to you with your auditor or counsel.

Common questions

What is a trust services criterion?

In our view the most useful way to hold it is as one benchmark out of a published set, stating something that has to be true about a system rather than naming the mechanism that makes it true. The criteria come from a document published outside your company; your controls are what you put forward as meeting them.

Is a criterion the same thing as a control?

In our view no, and conflating them causes real confusion in scoping. A criterion is the benchmark being measured against, and it comes from a published document rather than from your own writing. A control is the measure you actually operate, described in your words, and one control can be offered against more than one criterion.

Who publishes the trust services criteria?

NIST's privacy engineering resources include a crosswalk page titled 'American Institute of Certified Public Accountants (AICPA) 2017 Trust Services Criteria Crosswalk', and that page names the criteria document as the '2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus – 2022)'.

Which trust services categories should be in scope?

That is a scoping decision rather than a given, and in our view it should start with the buyer telling you in writing which categories their policy expects. In our view every category in scope is more to describe and more evidence to keep for the whole period, so adding one speculatively is expensive.

Can a crosswalk from another framework prove we meet the criteria?

It can tell you where to look, which is genuinely useful if you already run something like the NIST Privacy Framework. It is not a conclusion about whether any criterion is met, because that question is answered by controls that actually operated and by evidence a reviewer can inspect.

Do buyers ask about criteria by name?

In our view, usually not. Reviewers ask whether the report covers the subject they are worried about and whether the coverage is recent enough, which is why getting the category list settled early matters more than memorising criterion identifiers.

Sources

1. American Institute of Certified Public Accountants (AICPA) 2017 Trust Services Criteria Crosswalk · National Institute of Standards and Technology, Privacy Engineering Program
2. Computer Security Resource Center Glossary — 'security control' · National Institute of Standards and Technology
3. Computer Security Resource Center Glossary — 'availability' · National Institute of Standards and Technology
4. Computer Security Resource Center Glossary — 'confidentiality' · National Institute of Standards and Technology
5. Interagency Guidance on Third-Party Relationships: Risk Management, 88 FR 37920 · Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation and Office of the Comptroller of the Currency, via the U.S. Government Publishing Office