ISO 27001 Risk Assessment Methodology: The Essential 2026 Guide to Choosing an Approach

Your ISO 27001 risk assessment methodology is the document an auditor reads first when testing whether your risk work is real. It does not have to follow a particular template, and the standard does not force an asset-by-asset spreadsheet, but it does have to define how you will identify, analyze and evaluate risks so that repeated assessments give consistent, comparable results. Teams that skip this step end up with a risk register no two people could reproduce.

This guide explains what clause 6.1.2 of ISO 27001:2022 requires, compares the asset-based and event-based approaches described in ISO/IEC 27005:2022, helps you choose between them and sets out a six-step method you can document and defend.

What clause 6.1.2 requires from an ISO 27001 risk assessment methodology

Clause 6.1.2 asks you to define and apply an information security risk assessment process. In practical terms, your ISO 27001 risk assessment methodology has to cover five things.

1. Risk criteria. Establish and maintain criteria, including risk acceptance criteria and the criteria for performing assessments.
2. Consistency. Make sure that repeated assessments produce consistent, valid and comparable results.
3. Risk identification. Identify risks associated with loss of confidentiality, integrity and availability of information within the scope of the management system, and identify risk owners.
4. Risk analysis. Assess the potential consequences, assess the realistic likelihood and determine the levels of risk.
5. Risk evaluation. Compare results with your criteria and prioritize risks for treatment.

You must also keep documented information about the process and its results. Notice what is absent: the standard does not say you must list assets, threats and vulnerabilities in a particular way. That is a choice, and it is why your methodology document matters. For the overall process, see our guide to ISO 27001 risk assessment, and for the standard itself see the ISO/IEC 27001 page on iso.org.

Asset-based vs event-based: two ways to identify risk

ISO/IEC 27005:2022, the guidance standard for information security risk management, describes two approaches to identifying risk. Its fourth edition was published in October 2022 and was aligned with ISO 27001:2022 and ISO 31000:2018. You can check the details on the ISO/IEC 27005:2022 page on iso.org.

	Asset-based approach	Event-based approach
Starting point	Specific assets in scope	Risk sources and strategic scenarios
Question asked	What threatens this asset, and what weakness could be exploited?	What events could harm our objectives, and how would they unfold?
Level of detail	Granular and operational	Higher level and strategic
Best for	Detailed technical treatment planning	Organization-wide threat analysis and consequence severity
Main risk	Long registers that nobody maintains	Vague scenarios that do not link to controls
Typical evidence	Asset inventory, threat and vulnerability lists	Scenario descriptions, risk source analysis

Neither approach is more compliant than the other. Auditors test whether the method you chose is defined, applied consistently and produces results that lead to treatment decisions.

Choosing between them

Small and mid-sized organizations often do better with scenarios. A dozen well-written scenarios such as ransomware on core systems, loss of a key supplier or accidental disclosure of customer data are easier to score and maintain than a thousand asset lines. Larger or highly regulated organizations often need asset-level detail for critical systems, because technical teams need specific vulnerabilities and controls to act on. Many use a hybrid: scenarios at the strategic level and an asset-based analysis for the systems that matter most.

Pick the approach that you can keep current. A register that is accurate for two systems beats one that claims to cover two hundred and is out of date within a quarter. Our guide to ISO 31000 versus ISO 27005 explains how the two guidance standards relate.

A 6-step ISO 27001 risk assessment methodology you can document

1. Define scope and context. Tie the assessment to the scope of your management system and to your interested parties.
2. Set risk criteria. Write down your scales for likelihood and consequence and your acceptance threshold. Our guide to risk criteria shows how.
3. Choose the identification approach. State whether you use assets, events or a hybrid and why.
4. Identify risks and owners. Record each risk in terms of confidentiality, integrity or availability, with a named owner.
5. Analyze and evaluate. Score consequence and likelihood, then compare with acceptance criteria and rank.
6. Feed treatment. Send risks above the threshold to your risk treatment plan and, from there, into the Statement of Applicability.

The same risk in both approaches

Take a hypothetical mid-sized company whose customer database sits on a cloud platform. Under the asset-based approach, the team lists the database as an asset, identifies threats such as credential theft and misconfiguration, notes vulnerabilities such as weak administrative access and missing logging, and scores the resulting combinations one by one. The output is a set of specific, technical risks that engineers can fix directly.

Under the event-based approach, the team writes a single scenario: an attacker gains privileged access to the customer database and copies the records, leading to regulatory notification, customer loss and contract penalties. They score the consequence and likelihood of the whole scenario, then list the controls that would prevent or limit it. The output is a smaller number of risks that executives can understand quickly, with control gaps identified underneath.

Both are valid, and both need an owner, a score and a treatment decision. The practical difference is how much effort each takes to maintain and who reads the result. If your executives will read the register, scenarios usually communicate better. If your engineers will work from it, asset-level detail helps more.

What to write in the methodology document

The methodology should be short enough to be read and specific enough to be followed. A good one is five to ten pages and includes the following.

• Purpose and scope. What the process covers and when it is run.
• Roles. Who leads the assessment, who owns risks, who approves acceptance.
• Approach. Asset-based, event-based or hybrid, with the reasoning.
• Scales. Definitions for each likelihood and consequence level, with examples.
• Risk matrix and acceptance criteria. The scoring rule and the score above which treatment is required.
• Timing. Annual assessment plus triggers such as major changes and incidents.
• Records. Where results are kept and how they are approved.

Making results consistent and comparable

The consistency requirement is where many methodologies fall down, and auditors often sample two or three risks and ask how each score was reached, so keep your rationale notes close. Two assessors given the same scenario should land on similar scores. Achieve that with written definitions, worked examples for each scale level and a calibration session where several people score the same three or four risks and discuss differences. Record the outcome. If you rerun the assessment next year with different people, the calibration notes make the results comparable.

Keep a change log for the methodology itself. If you alter a scale or the acceptance threshold, record when and why, and note that earlier scores were made on the old basis. Otherwise a year-on-year comparison will mislead management.

Common ISO 27001 risk assessment methodology mistakes

• Copying a template unchanged. Scales and thresholds must fit your organization.
• Undefined acceptance criteria. Without a threshold, nobody can say which risks need treatment.
• Owners missing. Clause 6.1.2 expects risk owners to be identified.
• Method and register disagree. If the document says scenarios and the register lists assets, an auditor will notice.
• Never reviewed. Revisit the methodology when scope, systems or the business change.
• Risks with no link to controls. Every treated risk should point to controls and the Statement of Applicability.

Start from a finished ISO 27001 risk assessment methodology

Building the scales, heat maps and treatment links from scratch is the slow part. The ISO 27001 Risk Assessment Report and Workbook provides a ready structure with a risk register, heat maps, a treatment plan and a live workbook that you adapt to your own scope. If you already keep a register, our guide to the cybersecurity risk register shows the fields to include.

ISO 27001 risk assessment methodology FAQ

Does ISO 27001 require an asset-based risk assessment?

No. Clause 6.1.2 requires you to identify risks to confidentiality, integrity and availability within scope but does not require a specific method. You may use assets, scenarios or a combination, as long as the method is defined and consistent.

Which approach do auditors prefer?

Auditors do not prefer one approach. They check that your ISO 27001 risk assessment methodology is documented, applied as written and produces results that drive treatment decisions.

How often must the risk assessment be repeated?

The standard expects assessments at planned intervals and when significant changes are proposed or occur. Annual assessment plus event triggers is a common pattern.

Can I use ISO 27005 as my methodology?

ISO 27005 is guidance, not a certification standard, and it can inform your methodology. You still need to document your own criteria, scales and process so they fit your organization.

Do I need risk owners for every risk?

Yes. Clause 6.1.2 requires risk owners to be identified, and the owner is normally the person accountable for accepting or treating the risk.