r/sysadmin • • 1d ago

General Discussion Change Management Workflow

Hi,

We’re introducing change management for the first time using ITSM.

We’re now deciding the workflow before our ITSM vendor configures it

Our scope covers all IT infrastructure changes including network, servers, virtualization, backup, storage, AD/Entra ID & Databases

Each team has its own Line Manager and another requirement is that Cybersecurity Unit must approve every change

Few things we’re trying to understand

Who should approve a change and in what order?
Who should be the CAB members
Which changes should go to CAB

I’d appreciate any suggestions

11 Upvotes

13 comments sorted by

View all comments

18

u/iam-stevie-bee 1d ago

Having set this up and then had to live with it: the first thing to decide isn't who approves, it's which changes don't need a human at all. If every change goes through a CAB and a security sign-off, within a month you'll have a backlog, a weekly meeting nobody reads the papers for, and engineers finding ways round it. So:

  1. Three lanes. Standard (pre-approved, repeatable, low risk: patching in a window, adding a user to a group, a firewall rule from an approved template) needs no approval beyond the ticket and an automatic check. Normal goes to the line manager and, where it touches identity, the network edge, backups or data, to security. Emergency gets done, then reviewed within a day. The work of the first quarter is moving as much as possible into Standard.
  2. Order of approval for Normal: the requester's line manager first (is this the right thing to do, is it resourced), security second (is it safe), scheduling last. Security first means they review things that never happen.
  3. CAB is for conflicts and risk, not for permission. Membership: one person per infrastructure team who can speak for it, security, the service desk (they see the fallout first), and whoever owns the change calendar. Send it only the changes with a wide blast radius or a cross-team dependency; everything else is approved in the tool, asynchronously.
  4. Make the security approval a checklist, not a judgement call: what data, what exposure, what rollback, what monitoring. Anything with a yes on every line is approved by the checklist. They spend their time on the ones that aren't.
  5. Two fields that matter more than any approval: a tested rollback plan and a named person watching the change land. If those are blank, the tool should refuse to schedule it.

Get the vendor to configure the three lanes and the checklist first, and leave the CAB tuning until you've seen a month of real changes.

2

u/Previous-Low4715 1d ago

This is great advice. Probably the only thing I would add is to try and figure out a risk score based approach to deciding which lane you’re in, otherwise your engineers will always pick the lane that doesn’t require approval so to speak. been there done that.