CC3: SOC 2 Risk Assessment Controls Explained

What Is CC3?

CC3 maps to the COSO Risk Assessment component. It requires the organization to identify, analyze, and respond to risks that could prevent the service commitments and system requirements from being met. For SOC 2, this means risks to the five Trust Services Criteria: security, availability, confidentiality, processing integrity, and privacy.

Most SOC 2 audits include only the Security criterion, but the risk assessment must still be scoped to the system being audited. If your SOC 2 report covers a SaaS product, your risk register should address risks to that product's confidentiality, availability, and integrity.

CC3 Sub-Criteria Overview

CC3.1 — The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives. This means your system description must define what the system is supposed to do, so risks to those objectives can be identified.

CC3.2 — The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. This is the risk identification and analysis step — your risk register.

CC3.3 — The entity considers the potential for fraud in assessing risks to the achievement of objectives. Fraud risk must be explicitly addressed — this is a separate point from general operational risk.

CC3.4 — The entity identifies and assesses changes that could significantly impact the system of internal control. This means your risk assessment process must be triggered not just annually but when material changes occur.

Building a Risk Register (CC3.1)

A risk register is a structured document listing identified risks, their likelihood and impact, the controls that mitigate them, and the residual risk after controls are applied. It does not need to be sophisticated — a well-maintained spreadsheet or GRC tool entry satisfies CC3.1.

Each risk entry should include: risk ID, risk description, threat source (e.g., external attacker, insider, natural disaster), affected objective (confidentiality, availability, etc.), inherent likelihood (1-5), inherent impact (1-5), inherent risk score, mitigating controls, residual likelihood, residual impact, and risk owner.

Typical risks for a SaaS company include: unauthorized access to production database, data exfiltration by a terminated employee, ransomware attack on cloud infrastructure, third-party vendor breach, and accidental data deletion. Each should map to controls in your control library.

Assessing Risks from Change (CC3.2)

CC3.2 and CC3.4 require you to assess risks when significant changes occur. Examples of triggering events: new product features that handle sensitive data, migration to a new cloud region, acquisition of another company, significant new vendor relationship, or changes to the engineering team structure.

Your risk assessment policy should define what constitutes a "significant change" and require a risk assessment to be completed before the change goes live. A lightweight risk assessment form attached to your change management tickets (Jira, Linear) can satisfy this requirement without adding significant overhead.

Fraud Risk Assessment (CC3.3)

CC3.3 explicitly requires considering fraud risk. For a SaaS company, relevant fraud risks include: billing fraud (manipulating subscription records), data theft by insiders for competitive advantage, expense reimbursement fraud, and vendor invoice manipulation.

Your fraud risk assessment doesn't need to be a separate document — it can be a section of your annual risk assessment. It should identify fraud scenarios, assess their likelihood and impact, and document the controls that mitigate them (e.g., segregation of duties in finance, access logs reviewed for unusual data exports).

Risk Treatment and Residual Risk

For each risk, the organization must decide how to treat it: accept (the residual risk is within tolerance), mitigate (add or improve controls), transfer (purchase cyber insurance or contractually shift risk), or avoid (stop the activity that creates the risk).

Auditors look for evidence that treatment decisions were made consciously — not just that controls exist. A risk register where every risk has an "accept" treatment with no justification will draw scrutiny. Document your risk tolerance statement and show how it drives treatment decisions.

CC3 Evidence Requirements

Primary CC3 evidence artifacts: (1) Risk register with at least one full annual cycle during the audit period. (2) Risk assessment policy defining scope, methodology, frequency, and responsible parties. (3) Risk assessment meeting minutes or approval records showing leadership reviewed and approved the risk register. (4) Evidence of in-period risk assessments triggered by changes. (5) Fraud risk assessment section or standalone document.

For Type II audits, auditors will check that the risk register was updated during the audit period — not just that it exists. Keep a dated revision history in your risk register.