CC3.2 SOC 2

SOC 2 CC3.2: COSO Principle 7: Identifies and Analyzes Risk

What This Control Requires

The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed. Risk identification considers internal and external factors and their impact on the achievement of objectives.

In Plain Language

Every control you implement should trace back to a real risk. Without a structured risk assessment, you're guessing at what to protect and how much effort to spend - and auditors will see right through that. CC3.2 is where you systematically identify what could go wrong, figure out how likely it is and how much it would hurt, and use that analysis to drive your control decisions.

Practically, this means running formal risk assessments that cover both internal risks (employee mistakes, system failures, insider threats) and external risks (cyber attacks, natural disasters, regulatory changes). The methodology needs to be consistent and documented so that risks can be compared and prioritised sensibly.

Auditors will examine whether you have a documented risk assessment methodology, whether assessments happen regularly, whether they cover all relevant threats for the trust services criteria in scope, and whether results actually feed into control decisions. A risk assessment that sits in a drawer and never changes is a red flag.

How to Implement

Pick a formal risk assessment methodology and stick with it. NIST SP 800-30, ISO 27005, FAIR, and OCTAVE are all solid options. Document your chosen approach, including how you identify, analyse, and rate risks.

Run a comprehensive initial assessment covering all systems and services in your SOC 2 scope. Identify assets, threats, vulnerabilities, existing controls, and the potential impact of control failures. Pull input from stakeholder interviews, incident history, threat landscape analysis, and system architecture reviews.

Build a risk register that catalogues every identified risk. For each entry, record the description, affected assets or objectives, threat sources, exploited vulnerabilities, existing controls, likelihood rating, impact rating, overall risk score, and treatment decision (accept, mitigate, transfer, or avoid).

Define your rating criteria clearly. Use a consistent scale (1-5 or Low/Medium/High/Critical) with written definitions for each level. Base likelihood on threat frequency and control effectiveness. Base impact on financial loss, reputational damage, and regulatory consequences.

Schedule annual reviews at minimum. Trigger interim reviews whenever something significant changes - new systems, emerging threats, organisational restructuring, or a major incident. Document every review, including new risks, changed ratings, and resolved items.

Involve people beyond IT and security. Risk assessment needs business context from operations, legal, and leadership to properly evaluate impact and set priorities. Treating it as a purely technical exercise is a common mistake.

Evidence Your Auditor Will Request

Documented risk assessment methodology describing the approach, criteria, and scales used
Complete risk register with all identified risks, ratings, and treatment decisions
Evidence of regular risk assessment reviews (at least annual) with documentation of changes
Records of stakeholder participation in risk assessment activities
Risk assessment reports provided to management for review and approval

Common Mistakes

Risk assessment is performed only once and not updated when significant changes occur
Risk register lacks specificity, with vague risk descriptions that do not tie to concrete threats and vulnerabilities
Risk ratings are assigned subjectively without consistent criteria or methodology
Risk assessment only considers technology risks and ignores human, process, and physical risks
Risk assessment findings are not communicated to management or used to inform control decisions

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.5.7	Related
nist-csf	ID.RA-01	Equivalent
nist-csf	ID.RA-02	Related

Frequently Asked Questions

Which risk assessment framework should we use?

It depends on your size and maturity. NIST SP 800-30 gives you a structured, government-aligned approach. ISO 27005 pairs naturally with ISO 27001 implementations. FAIR is great if you want to quantify risk in financial terms. For smaller organisations, a straightforward qualitative approach with a well-defined rating system is perfectly adequate for SOC 2. The key is consistency, not complexity.

How many risks should be in our risk register?

There's no magic number. Most organisations end up with 30 to 100 risks, but quality beats quantity every time. Each risk should be specific, actionable, and tied to an objective. If your register is so granular it becomes unmanageable, consolidate. If risks are so vague they don't point to a concrete threat, break them down further.

Can we use automated tools for risk assessment?

Absolutely. GRC tools are great for managing the process, maintaining your risk register, and tracking treatment plans. But they supplement human judgement - they don't replace it. Identifying and analysing risks properly requires business context and expert assessment that no tool can fully automate.

Track SOC 2 compliance in one place

AuditFront helps you manage every SOC 2 control, collect evidence, and stay audit-ready.

Start Free Assessment