Any significant challenge is more easily faced when broken into a smaller set of steps–taxes, cleaning the house, reorganizing the garage. In business, it is no different. With IT and cybersecurity governance, it is necessary, and taking an iterative approach can be very effective.
Iterations enable your company’s management to roll out tolerable and achievable requirements yet also provide IT and cybersecurity staff with the capacity to exercise necessary governance procedures and provide feedback on tools needed, what is possible and why. This cyclical feedback structure keeps governance requirements realistic – with all parties aware of their obligations. The pace of governance activities also allows your enterprise to mature its governance in parallel with the growth of your business so that the rigor of governance may be supported by sufficient staff, funding, and processes that can be replicated and ultimately standardized.
Working with the Director of IT at a client with a growing IT function, CREO outlined one of the basic requirements of software maintenance – software patching. At the outset of our assignment, CREO drafted a consolidated IT and cybersecurity policy with the addition of a policy statement that, among other things, required that all software patches are to be applied within 30 days of vendor release. Doing this helped our client take its first step towards IT governance.
Six months later, we returned to help our client take its second step in IT governance – to expand its initial policy on patch management. Finally, management was ready to apply a few more requirements of this activity, and IT engineering was prepared to provide some feedback, having lived under the initial policy for several months.
CREO put a basic structure on the whiteboard citing “Policy” as a top priority. We wrote the existing policy statement, “All software patches are to be applied within 60 days of vendor release.” (The IT team had proven that waiting 60 days instead of 30 would avoid some buggy patches.) After policy, “procedure” was the next priority and would be quite different for each type of technology in the infrastructure. We took time to guide the client through exercises that helped them focus on what was required from the procedure and how prescriptive it needed to be.
The next priority was “Control,” which describes the client’s requirements from the procedure. Control elements ensure that the procedure is effective, is followed by staff, and is not overly disruptive to the team and the user community. For Control, we developed an approach that mandated patches are to be tested on a small, low-priority portion of the enterprise population of the same type of technology. We guided the client through developing other control elements, such as test procedures and corresponding acceptable test results to be documented and maintained. A patch is not implemented into production less than two days following its implementation into the test environment without being classified as an emergency change and handled as such.
The next priority was “Metrics,” which are success metrics or key performance indicators to ensure that the process is functioning according to the requirements. We guided the client through developing key metrics that would quickly surface compliance issues. A few metrics developed included all vendor-released major patches to be applied within two calendar months of their release. All minor patches are to be applied within six months of their release. All patch exceptions are to be documented and approved by management.
Finally, we tackled “Reporting” as the last step. For reporting, we helped the client start with a basic reporting structure that included reporting on outstanding patches from each infrastructure management platform every six months with spot checks more frequently.
We completed this process walk-through in collaboration with the client’s IT staff under the leadership of CREO’s infrastructure engineers, who have significant experience in software patching and demonstrated how the application of patches could sometimes cause production issues. Involvement and collaboration between cybersecurity and the client’s IT staff ensured they understood their Playbook rationale and the overall importance of patch management as a cybersecurity governance tool.
The process of creating, documenting, and standardizing the use of a governing process hierarchy is what CREO calls a “playbook.”
For the client in this case study, the playbook CREO developed in collaboration with IT was in place for nine months. From that period forward, CREO and our client’s IT team was better positioned to be more proactive in its IT governance protocol.
Governance components that can be clearly defined and understood at each level–from management intent through procedure and reporting are most effective. Developing a standard governance process and “gated” priority structure also makes the completion of each area much more manageable. From our experience helping clients develop structured IT governance, we believe it is best to gate each priority within a hierarchical structure to ensure complete integrity with clear supporting documentation versus using a checklist which can often devolve into completing a form and filling in spaces.
