In a fifteen-minute meeting, the board of a midsize insurance company approves postponing the upgrade of its policy issuance system. The vendor has certified only the previous version, the integration with the premium calculation engine breaks every time a patch is applied, and the sales team has issuance targets for the following week. The decision is reasonable, it gets recorded in an email, and no one returns to the subject for the next eighteen months.
The scene repeats itself at companies of every size, with other names in place of the policy system: the ERP (Enterprise Resource Planning, an integrated management system) locked into a certified version, the server that supports a critical process and cannot afford downtime, the operating equipment running a system no longer supported by the manufacturer. Each exception is born of a sound operational reason, and that is precisely why it survives so long without review.
For those accountable for results, the relevant point is that the sum of these isolated decisions, and not the absence of an automated patching tool, defines the company's real risk surface. The management question is no longer whether the company is up to date, but how much risk it carries on purpose, for how long, and in exchange for what return.
The debt no one put on the balance sheet
The NIST (National Institute of Standards and Technology, the American standards institute) addressed the subject directly in its SP 800-40 Revision 4 guide, published in 2022: patch management is a business problem before it is a technical problem, and every exception should be created with a defined deadline, a named owner, and an associated compensating control. The same guide notes that organizations tend to see patching as pure operational cost, when it actually works like a premium paid in small installments to avoid a major claim.
The cost of not paying that premium shows up in incident data. The Microsoft Digital Defense Report from 2024 records that more than eight in ten ransomware compromises, the hijacking of data through encryption and a ransom demand, reached the network through devices that were not under the company's formal management. These are exactly the assets that live under an exception regime: outside the inventory, outside the patching cycle, inside the trust perimeter, and connected to the systems that sustain revenue.
Volume also works against the manager. Gartner, in its 2024 Market Guide for Vulnerability Assessment, points out that companies manage to remediate only a small fraction of the vulnerabilities detected in each cycle, which makes prioritization the program's decisive variable. When the queue is practically infinite and capacity is finite, the quality of the choice about what gets left for later becomes worth more than the speed with which the current patch is applied.
How to turn an exception into a decision
The first move is documentary, costs little, and can begin within two weeks: write the list. An explicit inventory of exceptions contains five columns, namely the affected asset, the technical or contractual reason, the named owner of the decision, the exception's expiration date, and the compensating control that reduces risk while it remains in place. The mere existence of this record changes the organization's behavior, because it converts an informal memory into a management object that can be reviewed, enforced, and priced.
The second move is to raise risk acceptance to the correct decision-making level. When the exception compromises a system that sustains revenue, customer data, or a regulatory obligation, the person signing off should not be the infrastructure coordinator, but the executive who answers for that process before the board. Mature structures of governance and compliance treat risk acceptance as a formal act, with a date, a signature, and periodic review, which avoids discovering after the incident that the decision never had an owner.
The third move is to translate technical severity into business exposure. A vulnerability classified as critical by CVSS (Common Vulnerability Scoring System, an open standard for scoring vulnerabilities) on an isolated lab server matters less than a medium-severity flaw in a system exposed to the internet and connected to the policyholder database. Programs of continuous vulnerability management combine recurring scanning, continuous monitoring, and business context to produce a queue ordered by potential damage, putting at the top whatever can truly halt operations.
Five questions every manager should ask
How many assets are under a permanent exception regime, and can anyone list them without consulting a technician's memory?
The honest answer, at most companies, is that the list exists only in the heads of two or three people. This creates a dangerous dependency, because knowledge about the environment's most fragile points walks out the door when the professional changes jobs, and the successor inherits an incomplete map that will only be updated at the next incident.
A simple test measures an organization's maturity on this point: ask for the list of exceptions in writing and observe how long it takes to arrive. If it takes more than two business days or comes in different formats from different sources, the gap lies in the process, which fails to record the decision at the exact moment it is made.
Who formally signs off on the risk acceptance when a core system cannot be updated?
In many organizations, the practical answer is no one, indefinitely. The email that authorized the exception carried no deadline, the manager who wrote it moved to another department, and the decision keeps producing effects years later, with the aggravating factor that the technical context that justified it may have already disappeared.
The practice recommended by NIST in its 2022 guide is to give every exception an explicit expiration date, with mandatory review at intervals of ninety or one hundred eighty days. At an insurance company, this means that the inability to update the policy issuance system becomes a recurring item on the executive committee's agenda, with an estimated cost and an evaluated alternative, instead of becoming a permanent feature of the architecture that no one questions.
What is the real cost of a planned window compared to that of an unplanned outage?
This comparison is rarely made, and it is the one that usually unlocks the budget. A planned four-hour window during a low-demand period has a known cost, with a prepared team, a tested rollback plan and advance communication to the affected departments, whereas an unplanned outage in the same system accumulates lost production, recovery hours, strained client relationships and, in regulated sectors, the obligation to notify authorities and data subjects.
For an insurance company, four hours without issuing policies during a low-demand period represents a measurable and recoverable number of proposals, whereas three days offline at the peak of the renewal season means brokers moving their book of business to the competition. Quantifying both scenarios in currency, even with a margin of error, tends to be the most effective argument for approving the maintenance that had been postponed.
Does your company prioritize by technical severity or by actual business exposure?
Most prioritize by technical severity, because that is the number the tool delivers ready-made. The limitation of this choice is that the score describes the theoretical seriousness of the flaw, without knowing whether that asset is exposed to the internet, whether it holds sensitive client data or whether it supports the process that generates cash at the end of the month.
Translating between these two languages is a management function and needs someone formally in charge of it. This role combines knowledge of the technical environment with an understanding of which processes bring the business to a halt, and it is where a back-office partner adds value quickly, by bringing method, comparative history and analytical capacity that a lean internal team can hardly sustain while handling the day's demands.
If a client or a cyber policy renewal required evidence of patching cadence within fifteen days, would you be able to present it?
The question is a readiness test, and the short deadline is intentional. Evidence of cadence means demonstrating, with records, how long the company takes on average between the publication of a critical patch and its application, what percentage of the environment is within the current policy and which exceptions remain active, with justification and expiration date.
Companies able to produce this material within fifteen days tend to obtain better terms on their cyber insurance renewal and to move faster through approvals with corporate clients. The rest find out, at the worst possible moment, that the documentation gap has a price, in the form of a higher premium, a larger deductible, an exclusion clause or the loss of the contract to a competitor that responded better to the same questionnaire.
Frequently asked questions
What is a patching exception and why does it represent a risk to the business?
A patching exception is the decision not to apply a security update to a given system, usually because of vendor dependency, the risk of breaking an integration or the impossibility of downtime. The risk arises when that decision receives no deadline, no named owner and no compensating control, because the temporary measure becomes permanent without a new assessment. The accumulation of these decisions defines the company's real risk surface.
How often should the list of exceptions be reviewed?
NIST's SP 800-40 Revision 4 guide, published in 2022, recommends that every exception have an explicit expiration date and periodic review, with usual cycles of ninety to one hundred eighty days. In the review, it is verified whether the original reason still exists, whether the compensating control remains effective and what the estimated cost is of keeping the exception active. More frequent reviews are appropriate for systems exposed to the internet or that handle sensitive data.
Who should sign the risk acceptance for a system that cannot be updated?
The signature must come from the executive accountable for the business process supported by that system, and not only from the technical owner. When the exception affects revenue, client data or a regulatory obligation, the acceptance needs to be a formal act, with a date, a validity period and an auditable record. This design prevents the organization from discovering, after an incident, that the decision never had an owner.
If your company's list of exceptions has never been written down, a no-obligation Strategic IT Assessment is a good place to start.