ISO 27001 is built on a simple premise: you cannot protect information you do not understand, and you cannot manage a risk you have never identified. Clauses 6 and 8 are the engine that turns that premise into a working information security management system (ISMS). One clause sets the rules. The other runs them.

They are inseparable in practice but distinct in purpose, and confusing the two is one of the most common findings we see at audit.

Think of it this way: Clause 6 is the recipe. Clause 8 is cooking the meal. If you map them onto the Plan-Do-Check-Act (PDCA) cycle that underpins every ISO management standard, Clause 6 is the Plan and Clause 8 is the Do.

Clause 6 tells the auditor how you will manage risk. Clause 8 gives them proof that you did.

That proof only holds up if the rules came first, which is the whole point of Clause 6. Before running a single risk assessment, it requires you to define the rules you will use. This is your risk assessment methodology, and it must be documented before any assessment takes place.

It needs to cover:

• How you identify risks — asset-based, scenario-based, or process-based, and what counts as a risk to confidentiality, integrity, or availability.
• How you identify risk owners — every risk must have a named individual accountable for it.
• How you score risks — your likelihood and impact criteria, and how the two combine into a risk score. A 3×3 or a 5×5 matrix are both acceptable; the standard does not mandate a method.
• Your risk acceptance threshold — the score above which a risk requires treatment. Risks below it can be formally accepted.
• How you will treat risks — the four options available, covered below.

Starting a risk assessment without a documented methodology is one of the most common audit failures we encounter. Define the rules first, and your results can be defended later.

With the rules in place, the work itself does not start with threats. It starts with understanding what you have and what matters most to your organisation.

This article focuses on the asset-based approach, the most common starting point and the most natural fit for ISO 27001. The process begins by inventorying your assets. Once you have that inventory, the next step is a protection needs analysis: for each asset, ask how serious a breach of its Confidentiality, Integrity, or Availability (CIA) would be. The assets with the highest CIA scores are where your effort should begin.

In practice, this means following the data. If customer data is your most critical asset, the next question is where it is processed. That answer leads you straight to the supporting systems carrying the highest risk: your CRM, your cloud environment, your ERP. Those become the focus of your analysis.

So you know which assets matter most. The next question is what could actually go wrong with them, and a risk is rarely a single thing. It is the product of three: an asset worth protecting, a vulnerability that exposes it, and a threat that could exploit that vulnerability. Hold any one of them in isolation and you have nothing to assess. A laptop is not a risk. An unencrypted laptop is not a risk either, until you add the threat of it being lost or stolen. Put the three together and the risk becomes real, and describable.

That structure is also how you should write a risk down. Express each one as Cause → Event → Impact: the vulnerability and the threat together are the cause, the security event is what happens, and the impact is what it costs you. Unencrypted laptops (cause) are lost in transit (event), exposing customer data and triggering a notifiable breach (impact). Written this way, a risk is specific enough to score and specific enough to treat, which is exactly what the next two steps demand.

Risk assessment must produce results that are reproducible and comparable, whether the assessment is carried out by you, a colleague, or someone conducting the next annual review. That is exactly why Clause 6 requires your scoring criteria to be defined before any assessment takes place.

Both likelihood and impact are scored on your chosen scale and multiplied to give a risk score: on a 5×5 matrix, any value from 1 to 25. What matters is that each point on the scale has a defined meaning for your organisation. For impact, define it across the dimensions relevant to your context. For likelihood, something that occurs once every ten years might be a 1, while something that happens monthly or more often is a 5.

Multiply likelihood by impact, and you have the current risk level.

For likelihood, once every ten years might be a 1; something that occurs monthly or more frequently a 5.

Multiply likelihood by impact to get the current risk level. This score drives every treatment and acceptance decision that follows.

A score captures a risk at one moment, but a risk is not static. A good methodology tracks it through four states rather than treating it as one fixed number: inherent, current, residual, and target.

Inherent risk is the exposure before any control exists, the raw risk if you did nothing at all. Current risk is where you stand today, with whatever controls you already have in place. Residual risk is what remains once your planned treatment has been applied, the exposure you have consciously chosen to live with. Target risk is the level you are aiming for, the goal your treatment plan is built to reach.

Read in order — inherent → current → residual → target — these tell the story of a risk over time. They show an auditor not only where you are, but where you started, where you are heading, and how much you are knowingly accepting along the way.

Knowing a risk's level is only half the picture; you still need something to judge it against. Your acceptance threshold is the score above which a risk requires a treatment decision. Anything at or below it can be formally accepted.

The right threshold depends on your organisation's risk appetite. A startup that handles no sensitive data might set its threshold at 10, a moderate appetite that leaves room for operational flexibility. A highly regulated organisation might set it as low as 4, a conservative appetite that reflects the consequences of a breach.

This threshold must be defined in your Clause 6 methodology. You cannot set it after you have seen your scores, because that would let the results decide what counts as acceptable, which is exactly backwards.

Once a risk sits above that threshold, it needs a decision, and ISO 27001 gives you four to choose from. The labels matter, so we use them consistently: Mitigate, Transfer, Avoid, and Accept.

Mitigate lowers the risk by adding or strengthening controls — encrypting the laptop, enforcing MFA, tightening access. It is the option you will reach for most often. Transfer moves the risk to a third party, usually through insurance or a contractual clause, though accountability for the asset stays with you. Avoid removes the risk entirely by stopping the activity that creates it; if a legacy system cannot be secured, you retire it. Accept is the deliberate choice to live with a risk, recorded by a named owner, and only ever applied where the score justifies it.

Treatment decisions feed directly into the last step. The Statement of Applicability is not a standalone exercise; it is a direct output of your risk process. Once you have identified your risks and selected your controls, you compare those controls against the measures in ISO 27001 Annex A, marking which ones apply, explaining why, and justifying any exclusions. Existing measures, such as MFA already in place or a physical security system, are checked against the Annex and noted accordingly.

The SoA belongs at the close of the Clause 6 process. The core of that process is three phases: identification, assessment, and treatment. Get those right and the SoA follows naturally.

Start with your asset inventory. Use the CIA scoring from your protection need analysis to decide where to focus first. For each asset, identify the vulnerabilities and threats that together create a risk. Write every risk as Cause → Event → Impact.

Score likelihood and impact on your predefined scale and multiply them to get the current risk level. Distinguish between inherent, current, and target risk. Define residual risk as the gap between where you are now and where your treatment plan will take you.

Treat everything above your threshold — avoid, reduce, or transfer. Formally accept what falls below it, with a named owner on record.

The Statement of Applicability closes the loop, mapping your chosen controls against Annex A. Then Clause 8 takes over: running the assessments, applying the treatments, and keeping the evidence that proves your ISMS works in practice.