An unofficial plain-English guide to the SOC 2® Trust Services Criteria

A customer’s questionnaire cites CC6.1. An auditor’s request list is numbered A1.2 and P4.1. A compliance tool shows a progress bar by criterion. Somebody handed you the paperwork, and the numbers don’t explain themselves.

This guide explains what those numbers are about, in plain English and in our own words, for people who run a small company and have no security team. It is organized around the questions you would ask (who can get into what, how a change reaches production, what a vendor can see) and not around the standard’s own order. The numbers stay on as tags, so you can move between this guide, a customer’s mapping, and the real text.

What this guide is, and isn’t

A SOC 2 report comes out of an examination by an independent CPA firm, which looks at how a company’s controls work and writes up what it found. The yardstick is the Trust Services Criteria, which the AICPA, the American Institute of CPAs, publishes.

We are not the AICPA, and this guide is not the criteria. It doesn’t reproduce their wording and can’t stand in for it. Where the exact requirement matters, read the AICPA’s own publication. Our summaries say what a criterion is about, and our “in practice” examples are our views of what a small team might do. Neither is a requirement, and neither promises a result.

The five categories

The criteria come in five categories. Security is the base. The other four are optional.

• Security (CC). Whether your protections hold up against misuse and damage. Its criteria are numbered CC1 to CC9 (the “common criteria”), and the other four categories build on them.
• Availability (A). Whether your service is up and usable the way you have promised, and whether you can recover when it isn’t.
• Confidentiality (C). Whether information you have agreed to keep private stays private, and is destroyed when its time is up.
• Processing integrity (PI). Whether the system does its job correctly: the right results, nothing dropped or duplicated, nothing run without approval.
• Privacy (P). Whether personal information is handled the way you told people it would be.

Which categories a report includes is a scoping decision for you, your customers, and the CPA firm. It depends on what you have promised, and we make no claim about what yours should be. Our guide to whether you need SOC 2 yet covers the earlier question, and what to send customers while you don’t have a report.

How to read a criterion number

A criterion number such as CC6.1 has three parts. The letters name the group: CC for the common criteria, and A, C, PI, and P for the four optional categories. The number after the letters is the series within that group. The number after the dot is the criterion within the series.

So CC6.1 is the first criterion in series 6 of the common criteria, and P4.2 is the second in series 4 of privacy. A customer’s mapping, an auditor’s request list, and a policy’s inline references all use these numbers, which is why this guide keeps them as tags.

Practice the numbers

If you would rather learn the numbers than look them up, our free SOC 2 criteria study tool has a map of the criteria, three kinds of drill that bring back the ones you miss, and progress saved in your own browser. It uses the same labels and summaries as this guide.

The topics

Each topic page explains a group of neighboring criteria, with short labels and a few examples of what a small team might do or keep. Start wherever your customer’s question points.

1. Ownership and communication (CC1.1 to CC2.3). Who owns security here, and how does everyone else find out?
2. Risk, monitoring, and policies (CC3.1 to CC5.3). What could go wrong, what are you doing about it, and how do you know?
3. Access control (CC6.1 to CC6.3). Who can get into what, and how do you know?
4. Networks, devices, and places (CC6.4 to CC6.8). What stands between your data and the outside world, and what happens to the hardware?
5. Detection and incident response (CC7.1 to CC7.5). How would you notice trouble, and what happens in the first hour?
6. Change management (CC8.1). How does a change get from a laptop to production, and who saw it?
7. Vendors and business disruption (CC9.1 to CC9.2). What happens when something outside your control stops working?
8. Availability (A1.1 to A1.3). Can customers count on your service being up, and could you rebuild it?
9. Confidentiality (C1.1 to C1.2). What do you hold in confidence, and when do you let it go?
10. Processing integrity (PI1.1 to PI1.5). Does the system do what you say it does with the data you give it?
11. Privacy: notice and consent (P1.1 to P3.2). What do you tell people, and what do you ask before you take their data?
12. Privacy: use, retention, quality (P4.1, P4.2, P4.3, P7.1). Are you using, keeping, and deleting personal data the way you said you would?
13. Privacy: requests and complaints (P5.1, P5.2, P6.7, P8.1). What do you do when someone asks what you hold about them?
14. Privacy: sharing and breaches (P6.1 to P6.6). Who else gets personal data from you, and what happens if it leaks?

Where a small company starts

The criteria don’t rank themselves, and an examiner doesn’t take them in this order. This is ours, for a team of a few people with a customer waiting:

1. Name an owner for security, and write down who covers for them. It takes an afternoon and settles questions that come up everywhere else.
2. Get access under control: one identity provider, multi-factor sign-in, a leaver checklist.
3. Make changes leave a trail. Branch protection and reviewed pull requests are most of it.
4. Write the incident plan and practice it once.
5. List your vendors and read the reports of the critical ones.
6. Then look at the optional categories, and add one only if you have made a promise that needs it: uptime, secrecy, correct results, or the handling of personal data.

Policies come before most of this, because they are where you write down what you decided. Our guide to the first five security policies covers them.

Criterion numbers, with our labels

The labels below are ours, not the AICPA’s wording. The numbers link to the topic pages that explain them.

What this guide doesn’t do

• It doesn’t replace the criteria. The AICPA’s publication is the authority, and it carries supporting detail that we leave out on purpose.
• It doesn’t tell you what an examiner will conclude. Examiners judge your controls in your context. A tidy set of documents is a starting point, and the logs, tickets, and records of what you actually do are what get tested.
• It isn’t a checklist. Following it doesn’t mean you will pass an audit or satisfy any customer or auditor.
• It isn’t legal advice. The privacy pages in particular describe engineering habits, not what any privacy law requires.

If you would rather hand off the writing

Blank Slate Creative, LLC does readiness and documentation only. We never audit or attest: an independent CPA firm issues any SOC 2 report. This guide draws on our own judgment and the published structure of the criteria, not client work.

• The five core policies, tailored to your stack. Information Security, Access Control, Incident Response, Acceptable Use, and Data Classification, with the SOC 2 criteria they support cited inline, for a flat $85. Order the five policies, $85.
• A SOC 2 gap analysis or a criteria map, by quote. A written list of where your documents fall short, or a map of your policies to the criteria. Both are documentation, not an examination. Tell us what you need.
• A person reads your policies. Each custom policy set is read before it is sent to you. We can’t promise how a customer or an examiner will judge them.
• See it first. The home page has two full sample policies, written for a fictional company. We have no client work to show yet, and would rather say so.

Where to read the real thing

• AICPA & CIMA, 2017 Trust Services Criteria (With Revised Points of Focus – 2022). The publication page is public. The PDF download asks for a free AICPA account.
• Our guides Do you need SOC 2 yet? and The first five security policies a startup needs before SOC 2 cover what to send customers and what to write first.