Who may approve a policy waiver on a rule that their own team owns?

## The question underneath the question Asking who may approve a waiver is really asking who is accountable when the exception turns out to be wrong. Everything else follows from that. ## Separation of duties, and its limit The non-negotiable part is small: the requester and the approver must be different authenticated identities, and the approval must be recorded as an identity rather than a typed string. If a waiver record is stored as code, this is nearly free — the approval is the review on the change that adds the record, from the same identity system that already controls what can be merged. If it is a form, then the field must be populated by the system from the authenticated session, never by the requester. What is genuinely contested is the next step: does owning the rule qualify you to except your own work from it? Owning a rule usually means you understand it best, which is an argument for you approving. It also means you wrote the thing now standing between your team and a release, which is an argument against. The resolution is that the approver must be accountable for the risk the rule addresses, not for the delivery date the exception unblocks. Sometimes that is the same team. Often it is not, and the honest test is: if this exception causes an incident, whose name is on the review? ## Authority should scale with blast radius A single approval bar for all exceptions is wrong in both directions — too heavy for the trivial case and too light for the dangerous one. Make authority a function of the two fields you already have in the record, scope and expiry, plus the severity of the rule: | Exception shape | Reasonable approver | | --- | --- | | One workload, weeks, low-severity rule | Delegated approver inside the owning team | | One account or prefix, a quarter, medium-severity | A security owner outside the requesting team | | Broad scope, long term, or a high-severity control | Named accountable owner of that control, plus a record leadership sees | This gives you the two properties you want at once. The overwhelming majority of exceptions are narrow and short, and they clear locally in minutes — which is what makes the process survivable for the engineer blocked at 17:00. The small number that are wide or long draw real scrutiny, which is where scrutiny was always worth spending. ## Why the central-approval-for-everything design fails It is worth being explicit about this, because it is the design most organisations reach for first. Route every exception through one security group and three things happen. The queue becomes the critical path for delivery, so pressure to approve quickly rises exactly where you wanted care. The approvers lose context — they cannot know four hundred services well enough to evaluate each justification, so they approve on the strength of the requester's summary anyway. And teams learn the timing, so requests arrive framed as emergencies. You end up with the ceremony of central control and the substance of self-approval, plus a delay. Delegation with hard caps and after-the-fact sampling gets you more actual control: caps that a delegated approver cannot exceed, records that are uniform enough to audit in bulk, and a periodic read of a random sample to see whether the delegated judgment is holding. If sampling shows a team consistently granting itself wide, long exceptions, you tighten that team's cap — a targeted response you could not have made under a uniform bar. ## Choosing the expiry length The approver's other real decision is the term, and there is a principle that removes most of the argument: **the expiry should match the plan that removes the need, not the calendar.** If the vendor release that lets an image read its key from a mounted file is due in six weeks, the exception runs eight. If there is no plan, the right term is short and the right next step is to produce one — a long expiry granted because nobody knows how long the fix will take is just deferring the same conversation with less information. A year is almost never the right answer for a technical blocker, and a week is almost never the right answer for a vendor dependency. Both extremes are usually the approver avoiding the question of what actually has to happen. ## Where this stops This is the planned path: a known blocker, a filed record, an approval before the change is made. It is not the emergency path where someone with authority overrides a gate during an incident, which is a different mechanism with different controls. Keeping the two separate matters, because a waiver process that quietly doubles as an emergency override loses the property that makes it useful — that every exception was decided in advance by someone who was not under fire. ## What a strong answer sounds like Name separation of duties as the floor, then immediately move past it to the real design question: how to keep approval fast enough that people use it, while keeping the wide and long exceptions in front of someone accountable. Tie the term to a removal plan. Anyone who answers only "the security team approves" has not thought about what happens at four hundred services.