For anyone who takes card payments — in any country
PCI DSS 4.0 — find the surface gaps before an assessor does.
PCI DSS is the payment card industry standard, not a US regulation. If you take card payments — a checkout, a donate button, a booking form — it applies to you. Some of it is visible from outside your network.
PCI DSS is the payment card industry's security standard. It is not a US regulation — it applies wherever card payments are taken, so a UK charity with a donate button and a British retailer with a hosted checkout are both in scope. What follows explains which parts of it are visible from outside your network, and what to do about the gaps.
Who it applies to
Any organisation that stores, processes or transmits cardholder data has PCI DSS obligations, whatever country it operates in. Most smaller organisations meet them through a self-assessment questionnaire rather than a full audit, and the questionnaire that applies depends on how payments are handled. Using a hosted payment page reduces the scope considerably — it does not remove it, because the page that redirects your customer to the payment provider still has to be served securely.
- Taking payments through a third-party checkout still leaves your own site in scope
- Donations, subscriptions and event bookings count the same as retail sales
- Scope is about how card data flows, not how much money moves
What an outside check can see — and what it cannot
PCI DSS covers people, process and technology. A great deal of that is internal and invisible from the public internet: network segmentation, key management, access control, staff training, logging. What an external check can establish is whether the parts an attacker or an assessor can reach from outside look right. That makes it useful as a pre-assessment sweep and useless as a substitute for one.
- Visible: transport security, certificate health, exposed services, published disclosure policy
- Not visible: cardholder data environment scoping, internal controls, policy documents
- A clean external result is a good sign, not a certification
What this check looks at
Each item below maps to something an assessor would expect to see, and each is externally verifiable without touching your systems in any intrusive way.
- HTTPS enforcement — cardholder data must never travel over plain HTTP, so an unredirected HTTP site is an immediate problem
- TLS protocol health — older protocol versions are no longer acceptable under the standard
- Certificate validity — an expired or mismatched certificate breaks the encryption customers rely on
- HSTS — tells browsers to refuse the insecure version of your site on future visits
- Known vulnerability exposure — unpatched software on internet-facing services is one of the most commonly cited failures
- Heartbleed — an old flaw that still appears on forgotten services
- Exposed database services — a database reachable from the public internet is hard to defend in any assessment
- Cloud storage observations — name matches leave ownership and public object access unverified; no objects are retrieved
- Mail transport evidence — advertised STARTTLS is distinguished from a completed TLS handshake; relay behaviour is not assessed
- security.txt — the standard expects a documented route for someone to report a vulnerability to you
Where organisations usually lose points
In practice the same handful of gaps come up repeatedly, and most are configuration rather than architecture. HSTS is often missing because it was never switched on rather than because anyone decided against it. security.txt is frequently absent simply because nobody knew it was expected. Unpatched services tend to be on something peripheral — a staging host, an old subdomain, a marketing microsite — rather than the main site everyone watches.
- Check the forgotten hosts, not just the main website
- Fix the transport-layer items first; they are quick and they carry the most weight with an assessor
- Publish a security.txt file — it takes minutes and it is a documented expectation
Common questions
›Does PCI DSS apply to UK organisations?
Yes. PCI DSS is a card-industry standard set by the payment brands, not a national law, so it applies wherever card payments are accepted. UK organisations are in scope on the same basis as everyone else.
›We use a hosted checkout. Are we still in scope?
Almost certainly, though at a much reduced level. Redirecting a customer to a payment provider narrows what you are responsible for, but the page doing the redirecting is still yours and still has to be served securely. Your acquirer or payment provider can tell you which self-assessment questionnaire applies.
›Is a clean result here the same as being compliant?
No, and it is important not to read it that way. This is an external surface check. It cannot see your cardholder data environment, your internal controls or your documentation, and it does not produce or replace a formal assessment. Treat it as a way to find and fix visible gaps before someone else finds them.
›How often should we re-run it?
After any change to hosting, certificates or DNS, and on a regular schedule otherwise. Certificates expire, new services appear on old subdomains, and vulnerabilities are published continuously — an external surface is not a fixed thing.
Advisory only. This is an external surface check, not a PCI DSS assessment or certification. Cardholder-data-environment scoping, internal controls and organisational requirements are out of scope, and nothing here constitutes compliance advice.
Also useful: Cyber Essentials readiness.