Policy Exception

A policy exception is a recorded, time-limited permission to do something a policy forbids, granted by a named approver on the basis of a stated reason. It is the pressure valve that keeps a policy honest: rules written for the general case will meet a legitimate specific case, and an organisation with no way to say a controlled yes will get an uncontrolled one instead. A real exception has five parts. What is being permitted, stated narrowly rather than as a general waiver. Why the normal control cannot be met. What compensating measure reduces the risk in the meantime. Who approved it, at a level of authority that matches the risk. And when it expires, which is the part that most often goes missing and the part that does the most work. Around AI, exceptions cluster in recognisable places: an unapproved tool needed for one project because nothing on the approved list does the job, customer data in a system that was scoped for internal use, a launch that goes ahead before its evaluation is complete, a model provider without the contractual terms the standard requires. Each is a reasonable request in the moment and a durable weakness if it never expires. The failure mode is the permanent exception. Once granted with no end date, it stops being a deviation and becomes the actual policy, unwritten and unreviewed — with the added harm that the written policy now describes a state of affairs that is not true, so nobody can rely on it. A register of open exceptions with expiry dates, reviewed on a schedule, is what prevents that; a pile of one-off approvals in an inbox does not. Read the register as a signal about the policy rather than about the people. Many exceptions of the same shape mean the rule is wrong or the approved options do not cover a real need, and the right response is to change the rule, not to keep granting the same waiver. Exceptions are where a governance programme learns what it got wrong.