- A risk assessment maps what you have, what threatens it, and what those threats would cost. A penetration test probes whether specific controls hold. Both are useful; the assessment comes first.
- Five steps: asset inventory, threat identification, vulnerability analysis, risk scoring, risk treatment. Each produces a document you can act on and audit against.
- NIS2 Article 21, ISO 27001 Clause 6.1, and UK GDPR Article 32 each require a documented risk assessment. Failing to have one is a regulatory exposure, not just a security gap.
- Risk scoring uses likelihood and impact. Most organisations use a 3x3 or 5x5 matrix. Consistency in applying the scale matters more than the scale itself.
- The output is a risk register and a treatment plan: two artefacts your auditors, insurers, and board will ask for.
Risk assessment versus penetration test
A cybersecurity risk assessment is a structured process that asks: what do we have, what could go wrong, how likely is it, and what would it cost us? It covers your entire environment: systems, people, processes, suppliers. It produces a prioritised list of risks with treatment decisions attached. The analysis is a management exercise that pulls in technical findings.
A penetration test is a focused technical exercise. A tester attempts to exploit specific systems or pathways to confirm whether your controls work as intended. It answers a narrower question: can an attacker get in here? The scope is agreed in advance and the output is a technical findings report.
You need the risk assessment first. Without it, you are asking a tester to probe systems you have not yet decided are worth protecting. The risk assessment tells you which systems carry the most risk and therefore which warrant a pen test.
Annually as a baseline. Also after: a cloud migration, a merger or acquisition, a new product handling personal data, significant headcount growth, or a security incident. NIS2 and ISO 27001 both treat risk management as a continuous obligation rather than a scheduled event.
Step 1: Asset inventory
You cannot assess risk on assets you do not know you have. Asset inventory is the first step and the one most organisations underinvest in.
An asset in this context is anything that holds, processes, or transmits information of value to your business. That includes hardware (servers, laptops, mobile devices), software (applications, SaaS subscriptions, cloud services), data (customer records, financial data, intellectual property), and people (employees with privileged access, key suppliers).
For each asset, record: what it is and where it sits (on-premises, cloud, hybrid), who owns it, what data it holds or processes, its criticality to business operations, and any existing controls protecting it.
The output is an asset register. Start with your most critical systems. A working register you can act on beats a comprehensive one still being built six months from now.
Step 2: Threat identification
A threat is any event or actor that could exploit a weakness and cause harm to your assets. Common threat categories for UK businesses:
- External attackers: ransomware groups, phishing campaigns, credential stuffing, supply chain compromise
- Insiders: employees misusing access, whether deliberately or through carelessness
- Third parties: suppliers, contractors, or cloud providers with access to your systems
- Physical threats: device theft, unauthorised physical access to server rooms
- Environmental: power failure, flooding, hardware failure at a data centre
Map each threat to the assets it could affect. Use sector-specific threat intelligence where available; the NCSC publishes regular threat assessments for UK organisations.
Step 3: Vulnerability analysis
A vulnerability is a weakness a threat could exploit. With assets and threats mapped, the next step is assessing what weaknesses exist in your defences.
| Source | What it finds |
|---|---|
| Vulnerability scanning tools | Unpatched software, misconfigured systems, open ports, weak cipher suites |
| Configuration reviews | Overpermissioned accounts, default credentials, disabled logging |
| Policy and process review | Missing procedures, untrained staff, undocumented change management |
| Supplier assessments | Third parties lacking security certifications, no right-to-audit clauses |
| Previous audit findings | Unresolved findings from prior pen tests, audits, or incidents |
Step 4: Risk scoring
Risk scoring lets you rank threats so decisions about time and budget follow the evidence. The standard formula:
Risk = Likelihood × Impact
Likelihood is how probable the threat-vulnerability combination is over a given period, usually 12 months. Impact is the severity of the outcome: financial cost, operational disruption, reputational damage, regulatory consequence.
Most organisations score each dimension on a 3-point (Low / Medium / High) or 5-point scale. A 3x3 matrix is easier to explain to a board; a 5x5 gives more granularity for prioritisation. Use whichever your organisation can apply consistently.
Overestimating likelihood for exotic threats while underestimating the mundane ones (phishing, unpatched systems). Treating impact as financial only. Reputational damage and regulatory fines should factor in. Scoring risks without accounting for existing controls: a vulnerability with a compensating control carries lower likelihood than one with none.
The output is a risk register: every risk listed with its score, owner, and current status. Your risk register is a live document, not a snapshot.
Step 5: Risk treatment
For each risk in your register, you choose one of four options:
- Mitigate: implement a control that reduces likelihood or impact. Patching software, adding MFA, tightening access permissions.
- Transfer: shift the financial consequence to a third party. Cyber insurance is the main mechanism.
- Accept: acknowledge the risk and decide not to act, typically because the cost of mitigation outweighs the expected loss. Acceptance must be documented and signed off by someone with authority.
- Avoid: stop the activity that creates the risk. Decommission a legacy system. Exit a product line. Terminate a supplier relationship.
Treatment decisions feed a risk treatment plan: who does what, by when, and with what budget. Risks with no treatment decision are a red flag in any audit.
Regulatory requirements
| Framework | Requirement | What auditors check |
|---|---|---|
| NIS2 Article 21 | Risk analysis and information system security policies must be in place for essential and important entities | Documentation of the risk analysis process; evidence of management oversight; treatment decisions for identified risks |
| ISO 27001:2022 Clause 6.1 | Define and apply an information security risk assessment process; document and retain results | Consistent methodology; risk ownership; risk register updated at planned intervals; Statement of Applicability linked to risk decisions |
| UK GDPR Article 32 | Implement appropriate technical and organisational measures, taking into account risks to personal data | Evidence that data protection risks were assessed; controls proportionate to identified risks; DPIA for high-risk processing |
One well-structured risk assessment covers all three if it spans personal data, information assets, and critical systems. You do not need three separate exercises.
What a completed risk assessment produces
Risk register: every identified risk, with asset, threat, vulnerability, likelihood, impact, score, owner, and current status. Updated on a defined cycle.
Risk treatment plan: the actions your organisation has committed to, with owners, deadlines, and links back to the risks they address. A board-level summary showing the before and after risk profile once treatment is complete.
Most cyber insurers now ask for evidence of a documented risk assessment during underwriting. A completed risk register with treatment actions in progress typically results in better coverage terms than a verbal assurance that risks are managed.
How often to repeat the process
Annual reassessment is the baseline. Significant events trigger an off-cycle assessment: moving workloads to a new cloud provider, acquiring a business and inheriting its systems, launching a product that handles personal data at scale, experiencing a breach, or a material change in the threat landscape.
Build your process so that partial updates (reassessing a specific asset class or business unit) are easier than full reassessments, so the trigger to start is lower.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years. View full profile