Glossary / Change Management

Change Management

The controlled process for planning, approving, testing, and rolling out a change to an IT environment — designed specifically to keep a planned change from becoming the next incident.

A formal change process typically runs a request through risk assessment, approval, a scheduled maintenance window, and a defined rollback plan before anything touches production — with a review afterward to confirm it actually worked as intended. ITIL formalizes this with named roles and a change advisory board, but scaled-down versions of the same idea show up in any team that's been burned by an undocumented change before.

Mature processes distinguish change categories rather than treating every change the same way: a "standard" change is low-risk and pre-approved for repeated use (a routine patch deployment, for instance), while a higher-risk or novel change goes through fuller review — that distinction is what keeps change management from becoming a bottleneck on everyday work.

The reason change management exists at all is that a badly planned change is a self-inflicted incident — and self-inflicted incidents are, unlike most security threats, entirely within the organization's own control to prevent through process rather than tooling alone.

How Nexus handles this

Nexus's patch engine applies change-management discipline by default — staged ring rollout, maintenance windows, and auto-halt on a rollout that starts failing — and every remote job runs against a default-deny capability registry rather than broad standing permission to change anything on an endpoint.

Ready to see it in the platform?

Join the design-partner cohort and we'll show you exactly where this lives.