Risk Assessment Process for SOC 2 Compliance: A Step-by-Step Guide for SaaS Teams
There's a version of a SOC 2 risk assessment that lives in a spreadsheet, gets updated once a year, and exists mainly to satisfy auditors. Most SaaS companies have exactly that version.
Then there's a risk assessment that actually tells you something one that your engineering lead, your Head of Security, and your auditor all find useful. The kind that shapes real decisions about where to invest in controls and where your exposure actually lives.
This guide is for building the second kind.
We'll walk through the full risk assessment process for SOC 2 compliance, explain what auditors are actually looking at under CC3, and give you a practical step-by-step method that works whether you're a 15-person startup preparing for your first Type I or a 200-person company going through a Type II renewal.
What Is a SOC 2 Risk Assessment, and Why Does It Matter?
A SOC 2 risk assessment is a structured process of identifying threats to your systems, evaluating how likely those threats are to materialize, assessing the damage they could cause, and deciding what to do about them.
That sounds obvious. Here's the part that trips people up: under SOC 2, the risk assessment isn't just a document you hand the auditor. It's the foundation your entire control environment is supposed to be built on. Auditors reviewing CC3 — the Risk Assessment criteria within the Common Criteria — want to see that you didn't just pick controls arbitrarily. They want to see that you identified risks, analyzed them, and implemented controls specifically to address those risks.
If your controls and your risk assessment don't tell a consistent story, that's a finding.
So the risk assessment matters twice: once because it helps you prioritize security work, and again because it's what gives your control environment a defensible rationale in the eyes of an auditor.
What SOC 2 Actually Requires: A Quick Look at CC3
The AICPA's Trust Services Criteria organizes SOC 2 requirements into categories. CC3 covers risk assessment specifically. Here's what it requires, in plain language:
CC3.1 — The organization specifies its objectives clearly enough that risks to achieving those objectives can be identified and assessed.
CC3.2 — The organization identifies risks to achieving its objectives, analyzes those risks, and determines how they should be managed.
CC3.3 — The organization considers the potential for fraud in assessing risks (this includes unauthorized access, misuse of systems, and intentional misstatement of data).
CC3.4 — The organization identifies and assesses significant changes in the environment that could impact the system of internal controls.
What this means practically: you need a documented process, a risk register with identified and analyzed risks, evidence that you evaluated fraud-related risks, and a mechanism for updating your assessment when things change — new products, new infrastructure, new vendors, acquisitions.
That's the scope. Now let's build it.
Step 1: Define the Scope of Your Risk Assessment
Before you start listing threats, you need to draw a box around what you're assessing. This is called defining your scope, and it's the step most teams rush past — then regret later when their risk register doesn't match the scope of their SOC 2 audit.
Your SOC 2 scope should define:
The system boundary: Which applications, services, and infrastructure components are included? If your product runs on AWS and uses three third-party APIs that handle customer data, those need to be in scope.
The Trust Service Categories you're pursuing Security (CC) is mandatory. Availability, Confidentiality, Processing Integrity, and Privacy are optional. Your risk assessment needs to cover the categories you're reporting on.
The data you're protecting: What types of customer data does your system store, process, or transmit? Personal data, financial records, health information, API credentials?
Your organizational boundary: Which teams, departments, and locations are involved in operating the in-scope system?
Document this clearly. Your risk assessment should reference your defined scope explicitly. Auditors will check for consistency between your scoping decisions and the risks you've identified.
Step 2: Choose a Risk Assessment Methodology
You don't need to invent your own approach. SOC 2 doesn't mandate a specific methodology — but it does require that your methodology is documented, consistently applied, and reasonable.
Two widely used approaches work well for SaaS companies:
Qualitative risk assessment: Risks are rated using descriptive scales (High/Medium/Low, or 1–5) for likelihood and impact. Results in a risk matrix. Easier to run and communicate, well-suited to teams without dedicated security staff.
Quantitative risk assessment: Risks are rated using numerical estimates (e.g., annualized loss expectancy). More rigorous and defensible, but requires more data and expertise. Typically overkill for early-stage SOC 2 programs.
Most SaaS teams doing SOC 2 for the first time, or maintaining an annual program without a full security department, do well with a documented qualitative methodology. The important thing isn't the methodology you choose — it's that you define it, write it down, and apply it consistently.
Your methodology documentation should answer:
What rating scales do we use for likelihood and impact?
How do we combine likelihood and impact into an overall risk rating?
What risk tolerance thresholds trigger different response types?
Who is responsible for conducting and approving the assessment?
How often do we perform the assessment, and what triggers an ad-hoc refresh?
Document this before you start rating risks. If you define it as you go, auditors will notice the inconsistency.
Step 3: Identify Your Assets
You can't assess risk in the abstract. Risk is always risk to something — a system, a dataset, a process, a relationship. Before listing threats, list the things those threats are targeting.
For a SaaS company, your asset inventory typically includes:
Data assets — Customer data, user credentials, PII, financial records, audit logs, API keys, encryption keys, configuration secrets.
System assets — Production servers and cloud infrastructure, databases, internal tools, development and CI/CD pipelines, employee laptops and devices.
Process assets — Deployment processes, access provisioning and deprovisioning, backup and recovery procedures, incident response workflows.
Third-party dependencies — Cloud providers (AWS, GCP, Azure), identity providers, payment processors, monitoring tools, communication platforms, any sub-processors handling customer data.
You don't need a 300-row inventory for a first risk assessment. You need enough detail to make your threat identification meaningful. For most early-stage SaaS companies, 20–40 assets is a reasonable scope.
Assign an owner to each asset. When a risk is identified against that asset, ownership is clear.
Step 4: Identify Threats and Vulnerabilities
This is where most risk assessments get thin. Teams list "data breach" and "ransomware" and call it done. A useful risk assessment goes deeper.
A threat is something that could cause harm — an external attacker, a negligent employee, a failing hardware component, a regulatory change.
A vulnerability is a weakness that a threat could exploit — weak access controls, unpatched software, misconfigured cloud storage, lack of employee security training.
A risk is the combination: a specific threat exploiting a specific vulnerability against a specific asset.
To build a meaningful list, work through each asset category and ask:
Who or what could harm this? How could it happen? What weakness makes it possible?
Common threat categories for SaaS companies:
External threats:
Unauthorized access via credential theft or phishing
Application-layer attacks (SQL injection, SSRF, API abuse)
DDoS attacks targeting availability
Supply chain compromise via third-party software or dependencies
Ransomware targeting infrastructure
Internal threats:
Accidental data exposure (misconfigured S3 buckets, shared credentials)
Insider misuse of access privileges
Errors in deployment causing data corruption or outages
Inadequate access revocation for departed employees
Environmental and operational threats:
Cloud provider outages affecting availability
Key person dependency (single engineer with undocumented admin access)
Failure of backup and recovery processes
Changes in regulation affecting data handling obligations
Don't forget CC3.3 — fraud risks. This includes things like: an employee deliberately exfiltrating customer data, unauthorized privilege escalation, or someone manipulating audit logs. These risks feel uncomfortable to document, but auditors expect to see them considered.
Step 5: Analyze and Rate Each Risk
With your asset list and threat/vulnerability pairs in hand, it's time to rate each identified risk. You're evaluating two dimensions:
Likelihood — How probable is it that this threat successfully exploits this vulnerability in your environment, given your current controls?
Impact — If it happened, how severe would the consequences be? Consider: data loss, customer impact, regulatory exposure, reputational damage, financial cost.
For a qualitative assessment, a 1–5 scale for each dimension works well:
Rating
Likelihood
Impact
1
Rare — no known cases, strong controls in place
Negligible — no meaningful harm
2
Unlikely — possible but improbable
Minor — limited customer or data impact
3
Possible — realistic given your environment
Moderate — meaningful but recoverable
4
Likely — has happened or is common in similar companies
Significant — substantial data, financial, or reputational damage
5
Almost certain — current controls are clearly insufficient
Severe — potential regulatory action, data loss at scale, business disruption
Multiply (or plot on a matrix) to get an inherent risk score before controls, and a residual risk score after accounting for your existing controls.
The gap between inherent and residual risk tells you how much your controls are actually doing. A high inherent risk that remains high residual risk is where your attention — and your remediation roadmap — should focus.
Step 6: Determine Your Risk Response
For each risk on your register, you need to document a decision. SOC 2 doesn't require you to eliminate all risk. It requires you to manage it intentionally.
There are four standard responses:
· Mitigate — Implement or strengthen controls to reduce the likelihood or impact. This is the most common response. Example: enforce MFA to mitigate credential theft risk.
· Accept — Acknowledge the risk and decide it's within your tolerance, typically because the cost of mitigation outweighs the residual exposure. Document why. Accepted risks with no rationale are a red flag for auditors.
· Transfer — Shift the financial impact of the risk elsewhere, usually through cyber insurance or contractual indemnification. Note: transferring risk doesn't eliminate it.
· Avoid — Change the activity that creates the risk. Example: stop storing certain data you don't need, eliminating the associated breach risk.
Each risk in your register should have a documented response, an owner, and — for risks being mitigated — a linked control or remediation action with a target date.
Step 7: Build and Maintain Your Risk Register
Your risk register is the living artifact of your risk assessment. It's what the auditor reviews. Here's what it needs to contain:
Risk ID (for easy reference)
Asset(s) affected
Threat description
Vulnerability exploited
Inherent likelihood rating
Inherent impact rating
Inherent risk score
Existing controls
Residual likelihood rating
Residual impact rating
Residual risk score
Risk response decision (mitigate / accept / transfer / avoid)
Control or action linked to response
Risk owner
Last reviewed date
Keep this in a system that can be updated continuously, not a spreadsheet emailed around annually. Managing a risk register in spreadsheets often leads to outdated information, version control issues, and limited visibility into risk ownership and remediation progress. This is why many SaaS teams adopt compliance platforms that centralize the risk register, link risks directly to controls, and track remediation status continuously.
Platforms like CalVant support this approach by helping teams maintain an up-to-date, audit-ready risk register without manual overhead.
Step 8: Map Risks to Controls
Here's where the risk assessment earns its place in your compliance program. Each mitigated risk should map to one or more controls in your control environment. And each control should trace back to one or more risks it addresses.
This bidirectional mapping — risk to control, control to risk — is what allows you to walk an auditor through your control environment and explain not just what you do, but why. It's also what prevents you from maintaining controls that address no meaningful risk (wasted effort) and from having risks with no mitigating controls (exposure).
For each risk, document:
Which control(s) address this risk?
Does the control reduce likelihood, impact, or both?
What evidence demonstrates the control is operating effectively?
This mapping becomes the spine of your SOC 2 audit package.
Step 9: Review and Update the Assessment
SOC 2 requires that your risk assessment isn't a point-in-time exercise. CC3.4 specifically requires you to identify significant changes and assess their impact on the control environment.
Practically, this means two things:
Annual full reassessment — At least once per year, review every risk in your register. Update ratings if your environment has changed. Add new risks introduced by product changes, new vendors, or new attack patterns. Remove or archive risks that are no longer relevant.
Event-driven updates — Certain triggers should prompt an immediate review of affected risks:
Launching a new product or feature that handles customer data differently
Onboarding a new third-party vendor who will process in-scope data
A security incident, even a minor one
Significant infrastructure changes (migrating to a new cloud provider, re-architecting your data model)
Changes in the regulatory environment affecting your customers
Document these reviews with a date, the scope of what was reviewed, what changed, and who approved the update.
Step
Activity
1
Define scope of risk assessment
2
Select appropriate risk assessment method
3
Identify information assets
4
Identify threats and vulnerabilities
5
Analyze and evaluate risks
6
Determine risk treatment/response
7
Maintain and update the risk register
8
Map identified risks to applicable controls
9
Review and update on a regular basis
What Auditors Are Actually Looking For
Beyond checking boxes, here's the substance of what a SOC 2 auditor wants to see when they review your risk assessment under CC3:
· Completeness — Does your risk register reflect the actual threats your system faces, or does it feel like a generic template? Auditors who see the same 12 risks in every SaaS company's register start asking questions.
· Consistency — Does your methodology match how risks are actually rated? Inconsistent ratings with no rationale suggest the register was filled in quickly rather than thoughtfully.
· Linkage — Are your controls connected to identified risks? If your control environment addresses things not in your risk register, or if significant risks have no mitigating controls, that's a gap.
· Currency — Is the assessment recent? Has it been updated since your last major product change or vendor addition?
· Ownership — Is it clear who owns each risk and who is responsible for the associated controls?
· Fraud consideration — Even one or two fraud-related risks, rated and addressed, satisfy CC3.3. The absence of any fraud-related risks looks like an oversight.
Building a Risk Assessment That Lasts
The goal isn't to pass one audit. The goal is a risk management practice that actually serves your company — that helps you make informed decisions about security investments, that keeps your team aligned on your biggest exposures, and that makes each subsequent audit faster and less stressful than the last.
That means:
A risk register that lives in your compliance platform, not a shared drive
Owners who know they own their risks
A quarterly cadence of risk reviews, even brief ones, so the annual assessment isn't a scramble
Controls that are linked to risks and continuously monitored for effectiveness
When you get this right, the risk assessment stops being a compliance tax and starts being a useful tool. Your security roadmap comes from the register. Your audit prep time drops because your evidence is already mapped. Your team has a shared language for talking about where the company is exposed.
That's the version worth building.
If you're building or maturing your SOC 2 risk assessment process, adopting a structured platform like CalVant can help you maintain a live, audit-ready risk register and significantly reduce manual effort.
Frequently Asked Questions
How often should we update our SOC 2 risk assessment?
At minimum, once per year — with a full review of all risks, ratings, and associated controls. You should also update it whenever a significant change occurs: a new major product feature, a new third-party vendor handling sensitive data, a security incident, or significant infrastructure changes. CC3.4 requires you to assess the impact of changes on your control environment.
Do we need a dedicated risk management team to do SOC 2 risk assessments?
No. Many early-stage SaaS companies complete thorough risk assessments with just a security lead and input from engineering and product. What matters is that the process is documented, consistently applied, and reviewed by appropriate stakeholders. A compliance platform can significantly reduce the overhead.
What's the difference between inherent risk and residual risk in SOC 2?
Inherent risk is the level of risk before any controls are in place — the raw exposure. Residual risk is what remains after your controls are applied. SOC 2 auditors want to see that your residual risks are within your stated risk tolerance, and that high residual risks have documented response plans.
Can we use a risk assessment template for SOC 2?
Yes, templates are a reasonable starting point. The important thing is that you customize the template to reflect your actual environment — your specific assets, your real threats, your existing controls. A generic template submitted unchanged will not satisfy an auditor reviewing CC3 in depth.
What happens if our risk assessment has gaps during a SOC 2 audit?
Gaps in the risk assessment — missing risk categories, risks with no linked controls, a register that hasn't been updated in over a year — will typically result in exceptions or observations in your audit report. Material gaps in CC3 can affect the overall opinion. Address gaps before your audit window, not after.
Does Calvant help with SOC 2 risk assessments?
Yes. Calvant provides a structured risk register, pre-mapped controls aligned to SOC 2 Trust Services Criteria, and continuous monitoring so your risk assessment stays current.
Want to stop managing your SOC 2 risk assessment in spreadsheets?
Top comments (0)