EU Presidency Series: Securing Irish Government in a High-Stakes Year #3
The majority of successful cyberattacks do not exploit cutting-edge, zero-day vulnerabilities. They exploit known weaknesses — flaws that software vendors identified, issued fixes for, and published to the world. In many cases, the organisations that fell victim had the patch available to them for months before the breach occurred.
This is the uncomfortable truth about patch management: most of the damage it prevents is entirely avoidable. And for Irish public sector organisations operating under heightened threat during the EU Presidency period, “we’ll get to it eventually” is not a policy — it’s a liability.
Why patching falls behind
Before examining what good patch management looks like, it’s worth being honest about why it so often slips. The reasons are rarely negligence. They are almost always structural.
- Operational continuity pressure. Applying patches — particularly to critical systems — often requires downtime or restarts. In organisations where systems run continuously and downtime requires sign-off across multiple stakeholders, patches get deferred.
- Testing requirements. In complex environments, a patch to one system can break functionality in another. Proper testing before deployment takes time that busy IT teams frequently don’t have.
- Legacy infrastructure. Older systems may no longer receive vendor patches at all — they have reached end of support and are essentially undefendable through conventional means. Many organisations are not fully aware of how much of their estate falls into this category.
- Sheer volume. A mid-sized organisation might be managing hundreds of systems across servers, endpoints, network devices, and applications. The volume of patches released across all of those in any given month is substantial.
None of these are reasons to stop patching. They are reasons to have a proper system for doing it.
The risk of falling behind
When a software vulnerability is publicly disclosed, it typically takes threat actors a matter of days — sometimes hours — to begin scanning for and exploiting unpatched systems. This is known as the exploitation window, and it has been shrinking consistently over recent years.
During a period of elevated targeting of Irish government systems, that window matters acutely. Attackers who are actively looking for ways into Irish public sector networks will scan for known, unpatched vulnerabilities as a first step. An organisation that is weeks or months behind on patches is, in effect, advertising its weaknesses.
The Cybersecurity and Infrastructure Security Agency (CISA) in the United States publishes a list of known exploited vulnerabilities — a catalogue of weaknesses that are actively being used in real-world attacks right now. Cross-referencing your patch status against that list is a sobering exercise for most organisations.
What a mature patch management programme looks like
Effective patch management is not simply “apply all patches as fast as possible.” It requires a structured approach that balances speed, risk, and operational reality.
- Asset inventory as the foundation. You cannot patch systems you don’t know exist. A current, accurate asset inventory — covering hardware, software, and firmware — is the prerequisite for everything else. This connects directly to the risk assessment work covered in the previous post in this series.
- Prioritisation by criticality. Not all patches carry the same urgency. Patches addressing actively exploited vulnerabilities in internet-facing systems demand immediate attention. Patches for low-severity issues in non-critical internal tools can be scheduled. A good patch management process makes this distinction explicitly and consistently.
- Defined SLAs for remediation. Best practice defines clear timelines for patch deployment based on severity: critical patches within 24–72 hours, high severity within two weeks, medium severity within a month. Having those targets written down and tracked is what separates a patch management programme from ad hoc activity.
- Testing environments. Where operationally feasible, patches should be tested in a non-production environment before deployment to live systems. This is especially important for core infrastructure.
- End-of-life system management. Systems that no longer receive vendor patches need a risk management strategy of their own — whether that is network isolation, compensating controls, or an accelerated replacement programme.
- Reporting and accountability. Someone in the organisation needs to own patch compliance as a metric and report on it regularly. Patch management that is nobody’s specific responsibility tends to drift.
Your action this fortnight
Pull a current report on patch compliance across your estate. Focus first on internet-facing systems and anything that handles sensitive data. Identify your oldest outstanding critical patches and set a deadline to resolve them. If your team doesn’t have visibility into patch status across the full estate, that gap itself needs to be addressed urgently.
The goal is not perfection — it is reducing your exploitable attack surface to the smallest it can practically be, as quickly as possible.
Paradyn helps Irish public sector organisations build and operate structured patch management programmes that are realistic, measurable, and effective. To set up a conversation about your current patch posture, reach out to the Paradyn team today.
