Prioritise security patches on internet-facing business systems

Before you begin

Patching everything at once is rarely possible. The NCSC's advice for the wave of software updates it expects is to reduce your internet-facing attack surface first and work inwards, patching external systems before the rest. This guide gives you a repeatable way to decide the order using public evidence, rather than whichever alert shouted loudest this morning.

The first five sections are read-only: you are looking things up and writing them down. Only the section on applying fixes changes a live system, and it says so where it matters.

• Authority: you must own the systems or be authorised to manage them. Do not probe other people's addresses to see what they expose.
• Read access to wherever exposure is defined: firewall or router rules, DNS records for your domains and any cloud portals. If an IT provider manages these, ask them for the same information.
• Somewhere to record the results. A spreadsheet is fine. The columns matter more than the tool.

List what the internet can reach

Public vulnerability lists know nothing about your business. They can tell you a product is being attacked, but not whether you expose it, so the inventory has to come first. Be thorough rather than tidy: the printer management page with a public address that nobody admits to owning is exactly the sort of thing this exercise exists to find.

1. Look at where exposure is defined: port-forwarding or NAT rules on your firewall or router, the DNS records for every domain you own (forgotten subdomains included), the public IP addresses and endpoints in any cloud portal, and anything an IT provider or web host runs for you.
2. Add one row per exposed service. Record what it is (VPN gateway, webmail, website, remote desktop gateway, file transfer and so on), the vendor and product, the exact version, who owns it and who is able to patch it.
3. Register your public IP addresses and domain names with the NCSC Early Warning service. It is free to any UK organisation and emails you about vulnerable services and open ports it associates with those details. It does not scan your network itself and the NCSC says it should not be your only layer of defence, so treat it as a second opinion on your list rather than the list.
4. Challenge anything exposed that nobody uses. Closing a rule that has no business purpose removes the risk outright, which beats patching it. Record or export the rule before you delete it and check with the apparent owner first, because the thing nobody mentions is usually the thing someone relies on at month end.

Match each item to a vendor fix

For each row you need to know three things: which security flaws affect your exact version, whether the vendor has released a fix, and whether the product is still supported at all. The vendor's own security advisory is the authority here, because only the vendor can say which versions are affected and which release fixes them.

1. Find the exact version from the product's administration console or about page. Menu names vary between products, so use the vendor's documentation if you cannot find it. If you genuinely cannot establish a version, treat the system as affected until you can.
2. Open the vendor's security advisories for that product and note any advisory covering your version: the CVE identifiers, the fixed version, the vendor's severity rating, whether the vendor says it is being exploited and any mitigation offered if a fix is not yet available.
3. Check whether your version is still supported. If it is end-of-life, no fix is coming. Mark it as replace or remove from the internet. The NCSC specifically calls out end-of-life technology that is externally exposed as something to replace or bring back into support.
4. Add the CVE identifiers to your row. You need them for the next lookup, and they let the next person see why a system ranked where it did.

What each piece of evidence tells you

Each signal answers a different question, and the common mistake is asking one of them to answer all of them. The vendor rating says how bad it is if it works, KEV says whether attackers are using it, EPSS estimates how likely that is soon and your inventory says whether you are exposed.

• Vendor severity and CVSS: CVSS (the Common Vulnerability Scoring System) is a score from 0 to 10 for how serious a flaw is. It measures potential impact, not whether anyone is exploiting it. Plenty of critical flaws are never attacked in practice, and a middling score is not proof of safety.
• KEV: CISA's Known Exploited Vulnerabilities catalogue lists flaws with reliable evidence that an attacker has run malicious code through them in the real world. Inclusion needs a CVE identifier, evidence of attempted or successful exploitation (scanning, research and proof-of-concept code do not count) and clear remediation guidance. It is the strongest public signal that a flaw is in use.
• The limits of KEV: it tells you a flaw is exploited somewhere, not that it is exploited against you or that you run the affected version. Absence from the list does not mean a flaw is safe, only that it has not been listed. Its field for use in ransomware campaigns is frequently shown as Unknown, which means not recorded, not no. The remediation deadlines bind US federal agencies, not UK businesses, but CISA still recommends that everyone prioritise KEV entries.
• EPSS: the Exploit Prediction Scoring System from FIRST estimates the probability, between 0 and 1, that a published CVE will be exploited in the wild in the next 30 days. Most scores are low, so a figure like 10% is high by comparison. Use it to order items within the same group, not to override a KEV listing. FIRST advises quoting the percentile alongside the probability (for example 15.3% at the 92nd percentile) and warns that cut-off lines for high, medium and low are subjective, so we suggest you do not invent a hard threshold.
• Exposure: only you can supply this, which is why the inventory comes first. A critical flaw in a product that only exists on an internal network is a different problem from a moderate one on your public VPN.

Rank the list

The order below is our engineering judgement, built on the NCSC's external-first advice and CISA's recommendation to treat KEV as an input to prioritisation. It is not a standard. Where you hold Cyber Essentials, its rules may set a minimum timescale for the middle tiers, as covered below the list.

Within each group, break ties with EPSS and then with how much damage the system could do if taken over. Remote access gateways, email and anything holding credentials deserve the benefit of the doubt.

• Do now: exposed, affected version, and credible exploitation evidence (a KEV listing or your vendor saying it is being exploited). The NCSC says to accelerate your update process when a critical vulnerability is being actively exploited, particularly on an internet-facing system. Apply the vendor's fix. If none exists yet, apply the vendor's mitigation or take the service off the internet until one does.
• Remove or replace: exposed and end-of-life. Nothing will patch these, so the choices are to take them off the internet, restrict access to named addresses or replace them. Until that is done they stay near the top of the list whatever their current CVE count.
• Next: exposed, with a vendor rating of critical or high (or a CVSS score of 7 or above) but no sign of exploitation. Patch these promptly, with EPSS ordering the queue. If you hold or are working towards Cyber Essentials, its security update control sets 14 days for updates that fix flaws the vendor describes as critical or high risk, that score 7 or above on CVSS v3, or where the vendor gives no severity at all. Check the requirements version your assessment uses for the current wording.
• Routine: exposed with lower severity, then internal systems. The NCSC's default is to update as soon as possible and ideally automatically, so these should mostly be handled by automatic updates rather than by this process. If you cannot cover everything, the NCSC suggests external systems first and then critical security systems.

Apply fixes to an exposed system safely

This is the section that changes live systems. Patching an internet-facing gateway or website can mean a restart or a brief outage, and a few appliance updates need specific upgrade paths or take a while, so read the vendor's release notes before you start. You need administrator access to the system and, ideally, a quiet period agreed with the people who use it.

One caution matters most for the first group. If a flaw was being exploited before you patched, installing the fix does not undo anything an attacker already did. Check the vendor advisory for signs of compromise and bring in specialist help if you find any.

1. Read the vendor's release notes for the fixed version. Note any required intermediate version, configuration changes, restart and the vendor's own rollback guidance.
2. Create a way back before you change anything: a snapshot or backup for a virtual machine or server, or an export of the configuration using the vendor's own method for an appliance. Confirm the export or snapshot exists before continuing.
3. Tell the people who will notice. A VPN gateway restart drops connections and a website update can interrupt orders, so choose a moment accordingly.
4. Apply the update using the vendor's documented method. Appliance and firmware updates can take several minutes and some must not be interrupted, so stay with it until the system is back and follow any vendor warnings.
5. Test from outside the building. Sign in to the VPN, load the website or send a test message from a device on mobile data rather than your office network, so you are checking what the internet sees.
6. If the update breaks something, roll back with the snapshot or configuration export. Be aware that rolling back restores the vulnerable version. For a first-group item, restrict access to known addresses or keep the service offline while you fix the problem, rather than putting an exploited flaw straight back on the internet.

Check it worked

Success is a list you can defend. Every exposed service has an owner, a version, a status and a position in the order, and nothing in the do-now group is still waiting.

To confirm each fix, check the version now shown in the system's console is the fixed release or later named in the vendor advisory. Update the row with the date and who did it. Then recheck that the service behaves as expected from outside, and keep an eye on Early Warning for alerts relating to the same address.

An illustrative example, with no real products or CVEs: a small firm lists a VPN gateway, a customer portal and an old branch router. The gateway's vendor advisory is also on the KEV list, so it goes first. The portal has a vendor-rated high flaw with no reported exploitation, so it goes second, ordered by EPSS if there are several. The router is end-of-life and cannot be patched, so the firm closes its remote management and plans a replacement. The internal file server stays on automatic updates and does not touch this process.

If it does not work

Most problems come down to missing information rather than anything difficult.

• You cannot find an advisory for your version: ask the vendor or the IT provider that supplied it. Until you have an answer, treat the system as affected.
• The vendor offers a mitigation but no fix: apply the mitigation as a stopgap and keep the item at the top of the list. Mitigations are temporary and the real fix remains the target.
• You cannot work out who owns an exposed service: restrict its access or close it, and let the owner come and find you. An unowned, exposed service is worse than a briefly inconvenienced one.
• You suspect something was exploited before you patched: stop here, preserve the system as it is and get specialist incident-response help rather than carrying on with routine patching.