Sample Risk Register for SOC 2 Compliance (Editable Examples)
A risk register is central to a SOC 2 examination — the Trust Services Criteria (CC3.0) expect you to identify, analyse and respond to risks to your service commitments. This free template gives you the structure, a scoring method, and worked example rows you can edit. It works just as well for ISO 27001.
Use this if you're preparing for a SOC 2 Type I or Type II report (or ISO 27001 certification) and need a defensible, living record of your risks and how you treat them.
Template
Information Security Risk Register
SOC 2 — CC3.0 (Risk Assessment)
How to score risk
Rate each risk for Likelihood (1 = Rare to 5 = Almost certain) and Impact (1 = Negligible to 5 = Severe). Risk score = Likelihood × Impact (1–25). Treat scores of ✎ e.g. 12 and above as high priority. Assign every risk an owner and a treatment decision: Mitigate, Accept, Avoid or Transfer. Review the register at least ✎ quarterly and after any significant change.
Using the register
The table below shows example entries — replace them with your own risks. Record the residual score after controls are applied, and track treatment actions to completion. Keep evidence (tickets, reviews) so an auditor can see the register is operating, not just written.
Example risk register entries (edit these)
| ID | Risk | Likelihood | Impact | Score | Owner | Treatment | Residual |
|---|---|---|---|---|---|---|---|
| R-01 | Phishing leads to credential theft | 4 | 4 | 16 | [Customize: Head of Security] | Mitigate — MFA + awareness training | 8 |
| R-02 | Cloud misconfiguration exposes data | 3 | 5 | 15 | [Customize: DevOps Lead] | Mitigate — IaC reviews + CSPM | 6 |
| R-03 | Critical vendor outage | 2 | 4 | 8 | [Customize: COO] | Transfer — SLA + backup provider | 6 |
| R-04 | Departing employee retains access | 3 | 4 | 12 | [Customize: IT Manager] | Mitigate — joiner/leaver process | 4 |
| R-05 | Unpatched critical vulnerability | 3 | 5 | 15 | [Customize: DevOps Lead] | Mitigate — 14-day patch SLA | 5 |
✎ Highlighted items are placeholders — replace them with your organization's details.
Generate a tailored Information Security Risk Register instantly with CompliWiseAI
Skip the placeholders — get a version written for your company's industry, size, country and risk level, ready to review and export.
How to customize this template
- Replace the example rows with risks specific to your systems, data and suppliers — generic registers don't pass audit.
- Set and document your risk acceptance threshold (the score above which a risk must be treated).
- Name a real owner for every risk; unowned risks are a common audit finding.
- Record residual risk after controls, not just the initial score — that's what shows your treatment works.
- Date your reviews and keep the register living; a register last touched a year ago undermines the whole control.
What an auditor looks for
- •Is there a documented risk-scoring method and acceptance criteria?
- •Does every risk have an owner and a treatment decision?
- •Is residual risk recorded, and are treatment actions tracked to closure?
- •Has the register been reviewed within the stated cycle?
Frequently asked questions
Does SOC 2 require a risk register?+
SOC 2's Common Criteria (CC3.0) require a risk assessment process. A risk register is the standard, auditor-friendly way to evidence that you identify, analyse and respond to risks.
What's the difference between a risk assessment and a risk register?+
The risk assessment is the process; the register is the living record it produces — the list of risks, scores, owners and treatments.
How often should I update it?+
At least quarterly is common, and always after a significant change (new product, new vendor, an incident). For SOC 2 Type II, you need evidence it operated across the audit period.