Join our Newsletter — 33% off our NHI Course
Home› Guides› SOC 2 CC1 to CC5 Guide: Entity-Level Controls,…
Guide Audit, Assurance & Compliance

SOC 2 CC1 to CC5 Guide: Entity-Level Controls, Evidence and Common Exceptions

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 11 November 2026 14 min read
On this page

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.

CriterionCOSO componentIn shortTypical control owner
CC1.1Control environmentCommitment to integrity and ethical valuesHR, legal
CC1.2Control environmentBoard independence and oversight of internal controlBoard, CEO
CC1.3Control environmentStructures, reporting lines, authorities and responsibilitiesExecutive team
CC1.4Control environmentAttract, develop and retain competent peopleHR, managers
CC1.5Control environmentIndividuals held accountable for internal controlHR, managers
CC2.1Information and communicationRelevant, quality information supports internal controlSecurity, IT
CC2.2Information and communicationInternal communication of objectives and responsibilitiesSecurity, HR
CC2.3Information and communicationCommunication with external partiesSecurity, legal, support
CC3.1Risk assessmentObjectives specified clearly enough to identify risksExecutive team, CISO
CC3.2Risk assessmentRisks identified and analysed across the entityCISO, risk owner
CC3.3Risk assessmentPotential for fraud consideredCISO, finance
CC3.4Risk assessmentSignificant changes identified and assessedCISO, engineering leadership
CC4.1Monitoring activitiesOngoing and separate evaluations of controlsCompliance, internal audit
CC4.2Monitoring activitiesDeficiencies evaluated and communicated in timeCompliance, management
CC5.1Control activitiesControl activities selected to mitigate risksCISO
CC5.2Control activitiesGeneral control activities over technologyIT, engineering
CC5.3Control activitiesControls deployed through policies and proceduresPolicy 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

CriterionTypical control statementsEvidence requestedFrequent exception
CC1.1Code of conduct acknowledged at hire and annually; background checks for new hires where lawful; disciplinary process for violationsSigned acknowledgements for sampled hires and staff; background check results; policyContractors missed from acknowledgement and screening
CC1.2Board or equivalent oversight body meets at least annually and reviews security and risk; independent members or advisers where possibleCharter, minutes, security agenda itemsStart-ups with no formal board record of security discussion
CC1.3Organisation chart maintained; security responsibilities assigned to a named role; job descriptions include security dutiesOrganisation chart, role descriptions, RACIChart out of date by the period end
CC1.4Job descriptions and hiring criteria; security training at hire and annually; performance reviewsTraining completion for sampled staff; review recordsAnnual training overdue for a few staff
CC1.5Performance reviews include control responsibilities; sanctions process enforcedReview templates, completed reviews, sanction recordsReviews 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.

CriterionWhat the risk assessment should showEvidence
CC3.1Security and service objectives, linked to service commitments and system requirementsObjectives section of the assessment, approved by management
CC3.2Risks across the entity, including vendors and business partners, with likelihood, impact, treatment and residual ratingRisk register with owners, dates and treatment plans
CC3.3Fraud scenarios: misuse of privileged access, payment fraud, falsified reporting, social engineeringFraud section or separate fraud risk assessment
CC3.4Assessment of significant changes: new products, acquisitions, cloud migrations, leadership changes, adoption of AI servicesChange 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

TopicStart-up or small companyLarger or regulated organisation
Oversight (CC1.2)Founders or a small board with a documented annual security review and minutes; an external adviser adds independenceAudit or risk committee with a charter and regular security reporting
Risk assessment (CC3)One annual assessment plus change reviews for major launchesEnterprise risk register with security risks, quarterly updates, separate fraud risk assessment
Monitoring (CC4)Compliance automation plus an annual readiness review by an outside partyInternal audit plan covering SOC 2 controls, second-line control testing
Policies (CC5.3)A compact policy set, all reviewed in one annual cyclePolicy 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

  1. 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.
  2. Build the populations: confirm HR, training and policy acknowledgement systems can export complete lists of hires, leavers, staff and contractors for any date range.
  3. 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.
  4. 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.
  5. Link risk to controls: make the CC5.1 control matrix trace every significant CC3.2 risk to a tested control.
  6. Track deficiencies: open a findings log now (CC4.2) and feed it from penetration tests, incidents and internal reviews.
  7. 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 2COSO 2013 principlesNIST CSF 2.0NIST SP 800-53 Rev 5ISO/IEC 27001:2022
CC1.1 to CC1.51 to 5GV.RR-01, GV.OC-03PL-1, AT-2Clause 5, A.5.4, A.6.1, A.6.3, A.6.4
CC2.1 to CC2.313 to 15ID.AM-02, GV.PO-01CM-8, PL-1Clause 7.4, A.5.9, A.5.12
CC3.1 to CC3.46 to 9GV.RM-01, ID.RA-03RA-3, PM-9Clause 6.1, 8.2
CC4.1, CC4.216, 17GV.OV-01, ID.IM-02CA-2, CA-7Clause 9.2, 9.3, 10.2
CC5.1 to CC5.310 to 12GV.PO-01PL-1Clause 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

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.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 11 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org