Undoing a change Qorionix made

The reversal path for a change is written down before the change is made, and shown to you next to the undo control. That ordering is the whole design. An owner reaching for undo is usually having a bad morning, and the worst possible moment to find out how something is reversed is the moment you need it reversed.

It also has a consequence you can see in your report: a change with no recorded reversal path is never applied without asking, even when it is obviously reversible. "Reversible in principle" is an untested claim, and the platform does not act on claims.

What is recorded, and when

Every applied change carries an undo handle. It is created by the code that makes the change, at the moment it makes it — never reconstructed afterwards, because a reconstruction can be wrong in exactly the situation where it matters.

{
  kind:         the reversal operation, e.g. restore_directory_role
  params:       the typed arguments the reversal needs
  instructions: the human-readable reversal path, shown next to the
                undo control so an owner is never guessing
  expires_at:   when reversal stops being possible; absent means no
                known expiry
}

kind

Names the reversal, not the original change. Reversing require_mfa_for_admins is disable_ca_policy; reversing revoke_app_consent is reinstate_app_consent. The reversal is its own typed operation with its own audit entry.

params

The exact arguments captured before the change. For an application consent that means the precise permission list, so restoring means restoring what was actually there rather than what somebody remembers.

instructions

One or two plain sentences, written for the person who will read them under pressure. This is what appears in the interface, in the notification, and in your evidence bundle.

expires_at

Some reversals have a window. A rotated application secret can be reverted for 24 hours; a removed directory role is kept for 90 days. Where the field is absent, there is no known expiry.

What "one tap" covers, and where it stops

Changes in the done pile can be undone in one tap. That is one of the six conditions for reaching that pile at all, and the sentence you see next to each of them says so: "safe, reversible and interrupts nobody, so it has already been applied and can be undone in one tap."

The approve pile is more mixed, and the product used to overstate it. An earlier version of the report promised "and you can undo it in one tap" next to every change awaiting approval. That was not true of most of them. The approve pile is where the Conditional Access, multi-factor, account-state and mailbox changes live, and reversing those happens inside your Microsoft 365 — which this platform does not write to unattended.

So the promise is now made per change, by the same function the undo endpoint enforces. Where a change genuinely is one tap away from reversal, you are told. Where it is not, you are shown the recorded instructions instead and not told anything about taps. Silence rather than a negative claim, because the instructions immediately below say what is actually involved, which is more use than being told what is not possible.

The reversal paths you are most likely to read

These are the actual recorded instructions from the check pack, verbatim. They are worth skimming once now rather than for the first time when you need one.

Two patterns are worth noticing. First, several of these say what was captured before the change — the exact permission list, the exact role assignment, the previous setting. That is what makes the reversal a restoration rather than an approximation. Second, the two that concern your own answers to the two onboarding questions are reversible at any time with no window at all, because an answer you cannot change is not an answer, it is a trap.

How to undo something

1. 1

   Find the change, not the finding

   Open the change set for the run rather than the finding that produced it. One finding can generate more than one change, and it is the change that carries the undo handle. Applied changes stay visible after the fact; they are not cleared from the report.

2. 2

   Read the recorded instructions before you tap anything

   They tell you what reversal actually does and how quickly. "It takes effect immediately" and "the previous secret stays valid for 24 hours" set very different expectations, and both matter if somebody is waiting on you.

3. 3

   Check the window

   If the handle carries an expiry, it is shown. Ninety days for a removed directory role, 24 hours for a rotated credential. Past the window the platform will tell you the reversal is no longer available rather than attempting it and failing halfway.

4. 4

   Undo, and watch for the confirmation

   A change_reverted event is written to the audit chain with you as the actor. If the reversal itself does not succeed, you get a change_failed event and an explanation rather than a silent no-op.

5. 5

   If the finding was right, decide what to do instead

   Reverting a change does not make the underlying finding go away, and it should not. The finding reappears on the next run because the condition it describes is still true. If you have decided the risk is acceptable, record that decision — a dated, documented decision not to act is a defensible position, and no record at all is not.

What we cannot undo

There are three categories here, and being clear about them is more useful than a reassuring blanket promise.

Changes that are destructive by nature

delete_unused_account is the clearest example. It is destructive and not reversible by us, so it is forced into the decide pile and will never be offered as one tap. If you want an account gone, we will show you the evidence and you will do it deliberately. The safer neighbour, disable_stale_account, is reversible and sits in approve.

Consequences rather than configuration

Reversal restores a setting. It does not restore the state of the world. Reinstating an application's consent does not un-read the mail it read while it had access, and re-adding a directory role does not recover work somebody could not do in the hour it was missing. Where a change is disruptive, the report says so before you approve it, and states the blast radius as a count of people.

Anything outside a recorded window

A rotated credential cannot be reverted on day three, and a removed role assignment is not kept beyond 90 days. The window is stated in the instructions from the beginning rather than discovered at the end.

One thing that is never in question: nothing the platform does on its own can fall into the first category. That is enforced by the classifier, by a validation pass over the whole change set, and by a database constraint — three independent checks, so a classifier regression, a bad migration or a direct write to the database still cannot land an irreversible change in the pile that gets applied without asking. The rules and the reasoning are in Done, approve, decide.

Every reversal is recorded

Reversals appear in the same hash-chained audit log as everything else, with the actor recorded as human, ai or system. A reverted change therefore has a complete, ordered history: proposed, accepted, applied, reverted — with who and when at each step.

This matters beyond curiosity. Under NIS2 Article 20 your management is personally responsible for approving cybersecurity risk measures, and the audit chain is what turns "we looked at this in September" into evidence. A change you approved and then reverted after finding it broke a scanner is a better story in front of an auditor than a change nobody ever considered.

Who in your organisation may approve and revert changes is controlled separately — see Roles and permissions.