SOC 2 security and the common criteria

SOC 2 security is the 33 common criteria, SOC 2 CC1.1 to CC9.2, which every SOC 2 report covers. CC1 to CC5 ask for the foundations of internal control: governance, communication, risk assessment, monitoring and control activities. CC6 to CC9 cover access, system operations, change management and the risk from disruption and suppliers.

The requirement in plain English

The criteria come from the AICPA’s 2017 Trust Services Criteria. Each is an outcome, not a prescribed control: you choose the controls, and the auditor judges whether they meet it. Points of focus under each criterion suggest what to consider; they are not a checklist.

CC1, the control environment (SOC 2 CC1.1 to CC1.5). Leaders show a commitment to integrity, someone independent of day-to-day management oversees internal control, the structure and reporting lines are clear, you hire and develop competent people, and people answer for their part.

CC2, communication and information (SOC 2 CC2.1 to CC2.3). You use reliable information to run controls, tell staff what their security responsibilities are and how to raise concerns, and tell customers and suppliers what they need to know, such as how to report an incident.

CC3, risk assessment (SOC 2 CC3.1 to CC3.4). You set objectives clear enough to find the risks to them, analyse those risks, consider fraud explicitly (SOC 2 CC3.3), and reassess when something significant changes.

CC4, monitoring (SOC 2 CC4.1 and CC4.2). You check that controls work, through ongoing monitoring and separate evaluations such as internal audits or penetration tests, and report the deficiencies to people who fix them.

CC5, control activities (SOC 2 CC5.1 to CC5.3). You choose controls that bring the risks down to an acceptable level, include general controls over technology, and put them into practice through approved policies and procedures.

CC6, logical and physical access (SOC 2 CC6.1 to CC6.8). The largest series: secure access infrastructure, approving and removing user accounts, least privilege by role, physical security, wiping data before disposal, protection at the network boundary, protecting data in transit and on removable media, and stopping malicious software.

CC7, system operations (SOC 2 CC7.1 to CC7.5). You detect vulnerabilities and configuration changes, monitor for anomalies, decide which security events are incidents, respond to them and recover.

CC8, change management (SOC 2 CC8.1). Changes to infrastructure, software and data are authorised, tested, approved and recorded.

CC9, risk mitigation (SOC 2 CC9.1 and CC9.2). You plan for business disruption, and you assess and monitor the suppliers and partners your service depends on.

This is guidance to help you understand the requirement, not legal advice.

What good looks like

Take a 30-person software company in Manchester, hosting on a major cloud provider and selling to US hospitals. The chief executive approves the Information Security Policy each year, and an investor director chairs a quarterly board meeting where security is a standing item, which covers CC1.2. Every new starter signs the code of conduct and completes security training in their first week.

The chief technology officer keeps the risk register, reviews it quarterly with the chief executive, and includes fraud scenarios such as a fake supplier invoice and an engineer exporting customer data. Every change to production goes through a pull request that someone other than its author approves, with automated tests, and emergency changes are reviewed the next working day.

Access runs through single sign-on with multi-factor authentication. Joiners and leavers are tickets linked to the HR system, and leavers lose access on their last day. The engineering lead reviews privileged access quarterly and all access twice a year, removing what is no longer needed. Logs go to one place with alerts on defined events, and an external firm runs a penetration test each year. The operations manager reviews each critical supplier’s own SOC 2 report annually.

Evidence an auditor expects

The criteria do not list required documents, so everything below is evidence the auditor samples rather than a mandated record. For Type II they test it across the whole period.

Approved policies: dated approval, an owner, and staff acknowledgement.
Board or oversight minutes: security discussed by people independent of management (CC1.2).
Joiner and leaver records: access granted after approval, and removed promptly, for a sample of each.
Access reviews: the population reviewed, the decisions, and the removals that followed.
Risk register: dated assessments, fraud considered, and treatment owners.
Change records: a sample of changes, each with approval by someone other than the author and evidence of testing.
Vulnerability scans and penetration test reports: findings tracked to closure.
Incident records: classification, response, and lessons learnt.
Supplier reviews: risk assessment and the supplier’s own assurance report, read.
Training records: completion by everyone in scope.

Common mistakes

Oversight that is really the founder checking themselves

CC1.2 asks for oversight independent of management. In a founder-run company the same person often runs and oversees security. Fix it with a board or advisory member who is not in management, a standing agenda item, and minutes that show challenge, not just a note that security was discussed.

Fraud missing from the risk register

Many registers list breaches and outages but no fraud, so SOC 2 CC3.3 has nothing behind it. Add scenarios where an insider or an impostor gains: payment diversion, misuse of customer data, falsified records.

Leavers who keep their keys

The auditor picks leavers from the HR list and checks each account. One account still active weeks later is an exception in a Type II report. Reconcile the HR leavers list against every system with customer data, not only single sign-on.

Reviews that only say “reviewed”

An access review with a tick and no detail does not show the control worked. Record the population, who decided, and what was removed or changed.

Changes approved by their author

A pull request merged by the person who wrote it, without another reviewer, fails CC8.1 in most samples. Enforce branch protection so the system, not memory, keeps the rule.

How Sted helps

For the SOC 2 common criteria Sted’s knowledge base maps the Information Security Policy (POL-ISP), Access Control Policy (POL-ACC), Change Management Policy (POL-CHG), Logging and Monitoring Policy (POL-LMP), Incident Management Procedure (PRC-IMP) and Supplier Approval and Management Procedure (PRC-SAMP), with record templates such as the Access Review Record (REC-ARR), Change Record (REC-CR), Information Security Incident Record (REC-ISI) and Supplier Review Record (REC-SRR).
Records are part of the Full Management System plan.
Management-system registers (scope, interested parties, obligations, issues, objectives, risks and opportunities, processes) are edited by administrators; the first three are drafted from your onboarding answers and the rest start empty.
Risk levels are computed from likelihood and impact.
You can set a record type to repeat (weekly to every two years) and Sted raises a task when it falls due.
Nothing is scheduled until an owner picks a first due date.
Training is completed against a specific approved version; a new version asks people to train again.
Re-issuing training on an unchanged version is not available yet.
Sted does not connect to your cloud, code or HR systems to collect evidence automatically; you record it.

Sted does not monitor your systems or test your controls. It holds the policies, registers and records; your CPA firm tests whether the controls worked.

The SOC 2 hub: how the common criteria fit with the other four categories.
Access reviews: how to run the review auditors sample most under CC6.2 and CC6.3.
Risk assessment: building the register CC3 asks for, fraud included.
Supplier due diligence: the vendor assessment behind CC9.2.
Control: what the auditor means by a control, as opposed to a criterion.
SOC 2 evidence: how auditors sample what these criteria produce.
Availability, confidentiality, processing integrity and privacy: the four optional categories that add criteria on top of these.

Frequently asked questions

Are the common criteria the same as the Security category?

Yes. The Security category is the 33 common criteria, and the same 33 apply when you add Availability, Confidentiality, Processing Integrity or Privacy. Those categories add their own criteria on top rather than replacing any.

Does a small company need an independent board for CC1.2?

No particular structure is required, but you need oversight that sits apart from day-to-day management and leaves a record. Small companies often use a board with an investor or non-executive director, or an advisory board, and minute its review of security. The auditor reads the minutes.

Do we need a penetration test for SOC 2?

The criteria do not name one, but most auditors expect one for a software service. CC4.1 asks you to evaluate whether your controls work and CC7.1 asks you to find vulnerabilities; an annual penetration test and regular scanning are the usual way to show both.