Ask a room of SOC 2 newcomers what the audit checks, and most will say “the controls.” That’s not wrong, but it skips what makes SOC 2 different from a checklist framework: nothing in the Trust Services Criteria tells a company which controls to build. The criteria require a risk assessment instead — a documented process for identifying what could go wrong, rating how likely and damaging it would be, and choosing a response. Controls are the output of that process, not the input. An auditor testing CC3 and CC9 is grading whether the company actually thought about its risks, and whether its controls trace back to that thinking.
Why Risk Assessment Sits at the Center
SOC 2 is an attestation report issued under the AICPA’s SSAE 18 standard — not a certification, and the distinction matters. A certification implies a fixed bar: meet the requirements, get the stamp. An attestation is an independent opinion on claims a company makes about its own systems. Two Common Criteria carry that idea directly: CC3 covers risk assessment, CC9 covers risk mitigation, and underneath both sits the COSO Internal Control framework — the model used for financial reporting, adapted here to information security.
There is no published SOC 2 control list to implement line by line. The criteria describe outcomes — risks are identified, analyzed, and addressed — and leave the specific controls to the entity. Two companies with identical Trust Service Criteria scopes can pass with different controls, because their risks and systems differ.
That structure puts risk assessment at the center of the exercise, not a preliminary step before the “real” audit work starts. Every control should trace back to a risk it was chosen to address — and that risk should trace back to a service commitment or a system requirement. An auditor who can’t follow that chain has found a control that exists for its own sake.
Service Commitments and System Requirements
Service commitments are the promises made to customers — uptime, confidentiality, data handling — often written into contracts or a trust page. System requirements are what the system needs technically and operationally to keep those promises. A risk assessment grounded in both is scoped to what the report is meant to prove.
- Service commitments — uptime, confidentiality, data residency, breach notification
- System requirements — the conditions needed to meet those commitments
- Risks — events that could prevent either from being met
- Controls — the evidenced responses chosen to address each risk
The Methodology, Step by Step
SOC 2 doesn’t mandate a specific methodology — “no mandated method” doesn’t mean “no method required.” Auditors expect a defined, repeatable process, even a self-built one, following roughly the same sequence regardless of which framework inspired it.
Define Scope and Objectives
The assessment anchors to what’s in scope for the report — the systems, services, and Trust Service Categories selected. Objectives here means the service commitments and system requirements already identified; the risk assessment protects those, not every conceivable concern in the business.
Identify Assets and Threats
Next comes an inventory of what could be affected — production systems, data stores, source code, integrations, and the people with access — paired with the threats that could act against each one.
- Assets — infrastructure, applications, data, credentials, vendors with access to any of it
- External threats — credential theft, phishing, unpatched software, denial-of-service
- Internal threats — misconfiguration, excessive access, unvetted change
- Third-party threats — a vendor’s breach or outage becoming the company’s incident
Assess Likelihood and Impact
Each risk — a threat acting against an asset — is scored on how likely it is and how damaging it would be. Most companies use a simple scale, such as low/medium/high, rather than a statistical model, which auditors accept as long as scoring is consistent and documented rather than assigned by gut feel.
Rate and Prioritize
Likelihood and impact combine into an overall rating, usually a simple matrix, which drives prioritization. Not every risk gets equal attention — the rating is what lets a company defend treating a high-likelihood, high-impact risk differently from a low-probability edge case.
Risk Treatment: Accept, Mitigate, Transfer, Avoid
Once a risk is rated, the company decides what to do about it — and “do nothing” is a legitimate answer if it’s a documented decision rather than an oversight. SOC 2 recognizes four standard treatments, borrowed from COSO and general risk practice.
| Treatment | What It Means | Example |
|---|---|---|
| Accept | Within tolerance; no additional control added | A low-impact risk with no data exposure |
| Mitigate | Controls implemented to reduce likelihood or impact | MFA and access reviews reducing unauthorized access |
| Transfer | Risk shifted, in whole or part, to another party | Cyber insurance, or liability shifted to a vendor |
| Avoid | The activity creating the risk is eliminated | Discontinuing a legacy system or data practice |
The treatment decision alone doesn’t satisfy CC9 — it needs to result in something concrete. For mitigate, the most common answer, that means specific controls, each mapped to both the risk it addresses and the Trust Service Criteria category it supports. That mapping turns a risk register from a planning document into audit-ready evidence — an auditor can pull any control and ask what risk it addresses, and the answer should already be written down.
The Risk Register
The risk register is where this becomes a single, referenceable artifact — the documented output of the methodology, and the first thing most auditors ask to see. It isn’t produced once and filed away; a register unchanged since the last audit period is itself a finding, since it implies the business stood still for a year, which is rarely true.
| Risk | Likelihood | Impact | Treatment | Control |
|---|---|---|---|---|
| Unauthorized access to production database | Medium | High | Mitigate | MFA + role-based access, quarterly reviews |
| Loss or compromise of encryption keys | Low | High | Mitigate | Managed key service, rotation and backup |
| Subprocessor data breach | Medium | Medium | Transfer + Mitigate | Vendor risk assessments, security terms, cyber insurance |
| Insider misuse of administrative privileges | Low | High | Mitigate | Least-privilege access, logging, segregation of duties |
| Ransomware via phishing | Medium | High | Mitigate | Awareness training, email filtering, EDR, tested backups |
Beyond the risk-to-control mapping, a register that holds up under audit also tracks who owns each risk and when it was last reviewed. Those fields matter because they let an auditor confirm the register is a living process, not a one-time exercise reverse-engineered from controls the company already had.
- Risk description — specific enough to be actionable, not a generic category
- Likelihood and impact ratings — with the scoring method stated somewhere in the documentation
- Treatment decision — accept, mitigate, transfer, or avoid, with rationale
- Linked control(s) — the specific control implementing the treatment
- Owner and review date — who’s accountable, and when it was last revisited
Fraud and Change Risk
Two considerations get explicit attention within CC3’s points of focus, and both are easy for a first-time SOC 2 company to underweight: the potential for fraud, and the risk introduced by change.
Fraud Risk
The criteria expect the assessment to consider fraud specifically — not just external attackers, but intentional misconduct by people with legitimate access, such as an administrator disabling logging or colluding to bypass segregation-of-duties controls. A risk assessment that only models external actors is missing a criterion auditors specifically look for.
Change Risk
New systems, new personnel, restructuring, rapid growth, or a shift in business model can all invalidate a risk assessment that was accurate when written. CC3 expects the company to identify and assess the risk introduced by significant change, not treat the assessment as fixed on a calendar schedule.
The compromise of SolarWinds’ Orion software, disclosed in late 2020, illustrates change risk left unassessed. Malicious code was inserted into a routine software build and shipped to thousands of customers through the company’s normal update process — exactly the pathway a change-risk assessment is meant to scrutinize. The intrusion went undetected for months because that pathway wasn’t weighted the way the outcome later showed it deserved.
What Auditors Actually Look For
When an auditor tests CC3 and CC9, they aren’t grading the sophistication of the methodology — a simple spreadsheet with a defensible process can pass, and an elaborate framework with no follow-through cannot. What matters is whether the risk assessment is real.
- Is it current? — reflects the systems, vendors, and business as they exist now
- Is it evidence-backed? — supported by artifacts, not asserted after the fact
- Was it acted on? — identified risks map to implemented controls
Auditors don’t take a risk assessment’s word for it. They expect artifacts proving the process happened on the dates claimed: review notes, a ticket showing a control implemented in response to a specific risk, sign-off from the risk owner, and a register with a modification history.
Common Failures
A handful of patterns account for most risk-assessment findings, and nearly all come down to the assessment being decorative rather than operational.
- Stale register — created once for the first audit and never meaningfully revisited
- No linkage to controls — risks that connect to no control, or controls with no risk driving them
- Missing fraud and change consideration — external threats only, organizational change ignored
- No owner or cadence — nobody accountable, no schedule beyond “before the audit”
Final Thought
Risk assessment isn’t a document produced to satisfy CC3; it’s the reasoning that should already exist behind every control in a SOC 2 report. Get the methodology right — commitments tied to real risks, honest scoring, deliberate treatment decisions, and a register that actually gets used — and the controls that follow are easy to defend, because they were never arbitrary.
The test worth applying before an auditor ever asks: pick any control and ask what risk it addresses, how it was rated, and who decided the treatment. If that chain runs cleanly from register to control, the risk assessment will hold up. If it doesn’t, the gap won’t stay hidden — it’s usually the first thing CC3 testing finds.
Frequently Asked Questions
No. SOC 2 is an attestation under AICPA’s SSAE 18 standard, not a certification against a fixed control list. The criteria describe outcomes and leave the specific controls to the entity, provided each one is a defensible response to that company’s own risk assessment.
CC3 is the category covering risk assessment. It requires the entity to set clear objectives, identify and analyze risks to them, consider the potential for fraud, and assess changes that could significantly impact the system of controls. CC9 covers how those risks are actually mitigated.
At minimum once a year, and whenever a significant change occurs — a new system, a major vendor change, rapid growth, or an incident that reveals a gap. Auditors testing CC3 expect evidence the assessment reflects the business as it currently operates.
Each risk, its likelihood and impact ratings, the treatment decision, the specific control implementing it, an owner accountable for it, and the date it was last reviewed. The owner and review date matter most, since they prove the register is a living process, not a one-time list.
Whether it’s current, whether it’s backed by evidence such as meeting notes and sign-offs rather than just asserted, and whether it was acted on — meaning identified risks trace to implemented controls. Common findings come from a stale register or risks with no linked control.