A patch management process is the routine of identifying, prioritising, testing, installing and verifying security updates for operating systems, applications, network devices and firmware. The goal is not to install every patch instantly, but to close actively exploited flaws first, without stopping the business, and with evidence that the fix actually landed.
Key takeaways
- Patch management is a continuous cycle of identifying, prioritising, testing, installing and verifying updates (NIST SP 800-40 Rev. 4).
- According to Verizon's 2026 DBIR, vulnerability exploitation became the most common initial access vector in breaches, at 31%.
- Priority depends not on a flaw's severity score but on whether it is being exploited and whether the asset is internet-facing.
- Systems you cannot patch (end-of-support operating systems, PLCs, SCADA) are protected with segmentation, restricted access and monitoring.
- "Deployed" is not the same as "installed"; every patch should be verified by a scan or version check and recorded.
What is patch management, and why are automatic updates not enough?
In most small and mid-sized companies, patching is left to the assumption that computers update themselves. The riskiest assets, however, usually sit outside automatic updates: the VPN appliance and firewall, the remote desktop server, the ageing server that runs the ERP, warehouse handhelds, IP cameras and shop-floor PCs. Described as "working, so don't touch it", they stay unpatched for months or years.
Part of the problem is ownership. Nobody is sure who approves a patch, which night it goes in, or who rolls it back if something breaks. The other part is visibility: a company without an asset inventory cannot say whether a newly announced flaw affects it, because it does not know which version runs where.
The US National Institute of Standards and Technology (NIST) publication SP 800-40 Rev. 4 defines enterprise patch management as identifying, prioritising, acquiring, installing and verifying the installation of patches, updates and upgrades, and frames patching as preventive maintenance and a normal cost of doing business. Treat it like the service schedule of any machine you depend on.
Why is delayed patching so risky?
Unpatched systems have become one of the main ways attackers get in. According to the Verizon 2026 Data Breach Investigations Report, exploitation of vulnerabilities was the most common initial access vector in breaches at 31%, while credential abuse, the previous leader, fell to 13%. The same report found that only 26% of critical flaws in the Known Exploited Vulnerabilities (KEV) catalogue of the US Cybersecurity and Infrastructure Security Agency (CISA) were fully remediated in 2025, and the median time to full remediation grew from 32 to 43 days.
The EU Agency for Cybersecurity's (ENISA) ENISA Threat Landscape 2025 reports that vulnerability exploitation remains a cornerstone of initial access at 21.3%, with widespread campaigns weaponising flaws within days of disclosure.
That is the patching gap in a sentence: attackers work in days, organisations in weeks. Drawing on more than a billion anonymised detection records, the 2026 DBIR shows that 60–70% of KEV vulnerabilities are still open seven days after detection. As of 24 September 2026, CISA's KEV catalogue lists 1,723 vulnerabilities, and the list keeps growing.
A common consequence is ransomware. When systems are encrypted, what saves the business is a sound ransomware backup strategy and regular restore testing. Neither closes the door that was left open, though; they only limit the damage.
For companies handling personal data of people in Turkey, there is a regulatory angle as well. Article 12 of Turkey's data protection law, KVKK (Law No. 6698), requires controllers to take appropriate technical and organisational measures, and a breach starts the 72-hour notification period set by a decision of the Personal Data Protection Board; our guide to the 72-hour breach notification explains the clock. "Why was a known flaw left open?" is a hard question to answer after the fact.
How does the patch management process work? A 7-step framework you can actually run
This seven-step patch management framework is designed for a company without a dedicated security team. Each step needs a named owner and a written output.
- Build an asset inventory. Servers, laptops, network devices, cloud services, business applications and anything with firmware go into one list, with version, owner and whether it is reachable from the internet.
- Track patch sources. Follow vendor security advisories, operating system update channels and the KEV catalogue. An advisory you cannot match to your inventory is just noise.
- Prioritise by risk. The question is not "what is the severity score?" but "is this being exploited, and is our asset exposed?". In June 2026 CISA itself moved to this model: BOD 26-04 replaced fixed deadlines with prioritisation based on asset exposure and exploitation risk.
- Test. For critical business applications, patches go first to a test machine or a small pilot group. Check that the ERP, production software and integrations still work afterwards.
- Deploy in a maintenance window. Schedule deployment for the least disruptive time and tell users in advance. Agree the reboot order for servers that depend on each other.
- Prepare a rollback plan. Take a snapshot or backup before patching and write down the steps to undo it. Teams without a rollback plan tend to postpone patches indefinitely.
- Verify and report. "Deployed" is not the same as "installed". Confirm with a vulnerability scan or version check that the patch is really in place, and log any flaws left open, with the reason and a review date.
Which patch first? A risk-based priority table
| Asset and situation | Risk level | Suggested approach |
|---|---|---|
| Internet-facing device (VPN, firewall, mail server) with a flaw listed in KEV | Very high | Emergency change; patch or mitigate within days |
| Internet-facing web application or remote access service | High | Next short maintenance window, after a quick test |
| Internal servers and critical business applications | Medium–high | Monthly cycle; test environment first |
| Staff laptops and browsers | Medium | Automatic updates, with a pilot group to catch conflicts |
| Shop-floor PCs, PLCs, SCADA | Varies | Vendor-approved, in a maintenance window; segment if unpatchable |
| End-of-support systems (no more updates) | High, permanent | Replace or isolate; record as a formal exception |
The logic of the risk-based priority table is simple: the same flaw is far more dangerous on an internet-facing appliance than on an office printer, which is why the table only works with an inventory behind it.
What should you do with systems you cannot patch?
Not everything can be patched. Shop-floor PCs often cannot be updated without the machine builder's approval, an end-of-support operating system receives nothing new, and some devices have firmware that is never updated at all. For these assets, compensating controls replace the patch: network segmentation, access limited to the people who need it, monitoring and a replacement plan.
We cover compensating controls on the production side in detail in our article on OT and SCADA security, and the same risk appears when retrofitting legacy machines to connect them to the network.
When buying new field equipment, ask whether it can be updated remotely. In our IoT device development process we treat over-the-air updates as a design decision, not an afterthought.
An architecture that grants no default trust inside the network (zero trust) also limits the blast radius of an unpatchable system. A zero trust security model makes it much harder for an attacker who compromises one stale machine to move freely.
How does patch management fit with vulnerability scanning, penetration testing and SIEM?
Patch management does not live on its own. Vulnerability scanning shows which flaw sits where, patching closes it, and a penetration test checks whether patches and configuration together actually hold up. They are not alternatives; they are stages of the same loop.
Monitoring matters in the patching process too. Successful installs, failed installs and rollbacks should all be logged, and SIEM and log management brings those records together and surfaces suspicious traffic aimed at a system that is still missing its patch. For companies preparing for ISO 27001, patch records are among the most tangible evidence for the technical vulnerability management control, as our ISO 27001 guide for SMEs explains.
Patching expectations also belong in supplier contracts. If a provider runs your server or application, the contract should state how quickly critical patches are applied and reported; otherwise responsibility falls between the two parties. If you will source these services externally, how to choose the provider is covered in our guide to choosing a cyber security company.
How does Digital Bridge set up patch management?
We do not start by selling a tool. We start by mapping the infrastructure you actually have. Within our cyber security consultancy, the work usually runs like this:
- Discovery and inventory. We list servers, network devices, cloud services and field equipment together with their owners, and flag everything that is internet-facing or out of support.
- Vulnerability scanning and prioritisation. We scan the inventory, rank findings by exploitation status and exposure, and write a practical remediation step for each one.
- A pilot cycle. In the first cycle we run test, deployment, rollback and verification together on a handful of critical systems, then document the routine so your team can run it.
- Infrastructure decisions. For old servers that have become hard to patch, we assess migration or replacement through our cloud migration and infrastructure consultancy. For workloads such as file shares, replacing an on-premise file server can also remove a patching burden.
- Protecting integrations. Patches break things most often at the seams: ERP, production and accounting connections. Drawing on our system integration work, we build those connections into the test plan.
- Compliance evidence. Where systems process personal data, we organise patch records as proof of technical measures as part of our data protection compliance service.
Because we design our own IoT devices and industrial software, we can also plan compensating controls for hard-to-patch systems such as shop-floor PCs, PLCs and SCADA without stopping production.
Your next step
You do not need a large project to begin. This week, list your internet-facing devices and their versions, then note when each was last updated. That list is your first priority queue. Review the other basics with our SME cyber security checklist, or browse more guides on the Cyber Security & Compliance topic page.
If you would like help building the inventory and running the first patch cycle, get in touch with our team. After a needs assessment, we will send a written proposal covering scope and phases.