A documented risk assessment is both a SOC 2 requirement in its own right and the justification for your entire control set. Auditors expect to see that you identified the risks to your in-scope assets, rated them, and chose your controls deliberately in response - not arbitrarily. A risk assessment is therefore not paperwork to satisfy a checkbox; it is the logical foundation on which a defensible program is built.
This guide explains what the criteria expect, how to run a SOC 2 risk assessment, how it drives control selection, and how to keep it current.
Why a risk assessment is required
The Common Criteria explicitly require a regular, documented process to identify and analyze the risks to your objectives. The reasoning is that controls should not be chosen at random or copied from another company - they should respond to the actual risks your environment faces. A risk assessment makes that link explicit, showing the auditor that each control exists for a reason. Without one, your control set has no documented rationale, which is itself a finding, and you lose the ability to explain why your program is shaped the way it is.
What the assessment covers
A SOC 2 risk assessment considers the threats and vulnerabilities affecting your in-scope information assets, systems, people, processes, and data. It looks at risks to confidentiality, integrity, and availability, and at the ways those risks could undermine the commitments you make to customers. The scope of the assessment should align with the scope of your audit, so that the risks you analyze correspond to the systems and criteria the auditor will examine. The goal is a realistic picture of what could go wrong in the environment you are attesting to.
Free resource
SOC 2 Readiness Kit
A practical checklist + policy starter pack to fast-track your audit.
How to run it
A workable process is straightforward: inventory your in-scope assets, identify the threats and vulnerabilities to each, rate each risk by likelihood and impact, and decide how to treat it - mitigate, accept, transfer, or avoid. The ratings need not be elaborate; a consistent likelihood-times-impact approach is sufficient, provided it is applied uniformly and documented. What matters is that the methodology is repeatable and that the resulting decisions are recorded, so the assessment can be reviewed, defended, and updated over time.
The risk register
The output of the assessment is a risk register: a living document listing each identified risk, its rating, the treatment decision, and the controls or actions that address it. The register is the artifact the auditor examines, and it is also a genuinely useful management tool, giving leadership a prioritized view of where the organization is exposed. A register that is created once and never revisited loses its value quickly, so it should be maintained as risks change rather than treated as a one-time deliverable.
How risk drives control selection
The crucial link the auditor looks for is that your risk assessment actually drove your controls. A high-rated risk should map to a control that mitigates it; a risk you chose to accept should be documented as an explicit decision rather than an oversight. This traceability - from risk to treatment to control - is what demonstrates a thoughtful program. It also helps you defend scoping and control choices, because you can point to the risk rationale behind each one rather than justifying them after the fact.
Keeping the assessment current
A risk assessment is not a one-time event. The criteria expect it to be performed regularly - at least annually - and refreshed when the environment changes materially, such as a new product, a major architecture change, or a significant new vendor. Treating it as a living process, reviewed on a schedule, ensures it continues to reflect reality and continues to justify your evolving control set. An assessment that is years out of date is nearly as problematic as not having one, because it no longer corresponds to the environment under examination.
Common risk-assessment gaps
The recurring problems are predictable: no documented assessment at all, an assessment that exists but does not connect to the controls, ratings applied inconsistently, or a register that was created for the first audit and never updated. Each undermines the rationale for your program. The fixes are equally clear - run a documented assessment, link risks to controls, apply a consistent methodology, and review the register on a schedule - and addressing them turns the risk assessment from an exception waiting to happen into a genuine strength of your program.
Risk assessment and vendor risk
Your risk assessment should extend to the third parties you depend on, because their failures can become your incidents. Identifying the risks posed by critical vendors and subprocessors, and addressing them through due diligence and monitoring, is both a sound practice and an expectation that the attestation standard emphasizes. Integrating vendor risk into your overall assessment - rather than treating it as a separate afterthought - gives a complete picture and aligns with how auditors expect a mature program to think about risk.
Quantitative versus qualitative approaches
Risk can be rated qualitatively, using descriptive bands such as low, medium, and high, or quantitatively, attaching estimated probabilities and dollar impacts to each scenario. For most companies pursuing SOC 2, a qualitative or lightly semi-quantitative approach is entirely sufficient and far easier to sustain - what matters to the auditor is that the method is consistent, documented, and actually used to inform decisions, not that it is mathematically elaborate. Over-engineering the scoring model is a common trap that consumes effort without improving the program. Choose the simplest approach your team can apply uniformly across every risk, and reserve more detailed quantitative analysis for the handful of risks where the investment in precision genuinely changes a decision.
Connecting risk to the broader program
The risk assessment should not sit in isolation; it is the hub that connects several parts of your program. The risks you identify justify your control selection, feed your vendor management decisions, shape your incident-response priorities, and inform what leadership reviews in governance meetings. When these connections are explicit - when a board can see that the controls funded this year address the risks rated highest - the program reads as coherent and deliberate rather than as a disconnected set of activities. Auditors notice this coherence, and so do customers who review your report. Treating the risk assessment as the organizing spine of the program, rather than a standalone document produced for the audit, is what turns it from a compliance artifact into a genuine management tool.
Reviewing the assessment with leadership
A risk assessment gains weight when leadership formally reviews it. Presenting the register to executives or the board on a regular cadence demonstrates governance involvement, ensures the risks the company is accepting are accepted knowingly at the right level, and creates a record auditors value. This review also keeps the assessment honest, because risks that have to be explained to leadership tend to be rated and treated more carefully than those that live only in a working document. Building a periodic leadership review into the process is a small step that markedly strengthens both the program and the story it tells.
How ISpectra supports your risk assessment
ISpectra helps you run a documented, defensible risk assessment, build a living risk register, and trace each risk to the control that addresses it - establishing the rationale auditors look for and keeping it current as you grow. This foundation is part of how we deliver a clean Type 1 within two months and a Type 2 within four. A sound risk assessment is the analytical foundation of SOC 2 compliance.
Free consultation
Need help with SOC 2?
Talk to our certified compliance team — we’ve supported 200+ audits.