The Explanatory Ledger: A Board-Ready Quarterly View of Unpatched Endpoints

Patch debt is not a synonym for negligence. It is the accumulated difference between the software estate a UK SME runs and the fixes it has been able to apply. Every organisation carries some. The difficult part is not eliminating it overnight; it is explaining it in a way that lets a board make sensible decisions about risk, resource and timing.

A quarterly patch debt statement does that. It is a one-page management document, not a technical scan report and not a compliance certificate. It should show what remains unfixed, how long it has remained so, which exceptions have been accepted and what it would cost to clear the backlog. Handled well, it turns a subject that often produces either silence or alarmism into a routine governance conversation.

Why a statement, not a score

Vulnerability dashboards are useful to operational teams, but they rarely answer the questions directors actually ask. A count of findings without context invites two unhelpful responses: panic about a number that may include low-risk items, or dismissal of a number that has become familiar. A statement imposes structure. It distinguishes between the estate that is visible and the estate that is assumed, between age and severity, and between a fix that is waiting for a change window and one that has no owner.

The word debt is deliberate. Like financial debt, patch debt has an opening balance, additions during the period, repayments and a closing balance. It can be refinanced through compensating controls or cleared through planned work. It can also compound if left unmanaged. That language is familiar in boardrooms and avoids treating every open vulnerability as an emergency.

The four lines that matter

A useful statement need not be elaborate. Four lines provide the backbone.

First, unpatched endpoints. This should be expressed as a fraction, not only a raw count: the number of endpoints with one or more open vulnerabilities above an agreed severity threshold, divided by the number of endpoints in scope. The denominator matters. If endpoint agents cover 180 of an estimated 220 devices, the board should see both figures. An apparently low finding count across an incomplete estate is not reassurance; it is a visibility gap.

Second, exposure days. Average exposure days can be distorted by a single old device, so a median and an age-band breakdown are often more informative. Showing open critical and high findings by age — zero to 30 days, 31 to 60, 61 to 90 and beyond — gives directors a sense of whether the backlog is being worked or merely stored. The statement should state the measurement date and whether the figure is based on first detection or the vendor's publication date.

Third, accepted exceptions. These are vulnerabilities the organisation has consciously chosen not to remediate within the normal window. Each should have an owner, a reason, a compensating control where one exists, and an expiry date. An exception without an expiry date is not a decision; it is an omission with paperwork.

Fourth, the cost to clear. This is an estimate, and should be labelled as one. It can combine internal engineering hours, contractor time, licence or hardware costs, and expected operational disruption. For a UK SME, a simple model is often enough: number of remediation tasks by effort band, multiplied by an agreed internal day rate, plus any external spend. The aim is not accounting precision. It is to let the board compare the cost of clearance with the cost of accepting the risk for another quarter.

Building the evidence without overclaiming

Endpoint management tools, vulnerability scanners and ticketing systems each see part of the picture. Reconciling them is where most of the effort lies. Start with the asset register or endpoint inventory and state its limitations. Then extract open findings from the scanning tool, filter to the agreed severity and scope, and match them to remediation tickets. Record where the match fails. Those unmatched items are often the most revealing: a finding with no ticket may indicate an ownership gap, while a ticket with no finding may indicate a stale record.

Avoid presenting a vendor risk score as though it were an audited fact. Scores change with vendor methodology and can obscure the age, exploitability and business context of a vulnerability. The statement should be clear about source, date and scope. If a scan failed on a group of devices, say so. If a business-critical application is excluded because patching is controlled by the supplier, say that too. A statement that admits its limits is more credible than one that implies complete knowledge.

Where possible, separate routine patching from exceptional remediation. A missing operating system update and a vulnerable line-of-business application may both appear in a scan, but they require different responses and different owners. The board does not need every technical distinction, but it does need to know that the numbers are not blending unrelated problems into a single misleading total.

Presenting it to the board without alarmism

The tone of the covering note matters as much as the table. Avoid language that implies every unpatched device is an imminent breach. Instead, frame the statement around direction of travel and decision points. Is the closing balance lower than the opening balance? Are older items being cleared or merely re-aged? Are exceptions expiring as planned? Is the cost to clear stable, rising or falling?

A short narrative can sit beneath the table: what changed this quarter, what constrained progress, and what decision is requested. For example, the board may be asked to approve a maintenance window, fund additional engineering capacity, or accept a defined exception until a supplier releases a fix. Each request should be specific enough to approve or reject.

Directors should also be given a confidence note. If agent coverage improved during the quarter, the apparent rise in findings may reflect better visibility rather than deteriorating security. If a scanner was misconfigured for part of the period, that should be disclosed. Calm presentation does not mean softening the facts; it means making them interpretable.

Linking exceptions to Cyber Essentials and insurers

Accepted exceptions should be kept in a register that can be reconciled with the organisation's Cyber Essentials scope. Cyber Essentials expects security updates to be applied within 14 days of release for high and critical vulnerabilities, where they are in scope. An exception does not automatically breach the scheme, but it needs a documented, risk-based rationale and appropriate compensating controls. The quarterly statement should show which exceptions affect in-scope systems and when they are due for review.

The same evidence is increasingly useful at insurance renewal. Cyber insurers and brokers commonly ask about patch management cadence, known exploited vulnerabilities, endpoint coverage and exception handling. A concise quarterly statement provides a consistent answer across the year rather than a last-minute reconstruction before the questionnaire arrives. It also demonstrates that exceptions are governed rather than ignored, which is usually more persuasive than a claim that no vulnerabilities exist.

A quarterly rhythm with monthly mechanics

The statement should be produced quarterly for the board, but maintained monthly by the operational team. A monthly review keeps the data current and prevents a quarterly scramble. The quarterly version can then focus on trends, exceptions and resource decisions rather than raw extraction.

Assign a single owner for the statement, usually within IT or security, and a reviewer from the business. Agree the severity threshold, the scope of endpoints and the effort bands in advance. Keep the format stable for at least four quarters; comparability is more valuable than cosmetic refinement.

The test of a useful statement

A patch debt statement has succeeded if a director can answer three questions after reading it: how much unfixed risk do we carry, how long has it been there, and what would it take to reduce it? It has failed if it produces a debate about scanner settings or a vague assurance that the team is working on it.

The aim is not to make patch debt disappear from the board agenda. It is to make it legible, owned and subject to normal management discipline. For UK SMEs in 2026, that is a more realistic ambition than a zero-vulnerability claim — and a more useful one.