Maksim Kabakou - Fotolia
While the basics around change management are clear – to have and follow a process – the problems are always in the implementation, which are getting worse as infrastructure and IT is outsourced or moved to the cloud and mobile devices become an ever larger part of the estate.
We need to tackle this problem from two angles. The first is when the organisation still does the changes itself – think server upgrades. The second is where change is applied externally to the organisation – think cloud or app upgrades.
In the first case, the organisation should have a documented approach to change. If there isn’t one, start with the Information Technology Infrastructure Library (ITIL) approach.
Appoint a senior manager, perhaps even the head of a function or a C-level executive, as the owner of the approach and the chair of change meetings. More importantly, ring-fence their participation – they have to be there.
You then need to identify the people and functions who should be at any change meeting and set out their roles and objectives, regardless of whether they come from inside the organisation or the supplier community.
Define the frequency, the agenda and paperwork required for decision-making. All changes should state business benefits, impact, cost, priority and plan.
Informal discussions between the various functions should be encouraged too. For example, cross-post security staff into the development team to gain a much better insight into why changes are required and how they are implemented, or social media can be used to encourage discussion of changes and effects before they go to the change meeting. Reward collaboration, even if it is just a thank you and to tell people about it.
The second case may provide additional problems, as the nature and timing of the change is not under the control of the organisation. However, the change meeting will still provide a mechanism for collaboration, and this can be supplemented by actively working with suppliers to understand their release schedules.
Of course, in certain cases, such as cloud or device upgrades, the upgrade is a “done deal” – here, the change meeting can still provide value by understanding how the change affects the overall infrastructure of the organisation and its security posture and promote collaboration.
Overall, security will almost always be one of the functional requirements in a change. The challenge is to secure recognition for this requirement so that the security perspective is included right from the start through to implementation, regardless of the nature of the change.