- › Accepting a security risk is a legitimate business decision, and a program that refuses every exception just pushes the work out of sight.
- › Most acceptances go wrong in the same three places: the wrong person signs, nothing expires, and nobody checks the compensating control afterward.
- › The acceptance should be signed by whoever would absorb the loss, with authority tiers matched to the size of the exposure.
- › Every acceptance needs a hard end date, and an expired one should reopen as a finding that gets reported upward automatically.
- › After an incident, the acceptance record is evidence of what the company knew, so its condition decides whether it reads as a decision or as neglect.
Three years ago, somebody in IT asked for an exception. An old server that fed the accounts payable system could not be upgraded until a new finance platform went live the following spring, so the security team wrote up the risk, a director signed the form, and the server stayed on the network with a line in a spreadsheet explaining why.
The finance project slipped twice and was then canceled in a budget round. The server is still there. The director who signed left the company last year, the spreadsheet was migrated into a governance tool, and the exception now shows as accepted, with no end date and no owner who still works in the building.
Nobody in that story did anything reckless, and every step was reasonable on the day it happened. The result is a known, documented, unpatched system that the organization has formally agreed to live with forever, without anybody ever deciding that it should.
Accepting Risk Is a Legitimate Decision
I want to defend risk acceptance before I criticize how it usually works, because the instinct in some security teams is to treat every exception as a failure. Businesses accept risk constantly, in contracts, in hiring, in which markets they enter, and security risk belongs in the same category. Sometimes fixing a finding costs more than the harm it could cause, and sometimes the fix has to wait for a project that is already funded.
A program that refuses every exception does not make the risk go away. It pushes the conversation out of sight, where people quietly work around the control and nobody records that they did. An exception process exists so that those decisions get made in the open, by somebody accountable, with the reasoning written down. Where the process usually goes wrong is in three things the typical acceptance is missing: the right signature, an end date, and anybody checking on it afterward.
The Wrong Person Signs
Most exception forms route to the security team for approval. That feels natural, since security wrote the finding, but it gets the ownership backwards. The security leader can describe the risk in detail, and they usually cannot decide whether the business should carry it, because they do not own the revenue, the customer relationship, or the budget that would pay to remove it.
When the security leader signs, two things happen at once. The business owner who asked for the exception walks away believing the risk has been handled, and the security leader now holds a decision that was never theirs to make. We looked at what that does to a security leader’s personal exposure in August, and the organizational cost is just as real. The person who could fund a fix and the person who would carry the consequence of not fixing it are no longer the same person.
The signature belongs to whoever would absorb the loss. For the accounts payable server, that is the head of finance, who would be explaining a payments fraud or a week without invoicing to the leadership team. Security’s role is to state the risk plainly enough that the signer understands what they are agreeing to, and to confirm the signer has the authority for a risk of that size.
That last part needs tiers. A manager might accept a low-rated finding for a few months, a high-rated finding needs the executive who owns the affected process, and anything that could plausibly become a reportable incident goes to the leadership team as a group. Write the tiers down, because without them every exception drifts toward whoever is easiest to get a signature from.
Nothing Expires
Exception forms usually have a field for an end date. In many organizations it is optional, and where it is filled in, it is often the go-live date of a project that has not yet slipped. An acceptance with no expiry is a permanent change to your security policy, made by one person on one afternoon and never discussed again.
Set a maximum term for every tier, with shorter terms for higher risks. When the term ends, renewal should be a fresh decision, with the current owner signing again against current facts, and never an administrator extending a date field because a reminder email arrived.
The most useful rule is what happens when nobody acts. An acceptance that expires without renewal should automatically reopen as an open finding and appear in the next report to leadership. That makes neglect visible by default, which is the opposite of how most registers work today, where neglect is invisible by default and the exception simply stays accepted until somebody happens to look.
The Compensating Control Nobody Checks
Most exceptions come with a compensating control. The old server is isolated on its own network segment, the shared vendor account is monitored, the unsupported device only accepts connections from a single management host. These controls are what make the risk acceptable, and they are described carefully at the moment of approval and rarely examined again.
Environments change around them. Network segments get merged during an office move, a monitoring rule gets switched off because it was noisy, and somebody opens a second path to the device to fix an urgent problem on a Saturday. The exception still reads as mitigated in the register, because nothing in the register knows that the mitigation is gone.
Treat a compensating control the way you should treat a remediated finding, as a claim that needs to be verified and not just recorded. Our piece on the retest gap after penetration testing makes the case for checking fixes, and the same logic applies here with more force, since a compensating control is the only thing standing between a known weakness and whoever finds it next. Check it at every renewal, and check it whenever the network or the system around it changes.
Nobody Reads the Register
A register that only grows is a filing cabinet. The value comes from reading it as a whole, and a handful of numbers tell you most of what you need: how many acceptances are open, how many are past their end date, how old the oldest ones are, and which business units and systems hold the most.
That last measure is the one that surprises people. A system carrying four or five separate exceptions is a system the organization has effectively decided to stop maintaining, one reasonable signature at a time, and somebody should say that out loud in a meeting where the budget to replace it can be discussed.
It also helps to look for acceptances whose signer has left. Those are decisions that currently belong to nobody, and in my experience they cluster around exactly the old, awkward systems that attackers tend to find first.
After an Incident, the Register Is Evidence
When an incident is reconstructed, one of the first questions anyone asks is whether the organization knew about the weakness that let the attacker in. For an accepted risk, the answer is yes, in writing, with a date and a signature.
That record can protect you or hurt you, depending on its condition. An acceptance signed by the right owner, inside its term, with a verified compensating control and a renewal history, reads as a deliberate business decision that was revisited as circumstances changed. The same weakness recorded three years ago by somebody who has since left, with a mitigation nobody has checked, reads as a known problem the company chose to ignore. We made a similar argument about the materiality call made in the middle of an incident, and the principle carries over directly: an undocumented judgment and an abandoned one look the same from the outside.
Directors are increasingly asked whether they exercised real oversight, and a board’s fiduciary duty on cybersecurity is easier to demonstrate when the board has seen the acceptances that matter. A short summary of the highest-rated open exceptions, with owners and end dates, is one of the more honest things a security leader can put in front of a board.
Where to Start This Quarter
You do not need a new tool for this. Pull the current exception register, sort it by age, and mark every entry whose signer has left or whose end date has passed. For each one, find the business owner who would absorb the loss today and ask them to renew it on current facts or fund the fix. Then write the authority tiers and maximum terms into policy, so the register you rebuild does not drift back into the one you started with.
Most of what is in that register was a reasonable decision when it was made. The work is making sure each one is still a decision, owned by somebody who knows they own it, and not a line in a spreadsheet that outlived everyone who remembers why it is there.
Jeff Welch is CEO of Grab The Axe.
A PhD candidate in Health Psychology and former Corrections Officer, Jeff founded GTA to dismantle passive security models. He focuses on the 'Human Zero-Day', mitigating executive burnout and decision fatigue before they become security breaches.
View Author Page →
