What SOC 2 Requires for Risk Assessment

CC3 of the SOC 2 Trust Services Criteria requires that you identify, analyze, and respond to risks that could affect your security objectives. This translates to three concrete deliverables auditors check:

A documented risk assessment methodology

A risk register with identified risks, likelihood, impact, and treatment decisions

Evidence that the risk assessment was completed and reviewed during the observation period

The most common CC3 finding: no risk register exists, or an outdated one that clearly hasn't been touched since a consultant created it. Auditors treat a stale risk register as evidence the risk program doesn't actually operate.

The Risk Register Structure

A SOC 2 risk register doesn't need to be complex. At minimum, each row should contain:

|---|---| Likelihood scale:

• 1: Rare — once in 5+ years
• 2: Unlikely — once in 2–5 years
• 3: Possible — once per year
• 4: Likely — multiple times per year
• 5: Almost certain — monthly or more

Impact scale:

• 1: Negligible — no customer impact, no data loss
• 3: Moderate — minor data exposure, recoverable
• 5: Critical — breach of customer data, material compliance failure

Risk Categories for SaaS Companies

Organize risks by category to make the assessment comprehensive:

Access Control Risks

• Unauthorized access to production systems via stolen credentials
• Insider threat from disgruntled employee
• Over-provisioned access not removed after role change
• Access key leak through code repository

Data Security Risks

• Customer data exfiltration via compromised application
• Unencrypted data at rest exposed via storage misconfiguration
• Data loss due to accidental deletion without backup

Infrastructure Risks

• Cloud account takeover via phishing/credential theft
• Production outage due to unplanned configuration change
• Supply chain attack via compromised dependency

Organizational Risks

• SOC 2 audit findings from undiscovered control gaps
• Vendor breach exposing customer data processed by sub-processor
• Key personnel departure causing operational disruption

Compliance Risks

• GDPR/CCPA violation due to undiscovered personal data processing
• Contractual breach of customer security requirements

Treatment Decisions

For each identified risk, document one of four treatment decisions:

Mitigate — Implement or enhance controls to reduce likelihood or impact. Most risks take this path. Document the specific controls that address the risk.

Accept — The risk is below your risk tolerance threshold (typically score ≤ 4). Document who approved acceptance and why.

Transfer — Shift the risk to a third party (e.g., purchase cyber liability insurance, require vendors to hold their own compliance certifications).

Avoid — Stop the activity that creates the risk (e.g., stop storing credit card numbers directly by using a payment processor).

The Annual Review Cycle

SOC 2 requires the risk assessment to be reviewed periodically — annually is the standard expectation. The annual review should:

Review all existing risks for accuracy (has likelihood/impact changed?)

Add new risks identified from security incidents, industry events, or changes to the system

Close out risks that are no longer applicable

Verify that treatment decisions are still appropriate

Get sign-off from the risk owner (typically CTO or VP Engineering) and document the review date

For a SOC 2 Type II with a 12-month observation period, you need at least one annual review completed within the period. For longer programs, auditors expect to see the review is actually annual — not a one-time exercise.

SecureSpect Risk Register

SecureSpect's built-in Risk Register module provides a structured workspace for creating, maintaining, and reviewing risks. Risks are linked to the controls that mitigate them — so when a control check fails, the associated risks are automatically flagged for review. The review history and owner assignments create the audit trail auditors need, without manual spreadsheet maintenance.