Welcome back to our series on building an effective security programme. Today we’ll touch on the first part of our framework: The Executive. 

This section, or “domain”, in our sample security framework is, in many ways, the most straightforward to create, but also potentially the most important. And while it’s the first thing I think people should do, it’s also one that requires significant insight and experience. 

In short, it defines and obtains management support for our mandate, proposes the strategy and programme, and defines our authority. 

For me it usually contains two documents. They work together and could be one document, but I usually separate them - mostly for ease of presentation purposes.  

The first is the Executive Charter. It states our mandate, captures the acceptance and support needed for our strategy and programme, and gets management sign-off for us to deliver it. 

The second I call the Security Strategy Overview. It’s an explanation of our strategy, the benefits to the business, and how it will be delivered through our programme. 

It also defines what resources we need, the team we will need to deliver it (as well as the collaboration from other parts of the business), and a rough timeline on delivery (something like a three-year plan). 

These documents are critical to get the support and capability you need to be successful. 

You shouldn’t need to fight for buy-in and budget 

Many CISOs talk about fighting for more budget but if our goal is to altruistically help the organisation, financially, from risk, etc., then traction is a far more valuable commodity. Plus, traction will naturally bring with it the budget you need (though maybe not the one we would like). 

I often recount a dinner event with senior executives who, when asked why they funded their security functions, replied with “To make the security people go away.”  

The disconnect between business and security in many organisations is big, and worrying.

These documents, destined for your ExCo and Board, contain the answers they should have given to that question. 

Presenting them is also an opportunity to be seen. To demonstrate that you are business-minded, strategic, have a wealth of insights, know what you are doing, ‘speak their language’, and are focused on their goals. 

If you do this properly, I’ve found that they will support you in supporting them. That’s why it’s critical to get this right.  

If new in your role, I recommend first spending a few weeks to understand the business’ operations, strategy, and culture. Speak to different people, hear their complaints, get a feel for the different departments and stakeholders. 

Then, look at the current issues with a focus not on the operational work they create, but on their root causes. Foresee what challenges could arise in tackling these and then create a plan on how to best prevent and address them.  

Note that, while these root causes should be our primary focus as it’s the only thing that drives sustainable improvements, we must not neglect risk management; we should think of how to deliver it as optimally as possible where needed. 

I cannot reiterate this enough to most practitioners: Do not to be myopic about technology or get sucked into fixing technical problems because they appeal to you. Quite often their resolution isn’t what’s best for the business in terms of where effort could be spent. 

Only once you understand the business, people, problems, causes, strengths, challenges etc., can you formulate a strategy and build a programme that will drive lasting positive change.  

I cannot tell you how to do this. You are the best-placed person to understand what this should look like for your organisation. 

The Executive Charter 

What I can help you with is creating an Executive Charter that references your security strategy and programme.  

(By the way, the fact that my Executive Charters tend to remain largely the same between organisations while the Security Strategy can change dramatically, is another reason why I’ve split them as two documents in the Executive Domain of my frameworks.) 

The inspiration for an Executive Charter came to me about 15 years ago studying, when for my PMP certification.  

One of the Project Management Institute’s principles is that every project should have a Project Charter that defines the authority, resource, scope, budget and so forth for a given project. This is to prevent that project being deviated, encountering scope creep, being defunded, having timelines changed, etc. 

I saw clear benefits in such a charter, in terms of addressing a lot of the challenges I faced in delivering a holistic security function. 

The contents of the Executive Charters I’ve created since are mostly statements or directives, for which we need executive-level agreement and backing. 

I typically include the following ten: 

1 - Overall Responsibility: Here we state that senior management accepts overall responsibility for Information Security.

We then add that it is ultimately the responsibility of each team and department to ensure the security of its outputs with the guidance of the security function/team.  

This is likely to be where you first encounter some surprise that “security” won’t be sorting everything by itself, and your first opportunity to explain the concept and value proposition of “security through quality” (which I like to elaborate on in my Security Strategy document).  

2 - Mandate: We state that management delegates the above responsibility to the Information Security function, with a clear scope and appropriate responsibility. This is also a good place to dictate that the function will report to the ExCo and Board to ensure they have enough information to fulfil their obligations under the previous point.

3- Define Security Strategy: How will the security function deliver on its mandate?  

This is where we state that we will create and deliver an Information Security framework; encompassing a programme that will develop, disseminate, and enforce a cohesive set of processes and procedures, as well as implement technological security elements as needed.

Leave this at a high level and refer to the more tailored and detailed Security Strategy document we talked about earlier; we’ll go into more detail on that later 

4 - Authority: Here we state that management grants the CISO and security team the necessary authority to apply and enforce all elements of the framework/programme. Some organisations may have competing authorities; this is a good place to define hierarchies and priorities.  

5- Resources & Support: Here we clearly state that senior management shall provide all reasonably necessary resources for the implementation of the above framework. If you have any ideas on how you can get management to demonstrate their support (and stipulate everyone else’s expected support) to the organisation, this is a good place to put them. 

6 - Project Involvement: I like to mention this one specifically because it’s important to drive it through: we must be involved at the initial stages of projects to ensure a solid security foundation. So, let’s state that management will instruct all project leaders to involve security from initiation. And no, that’s not limited to IT projects. 

To avoid any issues with non-compliance to this directive, I like to include that management give explicit authority for the security function to request details on any aspect of any project at any time.  
 
We also stipulate that we shall be involved in any executive roadmaps, be able to impose security approval gates where necessary on projects, and give input into when they go live to ensure any risks have been acknowledged and, where appropriate, resolved. 
 
Note that, conversely, we can also grant individual teams the authority to proceed if we trust their processes to implement things securely. This often comes in time as the organisation’s security maturity grows; freeing up some of the security function’s time and resource. 

7 - Control Over Change: This directive should stipulate largely the same as above, but for any operational changes that could have security impacts. This can be through a Change Approval Board, but more streamlined and potentially automated solutions should be explored whenever possible.

8 - Security Exceptions: Here we state that we can be overruled. Let’s face it, some people will always try to go over our heads. Even the most security savvy businesses can have a valid need to override security standards and processes now and again.  

It’s important that we allow for this and make sure it’s done through a formal process. This adds not just accountability, but also predictability to exceptions, which allows us to make them less frequent. If we don’t set a clear path for these exceptions, they end up all over the place - unmanageable and often undocumented. 

I also like to present the concept of “Direct Visibility” here, meaning we must be able to directly see the systems in the environment, without being dependent on IT. There can be political, cultural, and other reasons for a true picture of security not being presented when asked. 

10 - Daily Operations (security-relevant): This is where we define who has responsibility for security-relevant daily operations (usually IT operations). This could be patching, backups, or any other activity associated with security or providing a foundation for security.  

It’s important for responsible parties to be identified and given the necessary resources, authority, and responsibility too. They should also be added as signatories to the charter attesting their acknowledgement. 

After all, our security processes and tooling cannot be trusted if they’re built on infrastructure and business processes that undermine their integrity. 

Do feel free to modify any of these. Split them, remove some, add more. Do whatever it takes to best cover the underlying challenges you anticipate in your organisation.  

This is why it’s so important to take the time to first get to know the organisation as thoroughly as possible before creating your charter. 

Many of these directives are in place to make our future framework/programme function properly. Only once you have a good idea of what your strategy is and what organisational, technical, cultural, and political problems you will face, will you be able to write the executive charter that will make success possible. 

As always, if you enjoyed this instalment and would like help in creating your information security programme, please reach out to us. 

Join us for our next instalment, where we’ll have a look at two more domains of our sample framework, covering how to manage the framework itself, and how to integrate important relevant processes from other departments.