As previously discussed, 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.)
2. Externally Initiated Changes – Changes that are initiated from entities outside the company – typically by a client (i.e., software fixes, unscheduled security patches, requests from customers, customizations, etc.) What this post covers!
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.
1. The risk of fraud or security breaches due to lack of testing and/or approval of changes.
2. The risk of system downtime and/or application 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.
4. The risk of reputation damage or legal action due to damaging a client’s application or production environment.
5. The risk of client data breach due to lack of security in the testing environment or during software implementation.
Externally Initiated Changes and the Control Environment
Below is an example of a standard change management workflow and associated controls for externally (client) initiated changes.
Graphic by Christian Hyatt. Please do not use without permission.
Notes of Interest
1. Note the hand off of the source code package from the development team to the implementation team. As compared to internally initiated changes
, there is almost always a more defined package hand-off or segregated implementation process when implementing software to a client’s environment.
2. Note that client production data (data that may contain real data, including private data) is often used in testing environments. If this is the case the test environment (test servers and databases) should be treated with the same level of security as the live site.