The Permission That Outlived the Task

A temporary workaround should come with a way back. When the normal process cannot carry the work, a responsible manager may approve another route. The immediate problem gets solved. The harder question arrives later, when the problem is gone and the alternate route is still open: who is responsible for ending the exception?

Imagine a service team whose reporting system is being replaced. The manager authorizes a manual spreadsheet for the weekly report while the replacement is checked. The decision is sensible. It keeps the customer informed and gives the team time to verify the new system. Several reporting periods later, the new system is ready, but the spreadsheet continues. Its owner has changed. The handoff says “prepare the weekly spreadsheet.” An accommodation has become an instruction without anyone deciding that it should.

The paperwork might be excellent. The team may have the original approval, a detailed procedure and every report ever produced. What is missing is the condition that connects the permission to the reason it existed. A record can preserve a decision perfectly while allowing its meaning to change.

An exception needs an ending at the moment it begins. The useful approval names the ordinary rule, the permitted departure, the reason, the responsible person and the boundary. It also says what ends the departure or forces a fresh decision. “Use the manual report during the replacement” leaves the word “during” doing too much work. A named review date and an observable condition make the instruction usable by someone who was not in the meeting.

In the imagined reporting example, the condition might be that the replacement produces two agreed reporting periods whose totals reconcile to the approved source. The record would name who checks that result and who authorizes the switch. Two periods is simply a choice for this example, not a universal standard. The important part is that completion can be observed. “Until everyone is comfortable” cannot be assigned, checked or closed with the same clarity.

A review date and an expiry date do different jobs. A review date brings the decision back to its owner. An expiry date ends the permission unless it is renewed through the agreed process. Calling both a deadline hides the operational consequence. If the next report still has to go out, the team needs an approved fallback before the exception expires. Good control includes the continuity plan; it does not leave the operator to choose between an unexplained stop and an unauthorized continuation.

Security provides a concrete example of designing the ending. NIST's control catalog includes a provision for automatically removing or disabling temporary and emergency accounts after an organization-defined period. The provision is specific to those account types, but its design is instructive: the ending is part of the mechanism. It does not depend on somebody remembering that the emergency is over. See NIST SP 800-53, AC-2(2).

A handoff must carry the boundary with the permission. The incoming operator needs to know which exceptions are still active, what each permits, what it excludes and when it must be reconsidered. An old approval remains useful within its actual scope. It does not become broader because the person doing the work has changed. Equally, a transfer should not force someone to seek the same permission again merely to finish an unchanged, authorized task. A clear record should reduce that interruption.

The next action matters here. “Review exception” is easy to defer. “Compare the next report against the approved totals, record the differences and send the result to the named decision owner” gives the new operator work they can perform. If that action cannot happen because the source is unavailable or the owner has left, the obstacle belongs in the record with an escalation path. Silence should not quietly renew the arrangement.

Repeated extensions deserve a different conversation. They may reveal that the replacement is unfinished, that the original process was poorly designed, or that the supposed exception is now the better way to work. Any of those can justify a new decision. What deserves scrutiny is the habit of extending the date while leaving the reason untouched. At some point the organization should repair the normal process or deliberately adopt the new one, with its costs and responsibilities understood.

For a buyer receiving a service, this is a useful question to ask of the operating plan: which temporary arrangements will still exist when the delivery team leaves, and who closes them? The answer reveals work that a schedule alone can miss. A milestone can be reached while the people running the service remain dependent on an arrangement nobody intended to maintain.

Organizations need room to make exceptions. They also need a reliable way to finish them. The permission should stay attached to its purpose for as long as it is used, and the record should make the next decision unavoidable when that purpose changes. Otherwise “just this once” becomes a policy written by the calendar.