Welcome back to our series on building security programmes. A series we hope helps not only you better secure your organisation, but also highlights CDW’s commitment to help customers approach security holistically and effectively, with their unique business contexts in mind.
In this instalment we cover what I call the Programme Management domain.
I introduced this domain because I wanted to address the fact that most of the security programmes I encountered suffered from being scattered or lacking upkeep.
Even in the best cases, the continued management of operations, scope, and relevance was lacking, which resulted in parts of the business not being effectively protected.
Through some evolution, I typically include four components here:
The Programme Overview component presents the entire programme/framework structure and a full inventory of all its components. The idea is to have a full representation of all the components of the framework, which leaves nothing else out; and paints a complete picture.
It lists all documents in the programme, their purpose, when they were last reviewed or updated, an illustration of the framework, and a recap of the strategy and structure of the team and stakeholders charged with executing it.
This document is what I usually hand to auditors, along with the charter and strategy documents mentioned before, to explain what we are doing and why.
I used to worry that they’d find it unconventional, but I’ve been pleasantly surprised at auditors’ responses to the approach. Some have even asked if they could copy the template.
A little side story: In one organisation where security was several levels removed from the ExCo and Board, half the cover page on a report from our external auditors going to the board was about the promise presented by the programme via these documents.
At that point, the ExCo and Board didn’t even know that the programme or I existed. In fact, the CIO was resisting signing off on the programme, and I felt somewhat boxed in. However, the auditor mentioning it to the board created a great opportunity.
It wasn’t long before the board enquired, the security programme received the needed support, and I was on a first-name basis with the Chief Exec, who offered me a ride in their McLaren, which was nice.
The second component of this domain, the Continuous Improvement piece, defines how components (usually documents) are added, updated, and removed from the framework, the associated processes, frequency, how versioning is to be tracked, and so forth.
Its purpose is essentially to ensure the framework remains up to date, relevant, and efficient.
The third component, the Management System, defines just that. How we will manage the programme’s framework.
A decade ago, the framework would have been a collection of documents in a folder and sub-folders. Versioning would be done with folder hierarchy and file-naming conventions.
Nowadays, it’s far easier to build out the programme in something like Atlassian, where we can store all the documents in Confluence and schedules and workflows in Jira; allowing direct contributions, easy sharing, and much more. An area my colleague Jaro Tomik covers within CDW for knowledge management and Enterprise Service Management.
The final component, the Operations Schedule, is used to schedule all the operational elements. How often do you run your backups, your recovery tests, your incident response tabletop exercises, your vulnerability scans, and so on and so forth.
I used to have a huge spreadsheet to track all this but, as mentioned above, nowadays any number of planning and workflow solutions are a lot more powerful and flexible.
And that’s all for today on how I’ve come to manage security frameworks.
If you feel we can support you in any way with building or running your programme, please get in touch. We’d love to help.
Join us next time when we look at the importance of integrating important other parts of the business into our programme.