The Calendar as Control: A Monthly Patching Rhythm for Lean UK IT Teams

Ask an office manager when the company laptops were last updated and the honest answer is often "whenever the box popped up". That is rarely negligence. It is arithmetic. With no dedicated security team, patching competes with payroll, onboarding and the month-end accounts, and it loses almost every time until something goes wrong.

The resulting pattern is familiar to anyone who has reviewed a small estate: long quiet periods punctuated by a burst of activity after a scare, a client questionnaire or an awkward question from an insurer. The remedy is less about buying a tool than about owning a calendar. A fixed monthly rhythm, written down and defended, covers most of the exposure a small firm actually carries — and it produces the records that third parties increasingly ask to see.

Why a fixed date outperforms good intentions

Commercial software vendors have largely settled into a monthly cadence, and Microsoft's second-Tuesday releases have given the industry a shared reference point for two decades. A small firm does not need to mirror that date exactly, but it should adopt a date of its own and keep it. Predictability is the point: staff learn when to leave laptops switched on, the person doing the work can block out the time, and the task stops being renegotiated every month.

A useful compromise is to schedule the main patching window for the week following the vendor release cycle. That gives a few days for early reports of breakage to surface, while still keeping exposure to known vulnerabilities measured in days rather than months. Firms with a low tolerance for risk — those handling client data under contract, for example — may choose to act sooner on critical items.

Sort the estate into three tiers

Patching everything at once is neither practical nor necessary. What matters is that the ordering is deliberate rather than accidental. A workable division for most small organisations looks like this.

Tier one — the exposed edge. Browsers, email clients, remote access gateways, firewall and router firmware, and any device enrolled in multi-factor authentication. These are the components most likely to be probed from outside. Critical fixes should be applied within a few working days of release; everything else within the week.

Tier two — the everyday endpoint. Staff laptops and desktops, productivity suites, and the line-of-business applications that sit on them. A fortnightly cadence within the monthly cycle is usually sufficient, with a small pilot group updated first.

Tier three — the quiet corner. Meeting room systems, printers, network storage, door access controllers and any specialist equipment. Vendors here often publish advisories on their own schedule, so the monthly task is to check rather than to assume. Quarterly updates are commonly adequate, provided someone is looking.

The tier list itself should fit on half a page. If it needs a diagram, it will not be maintained.

The devices you cannot see

Hybrid working has broken the assumption that the estate passes through the office. A laptop that lives permanently at a kitchen table may go weeks without a wired connection, and a phone used for email and authentication is a computer in all but name. Three practical measures close most of the gap.

First, set update deadlines rather than update prompts. Managed devices can be configured to install pending updates on the next connection, with a forced restart after a stated grace period. Second, keep a small stock of loan machines so that a traveller with a failing update is not forced to defer it indefinitely. Third, decide explicitly what the position is on personal phones used for work — either they are enrolled and managed, or they are excluded and staff are told what that means.

Home routers deserve a mention. They sit outside the firm's control but often carry a VPN or remote desktop path into it. A line in the staff guidance asking people to check for router firmware updates twice a year costs nothing and closes an unglamorous gap.

Exceptions need a paper trail

Every small firm has at least one application that breaks when a particular update lands, usually something written years ago for a process nobody wants to revisit. The mistake is not having an exception; the mistake is having an undocumented one.

Record the affected device or system, the reason for deferral, who accepted the risk, what compensating control is in place, and when the position will be reviewed. A compensating control might be network isolation, restricted user permissions or a ban on storing client data on that machine. The record turns an invisible gap into a managed decision — and it demonstrates, if ever asked, that the firm knew what it was doing.

Evidence that satisfies insurers and clients

Cyber insurance renewals and client security questionnaires now routinely ask for a description of the patch management process. A firm with a monthly calendar can answer in a paragraph; a firm without one tends to answer in adjectives.

Keep the evidence simple. One row per month recording the date of the cycle, the systems covered, the personnel involved, the number of devices outstanding and any exceptions raised. A screenshot from a management console is acceptable supporting material, but the log is what gets read. Twelve rows built up over a year say more about a firm's discipline than any policy document.

A one-page calendar worth keeping

A routine that survives a busy month is short, owned and time-boxed. Roughly ninety minutes a month, split across four weeks, is realistic for most small firms.

• Week one: read the vendor advisories, note anything critical, and confirm the pilot group for the month.
• Week two: apply tier one updates and start tier two on the pilot group.
• Week three: roll tier two to everyone, then review which remote devices have checked in and chase the stragglers.
• Week four: handle firmware and mobile devices, review open exceptions, and complete the monthly log entry.

Name a single owner and a named deputy. Where the IT function is a team of one, the deputy is usually the person who covers leave — and the calendar should be legible enough that they can run it without a handover conversation.

Starting this month

November is an unglamorous but sensible moment to begin. The year's final vendor cycles are landing, staff are beginning to think about leave, and a baseline taken now will hold through the quieter weeks of December.

Begin with a short inventory: how many devices, which operating systems, and when each was last updated. That single exercise usually reveals more than a purchased tool would in its first month. Then fix the date for the first full cycle, put it in the shared calendar with the owner's name against it, and treat it as an appointment rather than a task.

The argument for this approach is not that a calendar replaces good tooling. It is that tooling without a rhythm quietly decays, while a rhythm maintained by one conscientious person keeps a small estate materially safer than many larger ones. Patch management, at this scale, is a habit before it is a product.