SOC 2 Trust Services Criteria: the five categories, the common criteria and the controls that meet them

Your US prospect's security questionnaire asks which SOC 2 Trust Services Criteria your report covers, and nobody in the business has decided yet. Choose too few and the report misses what your contract promises. Choose too many and you pay for testing no customer asked for.

This guide is for founders, COOs and security leads at UK B2B tech firms with 25 to 100 staff, many already holding ISO 27001. It indexes every category and criterion series in one place. It shows how the common criteria are built, splits criteria from controls, and gives you a rule for what goes in scope.

What are the SOC 2 Trust Services Criteria?

The SOC 2 Trust Services Criteria are the AICPA criteria a SOC 2 examination is tested against. They fall into five categories: Security, Availability, Processing Integrity, Confidentiality and Privacy. Security, made up of the common criteria, is always in scope. The other four are added only when your promises to customers call for them.

For what SOC 2 is and why buyers ask for it, start with our SOC 2 overview. This page goes one level down, into the criteria themselves.

The criteria are published as the AICPA's 2017 Trust Services Criteria, with points of focus revised in 2022. The AICPA's Assurance Services Executive Committee set them for attestation and consulting engagements. In the AICPA's mapping of the criteria to ISO 27001, it describes them as "outcome-based": each criterion names a result your system must reach and leaves the method to you.

Each category's full set of criteria includes the common criteria. Security is made of them alone. So the auditor tests the common criteria in every SOC 2 examination, whatever else is in scope.

How are the SOC 2 common criteria organised?

The SOC 2 common criteria run in nine series, CC1 to CC9, with 33 criteria in total. CC1 to CC5 follow the 17 principles of COSO's 2013 Internal Control – Integrated Framework, one criterion per principle. CC6 to CC9 are supplemental series covering access, system operations, change management and risk mitigation, which is where the security-specific work sits.

COSO's Internal Control – Integrated Framework was first issued in 1992 and refreshed in 2013. The Journal of Accountancy's report on the 2013 update sets out its 17 principles across five parts: control environment, risk assessment, control activities, information and communication, and monitoring.

The AICPA lined up the Trust Services Criteria with those 17 principles. It then added extra criteria for the controls a service firm runs day to day. Those extra criteria are what make SOC 2 about information security.

More than half of the common criteria are about how the company is run, not how its servers are configured.

The table indexes every series in the 2017 criteria. The counts are ours, taken from the AICPA's criteria document; the descriptions summarise each area in our own words.

The full set comes to 61 criteria. A Security-only examination uses 33 of them.

Are the SOC 2 points of focus requirements?

No. Points of focus are the AICPA's notes under each criterion on what a well-designed control might cover. They help management shape controls and help auditors judge them. Some will not fit your firm, and the AICPA says outright that you are not expected to show each one is met. The criterion is the requirement; points of focus are guidance.

The idea comes from COSO. In its framework, points of focus help a firm judge whether a principle is in place and working. The Journal of Accountancy's report on aligning controls with the COSO principles notes that not every point of focus needs to be present at every organisation.

The AICPA revised the SOC 2 points of focus in 2022. The criteria themselves are still the 2017 set.

Use the points of focus two ways:

• When you design a control, as a prompt list for what the criterion is getting at.
• When you prepare for fieldwork, as a preview of the questions an auditor may ask.

Do not build a control for every point of focus. A control with no risk behind it adds evidence to collect and a test that can fail, without making the service any safer.

What is the difference between SOC 2 controls and the Trust Services Criteria?

The Trust Services Criteria say what must be achieved; controls are what your firm does to achieve it. The auditor tests your controls against the criteria. There is no official SOC 2 controls list. Management designs controls for its own system and risks, so two firms can meet the same criterion in quite different ways.

The AICPA's description of the criteria starts from management understanding the risks that could stop the system meeting its objectives. Controls follow from those risks. The question of a minimum set of common controls comes up often. AICPA staff addressed it in their 2020 FAQs on SOC 2 and SOC 3 engagements.

A controls list copied from another firm's report describes their system, not yours.

The table gives examples of controls that typically meet each common criteria series at a 25 to 100 person software firm. These are our practical examples, not AICPA text, and your own set should come from your risk assessment.

Write each control as an outcome a tester can sample, with an owner and a frequency, rather than a tool name. Recording which criteria each control meets, in a controls matrix, is covered in our SOC 2 documentation guide.

Which Trust Services Criteria categories should you add beyond Security?

Add a category when you have made a promise in that area that a customer can hold you to. Examples are an uptime service level for Availability, accuracy duties for Processing Integrity, confidentiality clauses for Confidentiality, or a privacy notice customers rely on for Privacy. If no contract, service level or questionnaire answer creates the promise, leave the category out.

A five-step rule keeps the decision honest:

1. List your commitments. Pull them from your contracts, data processing terms, service levels, questionnaire answers and trust centre.
2. Sort each one into a category. An uptime figure is Availability; a promise to delete customer files at contract end is Confidentiality.
3. Ask the customer what they need. A prospect asking for "SOC 2" often needs Security alone; ask before you assume.
4. Price the addition. Each category brings more criteria, more controls to evidence, more samples and more places for an exception to appear.
5. Revisit it every year. New contracts create new commitments, and the scope should follow them.

Every category in scope is a promise, in writing, to every reader of the report.

We recommend starting with Security plus only the categories a signed commitment requires, then adding others when a customer's contract asks for them. The categories you choose are named in the scope of your system, which our SOC 2 system description guide covers.

What is the difference between Confidentiality and Privacy in SOC 2?

Confidentiality protects whatever information you have committed to keep restricted: customer files, source code, pricing. Privacy is narrower in what it covers and wider in what it asks. It deals only with personal data, and with how you handle that data from collection to deletion. The AICPA separates the two categories on the same basis.

The two overlap where customer data includes personal data, which is most of the time for a SaaS firm. The deciding question is whose objectives the controls serve.

Many B2B software firms handle personal data on their customers' instructions. They do not decide why it is used. If that is you, we recommend checking whether Confidentiality and the common criteria answer the customer's question before you add the 18 Privacy criteria.

Does the SOC 2 Privacy category prove UK GDPR compliance?

No. The Privacy category tests your controls against AICPA criteria over a period; it does not report on compliance with the UK GDPR. The AICPA says the criteria are generally not used when an auditor reports on compliance with laws and regulations. Accountability for UK GDPR compliance stays with the controller.

Article 5(2) of the UK GDPR makes the controller responsible for, and able to demonstrate, compliance with the data protection principles. A SOC 2 report can be part of that evidence, but the duty does not move to your auditor.

The AICPA publishes a mapping of the Trust Services Criteria to the GDPR. A mapping shows where the two overlap, not that one satisfies the other.

Where do ISO 27001 Annex A controls already meet the SOC 2 common criteria?

If you hold ISO 27001, your Annex A controls already answer much of CC6 to CC9. Your management system clauses cover a good part of CC3 and CC4. Check CC1 and CC2 most carefully: oversight by your governing body, and how you communicate commitments to customers. ISO 27001 frames both differently from SOC 2.

The AICPA publishes its own mapping between the Trust Services Criteria and ISO 27001, which shows how much ground the two share. At concept level, the overlap looks like this:

• CC1 and CC2. ISO 27001's leadership, competence and communication clauses help. SOC 2 asks for more explicit evidence of oversight and of commitments made to customers.
• CC3. Your ISO 27001 risk assessment and treatment process, set out under Clause 6.1, is the backbone. Make sure fraud risk is considered explicitly.
• CC4 and CC5. Internal audit, management review and the Statement of Applicability carry over well, as long as the evidence covers the whole report period.
• CC6 to CC9. The Annex A controls for access, operations, change, suppliers and continuity meet most of this ground directly.

What does not carry over is the form of the evidence. A SOC 2 auditor tests your controls against the criteria, sample by sample, over a defined period.

What are the common mistakes with the SOC 2 Trust Services Criteria?

The common mistakes with the SOC 2 Trust Services Criteria are easy to name. Teams add categories to look thorough, treat points of focus as a checklist, adopt a generic controls list, and assume ISO 27001 or the Privacy category settles questions it does not. Each adds testing you did not need or leaves a gap a reviewer will find.

• Scoping by reputation. Adding all five categories reads as thorough but commits you to 61 criteria, most of which no customer asked about.
• Treating points of focus as requirements. This multiplies controls and evidence for no gain in assurance.
• Adopting a downloaded controls list. Controls written for someone else's system produce exceptions in yours.
• Naming tools instead of outcomes. A control that says which product you use breaks the day you change product.
• Over-reading other assurance. ISO 27001 certification does not cover CC1 and CC2 in SOC 2's terms, and the Privacy category is not a UK GDPR compliance opinion.

Frequently asked questions