How to Conduct an ISO 27001 Risk Assessment (2022 Step-by-Step Guide)

What ISO 27001:2022 Requires for Risk Assessment

Clause 6.1.2 of ISO 27001:2022 requires every ISMS to define and apply an information security risk assessment process that produces consistent, valid, and comparable results. In plain terms, two people doing the same assessment must reach similar conclusions, and the same risk must score the same way every time you re-evaluate it.

The standard does not prescribe a specific methodology. You can use qualitative, quantitative, or hybrid approaches as long as you document the criteria, apply them consistently, and keep evidence of every decision. Most organizations choose a qualitative 5x5 likelihood-by-impact matrix because it is fast to operate and easy for auditors to follow.

Step 1 - Define Your Risk Criteria

Before you score a single risk, document two things: the criteria for accepting risk, and the criteria for performing assessments. Auditors will ask for both.

• Risk acceptance criteria. Which scores can be accepted as-is, and who is allowed to accept them. A common pattern: low risks accepted by the risk owner, medium risks by the ISMS manager, high and critical risks by top management.
• Likelihood scale. Define what 1-5 mean (e.g. 1 = once every 5+ years, 5 = monthly or more).
• Impact scale. Define what 1-5 mean across the categories that matter to your business: confidentiality, integrity, availability, financial loss, regulatory, reputation.
• Risk matrix. Multiply likelihood by impact to get an inherent risk score, then map score bands to severity (low/medium/high/critical).

Write these down once in a "Risk Assessment Methodology" document. Every assessment from now on references it.

Step 2 - Identify Risks

Clause 6.1.2 c) requires you to identify risks associated with the loss of confidentiality, integrity, and availability of information within the scope of your ISMS. The cleanest way to do this is the asset-threat-vulnerability model:

1. List your information assets - databases, source code repositories, customer data, employee laptops, SaaS tenants, physical sites.
2. For each asset, identify relevant threats - ransomware, insider misuse, supplier outage, lost device, misconfiguration.
3. For each threat, identify the vulnerability that would let it materialize - missing MFA, unpatched software, no offsite backup, no access review.
4. Combine into a risk statement - "Customer PII in the production database is exposed because of SQL injection in the web app."

Aim for 30-80 risks for a small organization. Fewer than 20 is usually too thin; more than 150 is hard to maintain.

Step 3 - Assign Risk Owners

Every risk needs a single named owner who is accountable for the treatment decision. This is a hard requirement of clause 6.1.2 c) 2). The owner is usually the manager of the function most affected - the CTO owns engineering risks, the Head of People owns HR risks, the CFO owns financial-process risks.

Avoid assigning all risks to the CISO or "IT". Auditors will challenge that pattern, and it puts decision-making on someone who cannot actually implement the fix.

Step 4 - Analyze Risks (Inherent Score)

For each risk, score likelihood and impact using the scales you defined in Step 1, before considering any existing controls. The product is the inherent risk score.

Document the rationale for each score in one sentence. "Likelihood 4 because we publish endpoints publicly and have seen scanning attempts in logs." That sentence is what an auditor reads to test whether your process is consistent.

Step 5 - Evaluate Against Acceptance Criteria

Compare each inherent score to the acceptance criteria from Step 1. Anything above the acceptance threshold needs treatment. Anything at or below can be formally accepted, but the acceptance still needs to be recorded with the owner's name and the date.

This is also where you decide priority. Critical risks get treated this quarter, high risks within six months, medium risks within the year.

Step 6 - Plan Risk Treatment

Clause 6.1.3 gives you four treatment options:

• Modify - apply controls to reduce likelihood or impact (most common).
• Avoid - stop doing the activity that creates the risk.
• Share - transfer via insurance, contract, or outsourcing.
• Accept - acknowledge and live with it, with formal sign-off.

For "modify" treatments, map each chosen control back to Annex A. This is what feeds your Statement of Applicability. After treatment is implemented, re-score likelihood and impact to get the residual risk score. The residual score is what you carry forward into ongoing monitoring.

Step 7 - Document Everything in a Risk Register

Your risk register is the single source of truth. For each risk, capture: ID, statement, asset, threat, vulnerability, owner, inherent likelihood/impact/score, treatment option, mapped Annex A controls, treatment plan, target date, residual likelihood/impact/score, acceptance status, last reviewed date.

If you are still using a spreadsheet, the free ISO 27001 risk register template on this site mirrors this structure. For a maintained register with automated scoring, audit trail, and reports, the Risk Assessment tool does the same job without the spreadsheet drift.

Step 8 - Review on a Schedule

Clause 8.2 requires risk assessments to be performed at planned intervals and when significant changes occur. The pragmatic rhythm:

• Quarterly - review high and critical risks, update residual scores if controls changed.
• Annually - full re-assessment of every risk in the register.
• Event-driven - any new system, new supplier, new regulation, or security incident triggers a targeted re-assessment.

Every review must be recorded. "Reviewed by Jane on 2026-06-15, no change" is enough.

Common Audit Findings to Avoid

• No documented methodology. You jumped straight to scoring risks without writing down the scales.
• Risks without owners, or every risk owned by the same person.
• Inherent and residual scores identical across the register - a sign you did not actually evaluate the effect of controls.
• Stale review dates - if every risk was last reviewed 14 months ago, your ISMS is not operating.
• No link from risks to Annex A controls, which breaks the Statement of Applicability.

Next Steps

The fastest way to operationalize this is to start with a structured template, then move to a tool once your register exceeds 30-40 risks. Try the free ISO 27001 risk register template, or jump straight into the Risk Assessment tool to build an audit-ready register with the methodology above already baked in.