- A cybersecurity strategy defines risk appetite, security goals, and investment priorities. A roadmap translates those goals into specific actions with owners and timelines. Both are necessary; neither replaces the other.
- Strategy is a business document, not a technical one. It requires board approval because it reflects decisions about acceptable risk, not just IT configuration choices.
- A strategy without a risk assessment is guesswork. The risk assessment identifies what matters most; the strategy decides how much protection that warrants.
- Two to three years is a reasonable horizon. Review annually; update after a major incident, regulatory change, or significant shift in your business or technology environment.
- Four components every strategy needs: risk appetite statement, strategic goals, guiding principles, and the measurement framework that tells you whether you are getting there.
Strategy versus roadmap: why the distinction matters
Most organisations that ask for a cybersecurity strategy actually want a roadmap: a prioritised list of things to fix. A roadmap is useful. It is not a strategy.
A strategy answers two questions: why are we investing in security, and what outcomes are we trying to achieve? It reflects your risk appetite and sets goals that security investments are expected to deliver against. It is a business document; the board approves it because it encodes decisions about acceptable risk that affect the whole organisation.
A roadmap answers different questions: how do we achieve those goals, and in what order? It translates strategic goals into specific projects, assigns owners, sets timelines, and tracks progress. It is an operational document. The security team runs it.
A roadmap without a strategy is a collection of good ideas competing for budget with no basis for choosing between them. A strategy without a roadmap describes where you want to be and leaves you there.
Start with the risk assessment
Set goals before you know your actual exposures and you are guessing. The risk assessment gives you the evidence; the strategy decides what to do with it.
The risk assessment tells you what assets you have, what threatens them, what weaknesses exist in your defences, and what the likely cost of a failure would be. That output feeds directly into strategy formation. Risks at the top of the register need a treatment decision now. Lower-scoring ones can be accepted or deferred with documented rationale.
If you already have a risk assessment, your strategy should be traceable to it. Every strategic goal should map back to a category of risk the assessment identified.
Risk appetite is a statement of how much risk your organisation is willing to accept in pursuit of its objectives. It is uncomfortable to write because it forces explicit decisions. Most organisations prefer vague language that avoids committing to anything. A strategy with vague risk appetite is not a strategy: it is a set of good intentions that will not survive a budget conversation.
The four components of a cybersecurity strategy
1. Risk appetite statement
Define, explicitly, what risks your organisation will accept, which it will not, and where the boundaries are. Break it down by risk category: financial loss, data exposure, operational disruption, reputational damage, regulatory consequence.
Risk appetite should reflect your business context. A financial services firm under DORA has very low appetite for operational disruption. Write it specifically enough that it can guide a real decision.
2. Strategic security goals
Goals are the outcomes the strategy is designed to achieve, stated in terms the business can evaluate. Not "improve patch management" but "reduce the time between vulnerability disclosure and patch deployment to under 30 days for critical systems." Not "train staff" but "achieve 95% completion on phishing simulation exercises across all business units by Q3."
Three to five goals is enough for a two-year strategy. Each goal should be tied to a risk category from your risk assessment, measurable with a metric that exists or can be created, achievable given your budget and headcount constraints, and approved by the board, not just the security function.
3. Guiding principles
Principles are the rules that govern security decisions in the gaps between explicit policies. Examples of useful principles: least privilege (users get the minimum access needed, by default); security by design (new products include security review before build, not after); third-party trust (suppliers with access to our systems must meet minimum standards before onboarding).
Principles are not aspirations. They are commitments that should be enforceable. If your organisation would not apply a principle under pressure, remove it.
4. Measurement framework
Define the metrics that will tell you whether you are making progress against each strategic goal. Identify who is responsible for collecting and reporting each metric, and at what frequency.
Security metrics worth tracking at board level: time to detect and respond to incidents; coverage of critical controls (MFA, patching, logging); percentage of high-risk vulnerabilities remediated within SLA; risk register movement over time.
How strategy and roadmap work together
| Strategy | Roadmap |
|---|---|
| Why and what | How and when |
| 2-3 year horizon | 12-18 month horizon, rolling |
| Board audience | Security and IT teams |
| 3-5 goals | 20-40 specific projects or workstreams |
| Risk appetite drives it | Strategy goals drive it |
| Reviewed annually | Updated quarterly |
Common strategy mistakes
Mistaking a framework for a strategy. Adopting ISO 27001 or Cyber Essentials is an implementation decision, not a strategy. "We will achieve ISO 27001 certification" is a roadmap milestone. "We will reduce our exposure to supply chain attacks by requiring certification of all Tier 1 suppliers" is a strategic goal.
Writing a strategy for the auditor, not the business. A strategy designed to satisfy a regulatory checkbox will not get budget or board attention when it competes with revenue-generating priorities.
Setting goals without checking budget. A strategy that requires a 40% increase in security headcount that has not been approved will not be executed. Validate resource assumptions before the strategy goes to the board.
No accountability. Every strategic goal needs a named owner: a person, not a team.
How long a strategy should last
Most organisations run a two-to-three-year strategy. Review it annually. Update it after a significant breach, a regulatory change, a merger, or any technology shift large enough to change your risk profile.
Use the annual review to pressure-test your risk appetite statement. If your organisation has grown, changed sector, or picked up new regulatory obligations, the appetite statement needs to keep pace.
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