Every business running a system it cannot afford to break eventually arrives at the same meeting. The security report says patch. The operations head says the last patch cost us a day of production. Someone offers the compromise that always sounds reasonable: leave it alone, put it on its own network, run it in a VM, keep it away from everything else.
That compromise is not wrong. It is just rarely examined. Here is what is actually being bought.
Myth 1: “Patch everything, immediately”
This is the advice every compliance checklist gives and almost nobody follows. The Verizon 2026 Data Breach Investigations Report found that exploitation of vulnerabilities has, for the first time in the report’s 19 year history, overtaken stolen credentials as the most common route attackers take into a network. In the same dataset, across 13,000 polled organisations:
- Vulnerability exploitation is now the number one initial access vector.
- The median time to fully patch a vulnerability rose to 43 days, from 32 the previous year.
- Only 26% of the vulnerabilities on CISA’s Known Exploited Vulnerabilities catalogue had been fully remediated.
Read that as a confession, not a scolding. Patching is not failing because IT teams are careless. It is failing because patching a production system is itself a risk event: a maintenance window, a vendor dependency, a regression nobody predicted, and a business that stops earning while it happens.
So the honest position is not “patch everything.” It is decide, deliberately, what you will patch fast, what you will mitigate and what you will accept, and record who owns each decision. NIST’s guidance on enterprise patch management (SP 800-40 Rev. 4) frames it exactly this way: patching is one risk response among several, and choosing a different one is legitimate as long as it is chosen rather than defaulted into.
Most organisations do not have a patching problem. They have an undocumented risk acceptance problem.
Myth 2: “It is isolated, so it is safe”
Isolation is a real control. It is also the control that decays fastest, because nothing tells you when it has stopped working.
A segment drawn on a network diagram in March is not the segment that exists in November. A vendor needs remote access for a support call and gets a rule that never expires. A reporting requirement pushes a data pull across the boundary. A new server is racked into whatever VLAN had a free port. None of these are recorded as security changes, and each one puts another door in a wall you believe is solid.
On a lending client’s database estate, the assumption going in was that the legacy systems were fenced off. Discovery found more than 30 linked server trust paths across the instances, several reaching a separate network entirely, and hundreds of stored procedures and scheduled jobs traversing them, including objects handling KYC and credit bureau data. Nothing had been done maliciously. The estate had simply been alive for a decade, and every integration built in that decade was a hole punched through a wall the diagram still showed as intact.
From a recent engagement
Isolation is not a state you achieve. It is a claim you have to re-prove, on a schedule, with evidence.
Myth 3: “A VM makes it secure”
Virtualisation genuinely helps, just not in the way people say it does. A hypervisor boundary is not a security guarantee. A virtual machine on a flat network with a domain admin credential cached in it is exactly as compromised as the physical box it replaced.
What virtualisation actually buys you is reversibility. Snapshot before the patch, roll back in minutes if the vendor’s update breaks an interface, test the upgrade on a clone with production data instead of arguing about it in theory. We have taken clients from “we cannot patch this, it took six hours last time and half of it did not come back” to a twenty minute change window, purely by virtualising the workload first.
The VM is not what lets you avoid patching. The VM is what makes patching cheap enough that you stop avoiding it.
The cost that never reaches the risk register
Here is the part that turns a security conversation into a business one. When you isolate a system instead of modernising it, you pay in capability, and you pay every month, forever. The isolated system cannot feed the analytics layer. It cannot expose an API to the customer app. It cannot exchange data with the partner who now insists on integration as a condition of the contract. It cannot be moved, and neither can anything that depends on it.
We assessed a hospital information system running on an operating system and application runtime that both passed end of support years ago. Isolation was the instinctive answer: keep it on its own segment, restrict access, carry on. It was also the reason the hospital could not build a patient-facing appointment flow, could not get clean data into a clinical dashboard, and could not honestly answer a question about where personal health data went. Under India’s DPDP Act, “we put it on a separate VLAN” is not an answer to a data principal’s grievance or a regulator’s query. The wall protected the system. It did not protect the obligation.
From a recent engagement
That is the real trade. Not patch versus isolate. It is remediate the system, or accept that everything you want to build for the next three years has to route around it.
What a defensible isolation decision looks like
If you choose isolation, choose it properly. A compensating control that survives an audit, an incident review or a serious customer’s security questionnaire has all of the following, in writing.
- A named owner. A person, not a department.
- An expiry date. Isolation is a bridge with a far bank. Without a funded plan to reach it, you have not mitigated the risk. You have deferred it and stopped counting.
- Default deny egress, not just ingress. Most damage travels outward from the compromised box.
- Brokered access. Vendor and admin access through a jump host with MFA and session logging, with rules that expire by default.
- Monitoring that assumes failure. Alert on traffic crossing the boundary, because eventually it will.
- Periodic proof. Test annually that the segment still holds, and treat the result as a board-level fact.
And prioritise on real exploitability, not severity scores alone. A vulnerability on CISA’s Known Exploited Vulnerabilities catalogue is being used against real organisations right now. A high CVSS score on a component nobody can reach from anywhere is a different problem with a different urgency.
The question to ask about every system nobody wants to touch
Is anyone actually exploiting this in the wild? Does this box sit on a path to something that would hurt us if it left, whether that is money, patient records or customer identity data? And what have we given up in the last two years because this system had to stay in its box?
If the answer to the third question is “quite a lot,” you are not managing risk any more. You are financing it.
Arsenal IT Consultants helps SMBs and healthcare organisations decide what to patch, what to isolate and what to replace, then executes the plan across ERP, database and infrastructure estates. If you have a system nobody wants to touch, a short assessment is usually enough to tell you what it is really costing you. Get in touch.
One Response