Leeds logistics operator cuts critical vulnerability exposure from 47 days to 6
A 140-staff Leeds logistics operator cut average remediation time for critical vulnerabilities from 47 days to 6 days and high findings from 112 days to 21 days, with 96% of the estate under continuous scanning within three months.
An insurance renewal questionnaire asked how quickly critical vulnerabilities were patched. Nobody could answer. The first measurement showed critical issues sitting unpatched for an average of 47 days across servers and endpoints.
Client: 140-staff logistics and distribution operator. Name withheld under our confidentiality terms.
At a glance
- Client
- 140-staff logistics and distribution operator
- Sector
- Manufacturing & Logistics
- Location
- Leeds, West Yorkshire
- Size
- 140 employees, 2 depots
- Services
- Vulnerability Management, EDR, 24/7 SOC (MDR)
- Timeline
- Baseline to steady state in 3 months
- Headline result
- 47 → 6 days — Average time to remediate critical findings
Measured results
- Average time to remediate critical findings
- 47 → 6 daysAverage time to remediate critical findings
- Average time to remediate high findings
- 112 → 21 daysAverage time to remediate high findings
- Estate coverage by continuous scanning
- 96%Estate coverage by continuous scanning
- Baseline to steady state
- 3 monthsBaseline to steady state
The challenge
- No measurement of patch timeliness across 140 endpoints, 9 servers and warehouse systems.
- Warehouse and depot devices ran continuously, so nobody wanted to reboot them.
- Third-party applications such as browsers and PDF readers were updated inconsistently.
- The cyber insurance renewal asked directly for time-to-patch figures.
What we did
- 1
Deployed continuous vulnerability scanning across endpoints, servers, cloud workloads and public-facing systems.
- 2
Established a measured baseline: 47-day average to remediate critical findings, 112 days for high.
- 3
Agreed maintenance windows per device group, so warehouse systems patched during scheduled downtime rather than never.
- 4
Automated third-party application patching for browsers, PDF readers and conferencing tools.
- 5
Prioritised by exploitability and exposure rather than CVSS score alone, so internet-facing systems went first.
- 6
Reported monthly with time-to-patch trend, open findings by severity, and exceptions with justification.
The outcome
- Insurance renewal completed with documented time-to-patch evidence.
- Warehouse systems patch inside agreed windows instead of being permanently deferred.
- Third-party application updates are automated rather than user-dependent.
- Monthly reporting gives the board a single, trackable exposure figure.
“The honest answer to the insurer's question was that we had no idea. Having a number, and watching it come down, changed the conversation internally.”
The concepts behind this engagement
Plain-English reference pages explaining the certifications, threats and controls involved in this piece of work.
Where this fits in what Complete Cyber Security does
FAQ
Questions about this engagement
The questions businesses in a similar position ask most often before starting.
What is a reasonable time to patch a critical vulnerability?
+
Fourteen days is the widely accepted benchmark for critical and high-severity issues, and it is the standard Cyber Essentials applies to patches rated critical or high by the vendor. Internet-facing systems warrant faster action, ideally inside 72 hours, because exploitation of a newly published vulnerability now often begins within days of disclosure. This operator moved from a 47-day average to 6 days for critical findings. The value is less in hitting a specific number than in having one at all: an unmeasured estate cannot be improved, and insurers increasingly ask for the figure directly.
How do you patch systems that can never be taken offline?
+
By replacing 'never' with a defined window, which is usually a negotiation rather than a technical problem. Warehouse and depot systems here ran continuously because no one had scheduled otherwise, not because downtime was genuinely impossible. We identified natural quiet periods per device group, agreed short monthly windows with operations, and staged patches so paired systems were never down together. Where a system genuinely cannot be patched, the fallback is compensating control: network segmentation, restricted access and enhanced monitoring, documented as an accepted exception with a review date rather than an ignored finding.
Why prioritise by exploitability rather than CVSS score?
+
Because CVSS measures theoretical severity in isolation, not risk in your environment. A CVSS 9.8 vulnerability in a service that is not enabled, on a server with no internet exposure, behind MFA, is less urgent than a CVSS 7.5 issue in a public-facing application with a known exploit circulating. Prioritising purely by score produces a very long list that nobody finishes, and it consistently pushes genuinely dangerous internet-facing issues down the queue. We weight by exposure, whether a working exploit exists in the wild, and what the affected system can reach, then patch in that order.
