Skip to content

Cyber Security Risk Assessment: What It Involves and How It Leads Into a Pen Test

A cyber security risk assessment shows where your organisation is most exposed. Learn what the process involves and how it shapes a focused pen test.
Cyber Security Risk Assessment: What It Involves and How It Leads Into a Pen Test

Most organisations have a reasonable sense of what would hurt them if it went wrong. Losing access to the finance system for a week, having client files published online, or watching a ransomware note appear on every screen in the building are all easy enough to imagine. What tends to be missing is a structured, written view of which of those scenarios is actually likely, what currently stands in the way, and where the money should go first. That is the job of a cyber security risk assessment.

It is also, interestingly, something that relatively few UK organisations get round to doing. The UK Government’s Cyber Security Breaches Survey 2025/2026, published on the 30th of April, 2026, found that only 30% of businesses and 27% of charities had carried out a cyber security risk assessment in the previous twelve months. Over the same period, 43% of businesses identified a breach or attack, meaning many organisations are being attacked without ever sitting down to identify where they are most exposed.

This guide explains what a risk assessment involves, how it differs from the more technical forms of assessment, and why a good one naturally ends with a decision about what to test.

What is a cyber security risk assessment?

A cyber security risk assessment is a structured exercise that identifies the information and systems an organisation depends on, the threats that could realistically affect them, and the likely business impact if those threats succeeded. The output is a prioritised list of risks, usually with an owner and a planned response for each one.

The important word here is organisational. A risk assessment looks at the business as a whole, including people, processes, suppliers and technology, and asks what matters most and what could go wrong. It is a management activity as much as a technical one, and the conclusions are usually aimed at directors or trustees who have to make decisions about budget and priorities.

The NCSC’s risk management guidance makes a point that is worth keeping in mind throughout. It describes the primary purpose of cyber risk management as improving business outcomes, and it explicitly favours approaches that reveal genuine risk over techniques that exist purely to satisfy a compliance requirement. In other words, the value of a risk assessment comes from the decisions it informs rather than from the document it produces.

How it differs from a vulnerability assessment and a penetration test

These three terms get used interchangeably, which causes a fair amount of confusion when organisations come to buy services. The simplest way to separate them is by the question each one answers.

Cyber security risk assessment Vulnerability assessment Penetration test
The question it answers What matters most to us, and what is most likely to go wrong? Which known weaknesses exist in these systems? Can an attacker actually exploit these weaknesses, and how far could they get?
Point of view Organisational Technical, broad Technical, adversarial
Typical method Workshops, interviews, asset and supplier reviews, documentation Largely automated scanning against known vulnerabilities Manual, human-led testing by qualified consultants
Main output A risk register and treatment plan A list of findings ranked by severity Evidence of exploitable paths, business impact and remediation advice

A risk assessment, then, tells you where to look. A vulnerability assessment tells you what is visibly wrong in the places you scan. A penetration test tells you what an attacker could genuinely do with those weaknesses, which is often quite different from what a severity score suggests.

What a cyber security risk assessment involves

There is no single mandatory method, and the NCSC is clear that no one technique suits every situation. That said, most credible approaches, including those described in ISO/IEC 27001 and NIST SP 800-30, follow a broadly similar sequence.

1. Define the scope

The first step, as you could probably guess, is agreeing what is being assessed and why. For a small firm this might be the whole organisation, whereas a larger business might start with a single division, a new product or a specific regulated service. Being explicit about scope matters because it prevents the assessment from skipping over awkward areas such as legacy systems or a recently acquired subsidiary.

2. Identify what you need to protect

This means building a picture of the assets that matter, which usually includes data (client records, financial information, intellectual property), systems (email, case management, payment platforms, operational technology) and the services that the business cannot function without. Crucially, it should also include the suppliers who hold or process that data. The same government survey found that only 15% of businesses formally reviewed the cyber risks posed by their immediate suppliers, even though supplier compromise has been behind several of the most damaging UK incidents of recent years.

3. Identify realistic threats

Here the assessment considers who might want to cause harm and how they would go about it. For most organisations the relevant threats are financially motivated criminals using phishing, credential theft, exposed remote access and ransomware, along with accidental exposure by staff. Sector matters a great deal, which is why a law firm handling completion funds faces a different threat profile to a school or a manufacturer running industrial control systems.

4. Review existing controls and weaknesses

Next, the assessment looks at what is already in place. This includes technical controls such as multi-factor authentication, patching and backups, as well as procedural controls like joiners and leavers processes, payment verification and incident response plans. Gaps identified here are often the point at which technical testing becomes relevant, because a control that exists on paper is not necessarily a control that works.

5. Assess likelihood and impact

Each risk is then rated according to how likely it is to happen and how badly it would affect the business if it did. Impact should be described in business terms, meaning lost revenue, regulatory exposure, contractual penalties, safeguarding consequences or reputational harm, rather than in purely technical language. This is the stage where directors usually start paying attention, because the conversation shifts from “we have an unpatched server” to “we could be unable to invoice clients for a fortnight”.

6. Decide how to treat each risk and record the result

Finally, each risk is given a response. The standard options are to reduce it with additional controls, transfer it (through insurance or contracts), avoid it by stopping the activity altogether, or formally accept it. The result is a risk register with named owners and review dates, and it should be revisited whenever something significant changes, such as a cloud migration, a merger or the launch of a new customer-facing application.

Where a risk assessment runs out of road

Perhaps the most important limitation of any risk assessment is that it relies heavily on assumptions. When a workshop concludes that the risk of an external breach is “low” because the firewall is well configured and MFA is enforced, that conclusion is only as good as the evidence behind it. In many cases the evidence is a conversation with the IT team or a policy document, rather than proof that the controls hold up against someone actively trying to get past them.

This is why risk assessments and technical testing work best together. The risk assessment identifies the scenarios that would matter most, and a penetration test checks whether the controls you are relying on to prevent those scenarios actually work. Notably, the same government survey found that only 13% of businesses and 7% of charities had used penetration testing in the previous year, so there is a substantial gap between organisations that think about risk and those that verify their defences.

How a risk assessment leads into a pen test

A well-run risk assessment should make scoping a penetration test much easier, because it has already told you where your highest-impact risks sit. Rather than testing everything at a shallow level, or testing the same handful of systems every year out of habit, you can point testers at the scenarios that genuinely worry you. We have written before about the problem with testing the same things every year, and a current risk assessment is one of the best ways to avoid it.

In practice, the link between a risk and a test usually looks something like this:

  • Risk: an attacker gains access through an internet-facing system or remote access gateway. This points towards external network penetration testing, which examines your perimeter in the way a remote attacker would.
  • Risk: a phished user account or compromised laptop leads to a wider breach. This calls for internal network testing, which shows how far an attacker could move once inside, and how quickly they could reach sensitive data or domain administrator access.
  • Risk: customer or client data is exposed through a portal or web application. A web application penetration test examines authentication, access controls and business logic flaws that automated scanners routinely miss.
  • Risk: you are not entirely sure what you have exposed online. This is common after rapid growth or a cloud migration, and an attack surface assessment is a sensible first step to map what an attacker can see before deciding what to test in depth.
  • Risk: a new AI chatbot or assistant could leak data or be manipulated. This is increasingly appearing on risk registers, and it needs specialist LLM penetration testing rather than a conventional web test.
  • Risk: a determined attacker combines several smaller weaknesses to reach a critical asset. For more mature organisations, red and purple teaming tests detection and response as well as prevention.

Once testing is complete, the findings should feed straight back into the risk register. A risk that was rated “low” on the basis of assumed controls may need re-rating if testers walked straight past those controls, and equally a well-defended area may justify a lower rating than before. If the test produces more findings than you can fix at once, our guide to penetration test remediation when you cannot fix everything explains how to prioritise using the same risk-based thinking.

How often should you carry out a cyber security risk assessment?

As a baseline, most organisations should review their risk assessment at least once a year. More importantly, it should be revisited whenever the business changes in a way that alters its exposure, for example when moving key systems to the cloud, onboarding a major new supplier, launching a new digital service or going through a merger or acquisition.

Regulatory expectations are also tightening. The Cyber Security and Resilience Bill, which was progressing through Parliament during 2026, is set to extend the UK’s existing NIS regime to cover medium and large managed service providers for the first time, and organisations already in scope of NIS are required to take appropriate and proportionate measures to manage risks to their systems. For businesses in regulated sectors such as finance, legal services and education, a current and evidenced risk assessment is increasingly something that clients, insurers and auditors expect to see.

Common mistakes to avoid

A few problems come up repeatedly when organisations carry out their own assessments:

  • Treating it as a one-off document. A risk register that was written for an audit three years ago and never reopened is effectively a historical record rather than a management tool.
  • Leaving it entirely to IT. The people best placed to judge business impact are usually department heads and directors, so an assessment written solely by the technical team often underestimates operational and reputational consequences.
  • Ignoring suppliers. If a third party holds your data or has remote access to your network, their weaknesses are part of your risk picture.
  • Assuming controls work because they exist. This is the gap that technical testing is designed to close, and it is the single most common reason that risk ratings turn out to be optimistic.

It is also worth remembering that schemes such as Cyber Essentials cover a valuable set of baseline controls, but certification on its own is not a substitute for understanding the specific risks your organisation faces.

Frequently asked questions

Is a cyber security risk assessment the same as a cyber security assessment?

Not quite, although the terms overlap. “Cyber security assessment” is often used as a broad umbrella covering risk assessments, vulnerability scanning, penetration testing and maturity reviews. A risk assessment specifically focuses on identifying and prioritising business risks, rather than on testing technical controls.

Do I need a risk assessment before a penetration test?

It is not strictly required, and many organisations commission a pen test without one. However, having a recent risk assessment makes it far easier to scope a test that focuses on your most significant exposures, which generally means better value and more relevant findings.

Can we carry out a risk assessment ourselves?

Yes, and many organisations do. The NCSC publishes free guidance that can help. The value of external support tends to come from an independent perspective and from experience of how attacks actually unfold in practice, which can make likelihood ratings more realistic.

How long does a cyber security risk assessment take?

For a small organisation with a straightforward IT setup, it might take a few days of workshops and documentation. Larger organisations with complex systems, multiple sites or heavy supplier dependencies should expect it to take several weeks.

Turning your risk assessment into a test plan

If you already have a risk assessment and want to know which of your assumptions would hold up against a real attacker, or if you are not sure where to start, Fortifi can help. Our CREST-accredited consultants carry out human-led testing and will help you scope work around the risks that matter to your organisation, rather than selling you a generic package. You can speak directly to one of our testers without going through a sales call.


Recent posts

How Penetration Testing Supports ISO 27001 Compliance

Read more

Mobile App Penetration Testing: What Gets Tested and How It Differs from Web Apps

Read more

How Much Does a Penetration Test Cost in the UK? What Drives the Price

Read more

What Auditors Want to See in a Penetration Test Report

Read more