ISO 27001 Risk Assessment: The One Decision That Determines Everything Else

Most ISO 27001 content treats risk assessment as a compliance checkbox – “do a risk assessment, feed it into the SoA, move on.” That undersells it badly. The risk assessment methodology you choose at the start of an ISO 27001 programme isn’t a formality; it’s the single decision that shapes your Annex A control selection, your audit defensibility, and how much ongoing work the ISMS actually takes to maintain for the next three years. Get it wrong and you’re stuck with either a bloated control set that’s expensive to operate, or a thin one that collapses the moment a Stage 2 auditor asks “why.”

Click the video below for a step-by-step Privacy Risk Assessment walkthrough:

This is the part of ISO 27001 that separates organisations that pass Stage 2 comfortably from organisations that pass it nervously, with findings, after a stressful remediation sprint. Everything below is the reasoning most guides skip.

1. Asset-based vs. scenario-based – and why the choice isn’t neutral

ISO 27001 doesn’t mandate a specific risk assessment methodology. ISO 27005 gives guidance, not a script, and Clause 6.1.2 only requires that the methodology be documented, repeatable, and produce comparable, consistent results across assessments. That gap is deliberate – the standard is method-agnostic on purpose – but it means the organisation has to make a real design decision, and most don’t realise how consequential it is until they’re two years in and stuck maintaining something unworkable.

Asset-based risk assessment starts by inventorying information assets – databases, servers, applications, physical records, even people in certain frameworks – then assesses confidentiality/integrity/availability risk to each one individually. It’s thorough, mechanical, and auditor-familiar; it’s the version most ISO 27001 templates online default to, because it’s easy to teach and easy to check off. But it scales badly. A mid-sized SaaS company can easily generate 200+ discrete assets, and if every asset gets its own risk entries across C/I/A, the register turns into a 500-to-800-row spreadsheet within the first year. Nobody updates a register that size quarterly with the rigor it needs – someone updates 40 rows, defers the rest, and the register quietly goes stale. Stale risk registers are exactly what Stage 2 auditors are trained to find: ask an employee to explain a risk entry from eight months ago and watch the story fall apart in real time, in front of the auditor, which is a far worse outcome than the finding itself.

Scenario-based (or event-based) risk assessment starts instead from plausible threat scenarios – “an employee’s credentials are phished and used to access production,” “a former contractor’s access isn’t revoked within the offboarding window,” “a misconfigured S3 bucket exposes customer data” – then maps which assets, processes, and controls are implicated by each scenario. It produces a smaller, more legible risk register – often 30-60 scenarios instead of hundreds of asset-level entries – and it maps more naturally onto how incidents actually happen in the real world, since breaches are event chains involving multiple assets and failure points, not isolated single-asset failures. The tradeoff is that it demands more judgment to build well up front; a lazy or narrow scenario list can leave real gaps that a mechanical asset inventory would have caught by brute force.

There’s also a hybrid approach worth naming explicitly, because most mature ISMS programmes end up here eventually: asset classification (crown-jewel systems get named and tracked individually; low-sensitivity assets get grouped into categories) combined with scenario-based risk scoring layered on top of the classified assets. This gets you the completeness of an asset inventory without the maintenance burden of scoring every asset independently, because scenarios do the heavy lifting on likelihood and impact while the asset classification just tells you where the scenario’s blast radius lands.

The part almost nobody says out loud: the methodology you pick determines the shape of your Statement of Applicability before you’ve selected a single Annex A control. Asset-based assessments tend to justify broad control adoption almost by default – “we have databases, so encryption-at-rest controls apply everywhere,” “we have laptops, so full-disk encryption applies to every device class” – which quietly inflates scope, cost, and the number of controls you now have to operate and evidence forever. Scenario-based assessments tend to produce sharper, more defensible justifications – “this control mitigates scenario 14, phished credentials leading to unauthorised production access, which we rated high-likelihood/high-impact based on our SSO logs and past incident data” – which is exactly the kind of reasoning an auditor wants to see written into the SoA, and exactly the kind of reasoning that lets you legitimately exclude controls without it reading as corner-cutting. A well-argued exclusion, grounded in a specific scenario analysis, is stronger evidence of ISMS maturity than including every control “to be safe.”

2. Likelihood × impact scoring is where most programmes quietly lie to themselves

Almost every organisation uses a 3×3 or 5×5 likelihood/impact matrix, because it’s the standard visual everyone’s seen in a template. Almost none of them interrogate what the numbers inside the matrix actually mean. If “likelihood: 3” has no defined criteria attached to it — no frequency band, no historical incident basis, no threat-intelligence input — it isn’t a risk score. It’s a guess dressed up as data, and it collapses the instant anyone asks a follow-up question.

Auditors are increasingly trained to probe exactly this. Ask someone in a Stage 2 interview to justify why a specific risk is scored 3 and not 4, and if the honest answer is “it felt about right at the time,” that’s a finding waiting to happen  even if it doesn’t get formally written up this cycle, it tells the auditor the whole register might be soft, and soft scoring invites deeper sampling everywhere else.

The fix isn’t complexity for its own sake. It’s defining scoring criteria once, in writing, before scoring anything, and then holding every risk entry to that same yardstick:

• Likelihood tied to something external and checkable where possible — observed frequency in your own environment (how many phishing attempts hit your inbox filters per quarter), documented threat intelligence for your sector, or, absent hard data, a clearly defined qualitative band (“Rare: no known occurrence in the industry in the past 3 years” vs. “Likely: occurs somewhere in our sector multiple times a year”).
• Impact tied to concrete business consequences instead of adjectives — data volume exposed, estimated downtime cost per hour, regulatory exposure (is this a reportable breach under GDPR/HIPAA/DPDP, and what does that trigger), contractual penalty exposure, reputational blast radius measured by customer count or revenue concentration in the affected system.

This is genuinely tedious to set up properly, and it’s genuinely the single biggest differentiator between a risk register that survives cross-examination in Stage 2 and one that quietly falls apart. It’s also worth building the impact criteria to explicitly cover cascading effects — a scenario that looks “medium impact” in isolation (a single service going down) can be “high impact” once you account for downstream dependencies (that service being the auth layer for six other systems). Scoring each risk in isolation without accounting for blast radius is one of the most common ways organisations under-rate the risks that actually matter.

3. Risk treatment isn’t a binary – and “accept” is the option everyone abuses

ISO 27001 gives four treatment options per risk: mitigate (implement a control), transfer (insurance, contractual risk-shifting to a vendor), avoid (stop doing the risky activity entirely), and accept (formally acknowledge and live with it). Most organisations use exactly one of these  mitigate  for almost everything, which produces the bloated, expensive-to-run control set problem again, and one of these  accept  as a dumping ground for anything inconvenient to fix.

That second pattern is the more dangerous one, and it’s worth naming directly: a risk acceptance process with no real threshold means the entire risk treatment plan downstream is theater. If “accepted risk” just means “the team decided not to deal with this,” every risk that’s expensive, embarrassing, or politically awkward to fix quietly gets waved through under that label, and the register stops reflecting actual risk posture. Clause 6.1.2 requires defined risk acceptance criteria specifically to prevent this – a threshold above which a risk must be treated, and only below which it can be knowingly accepted. Most first-time ISMS programmes either skip defining this explicitly, or set it so permissively that half the register clears the bar without real deliberation.

A defensible acceptance threshold usually needs to be anchored to something outside the ISMS team itself, so acceptance decisions aren’t self-graded by the same people whose job is to look compliant: board-level risk appetite statements, insurance policy limits and exclusions, regulatory exposure caps, or contractual liability ceilings with customers. When an auditor asks “who approved accepting this risk, and against what stated threshold,” the answer needs to point outward, not just to a checkbox the risk owner ticked themselves.

Transfer and avoid get used even less than they should, mostly because they require decisions above the security team’s pay grade  cancelling a risky product feature, or buying a specific insurance rider  and it’s organisationally easier to default to “mitigate with a control” even when transfer or avoidance would genuinely be cheaper and more effective. A mature risk treatment plan should show visible use of all four options, not just mitigate-everything with a side of accept-the-rest.

4. Residual risk is where most registers go quiet – and where auditors dig hardest

Every risk treatment should produce a residual risk score: what’s left over after the control is applied, because almost no control reduces risk to zero. This is the step organisations most often skip or fake  scoring the treated risk as “low” without re-running the same likelihood/impact logic used for the original score, just because a control now exists on paper.

The honest version requires asking, control by control: does this control actually reduce likelihood (making the scenario less probable), impact (making the scenario less damaging if it happens), or both  and by how much, realistically, given how the control is actually implemented, not how it’s described in the policy document. A control that exists in policy but isn’t consistently followed in practice doesn’t reduce residual risk at all, and Stage 2 fieldwork is specifically designed to catch that gap between documented control and operating control. This is also exactly where asset-based and scenario-based methodologies diverge again in practice: scenario-based registers tend to make residual risk reasoning more natural, because you’re re-asking “does this scenario still play out, and how badly, given the control”  a question with an intuitive answer  rather than re-scoring an abstract asset-level risk that was never tied to a concrete failure mode in the first place.

5. The review cycle is a control in itself, and it’s usually the weakest link

A risk assessment done once at ISMS launch and never meaningfully revisited is arguably worse than not having a formal one  it gives false confidence that risk is being managed while the register drifts further from reality every month. Clause 6.1.2 and the ongoing operation clauses require risk assessments to be reviewed at planned intervals and when significant changes occur (new systems, new vendors, a security incident, a major org change like an acquisition or a new product line touching customer data).

The organisations that handle this well tend to separate the review cadence into two tracks rather than one annual fire drill: a scheduled full review (commonly annual, sometimes semi-annual for higher-risk environments) covering the entire register end to end, and an event-triggered review that fires automatically off specific triggers  a new vendor onboarding, a new production system going live, an incident closing out  so the register updates continuously instead of accumulating a backlog of unreflected changes that all land at once, right before the next audit, done under time pressure and with obviously lower rigor.

Why this matters more than the control count

The instinct in a first ISO 27001 programme is to over-index on Annex A  which of the 93 controls to implement  because that’s the visible, checklist-shaped part of the standard, the part that feels like “doing the work.” But Annex A controls are downstream outputs of the risk assessment, not independent decisions made on their own merits. A rigorous risk assessment producing a small, well-justified control set will out-perform a sprawling control set built on a hand-waved risk register every single time in Stage 2, because the audit is testing whether the logic chain holds  risk identified, scored against defined criteria, treated with a justified option, residual risk assessed honestly, reviewed on a real cadence  not how many boxes got ticked in Annex A.

How GCAI helps: GCAI builds the risk assessment methodology first  asset-based, scenario-based, or hybrid, matched to your actual operating complexity  with defined scoring criteria, acceptance thresholds, and a real review cadence baked in from day one. The Statement of Applicability that follows is something you can defend line by line in Stage 2, not just something that looks complete on paper.