Defense
Managing Change (and releases)
This is an area that I think some might be interested in. I have worked with orgs of all shapes and sizes and one central area I find people struggle with is change management. I am not talking about organisational change management (that is another) but I am talking about the change of information systems or security controls.
Now you might be familiar with ITILv3/2011 and the PROCESS of change management or you might be in the new practise world of ITIL4 where it is called change enablement, or you might have no idea what I am rabbiting on about. That is ok that is why we are here!
The purpose of change management is (according to ITIL) to help minimise the risk of change for IT services.
In ITIL4 change enablement is freer but covers:
- Record
- Plan
- Approve
- Execute
- Review
A key concept in change management is that we need to be able to assess and categorise change and thus perform the appropriate due diligence to consider the risk and impact of a change.
Categories of change would normally include:
- Standard (Routine) which must be logged but have prior authorisation and approval
- Normal
- Major
- Emergency
Depending upon the change category the activities, flow and authorisation route may change. A good starting point is as follows:
Standard Changes
- Routine changes
- Create a standard change register
- Tickets are required to be raised but they are pre-approved
Normal Change
- A change where the Confidentiality, Integrity or Availability may be impacted or where there is significant change to architecture e.g., Upgrading of a component major version or overall configuration change e.g. a change to firewall rules
- Ticket Raised alongside change form competed
- CAB authorisation is required
Major Changes
- Major changes are high risk changes
- Detailed documentation should be provided for change evaluation
- CAB Approval is required
Emergency Change
- Emergency changes are as they say ‘an emergency’
- They can be retrospective
- They may be implemented in response to an incident
- They may use e-cab or single authorised individuals to approve
The high level processes
The general flow of change would look similar this the following:
Roles and Responsibilities
| Roles | Responsibility |
| Change Requester | The individual who has requested the change. |
| Change Advisory Board (CAB) | The team of people who will review, evaluate, and approve the change. |
| Change Manager | The person responsible for managing the change management process. A change facilitator is a good way of describing this. |
| Implementation Team | The individual or team responsible for enabling the change. |
Recording Changes
Howe we do this is up to us, but we could use a board with a change backlog and ensure we have a view on:
- The description of the change
- Change requestor
- An impact assessment statement
- A view on urgency, likelihood, impact, risk, and priority
- The change release schedule
So essentially log a ticket in an ITSM/Helpdesk of KanBan tool (something like Jira/MS DevOps/Trello etc.)
A quick-fire toolkit as a starting point to enable change management with low friction
All this paperwork and process you might be thinking. Well sure if you are going from NO paperwork to having a tracking system of course it is a bit different but let us look at things we can do to help:
- Get together and understand what good looks like for your organisation
- Agree change managemen principals. so you can formualte some policies (rules) to work with.
- Leverage industry good practises to help (ITIL etc.)
- Think about walking through a range of changes to see how this will work in practise.
- Assign an individual as the ‘Change Manager’
- Agree core CAB membership
- Create a register of all standard changes (this is useful in an automated DevOps/Agile world).
- Assess each for risk likelihood and impact and record this.
- Review these with the team to assess change and impact.
- Consider implementing a “No ticket, no change” policy.
- Setup whatever boards/tickets/dashboards you need in your tooling, ensure the team know how this is configured and will work.
- Use peer review where appropriate.
- Ensure people are communicated about the change process as well as ensuring changes themselves are well communicated.
- Agree and document change approval routes and specific people/roles that are required.
Great we now have a range of standard (pre-approved changes) and a view on what occurs for NORMAL, MAJOR and EMERGENCY changes.
CAB / E-CAB
- Form a change advisory board and setup a regular recurring meeting with the CAB members.
- Agree a change advisory board standard agenda and communication routing.
- Make change management use the tools at your disposal, consider video conferences, using ticket systems, kanban boards, colloboration spaces and workflows to record approval. Not every authorisation has to be in a meeting enviroment.
Change occurs all the time having a record and formal process should help not hinder
We manage risk and change in our everyday lives and with systems it’s not really much different. We have a range of risks, stakeholders and moving parts and we want to make sure our changes add value rather than create incidents or risks. Ensuring we management change and keep a good record of changes will help improve:
- Communication
- Value Realisation
- Remove bottlenecks
- Improve the customer experience
- Support incident management
- Mange risk
It can seem daunting to some if they have not formally managed change before but honestly build the process to meet your business requirements and see how change management can help you! Remmeber this can work in an agile and waterfall mode, just get going on making sure your automation and routine activities are understood and documented and you are already going to be in a better position.
Hope this helps introduce change management for those who are used to operating in a more lose manner without adding too much friction.
May the force be with you!
