This blog walks cybersecurity professionals through the logical steps to create a practical and actionable cybersecurity strategy.
You must clearly outline what actions you are going to take, and over what time period, to make your Cybersecurity Strategy real.
The success of your strategy rests totally on its practical operationalization. Not only must you be able to clearly articulate what actions you will take to accomplish the strategy (i.e., your Objectives and Key Results – See “Step Seven – But What Will It Do?”), you must outline the tasks, projects, initiatives and programs in a digestible timeline – your Roadmap. And that Roadmap must include what it will take to get there (e.g., costs, resources, time, etc.)
When working to define and build your Roadmap, here are a few things to consider.
Start with the Objectives as Your Guide
You may recall we discussed setting up your Objectives and Key Results in “Step Seven – But What Will It Do?”. This should easily provide you your blueprint for the roadmap. One of the primary recommendations to follow from Step Seven was to lay out the Key Results in a way that would accomplish the Objectives. Remember, each Key Result should outline a required task, project, initiative or program. So, the next step is to lay out the order in which these activities will be implemented (i.e., your timeline). Each Objective should have its own set of activities laid out in a logical timeline that tells the story of how that Objective will be accomplished.
The key benefit of laying out your Roadmap timeline aligned with your Objectives is that it provides a tangible picture of how and over what time each Objective of your Cybersecurity Strategy will be realized.
It’s in the Details
Laying out a logical timeline of activities is only one part of the Roadmap; there are a lot of other things to define that will go toward making the Roadmap more practical and valuable. The roadmap must be looked to as a north star for the operationalization of the cybersecurity strategy. As such, there are a lot of details that must be incorporated to give it optimal value. These include the following:
- Duration of the Key Activities – This should go without saying but it is imperative to estimate the projected duration of each of the tasks, projects, initiatives and programs. At this stage, it doesn’t have to be down to the last second; this is a reasonable projected estimate for budgeting purposes. For example, have three ranges for the activities (e.g., less that three months, between three and six months, or greater than six months, or whatever works for your environment).
- Complexity and Resource Requirements – Is the particular task, project, initiative or program a quick job that can be done by a single person or is it a monolithic affair requiring a team of experts for months on end? Something in between? Again, keep in mind that this is a reasonable projection. You can estimate complexity in terms of what you anticipate it will take technically and operationally (e.g., Low, Medium, and High) and how many resources you estimate it will take to get it done (e.g., less than 3 resources, between 3 and 10 resources or more that 10 resources or whatever works for your environment).
When discussing the matter of technical and operational “Complexity” for a proposed action, there are a number of possible contributing factors. From the technical standpoint for example, is this a simple re-configuration of an existing solution, or does the action entail the deployment of an entirely new security system for example. Does the proposed action include a lot of moving parts? From an operational standpoint, does the proposed action merely require your existing team members to execute using existing processes and procedures? Or does the action entail the re-envisioning of your operational model? Or even a re-organization of a department (e.g., a consolidation of teams, formation of a new team) for example?
- Costs – This projection would take the previous factors into account to estimate – at a very high level – what it will cost to get the job done. Again, don’t go down to nickels and dimes; use ranges (e.g., less that $100K, between $100K and $500K or greater than $500K or whatever works for your environment).
- Metrics – When we discussed Objectives and Key Results in Step Seven, we mentioned the importance of ensuring the Key Results (i.e., the tasks, projects, initiatives and programs in your Roadmap) were measurable. Determining measurements for your Key Results were premature at that stage. The Key Results are now translated to tangible activities and it is here that we must work them out. Metrics are a key element to determining success and it is important to keep in mind that the determination of effective metrics require a great deal of collaborative discussion and agreement on what success looks like (e.g., “100% of privileged human identities are identified and under full governance.”, “Migrate all 3rd-party developers to a secure virtual desktop environment within 6 months.”, “Enroll at least 80% of laptops in MDM by the end of the calendar year.”, etc.). Therefore, this is something that should be done with other colleagues, key decision makers and stakeholders.
When outlined properly, your Roadmap will provide a rich set of details for stakeholders to understand what it will take to operationalize your Cybersecurity Strategy and what benefits it will provide the organization.
But there are two additional very important items to consider.
Priorities and Risk Statements
Regardless of how awesome the Roadmap ends up looking or how compelling a story it tells, you have to be realistic about the fact that not all of the proposed activities may be approved. So, it is critical to do two things to allow for a more clear choice of what parts of the Roadmap should be considered above others:
Prioritization – It is important to place a priority on each task, project, initiative or program in the Roadmap. This may typically be within their Objective “family”. Similarly, it is important to prioritize the Objectives so that, if the entire Roadmap is not economically feasible or viable, you can trim the Roadmap by Objective, rather than by individual actions.
Risk Statements – As important as it is to outline the benefits the component tasks, projects, initiatives or programs within a Roadmap will have, it is perhaps equally important to articulate the risk of any of these not being executed. Each activity in the Roadmap should have a well thought-out Risk Statement outlining what the organization is risking by not going through with it. It is preferable to make the Risk Statement objective (i.e., in terms of cost to the organization) if possible. However, a subjective risk statement is better than none at all.
When developing your Roadmap and its component activities, be conscious of the practicality of the timeline and how long it takes to deliver results. Be realistic about what you can get done – either with your own resources or with the help contractors. And, even if you had adequate resources, be realistic about the amount of change the organization can – or is willing to – absorb. Technical and operational changes can be jarring if they’re too radical or done too quickly.
Also, when estimating such things as complexity and cost, don’t be afraid to get outside perspectives and advice. Remember that you’re not in this alone. And that is a good segue to …
It Takes a Village
Just as with almost every other aspect of the Cybersecurity Strategy, many hands make light work. Be sure to bring in other experts from within or outside of the organization to aid in the development of the Roadmap. Lean on Key Decision Makers and Stakeholders when looking for that reality check on the Roadmap’s details. As always, whenever you involve others in the process, their engagement and buy-in will be all the greater.
Thank you for your time. Be sure to stay tuned for the next posting in this series: Cybersecurity Strategy Step Ten – It’s All About the Journey (Keeping the Strategy Relevant).
Special thanks to Karel Beukes for his very valuable contributions to this post.