There were 1,900 open policy exceptions. Soame were four years old. Many had no expiration date. Several referenced business justifications for systems that had since been decommissioned. The stated policy said customer data must be classified within 30 days of ingestion; in practice, 40 percent of new data sources were operating under a standing exception to that rule.
The policy on paper and the policy in force were two different documents. Nobody had decided to change the rules. The rules had simply eroded, one approved exception at a time.
The Symptoms
The exception with no expiry. A team requests relief from a control for a legitimate, time-bound reason. The exception is granted. But no end date is attached, and no review is scheduled. What was meant to be temporary becomes structural, and the control it bypasses quietly stops applying.
The renewal reflex. When exceptions are reviewed at all, they are rubber-stamped. The reviewer sees that the exception already exists, assumes prior diligence, and extends it. Each renewal makes the next one easier to justify.
The invisible aggregate. Individually, each exception looks reasonable. Collectively, they represent the real risk posture of the organization — but no one reads them as a set. The governance committee approves exceptions one at a time and never sees the shape of what it has permitted.
The orphaned justification. Exceptions outlive the conditions that created them. The system is retired, the project ends, the regulation changes — but the exception remains open, protecting nothing and obscuring the fact that the control now has a hole in it.
The Root Cause
This is not a discipline problem, and it is not caused by teams trying to evade governance. Most exceptions are requested in good faith for real operational reasons.
The problem is that exception handling is designed as an intake process, not a lifecycle. Organizations build a clear path to grant an exception and almost no mechanism to retire one. Approval is an event; expiration is an afterthought.
Because exceptions are managed as static records rather than living commitments, they accumulate. A governance model that can only add relief, never remove it, will drift toward its most permissive state over time. The published policy stays strict. The operating policy gets quietly rewritten by its own backlog.
The Cost Beyond Compliance
The first cost is examination risk. Under OCC expectations for risk governance, a control framework is judged by what actually operates, not what is documented. A large, stale exception population signals to an examiner that the bank's stated controls are aspirational — and that finding tends to escalate quickly.
The second cost is decision blindness. When leadership cannot see the aggregate exposure created by open exceptions, it is managing to a policy that no longer reflects reality. Risk appetite statements lose meaning when the exceptions to them are unbounded and uncounted.
Redesigning the Process
Organizations that manage this well stop treating exceptions as permanent grants and start treating them as time-boxed liabilities. Every exception carries an expiration date and an automatic review trigger, so relief lapses by default unless someone actively renews it with fresh justification.
They also monitor the exception population continuously rather than at audit time. The relevant question is not "is this one exception justified?" but "what does our entire exception portfolio say about the gap between our policy and our practice?" That view has to be live, because the backlog changes weekly.
The CoComply Position
CoComply treats a policy exception as a governed object with a lifecycle, not a log entry. This directly addresses the two failures at the center of this article: the exception with no expiry and the invisible aggregate.
Every exception in CoComply is bound to the specific control and standard it suspends, given a mandatory expiration, and tied to the condition that justified it. When that date arrives, the exception does not silently persist — the workflow forces a decision to close it or re-justify it, so relief expires by default instead of surviving by inertia. That single mechanism turns the "renewal reflex" into an affirmative act rather than a rubber stamp.
Because each exception is linked to a live control, CoComply also reads the population as a set. Governance leaders see, continuously, how much of their stated policy is currently overridden, where the concentrations are, and which exceptions have outlived the systems that prompted them. The gap between the policy on paper and the policy in force stops being an audit-time surprise and becomes a monitored metric.
CoComply's governance model is built on the premise that a control framework is only as strong as its ability to reclaim the ground it gives away. Granting relief is easy; the discipline lives in retirement, and that is the part the design enforces.
A Quick Test of Your Program's Health
Pull your exception log and check three things. First, what share of open exceptions have no expiration date? Anything above zero is a slow leak in your control framework.
Second, measure the median age of your open exceptions. If it is counted in years, your published policy and your operating policy have already diverged.
Third, ask whether anyone has reviewed the exception population as a whole in the last quarter — not one request at a time, but the full set. If the answer is no, you do not currently know your real risk posture. You know the one you wrote down.