ISO 27001 Risk Assessment Template: Methodology, Register & Annex A Mapping
A defensible ISO 27001 risk assessment is the backbone of any ISMS. This page explains the asset-threat-vulnerability methodology, gives you a reusable risk register table, and shows how to map treated risks to the 93 Annex A controls — aligned to clause 6.1.2 of ISO/IEC 27001:2022.
What Is an ISO 27001 Risk Assessment?
ISO/IEC 27001:2022 clause 6.1.2 requires the organisation to define and apply an information security risk assessment process. The assessment identifies risks to the confidentiality, integrity, and availability of information assets in ISMS scope, analyses and evaluates each risk, and feeds directly into the risk treatment decisions captured in the Statement of Applicability.
The risk assessment is not a one-off document. The standard requires it to be repeated at planned intervals or when significant changes occur, with results retained as documented information. Every external audit will sample the register, the methodology, and the SoA — so the three have to line up.
The most widely used methodology in Australian and global ISO 27001 implementations is asset-threat-vulnerability. Each in-scope information asset is paired with credible threats and the vulnerabilities that could be exploited, producing a risk statement. This page uses the asset-threat-vulnerability approach; the underlying template also works for scenario-based or event-based methodologies with minor column changes.
The Seven-Step ISO 27001 Risk Assessment Process
Follow these seven steps to produce a risk assessment that stands up to audit. Each step corresponds to an explicit requirement in clause 6.1.2 of ISO/IEC 27001:2022.
Define your methodology
Document the approach, criteria, and scales before you start assessing. Capture your risk appetite, likelihood and consequence scales, and the aggregation method (e.g. likelihood × consequence = risk rating). Without a written methodology, two assessors will produce incompatible results — and auditors will flag it.
Build the information asset inventory
List every information asset inside ISMS scope — data, systems, applications, physical records, supporting services, key people. Assign an owner to each asset. The inventory drives the entire assessment; scope gaps here become audit findings later.
Identify threats and vulnerabilities
For each asset, identify credible threats and the vulnerabilities that could be exploited. Start from published catalogues (ISO/IEC 27005 annex, ENISA threat landscape, MITRE ATT&CK, NIST SP 800-30) and reduce to what is realistic for your context.
Assign risk owners
Each risk has a single accountable owner — usually the asset owner or business process owner — who can approve treatment decisions. This is an explicit clause 6.1.2(c) requirement.
Analyse inherent risk
Assess likelihood and consequence before any controls are applied. Use your documented scales consistently. Record both the individual values and the combined rating (e.g. High, Medium, Low) so prioritisation is explicit.
Evaluate residual risk and decide treatment
Recalculate likelihood and consequence with existing controls in place. Compare to risk appetite. Choose one of the four treatment options: modify (add or strengthen controls), retain (accept with owner sign-off), avoid (remove the activity), or share (transfer via insurance, contract, or partner).
Map controls and produce the Statement of Applicability
For every risk you treat, list the Annex A controls applied. Build the Statement of Applicability (SoA) listing all 93 controls as included or excluded, with justification for each. The SoA is the single most-audited document in your ISMS — treat it as a first-class artefact.
Reusable Risk Register Template
Copy the columns below into a spreadsheet or GRC tool. These are the minimum fields required to produce a defensible ISO 27001 register — you can add context-specific columns (e.g. regulatory driver, business unit) but should not remove any of these.
For a shared likelihood × consequence scale compatible with this register, reuse the 5×5 grid from our ISO 31000 risk matrix template — the scales work equally well for information security risk under ISO 27001.
Annex A Control Mapping Example
The register's Annex A column is where the risk assessment and Statement of Applicability meet. Each risk marked "Modify" should list the specific Annex A controls applied — and those same controls should appear in the SoA with the same risk references. Here is an example mapping from three typical SaaS risks.
Not every risk needs every control, and not every control needs to map to a risk — some controls are included because they are baseline good practice (e.g. screening of personnel, acceptable use) rather than because of a specific risk. Auditors will sample both directions.
Common Mistakes to Avoid
- Assessing risk at asset level only. The unit of analysis is the risk, not the asset. "Customer database" is not a risk — "external attacker exfiltrates customer database via unpatched web server" is.
- No inherent risk column. If you only record residual risk, you cannot demonstrate why controls were selected. Auditors expect to see both.
- Unowned risks. A risk without a named owner has no decision-maker. Clause 6.1.2(c) makes risk ownership explicit — blank owner columns are a guaranteed finding.
- Treatment decisions without rationale. "Retain — accepted by management" is not enough. Document why the residual is within appetite, who signed off, and when it will be reviewed.
- SoA that doesn't match the register. A control can't be "included" in the SoA and absent from the register — and vice versa. Cross-reference both ways.
- Annual-only reviews. The standard allows annual review as the minimum, but significant changes (new systems, incidents, regulatory shifts) trigger ad-hoc reviews. A stale register from 11 months ago is a finding.
- Generic likelihood and consequence labels. "Likely" and "Major" with no definitions mean different things to different assessors. Every scale value needs a measurable threshold.
Resources
- ISO 27001 Certification Guide — Complete overview of the standard, scope, and Australian certification process.
- ISO 27001 Annex A Controls — All 93 controls with one-line descriptions for mapping into the register.
- ISO 31000 Risk Matrix Template — 5×5 likelihood × consequence grid compatible with this register's scale columns.
- ISO 27001 Certification Cost — Detailed cost breakdown for first-time certification including risk assessment effort.
- PECB ISO 27001 Lead Implementer — Full implementation methodology, including clause 6.1.2 walkthroughs, $849 AUD.
- ControlStack Controls Library — Browse ISO 27001 Annex A alongside Essential Eight and NIST CSF for cross-framework register mapping.
Frequently Asked Questions
Common questions about ISO 27001 risk assessment and risk register design.
Is an ISO 27001 risk assessment mandatory?
Yes. Clause 6.1.2 of ISO/IEC 27001:2022 requires the organisation to define and apply an information security risk assessment process. The assessment must identify risks to the confidentiality, integrity, and availability of in-scope information assets, assign risk owners, and analyse, evaluate, and treat each risk. Without a documented risk assessment, you cannot produce a defensible Statement of Applicability — and you cannot be certified.
What methodology should I use?
ISO/IEC 27001 does not mandate a specific methodology, but the most widely used approach in Australian and global implementations is asset-threat-vulnerability (sometimes abbreviated ATV or "asset-based"). Each information asset is paired with credible threats and the vulnerabilities that could be exploited, producing a risk statement. Alternatives include ISO 31000-style scenario-based assessment or a pure event-based approach. Whichever you choose, document it — the methodology itself is subject to audit.
What should a risk register contain?
At minimum, each risk entry should capture: a unique risk ID, the information asset at risk, the threat, the vulnerability, the risk owner, the inherent likelihood and consequence (before controls), the residual likelihood and consequence (after existing controls), the treatment decision (modify, retain, avoid, share), the Annex A controls applied, and a review date. Without risk owners and review dates, you will not pass audit.
How often should I review the risk assessment?
ISO 27001 requires the risk assessment to be performed at planned intervals or when significant changes occur. Most certified organisations run a full review annually, with lighter updates quarterly and ad-hoc reviews after incidents, organisational changes, new systems going live, or significant regulatory updates. The Plan-Do-Check-Act cycle expects risk to be a living document, not a set-and-forget artefact.
How do I link risks to Annex A controls?
For each risk you choose to treat, identify the Annex A controls that reduce the likelihood or consequence. The mapping goes directly into the Statement of Applicability (SoA): if a control is applied because of one or more risks, mark it as "included" and reference those risks; if a control is not applicable, document the justification. The auditor will sample both directions — risks without controls and controls without risks — so keep the mapping explicit.
Do I need to use a spreadsheet?
No. A spreadsheet is the most common starting point for small and medium organisations because it is flexible and cheap, but enterprise GRC platforms (Vanta, Drata, ControlStack, ServiceNow GRC, RSA Archer) all have purpose-built risk register modules that integrate the risk assessment with the SoA and audit evidence. Pick the tool that matches your scale — the standard cares about the process and outputs, not the format.
What is the difference between inherent and residual risk?
Inherent risk is the likelihood × consequence before any controls are applied. Residual risk is the same calculation after existing controls are in place. ISO 27001 treatment decisions are made on residual risk — if the residual is still above your risk appetite, you need additional controls (modify), acceptance sign-off (retain), scope reduction (avoid), or transfer (share). Auditors expect to see both figures in the register.
How does this relate to ISO 31000?
ISO 31000 provides the generic risk management framework; ISO 27001 applies it specifically to information security. The clause 6.1.2 requirements are compatible with an ISO 31000 process — you can run one risk management function that handles enterprise risk (ISO 31000) and produces an ISO 27001-compliant information security output. See our ISO 31000 guide for the parent framework and the ISO 31000 risk matrix for a compatible likelihood × consequence grid you can reuse here.
Ready to run a defensible ISO 27001 risk assessment?
The PECB ISO 27001 Lead Implementer course walks through clause 6.1.2 in detail, with reusable templates for the methodology, register, and Statement of Applicability — plus the exam voucher and free resit.