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

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 walks through each requirement.

UK government guidance points the same way. The NCSC's 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 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.

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.

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 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, 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 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