SOC 2 Controls Explained: CC1-CC9 and the Trust Services Criteria

SOC 2 Controls Explained: CC1-CC9 and the Trust Services Criteria | Osto

A guide to the SOC 2 controls: the nine Common Criteria that define SOC 2 Security, the four optional criteria, and the categories where audit findings most often arise.

Osto Security Team 8 min read Compliance & Trust

TL;DR

SOC 2 controls are not a fixed checklist. SOC 2 sets criteria your controls must satisfy, and the mandatory Security criterion is defined by nine Common Criteria, CC1 through CC9.

CC1 to CC5 cover governance and internal control. CC6 to CC9 are the technical core: access, operations, change, and risk. CC6 and CC7 are where auditors find the most gaps.

How SOC 2 controls are structured

SOC 2 does not hand you a list of controls to implement. It gives you criteria, which are objectives your controls have to meet. The criteria sit under the five Trust Services Criteria published by the AICPA. Only Security is mandatory, and it breaks into nine Common Criteria.

Security (mandatory) = 9 Common Criteria
CC1-CC5 · Governance
CC1Control environment
CC2Communication & information
CC3Risk assessment
CC4Monitoring activities
CC5Control activities
CC6-CC9 · Technical
CC6Logical & physical access
CC7System operations
CC8Change management
CC9Risk mitigation
The split in one line
CC1 to CC5 map to the COSO internal-control framework and ask whether your organisation is run in a way that can be trusted with data. CC6 to CC9 are the hands-on security controls.

CC1-CC5: the governance foundation

These five SOC 2 controls are less about firewalls and more about whether your organisation is structured to be trusted with data.

CC1

Control environment

The tone at the top: structure, roles, accountability, and ethical culture to support security.

Asks: Do you have defined roles, committed leadership, background checks, and competent security people?
CC2

Communication & information

How security information flows, internally to your team and externally to customers and partners.

Asks: Are security policies, responsibilities, and expectations clearly communicated to those who need them?
CC3

Risk assessment

Whether you actively identify, analyse, and plan to treat risks to your systems and data, including fraud risk.

Asks: Do you run a real risk assessment, set objectives, and account for how changes affect risk?
CC4

Monitoring activities

Ongoing evaluation of whether your controls are present and working, and remediation when they are not.

Asks: Do you continuously check that controls function, and fix deficiencies you find?
CC5

Control activities

The bridge from policy to action: the activities, technology, and procedures that carry out security directives.

Asks: Are policies translated into concrete control activities, including technology general controls?

CC6-CC9: the technical core

This is where the SOC 2 controls get hands-on. These four are security-specific and cover most of what people picture as security controls.

CC6

Logical & physical access

The biggest category. Who and what can access your systems and data: authentication, authorisation, encryption, network and physical access.

Asks: Is access restricted to the right people, protected by MFA and encryption, and removed promptly when someone leaves?
CC7

System operations

Running systems securely day to day: detecting issues, monitoring, vulnerability management, and incident response.

Asks: Do you monitor for anomalies, manage vulnerabilities, and have a working incident response process?
CC8

Change management

How changes to systems and code are requested, reviewed, approved, and deployed without introducing security risk.

Asks: Are system and code changes documented, reviewed, and approved before they ship?
CC9

Risk mitigation

Reducing the impact of disruptions and third-party risk, through contingency planning and vendor management.

Asks: Do you plan for business disruption and assess the risk your vendors introduce?

Where auditors actually find the gaps

If you are prioritising, put your energy into CC6 and CC7. Across first-time SOC 2 engagements, these two generate the most exceptions by a wide margin.

CC6 · Access
The usual culprits
Missing MFA, access not removed when someone leaves, and weak or undocumented access reviews.
CC7 · Operations
The usual culprits
No real monitoring, unmanaged vulnerabilities, and an incident response process that exists only on paper.

The four optional Trust Services Criteria

Security (CC1-CC9) is mandatory. The other four are optional. Add them only when your customer commitments or contracts call for them, because each one widens scope.

A

Availability

Whether your system is up and reachable as promised. For uptime and SLA commitments.

C

Confidentiality

Protecting information meant to stay restricted, like customer business data.

P

Processing Integrity

Whether data is processed completely, accurately, and on time. For fintech and data platforms.

Pr

Privacy

How you collect, use, retain, and dispose of personal information against your commitments.

Criteria, controls, and points of focus

One more layer worth knowing. Under each criterion sit points of focus: the AICPA’s suggested considerations for what a control satisfying that criterion might address. They are guidance, not a checklist.

A widely followed practice
Support each criterion with at least two or three controls. That way, if one control fails during the audit period, the others still satisfy the criterion and you avoid an exception.

Satisfying the criteria in practice

Read back over the SOC 2 controls in CC1 to CC9 and a pattern emerges. Most of these criteria describe security functions that have to genuinely run and produce evidence: access control and MFA, monitoring, change management, vulnerability management, vendor risk. The criteria are the objective; running controls with a clean evidence trail is how you meet them.

That is where a single platform changes the math. With Osto, the controls these criteria call for are built in and running: access controls and MFA enforcement, continuous monitoring, VAPT, and change management, with the evidence collected from the same modules. The CC6 and CC7 categories that trip up most first-timers are handled by the platform itself.

Close the CC6 and CC7 gaps before the auditor looks.

Osto is a one-stop cybersecurity and compliance platform for growing companies. The controls behind CC1-CC9, access, MFA, monitoring, VAPT, change management, run on one platform, with the evidence collected in the same place, so you can get SOC 2 ready in about 115 days.

Book a Demo →

Frequently asked questions

What are the SOC 2 Common Criteria?

The nine categories that make up the mandatory Security Trust Services Criterion in every SOC 2 report: CC1 (Control Environment), CC2 (Communication and Information), CC3 (Risk Assessment), CC4 (Monitoring), CC5 (Control Activities), CC6 (Logical and Physical Access), CC7 (System Operations), CC8 (Change Management), and CC9 (Risk Mitigation).

How many controls are in SOC 2?

SOC 2 defines criteria rather than a fixed list of controls, so the exact number varies by company. The mandatory Security criterion contains 33 Common Criteria points across CC1-CC9, and you implement whatever set of controls satisfies them for your environment.

Which criteria cause the most audit findings?

CC6 (Logical and Physical Access Controls) and CC7 (System Operations) generate the most findings in first-time audits. Recurring causes for CC6 are missing MFA and access not removed when people leave; for CC7 they are weak monitoring and vulnerability management.

Is Security the only mandatory criterion?

Yes. Security, made up of the nine Common Criteria (CC1-CC9), is the only mandatory Trust Services Criterion, and most first-time audits cover it alone. The other four (Availability, Confidentiality, Processing Integrity, Privacy) are added only when a contract requires them.

What are points of focus?

The AICPA’s suggested considerations under each criterion, describing what a control satisfying that criterion might address. They are guidance to help you design controls, not a mandatory checklist.