---
title: "Risk register: what to record, with an information security example"
canonical: https://www.grcmana.io/vault/risk-management/risk-register
published: 2023-11-01
updated: 2026-10-23
author: "Harry West"
framework: "Risk Management"
control: "Guide Risk register: what to record, with an information security example"
journeyStage: fundamentals
---

# Risk register: what to record, with an information security example

## Key takeaways

A risk register is the single record of an organisation's identified risks, each with a named owner, a score, existing controls, a treatment decision and a residual score. ISO 27001 never names a risk register, but it is where the documented risk assessment results and treatment plan usually live, linked to the Statement of Applicability and reviewed on a schedule and at significant change.

- **ISO 27001 and the risk register** — ISO/IEC 27001 never requires a document called a risk register. It requires documented risk assessment results, a risk treatment plan approved by risk owners, and a Statement of Applicability.
- **NCSC recommendation** — The NCSC's basic risk assessment and management method recommends a risk register to document assets, identify who is responsible for them and record how valuable they are to the business.
- **Review triggers** — ISO 27001 Clause 8.2 expects risk assessments at planned intervals and whenever a significant change is planned or happens. NCSC guidance adds changes in the threat or in system use.
- **Board reporting** — The UK Cyber Governance Code of Practice (April 2025) asks boards to agree senior ownership of cyber risks, define cyber risk appetite and require formal reporting at least quarterly.

The enterprise customer's security questionnaire has reached the risk section: "Do you maintain a risk register? Provide an extract showing owners, ratings and treatment." Your ISO 27001 Stage 1 audit is booked for the same quarter. What you have is a spreadsheet of worries that nobody has opened since it was made.

This guide shows what an information security risk register should record so the same document satisfies an ISO 27001 auditor and an enterprise customer. It is for founders, CTOs and security leads at UK B2B tech firms with 25 to 100 staff. It covers the columns, a worked example for a SaaS firm, how to write a risk statement, what goes to the board and when to review.

## What is a risk register?

A risk register is the single record of an organisation's identified risks, each with a named owner, a score, the controls already in place, the treatment decision and the residual score after treatment. For information security, the risk register is usually where ISO 27001's documented risk assessment results and risk treatment plan live.

The definition is deliberately plain. The register is a record of decisions, not a list of fears. Every row says who owns the risk, how bad it is, what is being done and whether the business has accepted what is left.

ISO/IEC 27001 never uses the phrase "risk register". Clause 6.1.2 requires a defined risk assessment process that identifies risk owners, and Clause 6.1.3 requires a risk treatment plan approved by those owners. Clauses 8.2 and 8.3 then require you to keep documented information of the assessment and treatment results. Our guide to [ISO 27001 Clause 6.1](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) walks through each requirement.

UK government guidance points the same way. The NCSC's [basic risk assessment and management method](https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method) recommends developing a risk register to document your assets, identify who is responsible for them and record how valuable they are to the business. For the method behind the entries, [ISO/IEC 27005](https://www.grcmana.io/vault/iso-27005) is the guidance standard that supports ISO 27001 risk work.

## What should a risk register include?

An information security risk register should include, for each risk: an ID, a risk statement, the asset or scenario affected, the threat and vulnerability, an owner, inherent likelihood, impact and score, existing controls, the treatment option, linked Annex A controls, a residual score, who accepted it and when, and a review date.

The table below shows each column, what it records, and whether an ISO 27001 auditor or an enterprise customer's questionnaire is likely to look at it. Auditors trace sampled risks through every column. Customers usually want evidence that a register exists, has owners and is reviewed, plus the treatment of risks that touch their data.

| Column | What it records | ISO 27001 auditor checks | Customer questionnaire asks |
| --- | --- | --- | --- |
| ID | A stable reference such as R-014, never reused | Yes, to trace a risk to the SoA and evidence | Rarely |
| Risk statement | Cause, event and consequence in one sentence | Yes, that it describes a risk, not an asset | Sometimes, in an extract |
| Asset or scenario | The information, system or process at risk | Yes, link to the asset inventory | Rarely |
| Threat and vulnerability | What could cause harm and the weakness it exploits | Yes, that identification followed the method | Rarely |
| Owner | A named person with authority to act | Yes, Clause 6.1.2 requires risk owners | Yes, "who owns security risk?" |
| Inherent likelihood, impact and score | The rating before current controls, or before treatment | Yes, against your documented criteria | Sometimes, as a rating |
| Existing controls | Controls already operating | Yes, that they exist and are evidenced | Sometimes |
| Treatment option | Modify, retain, avoid or share | Yes, a decision for every risk above the line | Yes, for risks touching their data |
| Linked Annex A controls | The controls that deliver the treatment | Yes, the thread to the Statement of Applicability | Rarely |
| Residual score | The rating after treatment | Yes, that it was recalculated | Sometimes |
| Acceptance (by whom, when) | The risk owner's sign-off on what remains | Yes, Clause 6.1.3 requires owner approval | Rarely |
| Review date | When the risk was last reviewed and is next due | Yes, read alongside the change history | Yes, "how often is it reviewed?" |

If you are starting from nothing, the owner, statement, scores, treatment and review date are the columns that do most of the work. The others turn a list into an audit trail. The scales behind the scores, and how to calibrate them, belong in your risk methodology rather than the register itself.

## How do you write a good risk statement?

Write a risk statement as cause, event and consequence: because of a cause, an event may happen, which would lead to a consequence for the business. A good risk statement names the threat, the weakness it exploits and the business harm, so an owner can act on it and an auditor can see why the controls exist.

Compare two entries for the same concern:

- **Weak:** "Customer database."
- **Weak:** "Data breach."
- **Strong:** "Because administrator accounts for the production cloud environment are protected by passwords alone, a phishing attack could give an attacker control of the customer database, leading to a reportable personal data breach and loss of enterprise contracts."

The strong version tells the owner where to act (authentication), tells the auditor which controls should follow, and tells the board why it matters. The NCSC method makes a related point: write risk statements that help decision makers understand the timescales and the uncertainty involved, rather than implying the risk is certain to happen exactly as described.

Keep one risk per row. A statement joined by "and" usually hides two risks with different owners and different treatments.

## What does an information security risk register example look like?

An information security risk register for a SaaS firm might hold five rows like the example below: account takeover through phishing, a cloud region outage, a leaver keeping access, a sub-processor breach and secrets leaked in source code. Each row carries an owner, an inherent and a residual score, the treatment and the Annex A controls behind it.

The scores below use a 1 to 5 likelihood and impact scale multiplied together, with an acceptance line of 8. The scale, the acceptance line, the scores and the review intervals are our illustration, not requirements of ISO 27001: your own methodology sets yours.

| ID | Risk statement (short) | Owner | Inherent (L x I) | Existing controls | Treatment | Annex A controls | Residual | Review |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| R-01 | Phishing captures an administrator password, giving control of production and customer data | CTO | 4 x 5 = 20 | Password policy, annual awareness training | Modify: phishing-resistant MFA, separate admin accounts | A.5.17, A.8.2, A.8.5, A.6.3 | 2 x 5 = 10, accepted by the CTO with a dated review | Quarterly |
| R-02 | An outage in the single hosting region stops the service and breaches availability commitments | Head of Engineering | 3 x 4 = 12 | Daily backups | Modify: multi-zone deployment, tested restores | A.5.30, A.8.13, A.8.14 | 2 x 3 = 6 | Six-monthly |
| R-03 | A leaver keeps access to code and cloud consoles because offboarding is manual | Head of People | 3 x 4 = 12 | Offboarding checklist | Modify: identity-provider deprovisioning, monthly access review | A.5.18, A.6.5, A.5.11 | 1 x 4 = 4 | Quarterly |
| R-04 | A sub-processor holding customer personal data suffers a breach | COO | 2 x 5 = 10 | Supplier contracts | Share and modify: security clauses, due diligence, cyber insurance | A.5.19, A.5.20, A.5.22 | 2 x 3 = 6 | Annually and on supplier change |
| R-05 | API keys committed to a repository are found and used to reach production | CTO | 3 x 4 = 12 | Code review | Modify: secret scanning in the pipeline, key rotation | A.8.4, A.8.28 | 1 x 4 = 4 | Quarterly |

Three things make this example audit-ready. Every row has a named owner, not a team. Every treatment points to Annex A controls, so the thread to the Statement of Applicability is visible. And R-01 shows an honest outcome: the treatment reduced the score, but not below the line, so the owner's acceptance is recorded with a date rather than left implied.

The example is information security only. Project registers that track delivery risks, assumptions and dependencies serve a different purpose and should stay separate from the register your auditor samples.

## How does the risk register link to the Statement of Applicability and the treatment plan?

The risk register is the start of a chain an auditor follows: a risk, its treatment decision, the Annex A control that delivers it in the Statement of Applicability, and evidence that the control operates. The risk treatment plan sets out the actions, owners and dates that move each risk from its inherent to its residual score.

ISO 27001 Clause 6.1.3 asks you to compare the controls you chose with Annex A and produce a Statement of Applicability. That statement lists the necessary controls, why each is included, whether it is implemented, and why any Annex A control is excluded. When the register's Annex A column is filled in, most of those justifications write themselves: a control is included because named risks need it.

The treatment plan can live inside the register as extra columns (action, action owner, due date, status) or as a linked list of tickets. Either works, as long as the register shows which actions belong to which risk. Risk owners approve the plan and accept the residual risk; the action owner who does the work may be someone else, so record both. Our guide to [ISO 27001 Clause 8.3](https://www.grcmana.io/vault/iso-27001/clause-8-3-information-security-risk-treatment) covers how to carry out the plan and keep the evidence.

A Statement of Applicability that cannot point back to a risk is a list of controls you happen to have.

## What goes on a board risk register versus an operational one?

An operational risk register holds every identified information security risk at full detail and is maintained by the security lead and risk owners. A board risk register, or board risk report, shows a short list of top risks, their trend, anything above the agreed risk appetite and any acceptance that needs board-level sign-off.

The two should come from the same data. A separate board spreadsheet soon drifts from the operational register, and then the board is governing a different set of risks from the ones being managed.

The government's [Cyber Governance Code of Practice](https://www.gov.uk/government/publications/cyber-governance-code-of-practice/cyber-governance-code-of-practice), published in April 2025, sets out what boards should do. It asks boards to agree senior ownership of cyber security risks, to define the organisation's cyber risk appetite, and to require formal reporting at least quarterly with agreed metrics and tolerances. The Code was designed for medium and large organisations, and says small organisations should also seek to apply its principles.

The Code does not say which risks to escalate. As a starting point, we recommend escalating these to the board (our guidance, not the Code's):

1. Any risk whose residual score sits above the agreed appetite.
2. Any proposed acceptance above a threshold the board has set for itself.
3. Any new risk rated in your highest band, between scheduled reports.
4. The movement of the top risks since the last report, with the reason for each change.

Some enterprise questionnaires ask how the board oversees security risk. A short, regular board report drawn from the register is a straightforward answer.

## When should you review a risk register?

Review a risk register on a schedule and whenever something significant changes. ISO 27001 Clause 8.2 expects the risk assessment to be repeated at planned intervals, and again whenever a significant change is planned or happens. Incidents, near misses, new products, new suppliers and changes in the threat picture should all prompt a review of the affected risks.

The NCSC's guidance treats risk management as continuous. It says to revisit assessments and controls at regular intervals, and immediately when something significant changes, such as a change in the threat or in how a system or service is used. Our guide to [ISO 27001 Clause 8.2](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment) covers how to set a cadence an auditor will accept.

Write your review triggers down in advance, so "significant change" is not decided after the event:

- **Scheduled:** a quarterly pass of the top risks and a full annual review is a sensible starting point for a firm of 25 to 100 staff (our suggestion, not a requirement).
- **Significant change:** a new product or major feature, a new hosting region, an acquisition, a new critical supplier, or a change in the data you process.
- **Incident:** any security incident or near miss, with the related risks re-scored once it is closed.
- **External:** a new regulatory obligation or a new customer contract with security terms.

## Should you keep a risk register in a spreadsheet or a tool?

A spreadsheet is enough for a first ISO 27001 or SOC 2 cycle if it has the right columns, named owners, controlled access and a change history. A dedicated tool starts to earn its cost when many owners update risks, when risks must link to controls and evidence across several frameworks, or when reporting takes too long by hand.

Choose on the job the register has to do, not on the format:

- **A spreadsheet works when** one person maintains it, there are a few dozen risks, there is one framework, and version history is switched on so the auditor can see when entries changed.
- **A tool helps when** owners across several teams update their own risks, risks link to controls, tickets and evidence, you report against ISO 27001 and SOC 2 together, or acceptances need reminders before they expire.

Either way, the auditor and the customer judge the content: owners, decisions, dates and evidence. A well-kept spreadsheet beats an expensive tool that nobody updates.

## What are the common mistakes in an information security risk register?

The most common mistakes in an information security risk register are listing assets instead of risks, leaving risks without a named owner, setting scores once and never revisiting them, and recording treatments that are not linked to any control. Each one breaks the trail an auditor follows from risk to evidence.

- **Assets listed as risks.** "Laptops" or "AWS" is not a risk. Rewrite each entry as cause, event and consequence.
- **No named owner.** "IT" or "Engineering" cannot accept a residual risk. Clause 6.1.2 expects risk owners, and a team is not a person.
- **Scores never revisited.** A residual score identical to the inherent score after treatment raises the question of whether anything was done. Dates that never move tell the same story.
- **Controls not linked.** A treatment of "improve security" cannot be traced to the Statement of Applicability or tested.
- **Acceptance by silence.** A risk above the line with no recorded acceptance is an open finding, not a decision.

## Frequently asked questions

### Is a risk register mandatory for ISO 27001?

No document called a risk register is mandatory, but the records it usually holds are. The results of each assessment and of treatment must be kept as documented information, and Clause 7.5 expects that information to be controlled like any other ISMS record: versioned, protected and available when needed. A register is the simplest way to keep those records in one place, with each risk's results and treatment side by side.

### Who should own the risk register?

One person, usually the security lead or the person responsible for the ISMS, should maintain the register as a whole. Each risk then has its own owner: a named person with the authority and budget to act on it. Ownership of the register and ownership of the risks are different jobs, and the register should show both.

### What is the difference between a risk assessment and a risk register?

A risk assessment is the activity: identifying, analysing and evaluating risks using your agreed method. The risk register is where the results are recorded and then kept current through treatment and review. An auditor will want to see both the method you followed and the register it produced.

### Can one risk register cover ISO 27001 and SOC 2?

Yes. SOC 2's common criteria include a risk assessment group (CC3), and the same risks, owners and treatments can support both. Add a column that maps each risk's controls to the relevant SOC 2 criteria, next to the Annex A references. One register then feeds both the Statement of Applicability and the SOC 2 control set.

### Should we share our risk register with customers?

Rarely in full. The register describes your weaknesses in detail, so we recommend sharing a summary or an extract under a non-disclosure agreement. Show that a register exists, how it is owned and reviewed, and how risks affecting the customer's data are treated. Agree in advance what you will share, so a questionnaire does not force a rushed decision.