CC1 to CC5 are the SOC 2 criteria that test whether a service organisation is governed, rather than whether its systems are configured, and they produce a surprising share of first-year exceptions because the evidence is easy to forget. These 17 criteria cover the control environment (CC1), information and communication (CC2), risk assessment (CC3), monitoring activities (CC4) and control activities (CC5). They follow the 17 principles of the COSO 2013 Internal Control Integrated Framework, which the AICPA Trust Services Criteria adopt as the base of the common criteria. This guide goes criterion by criterion from the auditor's side: the control statements organisations typically write, the evidence a service auditor asks for in a Type 2 period, and where exceptions come from. It is for compliance leads, CISOs and founders preparing a first or second SOC 2. For the cyber interpretation of each COSO principle, read the COSO for Cybersecurity Guide; this page does not repeat it.
Source note: this page summarises the official text and the sources listed at the end. Confirm against the official text before relying on it.
Key takeaways
- CC1 to CC5 are the COSO principles in SOC 2 form: CC1.1 to CC5.3 map one to one to COSO principles 1 to 17, and CC6 to CC9 add the security-specific criteria on top.
- Entity-level controls are often annual: risk assessment, policy review, board or management meetings and performance reviews may happen once or a few times in the period, so a single missed occurrence is an exception with no second chance.
- Population evidence matters as much as policy: auditors sample from complete lists of hires, leavers, attendees and acknowledgements; an incomplete HR export undermines CC1.4 and CC2.2 testing.
- The 2022 points of focus raised the bar on risk and information: they break risk assessment into threats, vulnerabilities, likelihood, magnitude and residual risk, and add information about data flows, asset inventory, classification and the completeness and accuracy of information.
- Points of focus are not a checklist: as EY summarises the 2022 revision, points of focus depend on facts and circumstances and need not all be met; you design controls to meet the criterion, and the auditor tests the controls you describe.
The 17 criteria at a glance
The criterion wording below is summarised. The authoritative text is the AICPA "2017 Trust Services Criteria (With Revised Points of Focus, 2022)", available from the AICPA and CIMA site.
| Criterion | COSO component | In short | Typical control owner |
|---|---|---|---|
| CC1.1 | Control environment | Commitment to integrity and ethical values | HR, legal |
| CC1.2 | Control environment | Board independence and oversight of internal control | Board, CEO |
| CC1.3 | Control environment | Structures, reporting lines, authorities and responsibilities | Executive team |
| CC1.4 | Control environment | Attract, develop and retain competent people | HR, managers |
| CC1.5 | Control environment | Individuals held accountable for internal control | HR, managers |
| CC2.1 | Information and communication | Relevant, quality information supports internal control | Security, IT |
| CC2.2 | Information and communication | Internal communication of objectives and responsibilities | Security, HR |
| CC2.3 | Information and communication | Communication with external parties | Security, legal, support |
| CC3.1 | Risk assessment | Objectives specified clearly enough to identify risks | Executive team, CISO |
| CC3.2 | Risk assessment | Risks identified and analysed across the entity | CISO, risk owner |
| CC3.3 | Risk assessment | Potential for fraud considered | CISO, finance |
| CC3.4 | Risk assessment | Significant changes identified and assessed | CISO, engineering leadership |
| CC4.1 | Monitoring activities | Ongoing and separate evaluations of controls | Compliance, internal audit |
| CC4.2 | Monitoring activities | Deficiencies evaluated and communicated in time | Compliance, management |
| CC5.1 | Control activities | Control activities selected to mitigate risks | CISO |
| CC5.2 | Control activities | General control activities over technology | IT, engineering |
| CC5.3 | Control activities | Controls deployed through policies and procedures | Policy owners |
How auditors test entity-level criteria
For each control in your system description, the service auditor combines inquiry with at least one stronger procedure: inspection of documents (minutes, signed acknowledgements, risk registers), observation, or re-performance. For a Type 2 report the auditor tests whether the control operated throughout the period, so frequency drives sample size: an annual control is usually tested once, a quarterly control a few times, and event-driven controls (a new hire, a leaver) are sampled from a full population list. Two practical consequences follow.
- Completeness first: the auditor will ask how the population was produced (for example, an HR system report of all hires in the period) and may test it. A spreadsheet maintained by hand invites questions.
- Timing inside the period: an annual risk assessment dated one week after the period ends does not count for that period. Put annual entity-level controls on a calendar that sits well inside the review window.
If you are on the reading side rather than the audited side, the How to Read a SOC 2 Report Guide explains how these tests and exceptions appear in Section 4 of a report.
CC1: control environment
| Criterion | Typical control statements | Evidence requested | Frequent exception |
|---|---|---|---|
| CC1.1 | Code of conduct acknowledged at hire and annually; background checks for new hires where lawful; disciplinary process for violations | Signed acknowledgements for sampled hires and staff; background check results; policy | Contractors missed from acknowledgement and screening |
| CC1.2 | Board or equivalent oversight body meets at least annually and reviews security and risk; independent members or advisers where possible | Charter, minutes, security agenda items | Start-ups with no formal board record of security discussion |
| CC1.3 | Organisation chart maintained; security responsibilities assigned to a named role; job descriptions include security duties | Organisation chart, role descriptions, RACI | Chart out of date by the period end |
| CC1.4 | Job descriptions and hiring criteria; security training at hire and annually; performance reviews | Training completion for sampled staff; review records | Annual training overdue for a few staff |
| CC1.5 | Performance reviews include control responsibilities; sanctions process enforced | Review templates, completed reviews, sanction records | Reviews skipped in a reorganisation |
Background checks are a recurring trap: screening rules vary by country and must follow local law, so describe the control as "where permitted" and keep a record of what was performed per hire. The Insider Threat from Fake IT Workers Guide shows why identity verification at hire is now a security control, not only an HR formality. For training, see the CIS Control 14 Security Awareness and Skills Training Guide.
CC2: information and communication
- CC2.1 quality information: the 2022 points of focus, as summarised by EY, add information about data flows, asset inventory and location, information classification, and the completeness and accuracy of information used in the system. Practical controls: a maintained system inventory and data flow diagram reviewed at least annually, a data classification policy, and checks that reports used in other controls (user lists, change lists) are complete.
- CC2.2 internal communication: policies published and acknowledged, security responsibilities communicated at onboarding, an internal channel to report incidents and concerns (including anonymous reporting for ethics matters).
- CC2.3 external communication: a published way for customers to report security issues, customer-facing commitments (terms, security pages, the system description), and procedures for notifying customers of incidents and changes that affect them. A vulnerability disclosure route belongs here too.
Evidence is usually the published artefacts plus records that they were used: tickets from the reporting channel, customer notifications sent, release notes. If CC2.3 commitments promise notification "within 72 hours" and the incident log shows a slower notification, expect an exception. See the Information Security Policy Template.
CC3: risk assessment
CC3 is where a single annual document carries four criteria, so it needs to be thorough. The 2022 revised points of focus describe risk analysis in terms of threats, vulnerabilities, the likelihood and magnitude of a threat exploiting a vulnerability, and residual risk after controls and management's decision to accept, reduce or share risk.
| Criterion | What the risk assessment should show | Evidence |
|---|---|---|
| CC3.1 | Security and service objectives, linked to service commitments and system requirements | Objectives section of the assessment, approved by management |
| CC3.2 | Risks across the entity, including vendors and business partners, with likelihood, impact, treatment and residual rating | Risk register with owners, dates and treatment plans |
| CC3.3 | Fraud scenarios: misuse of privileged access, payment fraud, falsified reporting, social engineering | Fraud section or separate fraud risk assessment |
| CC3.4 | Assessment of significant changes: new products, acquisitions, cloud migrations, leadership changes, adoption of AI services | Change risk reviews, architecture review records |
Vendor risk usually sits under CC3.2 (identifying risk from vendors) and CC9.2 (managing it). A NIST SP 800-30 Risk Assessment Guide style method gives auditors a recognisable structure; the Third-Party Risk Management Guide covers the vendor side.
Where identity fits
Risk assessments that list "unauthorised access" as one line rarely survive a good auditor's walkthrough. Name the identity risks concretely: compromised workforce accounts, over-privileged service accounts, long-lived API keys and tokens held by integrations and AI agents, and third-party OAuth applications. These are the risks your CC6 controls answer, and naming them in CC3.2 makes the link between risk and control visible. See the SOC 2 CC6 Logical Access Guide and the Board Briefing: NHI Risk.
CC4 and CC5: monitoring and control activities
- CC4.1 evaluations: ongoing evaluations (automated control monitoring, dashboards reviewed by control owners) and separate evaluations (internal audit, penetration tests, readiness assessments). The 2022 points of focus, per EY, add monitoring by first-line staff and their managers, not only internal audit. Review of subservice organisations' SOC reports is often placed here too.
- CC4.2 deficiencies: a findings log with severity, owner and due date, reported to management or the board at a set frequency. Auditors look for evidence that items from penetration tests and internal reviews were tracked to closure.
- CC5.1 control selection: a control matrix that links each significant risk in CC3.2 to the controls that mitigate it.
- CC5.2 technology general controls: the selection of access, change, operations and acquisition controls; the detail is tested under CC6, CC7 and CC8. See the SOC 2 CC8 Change Management Guide and the SOC 2 CC7 System Operations Guide.
- CC5.3 policies and procedures: policies approved and reviewed at least annually, procedures that make them operable, and named owners. An approval date outside the period, or a policy that contradicts the system description, is a common finding.
Continuous monitoring tools can provide much of the CC4.1 evidence, but the auditor still needs proof that someone reviewed the results and acted. See the Audit Evidence and Continuous Controls Monitoring Guide.
Decision guidance: small and large organisations
| Topic | Start-up or small company | Larger or regulated organisation |
|---|---|---|
| Oversight (CC1.2) | Founders or a small board with a documented annual security review and minutes; an external adviser adds independence | Audit or risk committee with a charter and regular security reporting |
| Risk assessment (CC3) | One annual assessment plus change reviews for major launches | Enterprise risk register with security risks, quarterly updates, separate fraud risk assessment |
| Monitoring (CC4) | Compliance automation plus an annual readiness review by an outside party | Internal audit plan covering SOC 2 controls, second-line control testing |
| Policies (CC5.3) | A compact policy set, all reviewed in one annual cycle | Policy framework with owners, staggered review, exception process |
Do not over-promise. Every control you write into the description will be tested. A small company that commits to quarterly board meetings and holds three will carry an exception it did not need.
How to implement CC1 to CC5
- Draft control statements per criterion: one to four controls each, worded as something that happens with a frequency and an owner, and checked against the points of focus that apply to you.
- Build the populations: confirm HR, training and policy acknowledgement systems can export complete lists of hires, leavers, staff and contractors for any date range.
- Set the calendar: place annual controls (risk assessment, policy review, board security review, vendor review, training campaign) in the first half of the period, with a backstop date.
- Run a readiness test: before the Type 1 or the start of the Type 2 period, sample your own evidence the way an auditor would and fix gaps. Treat this as a pilot: adjust control wording that cannot be evidenced.
- Link risk to controls: make the CC5.1 control matrix trace every significant CC3.2 risk to a tested control.
- Track deficiencies: open a findings log now (CC4.2) and feed it from penetration tests, incidents and internal reviews.
- Prepare a correction path: if a control fails mid-period, record it, remediate and document compensating activity; describing a missed control honestly is better than an unexplained gap.
The SOC 2 Readiness Checklist and the Audit Evidence Request Tracker Template help run this.
Detection and measurement
- Acknowledgement coverage: share of staff and contractors with current code of conduct and policy acknowledgements (target 100 per cent).
- Training currency: staff with security training completed within the last 12 months.
- Annual control on-time rate: entity-level controls completed before their calendar backstop date.
- Risk register freshness: days since last review, and share of risks with an owner and treatment.
- Deficiency ageing: open findings past due date, by severity.
- Exceptions by criterion across successive reports, to show whether CC1 to CC5 controls are maturing.
Framework mapping
| SOC 2 | COSO 2013 principles | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | ISO/IEC 27001:2022 |
|---|---|---|---|---|
| CC1.1 to CC1.5 | 1 to 5 | GV.RR-01, GV.OC-03 | PL-1, AT-2 | Clause 5, A.5.4, A.6.1, A.6.3, A.6.4 |
| CC2.1 to CC2.3 | 13 to 15 | ID.AM-02, GV.PO-01 | CM-8, PL-1 | Clause 7.4, A.5.9, A.5.12 |
| CC3.1 to CC3.4 | 6 to 9 | GV.RM-01, ID.RA-03 | RA-3, PM-9 | Clause 6.1, 8.2 |
| CC4.1, CC4.2 | 16, 17 | GV.OV-01, ID.IM-02 | CA-2, CA-7 | Clause 9.2, 9.3, 10.2 |
| CC5.1 to CC5.3 | 10 to 12 | GV.PO-01 | PL-1 | Clause 6.1.3, A.5.1 |
A full crosswalk is in the SOC 2 to ISO 27001 Mapping Guide.
Common failure patterns
- Annual control missed: the risk assessment or policy review slips past the period end, and the only occurrence is an exception.
- Contractors outside HR controls: no acknowledgement, screening or training for contractors who have production access.
- Generic risk register: a template list with no residual ratings, owners or link to controls, which fails CC3.2 and CC5.1 together.
- No fraud consideration: CC3.3 skipped because "we are not a bank"; privileged misuse and social engineering are fraud risks for any service organisation.
- Findings without follow-up: penetration test results filed but not tracked, leaving CC4.2 without evidence.
- Description and reality diverge: the system description promises board oversight, meeting frequencies or notification times the organisation does not keep.
Practitioner checklist
- Write one to four testable control statements for each of the 17 criteria, with owner and frequency.
- Confirm complete population exports for hires, leavers, staff and contractors.
- Calendar every annual entity-level control inside the first half of the period.
- Collect code of conduct and policy acknowledgements from staff and contractors at hire and annually.
- Run an annual risk assessment with threats, likelihood, impact, residual risk, fraud and significant change sections.
- Maintain a control matrix linking significant risks to controls.
- Keep a deficiency log with owners and due dates and report it to management.
- Review and approve policies at least annually and check them against the system description.
Standards and references
- AICPA and CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
- COSO: Internal Control Integrated Framework
- EY: To the Point, AICPA revises Trust Services Criteria points of focus (2022)
- AICPA and CIMA: SOC suite of services
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: SOC 2 Guide, SOC 2 Readiness Checklist, COSO for Cybersecurity Guide, SOC 2 Auditor Selection, Board Cyber Risk Reporting Guide. This guide summarises the SOC 2 common criteria CC1 to CC5 and is not legal or assurance advice.