Every organisation holds data that someone else wants, customer records, financial information, intellectual property, employee details. A data security risk assessment is the structured process you use to identify what threatens that data, evaluate how likely and damaging each threat is, and decide what to do about it. Without one, you’re making security decisions based on gut feeling rather than evidence, and that’s a gamble most UK businesses can’t afford.
The process itself isn’t mysterious, but it does need to be methodical. You need to know which assets matter most, where the vulnerabilities sit, what the realistic threats are, and how to prioritise your response when budgets and resources are finite. Done properly, a risk assessment gives you a clear, defensible basis for every pound you spend on security, and it’s a core requirement if you’re working towards ISO 27001 certification.
At TrustedIA, we’ve spent over 30 years helping UK businesses assess and strengthen their cybersecurity posture. Our team includes ISO 27001 subject matter experts, and we’ve built our own tooling (CRAFT) specifically for cyber security posture assessment. This guide draws on that hands-on experience to walk you through a practical seven-step methodology you can apply to your own organisation, from scoping and asset identification through to risk treatment and ongoing review.
Step 1. What a data security risk assessment is
A data security risk assessment is a formal process for identifying the information assets your organisation holds, understanding what threats and vulnerabilities apply to them, and estimating the likely impact if something goes wrong. The output is a prioritised risk register that tells you where to direct your attention and resources. It is not a one-off checkbox exercise; it is the foundation of a working information security programme.
A risk assessment without a defined methodology produces a list of concerns, not a plan of action.
What the key terms actually mean
Before you start, you need to be precise about the core terminology, because these terms get used loosely and inconsistently across teams and tools.
| Term | Definition | Example |
|---|---|---|
| Asset | Anything of value that holds, processes, or transmits data | CRM system, email server, cloud storage, physical filing cabinet |
| Threat | A potential event or action that could harm your data | Ransomware attack, accidental deletion, insider misuse, supplier breach |
| Vulnerability | A weakness a threat can exploit | No multi-factor authentication, unpatched operating system |
| Likelihood | How probable it is that a threat exploits a vulnerability | Based on your sector, threat landscape, and existing controls |
| Impact | The consequence if the risk materialises | Financial loss, regulatory fines, reputational damage, operational downtime |
Using these terms consistently throughout your assessment matters particularly when you are working towards ISO 27001 certification. The standard (published by the International Organization for Standardization) requires a documented and repeatable risk assessment process, and auditors will check that your terminology, scoring, and decisions are coherent from start to finish.
How a risk assessment differs from a vulnerability scan or penetration test
Many organisations treat a vulnerability scan and a risk assessment as the same thing. They are related but not interchangeable. A vulnerability scan is an automated technical exercise that surfaces known weaknesses in your systems, such as open ports or unpatched software. A penetration test goes further by actively attempting to exploit those weaknesses. Both produce useful technical findings, but neither tells you which business risks matter most, how they connect to your data environment, or how to prioritise remediation within a limited budget.
Your data security risk assessment sits at a higher level. It takes technical findings as inputs, alongside process reviews, physical controls, and people-related factors. The central question it answers is: given everything we know about our assets, threats, and vulnerabilities, where does our greatest exposure lie and what should we tackle first?
What it produces and why it matters in the UK
At the end of a well-run assessment, you will have a risk register, a living document that lists each identified risk, its likelihood and impact scores, the controls currently in place, and the agreed treatment action. This register is the primary artefact you maintain and update over time.
In the UK, this work is not just good practice. The UK GDPR requires organisations to implement appropriate technical and organisational measures based on risk. The Information Commissioner’s Office expects you to show that your security decisions are proportionate and evidence-based. A documented risk assessment provides exactly that evidence, whether you face a regulatory enquiry, an insurer’s request, or a client’s due diligence process.
Step 2. Set scope, context, and risk criteria
Before you identify a single threat, you need to define what you’re assessing and how you’ll measure risk. Skipping this step means your assessment drifts in scope, produces inconsistent scores, and fails to give you the prioritised, defensible output that a serious data security risk assessment must produce. Context and criteria are the structural foundations you build everything else on.
Define what’s in scope
Your scope statement sets the boundaries of the assessment. It specifies which systems, locations, processes, and data types you’re covering, and equally, what you’re excluding and why. A scope that covers your entire organisation at once is usually too broad to be useful, particularly for an SMB with limited internal resources and time.
Answer these three questions and document your responses formally:
- Which data do you process? List the categories: customer records, payroll data, intellectual property, supplier contracts, operational data.
- Where does that data live? On-premise servers, cloud platforms such as Microsoft 365 or Azure, employee devices, physical archives.
- Which teams and processes handle it? Finance, HR, sales, customer support, third-party suppliers with system access.
Your scope statement forms part of the formal assessment record and is required documentation for ISO 27001 certification. Write it in plain language so that anyone reviewing the assessment later can understand exactly what was included.
Establish your risk criteria before you score anything
Risk criteria define how you measure likelihood and impact, and what score threshold determines whether a risk is acceptable or needs treatment. Without an agreed framework in place first, two people assessing the same threat will produce different scores, which makes your risk register impossible to defend or compare over time.
Agree and document your scoring method before you assess a single risk, or the results will be inconsistent and your prioritisation decisions will be unreliable.
Use a simple matrix. Here is a practical template you can adopt directly:
| Score | Likelihood | Impact |
|---|---|---|
| 1 | Unlikely (once in several years) | Minimal disruption, no regulatory exposure |
| 2 | Possible (around once a year) | Moderate disruption, potential regulatory notice |
| 3 | Likely (several times a year) | Significant financial loss, regulatory fine, or reputational damage |
Multiply likelihood by impact to produce a risk score from 1 to 9. Then set your thresholds: scores of 6 to 9 require immediate treatment, 3 to 4 require a scheduled remediation plan, and 1 to 2 are acceptable with monitoring. Fix these thresholds before you begin scoring individual risks, not after.
Step 3. Map data flows and classify data
You cannot protect data you haven’t located. Before you start identifying threats, you need to know where your data originates, where it moves, and where it ends up. Data flow mapping gives you a visual or documented record of exactly that. Without it, your data security risk assessment will miss entire categories of exposure, particularly risks that sit in transit between systems or with third-party processors.
Trace where your data travels
Walk through each data category you defined in your scope and document the full journey it takes through your organisation. Start at the point of collection and follow the data through every system, team, and external party that touches it.
For each data flow, capture the following:
- Source: Where does the data enter your organisation? Web form, email, paper, API feed.
- Processing location: Which systems handle it? On-premise server, cloud application, employee device.
- Storage location: Where does it sit at rest? Database, shared drive, cloud storage bucket, physical archive.
- Transmission method: How does it move? Email, encrypted file transfer, direct system integration.
- Recipients: Who receives it internally and externally? Finance team, third-party payroll provider, marketing platform.
A data flow map doesn’t need to be a complex diagram. A simple table works equally well, as long as it’s accurate and kept up to date.
Document your completed map formally, because it becomes a reference document you update whenever systems or processes change.
Apply a classification scheme
Once you know where your data lives and moves, you need to classify it by sensitivity and criticality. Classification tells you how much protection each data type warrants and directly informs your risk scoring in Step 5.
Use a straightforward four-tier scheme that aligns with the requirements of UK GDPR and ISO 27001:
| Classification | Description | Example |
|---|---|---|
| Public | No restrictions on access or sharing | Marketing materials, published reports |
| Internal | Limited to staff, no external sharing | Internal process documents, staff directories |
| Confidential | Restricted access, handled with controls | Customer records, financial data, contracts |
| Restricted | Highest sensitivity, strict access controls | Special category personal data, credentials, legal privilege |
Assign each data flow a classification level. Higher classifications automatically attract tighter controls and higher baseline risk scores, which you’ll carry forward into your threat identification and scoring steps.
Step 4. Identify threats to your data
With your data map and classification scheme in place, you can now identify what could actually harm your data. This step asks you to work through every data flow and asset in scope and ask: what could go wrong here, and who or what could cause it? The goal is a comprehensive list of credible threats, not an exhaustive catalogue of every theoretical risk in existence. Focus on threats that are realistic given your sector, size, and systems.
A threat you haven’t named is a threat you can’t manage. Spend time here being thorough, because gaps in this list become blind spots in your entire data security risk assessment.
Use threat categories to structure your thinking
Approaching threat identification without structure leads to lists that are either too narrow or too scattered. Working through recognised threat categories ensures you cover each angle systematically. For each category below, consider which assets in your scope are exposed and note the specific threat that applies.
| Category | Example threats |
|---|---|
| External attackers | Ransomware, phishing, brute-force credential attacks, supply chain compromise |
| Insider threats | Accidental data sharing, deliberate data theft, misconfiguration by staff |
| Physical threats | Laptop theft, unauthorised access to server rooms, printed records left unsecured |
| Third-party risks | Supplier data breach, insecure API integrations, cloud provider outage |
| System failures | Hardware failure, software bugs causing data corruption, failed backups |
| Environmental hazards | Flooding, fire, power outage affecting data availability |
Work through each category in relation to every asset and data flow you documented in Step 3. Record every plausible threat you identify, even if it feels unlikely. You’ll apply likelihood scoring in Step 5.
Build your threat log
As you identify threats, record them in a structured format so nothing gets lost before you move to scoring. Use this simple template for each entry:
| Field | Detail to record |
|---|---|
| Asset or data flow | Which specific system, dataset, or process does this apply to? |
| Threat description | What is the specific threat in plain language? |
| Threat source | External actor, internal staff, third party, system, environment |
| Data classification affected | Public, Internal, Confidential, or Restricted |
Your completed threat log feeds directly into the next two steps. Keep descriptions specific rather than generic: "phishing email targeting finance team credentials" is more useful than "phishing attack".
Step 5. Find vulnerabilities and control gaps
You now have a list of credible threats mapped to specific assets and data flows. The next task in your data security risk assessment is to ask: what weaknesses exist right now that would allow those threats to succeed? A vulnerability is any gap in your controls, whether technical, procedural, or physical, that a threat can exploit. This step connects your threat list to the reality of your current security posture.
Review controls against each threat
Work through your threat log from Step 4 and, for each entry, identify what control currently prevents or limits that threat from causing harm. A control can be technical (multi-factor authentication, encryption, endpoint protection), procedural (a documented access review process, an incident response plan), or physical (locked server rooms, clean desk policies). If no relevant control exists, that is a gap. If a control exists but is incomplete or inconsistently applied, that is also a vulnerability.
A partial control is not the same as an effective one. Record both the control and its actual state, not the control you intend to have in place.
For each threat in your log, capture the following:
| Field | Detail to record |
|---|---|
| Threat reference | Link back to the relevant entry in your threat log |
| Existing control | Name the specific control currently in place, or note "none" |
| Control effectiveness | Is it fully applied, partially applied, or absent? |
| Vulnerability identified | Describe the specific weakness in plain language |
Common control gaps to check
Many UK businesses discover the same categories of weakness when they conduct this exercise honestly. Work through each area below and check whether a gap applies to your organisation.
- Access management: Are user accounts reviewed regularly? Do former employees retain access to systems?
- Patch management: Are operating systems and applications on a defined patching schedule, or is it ad hoc?
- Data transfer controls: Is sensitive data transmitted over unencrypted channels such as plain email?
- Backup integrity: Are backups tested regularly, or just assumed to be working?
- Third-party oversight: Do you have written agreements covering data security obligations with every supplier who processes your data?
- Staff awareness: Have all staff completed security awareness training in the past 12 months?
Record every gap you identify against its corresponding threat. This list feeds directly into your risk scoring in the next step.
Step 6. Score risk and prioritise actions
With your threats logged and your control gaps documented, you now have everything you need to score each risk and rank them in order of urgency. This is the step where your data security risk assessment moves from analysis to decision-making. Apply the scoring criteria you defined in Step 2 to each risk entry consistently, using the same method throughout so your results are comparable and defensible.
Apply your scoring matrix
Work through every entry in your threat log and assign a likelihood score and an impact score using the 1-to-3 scale you agreed earlier. Multiply the two scores to produce a risk rating between 1 and 9. Base your likelihood score on your organisation’s current control effectiveness from Step 5, not on how the threat would score if you had perfect defences. A partial or absent control should push the likelihood score up.
Score risks as they stand today, not as you hope they will stand after planned improvements are in place.
Use this template to record each scored risk:
| Risk ID | Asset or Data Flow | Threat | Likelihood (1-3) | Impact (1-3) | Risk Score | Priority |
|---|---|---|---|---|---|---|
| R-001 | CRM database | Ransomware via phishing | 3 | 3 | 9 | Immediate |
| R-002 | Payroll data | Insider data theft | 2 | 3 | 6 | Immediate |
| R-003 | Email system | Brute-force credential attack | 2 | 2 | 4 | Scheduled |
| R-004 | Marketing files | Accidental public sharing | 2 | 1 | 2 | Monitor |
Complete this table for every risk you have identified. Do not group threats together to save time; each distinct risk needs its own row so nothing gets buried or overlooked when you move to treatment.
Translate scores into a prioritised action list
Once every risk is scored, sort your register by risk score from highest to lowest. This ranked list is your working priority order. Risks scoring 6 to 9 require immediate treatment, meaning you assign a named owner, a specific action, and a fixed deadline. Risks scoring 3 to 4 require a scheduled remediation plan with a defined review date. Risks scoring 1 to 2 are acceptable in the short term but must be monitored and reassessed at your next review cycle.
Document the action, the owner, and the deadline for every risk rated 3 or above. A scored register with no assigned owners is not a plan; it is just a list.
Step 7. Record, treat, and review risks
A scored risk register only has value if it becomes a living document that drives real action. This step is where your data security risk assessment moves from analysis into operation. You record every risk formally, assign a treatment decision, and establish a review cycle so the register stays accurate as your organisation changes.
Formalise your risk register
Your risk register is the central record of everything your assessment has produced. For each risk, you need to capture enough detail so that anyone reviewing the document six months later can understand the original finding, the treatment decision made, and the current status without needing to speak to the person who ran the assessment. Use this template as your baseline:
| Field | What to record |
|---|---|
| Risk ID | A unique reference (R-001, R-002, etc.) |
| Asset or data flow | The specific system or process affected |
| Threat and vulnerability | Plain-language description of both |
| Likelihood / Impact / Score | Your scores from Step 6 |
| Risk owner | The named individual accountable for treatment |
| Treatment decision | Accept, mitigate, transfer, or avoid |
| Treatment action | The specific action and its deadline |
| Review date | When this risk will be formally reassessed |
Store the register in a controlled location with version history, whether that is a shared document platform such as Microsoft SharePoint or a dedicated information security management tool.
Choose a treatment for each risk
Every risk in your register needs a formal treatment decision. There are four standard options: mitigate (implement or strengthen a control), accept (document that the risk sits within your tolerance), transfer (shift the financial exposure through cyber insurance), or avoid (stop the activity that creates the risk). Most risks will require active mitigation rather than acceptance.
Accepting a risk without a documented rationale and sign-off at the appropriate level leaves you exposed if a regulator or insurer asks how you managed it.
Record who approved each acceptance decision and on what date, and attach that approval to the relevant register entry.
Schedule your review cycle
Your risk register is not a document you file and forget. Set a formal review date for the full register at least annually, and trigger an out-of-cycle review whenever your organisation experiences a significant change: a new system deployment, a supplier change, a security incident, or a shift in regulatory guidance from the ICO. Assign a named individual to own each review so it does not get quietly deferred.
Next steps
Running a data security risk assessment is not a project you complete once and shelve. It is a repeatable discipline that keeps your organisation’s security posture grounded in current evidence rather than outdated assumptions. The seven steps in this guide give you a structured, auditable methodology you can apply right now, whether you are preparing for ISO 27001 certification, responding to a client’s due diligence request, or simply bringing more rigour to how your organisation manages risk.
Start with scope. Define your boundaries, agree your risk criteria, and build your data flow map before you attempt to score a single threat. Each step in this guide builds directly on the one before it, so the quality of your risk register depends on the groundwork you lay at the start.
If you want expert support to run this process or assess your current security posture, speak to the TrustedIA team to find out how we can help.
