SOC 2 risk assessment: the CC3 process auditors scrutinize
A practical look at what the CC3 risk assessment criteria actually require, the COSO principles behind them, and the documentation gaps that draw auditor exceptions.
What CC3 actually asks for
Risk assessment sits in the SOC 2 common criteria as CC3.1 through CC3.4, and these criteria map directly onto COSO Principles 6 through 9, the framework the AICPA borrowed when it built the 2017 Trust Services Criteria. CC3.1 expects you to specify objectives clearly enough that risks to them can be identified; CC3.2 expects you to identify and analyze those risks across the entity; CC3.3 requires you to consider the potential for fraud; and CC3.4 requires you to identify and assess changes that could meaningfully affect your system of internal control. The point is not to produce a single artifact but to demonstrate a repeatable process: objectives, threats, analysis, and a decision about what to do. Auditors read CC3 as evidence that your control environment is risk-driven rather than a generic checklist someone copied from a template. If you cannot articulate which risks your controls are meant to address, the rest of the report tends to look arbitrary.
Building the risk register
Most service organizations operationalize CC3 through a risk register that lists each identified risk, the assets or objectives it threatens, an owner, and a scored estimate of likelihood and impact. A common and perfectly acceptable approach is to rate both dimensions on a simple scale, often one to five, and multiply or matrix them into an inherent risk rating before accounting for existing controls to land on a residual rating. The methodology itself matters less than consistency: auditors want to see that the same scoring logic was applied across entries and that the criteria for each score level are written down somewhere. Each risk should then carry a treatment decision, and the four standard options are to mitigate it with controls, transfer it through insurance or contractual means, accept it when it falls within tolerance, or avoid it by discontinuing the activity. The register becomes far more defensible when accepted risks reference who accepted them and why.
Linking risks to controls
The register is only useful if it connects to your actual control set, and this linkage is where CC3 earns its keep during an audit. For every risk you decide to mitigate, there should be one or more named controls that address it, and those controls should be the same ones described and tested elsewhere in your SOC 2 report. This traceability lets the auditor confirm that your controls exist for a reason rather than as window dressing, and it helps you spot risks that have no corresponding control, which is a gap worth closing before the examination period begins. The AICPA generally expects a thoughtful mix of preventive and detective controls and of automated and manual ones, with segregation of duties addressed explicitly where it is relevant. When risks and controls are cross-referenced cleanly, the narrative of your report reads as a coherent system rather than a collection of disconnected practices.
Fraud risk under COSO Principle 8
Fraud risk is the part of CC3 that organizations most often gloss over, yet it is a distinct requirement embedded in COSO Principle 8 and reflected in the criteria. The expectation is that your risk assessment explicitly considers the potential for fraud, including fraudulent reporting, misappropriation of assets, and management override of controls, and that you think about the incentives, pressures, opportunities, and rationalizations that make fraud more likely. For a software company this often surfaces as risks around privileged access being abused, financial or billing data being manipulated, or an insider exfiltrating customer data. You do not need an elaborate forensic program, but you do need evidence that fraud was considered as its own category of risk rather than folded silently into generic security threats. Auditors frequently note that a register has rich coverage of external and technical risk but says nothing about fraud at all.
What auditors expect to see as evidence
When an examiner tests CC3, they typically ask for the documented risk assessment, the methodology that explains how risks are scored and treated, and proof that the assessment was performed during the examination period rather than years earlier. A Type 2 examination covers a window of time, so a risk assessment dated well before that window, or one that has clearly not been revisited, undermines the claim that the process operates. Practitioners generally expect at minimum an annual refresh, with many organizations reviewing the register quarterly and re-examining their highest-rated risks more often. Evidence of change-driven reassessment also matters under CC3.4, so meeting minutes, tickets, or updated register entries that show you reassessed risk after a major product launch, acquisition, or new data type carry real weight. The strongest evidence shows dates, named participants, and a clear before-and-after that proves the process is alive.
The gaps that draw exceptions
The single most common finding is the stale assessment: a register created once to pass the first audit and then left untouched, which directly contradicts the periodic, ongoing nature CC3 contemplates. Close behind is the orphaned risk that lists no owner and no treatment, and the inverse problem of controls that exist with no risk to justify them. Many organizations also fail the fraud consideration outright, and others apply scoring so inconsistently that two similar risks carry wildly different ratings with no explanation. The fix is rarely more sophistication; it is discipline, meaning a recurring calendar reminder to revisit the register, a short standing agenda item to capture risks from significant changes, and a habit of dating every update. Treat the risk assessment as a living management process you would run even without an auditor watching, and the evidence largely produces itself.