- A cybersecurity roadmap protects business processes, not just assets. Start with what would break the business, then work backward to the systems, data, and controls that protect it.
- The right sequence is: business context → asset inventory → threats and risk → current maturity → target state → gap analysis → prioritisation → phased plan → ownership and budget → testing → governance.
- Maturity scoring across people, process, and technology gives you a more honest starting point than a binary in-place or not-in-place gap analysis.
- Incident response belongs in the first 90 days. You need a response capability before you need a mature one.
- Three roadmap horizons work in practice: Stabilise (0 to 90 days), Build foundations (3 to 12 months), Mature (12 to 24+ months). Avoid committing to a 36-month plan. Threats, technology, and business priorities change too fast.
- The roadmap's output is a table, not a strategy deck: priority, risk addressed, initiative, owner, dependency, target date, effort, and success measure for every initiative.
What a cybersecurity roadmap actually is
Most UK organisations treat cybersecurity as a product collection: antivirus here, a firewall there, a password policy because the IT provider asked. Each control exists in isolation. When a breach arrives, there is no prioritised list, no clear owner, and no plan.
A cybersecurity roadmap captures your current posture, defines the target state your risk profile and regulatory obligations require, and maps which controls close the gap, in order, with named owners and dates. It links to the risk register, carries a budget dimension, and refreshes on a fixed cadence. That makes it an investment plan, not a shopping list.
Step 1: Understand the business
Security programmes that start with asset inventory or framework selection skip the most important question: what would actually damage this business? A vulnerability on a public-facing web server may be technically severe. A compromise of your identity platform may bring every business service to a halt simultaneously. Those are not equivalent risks, and a roadmap that treats them as such wastes budget on the wrong problems.
Before cataloguing assets, establish the business context your roadmap is designed to protect:
- Critical services and processes: which operations, if disrupted, would cause material harm to customers, revenue, or regulatory standing
- Crown-jewel systems and data: the systems and datasets whose compromise would represent the worst-case outcome: financial records, customer PII, intellectual property, operational technology
- Maximum tolerable downtime: for each critical service, how long can the business function without it before consequences become serious
- Regulatory obligations and risk appetite: sector-specific requirements (NIS2, DORA, FCA, NHS DSP Toolkit) and the organisation's stated tolerance for security risk
- Key third-party dependencies: MSPs, SaaS providers, cloud platforms, and suppliers with privileged access or data-sharing relationships
- Business priorities for the next 12 to 24 months: planned acquisitions, geographic expansion, new product launches, cloud migrations, or outsourcing that will materially change the attack surface
With that context in place, every control decision has a concrete business anchor, and the roadmap becomes something a board can evaluate and fund.
Step 2: Build your asset and dependency inventory
You cannot assess, prioritise, or protect assets you have not catalogued. A useful inventory covers four categories: hardware (every device connecting to your network or accessing business data, including employee-owned devices used for hybrid working); software and services (every application, cloud platform, and SaaS tool in active use, including shadow IT and third-party integrations); data (where sensitive data lives, who can reach it, and how it moves between systems); and people and third parties (users, contractors, vendors with system access, and managed service providers).
Most organisations find sensitive data in more places than expected: email archives, unmanaged OneDrive folders, shared drives with no access review since deployment, spreadsheets used as improvised databases. Start with what you can catalogue now. Prioritise accuracy and maintenance over completeness, and map everything back to the critical business services identified in Step 1.
Step 3: Identify threats and assess risk
The attacks targeting UK organisations in 2025 and 2026 follow familiar patterns: ransomware encrypting systems and demanding payment; business email compromise diverting payments or extracting data; credential theft through phishing and password-spray attacks against cloud accounts; and supply chain compromise reaching you through a trusted software provider or managed service. Your risk assessment focuses on these patterns applied to your specific assets and business context.
Crown jewels and business impact
For each critical business service identified in Step 1, map the specific assets that service depends on. Then ask: what is the business consequence if that asset is compromised or made unavailable? The answer drives prioritisation more reliably than a generic severity score.
A useful crown-jewels analysis records, for each critical service: the systems required to operate it, the data required to operate it, the internal people required, external supplier dependencies, recovery time requirements, and the specific consequences of a compromise or prolonged outage. That analysis makes the risk register defensible at board level, because every risk has a business consequence attached.
Risk scoring
For each asset or service, score likelihood of a successful attack (1 to 5) and impact to the business if it succeeds (1 to 5). Multiply them. Controls that reduce the score of high-likelihood, high-impact risks give the most return per pound spent.
Step 4: Assess your current maturity
A binary gap analysis ("in place" or "not in place") misrepresents most organisations' actual security position. A control that exists but is inconsistently applied, untested, or undocumented is not the same as one that works reliably. Maturity scoring exposes the difference.
Score each security domain on a five-point scale: 0 = not implemented, 1 = ad hoc (exists informally or in isolated pockets), 2 = defined (documented and consistently applied), 3 = managed (monitored with metrics), 4 = measured (quantitatively understood with feedback loops), 5 = optimised (continuously improved based on evidence).
Assess across three dimensions: people, process, and technology. Use domains relevant to your organisation:
Score these domains honestly; the result is your current-state baseline. The gap between that baseline and your target (Step 5) generates the initiative list. Treat any domain scored at 0 or 1 as a priority regardless of risk-matrix position. Ad-hoc controls are not controls.
Step 5: Define your target state
Choose a recognised framework as your target anchor. Three apply most commonly in the UK:
Build the roadmap around business risk. Use frameworks and regulations to define control requirements and validate that your programme covers what matters.
Step 6: Perform the gap analysis
With a maturity baseline (Step 4) and a target framework (Step 5), compare your current maturity against your target for each control area. Record current score, target score, and the initiatives that close the gap. A gap analysis is only useful if specific enough to act on: "MFA is not enforced on shared service accounts" is actionable; "access control needs improvement" is not.
The gap list feeds into prioritisation. Every initiative on it has a parent risk from the register and a parent control requirement from the framework. That traceability makes the roadmap defensible when someone asks why a particular project is funded and another is not.
Step 7: Prioritise
Risk-based prioritisation outperforms compliance-first. Compliance-first asks what the auditor flagged. Risk-based asks what reduces the most real risk for the least effort.
Rank initiatives on two axes: the risk reduction they deliver, and the effort required. High-reduction, low-effort initiatives go first. Low-reduction, high-effort initiatives go last or are deferred. Regulatory deadlines add a third constraint: an NIS2 obligation with a hard deadline may warrant scheduling ahead of a higher-risk initiative that has no external date.
A roadmap is closer to a dependency graph than a ranked list. Some controls cannot be implemented until others are in place. Consider the chain: asset inventory enables identity and device visibility; that enables MFA and Conditional Access; that enables privileged access management; that enables Zero Trust. Similarly, backup inventory precedes backup architecture, which precedes immutable storage, which precedes restore testing, which precedes recovery exercises. Build the prioritisation to respect those dependencies.
Step 8: Build the phased roadmap
Three time horizons work for most organisations. Set a 24-month outer boundary with an annual reassessment. Beyond that, the forecast is too unreliable to plan against.
Example roadmap
The roadmap is a table. Every initiative has a named owner, a dependency, a target date, an effort estimate, and a measurable success criterion. Without specific success criteria, progress tracking has nothing to measure against.
| Priority | Risk addressed | Initiative | Owner | Dependency | Target | Effort | Success measure |
|---|---|---|---|---|---|---|---|
| Phase 1 : Stabilise (0–90 days) | |||||||
| Critical | Compromised cloud accounts | Enforce phishing-resistant MFA; block legacy auth | IT / Security | Identity inventory | 30 days | M | 100% account coverage, legacy auth blocked |
| Critical | Ransomware / data loss | Immutable backup with quarterly restore test | IT | Backup assessment | 60 days | M | Restore test passed, RTO validated quarterly |
| High | Unpatched vulnerabilities | Automated vulnerability management | IT | Asset inventory | 90 days | M | ≥95% of systems within patch SLA |
| High | No response capability | Minimum viable IR plan + tabletop exercise | CISO / IT | None | 60 days | S | Plan documented, tabletop completed, roles assigned |
| High | Stale accounts (leavers) | Same-day account offboarding procedure | IT / HR | HR process alignment | 30 days | S | Zero active accounts for leavers within 48h |
| Phase 2 : Build foundations (3–12 months) | |||||||
| High | Unmanaged endpoints | Device management and compliance enforcement | IT | MDM procurement, MFA deployed | 6 months | L | 100% corporate devices enrolled and compliant |
| High | Supply chain compromise | Third-party risk assessment programme | Security / Procurement | Supplier inventory | 6 months | M | All critical suppliers assessed; contractual requirements in place |
| Medium | Phishing susceptibility | Security awareness + quarterly simulations | HR / Security | None | 6 months | M | Click rate <5% sustained over two consecutive quarters |
| Medium | Privilege abuse | Privileged access management (JIT / PIM) | IT | MFA deployed | 9 months | L | All admin roles use time-limited activation; no persistent privilege |
| Phase 3 : Mature (12–24+ months) | |||||||
| Medium | Holistic security gaps | ISO 27001 certification programme | CISO / Senior leadership | Mature controls, management system | 18+ months | XL | Stage 2 audit passed; certificate issued |
Step 9: Assign ownership and budget
Name an owner and a funded budget for each initiative. Each one also needs: an owner with the authority to deliver it; an estimated cost covering external spend and internal resource time; any skills or third-party support that must be procured; and a link back to the risk or compliance requirement it addresses.
For board reporting, frame the budget as an investment decision. Each initiative reduces a named risk by a quantifiable amount. The board is allocating a finite security budget across competing risks. If a critical risk stays unfunded, that should be an explicit board decision, not something they discover after a breach.
Insurers require specific controls as a condition of coverage: MFA, immutable backup, and incident notification procedures are the most common minimum requirements. Before finalising the roadmap, review your policy's conditions and exclusions. Controls required by the insurer belong in Phase 1 regardless of their risk ranking. A claim denied because a mandated control was absent is expensive; it also eliminates the budget argument against implementing it.
Step 10: Test and measure
Untested controls are assumptions. Unexercised recovery is an assumption.
Run backup restore testing first. A backup that has never been restored is not a recovery capability. Test against the maximum tolerable downtime from your Step 1 analysis. If recovery takes longer than the business can absorb, the backup architecture needs revision.
Incident response exercises (tabletop at minimum, full simulation as the programme matures) test the process and people dimensions technology cannot cover. Who makes the call to isolate a system? Who approves external communications? Who contacts the ICO? Run the exercise before those questions arise in a real incident.
Penetration testing tells you whether your technical controls hold against an adversary's approach. Scope it to your crown-jewel systems first.
Key metrics to track against the roadmap: MFA coverage (percentage of accounts enrolled), patch compliance rate (percentage within SLA), phishing simulation click rate trending quarterly, mean time to detect and respond to security incidents, and open critical vulnerabilities unresolved past SLA.
Step 11: Govern and refresh
Two mechanisms keep the roadmap live. Quarterly reviews track progress, flag slipping initiatives, and update the threat context. Annual refresh revisits the risk assessment, incorporates new threats, regulatory changes, and business changes such as acquisitions or new market entry, and reprioritises for the coming year. The outer horizon is reassessed against actual progress.
Board or senior leadership reporting converts security progress into terms a board can act on: risk posture trend, incidents in the period, critical control status, and what is funded versus what is not. Boards need to know whether risk is moving up or down, and what decision they are being asked to make.
Regulatory alignment
Build the roadmap around business risk, and the major frameworks become validation layers rather than separate projects.
Cyber Essentials maps to the Stabilise phase. Most organisations that complete the first-90-day quick wins can achieve Cyber Essentials certification within the same quarter. Specific government and MOD contracts require Cyber Essentials Plus. Verify your contract terms.
NIS2 Article 21 requires policies on risk analysis, incident handling, backup and recovery, supply chain security, network security, cryptography, access control, and multi-factor authentication. Every item is a roadmap initiative. NIS2 compliance follows from a programme that covers the required controls. It is not a parallel workstream.
ISO 27001 Clause 6.1.2 requires a risk treatment plan linking each identified risk to a treatment decision and a control. That plan is structurally identical to your roadmap. Build the roadmap correctly and you produce the ISO 27001 risk treatment plan as a direct output.
DORA requires financial entities to maintain an ICT risk management framework, conduct resilience testing, and manage third-party ICT risks. The roadmap structure maps to each obligation. Resilience testing and third-party risk assessment belong in the foundational phase for any entity in DORA scope.
A roadmap built around compliance requirements tends to address what auditors check, not what would most damage the business. Risk-based prioritisation produces a different order.
Ryland has delivered cybersecurity, compliance, and IT management programmes for regulated organisations across the UK and the Netherlands for over 20 years, including senior roles at Microsoft, ING, IPsoft, PPHE and more. View full profile