---
title: "Cyber security risk assessment: a practical method for UK firms"
canonical: https://www.grcmana.io/vault/risk-management/risk-assessment
published: 2023-10-27
updated: 2026-10-23
author: "Harry West"
framework: "Risk Management"
control: "Guide Cyber security risk assessment: a practical method for UK firms"
journeyStage: intermediate
---

# Cyber security risk assessment: a practical method for UK firms

## Key takeaways

A cyber security risk assessment identifies what could harm a firm's information and systems, judges how likely and damaging each risk is against criteria set in advance, and decides which risks need treatment. Run it at planned intervals and after significant change, choose asset-based or scenario-based identification, and give every risk a named owner.

- **Risk criteria** — ISO/IEC 27001:2022 Clause 6.1.2 expects risk criteria and risk acceptance criteria to be set in advance, so that each repeat assessment gives results that can be trusted and compared.
- **When to reassess** — The NCSC advises revisiting cyber security risk assessments at regular intervals and immediately when something significant changes; ISO 27001 Clause 8.2 sets the same two triggers.
- **Component-driven vs system-driven** — The NCSC describes component-driven assessment as useful for exposure to known technical vulnerabilities and system-driven assessment for large, complex systems; the two can be used alongside each other.
- **UK adoption** — In the UK Cyber Security Breaches Survey 2025, 57% of medium businesses (50 to 249 employees) had carried out a cyber security risk assessment, so many had not.

An enterprise prospect's security questionnaire asks for your latest cyber security risk assessment. What you have is a spreadsheet someone filled in before last year's ISO 27001 audit, and nobody is sure the scores still mean anything. The deal now waits on a document the team doesn't trust.

A cyber security risk assessment done properly removes that wait, because one output can serve both the auditor and the buyer. This guide is for founders, CTOs and security leads at UK B2B tech firms with 25 to 100 staff. You may be running a first assessment for ISO 27001, SOC 2 or a customer. It sets out one method: decide when to run it, set the criteria first, choose how you will find risks, then identify, analyse, evaluate and hand the results to treatment.

## What is a cyber security risk assessment?

A cyber security risk assessment identifies what could harm your firm's information and systems, judges how likely and how damaging each risk is against criteria you set in advance, and decides which risks need treatment. An auditor and a customer both test the criteria and whether the method repeats. Neither is testing the template you used.

The NCSC's guide to [the fundamentals of cyber risk](https://www.ncsc.gov.uk/collection/risk-management/the-fundamentals-and-basics-of-cyber-risk) describes cyber risk as "the possibility of something bad happening". It also says there is no "one size fits all" approach to risk assessment. Most approaches still cover similar ground: the threats, weaknesses and likelihood behind a risk, and its impact on the business. For the wider discipline of risk management, see our page on [ISO 31000](https://www.grcmana.io/vault/iso-31000).

This page covers risk to your information and systems. Risk that the firm breaches a legal or regulatory obligation is a separate exercise, with different inputs and owners, and it is not covered here.

## When should you run a cyber security risk assessment?

Run a cyber security risk assessment when you first set up your security programme, then on a fixed schedule, and again whenever something significant changes. Triggers include a new product, a cloud migration, a major new supplier, an acquisition or a serious incident. Write the list of change triggers before you need it, so nobody debates whether a change counts.

ISO 27001 sets the rhythm for firms that follow it. Clause 8.2 expects the assessment to run at planned intervals and whenever significant changes are planned or happen, using the criteria set under Clause 6.1.2. Our page on [ISO 27001 Clause 8.2](https://www.grcmana.io/vault/iso-27001/clause-8-2-information-security-risk-assessment) covers that requirement in detail. The NCSC's [basic risk assessment and management method](https://www.ncsc.gov.uk/collection/risk-management/a-basic-risk-assessment-and-management-method) gives the same advice to every organisation: revisit assessments at regular intervals, and immediately when something significant changes.

We recommend a full pass at least once a year, with lighter reviews in between. That frequency is our suggestion, not a requirement of either source.

Many firms of this size have not started. The UK government's [Cyber Security Breaches Survey 2025](https://www.gov.uk/government/statistics/cyber-security-breaches-survey-2025/cyber-security-breaches-survey-2025) found that 48% of small businesses (10 to 49 employees) had carried out a cyber security risk assessment. The figure was 57% for medium businesses (50 to 249 employees) and 70% for large ones.

A risk assessment dated before your last big change describes a company that no longer exists.

## How do you run a cyber security risk assessment, step by step?

Run a cyber security risk assessment in six steps: set the scope and context, set the risk criteria and acceptance criteria, identify the risks, analyse their likelihood and consequence, evaluate them against the criteria, and hand the results to treatment. Setting the criteria before identifying anything is the step most first attempts skip, and the one auditors check first.

### Step 1: Set the scope and context

Write down what the assessment covers: the services you sell, the systems and data behind them, the people and locations involved, and the suppliers you rely on. For ISO 27001 this is the scope of your information security management system. For SOC 2 it is the system boundary covered in our [SOC 2 readiness assessment guide](https://www.grcmana.io/vault/soc-2/readiness-assessment). Include HR, finance and office access as well as production systems.

### Step 2: Set the risk criteria and acceptance criteria

Before anyone scores a risk, agree how risks will be scored and what level the business will accept. ISO/IEC 27001:2022 Clause 6.1.2 expects you to set both: criteria for how assessments are run, and criteria for which risks are acceptable. The aim is that each repeat assessment gives results you can trust and compare with the last one. Decide the likelihood and consequence scales, how they combine, the acceptance line, and who may accept a risk above it.

We recommend having the leadership team approve the criteria before the first workshop. Our page on [ISO 27001 Clause 6.1](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) explains how the criteria connect to treatment and the Statement of Applicability.

Criteria set after the scores are in are not criteria. They are a justification.

### Step 3: Identify the risks

List what could go wrong, to what, and through which weakness. Choose an asset-based or a scenario-based approach, as set out in the next section, and record a named owner for every risk as you go. The NCSC's basic method notes that vulnerabilities can exist in people, processes, places and technology, so draw on more than the technical estate.

### Step 4: Analyse likelihood and consequence

For each risk, estimate how likely it is and how much damage it would do, using the scales from Step 2. Ground each estimate in evidence: incident history, audit findings, scan results and supplier reports. Decide in Step 2 whether you score before or after existing controls, then apply that choice the same way every time.

### Step 5: Evaluate the risks

Compare each risk's level with the acceptance criteria and rank the results. Risks below the line are accepted and recorded; risks above it need a treatment decision. Evaluation is where leadership attention goes, so keep the ranking short and readable.

### Step 6: Hand the results to treatment

Pass every risk above the acceptance line to the treatment process, with its owner and its analysis attached. Under ISO 27001, the results feed the risk treatment plan and the Statement of Applicability, and the results must be kept as documented information. Treatment options themselves are a separate decision with their own guidance.

## Should you use an asset-based or a scenario-based risk assessment?

Use an asset-based assessment when you need complete coverage, such as a first ISO 27001 assessment built from an asset inventory. Use a scenario-based assessment when you want to reason about how real incidents unfold across systems and suppliers. The two work best together: NIST SP 800-30 calls them asset/impact-oriented and threat-oriented analysis, and suggests using both.

An asset-based assessment starts from what you hold: customer data, source code, production infrastructure, laptops, key suppliers. For each asset you ask what could affect its confidentiality, integrity or availability. A scenario-based assessment starts from events: a compromised admin account, ransomware on the build pipeline, a cloud provider outage. For each scenario you trace what it would touch and what it would cost. Our page on [ISO/IEC 27005](https://www.grcmana.io/vault/iso-27005) covers the standard itself.

|  | Asset-based | Scenario-based |
| --- | --- | --- |
| Starting point | An inventory of information assets and their owners | A list of plausible events or incidents |
| Strong at | Complete coverage; easy to show an auditor nothing was missed | Realistic chains of cause and effect across systems |
| Weak at | Can produce a long list of similar, low-value risks | Can miss assets nobody thought to build a scenario around |
| Fits a 25 to 250-person firm when | You are building the first register or the ISMS scope is new | The register exists and you want depth on the top risks |
| Owner input needed | Asset owners confirm value and exposure | Engineers and business owners walk through how the event unfolds |

The NIST guide to conducting risk assessments, [SP 800-30 Rev. 1](https://csrc.nist.gov/pubs/sp/800/30/r1/final), explains why. It warns that the starting point of an assessment "can potentially bias the results, causing some risks not to be identified", and that analysing from a second orientation can improve rigour. We recommend starting asset-based for the first register, then running scenarios for the handful of risks that matter most.

## How deep should a cyber security risk assessment go?

Match the depth to the system. The NCSC separates two approaches. Component-driven assessment analyses the risks to individual technical components. System-driven assessment starts from the goals of the whole system and looks for failures that emerge from how its parts interact. Neither is better; the NCSC says they can be used alongside each other.

The NCSC's [introduction to system-driven and component-driven risk management](https://www.ncsc.gov.uk/collection/risk-management/introducing-system-and-component-driven-risk-management-approaches) says component-driven approaches are useful for exploring exposure to known technical vulnerabilities, and suit less complex systems with well-understood connections. System-driven approaches suit large and complex systems.

For a B2B tech firm of 25 to 100 people, we suggest a component-driven pass over the well-understood estate (endpoints, identity, office network, standard SaaS tools). Then take a system-driven look at the product platform, where customer data flows through many services and suppliers. That split is our guidance, not the NCSC's.

## Who should take part in a cyber security risk assessment, and who owns each risk?

A security lead runs the assessment. The people who run each part of the business supply most of the knowledge: engineering, product, people and HR, finance and customer operations. Every risk needs a named owner senior enough to fund its treatment or accept it. ISO 27001 Clause 6.1.2 requires risk owners to be identified.

The NCSC's basic method asks you to record owners for assets because they are "responsible and accountable for what happens to their assets". The same logic applies to risks. An owner who cannot spend money or change a process can describe a risk but cannot decide anything about it.

Keep the roles clear:

- **Facilitator.** Usually the security lead or an outside adviser. Runs the method, challenges scores and keeps the record.
- **Contributors.** Team leads who know where data sits, how systems connect and what has gone wrong before.
- **Risk owners.** Senior people who accept, fund or escalate each risk.
- **Leadership.** Approves the criteria and the acceptance line, and reviews the ranked results.

## What should a cyber security risk assessment output contain?

The output should contain the method and criteria you used, every identified risk with its owner, likelihood, consequence and evaluated level, the decision for each risk, and a dated approval. For ISO 27001 those results link to the treatment plan and Statement of Applicability. In our view, a customer wants proof the assessment is current, approved and drives your controls.

The auditor and the buyer read the same output with different questions in mind. The table sets them side by side. The right-hand column is our guidance on what security questionnaires commonly cover, not a quote from any one questionnaire or a formal requirement.

| Output element | What an ISO 27001 auditor checks | What we expect a customer questionnaire to ask |
| --- | --- | --- |
| Method and criteria | Written, approved and applied the same way on every run | Whether you have a documented risk assessment process |
| Risk list with owners | Each risk traced to a named owner and an analysis | Who is accountable for security risk |
| Dates and triggers | Runs at planned intervals and after significant change | When the last assessment was completed |
| Evaluation and decisions | Results compared with acceptance criteria | Whether risks are reviewed by senior management |
| Link to controls | Risks traced to the treatment plan and the Statement of Applicability | How identified risks lead to security controls |

Keep one version of the truth. A summary for customers, drawn from the same record the auditor sees, is easier to defend than a separate document written for sales.

## Why isn't a vulnerability scan or penetration test a risk assessment?

A vulnerability scan or penetration test finds technical weaknesses at a point in time. A cyber security risk assessment asks what those weaknesses, and many others, mean for the business: how likely harm is, how bad it would be, and whether the firm can accept it. Scan and test results are inputs to the assessment, not a substitute for it.

NIST SP 800-30 treats a vulnerability-oriented analysis as one of three possible starting points, alongside threat-oriented and asset or impact-oriented analysis. A scanner only sees technology, so it misses the weaknesses in people, processes and places that Step 3 draws on. A clean penetration test says nothing about a supplier with admin access or a finance process that a phishing email could redirect.

A scan tells you what is open. A risk assessment tells you whether that matters.

## What are the most common cyber security risk assessment mistakes?

The most common cyber security risk assessment mistakes are assessing to pass the audit, limiting the scope to IT, leaving risks without owners, scoring once a year and never between, and changing the scales between runs. Each one produces a document that looks complete while telling leadership very little about real exposure.

1. **Assessing to pass the audit.** A register written the month before certification shows the auditor a snapshot, not a process.
2. **IT-only scope.** Leaving out people, suppliers, finance processes and physical access misses many of the ways incidents actually start.
3. **No owners.** A risk owned by "IT" or by nobody has no one to decide on treatment.
4. **Scoring once a year.** An annual pass with no change triggers leaves the assessment behind every migration and new supplier.
5. **Moving the scales.** Changing the criteria between runs means this year's scores can't be compared with last year's, which defeats the repeatability Clause 6.1.2 expects.

The fix is the same in each case: set the criteria first, give every risk an owner and let real change, not the audit date, trigger the next run.

## Frequently asked questions

### How long does a cyber security risk assessment take?

It depends on the scope, the number of systems and suppliers, and whether an asset inventory already exists. A first assessment takes longest because the criteria and the inventory have to be built. Later runs are faster, because they update an existing record rather than start again.

### Can we use a cyber security risk assessment template?

Yes, as a format. A template gives you columns and a layout, but the criteria, scope and owners must be your own and approved by your leadership. An auditor will test whether the method produces consistent results, and a copied template does not prove that.

### Is a cyber security risk assessment the same as an information security risk assessment?

They overlap heavily. ISO 27001 uses "information security risk assessment", which covers information in any form, including paper records and what people know. A cyber security risk assessment usually focuses on digital systems and data. For ISO 27001 purposes, scope it as an information security risk assessment.

### Should we follow ISO/IEC 27005 or NIST SP 800-30?

Either can guide the method. ISO/IEC 27005 is written to support ISO 27001, so it fits firms pursuing certification. NIST SP 800-30 is free to download and sets out a detailed process with example scales. Both lead to the same outcome if your criteria are set first and applied consistently.