A small team can run a useful risk register with ten columns: ID, scenario, asset, likelihood, impact, rating, owner, treatment, next action, and review date. Write each risk as a sentence that names a cause and a consequence, and keep the whole list short enough to review in one meeting.
The ten columns
- ID. A stable number so you can reference it in tickets and minutes.
- Scenario. One sentence: who or what does what, to which asset, with what result.
- Asset. The system, data set or service at stake.
- Likelihood. A rating from your own written scale.
- Impact. A rating from a second written scale.
- Rating. The combined result, from a lookup table you defined.
- Owner. One person with authority over the asset or the budget.
- Treatment. Reduce, avoid, share, or accept.
- Next action. A concrete task with a date, or the acceptance note.
- Review date. When someone must look at this entry again.
A worked example row
- Scenario: A contractor's stolen laptop gives an attacker access to our source code host.
- Asset: Source code repositories.
- Likelihood: Medium. Impact: High. Rating: High.
- Owner: Head of engineering.
- Treatment: Reduce. Require hardware backed sign in and device checks for contractor accounts.
- Next action: Enforce by end of quarter. Review in 90 days.
Notice there is no tool name, no vulnerability number and no jargon. A manager outside security can read it and decide.
Define the scales before you score
Write down what each level means. "High impact" could mean customer data for more than a set number of people, a service outage longer than a set time, or a contract loss. Pick definitions that fit your business and put them on a second tab.
NIST SP 800-30 makes a related point: qualitative values are more repeatable when each is clearly defined and annotated with the reason, such as "this is high because of the following". Add a rationale column if scores keep getting argued.
Common mistakes
- Scoring controls instead of scenarios. Control status belongs in a separate tracker.
- Giving a risk to a team, not a person. Teams do not accept risk, people do.
- Skipping the review date. An undated entry never gets revisited.
- Letting every item sit at "medium". If nothing is high or low, the scales are too vague.
Keep the template boring
Resist adding columns for every framework you might need. You can map risks to SOC 2, ISO 27001 or HIPAA requirements later with a lookup. Start with what leadership needs to decide, then add fields only when someone asks a question the register cannot answer.
Quick check
Do I need risk software?
Not at first. A shared spreadsheet with edit history works. Move to a tool when reviews and approvals become hard to track.
Who should own the register itself?
Security usually maintains it, but each risk needs a business owner outside the security team.
Sources
Last reviewed: 19 October 2026.
