PCI DSS v4.0: What Changed and How to Stay Compliant
Version 4.0 brings a customised approach, targeted risk analyses and stricter authentication. For healthcare the first question is usually how much of the estate is even in scope.
GuardsArm Team
Security Experts
Healthcare organisations take card payments — copays, self-pay balances, pharmacy, car parking, the café — and therefore fall in scope of PCI DSS. The standard is often treated as a finance problem, which is how hospitals end up with card data flowing through systems nobody assessed.
What v4.0 actually changes
A customised approach. Alongside the prescriptive requirements, v4.0 allows you to meet a stated security objective by a different means, provided you document a targeted risk analysis and the assessor agrees. This is genuinely useful for environments where the defined method does not fit — and it requires more evidence, not less.
Targeted risk analysis. Several requirements now let you set your own frequency, justified by a documented risk analysis rather than a fixed interval. That flexibility comes with the obligation to write it down and review it.
Authentication. MFA for all access into the cardholder data environment, not only administrative access, and stronger password requirements where passwords remain the only factor.
Continuous rather than periodic. More emphasis on demonstrating controls operating throughout the period, rather than evidencing them at assessment time.
Scope reduction beats control implementation
The cheapest PCI programme is the one covering the smallest environment. Every system that stores, processes or transmits cardholder data — and every system connected to those — is in scope.
For most hospitals the practical answer is: use a hosted payment page or an iframe from the payment provider so card data never touches your systems, and tokenise anything you must retain for recurring billing. What remains is a small, segmented environment rather than a large part of the hospital network.
SAQ or ROC
| Path | When | Effort |
|---|---|---|
| SAQ A | Fully outsourced e-commerce, card data never touches you | Lowest |
| SAQ A-EP | E-commerce where your site affects the payment page | Moderate |
| SAQ B / B-IP | Standalone terminals only | Low |
| SAQ C / C-VT | Payment application or virtual terminal, segmented | Moderate |
| SAQ D | Everything else — storage, or complex environments | High |
| ROC (QSA assessed) | Large volumes, or required by the acquirer | Highest |
Your acquiring bank determines which applies based on transaction volume and channel. Confirm with them rather than assuming.
Where it meets healthcare specifics
- Card data alongside PHI. A payment record linked to a patient is both cardholder data and PHI. Both regimes apply; neither substitutes.
- Call recordings. Payment taken over the phone may capture card numbers in recordings — a common and awkward finding. Pause-and-resume recording or DTMF masking is the usual fix.
- Legacy terminals. Older standalone devices in cafés and car parks are frequently forgotten and are still in scope.
- Third-party billing services. They handle card data on your behalf, which makes their compliance your concern — see vendor risk scoring.
Where to start
Map where card data actually flows, including phone payments and any recordings of them. Most healthcare organisations find at least one path they had not considered, and the map is what makes every subsequent decision — outsource, tokenise, segment — possible.
GuardsArm supports PCI DSS scope reduction and segmentation testing. Book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on “PCI DSS v4.0: What Changed and How to Stay Compliant”
Talk to the GuardsArm team about how these services apply to your environment.
