We’ve finally reached the end of our series aimed at helping you build effective security programmes.   

In this final instalment, we look at a part, or area, of our sample framework that I’ve called Business Stubs.  

The Business Stubs “domain” isn’t really a domain like the others. In many ways it’s more a repository, or a linking point for other departments’ processes. 

Other departments should be able to access any relevant part of our framework documentation to ensure they know the security standards and processes we have defined. That’s just common sense! 

But we, as the security team, also need visibility of other departments’ business processes if we’re to understand what needs protecting, mitigating, and improving.  

The Business Stubs portion of the framework is a space where we can store or link to other departments’ processes, inventories, etc. We can potentially even have automatic alerts to any changes in other departments’ processes. 

I recommend structuring this section as folders; one per department, with subfolders for different functions within each. You may want to capture a mandate for other departments to store their processes here (or any other defined repository we can link to) as part of your Executive Charter, which we discussed at the start of this series. 

(You should ideally have a standardised way of storing business processes, like Confluence for example, that allows for easy interconnection/visibility of processes across departments.) 

While this part of the framework may seem superfluous to some, it’s there for a good reason. Holistic coverage is key for an effective security posture, and it’s incredibly easy for more obscure business processes to go unseen by us.  

There have been many breaches involving significant amounts of sensitive data due to processes, systems, and tools that had escaped the attention of the security department. 

It also saves the respective department a whole lot of time answering questions from us, if we have a copy of their processes that we can review by ourselves. 

What we learn about the business through understanding how other departments operate (and what data, systems, and revenue streams are involved) should always be in the back of our minds when we define our security processes and programme. 

Finally, when do we find issues, having this (hopefully shared) repository creates an easier way to collaborate around adjusting processes to minimise business risk. 

That’s all for this final part of the framework, which could be implemented in many different ways as long as it achieves the desired outcome of visibility and co-operation.  

And that means we’ve reached the end of this series outlining just one possible, and potentially unorthodox, way to structure a security programme which has served me well. 

Is it perfect? No. I keep adapting and improving it to best reflect different organisations and my own knowledge. In fact, I change it continuously as my experience grows and the organisations I serve change. 

Could there be a fundamentally better, completely different way of doing it? Quite likely! 

The most important point of all is to have a framework; one that houses a programme that supports a strategy to improve your business, rather than just scaling-up operational security work. 

Do it any way you want, so long as there are real and sustainable outcomes in terms of improving the security of your organisation. 

Keep progressing, thinking, innovating, and not being afraid of trying something different. 

No matter what your framework looks like, your ability to determine the optimal strategy and build and execute a programme to deliver it successfully will come down to the same things: Your understanding of your organisation and your leadership skills. 

As always, feel free to get in touch. 

Good luck and goodbye for now!