Every Exception Was Temporary. Read the Dates on Them.

Every grant was the right call

Read any single exception and it holds up. A release was going out on Thursday, the control blocked it, and the finding behind the control was real with a fix that would take a sprint nobody had. Someone wrote three weeks on the form, someone senior enough signed it, and the release went out. Everyone in that conversation was doing their job well.

The set behaves differently from the grants that built it. Exceptions are requested one at a time, approved one at a time and filed one at a time, and the whole set has exactly one reader: a query somebody has to write. What accumulates is the difference between the controls you wrote and the controls that run.

The set announces itself in individual records long before anybody counts it. Four lines, each an administrative detail on its own.

• An exception granted for one release is still in force two years after that release shipped
• The approver on the record left the company, and their approvals still stand in their name
• The requesting team has reorganized twice, and the system now sits with people who never asked for the exception
• The count of open exceptions against any single control has to be assembled by hand

Expiry that waits on a person

An expiry date on a record is a statement about intent. What governs is what the systems do on the morning after that date, and where the date lives in a document while the control lives in a pipeline, the systems do that morning what they did the day before.

Follow what expiry asks for. Somebody runs a query and produces a list. Somebody identifies the current owner, which is real research once a reorganization or two has passed. Then that person tells a delivery team that a control they have shipped without for a year is coming back, and asks them to fit it into a plan set last quarter. Three steps, each one optional.

The last step carries the weight, because it is a removal. For the delivery team the arithmetic is plain: schedule spent, and the benefit landing on somebody else's risk register. That conversation gets deferred once, and after that it lives in somebody's memory. Meanwhile the reason for the exception ages on its own: the library that could not be upgraded was upgraded eight months ago for unrelated reasons, and the exception now guards nothing.

An expiry date describes an intention. What governs is what happens the morning after, when nobody does anything.

Put the expiry in the enforcement

Three things below are CWS positions, argued in this text: expiry as the default enforcement state, renewal priced by cumulative duration, and the exception set read as a population with its own distribution.

The mechanism that makes expiry real is dull, and it is engineering work. The exception has to live where the control is enforced, carrying its end date, so the control comes back on its own. Where the register is one document and the enforcement configuration is another, the two drift, and the register goes on describing a control environment the pipeline stopped matching.

That puts a requirement on how a grant is written. It has to be specific enough for a machine to hold: which control, which repositories or accounts, which end date. An exception phrased as a paragraph about a team's circumstances has to be interpreted by a person before any system can act on it, which is what keeps it in force.

Some controls cannot simply switch back on. A build gate that starts failing pipelines at midnight stops a delivery team's work with no warning, and that is how a security program loses the standing to run gates at all. The handling is a notice period owned by the team holding the exception. Four properties make the difference.

• One record, read by both the register and the enforcement, so no second copy can drift
• Scope written in the terms the control is applied in, so a grant can be counted and revoked without interpretation
• Notice to the holding team on a schedule they can plan against, with the chasing owned by the holder
• Resumption automatic at the end date, with a short logged grace path where a hard cutover would break a delivery in flight

Renewal has to cost something

Expiry on its own relocates the problem. Where renewal is the same form signed by the same person, the set keeps growing and every entry carries a renewal history that reads as diligence. Price the renewal, and let the price rise with the total age of the exception.

The price is meant to be paid. Some exceptions should renew for years, because the thing behind them is a platform migration with a real plan and a real date, and forcing those closed early buys an outage. What the price buys is that somebody with standing looks at each one, and that renewing stops being cheaper than fixing.

One caution. Price it too high and requests stop arriving through the register while the practice underneath carries on, which costs you the visibility and leaves the risk where it was. Aim for a cost a team with a real reason will pay, and a team with a habit will find harder than closing the finding. Four levers do most of the work.

• Approval level set by cumulative duration, so a fourth renewal reaches somebody above whoever granted the first
• A fresh justification each time, written to answer what happened to the fix described in the previous one
• Evidence that the compensating control is still running, taken from a log
• The renewal list read in the forum that already owns delivery risk, which puts the whole set in front of the people accountable for it

Renewal has a price so that somebody with standing has to look. Some exceptions will pay it for years, and that is the system working.

The set is the control environment

The written policy describes what the organization intends to enforce. The exception set describes where that intention has been suspended, and by whom. Add the two together and you have what runs, and that sum is what a regulator, a customer security questionnaire and an incident review are each trying to reach. An auditor who reads the policy and never sees the register comes away with an accurate account of a document.

Auditors are owed the qualification: they read what the organization puts in front of them. If the register is missing from the evidence pack, the policy is the evidence, and the finding at the end will be a finding about the policy. An organization that hands over both is describing itself.

Roughly 6,300 repositories is the size of the one estate CWS has discovered end to end. At that size, a control exempted in even a modest share of it produces a population of exceptions, and a population has to be managed as one.

Reading the set whole produces views that no individual record can give you, cheap to compute once the exceptions sit in one place. Four of them change the conversation.

• Grouped by control, so a clause exempted across most of the estate becomes visible for what it is
• Grouped by root cause, because a stack of exceptions against one control can share a single origin: a build template or a base image that every affected system inherited
• Aged against the policy itself, which surfaces exceptions granted against wording that has been rewritten twice since
• Filtered for orphans, where the approver has left, the system has been decommissioned, or the owning team no longer exists

A control exempted across most of the estate is a control the organization has chosen to stand down. The register says so before anybody says it out loud.

Getting to a set you can run

What is already open needs its own treatment, and retro-justifying historical grants is a poor use of a quarter. Draw a line at a date, and treat everything before it as a separate body of work with its own owner and end state.

From the line forward, every exception carries a scope the enforcement can read and an end date the enforcement honors. One small rule, and the set stops growing.

For the existing set, sort by root cause before anyone schedules a risk conversation. Where exceptions against a single control share a cause, closing the cause closes them in a batch with no approval meeting. What survives that pass is the population that genuinely needs a decision.

Two numbers make the mechanism visible to whoever funds it. How many exceptions are open, and how many are past their own end date. The first stays positive in any program doing real work. The second one falling is the evidence that any of this works.

• Publish the start date before the rule applies, so the first team it affects hears it from you before their build fails
• Reconstruct the open set into one place and accept that part of it has no identifiable owner. That count is itself a finding
• Close the batches first, then bring the remainder to a named approver with the renewal price attached
• Report both numbers on the same slide every quarter, because one count of open exceptions hides whether anything expires