SOC 2 Risk Assessment Process: Step-by-Step Playbook

At Agency, we facilitate risk assessments for dozens of clients each year — and it is one of the most commonly missed SOC 2 requirements we encounter with first-time organizations. SOC 2 Common Criteria CC3 requires organizations to identify, evaluate, and manage risks that could affect the achievement of the Trust Service Criteria objectives. In practice, this means conducting a formal, documented risk assessment at least annually that identifies threats and vulnerabilities, evaluates likelihood and impact, documents risk treatment decisions, and maintains a risk register. What we always tell clients is that auditors do not expect a perfect risk-free environment — they expect evidence that the organization has a structured process for identifying risks, evaluating their significance, and making intentional decisions about how to address them.

This playbook walks compliance teams through the complete SOC 2 risk assessment process, from initial threat identification through risk register maintenance. It covers risk identification methodologies, likelihood and impact scoring frameworks, risk appetite definition, treatment option selection, risk register construction, and how to integrate risk assessment outputs with your GRC platform and control framework.

What Auditors Expect from Your Risk Assessment

CC3 Requirements

| Requirement | What the Auditor Checks | |-------------|------------------------|
| CC3.1 — Risk identification | Documented process for identifying risks; evidence that risks have been identified across the control environment | | CC3.2 — Risk evaluation | Methodology for assessing risk likelihood and impact; consistent application of evaluation criteria | | CC3.3 — Change-driven risk | Evidence that significant changes (new services, infrastructure changes, organizational changes) trigger risk reassessment | | CC3.4 — Fraud risk | Consideration of potential fraud risks and preventive controls |

What a Passing Risk Assessment Looks Like

Element	Auditor Expectation
Documented methodology	Written approach describing how risks are identified and evaluated
Risk register	Maintained list of identified risks with owners, ratings, and treatment decisions
Annual completion	Risk assessment completed within the last twelve months
Management involvement	Evidence that leadership participates in or reviews the risk assessment
Risk-control linkage	Risks connected to the controls that mitigate them
Treatment decisions	Each risk has a documented treatment decision (mitigate, accept, transfer, avoid)

Common Risk Assessment Findings

Finding	How to Avoid
No formal risk assessment exists	Complete this playbook; document the assessment in your GRC platform
Risk assessment completed but no risk register maintained	Build and maintain the risk register as described in Step 5
No methodology documented	Document your scoring methodology before conducting the assessment
Risk assessment is over twelve months old	Schedule annual reviews; set calendar reminders or GRC platform alerts
No fraud risk consideration	Include fraud risk as a category in your threat identification
No change-triggered reassessment	Document the process for reassessing risk when significant changes occur

Step 1: Define Your Risk Assessment Methodology

Choose a Scoring Framework

Before identifying risks, define how you will evaluate them. We recommend a qualitative likelihood-impact matrix as the most practical approach for SOC 2:

Likelihood Scale

| Rating | Score | Definition | |--------|-------|-----------|
| Rare | 1 | Unlikely to occur within three years; no history of occurrence | | Unlikely | 2 | May occur once within three years; limited history | | Possible | 3 | May occur once per year; some history or industry precedent | | Likely | 4 | Expected to occur multiple times per year; regular occurrence in the industry | | Almost Certain | 5 | Expected to occur frequently; active threat or known vulnerability |

Impact Scale

| Rating | Score | Definition | |--------|-------|-----------|
| Negligible | 1 | Minimal business impact; no data exposure; no customer notification required | | Minor | 2 | Limited business impact; minor data exposure; single customer affected | | Moderate | 3 | Significant business impact; moderate data exposure; multiple customers affected | | Major | 4 | Severe business impact; significant data exposure; regulatory notification required | | Critical | 5 | Existential business impact; widespread data breach; regulatory enforcement; loss of major customers |

Risk Rating Calculation

Risk Rating = Likelihood × Impact

Risk Score	Risk Level	Response Priority
1-4	Low	Monitor; accept or mitigate per risk appetite
5-9	Medium	Mitigate within ninety days; assign control owner
10-15	High	Mitigate within thirty days; escalate to management
16-25	Critical	Mitigate immediately; executive attention required

Document the Methodology

We advise creating a one-to-two-page methodology document that includes:

• The scoring scales (likelihood and impact definitions)
• The risk rating calculation method
• Risk level definitions and response priorities
• Review cadence (annual at minimum; change-triggered reassessment process)
• Roles and responsibilities (who conducts the assessment, who reviews, who approves)

This methodology document serves as auditor evidence and ensures consistency across annual assessments.

Step 2: Identify Threats and Vulnerabilities

Threat Categories for SOC 2

We recommend organizing risk identification across these categories to ensure comprehensive coverage:

Category	Example Threats
External cyber threats	Phishing attacks, ransomware, DDoS, API exploitation, supply chain attacks, credential stuffing
Internal threats	Unauthorized access by employees, accidental data exposure, insider theft, privilege misuse
Access management	Unauthorized access due to deprovisioning failures, excessive permissions, MFA bypass, shared credentials
Change management	Unauthorized code changes, deployment failures, configuration drift, untested changes in production
Data protection	Unencrypted data exposure, data leakage through logging, improper data disposal, backup data exposure
Availability	Infrastructure failure, cloud provider outage, capacity exhaustion, single points of failure, DDoS
Vendor / third-party	Vendor data breach, vendor service disruption, supply chain compromise, API dependency failure
Regulatory / compliance	Non-compliance with contractual obligations, regulatory enforcement, audit failure, privacy violations
Physical	Data center failure, natural disaster affecting infrastructure, unauthorized physical access
Human error	Misconfiguration, accidental data deletion, incorrect deployment, operational mistakes
Fraud	Financial fraud, data manipulation, unauthorized transactions, social engineering

Risk Identification Methods

Method	How to Apply
Brainstorming workshop	Gather compliance, engineering, and operations leads for a structured risk identification session (two to three hours)
Prior incident review	Review past security incidents, near-misses, and audit findings for recurring risk themes
Industry threat intelligence	Review industry reports (OWASP, SANS, ENISA, Verizon DBIR) for common threats in your sector
Control gap analysis	Review SOC 2 gap assessment findings — each gap represents an unmitigated risk
Customer security questionnaire review	Review security questionnaire questions from customers for risk areas they care about
GRC platform risk module	Use your platform's built-in risk identification framework as a starting checklist

Step 3: Evaluate Each Risk

Apply the Scoring Framework

For each identified risk, assess likelihood and impact using your defined scales:

| Risk | Likelihood | Impact | Risk Score | Risk Level | |------|-----------|--------|-----------|-----------|
| Phishing attack compromises employee credentials | 4 (Likely) | 3 (Moderate) | 12 | High | | Cloud provider experiences extended outage | 2 (Unlikely) | 4 (Major) | 8 | Medium | | Employee access not deprovisioned after termination | 3 (Possible) | 3 (Moderate) | 9 | Medium | | Ransomware encrypts production data | 2 (Unlikely) | 5 (Critical) | 10 | High | | Code deployed without review introduces vulnerability | 3 (Possible) | 3 (Moderate) | 9 | Medium | | Unauthorized data access by internal employee | 2 (Unlikely) | 4 (Major) | 8 | Medium | | Vendor data breach exposes customer data | 2 (Unlikely) | 4 (Major) | 8 | Medium | | Backup restoration fails during disaster | 2 (Unlikely) | 5 (Critical) | 10 | High | | Customer data exposed through logging | 3 (Possible) | 3 (Moderate) | 9 | Medium | | Fraudulent modification of financial data | 1 (Rare) | 4 (Major) | 4 | Low |

Evaluation Best Practices

Practice	Why It Matters
Involve multiple perspectives	Engineering, operations, and compliance see different risks; cross-functional input produces a more complete assessment
Score based on current controls	Evaluate likelihood with current controls in place, not in a hypothetical zero-control environment
Use consistent scoring	Apply the same definitions consistently across all risks — avoid inflating or deflating scores
Document scoring rationale	For high and critical risks, document why you assigned specific likelihood and impact scores
Consider residual vs inherent risk	Inherent risk is risk without controls; residual risk is risk after controls. SOC 2 focuses on residual risk

Step 4: Select Risk Treatment

Treatment Options

Treatment	When to Use	Example
Mitigate	Implement controls to reduce likelihood or impact	Enforce MFA to reduce the likelihood of credential compromise
Accept	Risk is within risk appetite; cost of mitigation exceeds the risk	Accept the risk of a cloud provider outage for non-critical services with adequate DR
Transfer	Shift the risk to a third party	Purchase cyber insurance; use a managed security provider
Avoid	Eliminate the activity that creates the risk	Discontinue processing a data type that creates disproportionate risk

Treatment Decision Documentation

For each risk, we advise documenting:

| Field | Content | |-------|---------|
| Treatment decision | Mitigate, accept, transfer, or avoid | | Rationale | Why this treatment was selected | | Controls (if mitigate) | Specific controls that address this risk | | Owner | Who is responsible for implementing and maintaining the treatment | | Timeline | When the treatment will be fully implemented | | Residual risk | The risk level after treatment is applied |

Risk Acceptance Requirements

For risks that are accepted (not mitigated):

• Document the acceptance decision with rationale
• Obtain management approval for the acceptance (auditors verify this)
• Set a review date to reassess whether acceptance remains appropriate
• Record the accepted risk in the risk register with "Accepted" status

Step 5: Build and Maintain the Risk Register

Risk Register Structure

Field	Description
Risk ID	Unique identifier (e.g., RISK-001)
Risk description	Clear description of the threat, vulnerability, and potential impact
Category	Threat category (from Step 2)
Likelihood	Score from your likelihood scale
Impact	Score from your impact scale
Inherent risk score	Likelihood × Impact before controls
Controls	Existing controls that mitigate this risk
Treatment decision	Mitigate, accept, transfer, avoid
Residual risk score	Risk score after controls and treatment
Owner	Person responsible for the risk
Status	Open, mitigated, accepted, transferred
Last reviewed	Date of most recent review
Next review	Scheduled review date

Risk Register Example (Abbreviated)

ID	Risk	L	I	Score	Treatment	Controls	Owner	Status
R-001	Phishing compromises credentials	4	3	12	Mitigate	MFA, security training, email filtering	Security Lead	Mitigated
R-002	Access not deprovisioned	3	3	9	Mitigate	Automated deprovisioning, access reviews	IT Lead	Mitigated
R-003	Cloud provider extended outage	2	4	8	Accept + Transfer	Multi-region DR, cyber insurance	Engineering Lead	Accepted
R-004	Ransomware encrypts production	2	5	10	Mitigate	Backup/restore, endpoint protection, network segmentation	Security Lead	Mitigated
R-005	Code deployed without review	3	3	9	Mitigate	Branch protection, required reviewers	Engineering Lead	Mitigated

Risk Register Maintenance

Activity	Frequency	Who
Full risk assessment review	Annually	Compliance lead + cross-functional team
Risk register update	Quarterly (review existing risks for changes)	Compliance lead
New risk addition	As identified (incident-driven, change-driven)	Risk owner
Change-triggered reassessment	When significant changes occur	Compliance lead + affected teams
Management review	Annually (part of full assessment)	Executive sponsor

Step 6: Connect Risk Assessment to Controls

Risk-Control Mapping

The risk assessment should inform your control framework. Each significant risk should be linked to one or more controls that mitigate it:

Risk	Mitigating Controls	SOC 2 Criteria
Unauthorized access	MFA, access reviews, deprovisioning, RBAC	CC6.1, CC6.2, CC6.3
Code vulnerabilities	Code review, branch protection, SAST scanning	CC8.1, CC8.2
Data breach	Encryption, access controls, monitoring, incident response	CC6.1, CC6.7, CC7.2, CC7.3
Service unavailability	Redundancy, backup, DR testing, capacity monitoring	A1.1, A1.2, A1.3
Vendor compromise	Vendor risk assessment, contractual requirements, monitoring	CC9.2

This mapping demonstrates to the auditor that your controls are risk-informed — they exist because identified risks require mitigation, not because a checklist says they are needed.

Using GRC Platforms for Risk Assessment

Platform Risk Modules

GRC platforms like Vanta, Drata, Secureframe, and Sprinto include built-in risk assessment modules:

| Feature | What It Provides | |---------|-----------------|
| Risk assessment templates | Pre-built risk identification checklists aligned to SOC 2 criteria | | Scoring frameworks | Built-in likelihood and impact scales with automatic risk score calculation | | Risk register | Integrated risk register with status tracking and owner assignment | | Risk-control mapping | Connect risks to controls within the platform for automated tracking | | Review scheduling | Automated reminders for annual reviews and change-triggered reassessments | | Auditor access | Auditors can review the risk assessment and register directly in the platform |

Key Takeaways

• A formal, documented risk assessment is required for SOC 2 (CC3) — in our experience, it is one of the most commonly missed requirements for first-time organizations
• We recommend using a qualitative likelihood-impact matrix with five-point scales — this is the most practical approach for most organizations
• Document your methodology before conducting the assessment — the methodology document is auditor evidence
• We advise identifying risks across eleven categories: external cyber, internal threats, access management, change management, data protection, availability, vendor/third-party, regulatory, physical, human error, and fraud
• Evaluate each risk using consistent scoring; document scoring rationale for high and critical risks
• Select treatment for each risk (mitigate, accept, transfer, avoid) and document the decision with rationale
• Build a risk register with unique IDs, scores, treatment decisions, controls, owners, and review dates
• We always tell clients to connect risk assessment outputs to their control framework — controls should be traceable to the risks they mitigate
• Conduct the full assessment annually; review the risk register quarterly; reassess when significant changes occur
• Management must approve risk acceptance decisions — auditors verify this

Frequently Asked Questions

How detailed does the risk assessment need to be?

What we tell clients is: detailed enough to demonstrate a structured, repeatable process — but not so detailed that it becomes impractical to maintain. Most organizations we work with identify fifteen to thirty risks across the categories listed in this playbook. Each risk should have a clear description, consistent scoring, documented treatment, and an assigned owner. The auditor looks for evidence of a real process, not an exhaustive catalog of every conceivable risk.

Do we need to use a specific risk assessment framework?

The guidance we give is that SOC 2 does not prescribe a specific framework. The CC3 criteria require a risk assessment process but allow organizations to choose their methodology. The qualitative likelihood-impact matrix described in this playbook is the most commonly used approach across our client base. Some organizations use NIST SP 800-30, ISO 27005, or FAIR (Factor Analysis of Information Risk) for more structured methodologies. For most SOC 2 organizations, the qualitative approach is sufficient and practical.

Who should participate in the risk assessment?

Based on what we see produce the best outcomes, the risk assessment should involve cross-functional representation: compliance lead (facilitator), engineering lead (technical risk perspective), operations/IT (infrastructure and operational risks), and executive sponsor (business risk context and risk appetite). For organizations with dedicated security teams, the security lead should be a core participant. Involving multiple perspectives produces a more comprehensive risk identification and more realistic scoring.

What happens if we identify a critical risk with no mitigation?

The advice we give here is: document it transparently. Document the risk with its current score, note that no mitigation currently exists, and document a remediation plan with a timeline. The auditor may note this as a finding if the risk is within your SOC 2 scope and affects Trust Service Criteria. Critical unmitigated risks should be escalated to management with a clear remediation timeline. The goal is not to have zero risks — it is to have a documented, intentional approach to managing risks.