ISO 27001 Risk Register: Structure and Example Entries
An ISO 27001 risk register is the documented output of the risk assessment process required by Clause 6.1.2: risks to the confidentiality, integrity, and availability of information within your ISMS scope, each with a named risk owner, an analysed consequence and likelihood, and an evaluation against your own risk criteria. The columns that matter are the ones the standard implies — risk description tied to an asset and a threat, owner, consequence, likelihood, resulting risk level, treatment option, the controls selected, and the residual risk the owner accepted. Ten specific entries you actually review beat a hundred generic rows you downloaded.
An ISO 27001 risk register is the documented output of the risk assessment process required by Clause 6.1.2. It records risks to the confidentiality, integrity, and availability of information inside your ISMS scope — each with a named owner, an analysed consequence and likelihood, and an evaluation against risk criteria you defined in advance.
If you want the general, non-ISO version of the concept first, we have a primer on what a risk register is and why any growing company benefits from one. This article is narrower: the structure that survives a certification audit, and five worked entries you can adapt.
What Clause 6.1.2 Actually Demands
The standard doesn't dictate a format, but it does dictate a process — and the process implies the columns. Clause 6.1.2 requires you to define and apply a risk assessment process that:
- Establishes and maintains risk criteria, including risk acceptance criteria and the criteria for performing assessments. Decide what "high" means and what you're willing to live with before you start scoring, not after.
- Produces consistent, valid, and comparable results when repeated. Two people assessing the same risk should land in roughly the same place, and this year's assessment should be comparable to last year's.
- Identifies risks associated with the loss of confidentiality, integrity, and availability of information within scope.
- Identifies risk owners — named people, not departments.
- Analyses risks — assesses realistic consequences and likelihood, and determines the resulting level of risk.
- Evaluates risks — compares them against your criteria and prioritises them for treatment.
Clause 6.1.2 also requires you to retain documented information about the process. The register is how most organizations satisfy that.
The Minimum Column Set
Every column below maps to something the standard asks for. If a column in your template doesn't, it's decoration — and decoration is what turns a register into a chore nobody updates.
| Column | Why it exists |
|---|---|
| ID | A stable reference so treatment plans and audit findings can point at it |
| Risk description | Asset + threat + consequence, in one specific sentence |
| Affected asset or process | Ties the risk to your asset inventory |
| CIA impact | Which of confidentiality, integrity, availability is at stake |
| Risk owner | Clause 6.1.2 c) 2 — a named individual who can actually decide |
| Consequence | Analysed impact, scored against your criteria |
| Likelihood | Realistic probability, scored against your criteria |
| Risk level | The resulting level, evaluated against acceptance criteria |
| Treatment option | Modify, retain, avoid, or share |
| Controls selected | The controls that treat it, cross-referenced to your SoA |
| Residual risk | The level after treatment — and whether the owner accepted it |
| Review date | When it was last looked at, so staleness is visible |
Five Worked Entries
These are written for a cloud-native startup. The scoring uses a simple 1–5 scale for consequence and likelihood with risk level as the product, which is more than adequate for a small team — the standard cares that your method is consistent, not that it is sophisticated.
R-01 — Departed employee retains SaaS access
Description: An employee leaves and access to a SaaS tool outside the SSO estate is not revoked, allowing continued access to customer data. Asset: Customer support platform. CIA: Confidentiality. Owner: Head of Operations. Consequence 4, Likelihood 3, Level 12. Treatment: Modify — offboarding checklist covering non-SSO tools, plus quarterly user access reviews. Residual: 4, accepted.
R-02 — Cloud region outage exceeds recovery objective
Description: A prolonged availability-zone failure at the hosting provider takes the platform offline beyond the recovery time objective committed in customer agreements. Asset: Production platform. CIA: Availability. Owner: CTO. Consequence 4, Likelihood 2, Level 8. Treatment: Modify — multi-AZ deployment, documented recovery runbook, tested annually. Residual: 4, accepted.
R-03 — Extreme weather disrupts a critical supplier
Description: Flooding or heat-driven grid stress at a supplier's facility interrupts a service the platform depends on. Asset: Supplier-provided service. CIA: Availability. Owner: CTO. Consequence 3, Likelihood 2, Level 6. Treatment: Retain, with monitoring — supplier continuity commitments reviewed annually. Worth including explicitly since the 2024 amendment brought climate considerations into Clauses 4.1 and 4.2 — see the amendment nobody told you about. Residual: 6, accepted.
R-04 — Secrets committed to source control
Description: API keys or credentials are committed to a repository and exposed to anyone with repo access, or publicly if the repo is ever opened. Asset: Source code repositories. CIA: Confidentiality. Owner: Engineering Lead. Consequence 5, Likelihood 3, Level 15. Treatment: Modify — automated secret scanning in CI, managed secret store, rotation procedure. See secure development controls. Residual: 5, accepted.
R-05 — Single-person dependency on production deployment
Description: Only one engineer holds the knowledge and access required to deploy and recover production, creating an availability risk if they are unavailable. Asset: Deployment pipeline. CIA: Availability. Owner: CTO. Consequence 4, Likelihood 3, Level 12. Treatment: Modify — documented runbooks, a second trained engineer, break-glass access procedure. Residual: 6, accepted.
Ready to Streamline Your Compliance?
Discover how AuditBadger can simplify your compliance management process.
Risk Owners Are People, Not Departments
"IT" cannot accept a risk. "Engineering" cannot approve a treatment plan. Clause 6.1.2 asks you to identify risk owners because Clause 6.1.3 later requires those owners to approve the risk treatment plan and accept the residual risks — and only a person can do that.
In a small company the same two or three names will appear repeatedly, and that is fine. What matters is that the named owner has the authority to fund a fix or to accept living without one. If your register lists an owner who can do neither, the entry is decorative.
How the Register Feeds the SoA
The register is not the end of the chain. Under Clause 6.1.3 you take the evaluated risks and:
- Select treatment options — modify, retain, avoid, or share.
- Determine the controls necessary to implement those options.
- Compare your determined controls against Annex A to verify no necessary control has been overlooked. Annex A is a cross-check, not a shopping list.
- Produce a Statement of Applicability recording which controls apply, why, and whether they are implemented.
- Formulate a risk treatment plan, and obtain risk-owner approval of the plan plus acceptance of the residual risks.
An auditor will trace this chain in both directions. They will pick a control marked "applicable" in your SoA and ask which risk drove it. Then they will pick a high-scoring risk in your register and ask which controls treat it. A register that doesn't reconcile with the SoA is one of the more uncomfortable findings to receive, because it suggests the two documents were produced independently — which is usually exactly what happened.
The Anti-Patterns
- The hundred-row download. A generic template populated with risks that have nothing to do with your business. It looks thorough and reviews terribly, because nobody recognises any of it.
- Risks written as categories. "Cyber risk" is not a risk. "Customer data exfiltrated via a compromised admin account" is.
- Scoring theatre. Elaborate formulas without documented criteria. The standard wants consistency and comparability, which a simple, written-down scale delivers better than an unexplained algorithm.
- No residual risk. If you never record what's left after treatment, the owner has nothing to accept — and Clause 6.1.3 asks them to accept it.
- The frozen register. Same twelve rows, same scores, same dates, year after year. This is the single most common finding at surveillance audits, because it is trivially visible.
The Takeaway
Build the register around what Clause 6.1.2 asks for: specific risks tied to real assets, named owners with authority, criteria you wrote down before scoring, and residual risk somebody actually accepted. Then review it on a cadence and let the review show in the dates. Ten entries you genuinely maintain will pass an audit that a hundred inherited rows will not.
Next: Clause 6 in full, risk assessment methodologies if you're still choosing an approach, or see how risk assessment in AuditBadger keeps the register, the treatment plan, and the SoA pointing at each other.
Frequently asked questions
What columns should an ISO 27001 risk register have? +
Every column should map to something Clause 6.1.2 or 6.1.3 asks for: an ID, a specific risk description tying an asset to a threat and a consequence, the affected asset or process, which of confidentiality, integrity, or availability is at stake, a named risk owner, analysed consequence and likelihood, the resulting risk level, the treatment option chosen, the controls selected, the residual risk the owner accepted, and a review date. Anything else is decoration.
Who should be the risk owner in an ISO 27001 risk register? +
A named individual, never a department. Clause 6.1.2 requires you to identify risk owners because Clause 6.1.3 later requires those same owners to approve the risk treatment plan and accept the residual risks — and only a person can do that. The practical test is authority: the owner must be able either to fund a fix or to accept living without one. In a small company the same two or three names will recur, which is fine.
How many risks should a startup's risk register contain? +
There is no required number, and more is not better. Ten to twenty specific, genuinely maintained entries will pass an audit that a hundred rows from a downloaded template will not. The failure mode of large inherited registers is that nobody recognises the entries, so nobody reviews them — and a frozen register with unchanged scores and dates is one of the most visible findings at a surveillance audit.
What is residual risk in ISO 27001? +
Residual risk is the level of risk that remains after your selected controls have been applied. It matters because Clause 6.1.3 requires risk owners to formally accept residual risks as part of approving the risk treatment plan. If your register records only the initial risk level and never the residual, the owner has nothing to accept — which means one of the standard's explicit requirements has no evidence behind it.
How does the risk register connect to the Statement of Applicability? +
The register feeds the SoA. Under Clause 6.1.3 you select treatment options for evaluated risks, determine the controls needed, compare those against Annex A to check nothing necessary was overlooked, then record the result in the Statement of Applicability. Auditors trace this chain both ways: they pick a control marked applicable and ask which risk drove it, then pick a high-scoring risk and ask which controls treat it. Registers and SoAs produced independently fail that test.
