Forcing egress through the proxy on a 24/6 line gives you one window - how do you sequence it, and what justifies refusing a 03:00 revert that hands an implant the direct path out again?

## The constraint A line running 24/6 gives you one shutdown to enforce in. There is no environment that behaves like the plant, because the plant is a specific collection of machines, controllers, instruments and licence servers of varying ages, and no lab reproduces it. So the usual software answer - test it somewhere else first - is unavailable, and everything depends on how much you can learn without stopping anything. ## Learning without the window **Log-only enforcement.** Deploy the policy in a mode that evaluates and records but does not block, for long enough to cover the estate's slowest cycle - monthly licence check-ins, quarterly vendor diagnostics, the annual thing nobody remembers. What you are producing is a destination inventory measured from reality: every destination each device actually reached, from flow records and, where sessions use names, the server name in the TLS ClientHello. **Why the vendor's documentation is not a substitute.** Vendor lists are written for a generic install, are usually incomplete, and often name destinations that resolve differently in your region. Measurement beats documentation here, and where they disagree, the measurement is the thing that will break the line. **Ring enforcement.** Office segments and any non-production cell first; then the least critical production cell; then the line. Each ring is a rehearsal that costs you almost nothing and teaches you which classes of software fail and how the failure presents - silent telemetry, a stalled queue, an alarm on a panel. ## Sequencing inside the window Order the changes by risk, riskiest first, so the thing most likely to need investigation gets the most remaining time. Leave real observation time after each step rather than stacking every change and hoping. Have the rollback for each step prepared and tested as a step of its own, since a rollback you have never executed is not a rollback. And know in advance which machines you cannot restart, because a device that will not come back cleanly turns a two-minute change into the outage. ## The 03:00 call This is where the leaf's real question sits. At 03:00 someone will ask for the change to be reverted. The operator who owns the window must not be improvising a policy at that hour, so the criteria are written and agreed beforehand with the line owner: - **What symptom triggers a revert.** Named, observable, on a list: this alarm, this queue stopping, this licence check-in failing. Not "it feels wrong". - **How long you wait before acting.** Many failures are transient re-establishment behaviour and resolve in minutes. - **What the operator may do without waking anyone.** Usually: revert one step, or grant one pre-approved narrow exception. And there must be a third option prepared, because otherwise the choice at 03:00 is binary and the blanket revert wins by default. That third option is a narrow, time-boxed, single-destination exception for the device that broke - written from a template, logged as an exception with an owner and an expiry, and reviewed the next working day. ## What justifies refusing Refusing a revert is legitimate when the symptom is not on the agreed list, when the reported failure is not attributable to the change (a coincidence elsewhere in the estate, a device that was already failing before the window), or when the request is to disable everything because one device broke and a targeted exception would fix it. It is not legitimate to refuse when a named symptom on the list is present and production is being lost - that is what the list was for, and an engineer who overrides it at 03:00 has destroyed the trust the next window depends on. ## Why the blanket revert is the expensive answer Reverting the whole policy restores direct egress for every device at once. It is the widest possible response to a single failure. If anything in that estate is already compromised, the revert hands it back an unmonitored path out for however long the policy stays off - and "temporarily off" has a way of lasting until the next shutdown, which on a 24/6 line may be months away. That is the argument to have in daylight, with the line owner, when the criteria are being agreed, and it is precisely why the narrow exception must exist as a prepared option rather than an idea someone has at 03:00. ## Answering it well Lead with the reframing - the window is for enforcement, discovery happens in log-only mode beforehand - then rings, then sequencing, then the written revert criteria and the prepared third option. Finish on the cost of the blanket revert, in terms of the estate rather than the change: it is not one control off for one device, it is every device's direct path back for an unbounded period.