PCI DSS: Credit card data and what to expect from version 4.0

In this podcast, we preview the forthcoming PCI Europe Community Meeting in Dublin later this month, where a major revision of the credit card payment data standard is expected.

Subjects covered are expected to include credit card payment data and point-to-point encryption, software security frameworks, use of the cloud, and what data should and should not be retained by those who transmit, store and process it.

Computer Weekly storage editor Antony Adshead talks with Vigitrust CEO Mathieu Gorge about likely subjects for discussion at the event and the implications for storage and compliance.

Adshead: Why are people getting together to talk about PCI DSS when we’re still devoting lots of attention to GDPR [General Data Protection Regulation], CCPA [California Consumer Privacy Act], etc?

Gorge: PCI covers organisations that transmit, process or store credit card holder data, which is one of the types of data that would be covered by GDPR, CCPA and other privacy and security regulations.

The standard was created 14 years ago by Visa, Mastercard, JCB and American Express, each of which had their own standards with which merchants and acquiring banks needed to comply. So they got together to create a single standard that superseded or complemented their own standards.

Today, we have a suite of 13 technical standards with new standards coming up on a technical basis. It covers merchants taking credit cards, payment service providers, acquiring banks, payment applications, integrations of payment solutions by integrators, as well as software security.

The current version of the standard is the PCI DSS 3.2.1. At the event in Dublin, they will unveil a major revision coming up in version 4.0.

In a nutshell, from a storage and compliance perspective, the high-level vision of it is that there are 12 high-level requirements with different controls that are either technical-, policy- or training-based, or a mix of these, and which essentially tell organisations what to do with regards to transmitting, storing or processing credit card holder data.

Adshead: What can we expect from the event in terms of storage, backup, data protection, etc?

Gorge: If you look at credit card holder data protection, there are a number of sessions in the event in Dublin that will cover data scoping.

So, which card holder data is in scope?

The definition of card holder data for PCI is reasonably clear within the standards.

However, there are some parts of the data that can be stored, others that cannot, like a CVV or CV2, depending on where you’re based.

There are sessions on point-to-point encryption that look at encrypting the data and storage and compliance of encrypted data, sessions on the new software security framework for payment applications, and sessions around cloud computing and how to store or transmit credit card holder data from a payment application based on e-commerce sites, mobile devices going back into the cloud.

Essentially, they are going to cover how to map your ecosystem, how to ensure that the right data is kept and the toxic data, so to speak, is taken away, how to store data, how to document all that so that you are ready for full assessment by a qualified security assessor.

We can expect some lively talks about mapping PCI to other frameworks, such as the NIST security framework, and the real value of the event is to network with your peers and understand what they do to store the data correctly to transmit it according to the standard and to make sure that if data is being processed, it’s not putting them, for PCI or GDPR or other regulations.