Another notification appears about a critical vulnerability. Somewhere in a system you probably use. Or maybe not, you don’t know for sure yet. A hectic search follows: who manages this system, is it exposed at our company too, does something need to happen right now? By the time you have an answer, the weekend is already over and everyone just gets back to work. Until the next notification.
If this sounds familiar, you’re certainly not alone. It happens to most companies that lack a change process. And that’s exactly where we see the difference between companies that keep getting startled and companies that stay calm.
The pattern you probably recognise
The cycle is nearly identical at almost every company. A vendor or government agency reports a vulnerability. Someone within the company sounds the alarm, often whoever happens to read the news. A hurried check follows, patches get applied, and everyone hopes nothing goes wrong. If it works out, there’s relief and everyone moves on. Until the next notification arrives, and the whole cycle starts again.
The problem here isn’t that vulnerabilities exist. They always will, in every system, with every vendor. The problem is that there’s no fixed way to respond to them. Without a process, you react on reflex, and reflexes are unpredictable: sometimes fast and thorough, sometimes too late or half-done.
The real problem isn’t the leak, it’s the missing policy
What companies that keep panicking usually lack isn’t technical knowledge but a documented change policy. That’s nothing more than clear agreements about who gets to decide a system will be changed, how you test that the change won’t cause new problems, and how you communicate to everyone who works with it.
Without those agreements, everything depends on who happens to be paying attention that day, who’s reachable, and how much time there is before the weekend starts. With those agreements in place, it no longer matters whether it’s a critical vulnerability or a routine software update: the process stands, and the technology follows afterwards.
Measure first, then policy, then technology
At Motics we deliberately reverse the order most companies follow. Many companies reach straight for a technical solution when a new threat appears: an extra security tool, another scanner, an emergency patch. But without an overview of what you actually have running, you don’t know where that technology should even land.
That’s why we always start with measuring: which systems exist, who is responsible for them, and what is critical to keep your business running. Only once that’s clear do you set the policy: who may make changes, how you test, when you communicate. And only then does the technology follow that supports that policy. Reverse this order and you end up buying technology nobody uses properly, because there’s no process backing it up.
Bring people along before you make it mandatory
A change process only works if the people affected by it understand and accept it. An employee using a system needs to know why an update sometimes waits for a test window, and why another update is pushed through with priority instead. Explain that before you enforce it. Policy that gets imposed as a decree gets ignored the moment it becomes inconvenient. Policy that gets explained gets supported.
What you can do right now
You don’t need to build a complete process overnight. Start with these steps:
- Make a list of your critical systems: what can never go down, and who’s responsible for it.
- Decide who within your company is allowed to approve a change or patch, and within what timeframe.
- Agree on how you test before something goes live, even if that testing only takes a few hours.
- Determine who needs to be informed when something changes, and how you’ll do that.
These four points lay the foundation. They don’t require new technology, just time and attention to put it on paper.
Why this matters for NIS2 too
Under NIS2, companies are expected to demonstrate how they handle changes and vulnerabilities, not rely on gut feeling. A documented change process is exactly the kind of evidence that fits: it shows you’re not waiting for something to go wrong, but working structurally on control. Such a process may feel like one more obligation, but it follows logically from how you’d want to work anyway.
A few questions we’re often asked
Does a change process mean every update now takes longer?
Not necessarily. Critical vulnerabilities that are actively being exploited can be defined in your policy as an exception with a shorter turnaround time. The process determines the speed per situation, instead of speed being reinvented every time.
Is this only useful for companies with their own ICT department?
No, companies without an internal ICT department benefit even more. Without a documented process, everything depends on whichever ICT partner happens to respond fastest, whereas with a process in place, it’s clear beforehand who’s responsible for what.
How do I prevent the process itself from becoming a paper tiger?
Keep it small and practical: a handful of agreements everyone can recite works better than a thick document nobody reads. Test the process regularly against a real situation to keep it alive.
Do I need to set up this process separately for every system?
No, we prefer to look at coherent domains rather than individual systems, for example everything related to your business-critical workstations or your network. That keeps the process manageable and easier to maintain.
Curious what a change process would concretely look like for your company? We’re happy to think it through with you, starting from overview instead of panic.
