The risk register your auditor wants to see

An ISO 27001 assessor will read three rows of your risk register and know roughly how the rest of the audit is going to go. What they are looking for is not sophistication. It is evidence that the register is used.

Written by Apexward Assure editorial team
Reviewed by Apexward Assure product team
Last reviewed: 30 August 2026

What the assessor is checking for

Registers fail audits for boring reasons. Every row was created on the same date. Every owner is “IT”. Every review date is in the past. Nothing has ever been closed. The assessor is not judging your risk analysis, they are checking whether the register is a live management tool or a document produced for them. The first thing they look at is the distribution of dates in the columns, and that tells them almost everything before they read a single risk description.

The good news is that a register that passes this test is not elaborate. Ten to forty real risks, honestly maintained, beats two hundred imported from a template. What matters is that each row carries enough structure to be acted on.

The fields that actually matter

  • Identifier. A stable reference such as R-014 that never gets reused. You need it so that minutes, actions and evidence can point at a risk rather than describe it.
  • Description. Written as cause, event, consequence. See below, because this is where most registers go wrong.
  • Owner. A named individual with the authority to accept the risk or fund its treatment. If the owner cannot make that decision, the risk is parked, not owned.
  • Date raised. Trivial, and one of the first things an assessor sorts by.
  • Inherent rating. Likelihood and impact before your existing controls are taken into account.
  • Existing controls. What is already in place, referenced to your control set rather than described in prose.
  • Residual rating. Likelihood and impact with those controls working. The difference between the two numbers is the argument for why the controls are worth having.
  • Treatment decision. Treat, tolerate, transfer or terminate, with a date and the name of whoever decided. A tolerated risk is a legitimate answer, but it has to be an explicit one.
  • Actions. If the decision is to treat, what is being done, by whom, by when. An action with no due date is a wish.
  • Next review date. The column that proves the register is alive.

Write risks as cause, event, consequence

“Ransomware” is not a risk, it is a noun. “Cyber attack” is worse, because it covers everything and therefore commits to nothing. Neither can be scored, treated or closed, which is why registers full of them never change.

The usable form names all three parts: because of some cause, an event may occur, leading to a consequence. For example: “Because engineering laptops are not enrolled in device management, a lost or stolen laptop may expose unencrypted customer data, leading to notifiable personal data breach and contractual penalties.” That sentence contains its own treatment plan. You can see what to fix, you can see what to measure, and you can see when it is no longer true.

A useful discipline: if you cannot say what would have to change for the risk to be closed, the description is not specific enough yet.

Scoring without inventing precision

A 5x5 matrix multiplies two guesses and presents the result to three significant figures of apparent confidence. Nobody can distinguish a likelihood of 3 from a likelihood of 4 for an event that has never happened to them, and the resulting score of 12 versus 16 carries no real information. This is worth being honest about, because the pretence is what makes people cynical about the whole exercise.

Use the matrix anyway, but use it as a sorting mechanism rather than a measurement. Three things make it defensible:

  • Define the scale in your own terms. Impact 4 should mean something like “loss of a top-ten customer or more than 30,000 pounds of unbudgeted cost”, not “major”. Likelihood 4 should mean “expected at least once a year”, not “likely”. Written definitions turn a subjective score into a repeatable one, and they are what an assessor asks to see when they question a rating.
  • Score in a room, not alone. Two people disagreeing about whether something is a 3 or a 4 usually surfaces a difference in understanding that is more valuable than the score.
  • Publish the appetite. Decide in advance which scores require treatment, which require sign-off to tolerate, and which are accepted by default. Without that threshold, the score is decoration.

If the exercise feels overbuilt for your size, a three-point scale with clear definitions is better than a five-point scale with vague ones. No assessor has ever objected to a smaller matrix that is used consistently.

Four failure modes

The register written once. All rows dated within the same fortnight, twelve months ago, with no closures and no additions. It reads as what it is: a deliverable, not a process.

Issues masquerading as risks. “We have no backup for the file server” is not a risk, it is a fact about today. Risks are about things that might happen. Present-tense problems belong on an action list with an owner and a date, and a register clogged with them hides the risks that need judgement.

Everything is medium. When nothing is high, nothing gets funded, and when nothing is low, nothing gets closed. A register where 80 per cent of rows share one rating has stopped discriminating, which is its only job. Force a ranking: if you could only treat three of these this quarter, which three?

Residual equals inherent. If the two ratings are identical across the register, either your controls do nothing or nobody re-scored after implementing them. Both are findings.

Linking risks to controls is what turns a register into evidence

This is the step that most small organisations skip and the one that changes the character of the document. When each risk names the specific controls that treat it, and each of those controls has evidence that it is operating, the register stops being an opinion and becomes a claim you can support.

It also works in the other direction, which is where the audit value sits. An assessor picks a control from your statement of applicability and asks why you implemented it. If the control points back at the risks it treats, the answer is immediate and specific rather than “the standard asked for it”. That connection between risk, control and evidence is what ISO 27001 assessors are actually testing when they ask about your risk process, and it is the same connection the Defence Cyber Certification expects at Level 2.

Practically, add one column: the control references that treat this risk. Then, at each review, check that those controls still have current evidence. A risk treated by a control whose last evidence is fourteen months old has not really been treated.

Review cadence

Quarterly review of open risks with the owners, annually for the whole register including closed items, and immediately on any significant change: a new system, a new customer segment, an acquisition, an incident. Record the review as a dated entry even when nothing changes, because “reviewed 27 April 2026, no change” is evidence and a blank column is not.

Where a platform earns its place

A spreadsheet with the columns above, reviewed quarterly, will pass an audit. What it will not do is keep the link between a risk, the controls treating it and the evidence that those controls are working, because that link has to be maintained by hand in three places. Apexward Assure holds the register alongside the control set, so a risk points at live controls, those controls carry checksummed evidence with expiry tracked, and an assessor given a scoped read-and-question role can follow the chain themselves without you assembling a pack. The platform is free, so moving your existing register into the compliance module to see what the mapping looks like costs nothing.