How to Build a Risk Register That Satisfies SOC 2 CC3 Requirements
A practical guide to building and maintaining a risk register for SOC 2 CC3 compliance — what risks to log, how to score them, and how to document treatment decisions.
What CC3 Actually Requires
SOC 2 CC3 is the risk assessment criterion. The Trust Services Criteria say you must:
- Identify risks to achieving your security objectives
- Analyze and score identified risks
- Document risk responses (mitigate, transfer, accept, avoid)
- Monitor risks and update the register when your environment changes
What CC3 does not require:
- A specific risk scoring methodology (FAIR, CVSS, qualitative matrix — any documented approach works)
- A specific number of risks (10 meaningful risks is better than 100 generic ones)
- External risk consultants (you can build and maintain this internally)
The Minimum Viable Risk Register
A compliant risk register has these fields per risk:
| Field | Description |
| Risk ID | Unique identifier (e.g., RSK-001) |
| Category | Infrastructure, People, Vendor, Data, Regulatory, etc. |
| Risk statement | Clear description of the risk event and its potential impact |
| Likelihood | 1–5 scale (Rare → Almost Certain) |
| Impact | 1–5 scale (Negligible → Catastrophic) |
| Risk score | Likelihood × Impact |
| Treatment | Mitigate / Transfer / Accept / Avoid |
| Treatment description | Specific controls or actions taken |
| Owner | Person responsible for managing this risk |
| Status | Open / In Treatment / Accepted / Closed |
| Last reviewed | Date of most recent review |
The 15 Risks Every SaaS Company Should Log
Infrastructure risks:
People risks:
Vendor risks:
Data and compliance risks:
Scoring Methodology
A simple 5×5 risk matrix is sufficient for SOC 2 CC3. Score each risk by:
Likelihood (1–5):
Impact (1–5):
Risk score = Likelihood × Impact. Scores 15–25 are high, 8–14 medium, 1–7 low.
Treatment Decision Documentation
Auditors check that treatment decisions are defensible, not just documented. For each risk, document:
Mitigate: The specific controls you've put in place. "Risk RSK-001 (AWS account compromise) is mitigated by MFA enforcement on all IAM users (see control SS-IAM-001), quarterly access reviews (see process PR-ACR-001), and GuardDuty threat detection (see control SS-GD-001)."
Transfer: The insurance or contractual mechanism. "Risk RSK-010 (critical vendor breach) is partially transferred via cyber insurance policy (Policy #XXX) covering third-party liability."
Accept: The formal acceptance decision. "Risk RSK-014 (regulatory change) is accepted at current likelihood (1) × impact (3) = score 3 (Low). Management has reviewed and accepted this risk as of [date]."
Avoid: The change to operations that eliminates the risk. "Risk RSK-013 (data outside agreed geography) was avoided by configuring all AWS services to restrict data to us-east-1 and us-west-2, with SCPs preventing creation of resources in other regions."
When to Update the Register
CC3 requires ongoing risk assessment, not a one-time exercise. Update the register when:
- You make significant infrastructure changes (new AWS account, new architecture, new product feature)
- A major vendor has a security incident
- You add new categories of personal data processing
- A new regulation applies to your business
- A risk event actually occurs (update the likelihood score upward)
- At minimum: full register review every 6 months
SecureSpect's Risk Register module tracks all of this — with version history, update timestamps, and direct links from risks to the controls that mitigate them.
