NCSC vulnerability management: turn urgent patching into buyer-ready evidence (2026)

An SME can have a patching policy and still be unable to answer a buyer's practical question: if a critical internet-facing flaw is exploited today, who knows, who decides, what gets updated first, and how can the business prove it happened? The NCSC's vulnerability-management guidance gives that answer a shape that a small team can operate and show.

Quick view

Signal	LinkedIn angle	Action window
The NCSC's vulnerability-management guidance is version 2.1 and was reviewed on 1 May 2026. 1	Replace "we patch regularly" with evidence of ownership, asset coverage, urgency and supplier response.	Use the next update review, MSP contract review or incident exercise.
Its update-by-default guidance sets best-practice completion windows of 5 days for internet-facing services and software, 7 days for operating systems and applications, and 14 days for internal or air-gapped services and software. These are guidance timescales, not a new legal duty; business-critical availability still has to be considered. 2	Turn a vague patching promise into a measurable control with exceptions and rollback evidence.	Set the default windows now, then record why any exception is longer.

The audience pain point

Small teams often treat vulnerability management as a monthly technical task. The harder failure appears when a serious flaw is being exploited: nobody knows whether an old appliance is still running, the MSP contract does not define a rapid response, and the change record says only "patched".

That is weak evidence in a buyer review. A prospect is not only asking whether updates are installed. They are asking whether the business can find the affected asset, make a safe decision under time pressure, involve the right supplier and show what happened afterwards.

What the NCSC guidance gives you

1. Make urgent patching an incident path

The NCSC says organisations should have a rapid response pathway or policy for exploited vulnerabilities. It recommends integrating that response with existing IT outage or incident processes because the governance, on-call roles and escalation routes may already exist. For a smaller organisation without a formal incident process, a simple agreement with IT staff can commit them to prioritising updates when the situation demands it. 1

The useful GRC question is not "Do we have a patch policy?" It is: what event moves a patch from routine work to an incident, and who has authority to act? Put that trigger, owner and escalation route in writing.

2. Include the assets nobody thinks they own

The guidance warns that attackers can use any available route, including shadow IT. During mass exploitation, the NCSC recommends checking beyond the systems already known to security and IT teams. Its examples include developer environments, contractors and embedded staff, as well as non-traditional data sources that can reveal use of an affected product. 1

For an SME, that does not require an expensive platform before taking action. Start with an asset register that names the owner, internet exposure, business importance, supplier and last verification date. Add the questions the team will use when a vendor advisory arrives: could this product be in a developer environment, a managed service, an old remote-access path or a contractor's workflow?

3. Put the expectation into supplier contracts

The NCSC says the rapid-response process should be reflected in supplier contracts. It recommends ensuring that critical suppliers and managed service providers are contractually liable to rapidly mitigate vulnerabilities in internet-accessible systems when those vulnerabilities are being exploited in the wild. 1

That is a practical supplier-assurance angle for a growing business. Check whether each important provider contract states:

who receives urgent security advisories;
which systems and services are in scope;
how quickly the provider acknowledges, investigates and mitigates an exploited flaw;
what evidence the provider returns; and
who decides whether a temporary outage is safer than leaving the service exposed.

Do not present this as a universal contractual rule. It is the NCSC's recommended control direction, and the agreement still needs to fit the service, the supplier and the business's risk decision.

4. Use a default window, then make exceptions visible

The NCSC recommends updating by default, as soon as possible and ideally automatically. It also describes staged rollout and canary deployment as ways to test updates on real systems while keeping a pause or rollback option. The guidance says its best-practice timescales apply to all updates, regardless of vulnerability severity, while business-critical systems need to be balanced against availability. 2

The practical evidence is a small record, not a grand policy library. For each exception, capture the affected service, the reason for delay, the compensating measure, the owner, the revised deadline and the approval. A buyer can understand that record. "Patching is managed" gives them nothing to test.

For actively exploited vulnerabilities, the NCSC describes a much shorter path. Its example table calls for an update immediately or within 24 hours when a vulnerability is in the CISA Known Exploited Vulnerabilities catalogue, internet-accessible, automatable and capable of giving an attacker total control; other combinations in the table use 48- or 72-hour windows. The table is a response aid in NCSC guidance, not a UK law or certification threshold. 1

A buyer-ready evidence pack

Use the next update cycle to assemble six items:

Asset view: the affected product, owner, location, internet exposure and business service it supports.
Decision record: the advisory received, the assessment of exposure, the chosen action and the person who approved it.
Change evidence: the ticket, deployment time, test or canary result, rollback plan and final verification.
Supplier trail: the MSP or vendor notification, response time, mitigation and any remaining dependency.
Exception log: every delayed update, its reason, compensating control, revised date and owner.
After-action note: what the team learned about unknown assets, access paths, monitoring or supplier terms.

This is not a claim that every SME needs a security operations centre. It is a way to show that the business can move from alert to accountable action without guessing who owns the decision.

NCSC vulnerability management: turn urgent patching into buyer-ready evidence