If you need to carry out a security risk assessment, agree the scope and decision criteria before listing threats or assigning ratings. A consistent sequence helps you connect evidence, controls and treatment decisions instead of producing disconnected findings.
The nine steps below are a practical way to organise a security risk assessment. They are not nine mandatory ISO steps: the ISO 31000 process is iterative, and consultation, recording and review continue throughout. Revisit earlier assumptions when new evidence changes the assessment.
Why order matters
Each step in a security risk assessment depends on the one before it. You can't meaningfully rate likelihood before you've identified the specific threat-vulnerability pairing you're rating. You can't identify a vulnerability sensibly before you know which assets and threats you're looking at it in relation to. Jump ahead — starting with a risk matrix, or a list of "top risks" carried over from last year — and you inherit whatever assumptions sat underneath that shortcut, usually without anyone noticing they were assumptions at all.
Running the steps in order also makes the assessment repeatable. A new assessor picking up the same facility next year, or a different assessor covering a sister site, should be able to follow the same sequence and land on comparable results. That's the actual test of whether a methodology is working — not whether any single assessment looks thorough, but whether independent people using it converge on similar answers.
The security risk assessment steps, in order
Step 1: Define scope and context
Before you assess anything, decide what you're assessing. A single facility, a program, a project, an enterprise-wide function. Define the boundary explicitly — what's in, what's out, what's covered by a separate assessment already. Establish the internal and external context that matters: regulatory obligations, organisational risk appetite, existing controls, related assessments already done. Skip this step and every later step inherits an ambiguous scope nobody agreed to.
Step 2: Identify assets and stakeholders
List what you're protecting and who has a stake in it. Assets aren't just physical — they include information, systems, people, reputation and continuity of operations. Stakeholders include asset owners, operational staff, and whoever will eventually approve the treatment plan. This step is often rushed because it feels like admin. It isn't — an asset missed here is a risk that never gets identified at all, no matter how carefully the later steps are done.
Step 3: Identify threats
A threat is a source of harm — a person, event or condition capable of causing loss. This includes malicious actors, natural hazards, human error, and system or process failure. Threat identification should draw on more than the assessor's memory: incident history, threat intelligence relevant to the sector, and input from people who actually work at the site being assessed, who often know about near-misses that never made it into any formal record.
Step 4: Identify vulnerabilities
A vulnerability is the gap or weakness a threat could exploit — a door that doesn't self-lock, a supplier with no cyber baseline, a process with no second check. Threats without a corresponding vulnerability don't produce risk. This step is where site walks, document reviews and control testing earn their place, because a control that's documented in a policy and a control that actually works in practice are frequently not the same thing.
Step 5: Analyse likelihood
For each threat-vulnerability pairing, estimate how likely it is to be realised within a defined period, using a documented likelihood scale rather than a gut call the assessor can't explain to anyone else. Likelihood should draw on incident history where it exists and structured judgement where it doesn't — and be explicit about which one you're using, because a rating based on judgement should carry a different level of confidence than one based on five years of incident data.
Step 6: Analyse consequence
Estimate the impact if the risk materialises, across the categories that matter to the organisation — safety, financial, operational, reputational, regulatory. Use a consequence scale with real definitions attached to each level, not just "low, medium, high" with nothing behind the words. Two assessors using the same scale should land on similar ratings for the same scenario; if they don't, the scale needs more specific wording, not a more experienced assessor.
Step 7: Evaluate and prioritise
Combine likelihood and consequence into a risk rating, then compare that rating against the organisation's risk criteria — what's acceptable, what needs treatment, what needs escalation. This is where a risk matrix earns its keep, but only if the criteria behind it were agreed before the assessment started, not chosen afterward to make the results look more palatable to whoever has to sign off on them.
Step 8: Determine treatment
For every risk above the acceptance threshold, identify treatment options: avoid, reduce, transfer or accept, with a clear owner and a realistic timeframe for each. A treatment plan with no owner and no date is a wish list, not a plan. This step should also record residual risk — what's left after treatment, and whether that residual level is genuinely acceptable to whoever is signing off, rather than simply assumed to be fine because a treatment was actioned.
Step 9: Report, communicate and schedule review
Document the findings in a form the intended audience can actually use — a one-page summary for the board is not the same document as the detailed register the security manager works from day to day. Set a review date. Risk profiles change: new threats emerge, controls degrade, the business changes what it's doing. An assessment with no review date is a snapshot that quietly becomes wrong, and nobody notices until something goes through a control that supposedly covered it.
Worked example: a regional water utility
A fictional regional water utility runs a security risk assessment on its main treatment plant, working through the nine steps in sequence rather than starting from the site's existing risk register.
| Step | Output for this assessment |
|---|---|
| 1. Scope | Physical and cyber perimeter of the treatment plant, excluding the separate SCADA network review already underway |
| 2. Assets | Treatment infrastructure, chemical storage, control room, on-site records, plant staff |
| 3. Threats | Unauthorised site access, insider misuse, chemical theft, vandalism |
| 4. Vulnerabilities | Perimeter fence gap identified on site walk, visitor sign-in not consistently enforced |
| 5. Likelihood | Rated using a five-point scale against two years of incident and near-miss data |
| 6. Consequence | Public health consequence category rated highest of the four categories used |
| 7. Evaluation | Two risks rated above the utility's acceptance threshold; escalated to the executive risk committee |
| 8. Treatment | Fence repair (owner: facilities manager, 30 days); visitor sign-in enforcement (owner: site supervisor, immediate) |
| 9. Reporting | One-page summary to the board; full register held by the security manager; review scheduled at 12 months |
Nine steps, one sequence, and a clear line from "fence gap" to "who fixes it and by when." Notice that the fence gap only surfaced because step 4 included an actual site walk rather than a desk review of the existing procedures — the perimeter policy on file described a fence that, in practice, no longer matched what was standing.
Common mistakes
- Starting with the risk matrix. Rating risks before threats and vulnerabilities are properly identified means the matrix is doing work the earlier steps should have done, and the ratings end up reflecting gut feel dressed up as analysis.
- Skipping context and scope. Two assessors, two different assumptions about what's in scope, two assessments that can't be compared or rolled up into a single portfolio view.
- No documented likelihood or consequence scale. Ratings become whatever the assessor feels on the day, and can't be defended later to an auditor or a board asking why a risk was rated the way it was.
- Treatment with no owner or date. The risk register lists a treatment; nobody is actually accountable for delivering it, and it's still open at the next review with no explanation.
- No review date set. The assessment is treated as finished rather than as a snapshot that needs revisiting once the site, the threat picture or the controls change.
Run the process properly
Once the risks are identified, they need somewhere consistent to live — see Security Risk Register Template (Free Word Download) for a register built around the same nine-step logic, so the fields in the register match the steps you actually ran. Threat identification in step 3 increasingly needs to cover social engineering specifically — Spearphishing vs Phishing: What Staff Need to Be Able to Tell Apart is a useful companion for that part of the exercise. And once treatments are decided in step 8, How to Write a Security Plan (Free Outline Template) covers turning them into a plan people can actually follow rather than a list that sits in the register untouched.
The Security Risk Assessment Process Flow Template gives you a customisable flowchart of this nine-step process aligned to SRMBOK and ISO 31000, with an editable legend and accountability guidance for strategic, program, project and operational levels. Download the free process flow template and adapt it to how your organisation actually assigns accountability, rather than forcing your structure to fit a generic template.