SOC 2 CC3.2: Identifying and Analyzing Risk to Your Objectives

SOC 2 CC3.2 requires an entity to identify risks to its objectives across the whole organization and to analyze them well enough to decide how each should be managed. It is the core of the CC3 series (Risk Assessment), and a frequent finding under it is a risk register scattered across a GRC platform, a spreadsheet, and people's heads, so no single view of what has been identified, accepted, or remediated exists when the auditor asks.

What does SOC 2 CC3.2 require?

CC3.2 takes the objectives set under CC3.1 and asks two things of them: find the risks that threaten them, and analyze those risks enough to decide what to do. Identification has to reach across the entity, not just the security team, and analysis has to estimate how significant each risk is so the response is proportionate.

The criterion expects a defined process, not a one-time exercise. Risks are identified from both internal and external factors, the analysis estimates the potential significance of each, and each risk ends with a management decision: accept, avoid, reduce, or share it. That decision is what the auditor traces, because a risk with no treatment decision is an open question, not a managed risk.

For SOC 2 the trust services criteria add specificity. The process has to identify threats and vulnerabilities to system components, account for threats arising from vendors and other third parties with access, and assess significance in terms of criticality, likelihood, and magnitude. The output of all this is a risk register the entity keeps current.

What are the CC3.2 points of focus?

The AICPA defines 9 points of focus for CC3.2. Because the Trust Services Criteria are AICPA copyrighted material, the points of focus below are paraphrased and grouped by theme rather than reproduced verbatim; consult the official TSC document for exact wording.

• Identifies risk across all levels of the entity. Risk identification reaches the entity, subsidiary, division, operating unit, and functional levels relevant to the objectives.
• Analyzes internal and external factors. Both internal conditions and external factors are considered for their effect on the objectives.
• Involves the right levels of management. Effective risk assessment mechanisms engage the levels of management with the authority to act.
• Estimates significance and determines response. Identified risks are analyzed for potential significance, and the process decides whether to accept, avoid, reduce, or share each one.
• Identifies threats and vulnerabilities (trust services addition). The process identifies threats from intentional, unintentional, and environmental sources, and the vulnerabilities of system processes, infrastructure, software, and information assets.
• Analyzes third-party threats (trust services addition). The process analyzes threats and vulnerabilities arising from vendors, business partners, customers, and others with access to the entity's systems.
• Assesses the significance of risks (trust services addition). Significance is assessed through component criticality, susceptibility, likelihood, magnitude, unidentified threats, mitigation strategies, and the appropriateness of residual risk.

How do you meet CC3.2 in cloud environments?

Cloud environments meet CC3.2 with a risk process that treats the provider relationship as an input, not an exemption:

• One risk register as the single source of truth. All risks live in one place, usually the GRC platform, with likelihood and impact ratings, an owner, a treatment decision, and a status, so the risk posture has a coherent view.
• Threat and vulnerability inputs feed the register. Findings from vulnerability scanning, identified under CC7.1, and from monitoring feed risk identification rather than sitting in a separate tool.
• Third-party risk is analyzed, not assumed away. Threats arising from SaaS vendors and subservice providers are analyzed, and the shared-responsibility split determines which risks the entity owns.
• Consistent scoring and a defined cadence. Risks are scored the same way each time and reviewed on a set cadence, with new risks registered as the environment changes.

A GRC platform does not satisfy CC3.2 on its own. It provides the register and the auditor's view into it, but the control is the process of identifying, scoring, and deciding on risks; the platform records those decisions rather than making them.

How do you meet CC3.2 on-prem?

On-prem and hybrid environments carry a wider threat model, because the entity owns the physical and hardware layers a cloud provider would abstract away. The risk management guide for hybrid and on-prem environments covers the detail; the shape is:

• A register structured for the real threat model. Physical access, hardware failure, firmware and supply-chain risk, hardware end-of-life, provider concentration, and key-person dependency all appear as risk categories, because they are the entity's to carry.
• Consistent scoring and a named owner per risk. Each risk is scored the same way, qualitative or quantitative, with an owner accountable for the response.
• Documented risk acceptance. Where a risk is accepted, the record names an authorized approver, the compensating controls, and a review date, so acceptance is a deliberate decision rather than a silent gap.
• Subservice provider risk evaluated directly. The colocation or hosting provider's SOC 2 or equivalent report is read and its risks recorded, since the data center is part of the system.

A register that names on-prem categories reads as one the team built. A generic template with the company name swapped in reads as one nobody applied to the infrastructure.

Cloud vs on-prem at a glance

What evidence do auditors expect for CC3.2?

A SOC 2 Type 1 audit is design-only, and in practice a risk assessment is one of the few evidence items an auditor asks to see for it, with a typical range of roughly five to fifteen risk items depending on company size. The risk register is one of the artifacts that has to exist in usable form even for a design-stage audit.

How does CC3.2 map to ISO 27001:2022?

ISO 27001 Clause 6.1.2 requires a repeatable process that identifies risks to confidentiality, integrity, and availability and analyzes them, and Clause 6.1.3 requires selecting treatment options and producing a treatment plan. Between them they line up directly with CC3.2's identify-analyze-respond process, so the risk register and treatment plan carry across both frameworks. The SOC 2 to ISO 27001 control mapping covers the full crosswalk across all five Trust Services Categories.

Related criteria

CC3.2 identifies and analyzes risks against the objectives set in CC3.1. Two of its risk types get their own criteria in the series: fraud risk is assessed under CC3.3, and risks arising from significant changes to the business, systems, or environment are assessed under CC3.4. The threat and vulnerability inputs to CC3.2 come partly from vulnerability management under CC7.1, and the ongoing monitoring that keeps the register current is evaluated under the CC4 monitoring criteria.

Frequently Asked Questions

What does SOC 2 CC3.2 mean?

SOC 2 CC3.2 means an entity must identify risks to its objectives across the whole organization and analyze them enough to decide how each should be managed. In practice it produces a risk register where each risk is scored for likelihood and impact and carries a decision to accept, avoid, reduce, or share it.

What evidence satisfies CC3.2?

The core evidence is a risk assessment policy, a risk register with likelihood and impact ratings, a risk treatment plan showing the decision on each risk, a risk assessment report, and management or committee minutes showing the right people were involved. For a Type 1 audit the risk register is one of the few operational artifacts an auditor asks to see.

How many risks should a SOC 2 risk register have?

There is no fixed number. A typical range is roughly five to fifteen risk items depending on company size, with more for larger or more complex organizations. What matters is that the register covers the real threats to the entity's objectives and that each risk is scored consistently and carries a treatment decision, not that it hits a target count.

What is the difference between mitigate and accept in a risk register?

Mitigate means the entity is doing something about the risk, so there must be a task or control and evidence showing what was done. Accept means the entity has made a conscious decision to live with the risk, so there must be a documented justification and, usually, an authorized approver and a review date. The two labels drive different auditor expectations.

How is CC3.2 different from CC3.1?

CC3.1 specifies the objectives clearly enough that risk can be assessed against them. CC3.2 is the next step: identifying the risks to those objectives across the entity and analyzing their significance so a response can be chosen. CC3.1 sets the target, CC3.2 finds and ranks what threatens it.