Your Guide to the SOC 2 Risk Assessment Template

A SOC 2 risk assessment is a formal, documented process an entity uses to identify, analyze, and evaluate potential risks that could threaten the achievement of its service commitments and system requirements as defined by the AICPA’s Trust Services Criteria. This process is a foundational requirement for the Security principle, directly addressing criteria like CC3.1, which mandates that the entity identify risks to its objectives, and CC3.2, which requires the analysis and evaluation of those risks.

See where you stand first. A documented risk assessment is one of the controls our SOC 2 readiness assessment scores from your auditor’s chair. Take the 90-second check to see whether yours would pass or land as an exception.

Understanding the Purpose of a SOC 2 Risk Assessment

The risk assessment is not an optional exercise. It is the primary evidence an auditor uses to verify that your security controls are relevant and purposefully designed, and it documents why you chose each control. Without one, you cannot prove that your controls address specific, identified threats to the system, which makes it nearly impossible to satisfy the core requirements of the Security principle. Our guide to what evidence a SOC 2 auditor asks for shows where the risk assessment fits among the rest.

The risk assessment answers the auditor’s fundamental question: “How did you decide which security controls to implement?” It gives a documented answer showing that your controls follow from an analysis of threats, not an arbitrary checklist, and it connects your operational environment to the control requirements in the SOC 2 framework.

Key Components in a SOC 2 Context

An auditor expects to see risk broken down into its core components:

• Threats: Potential events, whether internal (e.g., employee error) or external (e.g., cyberattack), that could adversely affect the achievement of your SOC 2 objectives.
• Vulnerabilities: Weaknesses in information systems, security procedures, internal controls, or implementation that could be exploited by a threat source. For example, an unpatched server or an inconsistent employee offboarding process.
• Impact: The potential negative consequences to the business if a threat exploits a vulnerability. In a SOC 2 context, this must be measured against your ability to meet service commitments related to security, availability, processing integrity, confidentiality, and privacy.
• Likelihood: The probability that a given threat will exploit a particular vulnerability.

The goal of a SOC 2 risk assessment is to demonstrate a mature, repeatable process. An auditor wants to see a clear, logical line connecting an identified risk (e.g., an insider threat), your analysis of its potential impact on a Trust Service Criterion (e.g., Availability), and the specific control you have in place to mitigate it (e.g., role-based access control). For more on the criteria your controls must satisfy, see the SOC 2 Trust Services Criteria.

The risk assessment is the documented record that your security measures respond to specific threats to the service commitments you make to your customers. An auditor will request it early in the engagement, and its quality tends to set the tone for the audit.

How to Build Your Risk Register

The risk register is the central artifact for your SOC 2 risk assessment. It is the living document that provides auditors with tangible proof that you have a formal process for identifying, analyzing, and treating risks to your systems and data. It is a structured log that must detail each risk, its potential impact and likelihood, the controls in place to mitigate it, and the planned response.

The risk register is the primary evidence examined to test compliance with the CC3.0 series (Risk Assessment) of the Common Criteria. An incomplete or poorly constructed risk register is a common cause of audit findings. Build it collaboratively so it reflects the organization’s actual risks, because auditors will often interview personnel from different departments to validate its contents.

Facilitating Collaborative Risk Workshops

Involve people from across the organization. Engineering, IT, operations, product development, HR, and legal each see different threats and vulnerabilities. A risk identified by an engineer (e.g., a vulnerable open-source library) counts as much for SOC 2 as one identified by HR (e.g., inconsistent access removal during employee termination).

Guide these workshops with specific questions tied to SOC 2 objectives:

• Incident Post-Mortems: “Reviewing our last service outage, what was the root cause? What control weaknesses were exposed that could impact our Availability commitments?”
• System Architecture Review: “Looking at our data flow diagram, where is sensitive customer data stored, processed, and transmitted? What are the specific threats to its Confidentiality at each point?”
• New Feature Launches: “For the upcoming product release, what new third-party services are being integrated? What are the vendor risks to our Security and Availability criteria?”
• Process Mapping: “Walk me through the employee offboarding process. At what specific points could a former employee retain access, violating our controls for CC6.3 (Access Removal)?”

The outputs from these workshops form the basis of your risk register. The workflow below turns them into a structured assessment that auditors can follow.

The steps: identify a potential threat to a service commitment, analyze its potential impact and likelihood, and then evaluate the controls you have in place to mitigate it.

Scoring Risk with a Likelihood and Impact Matrix

Once you have identified a list of risks, you must analyze and prioritize them using a consistent, defensible methodology. A risk matrix is the standard tool for this. Auditors will test whether your risk analysis process is systematic and repeatable, and a matrix gives objective criteria for scoring risks by their likelihood and potential impact, which replaces subjective opinion with scores.

Your matrix must be tailored to your business and its SOC 2 objectives. For a SaaS company, “impact” should be defined in terms of financial loss, reputational damage, operational downtime, and regulatory penalties related to failing service commitments. A common 5x5 matrix provides sufficient granularity for most organizations.

Here is a sample matrix you can adapt. It gives you a structured way to assign scores and a common language for evaluating threats.

Sample Risk Likelihood and Impact Matrix

A well-defined risk matrix limits subjectivity during an audit. It forces a structured conversation where a risk like ‘unauthorized access to a production database’ is clearly and objectively scored as having a catastrophic impact on the Confidentiality criterion, while a ‘minor cross-site scripting vulnerability’ might land at a low or moderate impact.

Understanding the real-world costs and timelines for a SOC 2 audit can help you define these impact levels. A typical audit can take two months for a prepared company but can easily stretch to 6 or even 12 months if you’re starting from scratch. In 2026, auditor fees for a Type I engagement typically run $15,000 to $60,000 depending on company size and scope, while Type II fees range from $20,000 to $85,000 for most SaaS companies working with specialized or mid-tier CPA firms. When you factor in compliance platform subscriptions, readiness consulting, and penetration testing, the total first-year investment for a Type II audit commonly lands between $35,000 and $130,000. These numbers give you a tangible basis for scoring financial impact and justifying the resources needed to address high-priority risks.

Articulating Risk with Clarity

A vague entry like “Poor Security” is unauditable and will be rejected. Every risk statement must be specific, clearly defining the cause, the event, and the consequence in relation to your service commitments.

A strong risk statement follows this formula: [Threat Source] could exploit [Vulnerability], resulting in [Impact/Consequence on SOC 2 Objective].

Compare:

• Poor Example: “Server failure.”
• Good Example: “An external power grid failure could exploit our single-homed data center connection, resulting in a multi-hour service outage and violating our customer SLA for the Availability criterion.”

This level of detail connects a potential threat directly to a SOC 2 objective, which is what auditors test. Your risk register is the primary evidence that you are systematically managing threats to your service commitments.

Mapping Risks to Controls and the TSC

A risk register is only a list of potential problems until you map each risk to the control(s) designed to mitigate it. The mapping is the core of your audit evidence: it shows an auditor that your security program is a deliberate, documented response to known threats and not a collection of unrelated activities.

Without this explicit link, an auditor cannot validate your risk mitigation strategy. They need to see the direct connection between an identified risk, your internal control, and the corresponding Trust Services Criteria (TSC) to complete their testing procedures.

Connecting Risks to Practical Controls

Show a defense-in-depth approach where a single high-impact risk is addressed by multiple controls. Your SOC 2 risk assessment template must have dedicated columns for “Control ID” and “Control Description” to document this mapping clearly.

Consider this common risk for a SaaS company:

• Risk Statement: A malicious actor could exploit an SQL injection vulnerability in our public-facing API to gain unauthorized access to sensitive customer data, resulting in a data breach that violates the Confidentiality criterion.

You must then prove how you address this. You would map it to controls like:

• Control C-01: Web Application Firewall (WAF) is implemented and configured with rules to block common SQL injection patterns.
• Control C-02: All developers are required to complete mandatory secure coding training, with records maintained by HR.
• Control C-03: All application code that interacts with the database uses parameterized queries, as verified by code review checklists.
• Control C-04: The company conducts annual third-party penetration testing to proactively identify and remediate injection vulnerabilities.

Each control counters the risk, and together they give you a defensible position during an audit.

Aligning Controls with the Trust Services Criteria

The final step is to link your internal controls to the specific AICPA Trust Services Criteria (TSC) they satisfy. This translates your operational security activities into the formal language of SOC 2.

This completes the evidentiary trail. It shows you are managing risk in a way that meets the formal requirements of the SOC 2 framework.

Continuing with the SQL injection example, the mapping to the Common Criteria (the “CC” series) would look like this in your register. Our guide on the SOC 2 Common Criteria provides further detail on these requirements.

The three-way connection of Risk > Control > TSC is what an auditor follows during testing. When they select a risk from your register, they must be able to trace this clear, logical line to the SOC 2 criterion it helps satisfy.

A-LIGN’s 2025 Compliance Benchmark Report, drawing on more than 1,000 respondents, found that 92% of organizations conduct two or more audits a year and 58% conduct four or more. Enterprise organizations were more than twice as likely as smaller ones (35% vs. 15%) to run six or more. Because the same documented risk-to-control mapping supports SOC 2 and can feed ISO 27001, HITRUST, and other concurrent programs, a well-structured template saves repeated work.

Calculating Residual Risk and Defining a Treatment Plan

After identifying risks and mapping controls, the next step is to calculate residual risk, the level of risk remaining after your controls have been applied. Calculating it acknowledges that no control is 100% effective, and shows auditors that your risk management process is realistic and continuous.

The result drives your risk treatment plan and justifies resource allocation for security improvements.

Calculating a Defensible Score

To calculate residual risk, you must first score the effectiveness of your existing controls. A simple 1-3 scale is sufficient and easy for auditors to understand:

• 3 - Highly Effective: The control is automated, preventative, and significantly reduces risk (e.g., automated vulnerability scanning that blocks deployments).
• 2 - Moderately Effective: The control is detective or procedural and relies on human action, offering a moderate risk reduction (e.g., annual security awareness training).
• 1 - Minimally Effective: The control has a minor effect, often due to inconsistent enforcement or being purely policy-based.

With an inherent risk score (Likelihood x Impact) and a control effectiveness score, you can use a simple formula like Residual Risk = Inherent Risk / Control Effectiveness. Document this methodology and apply it consistently across all risks.

Choosing Your Risk Treatment Strategy

Based on the calculated residual risk score, you must formally decide on a course of action. This is your risk treatment plan. Auditors will look for this documented plan to verify that you have a formal process for responding to identified risks, as required by criteria like CC3.2. There are four accepted strategies.

Your risk treatment plan is a direct response to your residual risk score. A high score demands mitigation, while a very low score may be acceptable. This documented decision-making is what auditors look for to confirm you are actively managing your security program.

The table below breaks down the four strategies with examples relevant to a SaaS company undergoing a SOC 2 audit.

Risk Treatment Plan Options

Documenting a treatment decision for every risk turns your soc 2 risk assessment template from an analysis into an action plan, and shows an auditor that your risk management program functions.

Keeping Your Risk Assessment Current

For a SOC 2 audit, especially a Type 2, a static risk assessment created once and never updated is a significant red flag. It must be a living document. A Type 2 report assesses the design and operational effectiveness of your controls over a period (3 to 12 months, most commonly 6 to 12), and auditors will look for evidence that your risk assessment process is ongoing and adapts to changes in your business, technology, and threats.

An outdated risk register fails to demonstrate this continuous management and can lead to a qualified opinion or finding. A core requirement of SOC 2 is to show that you are actively managing risk, not just documenting it once.

When to Update Your Risks Immediately

Certain business events introduce significant new risks and require an immediate, ad-hoc update to your risk assessment. Do not wait for the next scheduled review.

Triggers for an immediate review include:

• Major Architectural Changes: Migrating from a monolith to a microservices architecture introduces new risks related to API security, container vulnerabilities, and inter-service communication that must be immediately identified, assessed, and mitigated.
• Onboarding a Critical New Vendor: Integrating a new payment processor or data analytics platform introduces third-party risks. The SOC 2 process requires you to assess these vendor risks as part of your own, as per CC9.2 (Vendor Management). Our vendor security questionnaire guide covers how questionnaire records fit that control.
• Learning from a Security Incident: A post-incident review that identifies a control failure (e.g., a successful phishing attack) must result in an updated risk assessment. The incident proves that a risk was either unidentified or its mitigation was ineffective, and auditors will expect to see this reflected in your register.

Setting a Formal Review Cadence

Beyond ad-hoc updates, you must have a formal, documented schedule for reviewing the entire risk register. For SOC 2, an annual review is common practice, and it is what auditors usually expect to see within the audit period. For rapidly growing SaaS companies, a semi-annual or quarterly review is more appropriate.

This review must be a formal meeting with the cross-functional team, and its output must be documented. The agenda should cover:

1. Review of all existing risks for accuracy of likelihood and impact scores.
2. Evaluation of the effectiveness of existing controls.
3. Identification of new risks arising from business, technology, or threat landscape changes.
4. Documentation of meeting minutes, attendees, and decisions made.

A documented annual review process is your primary evidence for satisfying the monitoring component of the COSO framework, which SOC 2’s Common Criteria follow. Your auditor will specifically ask for the meeting minutes or project tickets that prove you are actively overseeing and updating your risk management program.

Using Your Risk Assessment for a Smoother Audit

Your completed risk assessment gives the documented rationale (“the why”) behind every control you have implemented. It links your operational reality to the auditor’s testing procedures. The annual risk assessment report is one of the documents listed in our SOC 2 documentation guide, alongside the policies it supports.

A well-structured risk assessment lets the auditor quickly understand your security strategy and your threats, and see the connections you’ve drawn between risks, controls, and the Trust Services Criteria.

Presenting Your Risk Assessment to Auditors

When you provide your risk register to an auditor, you are giving them the blueprint they will use to scope their testing and guide their evidence collection.

Do not simply email the file. Proactively walk the auditor through your methodology for identifying, scoring, and treating risks. Highlight one or two of your highest-rated risks and then demonstrate the layered controls you have implemented to mitigate them.

For example, you could highlight a high-impact risk like, “Unauthorized access to production database via compromised developer credentials.” Then show them the corresponding controls you have in place:

• MFA on all administrative accounts (Control maps to CC6.1)
• Principle of least privilege for database access (Control maps to CC6.3)
• Quarterly user access reviews (Control maps to CC6.3)
• Logging and alerting on failed login attempts (Control maps to CC7.1)

This shows a defense-in-depth approach tied directly to SOC 2 criteria. A clear, well-organized risk assessment also shows the auditor you have a repeatable risk management process, and can reduce back-and-forth questioning during the audit.

---

Tell us your scope once and we return 3–10 ballpark quotes from matched firms, free and anonymized: get SOC 2 audit quotes.