The PCI DSS Requirements UK Businesses Fail Most Often

There is a genre of PCI article that lists the ten requirements businesses fail most, and almost all of them are now useless — they were written against version 3, whose requirement numbers were retired in March 2024, and they describe a standard that no longer exists in that form. What follows is a rebuild for the version in force today, based on where merchants actually come unstuck. The striking thing is how few of these are technical. Most are documents nobody maintains and habits nobody has established. For the underlying framework, see our complete PCI DSS compliance guide.

1. Multi-factor authentication that does not cover everything

This is the biggest change in version 4 and the most common gap we find. Multi-factor authentication is required for all non-console access into the card data environment — every user, not just administrators — and separately for all remote access from outside your network. The failure is almost never a total absence of MFA. It is the account that was left out: the service account, the supplier's login, the shared till account, the director who found it inconvenient. Our guide to passwords and MFA covers how the requirements interact, and why the two obligations are not interchangeable.

2. A security policy nobody has read since it was written

You are expected to have a documented information security policy, to review it at least once every twelve months, to update it when the environment changes, and to have defined security responsibilities for all personnel. The typical failure is a policy written when the business was set up, referring to systems that no longer exist and staff who left years ago. A policy that is visibly out of date is worse than a short one that is current, because it tells everyone the whole exercise is theatre.

3. Security awareness training that is not evidenced

Training is required on hire and at least once every twelve months, using more than one method of communication, and covering phishing and social engineering specifically. Personnel must also acknowledge annually that they have read and understood the policy. Businesses frequently do a reasonable job of talking to staff about security and then have nothing whatsoever to show for it. Undocumented training does not exist as far as an assessment is concerned. Our guide to training staff to spot card fraud covers what to cover and what to keep.

4. An incident response plan that has never been tested

The standard requires an incident response plan, and requires it to be reviewed and tested at least once every twelve months. It also requires the plan to set out how you would notify your acquirer and the card brands. Most small businesses have either no plan or a template downloaded years ago and never opened. The test is where the value is: it is how you discover that the emergency contact has left, that nobody knows the acquirer's incident number, and that the person named as decision-maker is on holiday for three weeks every August.

5. Third-party providers who are unlisted and unmonitored

You are expected to keep a list of every third party that handles card data or could affect its security, with written agreements in which they acknowledge their responsibility, due diligence before you engage them, a check on their compliance status at least once every twelve months, and — the one almost everyone misses — a written record of which PCI DSS requirements are managed by them, which by you, and which are shared. That last document is the single most commonly absent item in the whole standard, and it is the one that determines what happens when something goes wrong. Our guide to what your provider actually does and does not cover explains why the assumption is so often wrong.

6. Card terminals that are never inspected

If you take payments face to face, you must keep a list of your card-reading devices with make, model, location and serial number; inspect them periodically for tampering and substitution; and train the staff who work near them to spot interference and to verify anyone claiming to be there to service a device. In practice the list is usually missing and the inspections have never happened, which means a swapped terminal would go unnoticed indefinitely. Our guide to physical security for card data sets out what a check involves.

7. Scope that was never actually established

You are expected to maintain an inventory of in-scope system components with a description of what each does, and to document and confirm your PCI DSS scope at least once every twelve months and whenever something significant changes — including the data flows for every payment channel you operate. This is the requirement that quietly causes the others to fail, because a business that has not established what is in scope cannot know which controls apply to it. It is also how merchants end up on the wrong questionnaire entirely; our guide to the card-present SAQ types covers how payment setup drives the answer.

8. Patching, and software that can no longer be patched

Patches for critical vulnerabilities are due within a month, and everything else within a timeframe you set for yourself based on your own risk ranking. Two failures dominate: no risk-ranking process at all, which makes the deadline meaningless, and software running years past the end of vendor support, which no patching schedule can rescue. Recent UK enforcement has repeatedly found end-of-life systems still in service at the point of breach. Our guide to patching and vulnerability scans covers the deadlines and what to do about unsupported systems.

9. Scans that are required but never run — or never passed

Where your questionnaire requires quarterly external scanning by an Approved Scanning Vendor, four failed scans do not add up to compliance: you have to fix what the scan finds and rescan until it passes. Two opposite failures are common. Merchants who need scanning have never arranged it, often unaware that version 4 added it to questionnaires that previously had none. And merchants who do not need it at all are paying for it, because nobody checked which requirements their questionnaire actually contains.

10. The targeted risk analysis nobody knew existed

Version 4 introduced a concept that catches out even well-prepared businesses: for a number of requirements, you choose the frequency yourself, but you must document how you reached that decision — the asset being protected, the threat, what drives likelihood and impact, and a justification for the interval you picked, reviewed annually. Merchants who have diligently decided to inspect terminals monthly or scan for malware weekly often have no written analysis behind the choice, which is the part the requirement actually asks for.

What do these have in common?

Eight of the ten are documentation and routine rather than technology, and none of them require significant spending. That is the encouraging reading. The less encouraging one is that they all require somebody to own them continuously, which is exactly what a small business has least of. Compliance does not usually fail at the point of assessment; it fails in month seven, when the person who understood it has moved on and the annual date passes unnoticed.

There is also a pattern in what regulators find afterwards. Recent UK enforcement action has turned repeatedly on the same handful of failures — an account without multi-factor authentication, privileges far beyond what the role needed, unsupported software, scanning tools bought and never used, and alerts that fired correctly and went unread. None of those are exotic, and all of them appear on the list above. Our PCI DSS compliance checklist for UK businesses is the practical way to work through them in order.

Key takeaways

• Any 'top ten failures' list using version 3 requirement numbers is obsolete — that version was retired in March 2024.
• The largest single gap under v4.x is incomplete multi-factor authentication, usually a forgotten service or supplier account.
• Most failures are documents and routines: the policy, the training record, the tested incident plan, the provider responsibility matrix.
• Scope is the requirement that causes the others to fail — establish it first, and confirm it every twelve months.
• Version 4 asks you to justify the frequencies you choose in a written risk analysis; choosing sensibly is not enough on its own.

Every item on this list is something we handle as a matter of course. Fraud Defence First's fully managed PCI compliance service establishes your scope, completes the correct questionnaire with you, produces the documentation these requirements ask for and files everything with your acquirer — then does it again next year, for a flat £100 + VAT.