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

Published February 24, 2026· Updated November 1, 2026·11 min read

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.

Key Takeaways

•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

For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.

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

What Auditors Expect from Your Risk Assessment? — comparison
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	Depends on scope and readiness
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

What Auditors Expect from Your Risk Assessment? — comparison
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
Depends on scope and readiness	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.

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

Step 1: Define Your Risk Assessment Methodology — comparison
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:

Step 2: Identify Threats and Vulnerabilities — comparison
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

Step 2: Identify Threats and Vulnerabilities — comparison
Method	How to Apply
Brainstorming workshop	Depends on scope and readiness
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

Step 3: Evaluate Each Risk — comparison
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

Step 4: Select Risk Treatment — comparison
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

Step 5: Build and Maintain the Risk Register — comparison
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)

Step 5: Build and Maintain the Risk Register — comparison
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

Step 5: Build and Maintain the Risk Register — comparison
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:

Step 6: Connect Risk Assessment to Controls — comparison
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 |

AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.

Frequently Asked Questions

What do auditors expect from a SOC 2 risk assessment?

A documented methodology, evidence it was performed during the period, risks scored consistently, treatment decisions with rationale, and a register that is maintained rather than produced once. It is one of the most commonly missed requirements.

How do you structure risk identification for SOC 2?

Work across categories rather than brainstorming freely: threats to systems and data, vendor and third-party risk, personnel risk, and business continuity. Structuring it this way keeps coverage consistent year over year.

Tyler Carbone

Managing Director and Cofounder

Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.