CC3.2 CC3 · Risk Assessment · Security (Common Criteria)

CC3.2 — Risk identification and analysis

COSO Principle 7 — The entity identifies risks to the achievement of its objectives and analyzes them as a basis for determining how they should be managed.

Also written as CC 3.2, TSC CC3.2, SOC2 CC3.2, SOC 2 Type 2 CC3.2.

What SOC 2 CC3.2 requires

Risk identification and analysis is one of 4 criteria in the Risk Assessment (CC3) series of the Security (Common Criteria) category. COSO Principle 7 — The entity identifies risks to the achievement of its objectives and analyzes them as a basis for determining how they should be managed. CC3 evidence is your risk assessment itself — auditors check that it is current, that it considers fraud, and that identified risks visibly drive the controls tested elsewhere in the report.

Audit evidence assessors look for

When preparing for a SOC 2 audit against CC3.2, gather artefacts such as:

  • Annual risk assessment report
  • Risk register with likelihood / impact scoring
  • Threat and vulnerability identification records
  • Risk treatment decisions and owner assignments

ISO 27001 mapping

CC3.2 corresponds to the following ISO 27001:2022 Annex A control(s): A.5.6, A.5.7, A.5.9. If you already run an ISO 27001 ISMS, map your existing evidence for these controls to CC3.2 rather than duplicating work.

Map CC3.2 to ISO 27001 & NIST CSF →
Crosswalk this criterion in the Control Mapper & Gap Assessment.
Document the risk →
Record treatment for gaps against CC3.2 in the Risk Register.

Other Risk Assessment criteria

CC3.1 Objectives for risk assessment CC3.3 Fraud risk assessment CC3.4 Assessing significant change

All CC3 Risk Assessment criteria →

Frequently asked questions

Is CC3.2 required for a SOC 2 report?

Yes. CC3.2 sits in the Common Criteria, which apply to every SOC 2 engagement regardless of which additional categories you scope in — there is no SOC 2 report that omits them.

How does an auditor test CC3.2?

In a Type 1 report the auditor assesses design only — does a control exist at a point in time that would meet CC3.2 if it operated. In a Type 2 report they also test operating effectiveness by sampling evidence from across the review period, typically 3 to 12 months. That difference is why Type 2 evidence has to be continuous rather than assembled the week before fieldwork.

What happens if CC3.2 fails testing?

A control that fails becomes an exception, which the auditor describes in the report along with management's response. Exceptions do not automatically make a report "failed" — a SOC 2 report is an opinion, not a pass/fail certificate — but a qualified opinion is what customers notice, so remediate and re-test before fieldwork closes where you can.

Does SOC 2 CC3.2 map to ISO 27001?

Yes — CC3.2 aligns with ISO 27001:2022 Annex A control(s) A.5.6, A.5.7, A.5.9. If you already run a certified ISMS, re-point that evidence rather than building a parallel set; the underlying control is the same and only the reporting format differs.