What belongs in a policy exception register—and what does not

A policy exception register should hold approved departures from a written policy—not every operational hiccup. When teams log temporary workarounds, system defects, and informal manager preferences in the same list, ageing reports become noise and audit committees lose the thread.

Start with a simple test: did someone formally approve a deviation from a named policy clause for a defined period? If the answer is no, it may still need a ticket or incident record, but it does not belong in the exception register.

For finance and procurement policies common among Taiwanese mid-market firms, typical register entries include temporary dual-approval waivers, vendor onboarding without a full due-diligence pack, and access rights granted outside the role matrix. Informal “we always do it this way” habits should go to process owners for redesign, not into the exception log.

Keep compensating controls in a dedicated field. If the register only stores the yes/no of approval, you cannot later test whether the promised second review or manual reconciliation actually happened.

Review the register monthly for entries past their expiry. An expired exception that is still operating is no longer an exception; it is an unapproved practice and should be escalated as such.