01
State the exact problem
Define the original symptom and the evidence supporting your theory. A change should test or resolve something specific, not simply be the next thing to try.
Everyday IT · Change Safety
Know how to get back before you move forward.
A technically correct change can still create a second incident if the current state, blast radius, dependencies, and rollback path are unclear.Before you change it, know what it is, who depends on it, and how you will reverse it.
Before the change
Safe remediation starts before the first click or command.
02
Capture current state
Record settings, memberships, ACLs, paths, versions, service state, screenshots, command output, timestamps, or other evidence needed to understand what existed before the change.
03
Identify the blast radius
Ask whether the change affects one user, one device, a shared folder, a department, a site, a tenant, a firewall, a server, or another shared dependency.
04
Define rollback
Know the exact steps required to restore the prior state. If rollback depends on a backup, export, snapshot, documented ACL, previous profile, or known-good configuration, confirm it exists first.
Not every rollback is the same
The recovery method should match the thing being changed.
Permissions
Record before you restrict
Capture ACLs, preserve administrative and service access, add the approved group before removing broad access, and verify both allowed and denied users after the change.
Profiles & clients
Preserve a working fallback
When rebuilding Outlook, a Windows profile, or another client state, keep the prior configuration available when practical until the replacement is proven.
Sync & data
Understand where the authoritative copy lives
Before unlinking, resetting, deleting, moving, or resyncing, determine which data is cloud-backed, local-only, pending, or at risk of overwrite.
Infrastructure
Use stronger controls
Server, network, firewall, identity-policy, mail-flow, virtualization, storage, and backup changes may require maintenance windows, exports, snapshots, configuration backups, peer review, or a formal change process.
During the change
Make it possible to understand exactly what happened.
Smallest change
Change only what your evidence justifies
A targeted change preserves causality. If you modify several unrelated layers at once, a successful result may still leave you unable to explain the root cause.
Checkpoint
Know when to stop
If the result differs from what you expected, the blast radius grows, new errors appear, or rollback becomes uncertain, pause before adding more changes.
Document
Record action and result together
Write down what was changed and what immediately happened. “Changed X, result Y” is far more useful than a list of actions with no outcomes.
Protect access
Do not remove your recovery path
Do not lock out the administrative identity, delete the only working profile, remove the only good copy of data, or disable the path you need to reverse the change.
After the change
A change is not complete because the interface accepted it.
Technical check
Did the expected state change?
Confirm the configuration, permission, service, policy, profile, path, or device state now matches the intended design.
Workflow check
Did the original problem actually go away?
Re-test the exact workflow that failed. A command succeeding or a status icon turning green is only an intermediate checkpoint.
Regression check
Did you break something adjacent?
When the change touched shared access or infrastructure, verify the known-good users, services, devices, or workflows that should remain unaffected.
Closure
Decide whether user validation is still required
Some outcomes can be proven technically. Others, especially historical data, role-specific behavior, completeness, or subjective performance, still require the user or owner to validate.
Red flags before changing anything
These conditions should slow the change down even when the proposed fix seems obvious.
No rollback
You cannot explain how to reverse it
If the only plan is “we will figure it out if it breaks,” the change is not ready.
Unknown owner
You do not know who approves the outcome
Permissions, retention, shared data, security settings, and business workflows should not be redesigned without understanding ownership and intent.
Large blast radius
The ticket is smaller than the change
If one user issue is about to trigger a tenant-wide, server-wide, firewall-wide, or department-wide change, stop and re-evaluate the scope.
Data risk
The change can delete, overwrite, or orphan information
Confirm recovery state before destructive repair, reset, unlink, move, restore, rebuild, or storage work.
Safe change = Current state + Blast radius + Rollback + Smallest justified action + Verification.
The goal is not only to fix the problem. It is to fix it without creating a larger one.
Related Guides
Complete the lifecycle after the controlled change.
Verify before close
Re-test the original symptom, the intended outcome, and any important side effects. Verify the workflow
Classify the outcome
Record whether the action restored productivity or controlled the underlying cause. Workaround or resolution?
Escalate with evidence
If the safe boundary is reached, stop and hand off the plan, result, risk, and rollback state. Build the escalation