SOC 2 CC3: risk assessment, with a worked
CC3 is four criteria and one document. If the risk register is good, three of the four are done.
CC3 asks four things: that you specify objectives clearly enough to identify risks against them (CC3.1), that you identify and analyse those risks (CC3.2), that you consider the potential for fraud (CC3.3), and that you identify and assess changes that could significantly affect the control system (CC3.4). One dated risk register with an owner per row, a treatment decision per row, at least one fraud scenario and a change-triggered review clause covers all four.
15 to 30 rows A defensible first risk register for a 10 to 50 person SaaS company
Under fifteen rows and an auditor reasonably asks whether you thought about it. Over about fifty and you have built something nobody will maintain, which fails the following year when CC3.4 asks what changed. Start narrow and let it grow from incidents and from the gap analysis.
What does a risk register row look like?
| Risk | Likelihood | Impact | Treatment | Owner |
|---|---|---|---|---|
| Departing engineer retains production access | Medium | High | Mitigate: offboarding checklist with a 24 hour access removal commitment | Head of platform |
| Long-lived cloud credentials committed to a repository | Medium | High | Mitigate: secret scanning in the pipeline, short-lived credentials, managed secret store | Engineering lead |
| Subprocessor suffers a breach affecting our customer data | Low | High | Mitigate and transfer: vendor review, breach notification clause, cyber insurance | Operations |
| Single founder holds sole access to the domain registrar | Medium | High | Mitigate: break-glass account documented, second administrator added | CTO |
| Employee with billing access issues fraudulent refunds | Low | Medium | Mitigate: refunds above a threshold require a second approver, monthly exception report | Finance |
| Region-wide cloud outage exceeds our stated recovery time | Low | Medium | Accept, with the recovery objective stated to customers rather than overpromised | CTO |
| Personal information of Quebec residents processed outside Quebec without assessment | Medium | Medium | Mitigate: privacy impact assessment before transfer, subprocessor list maintained | Privacy officer |
Two things in that table do real work. Every row names a person rather than a team, because an auditor testing CC3.2 will ask who owns it and "engineering" is not a person. And one row is accepted rather than mitigated, which is the mark of a register somebody thought about. A register where every risk is mitigated is a register that was written to pass an audit.
Why does CC3.3 ask about fraud?
Because the Trust Services Criteria inherit COSO's internal control structure, which was built for financial reporting, and fraud consideration is a COSO principle. Security teams read CC3.3, decide it does not apply to a SaaS company, and skip it. It is one of the more reliable exceptions in a first report.
You do not need a fraud program. You need evidence that you considered fraud scenarios relevant to your system and decided what to do. Three that apply to almost every SaaS company: an insider with database access altering customer records, an employee with payments access moving money, and an account takeover of a privileged internal account used to exfiltrate data. Put them in the register with a treatment and CC3.3 is satisfied.
CC3.4 is the criterion that catches you in year two
CC3.4 asks that you identify and assess changes that could significantly affect internal control. A first report usually passes it on the strength of the register existing. The second report is tested against a year in which you migrated a database, acquired a product, or hired thirty people, and the auditor will ask what risk assessment those changes triggered. Write the trigger list into the policy now: a new subprocessor, a new production environment, a material change in headcount, a new data type, an acquisition.
Should we score risks with numbers?
Only if you will defend the numbers. A three by three high, medium, low grid with a written rationale per row is acceptable to a SOC 2 auditor and takes an afternoon. A quantified model with dollar-value expected losses is better decision-making and much worse evidence, because the auditor will test whether the inputs are supportable and most of them will not be.
The exception is where you are heading for ISO 27001 as well, since a certification body expects a defined and repeatable risk methodology with documented criteria for accepting risk. If both are on the roadmap, build the methodology once to the stricter standard. The framework comparison on ISO27K covers the choice itself.
How often does the risk assessment have to run?
| Stated cadence | Records per year | Realistic for | Risk if you miss one |
|---|---|---|---|
| Annual, plus on trigger | 1 plus triggers | Almost every first audit | Low. Miss it and the exception is obvious and fixable |
| Semi-annual | 2 | Companies with a dedicated security owner | Medium. Two chances to be late in one window |
| Quarterly | 4 | Regulated data or a security team | High. Four records, and a template pack will promise this by default |
Write annual unless somebody is going to do more. A downloaded policy that promises quarterly assessments is the single most common self-inflicted finding in the whole standard, and the same trap is covered on the policy templates page.
Get a risk assessment an auditor will accept
A risk register written the week before fieldwork reads like one. Tell us your scope and compare firms that will run the assessment and keep it current.
Get matchedCommon questions
How many risks should a SOC 2 risk register have?
For a 10 to 50 person SaaS company, roughly 15 to 30 rows is defensible. The number matters less than the shape: every row needs an owner who is a named person, an analysis of likelihood and impact, and a treatment decision that is sometimes acceptance rather than mitigation.
Does CC3 require a formal risk methodology document?
SOC 2 does not require a separate methodology document the way ISO 27001 does. It requires that your process is defined enough to be repeated, which a short risk assessment policy covering scope, scale, cadence and who approves treatment decisions satisfies.
What fraud risks apply to a SaaS company?
Insider modification of customer data, misuse of payment or refund access, and abuse of a privileged internal account to extract data. Record those three with a treatment and CC3.3 is met. You do not need a fraud investigation function.
Can the risk register live in a spreadsheet?
Yes. Auditors accept a spreadsheet as readily as a platform module, provided it is dated, versioned and shows evidence of review rather than a single creation date. Keep a copy of the version in force at the start of the observation window.
Who should approve the risk register?
Whoever you named as the oversight body under CC1.2. Aligning the two means one meeting produces evidence for both families, and it stops you inventing an approval chain that does not exist.