Twice in the same week, a business can receive two contradictory pieces of advice that are both correct. The first: install security updates immediately, because the latest monthly patch cycle fixed hundreds of vulnerabilities, including flaws already being exploited by attackers. The second: be careful with updates, because that same patch bundle has been breaking things for some users - working software that crashed after the update, followed by the vendor publishing workarounds. Neither piece of advice is wrong. The uncomfortable truth is that updating promptly and updating safely are in genuine tension, and a business that resolves the tension with a reflex - always instantly, or always later - has chosen its failure mode rather than managed it.
The case for speed is unambiguous where active exploitation is involved. When a flaw is public and attackers are already using it, every day unpatched is a day exposed, and the businesses that get compromised through known, fixable holes are overwhelmingly the ones that deferred the fix. The case for caution is equally real: modern updates are large bundles touching many components, and even careful vendors ship regressions. For a business, an update that breaks the point-of-sale system, the accounting software, or the one machine running a critical legacy tool is not an inconvenience - it is downtime, and downtime during working hours can cost more than some security incidents. Pretending either risk away is how businesses end up either breached or broken.
The resolution used by organisations that handle this well is not a compromise but a sequence: stage the rollout. Update one or a few representative machines first - ideally ones whose disruption would be survivable - let them run the real daily workload for a short period, and then roll out to everything else once nothing has caught fire. For genuinely urgent, actively exploited flaws, compress that period to hours rather than days; for routine updates, a few days of soak time is reasonable. Keep backups current so that even a bad update is a recoverable event rather than a disaster. And know how to pause or roll back an update before you need to, because discovering the rollback procedure during the outage is the expensive way to learn it.
For a small business without an IT department, the same logic scales down to something almost trivial: let updates install promptly on most machines, but keep one critical system on a short delay and make sure the data on everything is backed up. What does not scale down is ignoring the problem in either direction. The business that switches updates off because one broke something once is accumulating known holes that attackers scan for automatically; the business that lets every update land everywhere simultaneously on patch day is betting its uptime on a stranger's testing. A staged rollout costs a little patience. Both alternatives cost considerably more, and the recent months of huge patch bundles - urgent fixes and regressions arriving in the same download - suggest the tension is not going away.