You're managing exceptions somewhere. Credit tracks loan-to-value departures in one spreadsheet. Information security maintains risk acceptances in another. Vendor management logs contractual deviations in a third. The question isn't whether to manage exceptions, it's whether to centralize them under one governance structure or keep them distributed across business lines.
The Case for Keeping Exceptions Distributed
Business units understand their own risk. A credit officer who approves loan exceptions daily knows the portfolio, borrower relationships, and compensating factors better than a central governance team ever will. Routing these decisions through a corporate workflow can add unnecessary bureaucracy.
Distributed ownership also means distributed accountability. When exceptions reside within the function that owns the policy, there's no risk of miscommunication. The credit team doesn't wait for a central registry update, the information security group doesn't need to translate technical controls into generic risk language, and vendor management doesn't route standard contract redlines through an enterprise form.
Speed is critical. A loan exception that takes three days to route through a central approval chain versus three hours through the credit committee is three days of lost business. The same applies to vendor contracts, system configurations, and operational workarounds. Business units argue they can move faster when they control their own exception processes.
Technical context often gets lost in translation when centralized. A database administrator requesting a segregation-of-duties exception understands the compensating control at the OS layer. A central risk team might see jargon and need clarification, adding time and potentially leading to poorer outcomes.
The Case for Centralizing Under One Framework
The OCC compliance management systems booklet states that management should have a process to authorize, document, and report exceptions to risk limits. Regulators expect consolidated reporting because boards can't oversee what they can't see in aggregate.
Without centralization, you can't answer basic questions. How many open exceptions does the institution carry? What's the residual risk profile across all departures? Which policies generate the most exceptions? Are any business units self-approving high-risk gaps? If each function maintains its own register, nobody knows.
Approval authority can break down in distributed models. A department head approving their own team's exception is self-approval by proxy, and internal audit will flag it. Centralized governance routes exceptions by residual risk rating to the appropriate approval level: low risk to department heads, moderate to the second line, high to the executive risk committee. That ladder only works if enforced consistently.
Expiry tracking fails when manual. A spreadsheet doesn't escalate automatically when an exception passes its end date. A GRC platform does. It sends notice before expiry, escalates on expiry, and reports to the risk committee for anything that stays open without renewal. The Interagency Guidelines for Real Estate Lending Policies require institutions to report aggregate exceptions exceeding supervisory loan-to-value limits to the board at least quarterly, assuming someone is collecting that data.
Pattern recognition requires a unified view. If three business units request exceptions to the same policy clause within six months, it's a signal the policy needs revision. Distributed registers hide that pattern until an examiner points it out.
Where Practitioners Actually Land
Most institutions run a hybrid model. Business units request and own compensating controls. The second line assesses residual risk, challenges weak justifications, and maintains the enterprise registry. The third line tests whether the process operated as designed and samples individual records.
The registry sits in a GRC platform, but approval workflows stay close to the business. A loan exception still routes through the credit committee; the difference is that the decision gets recorded in a central system with a standard schema. The same goes for vendor contracts, IT configurations, and operational departures.
The platform enforces the fields that matter: the exact policy clause being departed from, the business reason, the inherent risk, the compensating control and its owner, the residual risk after mitigation, the approver and their authority level, and the expiry date. If the request doesn't carry a residual risk rating, it can't be routed. If the compensating control doesn't have a named owner and a test schedule, it's not a control.
Reporting goes up, not laterally. Business units don't need to see each other's exceptions in real time, but the board needs quarterly aggregates by policy, by risk rating, and by business unit. That's the view centralization enables.
Our Take
Centralize the registry and reporting, but don't centralize the judgment. Business units should retain approval authority within their delegated risk limits, but every exception should land in a single system with a consistent record structure.
The alternative is what happens at examination: an auditor asks how many open exceptions the institution carries, and six departments produce six different answers in six different formats. That's not a governance framework; it's evidence that nobody's in charge.
The risk isn't that you grant too many exceptions. The risk is that you can't distinguish documented departures from undocumented failures, because the evidence looks identical when the exception was never written down.
