If you are making changes—for example, to your website or to the scope of a project—it is important to implement a change control process.
This matters.
It might be both quick and easy to—for example—decide to replace one plugin with another in your WordPress implementation. However, the plugin may not work in your specific implementation, taking down your website. Then you’ll have to work out how to get back to where you were—was that documented? Do you know which version of software you were using? Where is that backup when you need it? During that time, your website is unavailable, potentially reducing your revenue.
Another example: it might seem straightforward to agree that although you said your project would deliver X, what is needed is X+Y, so that is what you’ll work on. However, X+Y is a change in scope: it will probably cost more to deliver and may not be aligned with the original objective. Not only that, but Y may add more security weaknesses than when delivering only X, so X+Y should be carefully considered before agreeing.
Often, people assume that change control is only relevant to software projects but change in other areas of your organisation should be controlled too. Uncontrolled changes—for example, to the process for signing-in visitors—may result in the implementation of conflicting processes across departments, which might have an adverse effect on security.
What does a change control process cover?
A change control process doesn’t need to be complicated, but it should be followed consistently and by everyone. It should cover:
- Logging the change request in a change log—details of the requested change, the date it was requested, and who asked for it.
- Initial triage. Is this change realistic? If implementing it would obviously be so expensive or out of scope as to make it impractical, then time spent on further investigation isn’t warranted. Document the outcome of this stage (proceed or reject) in the change log.
- Detailed consideration. What impact would this request have on other, related activities? What would it cost? How long would it take? What would the benefit be? Don’t forget to check for security implications.
At the end of this stage, the change log should be updated with the decision: approve, reject, or defer it while you gather more information. If the change is approved, the change log should be updated with details on who is responsible for making the change and by when.
And once you’ve made the change, don’t forget to update the documentation—policies, procedures, whatever needs to be updated—and to communicate the change.
How can we help with the cyber security issues that you face? Contact us on 0113 733 6230 or via our contact form.
