A patch cadence is a written schedule stating what gets updated, how often, who does it, and how the work is recorded. To set one, list everything in your environment that receives updates, group those items into a handful of classes, give each class a frequency and a named owner, write down how an exception gets approved, and decide in advance what record proves the update happened. The schedule is the easy part; the record is what makes it real.
This article is general information about security administration and recordkeeping. It is not legal, compliance or security advice. Which frameworks and obligations apply to an organization varies by industry, size and jurisdiction, and those questions belong with a qualified professional who knows your situation.
Everything below is policy and recordkeeping. It covers how you schedule and document the work, not how any particular system is configured.
Start from a list of what actually needs updating
You cannot schedule updates for things you have not written down. Pull the list from your asset inventory if you keep one, and build it from scratch if you do not.
Six groups cover almost every small business:
- Operating systems on laptops, desktops, phones and tablets.
- Browsers and the extensions in them, which update on their own schedule and are easy to forget.
- Desktop applications people install locally, including the one-off tools a single person depends on.
- Server and on-premises systems, if you have any.
- Network and connected equipment, including routers, access points, printers and anything else with its own firmware.
- Hosted services and the add-ons inside them, where the provider updates the platform but you still own whatever you have installed, configured or extended.
Write the owner of each group beside it before you go any further. A group without an owner will not get a cadence that holds.
Group items into classes rather than scheduling each one
Scheduling every item individually produces a document nobody maintains. Three or four classes are enough, defined by how disruptive an update is and how much the item matters to the business.
| Class | What goes in it | Frequency | Approval to proceed |
|---|---|---|---|
| Routine, low disruption | Staff laptops, phones, browsers, everyday applications | Monthly, on a set week | None needed; owner proceeds |
| Business critical | Systems the work stops without | Monthly, in a named maintenance window | Owner notifies in advance |
| Infrastructure and firmware | Network equipment, on-premises servers | Quarterly, or when the supplier issues one | Owner schedules with notice |
| Out of cycle | Anything the supplier flags as needing attention sooner | As soon as the owner can schedule it | Owner decides and records the reason |
Two notes on that last row. Keep an out-of-cycle route in the policy, because a schedule with no fast path will be broken rather than followed the first time something needs attention. And do not write a target time into it. A commitment you cannot consistently meet is worse in a record than an honest “scheduled by the owner as soon as practical, with the date recorded”.
Pick the specific days. “Second Tuesday for routine, last Thursday evening for critical systems” is a cadence. “Monthly” is an intention.
Write down who does the work and who is told
A patch cadence needs three roles filled by name, and in a small business two of them may be the same person. That is fine as long as it is written.
The owner of each class is accountable for the schedule being kept and the record being complete. The person doing the work may be the owner, an internal colleague or an external provider. The person notified is whoever needs to know a system will be unavailable, usually a team lead or the whole staff for a shared system.
If an external provider does the work, the policy should say what they send you afterwards and when. A provider doing excellent work who sends you nothing leaves you with no record, and the record is the part you are asked for. Name the report you expect, not a deadline for it.
Pre-update steps worth putting in the policy
Three lines in the policy head off most of the trouble.
State that a current backup exists before a business-critical or infrastructure update proceeds, and that the person doing the work confirms it. State that updates to business-critical systems happen in the named window rather than during the working day. And state who decides to roll back and what gets written down if they do, because a rollback with no note turns into an unexplained version mismatch months later.
How to record exceptions in your patch cadence
Some things will not be updated on schedule. An item is mid-contract with a supplier, a vendor has not released a fix, a legacy application breaks when its host is updated, or a piece of equipment is past the point where the manufacturer issues anything at all. Those situations are normal. Leaving them undocumented is the problem.
Keep a single exceptions register with six columns:
- The item, named specifically enough to find.
- What the exception is — skipped this cycle, held at an older version, no longer receiving updates from the supplier.
- Why, in one honest sentence.
- Who approved it, by name. This should be someone senior to the person who raised it.
- What is being done instead, if anything, and who owns that.
- The review date, which is never blank.
An exception with a named approver and a review date is a managed decision. An exception with neither is a gap you will discover at the worst moment. Review the register on the same cadence as your most frequent patch class, and close out the entries that no longer apply rather than deleting them.
Watch for exceptions that have been renewed four quarters in a row. That pattern usually means the underlying item needs a decision at the business level rather than another extension.
How to evidence that the patching happened
Decide in advance what counts as evidence, because deciding afterwards means reconstructing it from memory.
The simplest workable record is a log with one row per cycle per class: the date, the class, the items covered, the person who did the work, anything that failed or was deferred, and where the deferred items were written into the exceptions register. One sheet, appended monthly. It takes a few minutes and it is the document that answers the question.
Supplement it with whatever your systems produce on their own. A management console report, an emailed summary from a provider, or an exported device list showing versions and last-updated dates are all stronger than a typed assertion, because they were not written by the person claiming the work was done. Save them into a folder named by month so the folder itself shows the sequence.
Record the misses too. A cycle that was skipped, and why, belongs in the log. A log with no gaps across two years reads as a log that was filled in once, and an honest record with three explained gaps is more credible than a perfect one.
Keep a short note of who reviews the log and how often. A monthly glance from the owner, dated, is enough to show the record is in use rather than being accumulated and ignored.
Keeping the patch cadence alive
Review the policy itself once a year and whenever your environment changes materially: new equipment classes, a new provider doing the work, or a system moving from on-premises to hosted. Note the review date and what changed, and keep the superseded version.
Three signs the cadence has quietly stopped working: the exceptions register is growing faster than it is closing, the log has not been written in two cycles, or nobody can name the owner of a class. All three are fixable in an afternoon if you catch them, and all three are visible from the record you are already keeping.
To see how your update schedule and its records sit against the rest of your security administration, work through the Free Cyber Security Scorecard page on this site and use the weakest area as your starting point.