Most companies preparing for SOC 2 compliance rush straight to implementing controls. They set up MFA, configure logging, write policies, and think they're making progress.

Then their auditor asks: "Can I see your risk assessment?"

Silence.

Here's the thing: Risk assessment isn't just another checkbox on your SOC 2 to-do list. It's the foundation that everything else builds on. Your auditor needs to see that you've systematically identified what could go wrong, evaluated how bad it would be, and made conscious decisions about how to address each risk.

Skip this step or do it poorly, and you'll face audit findings even if your technical controls are solid. Do it well, and you'll have a clear roadmap for exactly which controls matter most for your specific situation.

This guide walks you through how to conduct a SOC 2 risk assessment that will satisfy auditors while actually helping you build a better security program.

What is a SOC 2 Risk Assessment?

A SOC 2 risk assessment is your systematic process for identifying and evaluating security risks to the systems and data within your SOC 2 scope. It's how you figure out what could go wrong, how likely it is to happen, and how bad it would be if it did.

But here's what makes it different from a generic IT risk assessment: SOC 2 risk assessments are specifically focused on risks to the Trust Services Criteria. You're not just looking at IT risks in general—you're evaluating risks that could prevent you from meeting your commitments around Security, Availability, Processing Integrity, Confidentiality, and Privacy.

The Role in SOC 2 Compliance

Risk assessment directly supports three critical Trust Services Criteria:

CC3.1 - Risk Identification: The entity identifies risks that could affect its ability to meet its objectives.

CC3.2 - Risk Analysis: The entity analyzes identified risks to estimate their significance.

CC3.3 - Risk Mitigation: The entity responds to analyzed risks.

Your auditor will specifically look for evidence that you've done all three. They want to see that you didn't just copy-paste a risk register from somewhere—you actually thought through your specific systems, threats, and circumstances.

When to Conduct Your Risk Assessment

The short answer: Before you start implementing controls.

The slightly longer answer: You should complete your initial risk assessment within the first month of your SOC 2 preparation. This assessment informs which controls you need to implement. Then you update it at least annually, and whenever there are significant changes to your systems or business.

For companies following a 90-day preparation timeline, risk assessment should happen in weeks 1-2. For those on a longer timeline, complete it within the first quarter.

Risk Assessment Framework

Before you start identifying risks, you need a consistent framework for evaluating them. Here's the approach that works well for most SaaS companies pursuing SOC 2.

Asset Identification

You can't assess risks to things you don't know about. Start by cataloging:

Systems in Scope

• Production application servers
• Databases
• Authentication systems
• CI/CD pipeline components
• Monitoring and logging systems
• Customer-facing applications
• Admin interfaces

Data Assets

• Customer data (PII, credentials, usage data)
• Application data
• System configuration data
• Authentication credentials
• Encryption keys
• Backup data

Processes and Services

• Software development lifecycle
• Deployment processes
• Access provisioning/deprovisioning
• Incident response procedures
• Change management
• Backup and recovery

Don't try to document every single thing. Focus on assets that are either in your SOC 2 scope or directly support your scoped systems.

Threat Identification

For each asset category, consider who or what might threaten it:

External Threat Actors

• Malicious hackers attempting unauthorized access
• Automated attacks (bots, scanners, DDoS)
• Social engineering attempts
• Supply chain attacks through vendors
• Ransomware operators

Internal Threats

• Malicious insiders (disgruntled employees)
• Accidental data exposure by employees
• Misconfigured systems
• Insufficient access controls
• Inadequate security awareness

Environmental and Operational Threats

• Infrastructure failures
• Cloud provider outages
• Network connectivity issues
• Natural disasters affecting availability
• Capacity limitations during high load

Vulnerability Identification

Vulnerabilities are weaknesses that threats could exploit. Common categories:

• Unpatched software with known vulnerabilities
• Weak authentication mechanisms
• Overly permissive access controls
• Insufficient logging and monitoring
• Lack of data encryption
• Inadequate backup procedures
• Missing incident response capabilities
• Poor change management practices

Risk Scoring Methodology

Once you've identified potential risks, you need to evaluate them consistently. Most companies use a simple likelihood × impact matrix.

Likelihood Scale (1-5)

• 1 = Rare (< 5% chance in next year)
• 2 = Unlikely (5-25% chance)
• 3 = Possible (25-50% chance)
• 4 = Likely (50-75% chance)
• 5 = Almost Certain (> 75% chance)

Impact Scale (1-5)

• 1 = Negligible (minor inconvenience)
• 2 = Minor (limited operational impact)
• 3 = Moderate (significant operational impact)
• 4 = Major (severe operational or financial impact)
• 5 = Catastrophic (existential threat to business)

Risk Score = Likelihood × Impact

This gives you scores from 1 to 25. Most companies set thresholds like:

• 1-6: Low risk (accept or monitor)
• 7-14: Medium risk (mitigate within next quarter)
• 15-25: High risk (mitigate immediately)

Here's a sample risk scoring matrix:

Risk Appetite and Tolerance

Risk appetite is how much risk your organization is willing to accept in pursuit of its objectives. Risk tolerance is the specific level of variation you'll accept around objectives.

For most bootstrap SaaS companies, a reasonable approach is:

• Low/Medium risks: Generally acceptable with monitoring
• High risks: Require mitigation before audit
• Critical systems: Lower tolerance (treat medium risks as high)
• Non-critical systems: Higher tolerance (some medium risks acceptable)

Document this explicitly. Your auditor wants to see that leadership has made conscious decisions about risk acceptance, not just technical teams making calls in isolation.

Step-by-Step Risk Assessment Process

Now let's walk through how to actually conduct the assessment.

Step 1: Define Your Scope

Before identifying risks, be crystal clear about what's in scope for your SOC 2 assessment. This defines the boundaries for your risk assessment.

Questions to Answer:

• Which systems and applications are in scope?
• Which types of customer data are covered?
• Are you pursuing Security only, or additional criteria?
• What's explicitly out of scope?

For example: "Our SOC 2 scope covers our production SaaS application, the AWS infrastructure it runs on, and our customer data processing. It includes Security and Availability criteria. Out of scope: our internal HR system, our marketing website, and our corporate network."

Write this down. It's the first thing in your risk assessment documentation.

Step 2: Create Your Asset Inventory

For each asset category (systems, data, processes), create a simple inventory. A spreadsheet works fine for most companies.

Example System Inventory:

• Production API servers: AWS EC2 instances running application code, processes customer requests
• PostgreSQL database: AWS RDS instance, stores all customer data including PII
• Authentication service: Auth0, handles user authentication and MFA
• Monitoring platform: Datadog, collects logs and metrics from all production systems
• CI/CD pipeline: GitHub Actions, deploys code to production

For each asset, note:

• What it is
• What it does
• What data it processes or stores
• Who has access to it
• Where it's located (cloud, on-prem, SaaS vendor)

You don't need exhaustive detail. Just enough that someone unfamiliar with your systems could understand what you're protecting.

Step 3: Conduct a Threat Modeling Workshop

This is where you gather your team and brainstorm what could go wrong. Include:

• Engineering leads who understand the systems
• Security team members (if you have them)
• Operations/DevOps team
• Someone from leadership who understands business impact

For each major system or process, ask:

• Who might want to attack this? (Threat actors)
• How could they attack it? (Attack vectors)
• What weaknesses could they exploit? (Vulnerabilities)
• What would happen if they succeeded? (Impact)

Let's walk through an example: Your production database.

Threat: External attacker gains unauthorized access to production database Vulnerabilities:

• Database accessible from internet (if misconfigured)
• Weak database credentials
• Unpatched database software
• Application vulnerable to SQL injection

Impact: Complete exposure of all customer data, violation of privacy commitments, potential breach notification requirements, loss of customer trust

Likelihood: Depends on your controls

• With strong controls (network isolation, strong credentials, patching, secure coding): Unlikely (2)
• Without these controls: Likely (4)

Document 10-20 key risk scenarios. Don't try to document every theoretical possibility—focus on risks that could realistically impact your ability to meet SOC 2 criteria.

Step 4: Perform Control Gap Analysis

For each identified risk, evaluate your current controls:

Do you have controls to prevent this risk?

• Technical controls (MFA, encryption, network segmentation)
• Administrative controls (policies, procedures, training)
• Physical controls (if relevant)

Are those controls operating effectively?

• Are they actually implemented and working?
• Are people following procedures?
• Do you have evidence they're effective?

What's the residual risk after controls?

• Even with controls, some risk remains
• Score the risk assuming controls work as intended

Let's continue our database example:

Current Controls:

• Database in private subnet, not internet accessible ✓
• Strong credentials, managed via secrets manager ✓
• Automated patching enabled ✓
• Code review process for SQL queries ✓
• Web application firewall in place ✓

Residual Risk: With these controls, likelihood drops to Unlikely (2). Impact remains Major (4). Risk score: 8 (Medium).

Step 5: Risk Prioritization

Now you have a list of risks with scores. Prioritize them:

High Risks (Score 15-25) Must be addressed before your audit. These are deal-breakers. Either implement controls to reduce the risk, or if you choose to accept it, get explicit leadership approval with documentation.

Medium Risks (Score 7-14) Should be addressed, but you have more flexibility on timing. For SOC 2 Type I, you might get away with having a treatment plan even if controls aren't fully implemented. For Type II, you'll need controls operating throughout the observation period.

Low Risks (Score 1-6) Can generally be accepted with monitoring. Document why you're accepting them and how you'll monitor for changes.

Create a prioritized list that drives your control implementation. The risks at the top of this list should directly inform which security tools and controls you implement first.

Step 6: Develop Treatment Plans

For each risk requiring mitigation, document your treatment plan:

Risk Treatment Options:

Avoid: Eliminate the risk by not doing the risky activity

• Example: Don't store credit card data, use Stripe instead
• Completely removes the risk but might limit functionality

Mitigate: Implement controls to reduce likelihood or impact

• Most common approach for SOC 2
• Example: Add MFA to reduce likelihood of unauthorized access

Transfer: Shift the risk to a third party

• Example: Use AWS for infrastructure, they handle physical security
• Risk doesn't disappear, but responsibility shifts

Accept: Consciously decide to live with the risk

• Appropriate for low risks
• Must be documented with leadership approval

For each high or medium risk, document:

• Which treatment option you're choosing
• Specific controls you'll implement
• Timeline for implementation
• Who's responsible
• How you'll verify effectiveness

Example Treatment Plan:

Risk: Unauthorized access to production systems via compromised admin credentials
Score: 16 (High)
Treatment: Mitigate
Controls to Implement:

• Deploy MFA for all admin access (2 weeks)
• Implement privileged access management (4 weeks)
• Deploy session recording for admin activities (6 weeks)
• Conduct quarterly access reviews (ongoing)

Owner: DevOps Lead
Target Completion: 6 weeks
Verification: MFA logs, PAM audit trail, recorded sessions

Common Risk Scenarios for SaaS Companies

Here are the risk scenarios we see most frequently in SOC 2 audits, along with typical controls:

Unauthorized Access to Customer Data

Scenario: Attacker gains access to production systems or databases containing customer information.

Common Vulnerabilities:

• Weak or default passwords
• No MFA on privileged accounts
• Overly broad access permissions
• Lack of network segmentation

Typical Controls:

• MFA required for all production access
• Role-based access control (RBAC)
• Network segmentation between environments
• VPN required for remote access
• Regular access reviews
• Strong password policies

Residual Risk: Medium (with controls), High (without)

Data Breach Through Application Vulnerability

Scenario: Attacker exploits vulnerability in your application to extract customer data.

Common Vulnerabilities:

• SQL injection vulnerabilities
• Cross-site scripting (XSS)
• Insecure API endpoints
• Unpatched application dependencies
• Insufficient input validation

Typical Controls:

• Secure coding practices
• Regular security code reviews
• Automated vulnerability scanning
• Web application firewall (WAF)
• Penetration testing
• Bug bounty program

Residual Risk: Medium (with controls), High (without)

Prolonged Service Outage

Scenario: Critical system failure causes extended downtime affecting customer operations.

Common Vulnerabilities:

• Single points of failure
• Inadequate monitoring
• No failover capabilities
• Insufficient capacity planning
• Poor incident response procedures

Typical Controls:

• Redundant infrastructure
• Load balancing
• Auto-scaling configured
• Comprehensive monitoring and alerting
• Incident response procedures tested
• Regular disaster recovery drills

Residual Risk: Low to Medium (with controls), High (without)

Third-Party Vendor Compromise

Scenario: Security incident at a critical vendor impacts your systems or customer data.

Common Vulnerabilities:

• No vendor security assessments
• Excessive vendor access
• Lack of vendor monitoring
• No contingency plans for vendor failures

Typical Controls:

• Vendor security assessment process
• SOC 2 reports required from critical vendors
• Principle of least privilege for vendor access
• Contractual security requirements
• Regular vendor reviews
• Vendor contingency planning

Residual Risk: Medium (with controls), High (without)

Insider Threat (Malicious or Accidental)

Scenario: Employee or contractor deliberately or accidentally exposes, deletes, or modifies customer data.

Common Vulnerabilities:

• Excessive user permissions
• No separation of duties
• Insufficient logging
• Lack of background checks
• Poor security awareness

Typical Controls:

• Background checks for employees with access to customer data
• Principle of least privilege
• Separation of duties for critical operations
• Comprehensive logging and monitoring
• Regular security awareness training
• Data loss prevention tools
• Prompt access removal upon termination

Residual Risk: Low to Medium (with controls), Medium to High (without)

Change Management Failure

Scenario: Unauthorized or poorly tested change causes security incident or major outage.

Common Vulnerabilities:

• No formal change approval process
• Changes deployed directly to production
• Insufficient testing procedures
• No rollback plans
• Lack of change documentation

Typical Controls:

• Formal change request and approval process
• Separate development, staging, and production environments
• Required testing before production deployment
• Documented rollback procedures
• Change advisory board for high-risk changes
• Post-implementation review

Residual Risk: Low (with controls), High (without)

Here's how these risks typically map to controls and evidence:

Documentation Requirements

Your auditor will want to see specific documentation for your risk assessment:

Risk Register

This is your master document listing all identified risks. Include:

• Risk description
• Asset/system affected
• Threat source
• Vulnerability exploited
• Likelihood score
• Impact score
• Overall risk score
• Current controls
• Residual risk (after controls)
• Treatment plan
• Owner
• Status

A spreadsheet works fine. Most companies maintain this in Google Sheets or Excel.

Risk Assessment Report

A written document (typically 5-15 pages) that includes:

• Executive summary of key findings
• Methodology used
• Scope of assessment
• Assets identified
• Key risks identified
• Risk scoring approach
• Treatment recommendations
• Timeline for implementation

This doesn't need to be a formal report. A well-organized Google Doc is sufficient for most SOC 2 audits.

Treatment Plan Documentation

For each risk requiring treatment, document:

• What controls you're implementing
• Implementation timeline
• Resource requirements
• Success criteria
• Verification method

Review and Update Frequency

Document your process for keeping the risk assessment current:

• Annual review: Full risk assessment refresh
• Quarterly reviews: Check for new risks, update scores
• Trigger-based reviews: Significant system changes, security incidents, new regulations

Your auditor wants evidence that risk assessment is ongoing, not just a one-time exercise before your audit.

Tools and Templates

You don't need expensive software for SOC 2 risk assessment. Here's what actually works:

Spreadsheet-Based Approaches

Pros:

• Free or cheap (Google Sheets, Excel)
• Flexible and customizable
• Easy to share and collaborate
• Sufficient for most audits

Cons:

• Manual effort to maintain
• Can get messy with many risks
• No automated workflow

Best for: Companies under 50 employees, first SOC 2 audit, limited budget.

Risk Management Software

Options:

• GRC platforms (Vanta, Drata, Secureframe) include risk assessment modules
• Dedicated risk tools (RiskWatch, SimpleRisk)
• Project management tools (Jira, Asana) can be configured for risk tracking

Pros:

• Structured workflow
• Automated reminders
• Better for tracking over time
• Integration with other compliance activities

Cons:

• Costly ($10k-40k/year for GRC platforms)
• May be overkill for small companies
• Learning curve

Best for: Companies over 100 employees, complex environments, budget for tools.

Our Risk Management Policy Template

If you're starting from scratch, our Risk Management Policy template provides:

• Pre-written policy covering risk assessment requirements
• Risk register template
• Treatment plan framework
• Review schedule template

It's based on actual policies that have passed SOC 2 audits, not theoretical compliance documentation. You customize it for your specific environment and you're good to go.

For companies that want everything in one place, the Complete Bundle includes the Risk Management Policy plus all the other policies and documentation you need for SOC 2 compliance.

Conclusion

Risk assessment isn't the most exciting part of SOC 2 preparation, but it might be the most important. Do it well, and you'll have a clear roadmap for which controls matter most. You'll be able to explain to your auditor why you prioritized certain controls over others. You'll pass your audit with fewer findings.

Do it poorly or skip it entirely, and you'll face audit exceptions even if your technical controls are solid.

The key points to remember:

Start early: Complete your initial risk assessment before implementing controls. It should inform what you build, not justify what you've already built.

Be systematic: Use a consistent framework for identifying assets, threats, vulnerabilities, and impacts. Document your methodology.

Think like your auditor: They want to see that you've genuinely thought through your risks, not just filled out a template. Include specific examples relevant to your systems.

Make it ongoing: Risk assessment isn't a one-time event. Plan for annual reviews and updates when systems change significantly.

Connect to controls: Every significant risk should map to specific controls. If you identify a high risk with no controls, your auditor will flag it.

Most importantly, remember that risk assessment is ongoing, not a one-time project. Your systems change, threats evolve, and your business grows. Plan to revisit your risk assessment at least annually, and update it whenever significant changes occur.

Want to get started quickly? Our risk assessment templates provide the structure you need while letting you focus on the actual analysis rather than building frameworks from scratch.

Ready to tackle the next step in your SOC 2 preparation? Check out our guide on implementing change management processes - one of the controls that addresses multiple risks you've identified.