What a SOC 2 risk assessment needs to cover
A SOC 2 risk assessment is a documented, repeatable process for finding the risks to the commitments you make to customers, rating them, and deciding how each one is handled. The auditor wants to see that the process exists, that it ran when your policy said it would, and that its decisions led to real controls.
The requirement sits in the Common Criteria under risk assessment, CC3.1 to CC3.4. In general terms, they ask you to:
- Set objectives clearly enough to assess risk against them (CC3.1). You can't say what threatens your security commitments until you have written down what those commitments are.
- Identify and analyze risks (CC3.2). Find the risks to those objectives across the organization, including risks from vendors and partners, judge how likely and how serious each one is, and use that to decide how to respond.
- Consider the potential for fraud (CC3.3). Look at how someone inside or outside the company could misuse access, override controls or misreport, not only at accidents and outside attackers.
- Assess significant changes (CC3.4). Notice when changes in the business, its technology, its leadership or its environment could weaken your controls, and assess them.
Your auditor reads these criteria together with your own Risk Management Policy. The policy says how you assess risk and how often, and the audit checks that you did what it says. If you are still putting your policy set together, see Which SOC 2 policies do you need?
How to run an annual risk assessment, step by step
For a small company, this is usually a few working sessions with the people who run engineering, operations and the business, then a write-up and sign-off.
Step 1: Confirm scope and objectives
Start from what your SOC 2 report covers: the product or service in scope, the Trust Services Categories you chose, and the commitments you make in contracts and on your website (for example uptime, data protection and incident notification). Write a short paragraph stating the objectives the assessment protects, such as "customer data stays confidential and intact" and "the service is available as committed". This paragraph is your evidence for CC3.1, so keep it in the assessment itself.
Step 2: List your assets
List what you need to protect. Keep it at a useful level of detail: groups of things, not every laptop.
- customer data and where it lives (production databases, backups, logs, analytics);
- production infrastructure and the cloud accounts behind it;
- source code and the deployment pipeline;
- identity and access systems, such as your single sign-on directory;
- key vendors your service depends on;
- people with privileged access, and the knowledge only a few of them hold.
Step 3: Identify threats and write them as risks
For each asset, ask what could go wrong. Write each risk as a sentence with a cause, an event and a consequence, for example: "A phishing attack steals an engineer's credentials, leading to unauthorized access to production data."
Cover the usual categories: external attacks, mistakes and misconfiguration, outages and capacity, vendor failures, loss of key people, legal and contractual risk, and fraud. For fraud, think about incentives, opportunities and how someone could justify it to themselves: an admin who could delete audit logs, an employee who could export customer data before leaving, or a payment change requested by a fake email from a "vendor".
Step 4: Score likelihood and impact
Use a simple scale and write down what each number means so next year's scores are comparable. A 1 to 5 scale for each works well:
| Score | Likelihood (example definition) | Impact (example definition) |
|---|---|---|
| 1 | Rare: not expected in the next few years | Negligible: no customer effect |
| 2 | Unlikely: could happen once in several years | Minor: brief disruption, no data exposed |
| 3 | Possible: could happen within a year or two | Moderate: noticeable outage or limited data exposure |
| 4 | Likely: expected within the year | Major: extended outage, customer data exposed, contract breach |
| 5 | Almost certain: happens repeatedly | Severe: large breach, regulatory action, loss of key customers |
Multiply the two for a score from 1 to 25, and set bands, for example 1 to 6 low, 8 to 12 medium, 15 to 25 high. The exact numbers matter less than applying them consistently.
Step 5: Separate inherent and residual risk
Inherent risk is the score before your controls. Residual risk is the score after the controls you actually have today. Recording both shows which controls carry the most weight. List the existing controls next to each risk, and only count a control that is in place and operating.
Step 6: Decide how to treat each risk
Every risk above your tolerance needs an explicit decision. There are four options:
- Mitigate: add or strengthen controls to bring the residual risk down, such as enforcing multi-factor authentication or adding alerting.
- Accept: live with the risk because the cost of reducing it outweighs the benefit. Record who accepted it, why, and when it will be looked at again.
- Transfer: shift part of the impact to someone else, for example through insurance or contract terms. The risk doesn't disappear, so keep it on the register.
- Avoid: stop doing the thing that creates the risk, such as retiring a legacy system or no longer storing a type of data.
Step 7: Assign owners and due dates
Each risk gets a named owner who is accountable for it, and each mitigation action gets a due date. Track the actions in the tool your team already uses for work, and link the tickets from the register. An action with no owner and no date is a wish, and auditors treat it like one.
Step 8: Get management sign-off
Senior management (in a small company, usually a founder or the CEO, plus whoever leads security) reviews the results, agrees the treatment decisions and approves the accepted risks. Record who approved it and when. That sign-off is what turns a list of risks into a management decision.
A simple risk register template
The risk register is where the assessment lives between reviews. A table on a single page is enough for most small companies. Copy the columns below; the three rows are examples only, so replace them with your own risks.
| ID | Risk | Owner | Inherent (L x I) | Existing controls | Residual (L x I) | Treatment | Action and due date | Status |
|---|---|---|---|---|---|---|---|---|
| Example R-01 | Phished credentials give an attacker access to production data | Head of Engineering | 4 x 5 = 20 | Single sign-on with MFA, quarterly access reviews | 2 x 5 = 10 | Mitigate | Phishing-resistant MFA for admins, due end of Q2 | In progress |
| Example R-02 | Cloud region outage makes the service unavailable | Platform lead | 3 x 4 = 12 | Multi-zone deployment, tested backups | 2 x 4 = 8 | Accept | Accepted by CEO; revisit at next assessment | Accepted |
| Example R-03 | Fake vendor email changes payment details | Finance lead | 3 x 3 = 9 | None documented | 3 x 3 = 9 | Mitigate | Call-back check on bank detail changes, due next month | Open |
Add a "last reviewed" date to the page, and keep the scoring scale and bands from step 4 next to the table so a reader can interpret the numbers.
Tip: at each annual assessment, save a dated snapshot of the whole register with the assessment's evidence. A live register only shows today; the auditor needs to see what it looked like when management signed it off.
How often to refresh the risk assessment
Most SOC 2 programs run a full risk assessment at least once a year. SOC 2 doesn't fix one frequency: your Risk Management Policy sets it, and your auditor tests you against it. Between full assessments, keep the register alive. Many teams look at their top risks and open actions at a regular management security meeting, which also gives you a record that leadership is paying attention.
Changes that should trigger an update
CC3.4 is about change, so don't wait for the annual cycle when something significant happens. Typical triggers:
- a new product, a new market or a new type of customer data;
- a major architecture change, a new cloud provider or a new critical vendor;
- an acquisition, a reorganization or the departure of a key person;
- new laws, regulations or contract terms that apply to you;
- a serious security incident or near miss.
When one happens, assess the change, update the affected risks and note the date and reason on the register. To see where the annual assessment sits next to your other recurring controls, see The SOC 2 compliance calendar.
Common risk assessment mistakes
- A generic list. A register copied from a template with no link to your systems, vendors or commitments. Auditors ask how each risk applies to you.
- No fraud risks. CC3.3 asks for them specifically, and they are easy to forget when the team thinks only about attackers.
- Only inherent scores. Without residual scores you can't show which controls reduce which risks.
- Treatments with no owner or date. Mitigations that never happen show up a year later as the same open risk.
- Accepted risks with no approver. Acceptance is a management decision, so record who made it.
- No snapshot. The register was edited all year and nobody kept the version that was approved.
Scheduling the risk assessment with Compliance in a Box
If your team works in Confluence, Compliance in a Box sets up the risk assessment as one of its SOC 2 recurring activities, alongside the policy that governs it:
- An annual Risk Assessment activity. It runs once a year by default, following your fiscal year, with each period due on its last day. In the app's control mappings it supports CC3.1 to CC3.4.
- An evidence page every year. Before each period is due (14 days ahead by default), the app creates an evidence page under the Risk Assessment activity page. It starts with a checklist and a heading for each item to provide: the risk register snapshot, new risks and treatment decisions. Attach or paste the dated register there.
- An owner and approvers. The activity's owner completes and submits the evidence page, and every approver must approve it. The approval is bound to the exact page version submitted, and editing the page before approval cancels the submission. If the owner approves their own evidence, it is flagged as a self-approval, so choose an approver from management for the sign-off in step 8.
- The Risk Management Policy. The app provides it as one of the SOC 2 policies, mapped to CC3.1 to CC3.4, with a 12-month review cycle. Only its owner and Compliance Admins can edit it, and each new version goes through approval. If nothing changed at review time, the owner can use Mark as reviewed.
- Gaps stay visible. A period that passes its due date without approval shows as overdue on the Dashboard and in the Controls Matrix.
See Evidence pages and Periodic reviews in the user guide, the SOC 2 content reference for the full list of activities, and SOC 2 evidence collection for keeping assessments like this audit-ready.
FAQ
Is a risk assessment required for SOC 2?
Yes. The Common Criteria include a risk assessment group (CC3.1 to CC3.4) that applies to every SOC 2 report, whichever optional categories you add.
How often should a SOC 2 risk assessment be done?
At least annually is the common practice, plus an update after significant changes. Your Risk Management Policy sets the cadence, and your auditor checks that you followed it.
Do we need risk management software?
Not for a small company. A well-kept table with clear scoring, owners, treatments and a dated, approved snapshot each year meets the intent. What matters is that the process is repeatable and the decisions are recorded.