I am often surprised when I hear something like this from an auditor:

“Wow, your Information Security Strategy document lays out your approach well – I really understand what you are doing.”

Their surprise is what surprises me.  Obviously, they are not reviewing strategy documents often enough.

To be clear, almost no audit document request list ever asks me to produce my strategy – policies and procedures surely – but not my strategy.  It is for this reason, I think a written strategy is an undervalued artifact.  But as an information security leader, it is likely the most important document you can create – as creating and executing on strategy is your primary function.

Defining Your Strategy

First, it is import to compare and differentiate a strategy document from policies or procedures.

Policies lay out goals and objectives, and are often fairly high level.  Ideally, policies are some of the most enduring documents within an organization – meaning they are not expected to often materially change, and commonly see brevity as a value.   Policies should delegate to a strategy or program document the dynamic and changing approaches to achieving these goals. Ideally, policies should avoid naming specific products or solutions – as these should be responsive to the current environment.

Procedures are highly tactical documents that detail operational expectations.  Their primary stakeholders, and most likely authors are technical staff.  These documents seek to support organizational memory. They define the approved methods of execution and illustrate the appropriate use the tools and/or processes deployed within an organization (i.e. run books).  Here, products are more than just named, it would not be uncommon to see screen shots, network diagrams and commands used to operate them correctly within the environment. Lastly, procedures are usually tightly scoped, detailing a specific function or tool – and need to be reviewed and updated frequently (to account for upgrades and system changes).

Between them is your Strategy – your plan of attack to achieve your goals.  No one should have to divine this plan as the white space between your policy statements and the staff’s procedures. Strategy should be distinct, clearly documented and reviewable.  While strategy needs to be responsive, and may be adjusted more frequently than policy – they should be more durable than procedures. Critically, strategy is exactly what our stakeholders really want to understand, and need to support.

For example, a policy may set the goal of protecting the confidentiality, integrity and accessibility of the organizations information assets, and/or complying with a regulatory or similar mandate.  A strategy may establish:

1. Alignment to a cybersecurity framework which the organization adopts
2. The protective concepts implemented, such as Defense in Depth and/or Zero Trust
3. The organizations detection and response capabilities, and security operations “service levels” like mean time to respond
4. The testing program for validation, defining the expected cadence and scope of internal and external assessments

Unlike a policy, a strategy document can name and describe specific solutions or partners, and their role and “fit” within the environment.

As an example, this diagram excerpted from a strategy document, which illustrates Defense in Depth, would not serve an engineer, but illustrates the role and risk surface protected by various security tools (especially to non-technical stakeholders):

The strategy document can then proceed to explain the vendors \ solutions used for each function – with a brief description of what the tools can can block, detect or alert upon.  This digestible understanding of a security stack is often the missing component for our executive stakeholders and peers – a cause of uncertainty and unease.

A strategy document can also assist cybersecurity leaders in explaining their budgets – where and why resources are deployed, and where gaps may exist that require investment.

The diagram above is often the “Aha!” moment for many reviewers – they begin to understand how these tools work together to achieve policy goals.

Conclusion

I try not to overly militarize my cybersecurity language – but it is very easy to see cybersecurity leaders as “Generals” – our technical staff are our troops, and our executive sponsors are our leaders.  We are given objectives, and both our troops and our leadership trust us to create the plan off attack to achieve those goals. Communicating this strategy, and getting buy in and support from these stakeholders is in fact, our primary function.

Where this analogy seems to breakdown, is that within the enterprise, these stakeholders may not know to specifically request this plan from us. Yet it is likely the most valuable deliverable we can produce – more than worthy of our focus and attention.