A cyber security risk register is a living log that names every security risk your business faces, rates how likely it is and how bad the impact would be, and assigns someone to own the fix. Build one by listing assets and threats, scoring each risk on a 5x5 likelihood-and-impact matrix, mapping entries to the controls in ISO 27001:2022 Annex A, and reviewing the whole register at least quarterly. The part most businesses miss: a register with no assigned owner and no review date is just a spreadsheet nobody reads, and auditors flag it immediately.
Why this matters
A cyber security risk register is the document every ISO 27001 or SOC 2 auditor asks for first. Without it, you can't show you identified risks systematically rather than reacting to whatever broke last week.
The register also does real work outside the audit: it forces a decision on every risk (fix it, accept it, transfer it, or avoid it) instead of letting it sit unaddressed. Risk register software built for ISO 27001 programmes removes the spreadsheet-maintenance problem that kills most registers within six months.
How do you build a cyber security risk register?
Build a cyber security risk register in seven steps, in this order:
- List your assets - systems, data, third parties, physical sites. Anything with a risk attached needs a line.
- Identify threats and vulnerabilities per asset - a customer database has different risks than an office Wi-Fi router.
- Score likelihood and impact on a 5x5 scale (1 = rare/negligible, 5 = near-certain/severe). Multiply the two for a risk score from 1 to 25.
- Set a risk appetite threshold - most SMEs treat anything scoring above 15 as requiring immediate action.
- Assign an owner to every risk above your threshold, by name, not by department.
- Choose a treatment: mitigate, accept, transfer (insurance, contract clauses), or avoid.
- Set a review cadence - quarterly at minimum, and after any material change (new vendor, new system, new office).
| Column | What goes in it |
|---|---|
| Risk ID | Sequential number for tracking |
| Description | Plain-language statement of the risk |
| Asset affected | System, data set, or process |
| Likelihood (1-5) | How probable is this in the next 12 months |
| Impact (1-5) | Financial, operational, reputational damage |
| Risk score | Likelihood x impact |
| Owner | Named individual |
| Treatment | Mitigate / accept / transfer / avoid |
| Review date | Next scheduled reassessment |
This table is the skeleton of every functioning cyber security risk register in 2026, whether it lives in a spreadsheet or in dedicated software.
Mapping your risk register to ISO 27001 Annex A
ISO 27001:2022 lists 93 Annex A controls across four themes: organisational, people, physical, and technological. Your register doesn't need an entry for all 93 - only the ones relevant to your risk landscape - but every risk you do log should point to the control(s) that address it.
A gap analysis before ISO 27001 certification is the fastest way to spot which controls you're missing before an auditor does. Run it before you finalise the register, not after.
Why risk ratings vary from business to business
Two companies with identical systems can score the same risk differently. The factors that drive that variance:
- Data sensitivity - a healthcare record carries a higher impact score than a marketing email list.
- Regulatory exposure - GDPR, PCI DSS, or DORA obligations raise the impact rating for the same technical failure.
- Third-party dependency - risks tied to vendors you don't control usually score higher on likelihood.
- Existing controls - a risk with MFA and monitoring already in place scores lower on likelihood than the same risk with neither.
- Business size and single points of failure - a small team with one IT admin has a higher impact score for staff-absence risk than a company with redundancy.
- Historical incidents - a risk that's already caused a breach or near-miss should carry a higher likelihood score going forward.
Related questions
How does a risk register differ from a vendor risk assessment?
A cyber security risk register tracks internal and external risks to your business broadly, while a vendor risk assessment focuses specifically on third-party suppliers before and during a contract. If you rely on multiple vendors, a structured vendor risk assessment process feeds directly into your register as a distinct set of entries.
Does Cyber Essentials require a risk register?
Cyber Essentials does not require a risk register - it's a control-based scheme checking five technical controls (firewalls, secure configuration, access control, malware protection, patch management), not a risk-based framework. ISO 27001 and SOC 2 both require a documented, maintained risk register as part of certification.
How often should a cyber security risk register be updated?
A cyber security risk register should be reviewed at least quarterly, plus immediately after any material change - a new vendor, a new system, an office move, or a near-miss incident. Auditors for ISO 27001 will ask for the review history, not just the current state.
Frequently asked questions
One last thing
The most overlooked step in building a cyber security risk register isn't the scoring - it's the review date. A register scored perfectly in January and never touched again is worse than no register at all, because it gives false confidence going into an audit. Set the next review date the same day you finish the first draft, and put it in a calendar, not just the spreadsheet.
OneClickComply automates risk register maintenance alongside ISO 27001, Cyber Essentials, and SOC 2 evidence collection, so the register stays current without someone chasing updates every quarter. That's Seriously Simple Cyber Compliance: automate the parts that go stale, and keep your focus on running the business.