Patching: the boring habit that prevents most breaches

Almost every breach story has a mundane middle. Somebody knew an update was needed. It never got applied. A month passed.

Why it keeps not happening

  • Nobody is named as responsible, so everyone assumes someone else did it.
  • Updates are applied only when something breaks.
  • One business-critical app is known to break on updates, so patching stops entirely rather than being handled as an exception.
  • There is no list of what you actually own.

Start with the list

You cannot patch what you have not inventoried. Build a simple sheet with one row per device and one per internet-facing service:

ColumnWhy it matters
Device or serviceThe thing you are protecting
OwnerA person’s name, not a team
What it runsOperating system and major software
Internet-facing?These get patched first
Last patchedThe date you actually applied updates
NotesExemptions, quirks, vendor contacts

A spreadsheet is fine. A perfect tool you never fill in is worse than a plain sheet you update monthly.

The monthly routine

  1. Week 1 — review. Read the vendor security advisories for what you actually run. Skip the rest.
  2. Week 2 — test. Apply to one non-critical machine and one willing user. Watch for breakage.
  3. Week 3 — deploy. Roll out to everything else. Reboot. Confirm the version numbers actually changed.
  4. Week 4 — verify and record. Spot-check a sample of machines. Update your sheet. Note what failed and why.

Internet-facing systems — firewalls, VPNs, mail gateways — do not wait for the monthly cycle. Those are patched within days of a critical advisory, because they are the ones scanned and attacked automatically.

The one exemption rule

Sometimes a system genuinely cannot be patched. That is acceptable, but only with compensating controls written down:

  • Isolated on its own network segment.
  • Reachable only through a specific access path, with MFA.
  • Backed up immediately before any change.
  • Reviewed every quarter, with a named owner and a removal plan.

Prove it rather than assuming it

Do not trust a status dashboard that says ‘compliant’. Take three random machines each month and check the actual version numbers by hand. Dashboards drift, agents stop reporting, and machines sit switched off for months.

If you have not looked at the version number yourself, you do not know it is patched — you know someone clicked something.

The minimum viable version

If a full programme is not realistic yet, do these four things:

  1. Name one person who owns patching.
  2. Write the inventory, even if it is rough.
  3. Patch internet-facing systems within a week of any critical advisory.
  4. Run one monthly cycle, and write down what happened.

Four small habits, repeated, prevent more real-world incidents than most security products you could buy this quarter.


Want this running for you, with the records to prove it? Talk to a specialist.