Risk assessment for ISO 27001: the basis of your ISMS
The risk assessment is the foundation of your ISMS under ISO 27001 . For detailed guidance, ISO 27005 offers a complete method, and the NCSC (Netherlands National Cyber Security Centre) publishes practical tools. Without a good understanding of your risks, you cannot select good measures. This article explains how to carry out a risk assessment, with a concrete example and a checklist.
Do you work in healthcare? Then the same approach applies, but with extra attention to patient data. Read the risk assessment for NEN 7510 if you fall under that standard.
What does ISO 27001 require?
ISO 27001 sets requirements for your risk assessment in clause 6.1. You must:
- Carry out a risk assessment that is reproducible
- Identify risks that threaten the confidentiality, integrity and availability of information
- Analyse risks for likelihood and impact
- Evaluate risks and set priorities
- Choose a risk treatment: reduce, accept, transfer or avoid
- Document everything
The standard does not prescribe which method you must use. You choose an approach that suits your organisation, as long as it meets the criteria above.
How do you carry out an ISO 27001 risk assessment?
You carry out an ISO 27001 risk assessment in five steps: define the context, identify risks, analyse, evaluate and treat. The overview below shows what each step involves. We work them out below with examples and templates.
| Step | What do you do? | Result |
|---|---|---|
| 1. Define the context | Map the scope, assets, threats and vulnerabilities | Asset inventory |
| 2. Identify risks | For each asset, determine the threats, vulnerabilities and impact | Risk list |
| 3. Analyse risks | Score likelihood and impact for each risk | Risk scores |
| 4. Evaluate risks | Set priorities and decide what is acceptable | Risk matrix |
| 5. Treat risks | For each risk, choose: reduce, accept, transfer or avoid | Risk treatment plan |
Tip: The standard does not prescribe a specific method. A pragmatic approach with a spreadsheet is fine, as long as you are consistent and document everything. Start simple. You can refine it later.
Step 1: Define the context
Before you can identify risks, you need to know what you are looking at:
- Scope: Which systems, processes and information fall within your ISMS?
- Assets: Which information assets do you have? (systems, data, processes, people)
- Threats: Which threats are relevant? (hackers, human error, natural disasters)
- Vulnerabilities: Where are the weak points?
Tip: Start with an asset inventory. You cannot identify risks if you do not know what you need to protect. Think of: customer data, financial systems, intellectual property, staff records, and so on.
Step 2: Identify risks
For each asset you determine which risks exist. A risk is a combination of:
- A threat (what could happen?)
- A vulnerability (why could it happen?)
- An impact (what are the consequences?)
Example:
| Asset | Threat | Vulnerability | Risk |
|---|---|---|---|
| Customer database | Data breach by a hacker | Outdated software, no MFA | Unauthorised access to customer data |
| Email system | Phishing attack | Insufficient awareness | Employee clicks a malicious link |
| Laptop | Theft | No encryption | Sensitive data falls into the wrong hands |
| Server | Hardware failure | No redundancy | Service unavailable |
Sources for identifying risks:
- NCSC threat reports
- The incident history of your organisation
- Audits and penetration tests
- Input from employees
- Sector-specific threats
Step 3: Analyse risks
For each risk you determine the likelihood that it occurs and the impact if it does.
Likelihood scale (example):
| Score | Description | Frequency |
|---|---|---|
| 1 | Very unlikely | Less than once every 10 years |
| 2 | Unlikely | Once every 5-10 years |
| 3 | Possible | Once every 1-5 years |
| 4 | Likely | Once a year |
| 5 | Very likely | Several times a year |
Impact scale (example):
| Score | Description | Consequence |
|---|---|---|
| 1 | Negligible | Hardly noticeable |
| 2 | Minor | Limited inconvenience, quickly resolved |
| 3 | Moderate | Clear impact, recovery takes time |
| 4 | Serious | Major damage, long recovery |
| 5 | Catastrophic | Business continuity at risk |
The risk score = likelihood × impact
Step 4: Evaluate risks
The risk scores let you set priorities. Decide which risks are acceptable and which require action.
Risk matrix:
| Impact 1 | Impact 2 | Impact 3 | Impact 4 | Impact 5 | |
|---|---|---|---|---|---|
| Likelihood 5 | 5 | 10 | 15 | 20 | 25 |
| Likelihood 4 | 4 | 8 | 12 | 16 | 20 |
| Likelihood 3 | 3 | 6 | 9 | 12 | 15 |
| Likelihood 2 | 2 | 4 | 6 | 8 | 10 |
| Likelihood 1 | 1 | 2 | 3 | 4 | 5 |
Interpretation (example):
- 1-4: Low risk. Accept or monitor
- 5-9: Medium risk. Consider measures
- 10-15: High risk. Measures required
- 16-25: Critical risk. Immediate action needed
Set your risk appetite in advance. What is acceptable for your organisation? This differs by organisation and by type of information. A bank accepts less risk than a bakery.
Step 5: Treat the risks
For each risk above the acceptance threshold, you choose a treatment:
Reduce Take measures to lower the likelihood or the impact. This is the most common choice. You select measures from Annex A or your own measures.
Example: implementing MFA to reduce the risk of unauthorised access.
Accept Consciously accept the risk without further action. This is valid if the cost of measures does not outweigh the risk reduction, or if the risk falls within your risk appetite.
Example: accepting the risk of a short outage because the cost of full redundancy does not outweigh the impact.
Transfer Pass the risk (in part) to another party, usually through insurance or outsourcing.
Example: taking out cyber insurance for the financial consequences of a data breach.
Avoid Stop the activity that causes the risk, or organise it differently.
Example: stopping the processing of certain sensitive data if the risk is too high.
Methods
There are several methods for risk assessment. You do not have to use a specific one, but a recognised method helps with consistency.
ISO 27005
ISO 27005 is the ISO standard for risk management specifically for information security. It fits seamlessly with ISO 27001 and describes the process in detail.
Advantages: Perfect alignment with ISO 27001, internationally recognised Disadvantages: Relatively abstract, you have to fill in the details yourself
FAIR
FAIR (Factor Analysis of Information Risk) is a quantitative method that expresses risks in financial terms.
Advantages: Concrete figures, good for business cases Disadvantages: More complex, requires good data
OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) was developed by Carnegie Mellon University.
Advantages: Well structured, organisation-focused Disadvantages: Can be time-consuming
Pragmatic approach
Many organisations, especially small and medium-sized businesses, choose a pragmatic approach: a spreadsheet with assets, threats, likelihoods, impacts and measures. This is fine as long as you are consistent and document everything.
The ISO 27001 risk register
You document all your risks in a risk register. This is a living document that you update regularly.
Minimum content per risk:
- Unique ID
- Description of the risk
- Related assets
- Likelihood score
- Impact score
- Risk score
- Chosen treatment
- Planned or implemented measures
- Risk owner
- Status
- Date of last review
Example:
| ID | Risk | Asset | Likelihood | Impact | Score | Treatment | Measure | Owner |
|---|---|---|---|---|---|---|---|---|
| R001 | Unauthorised access | Customer database | 3 | 4 | 12 | Reduce | MFA, logging | IT Manager |
| R002 | Ransomware | All systems | 4 | 5 | 20 | Reduce | Backups, EDR, training | CISO |
| R003 | Short outage | Website | 3 | 2 | 6 | Accept | - | IT Manager |
Checklist: ISO 27001 risk assessment
Use this checklist to check whether your risk assessment is complete. Go through it before you schedule the internal audit. If you work under NEN 7510, the same list applies, supplemented with the healthcare-specific points on the NEN 7510 risk assessment page.
- The scope of the ISMS is defined and documented
- The asset inventory is complete (systems, data, processes, people)
- Threats and vulnerabilities have been named for each asset
- The likelihood and impact scales have been set in advance
- Each risk has a likelihood score, an impact score and a risk score
- Risk appetite (acceptance threshold) has been set by the board
- A treatment has been chosen for each risk: reduce, accept, transfer or avoid
- Each risk has an owner
- Chosen measures are linked to the Statement of Applicability
- Assumptions and reasoning are recorded (reproducible)
- The risk assessment has been accepted by the risk owners
- A review date is scheduled (at least once a year)
Tip: A risk assessment does not have to be perfect in the first round. The auditor wants to see that the process is consistent and repeatable, not that you have found every conceivable risk.
Practical tips
Start simple
You do not need to start with the most advanced method. A spreadsheet with 20 to 30 risks is a good start for many organisations. You can refine it later.
Involve the right people
Identifying risks is not a solo task for the security officer. Involve:
- IT (technical risks)
- HR (staffing risks)
- Operations (process risks)
- Management (strategic risks)
- End users (practical knowledge)
Be realistic
Do not exaggerate likelihoods and impacts to get budget, but do not underestimate them either. An honest assessment is more valuable than a politically coloured one.
Document your assumptions
Why do you estimate the likelihood at 3? Why the impact at 4? Record your reasoning. This helps with reviews and makes your assessment reproducible.
Review regularly
Risks change. New threats emerge, systems change, measures get implemented. Plan a full review at least once a year, and ad hoc after major changes.
Link to measures
Every risk you reduce must be linked to concrete measures. Document those measures in your Statement of Applicability (SoA). In it you record, for each Annex A control, whether you apply it and why.
Common mistakes in the ISO 27001 risk assessment
Too technical
Focusing only on IT risks and forgetting the human and organisational side. An employee who loses a USB stick is also a risk.
Too theoretical
Naming risks that exist in theory but are not relevant in your context. A meteorite strike is technically a threat, but it is not something you should focus on.
No ownership
Identifying risks but not making anyone responsible. Every risk must have an owner who is accountable for its treatment.
Set and forget
Doing the risk assessment once for the audit and then putting it in a drawer. Risk management is an ongoing process.
Copying
Taking a risk list from the internet without adapting it to your own situation. The auditor will see through this, and more importantly, it will not help you.
More information
- Requirements of the standard: what does ISO 27001 say about risks?
- The ISMS: how does risk management fit into the whole?
- Annex A controls: which controls can you select?
- Statement of Applicability: from risk to documented choice
- Supplier management: supplier risks in the risk register
- Step-by-step plan: the risk assessment in the overall process
- NEN 7510 risk assessment: for healthcare organisations
- ISO 27005 : the ISO standard for risk management