A risk assessment sits at the heart of an ISMS. It connects the organisation's context with specific risks, proportionate controls and decisions about residual risk. A practical approach remains clear to process owners, management and the board.
What role does the risk assessment play in ISO 27001?
ISO/IEC 27001:2022 requires an organisation to establish and apply an information security risk assessment process. The method must produce consistent and comparable results. The organisation also needs clear criteria for assessing and accepting risk.
The outcome guides risk treatment, the selection of controls, security objectives and improvement work. The risk assessment therefore provides a recurring basis for decisions within the ISMS.
Define the method in advance, work with recognisable scenarios and assign each risk to an owner who can support the treatment or acceptance decision.
1. Define the scope and risk criteria
Start with the agreed scope of the ISMS. Which business units, services, locations, processes, systems and suppliers are included? Then identify the interests at stake: continuity, confidentiality, integrity, legislation, contracts and expectations from customers or supply-chain partners.
Set out how likelihood and impact will be assessed, when a risk is acceptable and who is authorised to decide. Clear criteria keep the discussion focused on the substance of the risk instead of the scoring method.
- boundaries and dependencies of the ISMS
- critical processes and information
- impact categories and rating scales
- risk acceptance criteria
- roles of risk owners and decision-makers
2. Describe recognisable risk scenarios
A useful scenario explains what could happen, what might cause it and which business interest would be affected. For example: a compromised administrator account provides access to customer data and disrupts service delivery. This is more useful than a single label such as phishing or ransomware.
Discuss the scenarios with people who understand the processes and systems. They know which dependencies, exceptions and existing controls make a difference in day-to-day operations.
- failure of critical services
- unauthorised access to sensitive data
- ransomware or misuse of administrator accounts
- errors in software changes or data processing
- failure or compromise of a supplier
- loss of knowledge, key personnel or recovery capability
3. Assess likelihood, impact and existing controls
Assess each scenario using the agreed method. Consider the likelihood of the scenario, its potential consequences and the effect of existing controls. Record important assumptions so that the reasoning behind a rating remains clear.
Assess whether existing controls work in practice. A backup procedure reduces risk only when backups are protected and recovery has been tested. The same applies to access controls, monitoring, supplier agreements and incident procedures.
4. Select the risk treatment
Within the organisation's mandate, the risk owner decides how a risk will be treated. Options include reducing, avoiding, sharing or accepting the risk. Each decision needs a rationale, an owner and a review date.
Link every new control to the risk it is intended to reduce. This keeps the purpose of investments in time and budget visible.
- control and intended effect
- responsible owner
- planning and required resources
- expected residual risk
- acceptance decision
- date for reassessment
5. Connect risks with Annex A and the Statement of Applicability
The organisation compares the selected controls with Annex A to check whether relevant controls have been overlooked. The Statement of Applicability records which controls apply, why they were included or excluded and their implementation status.
Annex A therefore supports completeness and traceability. The risk assessment remains the starting point for choices within the ISMS.
What belongs in a useful risk register?
The risk register should support decisions. For each risk, record the context, owner, assessment, existing controls, selected treatment and current status. Add references to decisions or evidence where useful.
Schedule periodic reassessment and update the register after incidents, major changes, new suppliers or changes to the scope. This keeps the risk picture aligned with the organisation.
| Element | What should be recorded? |
|---|---|
| Scenario | Event, cause, affected process and potential consequences. |
| Assessment | Likelihood, impact, existing controls and rationale. |
| Ownership | Risk owner and authority to treat or accept the risk. |
| Treatment | Controls, planning, responsible person and expected residual risk. |
| Follow-up | Status, evidence, decision and reassessment date. |
Common mistakes in an ISO 27001 risk assessment
A risk assessment quickly loses value when one person completes it alone or when it consists mainly of generic threats. Involve process owners and keep the scenarios recognisable for the organisation.
A scoring method can also become unnecessarily complicated. A straightforward method, applied consistently and supported by clear reasoning, usually gives management and auditors a stronger basis for decisions.
- scope and acceptance criteria remain implicit
- scenarios are too general to assign ownership
- controls are treated as effective without evidence
- risk owners are absent from treatment and acceptance decisions
- Annex A is used as a standard checklist without a link to risks
- the risk register is no longer updated after the first assessment
Risk assessment, baseline assessment and gap analysis serve different purposes
An ISO 27001 risk assessment examines scenarios, likelihood, impact and treatment. An ISO 27001 baseline assessment or gap analysis compares the current ISMS with the standard and identifies missing elements, evidence or effective operation.
The two often complement each other. The gap analysis shows where the management system needs attention. The risk assessment helps determine which risks and improvements matter most to the organisation.
Sources and further reading
Based on official standards and practical implementation
The official sources provide the formal background. Kynexis Informatiebeveiliging BV translates these requirements into a practical approach for organisations operating in the Netherlands.
