PCI DSS

PCI DSS applies to any organisation that touches payment card data, and its requirements cover the environment where that data lives: access control, encryption, logging, secure configuration, vulnerability management and testing. Central to it is the idea of the cardholder data environment, the set of systems in scope, and much of the work is about defining and shrinking that boundary. Two mechanisms do the shrinking. Network segmentation isolates the systems that handle card data so that everything else falls out of scope, and tokenisation replaces the card number with a token so the systems holding only tokens are no longer in the sensitive environment. The standard also requires a penetration test at a defined frequency and after significant change.

The recurring failure is scope that leaks. An organisation defines a tidy cardholder data environment on paper, but the segmentation that is supposed to isolate it is weak, so a system meant to be out of scope can actually reach in, which drags it back into scope and, more importantly, gives an attacker a route to the card data. From the offensive side, the segmentation test is the point: if a compromised out-of-scope host can reach the cardholder environment, the boundary is fiction. The other common gap is card data found where it should not be (in logs, in backups, in a test database), which expands the real scope well beyond the documented one.

We test the two things PCI DSS scope depends on: whether the segmentation genuinely isolates the cardholder data environment (a segmentation test that attempts to cross the boundary), and whether card data has leaked outside it. The required penetration test covers the in-scope systems at the standard’s cadence, with findings tied to the requirement they touch. For businesses that also field US customer demands, this often runs alongside SOC 2. This is part of how we test in-scope systems for PCI DSS.