Patching and Vulnerability Scans: How Fast Is Fast Enough?

There is an uncomfortable arithmetic at the heart of patching. PCI DSS gives you a month to install a critical security patch. Cyber Essentials gives you fourteen days. Recent threat research puts the median time from a vulnerability being published to it being confirmed as exploited at around five days — and finds that a substantial minority of vulnerabilities show evidence of exploitation on or before the day they are made public. The compliance deadline is slower than the threat, which means treating the deadline as a target rather than a limit is a choice with consequences. This guide sets out what the standards actually require, when you need a vulnerability scan at all, and what a workable routine looks like. For the wider context, start with our complete PCI DSS compliance guide.

What does PCI DSS require you to patch, and how fast?

Two connected obligations. First, you are expected to have a process for identifying security vulnerabilities relevant to your systems and assigning each a risk ranking — drawing on industry-recognised sources, and identifying at minimum everything that is high-risk or critical for your environment. Second, you install patches accordingly: patches for critical vulnerabilities within one month of release, and all other applicable security patches within a timeframe you determine yourself, based on your own assessment of the risk.

The word doing the work in the first obligation is 'your'. Vendors publish severity scores for the world in general; your risk ranking is about your business. A critical flaw in software you do not run is irrelevant to you. A moderate flaw in the till system that handles every transaction you take may not be. This is also the part most small businesses skip entirely, which then makes the second obligation impossible to satisfy in any meaningful way, because you cannot patch on a schedule that depends on a ranking you never produced.

What does Cyber Essentials say?

Cyber Essentials is stricter and much simpler, which is why it is a useful yardstick even for businesses not pursuing certification. Updates must be applied within fourteen days of release where the vendor describes the vulnerability as critical or high risk, or where it carries a CVSS base score of seven or above, or where the vendor provides no severity information at all. That last clause catches a lot of small-business software. The scheme also requires that unsupported software is removed once it stops receiving updates. Our comparison of Cyber Essentials and PCI DSS covers where the two schemes align and where they diverge.

If you want one rule rather than two, use fourteen days. It satisfies both, it is easier to remember, and it closes rather more of the window than a month does.

Do you actually need vulnerability scans?

This is where a great deal of money is wasted, in both directions, so it is worth being precise. Whether you need scanning depends entirely on which self-assessment questionnaire applies to you — and several of the questionnaires that cover small UK merchants contain no scanning requirements at all.

• SAQ B (standalone dial-out terminals), SAQ C-VT (virtual terminal on an isolated computer) and SAQ P2PE (validated point-to-point encryption) contain no Requirement 11 at all — no vulnerability scanning, no penetration testing. If someone is selling you quarterly scans for a business on one of these, ask them which requirement it satisfies.
• SAQ B-IP (standalone terminals connected over IP) requires quarterly external scanning by an Approved Scanning Vendor, plus segmentation testing where segmentation is used.
• SAQ A now requires quarterly external ASV scanning for merchants whose payment page redirects to, or embeds an iframe from, their provider. This is newer than many merchants realise and is a common surprise at renewal.
• SAQ C adds internal scanning quarterly alongside the external ASV scans.
• SAQ A-EP is the heaviest of the self-assessment routes: ASV scanning, external penetration testing, segmentation testing, intrusion detection and file-integrity monitoring.
• SAQ D covers the full set, including authenticated internal scanning and internal penetration testing.

Establishing which questionnaire genuinely applies to you is therefore not an administrative detail — it is the single decision that determines whether you owe nothing here or several hundred pounds a year in scanning subscriptions. Our guide to the card-present SAQ types walks through which one matches your payment setup.

What is an ASV scan, and what counts as passing?

An Approved Scanning Vendor is a company the PCI Security Standards Council has approved to run external vulnerability scans against internet-facing systems. Where your questionnaire requires it, these scans happen at least once every three months, and you must reach a passing result — which means rescanning after you fix what the scan found, until it passes. Four quarterly scans that all failed do not add up to compliance.

Three points regularly cause confusion. Internal vulnerability scans, where required, do not need an ASV — a suitably qualified person can run them, provided they have organisational independence, which in practice means the person who built the network should not be the only person checking it. The extra external scan required after a significant change also does not require an ASV; it is event-driven rather than quarterly, and its bar is resolving anything scoring 4.0 or above. And that 4.0 is a severity score, not a version number: an ASV scan fails on anything scoring 4.0 or higher, which means medium-severity findings block you, not just the alarming ones.

What about penetration testing?

Penetration testing is a person actively trying to break in, rather than a tool listing known weaknesses, and it appears in far fewer small-merchant questionnaires than scanning does. Where it applies, external and internal testing run at least once every twelve months and after any significant infrastructure or application change, following a documented methodology, with results and remediation kept for at least twelve months. If you use network segmentation to keep systems out of scope, you also have to test that the segmentation genuinely holds — at least every twelve months for a merchant, and whenever you change it.

For most small UK merchants, none of this applies. For those on SAQ A-EP or SAQ D it does, and it is a real annual cost that should appear in any honest quote.

What goes wrong in practice?

The failures that produce regulatory action are rarely subtle. In May 2026 the Information Commissioner's Office fined a water company and its parent nearly £964,000 over a ransomware attack in which the attackers were present for roughly twenty-two months before detection. Among the findings: devices still running an operating system that had been out of support since 2015, domain controllers left unpatched against a vulnerability published nearly two years before the attack, and — asked to produce scan reports covering a twenty-month period — the company confirming it had run no internal or external vulnerability scans at all.

A 2025 case against a software supplier followed a similar pattern: the company had bought a vulnerability scanning product and never actually run scans with it, described its own patching as ad hoc, and could not demonstrate it had patched the specific vulnerability involved. Its own internal risk register had rated scanning its highest priority. The lesson in both cases is that buying the tool and running the process are different achievements, and only one of them is a control.

A routine that works for a small business

• Write down what you actually run — devices, operating systems, payment applications, the router, the website platform and its plugins. You cannot patch an inventory you do not have.
• Turn on automatic updates wherever the system will allow it. For most small businesses this single step does the majority of the work.
• Set one recurring slot a fortnight for whatever cannot update itself, and use fourteen days as your deadline for anything critical or high risk.
• Subscribe to your vendors' security notifications so that 'we did not know' stops being possible.
• Replace software that has stopped receiving updates. Unsupported software cannot be patched, so no schedule will save it.
• Confirm whether your questionnaire requires scanning before you buy any. If it does, book it quarterly and diarise the rescan until it passes.
• Keep the evidence — scan reports, patch dates, the rescan that finally passed. Assessment is about what you can show, not what you did.

Key takeaways

• PCI DSS gives one month for critical patches; Cyber Essentials gives fourteen days. Use fourteen and satisfy both.
• Exploitation now frequently precedes patching — the median time to confirmed exploitation is measured in days, not months.
• SAQ B, C-VT and P2PE require no vulnerability scanning at all; SAQ A now requires quarterly ASV scans for redirect and iframe checkouts.
• Only external quarterly scans need an ASV — internal scans and post-change external scans do not.
• Unsupported software is the one gap patching cannot close; replacing it is the control.

The most expensive mistake in this area is paying for scanning you do not need — or discovering at renewal that you needed it all along. Fraud Defence First's fully managed PCI compliance service establishes which questionnaire genuinely applies, tells you plainly whether scanning is required, and completes and files the assessment with your acquirer for a flat £100 + VAT a year.