Security Programs - A Plan is Not a Strategy
- Phil Venables
- 4 minutes ago
- 5 min read
Many security leaders, at all levels, correctly focus on having a good strategy and executing against that. However, many teams confuse planning, or “strategic planning” with actual strategy. In other words, a plan is not a strategy. This short video explains this very clearly.
So, a strategy specifies a competitive outcome you wish to achieve, based on a coherent theory of winning. In the case of security the notion of a competitive outcome has multiple dimensions. Competition can be against other companies, against attackers, or even "competing" against legislators/regulators - think of this as competing to achieve the spirit and letter of laws and regulations with the most commercially beneficial activities for the least toil.
A strategy is a short statement from which you can derive regular plans in different contexts. It’s about:
What angles we choose to focus on?
What the theory of winning is?
What capabilities we will need?
What management systems we will need to support that?
Taken together it’s a statement of how you will win.
Every organization’s strategy will most likely be different. So, this post isn’t meant to be a statement of a perfect security program strategy for you, or even a good one. What I’m going to cover are some aspects of strategy I’ve seen work in many organizations and use this to illustrate the difference between strategy and plans. You might find the following goals in a strategy:
Risk Transparency and Fast Feedback. We will make sure all accountable leaders in all areas have a clear picture of the level of mitigation of the security risks in their function, product or service and what residual risks (and possibly impact) remain. We will adopt an attitude of “escalation as a service” to senior leaders. This will create demand pull from them for more controls and more help from the security team. Success will come when people are pulling from security not security always having to push for outcomes. Risk transparency will operate in a very fast feedback loop so people can see immediate benefit from their new mitigating actions, or see new risks to handle. Remember, if you are living with long feedback loops then that’s a choice. You can do work to adjust feedback loops, obtain earlier signals and adopt many other techniques to get faster feedback to all teams.
Raise the Baseline by Reducing the Cost of Control. We will target controls to our most critical services and assets according to the likeliest threats. We will then actively work to reduce the total cost of ownership (CapEx, OpEx, etc.) of those controls so we can get more out of our budget and make those initially expensive controls more deployable to more places. Then with that budget we can progressively deploy more controls to more places. This approach will be necessary to cost effectively provide supply to meet the demands created from risk transparency.
Architect to Defeat Whole Classes of Attacks. We will constantly look at threats, vulnerabilities, incidents, and close-calls as a driver to define new control architectures that impose cost on attackers by eliminating whole classes of issues. We will place a small number of annual (or in some cases multi-year) big bets to constantly transform our approach.
Make the Secure Path the Easiest Path - Shift Down and Shift Left. We will use secure by design and secure by default approaches throughout our infrastructure, application, data and service stacks. This will be to ensure that in the absence of decisions to the contrary we will default to security as part of the tools and processes people use. Shift down to use controls by default in underlying platforms, like cloud, as well as shifting left.
10X Workforce Productivity. We will increase the security productivity of all our workforce - from end users, IT teams and the security team itself. This will involve rearchitecting work for toil reduction not just by automation.
Continuous Control Monitoring. We will treat, and thus aim to avoid, breaks in expected controls as first class incidents - at least as serious as security incidents.
Focus on Risks to Commercial Objectives - Seek Commercial Benefits. We will center our risk assessments on potential impact to vital business objectives not purely on potential monetary losses. For example, if a potential risk could lose $10M and also have a 10% probability of impacting a business objective, but another risk could lose $1M and also have a 90% probability of impacting a vital business objective then - given a choice - we would mitigate the latter first. We will constantly improve controls, beyond just their ability to mitigate risk, to deliver commercial (or wider mission) benefits e.g. reduce customer friction, deliver business outcomes, increase market accessibility.
Now, having the basic strategy you can take each of one of these and in each planning period determine what actions need to be taken to deliver on that strategy. You also need to look at what capabilities and management systems are needed to support that.
Let’s use the first item on this list as an example:
To do this you’re going to need a committed plan to create, or otherwise iteratively improve the following:
A risk register and regular re-assessment approach.
A defined risk universe that enumerates units of measure i.e. are you going to score by division, department, function, products, service or other approach. You might start coarse and then year by year get more fine grained.
A risk governance apparatus at departmental or product level with overall Board and executive leadership oversight.
A set of measurement and metrics capabilities (systems and tools) to deliver on the goal of fast feedback.
A risk escalation process including standard risk cards (uniform templates to reduce the effort for executives to comprehend complex issues), issue management systems, and thematic analysis.
Process gates for certain key activities like launches, vendor onboarding, or significant changes which could trigger risk (re-)measurement and adjustment.
An end to end systems quality oversight process to make sure all this is effective and working.
An incident learning process for when incidents (security, control or otherwise) occur to check if the measured risk posture predicted that.
The list could go on, but you see the point. Take each of the strategy statements and use it to drive planning and constantly look to see if you are both living up to the goal and that the goal is proving to be effective - ultimately if it's meeting your "theory of winning".
Bottom line: planning is not strategy. Strategy is something entirely different. It’s your coherent theory of how to win. While this should be consistent over time, it’s never entirely static and so should be regularly reviewed. Plans, actions, capabilities and systems should be delivered to meet the strategy.