What is a configuration rollback?
A configuration rollback deliberately resets a configuration to an earlier, working state after a change has caused problems. Rather than rebuilding the faulty change by hand, it restores a known state. It always needs a reference point: a configuration snapshot or a complete change history. A rollback can be complete, resetting the entire state, or granular, undoing only the one problematic change. The granular route is usually safer, because it keeps the intervention small. Importantly, a rollback is itself a change, and it needs the same control and documentation as the original change.
Configuration rollback in detail
Every rollback needs a reference point. Without a snapshot taken before the change, or a finely grained history, all that remains is risky reconstruction from memory, which costs time during an incident and introduces new errors. A clean reference point makes the way back predictable instead. How to pull back a single change with a before and after field diff is shown in our roughly two-minute video . A diff preview adds further assurance, because it shows exactly which values will change before you reset.
The difference between a complete and a granular rollback matters in daily operations. A complete rollback is simple, but it also undoes intended changes made between the reference point and the incident. A granular rollback removes only the one change causing problems and leaves the rest in place. Changes made outside the usual tool are particularly tricky: they must be visible too, or the rollback will not be complete.
Why configuration rollback matters in Zscaler operations
When a rule change in a Zscaler environment breaks access, every minute counts. A reliable rollback shortens the time to recovery, because you do not have to work out the way back from scratch. The granular approach keeps the damage small: only the triggering change is undone, while every other intended adjustment stays in place. That lowers the risk of introducing new incidents while fixing the original one.
For NIS2 or DORA evidence, the rollback is part of controlled change management. Resetting a configuration is itself a change to the active configuration and should follow the same rules: sign-off under the four-eyes principle, a diff preview before execution, and an entry in the audit trail. That way, it stays traceable who restored which state, when and why, instead of an emergency fix breaking the documentation trail.
Common sources of error
- No reference point: without a snapshot or a clean history, all that remains is risky reconstruction from memory.
- Complete rollback for a single fault: this also undoes intended changes made in the meantime.
- Rollback without control: resetting without sign-off and a log breaks the chain of evidence at its most critical point.
- Overlooked external changes: adjustments made outside the usual tool stay invisible and slip past the rollback.
Configuration rollback in practice: what CentaurNexus contributes
With Configuration Rollback, CentaurNexus reverses individual configuration changes in a targeted way, instead of resetting everything to an old state across the board. A diff preview shows what will change beforehand, and it also captures adjustments made outside CentaurNexus. Because resetting is itself a change, it goes through the same four-eyes principle and lands in the append-only audit trail. That keeps the way back precise, small and traceable. The following guide shows how this fits into a controlled change process: Find and clean up unused Zscaler rules.
Related terms
Frequently asked questions about configuration rollback
A configuration rollback is a deliberate reset of a configuration to an earlier, working state after a change has caused problems. It restores a known state instead of laboriously rebuilding the faulty change by hand. It always needs a reference point, such as a snapshot or a complete change history.
A complete rollback resets the entire configuration to an earlier state. A granular rollback undoes only the one problematic change and leaves everything else untouched. Granular is usually the better choice, because the intervention stays small and no intended changes are accidentally undone along with it.
A reliable reference point: a snapshot from before the change, or a complete, traceable change history. Without that foundation, all that remains is risky reconstruction from memory. A diff preview helps further, because it shows exactly what will change before you reset.
Yes. A rollback changes the active configuration and should therefore be just as controlled as any other change: with the four-eyes principle, a diff preview and an entry in the audit trail. That way, it stays traceable later who restored which state, when and why.
Yes, if the change history is kept fine-grained enough. Then you can undo a single change in a targeted way, without touching the rest of the configuration. A diff preview shows in advance which values are affected, so the intervention stays precise and traceable.
- BSI IT-Grundschutz, module OPS.1.1.3 (patch and change management) - bsi.bund.de
- Zscaler Help Portal: Backing Up and Restoring Configuration - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.