A risk register is the single authoritative list of risks your organisation has identified, who owns them, what you are doing about them, and what remains once you have done it. It is mandatory in substance for ISO 27001, the NCA ECC, SAMA CSF and SOC 2 - and it is the artefact most likely to be out of date when the auditor asks.
The columns that matter
- Risk ID - stable and unique, never reused.
- Title and description - written as cause, event, consequence: "Because X, Y could happen, resulting in Z."
- Category - cyber, operational, third party, regulatory, financial.
- Affected asset, process or service.
- Existing controls - what already reduces this risk today.
- Likelihood and impact (1-5 each) and the resulting inherent score.
- Risk owner - a named individual with budget authority.
- Treatment strategy - mitigate, transfer, avoid, accept.
- Treatment actions, each with its own owner and due date.
- Residual score and acceptance (who accepted it, and when).
- Status - open, treated, accepted, closed - plus next review date.
- Linked controls - which framework controls mitigate this risk.
That last column is what turns a register into a compliance asset: it lets you show an auditor exactly which control addresses which risk.
Writing risks that are actually useful
Weak entries read like categories. Strong entries read like scenarios:
- Weak: "Phishing."
- Strong: "Because staff are not trained on credential phishing and MFA is not enforced on the VPN, an attacker could obtain valid credentials, resulting in unauthorised access to customer data."
The strong version tells you what to fix, and makes likelihood and impact scoreable.
A risk register that maintains itself
GRC Copilot keeps your register linked to live control and evidence status, surfaces overdue treatment, and produces the board and audit views automatically.
Try GRC Copilot free Generate an AI-powered assessment Download the template Book a demo
Governance: the part that keeps it alive
- Set escalation thresholds. For example: score 1-6 managed locally, 8-12 reported to the security committee, 15+ escalated to the executive with a mandatory treatment plan.
- Review on a defined cadence - high risks monthly, medium quarterly, low annually.
- Trigger reviews on change - new system, new supplier, incident, acquisition, regulatory change.
- Require written acceptance for any residual risk above appetite, signed by someone with authority to accept it.
- Report trends, not just snapshots. Boards want the direction of travel and the overdue-treatment count.
If every risk in your register is green and nothing has changed in twelve months, the register is not being used - and an auditor will notice.
Frequently asked questions
What is the difference between a risk register and a risk assessment?
The assessment is the exercise that identifies and scores risks; the register is the living record that tracks them, their owners and their treatment over time.
How many risks should a register contain?
Enough to reflect reality and few enough to manage. Most mid-sized organisations run 30 to 80 active entries. Hundreds of unreviewed rows is a sign of a register nobody governs.
Can we accept a high risk?
Yes, provided the acceptance is explicit, justified, time-bound and signed by someone with the authority to accept it. Undocumented acceptance is what auditors flag.
Should risks link to controls?
Yes. Linking risks to the controls that mitigate them lets you demonstrate control effectiveness and reuse the same evidence across frameworks.
Key takeaways
- Write risks as cause, event and consequence - not one-word categories.
- Every risk needs a named owner, a treatment decision and a review date.
- Define escalation thresholds so governance is automatic, not discretionary.
- Link risks to controls to prove mitigation and reuse evidence.