Free Risk Register Template with Scoring Example

Get a copy

Drop your details, grab the template.

What's inside

Format: XLSX
Category: Risk
Price: Free

Asurvo customers get this template preloaded in their workspace, along with hundreds of other starter documents.

See Asurvo in action Browse all templates

Risk register

Field by field: building a risk register that drives decisions

A risk register is only useful if someone makes a decision because of it. Registers that list forty vague risks, all scored amber, with no owners and no dates, satisfy nobody: not the auditor, not leadership, and not the engineer asked to fix something. This template gives you a starting structure with inherent, residual, and target scoring. The guidance below explains what each field is for, how to score consistently, and what reviewers look for.

The fields and why each exists

Field, What to capture, Common failure comparison
Field	What to capture	Common failure
Risk ID	A stable unique reference that never gets reused	Renumbering rows so history and linked actions break
Risk statement	Cause, event, and consequence in one sentence	Writing a topic, such as 'ransomware', instead of a risk
Category	Security, privacy, operational, third party, compliance, and so on	Too many categories to report on meaningfully
Assets or processes affected	Systems, data sets, or business processes exposed	Left blank, so impact cannot be judged
Risk owner	A named role accountable for the risk and authorized to accept it	Assigning everything to the security team
Existing controls	Controls already operating that reduce the risk, ideally linked to control IDs	Listing planned controls as if they were in place
Inherent likelihood and impact	Scores before considering existing controls	Skipping inherent scoring, which hides how much you rely on controls
Residual likelihood and impact	Scores with existing controls operating as designed	Residual equal to inherent on every row
Treatment decision	Accept, mitigate, transfer, or avoid, with rationale	Choosing mitigate by default with no plan behind it
Treatment actions	Specific tasks, owners, and due dates	Actions with no date or a date that silently passes
Target score	Residual level expected once treatment completes	Target above the organization's acceptance threshold
Review date and status	Last reviewed, next review, open or closed	No review history, so staleness is invisible

Writing a risk statement that can be scored

A useful pattern is: because of a cause, there is a risk that an event occurs, which would lead to a consequence. For example: because production database credentials are stored in developer laptops, there is a risk that a stolen or compromised laptop exposes the credentials, which would lead to unauthorized access to customer records and regulatory notification. That statement tells you which controls matter, who should own it, and what impact to score. A statement like 'data breach' tells you none of that.

Worked scoring example

Assume a 5 by 5 matrix where likelihood and impact are each scored 1 to 5 and the risk score is the product, giving a range of 1 to 25. Assume the organization's documented acceptance threshold is a score of 6 or below. The scales themselves should be defined in your risk assessment methodology so that two assessors give the same risk the same score.

One risk scored three times

One risk scored three times
Stage	Likelihood	Impact	Score	Reasoning
Inherent	4	5	20	Credentials on endpoints are commonly targeted; access exposes regulated customer data
Residual	3	5	15	Full-disk encryption and EDR reduce likelihood; impact unchanged if the attack succeeds
Target	1	5	5	Planned: move credentials to a secrets manager with short-lived access and remove local copies

Notice that impact stays at 5 throughout. Most technical controls reduce likelihood; impact usually drops only through measures such as data minimization, segmentation, or tokenization. If a register shows impact falling sharply because of a detective control, question the logic. Here the residual score of 15 exceeds the threshold, so the owner cannot simply accept it; treatment is required, and the target of 5 falls within appetite once actions complete.

Choosing a treatment

Mitigate: implement or strengthen controls. Requires actions, owners, and dates.
Transfer: shift financial impact through insurance or contract. The risk event can still happen, so reputational and operational impact often remain.
Avoid: stop the activity that creates the risk, such as retiring a legacy system.
Accept: a documented decision by an owner with authority, within the acceptance criteria, with a review date. Acceptance is legitimate; undocumented acceptance is not.

ISO/IEC 27001:2022 clause 6.1.3 expects risk owners to approve the treatment plan and accept the residual risk. Keep that approval as a recorded decision, not an assumption.

Where the register fits the frameworks

ISO 27001 requires risk assessment and treatment in clauses 6.1.2 and 6.1.3 and requires assessments to be performed at planned intervals or when significant changes occur (clause 8.2), with results retained. Annex A controls selected for treatment feed the statement of applicability. SOC 2 addresses risk identification and analysis in CC3.2, and changes that could affect internal control in CC3.4. The HIPAA Security Rule requires both a risk analysis and risk management under §164.308(a)(1)(ii)(A) and (B). NIST CSF 2.0 covers this in ID.RA and the GV.RM category.

What auditors check

Scores are consistent with the documented methodology and scales
Every risk has an owner with the authority the methodology requires
Risks above threshold have treatment actions with dates, and overdue actions are visible
Acceptance decisions are recorded with approver and date
Existing controls listed in the register actually exist and link to tested controls
Evidence of periodic review, such as dated review records or minutes
New risks were added after significant changes such as a new product, vendor, or incident

Spreadsheets work well for a first register, but version drift and broken links between risks, controls, and actions set in as the register grows. The guide to building a risk register goes deeper on process, and Asurvo's Risk Management product keeps inherent, residual, and target scores, treatment plans, owners, and deadlines in one place with heatmaps and trends.

FAQ

Frequently asked questions

What columns should a risk register have?

At minimum: a unique ID, a risk statement, category, affected assets or processes, risk owner, existing controls, inherent likelihood and impact, residual likelihood and impact, treatment decision, treatment actions with owners and dates, target score, and review dates. Add columns only if someone will use them for a decision or report.

What is the difference between inherent, residual, and target risk?

Inherent risk is the level before existing controls are considered. Residual risk is the level with current controls operating. Target risk is the level expected after planned treatment is complete. Comparing the three shows how much you depend on controls and whether planned work will bring the risk within appetite.

How often should a risk register be reviewed?

Many organizations review high risks monthly or quarterly and the full register at least annually, plus whenever significant changes occur such as new systems, suppliers, or incidents. ISO 27001 requires assessments at planned intervals and on significant change, so define the cadence in your methodology and keep records of each review.

Who should own risks in the register?

The person with accountability for the affected business area and authority to fund treatment or accept the risk, usually a senior manager or department head. The security team facilitates assessment and tracks the register but should not own every risk, since it rarely controls the budget or process involved.

Is a 5 by 5 matrix required?

No. ISO 27001 and SOC 2 do not prescribe a matrix size. A 5 by 5 scale is common because it offers enough granularity without false precision, but 3 by 3 and 4 by 4 are also used. What matters is that scales are defined, applied consistently, and produce comparable results.

Keep exploring

Risk Register