Card payments are everyday business for most companies, in the online shop just as at the checkout counter. Where card data flows, an attractive target for attackers arises and, with it, a clearly regulated set of obligations: the Payment Card Industry Data Security Standard, PCI DSS for short. Anyone who ignores it risks contractual penalties from the payment service providers and, in an emergency, liability for card misuse.
What is PCI DSS?
PCI DSS is a globally uniform security standard for handling cardholder data. It is maintained by the PCI Security Standards Council, a body of the major card organizations, and is currently being developed further in version line 4. Unlike a law, the standard takes effect through contracts: merchants and service providers commit to compliance toward their bank or their acquirer.
At the center is the cardholder data environment (CDE). This includes all systems that store, process, or transmit card data, as well as every system with a direct connection to it. The scoping of this environment determines the audit scope: the more systems are networked with the CDE, the larger the area becomes that has to meet all requirements and be demonstrated in the audit.
How it works
The path to compliance follows a recurring pattern:
- Determine the scope: First, all data flows of card data are documented. From this it follows which systems belong to the CDE and which requirements apply where.
- Implement the core requirements: The standard bundles twelve requirements into six objectives. Roughly summarized, it calls for secured networks with controlled transitions, protection of stored card data and encryption during transmission, hardened systems with regulated vulnerability management, strict access control on the need-to-know principle, gapless logging with regular testing, and binding security policies for the organization.
- Reduce the audit scope: Segmentation separates the CDE from the rest of the network so that large parts of the IT drop out of the audit. This works especially precisely with microsegmentation , which restricts connections down to individual workloads and makes the effectiveness of the separation demonstrable. Tokenization and outsourced payment pages also reduce the scope considerably.
- Provide evidence: Depending on the transaction volume, a self-assessment questionnaire (SAQ) suffices, or a formal audit by a Qualified Security Assessor (QSA) is necessary. On top of this come quarterly scans by an Approved Scanning Vendor (ASV) for externally reachable systems.
- Maintain compliance: PCI DSS is not a one-off project. The evidence has to be renewed annually, and version 4 requires, in many places, demonstrably lived processes instead of snapshots.
Why it matters
- Contractual duty: anyone who accepts card payments has committed to compliance toward the acquirer and card organizations. Violations can mean increased fees or the loss of the acceptance agreement.
- Liability in an emergency: after a data outflow, the card organizations check the compliance status. Missing evidence shifts the costs for card misuse and re-issuance toward the affected merchant.
- Real protective effect: the requirements address the most common attack routes on payment data, from weak passwords to unpatched systems in the checkout network.
- Cost lever of audit scope: a cleanly segmented scope noticeably lowers audit effort and ongoing operating costs, often by orders of magnitude.
- Trust in the payment ecosystem: banks, payment service providers, and business customers expect the evidence as a matter of course.
Typical scenarios
An online merchant redirects its customers to the hosted page of a payment service provider for payment. Card data never touches its systems, which is why a short self-assessment questionnaire suffices. The effort stays small as long as the redirect is cleanly implemented.
A branch retailer operates its own point-of-sale systems with card terminals. Its checkout network belongs to the CDE and is strictly separated from the office network by segmentation. This keeps workstations and merchandise management outside the audit scope, and a compromised office PC leads attackers into a dead end.
An IT service provider hosts applications through which card data flows. It has to provide its own PCI DSS evidence toward its customers and thereby becomes part of their audit chain, including clearly delineated responsibilities.
PCI DSS vs. GDPR
The two frameworks are often confused, but they pursue different goals. PCI DSS is a contractual industry standard and protects exactly one type of data: cardholder data. For this it makes very concrete technical specifications, down to password rules and scan intervals. The GDPR is a law, applies to all personal data, and formulates risk-based principles instead of detailed technical specifications.
In practice, the two overlap: the name on a credit card is at the same time a piece of personal data. A card data leak can therefore simultaneously trigger reporting duties under the GDPR and procedures of the card organizations. Anyone who implements the PCI DSS controls cleanly thereby also meets a relevant part of the technical requirements from Article 32 GDPR, but does not replace them.
How KAEMI helps
KAEMI supports companies in technically limiting the scope cleanly and staying compliant over the long term. With microsegmentation based on Illumio, the cardholder data environment is precisely isolated, including the visualization of all connections as evidence for auditors. In addition, KAEMI's Professional Services accompany the preparation for audits, from scoping to the hardening of the network architecture. You can reach the team via the contact page for an initial assessment of your environment.