Ask any lead auditor what separates an ISMS that passes from one that doesn’t, and the answer will almost always come back to the same place: the risk assessment. Not the policies, not the number of controls implemented, not the size of the security team. The risk assessment.

And yet it is the document that most organisations either rush, template-copy, or delegate to someone who does not fully understand what it is supposed to achieve. This post is a direct, practical guide to what an ISO 27001 risk assessment actually requires — and how to avoid the mistakes that derail certifications every year.

What the Standard Actually Requires

ISO 27001:2022, Clause 6.1.2, requires organisations to define and apply a risk assessment process that:

The standard does not prescribe a specific methodology. You can use asset-based risk assessment, scenario-based assessment, or any combination — as long as your approach is documented, consistent, and produces results that can be used to make risk treatment decisions.

That flexibility is a trap for organisations that mistake it for permissiveness. “We can use any methodology” does not mean “we can do whatever we want and call it a risk assessment.” An auditor will test your methodology for logical consistency and evidence of application. If your risk assessment cannot withstand that scrutiny, neither will your certification.

The Four Steps That Must Be Traceable

A well-constructed ISO 27001 risk assessment has a clear, traceable sequence. Each step feeds the next, and each step generates evidence.

Step 1: Identify the risks. Start with your information assets — data, systems, people, processes, physical infrastructure. For each asset, identify what could go wrong (threats), what weaknesses could be exploited (vulnerabilities), and what the potential impact would be on confidentiality, integrity, or availability. This is the most time-consuming step, and the most valuable.

Step 2: Analyse the risks. Assign likelihood and impact ratings to each risk. Your rating scale (1–3, 1–5, qualitative labels) is less important than applying it consistently. A risk rated “High” in one part of the register should reflect the same thinking as a risk rated “High” elsewhere. Auditors specifically look for internal consistency here.

Step 3: Evaluate the risks. Compare each assessed risk against your pre-defined risk acceptance criteria. Risks that exceed your threshold require treatment. Risks below the threshold may be accepted — but that acceptance must be documented and signed off by an appropriate authority, not just implied.

Step 4: Produce the risk treatment plan. For each risk requiring treatment, document the selected treatment option (mitigate, transfer, avoid, accept), the relevant Annex A controls that address it, and the responsible owner. This is the bridge between your risk assessment and your Statement of Applicability.

The Statement of Applicability Connection

This is where many organisations make a critical error. The Statement of Applicability (SoA) — the document that lists every Annex A control and explains whether it applies and why — must be derived from your risk assessment. Not from a template. Not from what sounds sensible. From your actual documented risks and treatment decisions.

If your SoA includes a control that does not correspond to any identified risk or other justification in your risk assessment, an auditor will flag it. If your risk assessment identifies a risk that your SoA does not address with any control, an auditor will flag that too. The two documents must tell a coherent story.

Common Mistakes That Stall Certifications

“We used a template from the internet.” Templates are useful starting points for format. They are not a substitute for thinking about your actual assets and threats. A generic template risk assessment will not survive audit scrutiny because it will not map to your actual systems and processes.

Overly broad asset categories. “All company data” is not an information asset in the sense ISO 27001 intends. Break assets down to meaningful categories — customer data, financial records, source code, HR records — so that risks can be meaningfully assigned to them.

No owner assigned to risks. Risk ownership is a requirement, not an optional field. Each risk in your register should have a named individual (or role) responsible for the treatment decision. “IT Department” is not a risk owner. A specific role is.

Risk assessment done once and never updated. ISO 27001 requires you to conduct risk assessments at planned intervals and when significant changes occur. A risk assessment completed eighteen months ago that has never been reviewed is a non-conformity waiting to be found. Schedule it. Document the review. Update it.

How Detailed Does It Need to Be?

Proportionate to your context. A ten-person professional services firm and a 500-person financial institution will have risk assessments that look very different in scope and depth. Both can be ISO 27001 compliant. The test is not volume — it is thoroughness relative to your identified risks and organisational complexity.

If your organisation processes sensitive personal data, operates critical infrastructure, or provides services to regulated industries, expect auditors to probe more deeply. If you are a small business with a limited digital footprint, a focused, well-evidenced risk assessment will serve you better than an exhaustive one with gaps in the evidence.

At Bitsecura, we build risk assessments that are designed to be defended — not just completed. Our certified Lead Implementers work through your actual asset landscape with you, not from a generic template. The result is a risk register that holds up under audit and actually drives your security decisions.

If you want an honest conversation about your current risk assessment — or where to start building one — reach out to us here. No strings attached.

Bitsecura provides ISO 27001 implementation, internal audit, and ISMS maintenance services. Learn more about our ISO 27001 services.