ISO 27001 Clause 8.2 Information Security Risk Assessment is an operational control that requires organisations to perform risk assessments at planned intervals. It ensures you identify and evaluate risks based on criteria established in Clause 6.1.2, keeping your risk treatment plan relevant and effective for your current business environment.
Attributes Table
| Attribute | Value |
|---|---|
| Control Type | Plan and Do (Operational) |
| Information Security Properties | Confidentiality, Integrity, Availability |
| Cybersecurity Concepts | Identify, Protect |
| Operational Capabilities | Governance, Risk Management |
Implementation Difficulty & Cost
| Metric | Rating / Detail |
|---|---|
| Difficulty | 4/5 (High Complexity) |
| Implementation Cost | Medium (Staff time and software) |
| Primary Owner | Chief Information Security Officer (CISO) |
| Accountability | Risk Management Committee / Top Management |
ISO 27002 Control Guidance
In my experience, Clause 8.2 is the engine room of your ISMS. You must execute the methodology defined in Clause 6.1.2 consistently. It is not enough to have a policy; you must produce evidence of risk identification and evaluation that aligns with your stated risk appetite.
The technical aspect involves mapping your assets to specific threats and vulnerabilities. I often see firms miss cloud-native risks like misconfigured S3 buckets or API exposures. Your assessment must look at these technical realities, not just high-level business risks.
Behavioral factors are equally vital. You must engage with department heads to understand how they actually handle data. I look for evidence that the risk assessment reflects real-world workflows rather than a theoretical exercise conducted in a vacuum by the IT team.
The Auditor’s Eye: Expert Insight
I often find that organisations treat Clause 8.2 as an annual “tick-box” exercise. This is a mistake. When I audit this clause, I look for “Trigger Events.” If you moved your infrastructure to AWS six months ago, I expect to see a risk assessment dated around that time. If your risk register only updates once a year regardless of business changes, I will likely issue a Major Non-Conformity (NC). I also look at meeting minutes to ensure the results were shared with risk owners.
10 Steps to Implement Clause 8.2
-
Confirm Methodology
Ensure your operational activity matches the process defined in Clause 6.1.2. Use tools like Jira to track assessment tasks. I check that the scoring logic remains consistent across different business units.
-
Identify Asset Owners
Assign every data asset to a specific individual. They are the best people to identify local risks. In my experience, unidentified ownership leads to overlooked risks during the assessment cycle.
-
Gather Threat Intelligence
Use feeds from sources like NCSC or CISA to identify current threats. Don’t just guess what might happen. I want to see that your assessment reflects the current global threat environment.
-
Perform Vulnerability Scans
Use tools like Nessus or Tenable to find technical weaknesses. These scan results should feed directly into your risk identification process. I look for the link between these logs and your risk register.
-
Determine Impact Levels
Quantify the damage if a risk occurs. Use financial, legal, and reputational scales. I often find that companies underestimate the regulatory fines associated with data breaches when scoring impact.
-
Assess Likelihood
Calculate how often a threat might exploit a vulnerability. Use historical data and industry trends. Be realistic; not everything is “Low” likelihood just because it hasn’t happened yet.
-
Calculate Risk Levels
Multiply impact by likelihood based on your 6.1.2 formula. This creates a prioritised list for treatment. I check that the math in your risk register actually works.
-
Compare Against Risk Appetite
Identify which risks exceed your acceptable thresholds. This is where you decide to Treat, Tolerate, Transfer, or Terminate. I look for formal sign-off from management on these decisions.
-
Produce Risk Assessment Reports
Document the findings clearly for stakeholders. Use dashboards in tools like PowerBI or dedicated GRC software. I expect these reports to be legible to non-technical directors.
-
Schedule Re-assessments
Set dates for the next review based on risk severity. High-risk areas need more frequent checks. I look at your calendar to ensure these reviews are actually happening as planned.
Requirements by Environment
- Office: Focus on physical access, clean desk policies, and local network security risks.
- Home: Focus on Wi-Fi security, shoulder surfing, and the use of personal devices for work.
- Cloud: Focus on IAM permissions, data residency, and third-party provider outages.
The “Checkbox Compliance” Trap
| Requirement | SaaS Tool Trap | Auditor Reality |
|---|---|---|
| Risk Identification | Using a generic “template” from a GRC tool. | Must show risks unique to your specific business processes. |
| Regular Intervals | Setting a “review date” and then ignoring it. | Evidence of actual review activity and updated risk scores. |
| Asset Links | Risks not mapped to specific information assets. | I want to see exactly which database or service is at risk. |
10 Steps to Audit Clause 8.2 (Internal Audit Guide)
- Verify Methodology: Check if the current assessment follows the rules set in Clause 6.1.2.
- Check Sample Risks: Pick three risks and trace them from identification to the treatment plan.
- Verify Dates: Ensure the assessment occurred within the timeframe specified in your policy.
- Interview Owners: Ask risk owners if they were involved in the scoring process.
- Review Threat Sources: Ask how the team identifies new threats. Look for external sources.
- Check Asset Inclusion: Verify that new hardware or software bought recently is in the assessment.
- Validate Scores: Check if the impact and likelihood scores make sense for the business size.
- Examine Thresholds: Ensure risks above appetite have a corresponding treatment plan.
- Review Management Approval: Look for a signature or email approval from Top Management.
- Check Consistency: Compare the risk register with incident logs to see if “real” risks are captured.
Clause 8.2 Audit Evidence Checklist
| Evidence Item | Pass/Fail Criteria | Owner |
|---|---|---|
| Risk Register | Must be updated within the last 12 months (or per policy). | CISO |
| Risk Assessment Report | Must detail the methodology used and the final scores. | Risk Manager |
| Management Sign-off | Evidence of board or committee review of risk results. | COO/CEO |
Required Policy Content: A Lead Auditor’s Checklist
- Methodology Reference: Explicitly link to the Clause 6.1.2 risk assessment methodology.
- Assessment Frequency: Define exactly how often assessments occur (e.g., annually or after change).
- Roles and Responsibilities: Define who identifies risks and who approves the scores.
- Risk Criteria: List the scales for impact and likelihood used during the operational phase.
- Reporting Path: Define how the results reach the Risk Management Committee.
What to Teach Employees
- Risk Awareness: How to spot a potential security risk in their daily tasks.
- Reporting Channels: Who to tell when they identify a new threat or vulnerability.
- Ownership: What it means to be a “Risk Owner” or “Asset Owner” in the ISMS.
Enforcement and Consequences
Failure to perform regular risk assessments is a fundamental ISMS failure. I follow a strict path: Verbal warning for minor documentation gaps, Written NC for missed intervals, and potential certification suspension for a total lack of risk assessment evidence. Employees who fail to participate in mandated risk reviews should face disciplinary action per your HR policy.
Common Implementation Challenges
| Challenge | Root Cause | Solution |
|---|---|---|
| Stale Risk Data | Treating it as a static document. | Link risk reviews to your Change Management process. |
| Subjective Scoring | Lack of clear definitions for “High” or “Low.” | Use financial values (e.g., £10k – £100k) for impact scales. |
| Lack of Engagement | Staff see it as a “technical” burden. | Conduct workshops rather than sending spreadsheets. |
Sample Statement of Applicability (SoA) Entry
“Clause 8.2 is applicable. We perform information security risk assessments at planned intervals and when significant changes occur. Evidence is maintained in our Risk Register and reported to the Board quarterly. This ensures our controls remain effective against the current threat landscape.”
Changes from ISO 27001:2013
| 2013 Version | 2022 Version |
|---|---|
| Clause 8.2 (Execution of 6.1.2) | Clause 8.2 (Remains largely the same, but with stronger links to 6.1.2) |
| Less emphasis on “change” triggers. | Clearer expectation for re-assessment after significant changes. |
How to Measure Effectiveness (KPIs)
- Percentage of Risk Reviews Completed: Number of planned assessments vs. those actually finished on time.
- Risk-to-Incident Ratio: How many incidents were already identified as “High Risk” in your register? (Higher is better for identification accuracy).
- Time to Assess Changes: Average days between a major system change and its updated risk assessment.
Related ISO 27001 Controls
- ISO 27001 Clause 6.1.2: This provides the methodology that you must follow in Clause 8.2.
- ISO 27001 Annex A 5.12: Information classification helps determine the “Impact” score during your risk assessment.
- ISO 27001 Annex A 8.8: Vulnerability management provides the technical data needed to assess the “Likelihood” of a risk.
ISO 27001 Clause 8.2 FAQ
How often must we perform a risk assessment?
ISO 27001 says “at planned intervals.” Most organisations do this annually, but you must also perform one whenever a significant change occurs in the business or threat landscape.
Do we need special software for Clause 8.2?
No, a spreadsheet can work for smaller firms. However, as you grow, GRC tools help manage the complex relationships between assets, threats, and owners.
What is the difference between Clause 6.1.2 and 8.2?
6.1.2 is the “Planning” stage where you decide *how* to do it. 8.2 is the “Operation” stage where you actually *do* it.
Who should sign off on the risk assessment results?
Top Management or a delegated Risk Committee must review and approve the results to show they accept the residual risks.
Can an auditor fail us if we miss one risk?
Unlikely for a single minor risk. However, if I find a systemic failure to identify obvious risks, I will issue a Non-Conformity.