Patch governance is not patch deployment

Teams preparing for their first serious audit almost always prepare the wrong material. They document how patching works — the tooling, the cadence, how quickly critical updates go out. Then the auditor asks a question that material cannot answer, and the room goes quiet.

The question is: show me.

Two different activities

Patch deployment is engineering. Get the update onto the machine, verify it applied, handle the machines that failed. It is measured by outcome, and a good team is good at it.

Patch governance is evidential. Demonstrate that a defined control operated, over a defined population, at a defined frequency, with documented treatment of the cases where it did not. It is measured by record, and being good at deployment gives you almost none of it automatically.

This explains something that otherwise looks perverse to engineers. An estate that is ninety per cent patched with clear records of the remaining ten — why each was excepted, who accepted the risk, when it will be resolved — passes comfortably. An estate that is entirely patched with no records does not. From where the auditor sits, the second is indistinguishable from an estate that merely claims to be patched, and they have seen enough of those to be unmoved.

The four things evidence must establish

Scope. Which machines were in scope, during which period. This is harder than it sounds, because the population moves constantly — machines enrolled, decommissioned, rebuilt, reassigned. Evidence that does not pin down scope invites the question "what about the machines not on this list", which is far harder to answer afterwards than to prevent.

Execution. That the process ran, on those machines, at the stated frequency. Retained per-endpoint patch inventory plus a log of who dispatched which operation and when gives you this directly. A dashboard screenshot does not, because it shows today rather than the period under examination.

Exceptions. Which machines were not patched, why, who accepted the risk, and what the plan is. This is the part everyone omits and the part auditors care most about, because exceptions are where control programmes actually break. A report showing none reads as incomplete rather than exemplary.

Verification. That someone checked. A patch dispatched is not a patch applied — machines are offline, installs fail, users defer reboots for a fortnight. Re-scanning after a cycle converts your report from a statement of intent into a statement of outcome, and it is the single cheapest credibility improvement available.

Why doing it afterwards costs so much

The familiar pattern: audit scheduled, four weeks of reconstructing nine months of activity from change tickets, email and the memory of whoever was on shift. The result is incomplete, inconsistent in places, and consumed exactly the people the business could least spare.

It is also weaker evidence, and reasonably so. A record assembled by someone who already knows what conclusion is required is worth less than one produced as a by-product of the work. Auditors are trained to notice which they are looking at.

The alternative is not more effort but earlier effort. If patch inventory is retained continuously and every dispatched operation carries an actor and a timestamp, the audit response becomes a scoped export. Same facts, gathered as the work happened.

Write a policy you can actually meet

The most common self-inflicted finding is a policy the organisation cannot hit. A published commitment to patch every endpoint within seventy-two hours is admirable and, in any estate with field laptops and change-controlled servers, usually untrue. Every month you miss it is a documented deviation from your own control — which is materially worse than a longer window you hit every time.

Differentiate by class of machine, because a domain controller and a warehouse tablet do not warrant the same treatment and pretending otherwise helps nobody. Define what an exception is, who approves one, and how long it lasts. Make raising an exception easy enough that engineers do it rather than quietly leaving a machine out of scope — an exception register with three entries in an estate of a thousand machines is not a good sign, it is an unused process.

Then meet the policy, consistently and boringly. A modest control you satisfy every month is worth considerably more than an ambitious one you miss a third of the time.

The order to do this in

Establish scope. Then make execution recorded rather than merely performed. Then build the exception register. Then add verification by re-scanning. Then, last, tighten your windows.

Teams that reverse this — tightening targets before they can measure whether they are being met — end up with an impressive policy and an unimpressive audit, which is the worst combination available.