The Change Management Process (a.k.a CMLC) is one of the most vital processes for any IT Auditor or Security professional to understand when assessing an organization’s risk universe. In general, there are three key change management life cycles that exist within most organizations:

1. Internally Initiated Changes – Changes that are internally initiated and controlled (i.e., periodic software updates, scheduled patches, request from employees, etc.) What this post covers!

2. Externally Initiated Changes – Changes that are initiated from entities outside the company (i.e., software fixes, unscheduled security patches, requests from customers, customizations, etc.)

3. Infrastructure Changes – Changes to hardware and infrastructure (i.e., servers, computers, firewalls, etc.)

It is important to understand that each of these three processes may follow very different paths during the Change Management Life Cycle and present very different risks to the organization.

Risk Statements
1. The risk that changes to systems result in fraud or security breaches due to lack of testing and/or approval.
2. The risk of system downtime, operational failures due to invalid system changes.
3. The inability to perform data bench-marking and root-cause analysis due to not tracking or documenting changes.


Internally Initiated Changes and the Control Environment

Below is an example of a standard change management workflow and associated controls for internally initiated changes.

Graphic by Christian Hyatt. No use without credit.

Graphic by Christian Hyatt. No use without permission.

 Mitigation Strategies

Note: Updated 11/25/2014 from questions in comments.

Some small development teams do not have the staff to sufficiently enforce SoD so there are a variety of options that may mitigate the risks.

We’ll take the example of a developer having access to production:

1. Implement an alert system that alerts management and the development team any time there is a change implemented to production.
2. Implement a log and periodic review of changes implemented to production. The review should be frequent – such as weekly.
3. Implement a peer implementation system where a developer is never implementing their own work. This is enforced by policy and procedure and should be documented in the change management documentation for each change.
4. Consider requiring the developer packaging up the change and letting a manager “press the button” to implement into production. This allows the developer to do the technical “heavy-lifting” without having access to manipulate production or implement without approval.