Patch Governance: Evidencing a Programme, Not a Deployment

Teams preparing for their first serious audit consistently misjudge which part will be difficult. They prepare the technical story — how patching is performed, what tooling drives it, how quickly critical updates are applied — and are then asked a question they cannot answer from that material: show me.

Patch deployment is an engineering activity. Patch governance is an evidential one. They use the same underlying facts but they are answerable to different standards, and a team can be excellent at the first while being unable to produce the second.

What an auditor is actually asking

The auditor is not testing whether patches were applied. They are testing whether you operate a control — that is, a defined, repeatable process with a stated scope, a stated frequency, evidence that it ran, and a documented treatment of the cases where it did not work.

That distinction explains behaviour that otherwise looks perverse. An estate that is ninety per cent patched with clear records of the remaining ten per cent, why each was excepted, who approved it and when it will be resolved, will pass. An estate that is entirely patched with no records will not, because there is nothing to examine. From the auditor's position the second estate is indistinguishable from one that claims to be patched.

The four things evidence must establish

Scope. Which machines were in scope for this control, during this period? This is harder than it looks in a real estate, because the population changes constantly. Machines are enrolled, decommissioned, rebuilt and reassigned. Evidence that does not establish scope invites the question "what about the machines not on this list", and that question is much harder to answer retrospectively than to prevent.

Execution. That the process ran, on those machines, within the stated frequency. Retained per-endpoint patch inventory plus an action log recording who dispatched which operation and when produces this directly. A screenshot of a dashboard does not, because it shows today rather than the period in question.

Exceptions. Which machines were not patched, why, who accepted the risk, and what the remediation plan is. This is the part teams omit, and it is the part auditors care most about — because exceptions are where control programmes actually fail, and a report showing none reads as incomplete rather than exemplary.

Verification. That someone checked the result rather than assuming the deployment succeeded. A patch dispatched is not a patch applied; machines are offline, installs fail, users defer reboots indefinitely. A re-scan after a patch cycle is the verification step, and it is the difference between reporting intent and reporting outcome.

Why retrospective evidence is expensive

The costly pattern is familiar. Audit is scheduled. A team spends several weeks reconstructing nine months of activity from change tickets, email threads, tool exports and the memory of whoever was on shift. The result is incomplete, internally inconsistent in places, and consumed the time of exactly the people the business could least spare.

It is also less credible, and reasonably so. Evidence assembled by someone who already knows what conclusion is required is weaker evidence than a record produced as the work happened, and auditors are trained to notice the difference.

The alternative is not more effort. It is earlier effort. If patch inventory is retained continuously and every dispatched operation is logged with an actor and a timestamp, the audit response becomes a scoped export rather than a project. The same facts, gathered as a by-product of doing the work instead of as a special exercise afterwards.

Setting a defensible policy

The most common self-inflicted audit finding is a policy the organisation cannot meet. A published commitment to apply all critical patches within seventy-two hours across every endpoint is admirable and, in an estate with field laptops and change-controlled servers, usually false. Every month you miss it is a documented deviation from your own stated control, which is worse than a longer target you actually hit.

Write the policy you can evidence. Differentiate by class of machine, because a domain controller and a warehouse tablet do not warrant the same window and pretending otherwise helps nobody. Define what an exception is, who can approve one and how long it lasts. Then meet it, consistently and boringly.

A control you meet every month at a modest standard is worth considerably more than an ambitious one you miss a third of the time.

Practical sequence

Establish scope first — a defensible per-client, per-period list of machines in scope. Then ensure execution is recorded rather than merely performed. Then build the exception register, and make raising an exception easy enough that engineers do it instead of quietly leaving a machine out. Then add verification by re-scanning after each cycle. Then, and only then, worry about tightening the windows.

Teams that do this in the opposite order — tightening targets before they can measure whether they are met — produce impressive policies and unimpressive audits.