Control of the Week #14 – Change Process
This week’s control involves implementing changes in your system environments. Jose Costa (CISO at Tugboat Logic), Harpreet Shergill (Senior Manager, IS Risk & Compliance at Tugboat Logic), Jitendra Juthani (Senior Manager, IS Risk & Compliance), and Chika Nwajagu (Senior Security Analyst at Tugboat Logic) explain why your change process is vital to your audit.
Why this control is important
CM5 – Change Documentation and Approval – Changes to the application(s) and supporting infrastructure are documented, tested and approved by authorized personnel prior to implementation into the production environment in accordance with the change management process.
Last control of the week we discussed Change Management and the importance of having a formal process documented for the changes you make to your organization’s environments. Little did you know, we can go deeper.
This control assumes you have a formal change management process in place, and instead focuses on the documentation, testing and approval for any change before it gets introduced to an organization’s production environment. This will cover the final steps in the change lifecycle starting from documented “Request for Change”, “Testing”, followed by “Approval” before actual implementation, and keeping records of everything that happened.
Documentation during the Change implementation process is critical not only for knowing what changes were made for the purpose of impact assessments, but it will help your internal teams to understand what work has been done and what testing needs to be completed. Having clear records of the steps taken to implement changes will not only help you if issues arise. It will also help your team reach the right people or access the right systems to test and coordinate with the people responsible for the changes.
The key thing is being able to demonstrate you are doing all the steps required as part of the formal change management process. Some organizations go through this process informally, so all the changes are not always documented (a complete non-compliance to this control). The challenge is often around “what changes should be done next.” Changes happen all over the place, so you need to make sure you know what the process is to be able to organize it!
How to implement this control for your audits
Your formal Change Management Process will guide you through the planning and implementation of your changes. Documentation and approval need to cover all the changes in terms of software, enhancements, applications and any other systems or elements the changes will involve or touch.
A change request document, in itself, is a formal document that allows you to capture how business or technical changes impact the existing implementation of a project. The documentation for the changes (“Request for Change”) you make should include, at a minimum:
- Change description
- Requestor Details
- Reason for the change
- Impact or risk of the change
- Timeline or “window” for the change
- Implementation and testing plan
- Proposed action to be taken
- A blackout plan (a contingency plan in case the change fails in the production environment)
- Status of the change (approval block)
One way or another, all changes need to be documented. When auditors come for testing, they will ask for a list or a log of changes. They will want to know how many changes have been implemented or planned, and whether more have been requested or considered.
Depending on the size and scope of the changes you will be making, you need to determine if you will have a simple solution of manually tracking changes in a change log or spreadsheet, or whether you want to use a ticketing or automated tool such as ServiceNow. There are also code repositories that can be used such as Github.
Once you have a system for tracking in place and request for change is authorized, the cycle is testing, approval for implementation and the actual implementation. One thing to remember however…
**Never ever do your testing in a production environment.**
All testing should be done in a staging environment until the final product is ready to be put into production. Test the changes with your developers, quality assurance and end users. Ensure that it meets acceptance criteria before pushing the changes live.
Auditors will take a look to see if they can find all the changes that were made in a system and whether test plans and test records exist for each one. This can be a tricky control for organizations that may make quick changes and not consider the testing as part of the process. As redundant and tedious as it may seem, recording changes properly will save you tons of time and headaches in the long-run.
Last but not least, changes are required to be formally approved before actual implementation into the production environment. This approval needs to occur before implementation and is being done either via a Change Advisory Board (CAB) or by the change manager. There are three main open questions at this moment:
- Are there any technical red flags based on impact and testing results
- Has the change been properly communicated (including to the business)
- Has the change process been followed
Again, these approvals need to be formally recorded and retained for audit purposes.