Security is the one SOC 2 category you cannot leave out, so it is where most of the work in any SOC 2 lives. It is also where expectations are furthest from the text. Teams expect a technical checklist: MFA, encryption, a penetration test. The first criteria they meet are about board oversight and ethical values.
This article goes through the security criteria series by series. For each, it covers what the AICPA's trust services criteria actually ask, what an auditor usually wants to see, and where teams come up short. It ends with what the criteria deliberately leave to you, which matters as much as what they require.
Security is nine series of criteria, not one requirement
"The security criterion" is a slight misnomer. Security is a category, and its criteria are the common criteria, numbered CC1 through CC9. They are called common because they apply whichever other categories you include. If you are still deciding scope, the trust services criteria explained one by one covers the other four categories.
Each criterion states an outcome. You design controls to meet it, and your auditor tests those controls. One control can address several criteria, and one criterion is often met by several controls.
| Series | What it covers | Evidence an auditor commonly asks for |
|---|---|---|
| CC1 | Control environment | Code of conduct acknowledgements, org chart, board or governance records |
| CC2 | Communication and information | Published policies, internal security communications, external commitments |
| CC3 | Risk assessment | A dated risk assessment, including fraud risk and changes |
| CC4 | Monitoring activities | Control reviews, test results, deficiencies tracked to resolution |
| CC5 | Control activities | Approved policies and procedures that put controls in place |
| CC6 | Logical and physical access | User provisioning and removal, access reviews, encryption settings |
| CC7 | System operations | Vulnerability management, alerting, incident records |
| CC8 | Change management | A sample of changes with testing and approval |
| CC9 | Risk mitigation | Business continuity plans, vendor risk assessments |
The governance criteria engineering teams skip
CC1 to CC5 follow the five components of internal control in the COSO 2013 framework, and the 17 principles within them. They read like corporate governance because they are. Engineering-led teams tend to treat them as paperwork. Auditors do not.
CC1: control environment
CC1 asks whether the organization demonstrates a commitment to integrity and ethical values, whether the board of directors exercises oversight independent of management, whether structures and reporting lines are defined, whether it attracts and develops competent people, and whether it holds them accountable.
The hard one for a small company is oversight. A startup with a two-person board still has to show that someone above day-to-day management looks at security. Records of that review, such as minutes or a dated report to the board, are what the auditor will ask for. What oversight looks like should fit your size. Whether it exists is not optional.
CC2: communication and information
CC2 covers using quality information to support internal control, communicating internally about responsibilities, and communicating with external parties. The external part is easy to forget. Customers need a way to learn your commitments and to report a security concern. Your security page, terms, and a working report address are evidence.
CC3: risk assessment
CC3 asks you to specify objectives clearly enough to identify risks, to identify and analyze those risks, to consider the potential for fraud, and to identify changes that could significantly affect your system of internal control.
Fraud risk is the criterion teams miss. A risk register full of outages and breaches, with no entry for misuse by an insider or manipulation of financial data, leaves CC3.3 unaddressed. So does a risk assessment that never asks what changed this year: a new product line, an acquisition, a move to a new cloud region.
CC4 and CC5: monitoring and control activities
CC4 asks whether you evaluate your controls and communicate deficiencies to the people responsible for fixing them. The evidence is the loop, not the tool. A control failure that was found, assigned, and closed is better evidence than a dashboard nobody acted on.
CC5 asks you to select control activities that mitigate your risks, to select general controls over technology, and to deploy them through policies and procedures. Policies are where CC5 lives. Each one should be approved, dated, and consistent with what your team actually does.
Access: CC6
CC6 is the longest series, with eight criteria, and the one most engineers recognize. In plain terms, it asks you to:
Implement logical access security over protected information assets (CC6.1).
Register and authorize users before issuing credentials, and remove access when it is no longer authorized (CC6.2).
Grant, change, and remove access based on roles, least privilege, and segregation of duties (CC6.3).
Restrict physical access to facilities and protected assets (CC6.4).
Remove protections from assets only once data on them can no longer be read or recovered (CC6.5).
Protect against threats from outside your system boundaries (CC6.6).
Restrict and protect information in transmission, movement, and removal (CC6.7).
Prevent or detect unauthorized or malicious software (CC6.8).
Auditors usually test CC6 by sampling. They pick new hires and check access was approved before it was granted. They pick leavers and check access was removed on time. They look at periodic access reviews and whether the changes those reviews called for were made.
If you run entirely on a cloud provider, CC6.4 is mostly the provider's work. The provider is typically a subservice organization, and its controls are often carved out of your report. You still need controls over your own offices and laptops, and you are expected to monitor the provider, typically by reviewing its own SOC report.
Operations and change: CC7 and CC8
CC7 has five criteria that run from detection to recovery. You detect configuration changes that introduce vulnerabilities and susceptibility to newly discovered ones (CC7.1). You monitor for anomalies (CC7.2). You evaluate security events to decide whether they are incidents (CC7.3). You respond through a defined incident response program (CC7.4). You recover (CC7.5).
The gap is usually between CC7.2 and CC7.3. Alerts exist, but there is no record of anyone deciding what an alert meant. A short triage note on each significant event is the evidence that evaluation happened. If you had no incidents during the period, ask your auditor what they will accept to show the response process works. A documented exercise is a common answer.
CC8 is a single criterion, CC8.1, but a dense one. It covers authorizing, designing, developing or acquiring, configuring, documenting, testing, approving, and implementing changes to infrastructure, data, software, and procedures. Auditors typically sample changes from your deployment history and trace each one to its approval and testing. Emergency changes are where samples fail. Your process should say how they are reviewed after the fact, and the sample will test whether that happened.
Risk mitigation: CC9
CC9 has two criteria. CC9.1 covers mitigating risks from business disruption, which is where business continuity planning and, in some cases, insurance sit. CC9.2 covers assessing and managing risks from vendors and business partners.
CC9.2 is not satisfied by a vendor list. The auditor will want to see how you decided which vendors matter, what you reviewed for the ones that do, and when you last looked again.
What the criteria leave to you
This is the part that surprises people. The common criteria do not name a specific technology, setting, or frequency.
No specific controls. MFA, a particular encryption standard, endpoint protection, and penetration testing are common ways to meet criteria. None of them is named as a requirement in the criteria themselves. Your auditor, and your customers, may still expect them.
No frequencies. The criteria do not say quarterly access reviews or annual risk assessments. Your policies do.
Your policy becomes the requirement. Once your policy says quarterly, the auditor tests quarterly. Writing an ambitious frequency you cannot meet turns a choice into an exception.
Some controls sit with your customers. Where your controls depend on customers doing their part, such as managing their own users, the report lists complementary user entity controls. Those are outside your scope, but you have to identify them.
The freedom cuts both ways. Nobody hands you a list, so you have to decide what "protected" means for your system and be able to explain the choice. How your controls are expected to look for SOC 2 more broadly is on the SOC 2 framework page. Where interpretation is uncertain, settle it with your auditor before the period starts, not during fieldwork.
How TrustLynce helps
TrustLynce collects evidence on a schedule from your cloud, identity, HR, and code systems, timestamped and attributed, through evidence collection. Continuous monitoring checks controls between audits and routes failures to their owners, which gives CC4 the record of deficiencies found and closed that auditors look for.