Skip to content
compliancebase
SOC 2CC3 — Identifies and Analyzes Risk

CC3.2

Identifies and Analyzes Risk

SOC 2 · 2017 TSC (2022 Revised Points of Focus) · Last verified August 2026

Objective

Identify risks across the entity and analyze likelihood, impact, and significance as a basis for deciding how each risk should be managed.

Points of focus

  • Use a repeatable method to identify internal and external risks
  • Assess likelihood and impact at relevant organizational levels
  • Prioritize significant risks and determine responses

Implementation notes

Run risk workshops against actual SaaS architecture, customer promises, abuse cases, staffing, and vendors; connect high-rated scenarios to roadmap work and preserve the rationale for accepted residual risk. Operationalize use a repeatable method to identify internal and external risks in ticketing, IdP, or GRC workflows with named owners — not only in a static policy PDF. Retain risk methodology and current risk register with reviewer identity, population scope, dates, and remediation outcomes auditors can sample. A recurring failure mode is that the register is a static audit spreadsheet disconnected from operating decisions Revisit after material architecture, vendor, data-flow, or leadership changes and document the decision.

Audit tip: Sample risk methodology and current risk register with dates and named reviewers. Be ready to walk through how you detect and correct: the register is a static audit spreadsheet disconnected from operating decisions

Evidence auditors typically request:

  • Risk methodology and current risk register
  • Workshop notes involving engineering, security, legal, and business leaders
  • Risk ratings linked to treatment plans and acceptance decisions

Common gaps

  • The register is a static audit spreadsheet disconnected from operating decisions
  • Risks to customers and data subjects are omitted in favor of company-only financial impact

Cross-Framework Mapping

FrameworkRequirementImplementation note
SOC 2CC3.2This control
ISO 27001A.5.1, A.5.2Organizational controls provide related governance evidence but are not equivalent criteria.
HIPAA164.308(a)(1)HIPAA administrative safeguards overlap where ePHI systems are in scope.
GDPRArticle 32GDPR accountability and security duties can reuse evidence when personal data is in scope.

Primary sources

Frequently Asked Questions

Identifies and Analyzes Risk applies to the systems and commitments in your Trust Services Criteria scope. Translate the requirement into concrete operating workflows — use a repeatable method to identify internal and external risks — with evidence stored where auditors and customers can sample it.

Lead with risk methodology and current risk register and pair it with workshop notes involving engineering, security, legal, and business leaders. Samples should show who performed the control, when, against which population, and what changed as a result.

Teams often fail because the register is a static audit spreadsheet disconnected from operating decisions Close the loop with dated operating records and test the control on a realistic production path.

Control operation can often be shared across SOC 2, ISO 27001, GDPR, and HIPAA — but each framework uses different vocabulary and accountability. Maintain an explicit crosswalk rather than assuming equivalence.

Review at least annually and after material product, vendor, or data-flow changes. High-risk or privileged paths may need quarterly sampling even when the criterion does not prescribe a cadence.

Framework versions referenced in this page:

  • SOC 2 — 2017 TSC (2022 Revised Points of Focus)

Last verified: August 2026 · Primary sources linked above