ISO 27001 Risk Assessment Methodology

Clause 6.1.2 of ISO 27001:2022 sets specific requirements for the risk assessment process. The methodology must:

• Establish risk acceptance criteria
• Be applied consistently across the ISMS scope
• Identify risks to confidentiality, integrity, and availability of information
• Identify risk owners
• Analyze risks (likelihood and impact)
• Evaluate risks against acceptance criteria
• Be documented and repeatable

The standard does not prescribe a specific methodology. It allows asset-based, scenario-based, process-based, or hybrid approaches. The choice depends on what fits your organization. What matters is consistency: every risk assessor uses the same approach with the same scoring scales.

Document the methodology in a risk management procedure. The auditor will read it and verify the risk register matches the methodology. Cross-reference the ISO 27001 reference for clause-by-clause expectations.

Quantitative or qualitative scales both work. The 5x5 qualitative scale is most common because it is simple to apply and explain.

Likelihood scale example:

• 1 (Rare): Less than once every 5 years
• 2 (Unlikely): Once every 2-5 years
• 3 (Possible): Once every 1-2 years
• 4 (Likely): Once or twice per year
• 5 (Almost Certain): Multiple times per year

Impact scale example:

• 1 (Negligible): No business disruption, no financial loss
• 2 (Minor): Minor disruption, less than $10K loss
• 3 (Moderate): Significant disruption, $10K-$100K loss
• 4 (Major): Major disruption, $100K-$1M loss
• 5 (Severe): Existential risk, more than $1M loss or regulatory action

Define the scales in the methodology document and stick to them. Risk score equals likelihood times impact, ranging from 1 to 25.

Risk identification happens through structured workshops, not spreadsheet brainstorming. Effective workshop format:

1. Asset workshop: 2-3 hours per business unit. Identify information assets (data, systems, processes) in scope. Each asset gets confidentiality, integrity, and availability ratings.
2. Threat workshop: 2-3 hours with security and IT. For each asset category, identify relevant threats (insider misuse, ransomware, system failure, supplier breach).
3. Vulnerability workshop: 2-3 hours with technical teams. For each threat, identify vulnerabilities that could be exploited.
4. Risk synthesis: Map asset + threat + vulnerability combinations into risk statements.

Risk statements follow a consistent format: "Threat actor exploits vulnerability to compromise asset, resulting in impact." For example: "Ransomware exploits unpatched server vulnerabilities to encrypt customer data, resulting in availability loss and regulatory notification obligation."

Aim for 30-100 risks across the scope. Fewer means you missed things. More means you are at too low a level of abstraction.

Each identified risk is rated, then evaluated against the risk acceptance criteria. The acceptance criteria define which risk levels require treatment. A common pattern: any risk above 12 (likelihood 4, impact 3 or higher) requires treatment.

Four treatment options under ISO 27001:

• Modify (apply controls): Implement Annex A controls or other controls to reduce likelihood, impact, or both
• Avoid: Eliminate the activity that creates the risk
• Share (transfer): Insurance, contractual transfer to vendors, outsourcing
• Accept: Document the rationale and risk owner accountability

Most risks land in "modify" with applied controls. The risk treatment plan documents which controls apply to each risk. The Statement of Applicability then traces those controls back to Annex A references.

Risk acceptance must be explicit. "We are not going to do anything about this risk" requires a documented decision by the risk owner with reasoning. Auditors flag implicit acceptance as a finding.

The risk assessment is not a one-time exercise. ISO 27001 requires regular review and update:

• Scheduled reviews: Annual full review at minimum. Many programs review quarterly.
• Triggered reviews: After major changes (new product, acquisition, significant incident, regulatory change)
• Continuous monitoring: New risks identified through threat intelligence, vulnerability disclosure, vendor breaches

Track risk register changes over time. Auditors look for evidence the register is alive: risks added, scores updated, controls implemented and risks closed. A frozen register from 18 months ago is a red flag.

Tie the risk review to management review (clause 9.3). Senior leadership should see the top 10-20 risks at least annually with treatment status. This satisfies both clause 6.1 and clause 9.3 requirements.