Your Exception Register Is Your Real Policy

Category: Operating Models Tags: policy management, exceptions, risk acceptance, document hierarchy, attestation, policy review, governance

An auditor once asked me a question that took two weeks to answer, and the question was not hard. She wanted the list of active exceptions to a single security policy. Not the policy, which I could produce in a minute. The exceptions. It took two weeks because they did not live anywhere: some were approvals in a ticketing system, some were email threads where a director had said yes, a few were in a spreadsheet a departed analyst had maintained, and an unknown number had never been requested at all because the team simply did not comply and nobody had asked. When we finally assembled the list, it ran to about forty items, a third had no end date, and several had been granted by people who no longer worked at the company. The policy on the intranet described a control environment. The list described the one we actually had.

That gap is the whole subject of policy management, and it is why the discipline is so much less about writing than people expect. I have written about the writing part, where the Good Idea Fairy writes your policies and every stray "shall" turns into a finding you wrote yourself. This is the other half. Assume the document is well drafted and every promise in it is one you can keep. It still decays, because a policy is not a document, it is a claim about how an organization behaves, and organizations drift while documents sit still.

The Library Only Ever Grows

Start with the shape of the estate, because most programs have never looked at it as one. Policy libraries accumulate. Every incident, audit, and new regulation produces a document, and nothing produces a deletion, because retirement is nobody's job and carries risk nobody wants to own. So you end up with fifty or eighty documents, several covering the same ground in different words, a few contradicting each other in ways no single reader will ever notice because no single reader reads them all.

Much of that bloat comes from putting content at the wrong altitude. The useful hierarchy is simple: a policy states what must be true and who is accountable, a standard states the specific configuration or threshold that satisfies it, and a procedure states how a person does the thing on a Tuesday. The failure is writing the volatile content into the policy. Once the minimum key length or the tool name or the retention period is in a board-approved policy, every routine technical change requires a governance cycle to keep the document honest, so the document stops being kept honest. Put the stable principle in the policy and the changeable specifics in the standard beneath it, and the policy can survive a decade of technical churn without a single lie accumulating in it.

The Annual Review Is a Signature

Then there is the annual review, which in most programs is the single most reliable ritual in governance and one of the least informative. A calendar reminder fires, an owner opens a document they did not write, reads it in the way people read things they have already decided to approve, and marks it reviewed with no changes. The metadata now says the policy was reviewed last month. Nothing was verified.

A real review asks a different question than "is this document still acceptable." It asks whether anything in the world this policy governs has changed since the last look: a new regulation in scope, a new system that holds the data, an architecture decision that made a stated control impossible, an incident that proved a requirement unworkable, an exception granted so many times that the requirement is effectively dead. That is the same argument I made in regulatory change is an operating model problem, which is that the trigger should be the change in the world, not the turn of the calendar. The calendar review is a backstop for documents nothing has happened to. When something has happened, waiting eleven months to reflect it is how a policy becomes fiction.

An Exception With No End Date Is a Policy Change

Now the part that matters most, and the part most programs treat as administrative overhead. An exception is a deliberate decision to accept a risk the policy exists to prevent. That is a risk acceptance, and it deserves everything a risk acceptance deserves: a named requester, a stated business reason, an explicit scope so it cannot quietly widen, a compensating control where one exists, an approval at the level appropriate to the risk rather than whoever was reachable, and an expiry date. The expiry is the load-bearing field. An exception with no end date is not an exception. It is an amendment to the policy, made by one person, without the approval the policy itself required to be written.

Once exceptions carry expiry dates, the register becomes the most honest artifact in the program, because it is the only place the difference between the stated and the actual control environment is written down. It also becomes a design input rather than a nuisance. When the same exception has been granted forty times, that is not forty failures of discipline, it is one badly designed requirement, and the correct response is to fix the policy rather than keep issuing dispensations. Exceptions cluster, and the clusters point at the requirements that were written for an organization you no longer are.

Attestation Measures Distribution, Not Understanding

Annual attestation is the other ritual worth being honest about. Everyone receives the policy pack, everyone clicks the box, and the program reports ninety-eight percent completion to a committee. What that number actually measures is that a distribution mechanism worked. It is evidence the document was sent and the click was recorded, which is genuinely useful for exactly one purpose, which is proving notification after someone violates it.

It is not evidence anybody can follow the policy, and treating it as such is how programs end up surprised. If the goal is behavior rather than a completion percentage, the attestation should be narrow and targeted at the population that actually carries the obligation, asking about the handful of things that population has to do differently, rather than sending eighty documents to everyone once a year. The blanket pack is optimized for coverage statistics. A short, role-specific acknowledgment is optimized for someone remembering the rule at the moment it applies, which is the only moment that counts.

Retrieval at the Moment of Decision

Which brings me to the failure that makes all the others academic. A policy is only a control if the person making a decision can find it and understand it while they are making that decision. Most cannot. The document lives in a portal nobody visits, written in a register that assumes the reader already knows the answer, structured for the approver rather than the practitioner. So people do what people do, which is ask a colleague, and the colleague's summary becomes the operative policy for that decision.

I argued in GRC is a knowledge management discipline in denial that knowledge you cannot reach when you need it is indistinguishable from knowledge you do not have, and policy is the purest case. The practical fixes are unglamorous: put the requirement in the first paragraph rather than the fourth section, keep one document per subject so search returns one answer instead of three, and route people to the rule from the workflow where the decision happens rather than hoping they navigate to a library. A policy that is correct, current, and unfindable fails in exactly the same way as one that is wrong.

That two-week exception hunt ended better than it started. We built the register the auditor had assumed existed, gave every exception an owner and an expiry, and let a few hundred of them lapse on purpose to see which ones anybody actually needed, which turned out to be far fewer than the count suggested. The clusters that remained rewrote three requirements that had never fit the business. The policies themselves barely changed. What changed was that the difference between the document and the practice stopped being invisible, and once that difference is visible, it is manageable. Until then, everyone is governing a company described on the intranet rather than the one that exists.