PCI DSS, GDPR and the Cyber Security Obligations Every Retailer Must Meet

Retailers that process payment card data face a compliance landscape that overlaps two distinct frameworks: PCI DSS — the Payment Card Industry Data Security Standard — and UK GDPR. Both apply simultaneously, both have enforcement mechanisms with real financial consequences, and neither exempts small retailers from compliance. Understanding what each requires, and where they diverge, is the starting point for a security programme that satisfies both.

PCI DSS: The Payment Card Security Framework

PCI DSS is a contractual standard maintained by the PCI Security Standards Council and enforced through acquiring banks. Any organisation that processes, stores, or transmits payment card data — which includes virtually all retailers accepting card payments — is required to comply with the standard. Compliance is not optional: it is a condition of the merchant agreement with your acquiring bank.

PCI DSS has four compliance levels based on transaction volume. Most small retailers fall into Level 4 — fewer than 20,000 Visa or Mastercard e-commerce transactions per year, or up to 1 million transactions per year across all channels. Level 4 merchants are typically required to complete an annual self-assessment questionnaire (SAQ) and may be required to conduct quarterly vulnerability scans, depending on the SAQ type applicable to their payment environment.

The SAQ type that applies to a retailer depends on how card data flows through their systems. The most important distinction is whether card data ever touches the retailer's own servers. Retailers using a fully hosted payment page — where the customer is redirected to a payment gateway's own page to enter card details — qualify for the simplest SAQ type (SAQ A), which has minimal requirements. Retailers who process card data directly on their own website, or who integrate payment processing JavaScript into their own pages, face more demanding SAQ types with significantly more controls required.

The consequences of PCI DSS non-compliance are layered. Acquiring banks can charge monthly non-compliance fees. If a breach occurs and the retailer is found to be non-compliant, the financial institution bears the cost of card reissuance, fraud losses, and compliance investigation — and passes this back to the retailer through card brand fines that range from tens of thousands to hundreds of thousands of pounds. The retailer also faces the risk of losing their ability to accept card payments — a business-ending consequence for most retailers.

The 12 PCI DSS Requirements in Practice for Small Retailers

PCI DSS v4.0 (current as of 2024) organises its requirements across six goals and twelve high-level requirements. For small retailers, the requirements with the most practical day-to-day relevance are:

• Requirement 1 & 2 (Network Security): Install and maintain a network security configuration. Change vendor default passwords on all systems — routers, switches, payment terminals, and any other networked device.
• Requirement 3 (Stored Data): Do not store sensitive authentication data after authorisation. If you use a payment gateway that tokenises card data, confirm that you are not storing full card numbers anywhere in your systems — databases, spreadsheets, email, or log files.
• Requirement 5 & 6 (Security Systems and Applications): Protect all systems against malware. Develop and maintain secure systems. Apply security patches within one month of release for applications in the cardholder data environment.
• Requirement 7 & 8 (Access Control): Restrict access to cardholder data by business need to know. Identify and authenticate access to system components — every user account should be individual, with strong passwords and MFA where applicable.
• Requirement 10 (Logging and Monitoring): Log and monitor all access to network resources and cardholder data. This requirement explicitly calls for a security monitoring capability — the ability to detect and investigate anomalous access to systems that handle card data.
• Requirement 12 (Security Policy): Support information security with organisational policies and programmes — a documented security policy, annual risk assessment, and staff training.

Where PCI DSS and GDPR Overlap and Diverge

PCI DSS and UK GDPR share several common requirements: both mandate access controls, both require logging and monitoring, both require staff training, and both require incident response procedures. A retailer building a security programme that addresses one framework will find that the controls largely address the other — but there are important differences.

GDPR has a 72-hour breach notification obligation to the ICO that PCI DSS does not replicate — PCI DSS requires notification to your acquiring bank and the card brands, but not on the same timeline or through the same channel. A breach that triggers PCI DSS incident response also triggers GDPR notification, and the two processes need to be coordinated. Having a documented incident response procedure that explicitly covers both notification obligations — and assigns named responsibility for each — prevents the confusion that leads to missed notification deadlines.

GDPR applies to all customer personal data, not just payment card data. Order histories, delivery addresses, account credentials, and marketing preferences are all personal data under GDPR. PCI DSS is specifically focused on payment card data. Retailers need to apply GDPR-appropriate security to their broader customer data, not just to the card data environment that PCI DSS covers.

The Acquiring Bank Relationship

Your acquiring bank is your primary PCI DSS compliance enforcer. They will periodically ask for evidence of your compliance status, may require you to complete a new SAQ following a change to your payment environment, and will investigate if your merchant account is implicated in fraudulent transactions. Maintaining an open and proactive relationship with your acquiring bank's merchant services team — including being transparent about changes to your payment infrastructure — reduces the risk of compliance surprises and demonstrates responsible stewardship.

If you are breached, contact your acquiring bank immediately. They will initiate a PCI forensic investigation and will manage the card brand notification process. Do not attempt to manage the PCI response independently — your acquiring bank is the correct first contact for any payment card security incident.