Short answer: A SOC 2 risk assessment is a documented process for identifying risks to your service commitments, scoring them by likelihood and impact, deciding how to treat each one and reviewing the results at least annually and after major changes. Auditors look for a defined method, a risk register, management approval and evidence that treatments were followed up.
Risk assessment sits underneath almost every other SOC 2 control. Policies, access reviews, vendor management and monitoring are meant to respond to risks you have identified, not to a generic checklist. Auditors know this, and they test whether your controls link back to real risks. A company with excellent technical controls and no risk assessment will still struggle at fieldwork.
This guide walks through a practical process you can run in a few weeks, including a sample risk register, a simple scoring method and the evidence auditors typically ask for.
What SOC 2 expects from risk assessment
The Trust Services Criteria include a group on risk assessment within the Common Criteria. In plain terms, they expect you to:
- Specify objectives clearly enough to identify related risks.
- Identify risks to those objectives and analyze them to decide how to manage them.
- Consider the potential for fraud when assessing risk.
- Identify and assess changes that could significantly affect the system of internal control.
A related criterion addresses mitigation of risks from business disruptions and from vendors and business partners. The AICPA does not prescribe a method or a template. You choose an approach that fits your size and complexity, and then follow it consistently. See our summary of the five Trust Services Criteria for the wider framework.
Step-by-step process
Step 1: Define objectives and scope
Start from your service commitments, such as protecting customer data, keeping the service available and processing data accurately. Use the scope you defined in your SOC 2 scope work so the assessment covers the same systems.
Step 2: Build an asset and data inventory
List the systems, data stores, applications, vendors and people that make up the system. You cannot assess risks to things you have not listed.
Step 3: Identify threats and vulnerabilities
For each asset or process, ask what could go wrong. Typical categories include unauthorized access, data loss, ransomware, insider misuse, misconfiguration, third-party failure, outages, software vulnerabilities, regulatory changes and fraud. Involve engineering, operations, support and leadership, since each sees different risks.
Step 4: Score likelihood and impact
Use a simple scale that everyone understands. For example, rate likelihood and impact from 1 (low) to 5 (high) and multiply them for an overall score. Define what each number means so scores are consistent.
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Rare | Negligible effect on customers |
| 2 | Unlikely | Minor disruption, quickly resolved |
| 3 | Possible | Noticeable effect on some customers |
| 4 | Likely | Significant effect on many customers |
| 5 | Almost certain | Severe effect, major data exposure or long outage |
Step 5: Consider existing controls and residual risk
Score the risk before controls (inherent risk), list the controls that reduce it, and then re-score (residual risk). This shows how your controls connect to specific risks, which is exactly what auditors want to see.
Step 6: Decide on treatment
For each risk, choose to mitigate it, accept it, transfer it (for example through insurance or contract terms) or avoid it by changing the activity. Record who decided and why. Accepted risks need management sign-off.
Step 7: Assign owners and dates
Every risk that needs action gets an owner, a task and a target date, tracked in your ticketing system. Unowned risks stay open forever.
Step 8: Approve, review and repeat
Present the results to management and record approval. Repeat the assessment at least annually and whenever a significant change occurs, such as a new product, provider, region or major architecture change.
A sample risk register
| Risk | Inherent score | Key controls | Residual score | Treatment and owner |
|---|---|---|---|---|
| Unauthorized access to production data through a stolen credential | 20 | Multi-factor authentication, least-privilege roles, quarterly access reviews, logging | 8 | Mitigate. Head of Engineering |
| Critical vendor outage affects service availability | 16 | Vendor reviews, multi-zone deployment, status monitoring | 9 | Mitigate and monitor. Head of Operations |
| Ransomware encrypts internal systems | 15 | Endpoint protection, tested backups, network segmentation | 6 | Mitigate. Security Lead |
| Unreviewed code change introduces a vulnerability | 12 | Peer review, automated scanning, change approvals | 6 | Mitigate. Engineering Manager |
| Employee misuses access to customer data | 10 | Role-based access, background checks, monitoring | 4 | Accept with monitoring. CISO |
The scores above are illustrative. Your own values should come from your agreed scale and your real environment.
Do not forget these risk areas
- Fraud. Consider how someone might abuse their position, falsify records or bypass approvals.
- Vendors. Assess risks from providers that touch your system. Our guide to third-party risk management for SOC 2 covers this in detail.
- Change. Include risks created by growth, reorganizations, acquisitions and new technology.
- Business disruption. Link risks to your continuity and recovery plans.
- Emerging technology. If you use AI tools or new platforms, add the risks they introduce.
Evidence auditors usually request
- A written risk assessment methodology that describes scales and process.
- The current risk register with scores, controls, owners and treatment decisions.
- Meeting notes or approvals showing management reviewed and signed off.
- Tickets or tasks showing treatment actions were carried out.
- Proof that the assessment was refreshed at the required interval or after a significant change.
Our guide to documentation required for a SOC 2 audit lists the wider evidence set.
Common mistakes
- Using a generic risk list. A register copied from a template with no tailoring signals that no real assessment took place.
- No link between risks and controls. If controls exist for reasons the register does not explain, the program looks disconnected.
- One-time exercise. A register last updated 18 months ago fails the review requirement.
- No management approval. Auditors want proof that leadership accepted the results.
- Scores without logic. Unexplained numbers cannot be defended in an interview.
- Ignoring accepted risks. Risks that are accepted must be documented as such, with an owner.
Business implications
A good risk assessment does more than satisfy auditors. It helps leadership spend security budget where it matters and gives sales teams a credible answer when customers ask how you decide what to protect first. If you want help building one that fits your size, the SOC 2 readiness service includes risk assessment support, and a SOC 2 gap analysis shows where your current process falls short. The SOC 2 glossary defines terms such as inherent and residual risk.
Keeping the risk register alive after the first assessment
Auditors rarely criticise a first risk assessment for being imperfect. They criticise one that was done once and never touched. Build a rhythm so the register reflects the business as it changes.
Triggers for an off-cycle update
- A new product, feature, cloud region or major customer commitment.
- A security incident or near miss.
- A significant vendor change or vendor incident.
- A reorganisation, rapid hiring or the departure of a key person.
- A new regulation or contract term that affects data handling.
What a useful entry contains
| Field | Example content |
|---|---|
| Risk description | Compromised engineer credentials lead to unauthorised production access |
| Likelihood and impact | Your own consistent scale, such as low, medium or high, with written definitions |
| Existing controls | MFA, least privilege, access reviews, alerting |
| Residual risk | Rating after controls are considered |
| Owner and treatment | Named owner, decision to mitigate, accept, transfer or avoid, and a date |
Link each significant risk to the controls that address it, and review the register with leadership at least annually, recording the discussion. That record supports the governance expectations discussed in the governance and oversight expectations in the Common Criteria. For methodology help, our SOC 2 readiness service includes risk assessment support.
Frequently asked questions
Is a risk assessment required for SOC 2?
Yes. The Common Criteria expect you to identify and analyze risks to your objectives, and auditors will ask for evidence of a documented process.
How often should you do a SOC 2 risk assessment?
At least once a year, and again after significant changes such as a new product, major vendor or architecture change.
What is a risk register in SOC 2?
It is a record of identified risks with their scores, existing controls, treatment decisions, owners and review dates.
Does SOC 2 require a specific risk methodology?
No. The AICPA does not prescribe one. You choose a method suited to your organization and apply it consistently.
What is the difference between inherent and residual risk?
Inherent risk is the level before controls. Residual risk is what remains after your controls are applied.
Who should be involved in the assessment?
Leaders from engineering, operations, security, support and management. Management approval is expected for the final result.
Conclusion
A SOC 2 risk assessment is a repeatable process: define objectives, inventory assets, identify risks, score them, link them to controls, decide treatments, assign owners and have management approve the outcome. Do it once properly, refresh it on schedule and your controls will make sense to your team, your auditor and your customers.
