How to run a compliance risk register
Your customer's security team wants to see your risk register. Here is what a proper one looks like.
A compliance risk register is the central source of truth for the risks your organisation carries. It tracks what could go wrong, who owns the problem, and how you plan to fix it. To stay compliant, each entry must be scored for likelihood and impact, mapped to a concrete treatment plan, and reviewed on a strict schedule.
While ISO/IEC 27001:2022 requires you to document your risk assessment and treatment, running a register properly ensures you have the exact evidence a customer's security team wants to see before clearing your contract.
Does ISO 27001 require a risk register?
ISO/IEC 27001:2022 does not use the phrase "risk register" or mandate one by name. It requires you to assess information security risks against defined acceptance criteria, identify risk owners, analyse consequence and likelihood, treat those risks, and keep the results as documented information, under clauses 6.1.2, 6.1.3 and 8.2. A register is how you hold all of that in one place.
For a founder clearing a procurement gate, the distinction matters. A buyer's security questionnaire rarely asks "do you hold a register". It asks who owns your top risks, what you have done about them, and how you know the picture is current. A well-built register answers all three in one view. A spreadsheet usually answers none of them a year later, because a spreadsheet has no owner, no sign-off and no memory of what changed.
This is the layer Naq's Risks module is built around, so the rest of this article walks through how a proper register is structured and shows a worked example against those clauses. You can read the wider requirement on the ISO 27001 framework page.
What is the difference between inherent and residual risk?
Inherent risk is the exposure before any controls are applied. Residual risk is what remains once the controls are in place and working. A register that records both shows what a control actually changed, rather than asserting the risk is handled. ISO 27001 requires you to accept the residual level explicitly; capturing the inherent score alongside it is good practice.
Recording only one number hides the reasoning. If a register shows a single "current" score, an auditor or a customer cannot tell whether the risk was always low or whether real work brought it down. Two scores, before and after, tell that story on the record.
In Naq, the owner sets both. You enter an inherent likelihood and impact, then a residual likelihood and impact once treatment is defined. The gap between them is the evidence that your controls are doing something.
How should you score a risk?
Score each risk on two axes, likelihood and impact, using a fixed scale so scores stay comparable across the register. In Naq this is a 5×5 matrix with named descriptors on each axis. You set the likelihood and impact; the platform multiplies them into a rating and assigns a band: Low 1 to 5, Medium 6 to 12, High 13 to 19, Critical 20 to 25.
The division of labour is deliberate. The judgement stays with the person who owns the risk, because likelihood and impact are decisions, not calculations. The platform handles only the parts that should never vary by mood or memory: the multiplication, the banding, and the review cadence that follows from the band. Nothing infers a score for you.
Fixed bands keep a register honest. When every owner works to the same scale, a High on one risk means the same as a High on another, and the register can be read as a single picture rather than a collection of personal opinions.
What are the risk treatment options?
There are four ways to treat a risk: reduce it, avoid the activity that causes it, transfer it to a third party such as an insurer, or accept it as it stands. ISO/IEC 27005:2022, the guidance standard that sits alongside ISO 27001, names these as Modify, Avoid, Share and Retain. Naq's four strategies, Reduce, Avoid, Transfer and Accept, map directly onto them.
The treatment is only as good as the work behind it, which is why in Naq a treatment plan links to the Controls that carry it out. A control such as "enforce MFA on all privileged accounts" can satisfy requirements across ISO 27001, Cyber Essentials and other frameworks at the same time. So the work you do to bring one risk down counts once and is reused everywhere that control applies, rather than being re-evidenced framework by framework. That reuse is covered in full in reuse compliance evidence across frameworks.
Where the risk is a data-protection exposure, one of Naq's in-house virtual DPOs can make the controller-level call on whether the residual level is acceptable, so the sign-off carries the right authority.
A worked example: RISK-014
A third-party support vendor holds standing administrator access to your production environment. The owner opens RISK-014 and scores the inherent exposure: likelihood 4, impact 4, a rating of 16, which bands as High.
The treatment strategy is Reduce. The plan links to three Controls: enforce MFA on the vendor account, replace the standing access with time-limited just-in-time access, and run quarterly access reviews. Because those Controls also answer requirements in other frameworks, the work is logged once and counted wherever it applies. With the plan in place, the owner sets the residual score: likelihood 2, impact 2, a rating of 4, which bands as Low.
The owner submits RISK-014 with a comment explaining the reasoning. A different person, never the owner, reviews it and accepts the residual Low. That separation is exactly what ISO 27001 clause 6.1.3 f expects when someone signs off residual risk. On a spreadsheet, "16, High" could sit untouched for a year, with nobody accountable and nothing on record about who judged it acceptable.
Naq enforces a best-practice separation of duties to ensure compliance with 6.1.3 f isn't just a self-signing exercise
Who should own and approve a risk?
Every risk needs one person accountable for it and a second, different person to approve the treatment and accept the residual level. In Naq the owner drafts and submits; a separate approver signs off; the owner can never be the approver on the same record. Every step, submit, approve, request changes, revoke or close, requires a written comment.
The separation earns its place. ISO 27001 clause 6.1.3 f expects risk owners to approve the risk treatment plan and accept the residual risk, which only means something if the person accepting the risk is distinct from the person who scored it down. The mandatory comment leaves a reason on the record, so a year later anyone reviewing the risk can see not just what was decided but why.
Records are archived, never deleted, and each review cycle needs fresh sign-off. Nothing stays approved forever. The full activity trail behind this, including before and after values on every change, is covered in what makes a compliance audit trail audit-ready.
How often should you review a risk?
Review frequency should follow the size of the risk, so your attention goes where the exposure is greatest. In Naq the cadence is set by the band: Critical every 3 months, High every 6, Medium every 12, Low every 24. The approver can shorten any of these. The rating sets a floor on how long a risk can go unexamined, not a ceiling.
This is how ISO 27001 clause 8.2 reads in practice. The standard asks you to perform risk assessments at planned intervals and to retain the results. A rating-driven cadence turns "planned intervals" into a concrete date attached to each risk, rather than a good intention that slips.
What should trigger an unscheduled review?
A scheduled review is not enough on its own, because risk changes between dates. A register should let you reassess early when something material happens. Naq supports event-based reassessment triggers: an incident, a control failure, a change to a system, deployment, supplier or regulation, or a major release. Any of these can pull a risk forward for a fresh look before its next scheduled date.
Return to RISK-014. Its residual Low sits on a 24-month default cadence, but you would reassess it early if the vendor changed sub-processor, the data processing agreement lapsed, one of the linked Controls failed, or there was an incident involving that access. This is the second half of ISO 27001 clause 8.2: assess at planned intervals or when significant changes occur. A register that only runs on the calendar misses the changes that move a risk between reviews.
FAQ
Does ISO 27001 require a risk register?
Not by name. ISO/IEC 27001:2022 requires you to assess and treat information security risks against defined acceptance criteria, identify risk owners, and keep the results as documented information, under clauses 6.1.2, 6.1.3 and 8.2. A risk register is the practical way to hold all of that in one place.
What is the difference between inherent and residual risk?
Inherent risk is the exposure before any controls are applied. Residual risk is what remains after the controls are in place. Recording both shows what your controls actually changed, and ISO 27001 requires you to accept the residual level explicitly.
What are the four risk treatment options?
Reduce, avoid, transfer or accept. ISO/IEC 27005:2022 names these as Modify, Avoid, Share and Retain. A treatment plan should link to the specific controls that carry it out, so the work is traceable and reusable across frameworks.
Who should own and approve a risk?
One person owns and drafts the risk; a separate person approves the treatment and accepts the residual level. The owner should never approve their own risk. ISO 27001 clause 6.1.3 f expects that separation when residual risk is accepted.
How often should you review a compliance risk?
As often as its rating warrants. A common approach is Critical every 3 months, High every 6, Medium every 12 and Low every 24, with the ability to review sooner. The rating sets the maximum gap, not a fixed date.
What should trigger an unscheduled risk review?
A security incident, a control failure, a change to a system, supplier or regulation, or a major release. ISO 27001 clause 8.2 asks you to reassess at planned intervals or when significant changes occur, so material events should pull a review forward.
See how Naq structures your risk register
