A patch cycle is more than a regular IT task. It is a recurring opportunity to check whether the technology estate you believe you manage still matches the one your business actually uses.
That distinction matters. A deployment report can show that updates were installed, but it cannot prove that every relevant device, application or supplier service was included. For UK SMEs working towards stronger Cyber Essentials controls or an ISO 27001-aligned information security management system, reliable patching depends on sound planning, clear ownership and evidence that stays current.
A consultancy-led approach starts with those business controls, not a software dashboard. The Fractal IT Director view is to define the risk, responsibilities and recovery priorities first, then use Managed IT Services and other technical support as execution services that serve the strategy.
Patch Tuesday is a trigger, not the whole timetable
Microsoft’s monthly Windows security update is normally released on the second Tuesday of each month. Microsoft also provides optional preview updates and can issue out-of-band updates when an issue cannot wait for the regular cycle. The schedule makes a useful planning anchor, but it is not a universal timetable: applications, firmware, cloud platforms and other suppliers may publish updates on different dates.
The Microsoft update release cycle explains those Windows release types. For an SME, the practical implication is simple: schedule a regular review around Patch Tuesday, but monitor relevant supplier advisories throughout the month. An urgent vulnerability should not sit untouched because it arrived on a Wednesday.
The NCSC recommends applying updates as soon as possible, ideally automatically where appropriate. Its best-practice timescales are shorter for internet-facing services than for internal or air-gapped systems. They are a useful basis for a risk-based policy, not a reason to skip assessment of business-critical dependencies.
What Cyber Essentials expects from update management
Cyber Essentials gives SMEs a defined baseline. Its current requirements include keeping in-scope software licensed and supported, enabling automatic updates where possible and removing unsupported software, or isolating it appropriately where there is a genuine business need.
For high-risk or critical security updates and vulnerability fixes, the requirements set a 14-day installation deadline where the vendor identifies the issue as high or critical, the vulnerability has a CVSS v3 base score of 7 or above, or the vendor provides no severity information. The requirement applies to operating systems, applications and relevant router and firewall firmware. The Cyber Essentials assessment preparation material sets out the detail.
That 14-day limit is a maximum for the specified fixes, not an ideal target for every situation. If a supplier reports active exploitation, the response may need to be much faster. An organisation should also avoid treating a successful update to its laptops as proof that everything is covered: cloud services, servers, network equipment and specialist applications may require separate checks.
A workable monthly routine could look like this:
- Identify what is affected. Compare supplier notices with an accurate list of devices, operating systems, applications and services.
- Set priority and ownership. Consider severity, exposure, business impact and any dependencies. Assign an owner and target date.
- Test and deploy proportionately. Where appropriate, use a staged rollout or a limited pilot, then expand deployment while monitoring for problems.
- Track exceptions to closure. Record failed installs, systems that need testing, compensating controls and the person responsible for resolving each exception.
- Reconcile the evidence. Confirm that deployment results match the asset list and that no part of the estate has quietly dropped out of view.
The precise process should reflect the systems in use. For example, a finance application with a tightly controlled maintenance window may need a planned test and approval route. That is different from ignoring an update: the decision, risk and next action should be visible.
ISO 27001 is about governance, not a magic Tuesday
ISO/IEC 27001 provides a framework for establishing and continually improving an information security management system. It does not turn the second Tuesday of the month into a universal patch deadline. Instead, it expects an organisation to understand its information security risks and manage them through defined responsibilities and controls.
That makes patching part of a larger management process: maintain a usable asset inventory, monitor relevant vulnerability information, assess risk, define response times, approve justified exceptions and review whether the process is working. The ISO guide to ISO/IEC 27001:2022 for SMEs is a useful starting point for understanding the standard.
A regular update cycle can support this governance by making decisions repeatable and evidence easier to review. But a calendar entry alone proves very little. An auditor or business leader needs to see what was in scope, which updates were relevant, what happened when deployment failed and whether unresolved risks were accepted by someone with the authority to do so.
This is where consultancy adds value. An experienced IT consultant can help set proportionate policy, establish ownership and align technical controls with business risk. The patching tools and Helpdesk Support can then carry out and record the agreed work; they do not replace oversight.
Connect patching to Disaster Recovery
An update changes the system you may later need to restore. That makes patch management relevant to Disaster Recovery as well as security.
Before a significant change, understand the available recovery point and the steps required to return the service to operation if something goes wrong. After deployment, confirm that important data and applications remain accessible and that backups continue to run. Periodically test restoration; a backup report is not the same as a successful recovery.
The recovery plan should account for dependencies beyond the server itself: identity and access, cloud services, network access, suppliers and the people authorised to make decisions. A patch that is installed correctly but leaves an essential workflow unavailable still needs a business response.
Specialist environments may need their own maintenance and recovery approach. Where a business relies on IBM i Management, for example, update planning should account for the supported platform, applications, interfaces and recovery arrangements rather than assume that a standard Windows cycle applies. David’s practitioner background in IT project management, multinational onboarding and system administration informs this kind of dependency-led planning.
Keep evidence useful by keeping it connected
Patch evidence has a shelf life. A report created last month may no longer represent the estate after a new device is added, an application changes or a supplier ends support. The aim is not to accumulate screenshots; it is to maintain a traceable link between assets, decisions and outcomes.
A practical evidence set might include:
- The asset and software inventory, with support status
- Supplier advisories and the assessment of their relevance
- Deployment records, including failed or deferred updates
- Approvals and expiry dates for exceptions
- Records of backup checks and recovery exercises
- Reviews of recurring gaps, ownership and corrective actions
Useful management measures include the age of outstanding high-risk fixes, repeated deployment failures, the number of unsupported assets and whether recovery tests meet agreed objectives. These indicators show where attention is needed; they are more useful than a single headline percentage without context.
The same review can inform Technology Expense Management. Outdated or duplicated licences, unsupported software and overlapping services can create avoidable cost and security exposure. Rationalisation should be based on business need and risk, not on removing support or recovery controls simply to reduce a line on an invoice.
Make the cycle fit the business
For a smaller organisation, a disciplined update process need not mean building a large security department. It means deciding who reviews advisories, how quickly different risks are handled, who approves exceptions and how deployment results connect to recovery planning.
Those choices also matter when core systems change. A Dynamics 365 Jump Start for Business Central should consider security updates, user access, integrations and recovery responsibilities alongside process and data requirements, not leave them until after implementation. The goal is a system that fits the operating model and can be supported over time, not simply a completed installation.
Cloud Solutions, Network Solutions and Voice and Connectivity may all have their own supplier update notices and support lifecycles. Treating them as part of the same governance calendar helps avoid a familiar blind spot: patching what is easiest to see while overlooking the service a team depends on every day.
Evestaff IT Support and Consultancy provides strategic IT consultancy and support for UK businesses, with specialist partners available where particular technical delivery is required. To explore the wider group, visit the Evestaff gateway.
SEO tags: Cloud Solutions, Disaster Recovery, Dynamics 365 Jump Start, Helpdesk Support, IBM i Management, Managed IT Services, Network Solutions, Technology Expense Management, Voice and Connectivity, Cyber Essentials consultancy, ISO 27001 consultancy, Patch Tuesday, vulnerability management, UK SME IT support
Join The Discussion