"If it works, do not touch it" was a defensible engineering instinct in an era when the biggest threat to a working system was a botched change. That era is over. The biggest threat to a working system today is that somebody else touches it first, remotely, at scale, using a flaw that was published and patched two years ago.
The phrase has quietly changed legal category. It used to read as prudence. In an incident review, an insurance claim or a regulator's file, it now reads as a documented decision to accept a known risk. That is a governance position, and governance positions belong on the board's desk, not in the head of whoever happens to be on call.
The phrase changed category, from prudence to finding
Nothing about the words changed. What changed is that the risk behind them is now enumerated, dated and public. When the flaw in your version sits in a public catalogue of issues attackers actively use, choosing not to touch it stops being a technical preference and becomes evidenced acceptance of a named risk.
- ▸The evidence is external now. Anyone can check whether a class of flaw is being exploited in the wild. The CISA Known Exploited Vulnerabilities catalogue exists precisely so defenders stop guessing which issues attackers actually reach for.
- ▸The dates are external too. Vendor end-of-support dates are published years in advance. The Microsoft product lifecycle pages tell you, and everyone else, the exact day a platform stops receiving security fixes.
- ▸Silence is not neutral. A decision nobody wrote down is still a decision. It simply has no owner and no review date, which is the worst possible combination when an investigator asks who accepted the risk and when.
The uncomfortable symmetry: an attacker's reconnaissance and an auditor's evidence pack are assembled from the same public sources.
Duty of care now has a technical floor
Directors owe a duty of care that includes oversight of foreseeable operational risk. Foreseeable is the load-bearing word. A published flaw in a product whose support ended eighteen months ago, running on a system that holds customer data, is not an unforeseeable event. It is a scheduled one that nobody scheduled.
- ▸Foreseeability is documented for you. Public catalogues, vendor lifecycle pages and national framework guidance define what a competent operator should have known. The NIST Cybersecurity Framework supplies the vocabulary of govern, identify, protect, detect, respond and recover, which is also the vocabulary an investigator will use to structure their questions.
- ▸Delegation moves the work, not the accountability. You can outsource patching. You cannot outsource the duty to know whether patching is actually happening.
- ▸"Nobody told us" fails when nobody built a way to be told. If there is no asset inventory and no patch reporting, the absence of bad news is not good news. It is the absence of a control.
Practical translation for a board: you do not need to understand the exploit. You need to be able to show that you asked, were answered in writing, and set a date.
Your insurance policy is a technical standard in disguise
Read your cyber policy as an engineering specification, because that is what it is. Proposal forms and warranties ask about multi-factor authentication, backup isolation, patch cadence, endpoint detection and supported software versions. Every answer is a representation, and every representation is a condition you must keep true after signing, not just on signing day.
- ▸The MFA question is rarely about any MFA. Push approvals and one-time codes are phishable in ways hardware-bound factors are not, a distinction set out in CISA guidance on implementing phishing-resistant MFA. If your legacy application cannot sit behind a modern identity provider, you may be answering yes for the estate and no for the crown jewels.
- ▸Supported software is a common condition. A policy written on the assumption of vendor-supported systems sits badly next to a decade-old runtime that no longer receives fixes.
- ▸Renewal is an audit you did not schedule. The cheapest moment to discover that your control story has holes is at renewal, not at claim time.
If a legacy system would make you hesitate before answering an insurer's questionnaire honestly, you already know what belongs on the risk register.
Breach disclosure turns a private trade-off into a public one
Modernisation deferrals used to stay internal. Disclosure duties ended that. When an incident is reportable you do not only describe what happened, you describe what you knew and when you knew it. That is the moment a two-year-old upgrade ticket marked "deferred, revisit next year" becomes the most expensive sentence in the file.
- ▸Notification runs on clocks, not on readiness. Reporting windows are short and start when you become aware, not when your investigation becomes comfortable.
- ▸Customers read the same disclosure. Enterprise procurement now asks for incident history, and a root cause of "known issue, deferred" damages trust far more than a novel attack does.
- ▸Your artefacts write the narrative. Tickets, minutes and email threads become the record. Good governance is largely the habit of leaving a defensible trail before you need one.
The EU has put deferred upgrades on a named person's desk
Two pieces of EU law changed the ownership question. The NIS2 Directive places cybersecurity risk management under the accountability of the management body for in-scope essential and important entities, with supervision and incident reporting attached. The Cyber Resilience Act attaches security and vulnerability-handling duties to products with digital elements placed on the EU market.
- ▸Scope reaches past the obvious sectors. In-scope entities push requirements down their supply chain by contract, so a supplier who is not directly regulated inherits the obligations anyway.
- ▸If you ship software or connected products, you are on the product side of this. Vulnerability handling and a defined support period become part of what you sell, not an internal courtesy.
- ▸North African exporters selling into the EU feel it too. Market access is the trigger, not where you are incorporated.
The practical effect for a business owner is simple. A deferral now needs a name, a rationale and a date, on a document that somebody signs.
What "it works" is actually hiding
"It works" describes the happy path under normal conditions. It says nothing about the three failure modes that produce most incidents: the unpatched internet-facing service, the credential that still works because nobody rotated it, and the dependency nobody has updated since the original build.
- ▸Internet-facing and unpatched is the most reliable entry route there is. Attackers scan the internet continuously, and the window between a public fix and broad exploitation is short.
- ▸Credentials leak sideways. Infostealer malware harvests saved passwords and live session cookies from staff devices, and a stolen session bypasses the password check entirely. Credential stuffing then replays those pairs against every other system you own.
- ▸Abandoned dependencies rot in silence. A library that stopped receiving maintenance does not send you a letter. It simply stops getting fixes while your build keeps pinning it, which is how supply chain compromise, typosquatting and package confusion find their way in.
For the concrete, control-by-control version of this on the web side, our small business website security checklist for 2026 walks the same ground.
Turning the deferral into a governed decision
You do not have to modernise everything to fix the governance problem. You have to stop making the decision invisibly. A deferral that is written down, owned, priced and dated is a legitimate business choice. The same deferral living only in an engineer's head is a liability.
Four artefacts do most of the work:
- ▸An asset and version inventory, marking what is internet-facing and what holds personal data.
- ▸A support status column, sourced from vendor lifecycle pages rather than from memory.
- ▸A named owner per system at management level, not only a technical custodian.
- ▸A dated decision per legacy item: modernise, contain, or accept with a review date.
Containment counts as progress. Taking a system off the public internet, putting it behind an identity-aware proxy, segmenting its network and holding isolated offline backups all cut exposure while you plan the rebuild. That is also why what website maintenance should actually include matters far more than the monthly invoice suggests.
Where modernisation actually pays the governance bill
Rebuild where risk, cost and strategic value line up. That is usually the internet-facing system holding customer data on an unsupported stack. It is the one that fails an insurer's questionnaire, features in a disclosure narrative and blocks an enterprise deal, all at once.
- ▸Public web estate first. Ageing CMS installs carrying dozens of third-party plugins are the classic case, which is exactly why we wrote the WordPress security reality check every business owner avoids.
- ▸Then the systems of record. Long-lived business software holds the data that makes an incident reportable, and the route out is well trodden, as set out in escaping SaaS and migrating to custom software.
- ▸Keep the evidence as you go. A software bill of materials, patch records and access reviews turn the modernisation itself into the paperwork your auditor and your insurer both want to see.
How TuniCyberLabs helps
We run legacy modernisation as a governed programme, not a rewrite gamble. That means an inventory and exposure map first, a written risk decision per system with an owner and a date, containment for whatever is not being rebuilt this year, then a phased rebuild of what matters most, with software bills of materials, patch pipelines and phishing-resistant identity controls built in from the start. Engineering in Tunisia, contracting from Estonia, delivering across the EU and North Africa.
Tell us which system you are afraid to touch, and we will tell you what it takes to touch it safely: see how we work.