Let's explore the difference between a programme and a framework.  

There are many definitions I’m sure, and I could be found guilty of using the two terms interchangeably. But personally, and for the sake of this series, let’s define them roughly as follows: 

A security programme is the body of work defining what security professionals do in our service to the organisation (our strategy).  

The security framework is the structure needed to document, define, and organise that body of work. 

The “document” and “define” parts are particularly important. They don’t just apply to security operations (where many security functions stop), but also provide written guidelines and agreements for our interactions with other parts of the business, including activities and standards they must do and adhere to. 

Going beyond pre-defined industry security standards 

I want to clarify that my concept of a security framework is not implementing ISO 27001, NIST, or any similar third-party compliance standard.  

Our highest obligation of compliance is to what we have defined as the ideal state for our business. Only afterwards should we map what we do back to third-party standards. You’ll see that this mapping is covered as a part of the framework I will be demonstrating in this series. 

For me, a framework is a structured container containing all the elements of a programme designed to meet the specific security needs of our organisation and its specific business processes. 

Note that I didn’t say IT or infrastructure. Those are merely elements that support our organisation’s business processes. We must focus on business process first. This will naturally lead us to the supporting elements which include technology ones. 

I first started building frameworks like this about ten years ago with the goal of overcoming a number of problems I saw in the delivery of work by security teams.  

There were plenty of policies, processes, tasks, and tools, but their application and execution always seemed to be, if I’m being kind, “a bit messy”.  

And messy leads to gaps that let bad things happen. 

Accepting these issues is a bit like putting your precious tropical fish in an aquarium that “only” has a few small cracks and holes. You may as well just dump them on the floor because the result will be the same. 

Another point of concern was that a lot of the work I was seeing was siloed within the security department, which is not where most security issues originate, meaning there was little chance to reduce risk in any kind of sustainable way.  

Adding to this concern was the fact that there was little proactive effort invested in making sure there was visibility, awareness, and influence across the business. 

What good security looks like 

Part of what a security programme should deliver is a foundation of integrity onto which we can build, but they rarely do. Because of the above isolation of activities to the security silo, instead of a solid IT foundation (and business process), many try to “layer on” security too late in the game.  

This forced effort to mitigate and manage risks (often only from a technical perspective), rather than reducing the amount of unnecessary and preventable risks the business generates, is the reason behind so many of the security failures I’ve seen. 

I had made a list of some of the key issues I saw at the time, around why I felt most programmes failed to deliver: 

• A lack of general organisation. 
• Tick-box implementations of individual technologies without further consideration. 
• A lack of detail in processes and policies. 
• No systematic and holistic approach in documenting operations. 
• No clear scheduling of activities. 
• An inability to consistently enforce processes. 
• Loose and scattered pieces of documentation (policies, processes, standards, etc.) with no inventory. 
• Leaving many IT processes with heavy security impacts up to IT with no review of their efficacy. 
• A tendency for processes not being well aligned to each other due to their being created in a vacuum. 
• Process/work duplication due to a lack of integration. 
• Process outputs not feeding into other processes and various registries consequently going out of sync. 
• References to documents and policies no one can locate because they weren’t considered and updated in conjunction with the documents referencing them. 
• Documents often out of date. 
• Documents in conflict with each other (even if in small ways) because they come from different sources or were written under different contexts without considering the big picture. 
• Etc… 

As mentioned, the above list was from about ten years ago. While I think it still highlights many valid points, it also highlights my own lack of thought maturity at the time. 

You may have noticed the strong IT focus. For example, If I were to do it over again today, I would change, “Leaving many IT processes with heavy security impacts up to IT with no review of their efficacy.”  

With/to: 

“Leaving many business processes with heavy security impacts up to other departments with no review of their efficacy.” 

Basically, I’d rescope all of these to focus on the business process(es) and not just IT as I did back then. 

It’s also worth noting the implementation of the first framework I built was an abysmal failure. 

The reason being that, on my list of key issues, I missed a massive one: the support of senior management. Getting that support would require defining it, creating a mandate to justify it, and then learning to communicate and sell it. 

And that was when all I wanted to do was effect change in how IT operated, let alone the whole business like I do today! Capturing this executive engagement is literally the top of my programme structure, but first we need to look at what that structure looks like.  

Join us for the next instalment where we will go over exactly that.