How to Do an ISO 27001 Risk Assessment (Step by Step)

An ISO 27001 risk assessment is required by clause 6.1.2, and its quality depends on reflecting your real environment, not the template you start from. Here is how to define a repeatable method, identify and rank risks, and turn the results into a treatment plan and Statement of Applicability.

Start by defining a repeatable methodology

ISO/IEC 27001:2022 clause 6.1.2 requires you to define and apply an information security risk assessment process that produces "consistent, valid and comparable results." In plain terms: anyone following your method on the same situation should reach roughly the same answer, and a result this year should be comparable to one next year. That repeatability is the whole point of writing the methodology down before you assess anything.

The first decision is how you will identify risks. The 2022 standard is deliberately methodology-neutral — unlike the older 2005 edition, it does not mandate an asset-based approach, so you genuinely get to choose. An asset-based method starts from an inventory (systems, data stores, devices, suppliers) and asks what threats and vulnerabilities apply to each. A scenario-based method starts from plausible events ("ransomware encrypts our production database," "a laptop with customer data is stolen") and works back to causes and consequences. Many organizations blend the two. Pick whichever your team can actually execute consistently.

Then define your scales and criteria. Most teams use a likelihood scale and an impact scale — often a simple 1-to-5 each — combined into a risk level (commonly likelihood multiplied by impact, or read off a heat-map matrix). Crucially, clause 6.1.2 also requires you to establish risk acceptance criteria: the threshold above which a risk must be treated rather than tolerated. Decide all of this up front and record it. A methodology document or workbook gives you that structure out of the box; the scales and thresholds still have to reflect how your organization actually thinks about risk.

Identify risks to confidentiality, integrity, and availability

With the method set, identify the risks themselves. ISO 27001 frames information security around three properties — confidentiality, integrity, and availability (the "CIA triad") — so a thorough assessment asks, for each asset or scenario in scope, what could compromise each property. Confidentiality is about unauthorized disclosure; integrity is about unauthorized or accidental alteration; availability is about access being lost when it is needed. The same system often carries distinct risks under each heading: a customer database faces a confidentiality risk from a breach, an integrity risk from corrupted or tampered records, and an availability risk from an outage or ransomware.

Draw on real sources rather than imagination alone. Useful inputs include your asset and supplier inventories, past incidents and near-misses, vulnerability scan results, threat intelligence, the concerns of interested parties you identified when scoping the ISMS, and the practical knowledge of the people who run each system. Cover the obvious technical threats, but do not stop there — human error, lost or stolen devices, malicious insiders, supplier failures, and physical events all belong in the picture.

Clause 6.1.2 also requires something teams often miss: assign a risk owner to each identified risk. The risk owner is the person with the authority and accountability to make decisions about that risk — not necessarily the person who fixes it. Naming owners now prevents the common failure where a risk register is full of risks that belong to no one and therefore move nowhere.

Analyze, evaluate, and rank what you found

Analysis is where you apply the scales you defined. For each risk, assess the potential consequence (impact) if it materialized and the likelihood of it happening, then derive the risk level from your matrix or formula. Be honest and evidence-based: the temptation is to soften scores so the picture looks calmer, but an assessment that understates reality only fails you later, in an incident or in front of an auditor. Where you have data — incident history, industry frequency, control maturity — use it; where you do not, document the reasoning behind your estimate so the score is defensible and repeatable.

Evaluation is the next, distinct step: compare each analyzed risk against the risk acceptance criteria you set in your methodology, and prioritize. Risks above your acceptance threshold need treatment; risks at or below it may be knowingly accepted (by the risk owner) and recorded as such. Sorting the results from highest to lowest risk level gives you a ranked list that drives where you spend effort first.

This ranking is the bridge to treatment. It tells you which risks demand attention now, which can wait, and which you are accepting as-is — turning a long, flat inventory of concerns into a prioritized program of work.

Record everything in a risk register

The risk register is the documented information clause 6.1.2 expects you to retain, and it is one of the first artifacts an ISO 27001 auditor typically asks to see. It is the single, living record of your assessment, and its value comes from being maintained, not from being perfect on day one.

A workable register captures, for each risk: a unique identifier; a clear description (the asset or scenario, plus the threat and vulnerability or the event); the property affected (confidentiality, integrity, or availability); the named risk owner; the likelihood, impact, and resulting risk level; the evaluation decision (treat or accept); and, once treatment begins, the planned actions, status, and the residual risk level expected after treatment. A spreadsheet workbook handles this comfortably for most small and mid-sized organizations.

Treat the register as a working tool, not a one-time deliverable. It should change as you implement controls, as new risks emerge, and as you reassess. Dated entries and a visible status for each item are what let you — and an auditor — see that the assessment is genuinely alive rather than a document written once and forgotten.

Build the treatment plan and map to Annex A and the SoA

Risk treatment is a separate clause — 6.1.3 — and getting the relationship right matters. For each risk you decided to treat, choose an option: modify it (apply controls to reduce likelihood or impact), avoid it (stop the activity that creates it), share it (for example, via insurance or a supplier), or retain it (accept it knowingly within your criteria). Then determine the specific controls needed to carry out your chosen treatments, and capture all of this in a risk treatment plan.

Here is the order that signals you have actually read the standard: you determine the controls your treatment decisions require first, and only then compare that set against Annex A. ISO/IEC 27001:2022 Annex A is a reference list of 93 controls across four themes — Organizational, People, Physical, and Technological — and clause 6.1.3 uses it as a completeness check, not a menu you shop from. You compare your chosen controls against Annex A to verify that no necessary control has been overlooked. The result is documented in the Statement of Applicability (SoA), which records, for every one of the 93 Annex A controls, whether it is included or excluded, the justification, and its implementation status.

Finally, clause 6.1.3 requires the relevant risk owners to approve the risk treatment plan and to accept the residual risks that remain after treatment. That sign-off is what turns a list of intended controls into an authorized program — and it is the formal link between your assessment and the controls you operate.

Keep the assessment current

A risk assessment is a snapshot, and snapshots age. ISO/IEC 27001:2022 clause 8.2 requires you to perform information security risk assessments at planned intervals or when significant changes are proposed or occur. "At least annually" is a widely used good-practice cadence rather than literal wording in the standard, so set a planned interval that suits your environment and stick to it — but do not wait for the calendar when something material changes. Because clause references and requirements can shift between editions, confirm the current specifics against the official ISO/IEC 27001:2022 text rather than relying on summaries.

Significant changes that should trigger a reassessment include adopting a new system or major supplier, a meaningful shift in your products or processing, a relevant new threat or a serious incident, an acquisition or reorganization, or a change in legal or contractual obligations. Each of these can introduce risks your last assessment never considered or change the likelihood and impact of risks already on the register. Reassessing on change is what keeps the register, the treatment plan, and the SoA honest.

This is also the honest limit of any tool. A methodology document, a risk-assessment workbook, or a register template gives you a consistent, repeatable structure and removes the slow work of building all of that from a blank page. What it cannot do is the analysis itself: the risks, scores, owners, and treatment decisions have to reflect your actual environment, and keeping them current is ongoing work only your organization can do. The structure accelerates the assessment; the judgment that makes it valid — and credible to an auditor — is yours.

Frequently asked questions

Does ISO 27001 require an asset-based risk assessment?

No. ISO/IEC 27001:2022 is methodology-neutral and does not mandate an asset-based approach — that was a feature of the older 2005 edition. You may identify risks by working from an asset inventory, by working from plausible threat scenarios, or by blending both. What clause 6.1.2 actually requires is that your chosen process is defined, applied consistently, and produces "consistent, valid and comparable results." Pick the method your team can run repeatably.

What is the difference between the risk assessment and the risk treatment plan?

They live in different clauses and do different jobs. The risk assessment (clause 6.1.2) identifies, analyzes, evaluates, and ranks your information security risks and assigns each a risk owner. The risk treatment plan (clause 6.1.3) then decides what to do about the risks you chose to treat — modify, avoid, share, or retain them — determines the controls needed, compares those against Annex A, and is approved by the risk owners. In short, the assessment tells you what your risks are; the treatment plan records how you will address them.

How does the risk assessment connect to Annex A and the Statement of Applicability?

Through risk treatment. You first determine the controls your treatment decisions require, then compare that set against the 93 reference controls in Annex A of ISO/IEC 27001:2022 to check that you have not missed anything necessary — Annex A is a completeness check, not a menu to shop from. The Statement of Applicability (SoA) then records, for every one of the 93 controls, whether it is included or excluded, why, and its implementation status. The SoA is the documented link between your assessed risks and the controls you operate.

How often should an ISO 27001 risk assessment be updated?

Clause 8.2 requires risk assessments at planned intervals or when significant changes are proposed or occur. Many organizations adopt an annual cadence as good practice, but "at least annually" is a common convention rather than literal text in the standard, so set a planned interval that fits your environment and confirm the current requirements against the official ISO/IEC 27001:2022 text. Regardless of the interval, reassess when something material changes — a new system or major supplier, a significant new threat or incident, a reorganization, or a change in legal or contractual obligations.

Does a risk assessment template or workbook make my organization ISO 27001 certified?

No. A template or workbook gives you a repeatable methodology, scales, and a register structure so you are not building from a blank page, but the analysis must reflect your real environment — the risks, scores, owners, and treatment decisions are yours to make. ISO 27001 certification is issued only by an accredited certification body after it audits a working information security management system (ISMS); a document set, on its own, cannot confer it. A toolkit accelerates and structures the documentation — it does not, by itself, make your organization certified.

Related guides: ISO/IEC 27001

Toolkits that help

← All articles