The risk assessment is the engine of an ISO/IEC 27001:2022 ISMS. Every control you implement, every line in your Statement of Applicability, traces back to it. Yet it is also where organisations most often overcomplicate things, building elaborate scoring models nobody can repeat, or undercomplicate them, producing a thin spreadsheet that collapses under audit. There is a practical middle path.
This article sets out a repeatable risk assessment and treatment method aligned to clause 6.1 of the standard and informed by ISO/IEC 27005. For how the output feeds the rest of the management system, see our articles on the Statement of Applicability and building an ISMS that auditors trust, and our overview of ISO 27001 certification.
What clause 6.1 actually requires
Clause 6.1.2 requires a documented risk assessment process that is consistent and repeatable, so that running it twice on the same facts produces comparable results. The process must establish risk criteria (including acceptance criteria), identify risks, analyse them, and evaluate them. Clause 6.1.3 then requires you to treat the evaluated risks and record your control choices in the Statement of Applicability.
The 2022 standard does not mandate a specific methodology. You can take an asset-based approach, a scenario-based approach, or a hybrid. What matters is that it is defined, repeatable and produces valid results. ISO/IEC 27005 provides recognised guidance for doing this well, which is why many organisations base their method on it.
Step 1: Set your risk criteria first
Before you assess anything, define the rules of the game. This is the step organisations skip and later regret. Establish:
- Likelihood scale. A defined scale, for example rare, unlikely, possible, likely, almost certain, with descriptions so different assessors interpret them the same way.
- Consequence scale. The impact of a risk materialising, described in terms that matter to your organisation: financial loss, regulatory breach, service disruption, reputational harm.
- Risk evaluation method. How likelihood and consequence combine into a risk level, typically a matrix.
- Acceptance criteria. The threshold below which a risk is tolerable without further treatment, owned by management.
Defining these up front is what makes the process repeatable. Without them, scoring becomes a matter of opinion and your results will not survive an auditor asking why two similar risks scored differently.
Step 2: Identify the risks
With criteria set, identify your information security risks across the ISMS scope. An asset-based method works through information assets and the threats and vulnerabilities affecting their confidentiality, integrity and availability. A scenario-based method works through plausible events, such as ransomware, supplier compromise, or insider data theft. Both are valid; many organisations combine them, using assets to ensure coverage and scenarios to capture realistic attack paths.
Whatever the approach, record each risk clearly: what could happen, to which asset or process, and through what cause. Assign each risk an owner, a real accountable individual, not a department, because that owner will later accept the residual risk.
Step 3: Analyse and evaluate
For each identified risk, assess likelihood and consequence using your defined scales, and combine them to produce a risk level. This is the analysis. Evaluation then compares each risk level against your acceptance criteria to decide which risks require treatment and in what priority order.
Resist the temptation to over-engineer the scoring. A clear five-by-five matrix applied consistently beats a complex quantitative model that nobody can reproduce. The standard prizes consistency and comparability over precision. The goal is to reliably separate the risks you must treat from those you can accept.
Step 4: Choose a treatment for each risk
For every risk above your acceptance threshold, select a treatment. ISO 27001 recognises four treatment options:
- Modify. Apply controls to reduce likelihood or consequence. This is the most common option and is where Annex A controls come in.
- Retain. Accept the risk because it is within tolerance, with the risk owner’s documented agreement.
- Avoid. Stop or change the activity that creates the risk altogether.
- Share. Transfer part of the risk through insurance, outsourcing or contractual terms. Note that sharing rarely removes accountability, so residual exposure usually remains.
Where you choose to modify, select the controls that treat the risk. These selected controls then flow directly into your Statement of Applicability, each justified by the risk it addresses. This is the link auditors trace, so make it explicit.
Step 5: Assess and accept residual risk
After treatment, some risk remains. This residual risk must be assessed and formally accepted by the risk owner. The acceptance confirms the remaining exposure is within tolerance. Auditors look closely here, because residual risk acceptance is where accountability lives. They want to see that the person who owns the business consequence, not just the IT team, has signed off the residual risk they carry.
Document the residual risk level, who accepted it, and when. Where residual risk exceeds tolerance, you need further treatment, not a signature.
Step 6: Build the risk treatment plan
The risk treatment plan turns decisions into action. For each risk being modified, it records the controls to implement, who owns the implementation, the timeline, and the resources required. Distinguish this clearly from the Statement of Applicability: the SoA is the decision of what applies, the treatment plan is the schedule of how and when it gets done. Auditors expect both and expect them to align.
Keeping the assessment current
Clause 8 requires you to perform the risk assessment at planned intervals and when significant changes occur, such as a new system, a major supplier, a merger, or a serious incident. A risk register reviewed once and never touched again is a classic nonconformity. Schedule reviews, and trigger an out-of-cycle review when the environment changes materially. A current register is one of the clearest signals that your ISMS is genuinely operating.
Asset-based versus scenario-based: choosing well
Because the standard leaves the method open, the choice between asset-based and scenario-based assessment is worth making deliberately. An asset-based approach gives systematic coverage: by working through every information asset and the threats to its confidentiality, integrity and availability, you are unlikely to miss something. Its weakness is volume; large asset inventories can generate hundreds of repetitive risks that obscure the ones that matter.
A scenario-based approach starts from realistic events, such as a ransomware outbreak, a compromised privileged account, or a key supplier breach, and works back to the assets and controls involved. It produces a shorter, more decision-useful register that resonates with executives, but it can miss risks that do not fit a pre-imagined scenario. In practice, a hybrid works best for most organisations: use asset thinking to ensure coverage and scenario thinking to prioritise and communicate. Document whichever method you choose, because the auditor will check that your process matches what you actually did.
Linking risk to legal and contractual obligations
Not every control is justified purely by a risk score. ISO 27001 expects you to account for legal, regulatory and contractual requirements as drivers too. An Australian organisation may need certain controls because of the Privacy Act, sector regulation, or a client contract, regardless of where the risk lands on the matrix. Capture these requirements during context-setting and reflect them as justifications when you select controls, so your Statement of Applicability shows both risk-driven and obligation-driven inclusions.
Common pitfalls to avoid
- Scoring without defined criteria, making results inconsistent and indefensible.
- Treating the register as an IT artefact, when risk ownership belongs across the business.
- Selecting Annex A controls first, then reverse-engineering risks to fit, which inverts the whole logic.
- Forgetting residual risk acceptance, leaving exposures unowned.
- Letting the register go stale between certification cycles.
A sound risk assessment makes everything downstream easier: control selection, the Statement of Applicability, and the audit itself. CISO Advisory builds practical, repeatable risk assessment methodologies aligned to ISO 27005 for organisations across the private sector and government and council sector, and can run the ongoing risk programme through our Virtual CISO service. To discuss your risk process, call 07 2112 8502 or get in touch.
Frequently asked questions
What does ISO 27001 require for risk assessment?
Clause 6.1.2 requires a defined and repeatable process that establishes risk criteria, identifies information security risks, analyses their likelihood and consequence, and evaluates them against acceptance criteria. The process must produce consistent, valid and comparable results each time it is run, so two assessors reach similar conclusions.
What is ISO 27005 and do I need it?
ISO/IEC 27005 is the guidance standard for information security risk management. It is not mandatory for certification, but it provides a recognised, practical method for the risk process ISO 27001 requires. Many organisations base their methodology on ISO 27005 because auditors recognise and trust the approach.
What are the four risk treatment options?
The four options are modify the risk by applying controls to reduce it, retain or accept the risk if it is within tolerance, avoid the risk by stopping the activity that causes it, and share the risk through insurance, outsourcing or contracts. Most risks are treated by modification using Annex A controls.
What is residual risk?
Residual risk is the risk that remains after treatment has been applied. ISO 27001 requires risk owners to formally accept residual risk, confirming it is within the organisation's tolerance. This acceptance is documented, and auditors check that the right people, not just IT, have signed off the residual risk they own.
How is the risk assessment linked to the Statement of Applicability?
The risk assessment identifies risks, the treatment process selects controls to address them, and those selected controls are recorded in the Statement of Applicability with their justification. Auditors trace this chain, so every control you include should map back to a risk, requirement or obligation.
Need this handled for your organisation?
Confidential and no obligation. We respond the same business day — on-site same day / next business day, or remote, Australia-wide. Prefer to talk now? Call us 24/7 on 07 2112 8502.