Risk register template for SOC 2
A free risk register in Excel format: one row per risk, inherent and residual scores on 1 to 5 likelihood and impact scales, ratings that calculate themselves, and columns for treatment, owners and acceptance. It is the same register that ships in the Policyseed Audit Kit, written here for a generic stack.
What a risk register is
A risk register is the record of your risk assessment. Each row is something that could go wrong for the company or its customers, scored for how likely it is and how much damage it would do, with a named owner and a decision about what to do about it. For SOC 2, it is the main evidence that the assessment in the Risk Assessment and Management Policy actually ran: the policy says what you will do, the register shows you did it.
The workbook has two sheets:
- Risk Register. 10 starter risks plus ten empty numbered rows. The likelihood and impact cells are empty; the score and rating columns hold formulas that fill in once you enter both numbers.
- Scoring Scales. What each likelihood and impact score means, and the response each rating requires. These are copied from section 2 of the policy, so the register and the policy use the same yardstick.
The starter risks
The template starts with risks most small SaaS companies have to consider. They are prompts, not a finished assessment: none is scored, and each names the policy area that usually addresses it. Edit them for your stack, delete any that do not apply and add your own.
- An employee account is taken over through phishing or a reused password.
- Customer data is exposed through misconfigured cloud storage, network rules or IAM.
- A vulnerable dependency or code flaw in the product is exploited.
- An unreviewed or faulty change reaches production.
- Production data is lost or corrupted and cannot be restored.
- A prolonged outage of the cloud provider or a region takes the product down.
- A vendor holding customer data (vendors that process customer data) suffers a breach or failure.
- A former employee or contractor keeps access after leaving.
- A laptop with company data is lost, stolen or left unpatched.
- A security incident is not detected, or the response is slow or uncoordinated.
The Audit Kit’s version of this register is pre-filled from your stack: the starter risks name your cloud provider, identity provider, source control, backup and logging tools and vendors, and the existing controls say whether you enforce MFA.
How to fill it in
Work through it with the people who run the systems, not alone. For each risk, agree the inherent scores first, list the controls you already have, then agree the residual scores. Every column, in the order it appears in the sheet:
| Column | What goes in it |
|---|---|
| ID | A stable identifier for the risk. Keep it when the risk is closed so its history stays traceable. |
| Risk | What could happen, written as an event with a cause, not a one-word category. |
| Affected assets | The systems, data or services the risk would hit. |
| Owner | One named person accountable for the treatment decision and for keeping the entry current. |
| Inherent likelihood (1-5) | How likely the risk is before counting existing controls, on the Likelihood scale in the Scoring Scales sheet. |
| Inherent impact (1-5) | How much damage it would do, on the Impact scale in the Scoring Scales sheet. |
| Inherent score | Formula: likelihood times impact. It stays blank until both scores are entered. |
| Inherent rating | Formula: Critical 15 to 25, High 10 to 14, Moderate 5 to 9, Low 1 to 4. |
| Existing controls | The controls already operating against this risk, and the policy that documents each. |
| Treatment (mitigate / accept / transfer / avoid) | The decision for this risk and, briefly, why. |
| Actions | What will be done to reduce the risk, specific enough that someone can say it is finished. |
| Action owner | Who completes the actions, if not the risk owner. |
| Due date | When the actions are due. The rating sets how quickly a treatment plan is needed. |
| Residual likelihood (1-5) | Likelihood after existing controls and completed actions. |
| Residual impact (1-5) | Impact after existing controls and completed actions. |
| Residual score | Formula: residual likelihood times residual impact. |
| Residual rating | Formula: the same bands as the inherent rating. |
| Acceptance approver | If the residual risk is accepted, who approved it. The policy sets who may accept each rating. |
| Acceptance expiry | When the acceptance lapses and the risk must be re-approved or treated. |
| Last reviewed | The date this entry was last reviewed or changed. |
The score is likelihood multiplied by impact, so it runs from 1 to 25. The rating bands and the response each one requires (for example, a treatment plan within five business days for a Critical risk) come from the policy; the policy also sets who may accept residual risk at each rating, in section 4, and the assessment and quarterly review procedure, in section 5.
How an auditor uses it
The risk assessment criteria sit in the CC3 series. The auditor reads the policy, asks for the register, and checks that the two agree and that the register was worked on during the period. What they look for under each criterion:
| Criterion | What the register has to show |
|---|---|
| CC3.1 Objectives for risk assessment | That objectives were set clearly enough to assess risks against them. The register's affected assets and the policy's risk appetite are where this shows. |
| CC3.2 Identifying and analyzing risks | That risks were identified and analyzed: a register with dated scores, owners and treatment decisions, and evidence the assessment ran inside the period. |
| CC3.3 Fraud risk | That fraud was considered. Auditors look for entries on misuse of privileged access or manipulation of records, not only external attackers. |
| CC3.4 Changes that affect risk | That changes which affect risk were assessed: new vendors, new infrastructure, incidents. Entries added or re-scored after such a change show this. |
Expect follow-up questions that test the link between risks and controls: pick a High risk and ask what treats it, or pick a control and ask which risk it answers. The existing controls column is where that answer should already be written. Monitoring (CC4.1) and vendor risk (CC9.1) often draw on the same register.
Common mistakes
- Copying scores from a template. Scores nobody at the company agreed are hard to defend when the auditor asks how they were reached. This template leaves them blank for that reason.
- Risks with no owner, or a team as owner. “Engineering” cannot make a treatment decision. Name a person.
- Accepted risks with no approver or expiry. Acceptance is a decision someone with the authority made, in writing, for a limited time. A blank approver column reads as no decision.
- A register that never changes. If the register looks the same after an incident, a new critical vendor or a major infrastructure change, it suggests changes are not being assessed (CC3.4).
- Only external attackers. Leaving out insider misuse, fraud, vendor failure and plain mistakes leaves CC3.3 without evidence.
- Scales that disagree with the policy. If you edit the scoring scales, edit the policy and the formulas too.
For the access side of the same audit, see the user access review template. For the evidence auditors collect across all criteria, see the SOC 2 evidence checklist.
Frequently asked questions
- Does SOC 2 require a risk register?
- SOC 2 requires a risk assessment (criteria CC3.1 to CC3.4), not a particular document. A register is the usual way to show the assessment happened: it records each risk, how it was scored, who owns it and what was decided. Expect the auditor to ask for it, or for an equivalent record.
- Why are the starter risks not scored?
- Because the scores are your judgment, and the auditor will ask how you reached them. A template that arrives pre-scored invites you to keep numbers nobody at your company decided. The ten starter risks are prompts: keep the ones that apply, edit them for your stack, delete the rest and add your own.
- What is the difference between inherent and residual risk?
- Inherent risk is scored as if the controls you rely on were not there. Residual risk is what remains after existing controls and completed actions. The gap between the two shows which controls matter, and residual risk is what someone has to treat or accept.
- How often should the risk register be updated?
- The Policyseed Risk Assessment and Management Policy commits to a formal assessment at least annually and after triggers such as a serious incident, a significant change or a new critical vendor, with High and Critical risks reviewed each quarter. Whatever cadence your own policy states, the register has to show it was followed.
- Can I change the 1-5 scales?
- Yes. The scales in the Scoring Scales sheet match the Policyseed Risk Assessment and Management Policy, and the rating formulas use its bands (15 and above Critical, 10 to 14 High, 5 to 9 Moderate, 1 to 4 Low). If your policy uses different scales or bands, change the policy, the sheet and the formulas together so they never disagree.
Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.