Early in a first SOC 2 project, someone asks which criteria the audit will cover. Sales has heard "all five." Engineering has heard "only security." Neither answer is quite right, and the real one decides your scope, your evidence, and how much work the audit period takes.
The criteria themselves are published by the AICPA, in a document called the 2017 Trust Services Criteria, which the AICPA updated in 2022 with revised points of focus. They are shorter and more general than most people expect. This article goes through what each category covers, the criteria it contains, and how to decide which categories belong in your report.
How the criteria are organized
The AICPA's document has three layers, and the words for them get used loosely. It helps to keep them straight, because your auditor will.
Categories. There are five: security, availability, processing integrity, confidentiality, and privacy. Older material calls these "principles." The 2017 version uses that word for something else, so "categories" is the current term.
Criteria. The numbered statements your controls are evaluated against. Each has a prefix: CC for the common criteria (security), A for availability, PI for processing integrity, C for confidentiality, and P for privacy. So CC6.1 is a security criterion and C1.2 is a confidentiality one.
Points of focus. Characteristics that illustrate what a criterion is getting at. They are not requirements. The AICPA says not every point of focus will be relevant to every organization, and a criterion can be met without addressing each one.
The most important thing to understand is what the criteria are not. They are not a list of controls. A criterion describes an outcome, such as restricting logical access to authorized users. You design the controls that achieve it, and your auditor tests whether those controls meet the criterion. Two companies can satisfy the same criterion in quite different ways.
Security, the category every report includes
Security is required in every SOC 2 examination. The AICPA describes it as protecting information and systems against unauthorized access, unauthorized disclosure, and damage that could compromise the availability, integrity, confidentiality, or privacy of information or systems.
Its criteria are called the common criteria because they are common to all five categories. If you add confidentiality, the access controls that protect confidential data are still evaluated under the CC6 criteria. They are not repeated under C1. This is why every other category is relatively short: most of the heavy lifting is already in security.
The common criteria run from CC1 to CC9. The first five series follow the five components of internal control in the COSO 2013 framework: control environment, communication and information, risk assessment, monitoring activities, and control activities. The last four add criteria specific to technology: logical and physical access, system operations, change management, and risk mitigation.
A security-only SOC 2 is a complete report, not a reduced version of one. For many service organizations it is the right scope, because security is what their customers' questionnaires are about.
Availability
Availability covers whether your system is available for operation and use to meet your objectives, which in practice means your commitments to customers. It has three criteria:
A1.1 asks you to maintain, monitor, and evaluate current processing capacity and usage, so you can manage demand and add capacity when needed.
A1.2 covers environmental protections, software, data backup processes, and recovery infrastructure.
A1.3 asks you to test the recovery plan procedures that support system recovery.
What people get wrong: availability does not set an uptime target. The criteria contain no number. Your commitments do. If your contracts or service level agreement promise a level of uptime, the auditor looks at whether your controls support meeting it.
The evidence that tends to be missing is the restore test. Backup job logs are easy to produce. A dated record showing a backup was actually restored, and what was checked afterward, is the artifact that shows A1.3 operated.
Processing integrity
Processing integrity covers whether system processing is complete, valid, accurate, timely, and authorized. It has five criteria, PI1.1 to PI1.5, which follow data through the system:
PI1.1 covers defining and communicating what the processing is meant to do, including definitions of the data processed and specifications of the product or service.
PI1.2 covers inputs, including their completeness and accuracy.
PI1.3 covers processing itself.
PI1.4 covers outputs and how they are delivered.
PI1.5 covers storing inputs, items in processing, and outputs.
This category fits services where customers rely on the correctness of what the system produces: payroll, billing, payments, claims, or data transformation. It is a poor fit where processing accuracy is not something you have promised.
A frequent misunderstanding is that processing integrity is about data tampering. Protection against unauthorized change is a security concern, and it sits in the common criteria. Processing integrity asks a different question: does the system do what you said it would, correctly and on time?
Confidentiality
Confidentiality covers information designated as confidential, and whether it is protected to meet your objectives. It has two criteria:
C1.1 asks you to identify and maintain confidential information.
C1.2 asks you to dispose of confidential information.
"Confidential" means whatever your commitments say it means. For most service organizations, that is customer data held under contract. It can also include intellectual property, financial information, or business plans.
The evidence starts with a data classification scheme and a retention schedule. The criterion teams underestimate is C1.2. Deleting a departing customer's data, on the timeline your contract states, and keeping a record that you did, is harder than it sounds once backups and analytics copies are involved.
Privacy
Privacy covers personal information: how it is collected, used, retained, disclosed, and disposed of. Its criteria are grouped into eight series:
P1 Notice and communication of objectives related to privacy
P2 Choice and consent
P3 Collection
P4 Use, retention, and disposal
P5 Access, meaning individuals' access to their own information
P6 Disclosure and notification
P7 Quality
P8 Monitoring and enforcement
Confidentiality and privacy are easy to confuse. Confidentiality applies to any information designated confidential, personal or not. Privacy applies only to personal information, and it follows that information through its whole life, including what individuals are told and what they can choose.
Two cautions. First, including privacy in a SOC 2 does not make you compliant with GDPR, HIPAA, or any other privacy law. It is a separate attestation against separate criteria. Second, if you process personal information on behalf of customers rather than collecting it from individuals yourself, some privacy criteria may be carried out by your customers. How that is handled in scope is a question for your auditor before the period starts.
How to choose your categories
The five categories side by side:
| Category | Prefix | The question it answers | Include it when |
|---|---|---|---|
| Security | CC1 to CC9 | Is the system protected against unauthorized access and damage? | Always. It is required. |
| Availability | A1 | Is the system available as committed? | You make uptime or recovery commitments customers depend on |
| Processing integrity | PI1 | Does processing produce complete, accurate, timely results? | Customers rely on the correctness of your output |
| Confidentiality | C1 | Is confidential information protected and disposed of? | Contracts commit you to protecting specific information |
| Privacy | P1 to P8 | Is personal information handled as committed, from collection to disposal? | You collect personal information and make privacy commitments |
Then work through the decision in order:
List your service commitments. Read your customer contracts, data processing agreements, service level agreements, and public security pages. Your system description has to describe your principal service commitments and system requirements anyway, so this work is not wasted.
Ask your customers what they need. Check the questionnaires and contract clauses that prompted the audit. If no customer has asked about processing integrity, that is information.
Map each commitment to a category. A commitment to delete data at contract end points to confidentiality. A committed recovery time points to availability.
Count the cost. Each category adds criteria, controls, and evidence. In a Type II report, that evidence has to cover the whole period.
Agree the scope with your auditor before the period begins. Adding a category partway through a Type II period means its controls have not operated across the full window.
The common mistake is assuming more categories make a stronger report. A category with no commitment behind it adds work for no reader, and gives the auditor more places to find exceptions in controls nobody relies on. Scope to what you have promised, then expand when a customer gives you a reason.
If you want to see where you stand before committing to a scope, the SOC 2 readiness checklist walks through the areas the common criteria cover. The SOC 2 framework page and the glossary entry for the trust services criteria cover the surrounding terms.
How TrustLynce helps
TrustLynce maps your controls to the trust services criteria you choose, and reuses the same controls and evidence where they also satisfy other frameworks, through compliance automation. The readiness dashboard shows your gaps per category, so adding one to scope is a visible decision rather than a surprise during fieldwork.