Nearly every week brings another notice about a vulnerability that needs attention fast. The tone is usually the same: fix this now, or you’re at risk. For many business owners that feels like a kind of reflex. An update arrives, and it gets installed as quickly as possible. Understandable, but also risky. Because who actually decided this had to happen right now, on this system, at this moment? And who considered what happens if that update affects something it wasn’t meant to touch?
An update is a decision, not a reflex
An update looks like a technical action. Press a button, the system restarts, done. But in a business with a production line, a warehouse system, or transport planning, it works differently. An update can break a connection, stop a machine, or delay a process that’s running at exactly that moment. Sometimes fast action is needed, for instance when a vulnerability is being actively exploited. But acting fast without a process isn’t safety. It’s trading one risk for another.
Measure first, then choose
You can’t make a decision about something you can’t see. Before you decide whether an update is rolled out immediately or tested first, you need to know exactly which systems it touches. Which application runs on which server, which department depends on it, and what happens if that system is unavailable for a few hours? Many businesses lack that overview, and without it an update becomes a gamble instead of a considered choice. That’s why we always start with an inventory: what do you have, what does it affect, and what’s the impact if something goes wrong.
Policy before technology: who decides, and within what timeframe
Once the overview is in place, the next step is to establish who gets to make the decision and within what timeframe. Not every update carries the same urgency. A critical vulnerability that’s actively being exploited calls for a different approach than a routine update to an office application. Decide who can approve an immediate rollout, and who determines that something should be tested first in an environment outside production. This doesn’t need to be a heavy document. It’s a handful of agreements that prevent a decision from being made under time pressure, by whoever happens to read the notice first.
Bring people along before you make something mandatory
A policy only works if the people affected by it actually understand it. A production supervisor who suddenly learns, mid order, that an update is being rolled out reacts very differently from someone who already knows when these moments are planned. That’s why we always take the time to discuss with the people on the floor what a change means for their work, before we make it mandatory. That prevents resistance, and it prevents an update from quietly being postponed because no one thought the timing was right.
Thinking in domains, not in loose updates
A patch never stands on its own. It’s part of a broader domain of change management, which also includes asset management, access control, and recovery procedures. That’s why we don’t treat an update as a standalone task to check off a list, but as part of a process that we document together with you and can demonstrate. That’s exactly what matters for organisations working to become demonstrably aligned with NIS2: not a feeling that things are probably fine, but a process that shows who decided, when, and on what basis.
What you can do now
- Build an overview of your systems and how they depend on each other, so you know what an update can affect.
- Decide who has the mandate to choose between an immediate rollout and testing first, and set timeframes per urgency level.
- Talk to the people doing the work about when changes fit their schedule, and when they don’t.
- Make patching a standing part of your change process, instead of something you figure out the moment a notice comes in.
A few questions we’re often asked
Does this mean critical updates should always be tested first?
No, not necessarily. For a vulnerability that’s actively being exploited, rolling it out immediately can be the right call. The point is that the choice is made deliberately by someone with the mandate to do so, based on what you know about the impact, rather than automatically because the notice just arrived.
Who in our business should be making this decision?
That differs per organisation, but it should be someone who understands both the technical impact and the business impact. Often that’s the owner together with whoever handles ICT management, working from criteria agreed on in advance, so the discussion doesn’t have to start from scratch with every notice.
How long does it take to set up a process like this?
The initial inventory and basic agreements can often be done within a few weeks. It isn’t a project you finish once. It grows along with your business as systems change and new dependencies appear.
What if we don’t have a test environment at all?
That doesn’t need to mean a separate investment right away. Often part of your existing infrastructure, or a temporary copy of a system, is enough to test for the biggest risks before you go live.
Curious what change management looks like in your business, and who actually decides on updates right now? We’re happy to think it through with you.
