SOC 2 Risk Assessment: How to Identify and Document Risks
SOC 2 CC3 requires a formal risk assessment process. Learn how to identify threats, assess likelihood and impact, document your risk register, and satisfy auditor requirements.
- CC3.1 through CC3.4 require that you specify security objectives, identify risks to those objectives, assess fraud risk, and identify changes that affect risk.
- A risk register — typically a spreadsheet or GRC tool — is the central artifact documenting identified risks, likelihood, impact, inherent risk score, controls, and residual risk score.
- Risk assessments must be updated at least annually and triggered by significant changes such as new products, new infrastructure, or new regulatory requirements.
- Auditors test risk assessment by reviewing your register, verifying it was updated during the observation period, and checking that high-residual risks have documented treatment plans.
- Risk assessment does not need to be complex — a structured 2-hour workshop with the right participants produces better evidence than a six-month consulting engagement that sits on a shelf.
In this guide
CC3 Criteria Overview
The CC3 cluster in the SOC 2 Trust Service Criteria addresses risk assessment. CC3.1 requires that the entity specify security objectives with sufficient clarity to enable the identification and assessment of risks. CC3.2 requires that the entity identify risks to the achievement of those objectives, considering relevant threats from internal and external sources. CC3.3 requires consideration of fraud risk — the potential for deliberate misrepresentation or misuse. CC3.4 requires identification of changes (new systems, new personnel, acquisitions) that could significantly affect the system of internal control.
These criteria collectively establish that risk assessment is not a one-time exercise but an ongoing process integrated into your operating model. A company that completed a risk assessment in year one of their SOC 2 program but has not revisited it in two years while doubling headcount and adding three new products has not satisfied CC3.4.
CC3 criteria feed directly into CC9.1 (risk mitigation through controls). The risk register is the bridge between identified risks and implemented controls — auditors follow the thread from a documented risk to the control designed to address it.
Building Your Risk Register
A risk register is a structured document (spreadsheet, GRC tool, or database) that captures each identified risk along with its assessment and treatment. Standard columns include: risk ID, risk category, threat description, affected asset or objective, likelihood (1–5 scale), impact (1–5 scale), inherent risk score (likelihood × impact), existing controls, control effectiveness, residual risk score, risk owner, treatment plan, and review date.
Risk categories relevant to SaaS companies include: infrastructure and cloud security risks (misconfiguration, data breach, DDoS), application security risks (injection, authentication bypass, API vulnerabilities), personnel risks (insider threat, phishing, negligent data handling), vendor and supply chain risks (vendor breach, third-party code vulnerabilities), compliance and regulatory risks (data protection law violations, contractual breaches), and availability risks (outage, capacity failure, disaster recovery gaps).
Start with 15–25 risks for a typical SaaS company in your first risk assessment. Each risk should be specific enough to have a clear owner and a clear set of controls. "Cybersecurity risk" is too broad to be useful. "Unauthorized access to production database due to overprivileged IAM roles" is actionable and auditable.
Identifying Threats and Vulnerabilities
Threat identification should be systematic, not ad hoc. Common approaches: use a threat library (NIST SP 800-30 threat catalog, OWASP Top 10 for application risks, CIS Top 18 for infrastructure risks) as a starting checklist and remove items that don't apply; conduct a structured brainstorm with your engineering, operations, and business leadership; and review prior security incidents and near-misses for risks that materialized.
For each identified threat, document the relevant vulnerability — the condition that makes the threat likely to materialize. Threat: "phishing attack targeting an engineer." Vulnerability: "engineers have high-privilege AWS access and no MFA enforced on AWS console." The combination of threat and vulnerability produces the risk. The control is the measure that reduces either the likelihood of the threat materializing or the impact if it does.
External sources of threat intelligence include: your auditor's industry benchmarking, penetration test findings, CISA Known Exploited Vulnerabilities (KEV) catalog, and threat intelligence feeds relevant to your technology stack. Documenting that your risk identification process incorporated external threat intelligence demonstrates a rigorous, evidence-based approach to CC3.2.
Risk Scoring Methodology
The most common SOC 2 risk scoring methodology uses a 5×5 likelihood/impact matrix. Likelihood scores: 1 (rare — unlikely in the next 3 years), 2 (unlikely — might occur in the next 3 years), 3 (possible — could occur in the next year), 4 (likely — will probably occur in the next year), 5 (almost certain — expected to occur within 6 months). Impact scores follow a similar scale from 1 (negligible) to 5 (catastrophic).
Inherent risk is the score before controls are applied (likelihood × impact, producing a 1–25 scale). Residual risk is the score after controls are applied. The gap between inherent and residual risk demonstrates the value of your control environment. A risk with inherent score 20 (high likelihood, high impact) and residual score 4 (controls are highly effective) shows mature risk treatment.
Define risk tolerance thresholds in your risk policy: for example, "residual risks scoring 15 or above require executive approval and a documented risk treatment plan." This threshold-based approach is testable — auditors can verify that all risks above your threshold have treatment plans and approvals on file.
Risk Treatment Plans
Every risk above your risk tolerance threshold must have a documented treatment plan. The four standard treatment options are: mitigate (implement or strengthen controls), transfer (purchase insurance or contractually shift liability to a third party), avoid (discontinue the activity creating the risk), and accept (formally accept the risk with documented justification and owner approval).
Risk treatment plans should include: the selected treatment strategy, the specific actions to be taken, the owner responsible for executing the plan, the target completion date, and the expected residual risk score after treatment. Auditors will verify that treatment plans were executed — not just documented. A treatment plan that calls for implementing MFA on the production AWS console with a deadline of Q2 but was never completed is worse than accepting the risk formally, because it shows your control process is not operating.
Risk acceptance decisions must be documented and approved. Define in your policy who can approve risk acceptance based on the residual risk score. Operational risks might be accepted by department heads; high residual risks (15+) might require CISO or CEO approval. This governance structure is evidence of the mature risk oversight that CC3.2 seeks.
Annual Review Process
Your risk assessment must be reviewed and updated at least annually under CC3.4. The annual review should: reassess likelihood and impact for existing risks in light of current controls and threat landscape changes; retire risks that are no longer relevant; add new risks identified from new products, new vendors, new regulations, or recent incidents; and update residual risk scores to reflect control changes during the year.
Document the annual review as a formal meeting with named attendees, an agenda, and a written output (updated risk register with a version date). Many companies combine the annual risk assessment with their annual security review meeting, covering the risk register, control effectiveness, and the coming year's security roadmap in a single session. The meeting minutes and updated register together constitute the evidence for CC3.4.
Trigger reviews outside the annual cycle when significant changes occur: a major new product feature that changes your data flows, a cloud migration, a significant headcount change, a security incident, or a new regulatory requirement. Document these triggered reviews even if the outcome is "no new risks identified" — the documentation shows the process is operating continuously, not just annually.
Evidence Auditors Collect
Auditors testing CC3 typically request: (1) your current risk assessment policy describing the methodology and frequency; (2) the current risk register with all fields populated; (3) evidence that the risk register was reviewed and updated during the observation period (meeting minutes, version history, or changelog); (4) treatment plan documents for risks above your risk tolerance threshold; and (5) evidence that treatment plan actions were completed.
A well-structured risk register in a GRC tool with version history and audit trail is the strongest evidence format. A Google Sheet with clear version dates and a change log is acceptable. A Word document with no version history and a date that hasn't changed in two years will generate questions.
Auditors may also connect your risk register to your control library, verifying that risks identified in the register correspond to controls implemented and tested elsewhere in the audit. If your register identifies "unauthorized access to production database" as a risk but your access control evidence shows no formal access review process, that disconnect will be flagged.
Frequently Asked Questions
Does SOC 2 require a specific risk assessment methodology?
How many risks should our register contain?
Can we use a GRC tool to manage our risk register?
Does the risk assessment need to be conducted by an outside party?
What is fraud risk and does it apply to a SaaS startup?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free