Approve the change

- [Instructor] Now that you have a change request in with all the necessary information, you need to get it reviewed and approved. Your process needs to designate who's going to be the referee that starts the race. Of course, routine changes, as we've discussed, don't need approval. That's the best case. So let's talk about how to best set up approvals for emergency and normal changes. Emergency changes need to be made quickly, but they're risky and all the riskier because they're being made under pressure. So they do need review, but the best reviewer is someone else with in-depth knowledge of the systems in question. Remember, there's no requirement in any compliance regime that someone approving a change be in an upper management position. A process that states another engineer must review and sign off on change works fine. When I worked at a cyber security company, our emergency change management process was integrated with our incident management process. Two engineers would be in chat during an incident. One would say, "I believe I need to make change X for this reason to restore service." The second would review that proposal and either give feedback or say, "I concur." Immediately and document their agreement in a ticket comment. Done. Fast, but with high quality and good traceability. Of course, the other way to dispense with emergency changes is to turn them into routine changes. Logging onto a customer system, looking at the logs and restarting it could be an emergency change, or if you have a centralized system with good role-based access control and you can just click to download logs and restart the system, it can be a routine change and not need additional approval since it's being performed by a safe, reviewed, automated process. This is even faster with higher quality and guaranteed traceability. At that same cybersecurity company, we did a lot of this with runbook automation using a runbook automation tool called Rundeck, available in commercial or open source versions. We had all kinds of standard system rebuilds, restarts, backups, and such built into it as code. We resolved many incidents without requiring an actual emergency change request as a result. As we move to talk about standard changes, the same thing applies. If a change can be turned into a routine, reviewed automated process, it doesn't have to be a separately approved change. But let's say it can, here's where you need additional approval, but how much? This is effectively based on the risk appetite of your company and the trust it has in the technical staff. Again, there's no compliance rule anywhere saying you have to have a director or above approval or a whole change advisory board. These are that companies do because they believe it's enhancing the safety of their changes. But of course, if these structures are too slow and impede needed changes, they compromise safety instead. One thing you can do to finesse this is to have risk categories of your change that determine what level of approval you need. Usually minor and major is enough. A minor change might be fine with a single manager, or senior technologist reviewing it and signing off. A major change to a critical corporate system might require a panel to review it. You may want multiple reviewers from either a technical point of view, if there's an owner of or expert in the system that has valuable oversight, or from a business point of view if there are other stakeholders who need to approve a change from more of a user change or scheduling perspective. Negotiating who needs to approve major changes in your organization is left as an exercise for the viewer. But don't confuse approval with communication. Many times, additional approvals get installed into a system when someone important feels like they're not being appropriately informed of changes. Similarly, don't confuse change approval with participation earlier in the development of a change. Usually, no, your security team doesn't need to be a change approver. They need to instead be working with the teams making changes earlier in the process so that the change was already evaluated for security prior to it reaching the end of the pipeline. Blocking a change once it's ready to be made is the most expensive option. If a lot of people feel like they need to be approving changes, figure out how to plug them into the process in a constructive, not obstructive way. Consider creating a RACI model for each system or service. RACI stands for responsible, accountable, consulted, informed. The responsible party is the one making the change. Accountable parties approve, but the best case here is just one. Others usually should be either informed or consulted as part of the change preparation. But too many approvers is usually a sign of dysfunction in an attempt to spread around or cloud real accountability.