ISO 27001 Clause 6.1 requires your organisation to define and apply an information security risk assessment process. This is not a tick-box exercise — it is the analytical foundation that determines which controls you implement, which risks you accept, and how you demonstrate to an auditor that your ISMS is proportionate and reasoned. A risk assessment that is clearly connected to your Statement of Applicability is the hallmark of a mature ISMS. A disconnected one is the most common reason organisations fail their Stage 2 audit.
Step 1: Define Your Risk Assessment Methodology
Before you assess a single risk, you must document the methodology you will use. The standard does not prescribe a specific approach — it requires that your approach is consistent, repeatable, and produces comparable results. You need to decide:
- Whether you will use an asset-based approach (identify information assets, then identify threats and vulnerabilities to each) or a scenario-based approach (identify threat scenarios and assess their likelihood and impact directly)
- How you will score likelihood — typically a 3-point or 5-point scale
- How you will score impact — what constitutes low, medium, and high impact for your organisation
- How likelihood and impact combine to produce a risk rating — usually a simple matrix
- What risk acceptance criteria apply — above what score must a risk be treated?
For most small-to-medium organisations, the scenario-based approach is more practical. Asset-based approaches require maintaining a comprehensive asset register, which adds overhead. The scenario approach allows you to focus directly on realistic threat scenarios relevant to your organisation.
Step 2: Identify the Risks
Risk identification is a structured exercise, not a brainstorm. You are looking for scenarios where information assets in your ISMS scope could be subject to a loss of confidentiality, integrity, or availability — the three properties ISO 27001 is designed to protect.
Common risk categories to work through include:
- Unauthorised access to systems or data (external attackers, insider threat, misconfigured access controls)
- Data loss or leakage (accidental disclosure, inadequate data handling, lost devices)
- Ransomware and malware attacks
- Phishing and social engineering leading to credential compromise
- Supplier or third-party security failures
- Availability failures (system outages, infrastructure failures, DDoS)
- Software vulnerabilities in your own products or in third-party software you depend on
- Physical access by unauthorised persons
- Non-compliance with legal and regulatory requirements
Aim for 30 to 60 risk entries in your initial register. Fewer than 20 will look superficial to an auditor. More than 80 is usually a sign of over-granularity that makes the register difficult to maintain.
Step 3: Score Each Risk
For each identified risk scenario, score likelihood and impact using the scales you defined in your methodology. A simple 3x3 matrix (low/medium/high for each dimension) is sufficient for most organisations and is much easier to maintain than a 5x5 matrix. The resulting risk score tells you the inherent risk level — before any controls are applied.
Sample 3×3 Risk Matrix
| Likelihood ↓ / Impact → | Low Impact | Medium Impact | High Impact |
|---|---|---|---|
| High Likelihood | Medium | High | Critical |
| Medium Likelihood | Low | Medium | High |
| Low Likelihood | Low | Low | Medium |
Treat = High/Critical · Accept = Low/some Medium · Document all decisions
Inherent risk versus residual risk: the inherent risk is what exists before controls. The residual risk is what remains after controls are applied. Your risk register should capture both. For risks you treat with controls, the residual risk score should be lower than the inherent risk score — this demonstrates that your controls are effective. Auditors will look for this logical flow.
Step 4: Decide on Risk Treatment
For each risk above your acceptance threshold, you must choose a treatment option. There are four:
Treat (Reduce)
Implement controls to reduce the likelihood or impact of the risk to an acceptable level. This is the most common treatment for high and medium risks. When you select this option, you must specify which Annex A controls (or other measures) you will implement, and record this in the risk treatment plan.
Tolerate (Accept)
Accept the risk without implementing additional controls, because the cost of treatment exceeds the potential harm. This is valid for low-scoring risks that fall within your defined acceptance criteria. The acceptance must be formally recorded and signed off by appropriate management — an undocumented acceptance is not the same as a documented one.
Terminate (Avoid)
Stop the activity that creates the risk — for example, stop collecting a category of data that is not necessary for your operations, or stop using a supplier whose practices create unacceptable risk. This is less common but appropriate in specific circumstances.
Transfer (Share)
Transfer the financial consequence of the risk to a third party through insurance or contractual arrangements. Cyber insurance is the most common form. Transfer does not eliminate the risk — it manages the financial impact if the risk materialises.
Step 5: Link Risk Treatment to Annex A Controls
For risks you have chosen to treat, identify which Annex A controls address them and record this linkage. This is the connection that ties your risk register to your Statement of Applicability — it is what allows you to explain to an auditor why you selected each control. A control that appears in your SoA but cannot be traced to a risk in your register is a red flag. A risk in your register with no corresponding control is equally problematic.
How Often to Update the Risk Register
The standard requires risk assessment to be conducted at planned intervals and when significant changes occur. In practice, a full review annually — before your management review — is the minimum. Trigger reviews should also happen when you onboard a significant new supplier, launch a new product or service, enter a new market, or experience an incident that reveals a gap in your assessment.
A risk register that has not been touched since initial certification is a surveillance audit problem waiting to happen. Even if nothing has changed materially, you should document a review that confirms this — the evidence of the review is what matters.
Download our free risk register template from Gumroad to get a pre-structured starting point with scoring formulas, treatment columns, and Annex A control mapping built in. Or browse the full ISO 27001 template library for the complete documentation set.