Why this matters
The risk assessment is one of the few SOC 2 items you write rather than adopt. Under CC3, the auditor checks that you set objectives, identify risks to those objectives, consider fraud, and revisit the list when your system changes. A spreadsheet of generic rows does not clear that bar.
It also shapes the rest of your control set. A risk with no control against it is either a gap to fix or an acceptance to sign. That link is what stops the assessment from being a document you produce once for the auditor and never open again.
Done well, you get a short list of real risks, each with an owner, a date, and a control or a signed acceptance behind it. Done badly, you get controls you do not need and gaps nobody flagged.
Before you start
Name one owner, usually the CTO or a security lead, plus a senior signer such as a founder or a finance lead. Two names is enough. A committee will not finish it.
Collect the inputs first: the system description and its boundary, last year's register, the incident log, the vendor list, any penetration test output, staff changes, and your control matrix. If the control matrix is not written down, list the controls you actually run before you score anything. You cannot map risks to controls that exist only in someone's head.
Agree the scoring scale in writing. A 5x5 matrix with plain definitions for each level works. Define impact in your own terms: hours of downtime, number of records, contractual exposure. Two people scoring the same risk should land on the same number. If they don't, the definitions are too vague.
Book a 90 minute session with engineering, operations, and whoever handles finance and HR. Ask each to bring risks from their own area. Set the review cadence now: a full review every year, plus a lighter refresh when you add a product line, a region, a critical vendor, or a new class of data.
How to do it
Run it in two passes. First list risks without judging them, then score and decide. Separating the passes stops people from killing a risk because it sounds unlikely.
Write each risk as one sentence with a cause, an event, and a consequence. That structure keeps the register specific. Close the session by mapping every risk you keep to a control, or by writing a formal acceptance with a name and a date.
The steps below are the order that works when the group is small and the time is short.
- Write the scoring rules first. Before anyone names a risk, agree what a 4 on impact means and what a 4 on likelihood means. Put those definitions in the same document as the register so the next review uses the same scale.
- List the assets in scope. Name the systems, the data stores, and the customer data types your system description covers. Risks to anything outside that boundary belong in a different exercise.
- Brainstorm by risk category. Walk through external attack, insider misuse, vendor failure, technology failure, people and process error, physical and environmental damage, and fraud. Fraud gets its own line items under CC3.3, not a footnote.
- Write risks as cause, event, consequence. One sentence, specific to your system. If you cannot name the cause or the consequence, the risk is too vague to treat or test.
- Score, rank, and trim the list. Score every risk, sort them, and keep a working register of the ones that matter. Twelve to twenty five live risks is a normal size for a small company. A hundred rows means nobody is acting on them.
- Pick a treatment and name an owner. Mitigate, accept, transfer, or avoid, with a named person and a target date. Accept is a valid answer when a senior person signs it and you record why.
- Map risks to control IDs. Use the same IDs as your control matrix so the two documents speak to each other. Any risk with no control and no acceptance becomes a remediation item on your roadmap.
- Get sign-off and version the document. Record who reviewed it, when, and what changed from the last version. Keep old versions, because the auditor often asks for the one in force during the test period.
- Book the next review before you leave. Put the date in the calendar and list the trigger events that force an early refresh, such as a new region, a critical vendor change, or a serious incident.
How to check it worked
Test it the way an auditor will. Pick three risks at random from the register. For each one, ask which control mitigates it, whether that control was running during the period, and whether you can pull evidence for a sample. If you cannot answer all three inside ten minutes, the register is not connected to your operations.
Check the paperwork. The assessment should be dated inside the audit period, approved by someone senior, and versioned. A register last touched 14 months ago with nothing changed invites a question about how you monitor change under CC3.4.
Look for coverage holes. Fraud should be its own set of items. Vendor risk should appear. So should change management, because new systems bring new risk. If every entry is a variation of an employee clicking a phishing link, you have not assessed your own system.
Re-check after remediation. Risks you said you would fix should now be closed with evidence, or accepted again with a fresh signature. An item that rolls forward three cycles with the same date tells the auditor the process is not working.
Mistakes to avoid
Copying a template register and signing it. A generic list that mentions unauthorized access six times does not describe your system, and auditors see the pattern quickly.
Leaving fraud out. CC3.3 asks how fraud could stop you meeting your objectives. That means insider theft, falsified records, and someone bypassing a control on purpose. Add the items even when the answer is low likelihood and moderate impact.
Splitting the register from the control matrix. If risk IDs and control IDs live in different tools with different owners, nothing links and nobody can trace a control back to a reason. Keep the IDs consistent even if the documents stay separate.
Treating it as a once-a-year event. Changes to your system change your risk. Keep a trigger list in the document and act on it. If you want a second pair of eyes on the whole picture, the Cloudverg SOC 2 readiness assessment is a fixed price $7,500 engagement over three weeks with a gap assessment against the Trust Services Criteria and a remediation roadmap with owners and dates. It is one option. A steady internal lead can run the same process.
Frequently asked questions
How often should a SOC 2 risk assessment be done?
At least once a year, and again when something material changes. The review date needs to fall inside the period the auditor is testing. Keep a trigger list in the document so a new vendor or region does not wait for the annual cycle.
Who should own the SOC 2 risk assessment?
Usually the CTO or a security lead runs the process, and a founder or finance lead signs it. Each risk also gets its own owner in the register. Pick someone who can actually change the thing that creates the risk.
Does the risk assessment need to cover fraud?
Yes. CC3.3 asks how fraud could prevent you from meeting your objectives. Cover insider misuse, falsified records, and deliberate control bypass. A short set of scored fraud items is enough to show the work.