Risk management is the engine of any Information Security Management System (ISMS). Under ISO/IEC 27001:2022, you cannot build a compliant ISMS without first understanding what risks your organisation faces, deciding how to treat them, and keeping that picture current as your environment changes. This guide covers what ISMS risk management requires under the standard, how to run the risk assessment and risk treatment process step by step, how to build and maintain a risk register, and what auditors will look for when they review your work.
What Is ISMS Risk Management?
ISMS risk management is an essential part of the ISMS and a structured framework for protecting critical data in a way that supports business objectives. Guided by international frameworks like ISO/IEC 27001 and the NIST Cybersecurity Framework, it is designed to identify, analyse, evaluate, and treat security vulnerabilities affecting the confidentiality, integrity, and availability of digital and physical assets. It is not a one-time project — ISO 27001 requires the process to be repeatable, documented, and continuously reviewed as the threat landscape and the organisation’s own systems change. In practice, risk management consists of a sustainable cycle rather than an attempt to eliminate all risk.
The requirements for risk management in ISO 27001:2022 sit primarily in Clause 6.1 (Actions to address risks and opportunities) and Clause 8.2 (Information security risk assessment). Clause 6.1.2 sets out what the risk assessment process must achieve: it must establish and maintain risk criteria, ensure that repeated assessments produce consistent and comparable results, identify risks associated with the loss of confidentiality, integrity, and availability of information assets within the ISMS scope, identify risk owners, and analyse and evaluate those risks against the defined criteria. The core stages are risk identification, risk analysis, risk evaluation, risk treatment, and continuous monitoring and review.
ISO/IEC 27005:2022 — the dedicated information security risk management standard in the ISO 27000 family — provides detailed guidance on how to fulfil these requirements. ISO 27001 prescribes what the process must achieve; ISO 27005 explains how to do it.
Step 1: Define Your Risk Criteria and Methodology
Before you identify a single risk, you need to establish the criteria against which risks will be assessed. ISO 27001 does not prescribe a methodology — it requires that you select a documented risk assessment methodology, supported by a formal risk assessment methodology, that produces consistent, comparable, and repeatable results. The methodology you document must define. ISO 27001 broadly frames this process as establishing the framework, identifying risks, analyzing risks, evaluating risks, and then selecting risk treatment options.
Risk acceptance criteria. What level of residual risk is your organisation prepared to accept without further treatment? This is your risk appetite, and it must be approved by top management. Risks that fall below this threshold can be accepted; risks above it must be treated based on an acceptable risk threshold.
Likelihood scale. How you will score the probability that a threat will exploit a vulnerability — typically a numeric scale of 1 to 5, from very unlikely to near certain.
Impact scale. How you will score the consequences of a risk materialising — again typically 1 to 5, covering impact on confidentiality, integrity, and availability, as well as business impact such as financial loss, regulatory penalty, or reputational damage.
Risk scoring formula. Most organisations use likelihood multiplied by impact to produce a risk score, with the resulting matrix used to classify risks as low, medium, high, or critical.
Document this methodology formally. Auditors will check that your assessments are consistent with it — if two different people assessed the same risk and arrived at materially different scores because the criteria were ambiguous, that is a finding. Many teams use an asset based risk assessment, based on assets, threats, and vulnerabilities, though ISO 27001 allows flexibility in how risks are identified. A consistent risk assessment methodology also helps different departments assess risks on the same basis and supports legal and regulatory compliance.
Step 2: Build Your Asset Inventory
ISMS risk management requires you to identify the information assets and supporting business processes within your scope — because risks are assessed in relation to the assets they could affect. Under ISO/IEC 27001:2022, the asset inventory is addressed by control A.5.9 (Inventory of information and other associated assets).
Your asset inventory should cover:
- Information assets: databases, documentation, intellectual property, personal data sets
- Software assets: applications, operating systems, development tools
- Physical assets: servers, workstations, network devices, removable media
- Services: cloud services, communication services, utilities
- People: roles and teams with access to sensitive information
- Suppliers and third parties: service providers whose systems or access could affect your assets
Cataloguing hardware, software, data, networks, and personnel resources gives you visibility into company information and helps link each asset to the processes it supports, which also makes it easier to map data assets and identify threats and vulnerabilities.
For each asset, record the asset owner — the person accountable for the protection of that asset — and the classification of the information it contains. Asset classification (control A.5.12) determines the level of protection the asset requires.
Step 3: Identify Threats and Vulnerabilities
For each asset in scope, perform risk identification by identifying the threats that could exploit a vulnerability to cause harm. Threats are external or internal events that could cause loss — ransomware, phishing, physical theft, accidental deletion, supplier failure. Vulnerabilities are weaknesses that threats could exploit — unpatched software, inadequate access controls, untrained staff, absence of a backup process. different threats affect different asset classes in different ways, which is why scenarios should be assessed consistently across assets.
The combination of a threat and the vulnerability it could exploit defines a risk scenario. A practical way to structure this is:
Asset: Customer payment records databaseThreat: Ransomware attackVulnerability: No offline backup; patch management process running behind schedule; insecure remote access**Risk: Ransomware encrypts the database, rendering customer records unavailable, creating potential data loss, and causing regulatory notification obligation
The risks identified here will later drive security controls and other controls; consistent policies and technical controls also help standardize defenses across the organization. Each risk scenario should have an identified owner — the person responsible for deciding how the risk is treated and for implementing the treatment. Risk ownership is a formal requirement of Clause 6.1.2 and a consistent point of audit scrutiny.
Step 4: Analyse and Evaluate Risks
With your risk scenarios documented, apply your scoring methodology to each one. Risk Analysis is where teams determine the likelihood of a security incident occurring and estimate its potential impact on the business. Risk Evaluation then compares the score against your pre-defined risk appetite and risk acceptance criteria. Risks above that threshold are unacceptable risks; those at or below it may fall within acceptable risk.
Risks above your acceptance threshold require treatment. Risks at or below the threshold may be accepted, but acceptance must be a conscious decision documented by the risk owner — not a default outcome of inaction. Your risk assessment results should also help direct allocated resources toward the highest-ranked risks first.
At this stage, you are not yet deciding how to treat each risk. You are producing a ranked view of all the identified risks that will form the basis of your risk treatment plan. This inventory is your risk register — the central document of your ISMS risk management process.
Step 5: Produce the Risk Treatment Plan
For each risk above your acceptance threshold, the risk treatment plan explains how the organisation is treating risks that exceeded the threshold. The next step is to select risk treatment options for each relevant risk. ISO 27001 defines four treatment options:
Modify (mitigate): Implement security controls that reduce the likelihood or impact of the risk to an acceptable level. This is the most common treatment option and is where information security controls selected from Annex A are applied — the treatment plan connects each risk to the specific controls selected to address it. The risk treatment process involves selecting appropriate controls from ISO 27001 Annex A, which includes 114 controls covering different aspects of information security management.
Retain (accept): Accept the risk as it stands, on the basis that the cost of treatment exceeds the cost of the risk materialising, or that the risk falls within your appetite. Accepted risks must be documented with the rationale and the risk owner’s sign-off.
Avoid: Cease the activity that gives rise to the risk — for example, discontinuing a service that processes a category of data that creates disproportionate risk. This is risk avoidance.
Share (transfer): Transfer the risk to a third party through insurance or contractual arrangements. Transferring a risk does not remove your compliance obligations — if a cloud provider suffers a breach of your customer data, you remain accountable to regulators.
The treatment plan should clearly address the identified risks selected for action. The risk treatment plan must also document the residual risk — the risk that remains after the treatment controls are applied — and confirm that residual risk falls within the acceptance criteria. Management sign-off on residual risk is a formal ISO 27001 requirement (Clause 6.1.3).
Step 6: Build and Maintain the Statement of Applicability
The Statement of Applicability (SoA) is the document that connects your risk treatment plan to the Annex A controls. For each of the 93 controls in Annex A, the SoA records whether the control is included or excluded, with justification. Where a control is included, the SoA records whether it was selected because the risk assessment identified a need for it, because of a legal or contractual obligation, or as a result of organisational policy.
The SoA is one of the most scrutinised documents in a certification audit. It must be consistent with your risk register and risk treatment plan — if your risk assessment identified a significant access control risk but you excluded control A.5.15 from the SoA without explanation, the certification auditor will raise a finding.
Step 7: Monitor, Review, and Update
ISMS risk management is not static. Clause 9.1 of ISO 27001 requires continuous monitoring and measurement of the ISMS, and Clause 10 requires continual improvement. In practice this means:
Regular risk review cycles. Most organisations conduct a formal risk assessment review at least annually, and additionally when significant changes occur — a new cloud migration, a merger, a material change in the threat landscape, a security incident.
Trigger-based reassessment. Infrastructure changes, new service launches, personnel changes in key roles, and significant supplier changes should each trigger a review of the relevant risk scenarios rather than waiting for the annual cycle.
Internal audit. ISO 27001 Clause 9.2 requires regular internal audits of the ISMS, which include testing that the risk management process is operating as documented — that assessments are being conducted, risk owners are engaged, treatment plans are being implemented, and the risk register reflects current reality.
Management review. Clause 9.3 requires management to review the ISMS at planned intervals. Risk management performance — the status of risks, the progress of treatment plans, and any changes to the risk profile — is a standard agenda item for the management review.
What Auditors Look For
In a Stage 2 certification audit, the risk management process receives significant attention. The most common findings relate to:
- Risk assessments that are documented but cannot demonstrate how scores were arrived at — the methodology exists but was not applied consistently
- Risk registers that were built at the start of the programme and not updated since — assets have changed, new services have been added, but the register still reflects the original scope
- Risk owners who are named in the register but have no awareness of the risks assigned to them
- Treatment plans where controls are listed as “planned” but show no progress months after the assessment
- Residual risk that has not been formally accepted — treatment has reduced the risk, but there is no documented sign-off that the remaining risk is within the acceptance criteria
- Documentation where risk assessment results cannot be traced to actual treatment decisions and the controls selected as audit evidence
All of these are addressable before the audit. The purpose of the risk register and treatment plan is not to produce documents that satisfy auditors — it is to protect the organisation’s assets through systematic assessment, treatment, and ongoing executive oversight, while giving the organisation genuine visibility over its information security risks and the confidence that those risks are being managed. Auditors can tell the difference, and interested parties such as leadership, auditors, and process owners should be able to understand why risks were prioritised in the way they were.
Frequently Asked Questions
What is the difference between a risk assessment and a risk treatment plan?
A risk assessment identifies and evaluates risks — it tells you what your risks are and how significant they are. A risk treatment plan documents what you are going to do about the risks that exceed your acceptance threshold — which treatment option you have chosen and which controls you will implement. The two documents are produced sequentially and must be consistent with each other.
How often should an ISMS risk assessment be conducted?
ISO 27001 does not specify a minimum frequency, but it requires the process to be conducted at planned intervals and when significant changes or incidents occur. Most organisations conduct a formal annual review as a baseline, supplemented by trigger-based reviews when material changes happen.
Does ISO 27001 specify which risk methodology to use?
No. ISO 27001 requires that the methodology you choose produces consistent, comparable, and repeatable results, but it does not mandate a specific approach. Common methodologies include likelihood-impact matrices (the most widely used), OCTAVE, FAIR, quantitative risk assessment, and asset-based approaches following ISO 27005. The most important criterion is that your chosen methodology is documented and applied consistently.
What is residual risk?
Residual risk is the risk that remains after treatment controls have been applied. Even after implementing controls, some level of risk typically remains — either because the controls reduce but do not eliminate the risk, or because the chosen treatment option was acceptance or transfer rather than mitigation. Residual risk must be formally evaluated against your acceptance criteria and signed off by management, which is where management decides whether the remaining risk is acceptable risk.
ISMS risk management is the discipline that turns ISO 27001 from a documentation exercise into a genuinely useful security programme. The organisations that derive the most value from it are those that treat the risk register as a living document — something that reflects real changes in their environment and informs real decisions about where to direct security effort — rather than a compliance artefact produced for the annual audit and filed away until the next one.
How Copla Supports ISMS Risk Management
We work with financial institutions and regulated organisations through every stage of the ISMS risk management process. The engagement starts with a scoping workshop and an initial asset inventory, followed by the risk assessment itself — scoring threats and vulnerabilities against your defined criteria and producing a risk register that reflects your actual environment rather than a generic template.
From there, we build the risk treatment plan and Statement of Applicability in the Copla platform, connecting each risk to the specific Annex A controls selected to address it. For organisations subject to DORA or NIS2 alongside ISO 27001, we structure the risk treatment work so that controls addressing overlapping requirements are built once and evidenced across frameworks. The Copla platform tracks treatment plan progress continuously, so the risk register remains current between annual review cycles rather than drifting out of date.
Schedule a call with Copla to walk through how this would look for your organisation.
