Is compliance with payment card data security standards being ignored?

The recent £500,000 fine, levied by the UK Information Commissioner on DSG, the owner of Currys PC World and Dixons Travel stores, highlights a worrying trend of non-compliance with payment card security standards. Our Security & Privacy Team has prepared a full blog post on the DSG fine.

It seems somewhat perverse that, in a world where data breach scrutiny and sanctions have increased dramatically, compliance with payment card security standards have fallen.

However, this appears to be the case, at least according to Verizon’s Payment Security Report.  Published in September 2019, alarmingly, the report reveals that full compliance with the Payment Card Industry Data Security Standard fell to 36.7% globally in 2019 – dropping from 52.5% in 2018.  The report breaks this down by region as follows:

• Asia-Pacific has the highest compliance at 69.6%;

• Europe, Middle East and Africa holds the middle ground at 48%;

• the Americas is just 20.4%.

In grading terms, Asia-Pacific achieves a high C, Europe, Middle East and Africa a lowly E and summer schooling is on the cards for the Americas. In each case, the careers teacher is busy realigning expectations.

This drop is no one-off, but follows a steady decline over the past three years from a peak at 55.4% in 2016.

What is the Payment Card Industry Data Security Standard?

For people with a severe aversion to acronyms, I apologise and please brace yourself.  I shall try to be brief.

In 2006, Visa, Master-Card, JCB, Discover and American Express founded the Payment Card Industry Security Standards Council (PCI SSC) to establish common security standards.  These include:

• PCI Data Security Standard (PCI DSS): The PCI DSS is the overarching framework that applies to all entities that store, process, and/or transmit cardholder data. It covers technical and operational standards.

• Payment Application Data Security Standard (PA-DSS): The PA-DSS applies to software developers and integrators of payment applications that store, process or transmit cardholder data.

• PIN Transaction Security (PTS) Requirements: The PTS focuses on characteristics and management of devices used in the protection of cardholder PINs.

In general terms, the PCI DSS are intended to apply to all organizations or merchants that accept, transmit or store any cardholder data (such as e.g. the cardholder name, primary account number, expiration date and security code), with the PA-DSS and PTS setting out additional standards for software applications and devices.

The standards are intended to be imposed by a virtuous contractual waterfall flowing down from card issuing members – to customers (typically banks) – to merchants – to service providers (including e.g. payment processors, payment application providers and device manufacturers).

Significantly, the PCI DSS is not typically imposed or enforced on the basis of statute although, in the United States, legislative proposals have been proposed several times.

Why should businesses care?

The answer is – for many reasons.  These include:

• Increased Risk of Breach: non-compliance inevitably increases the likelihood of a data breach.

• Contractual Fines: a business will be liable to pay monthly non-compliance fines passed from the acquiring banks (ranging from $5,000 to $10,000 per month). In addition, a business may be liable for card reissuance costs and the costs of additional fraud detection services mandated by the card brands.

• Reputational Damage: data breaches are now widely reported, which can have a very real impact on revenue and share price.

• Because Data Protection Regulators say so: regulators such as the Information Commissioner have expressly stated that PCI DSS compliance matters and will be taken into account when considering enforcement action.

Comment

The exact reason for the current slump in PCI DSS compliance is unclear, although it is likely to be due to a combination of factors including:

• Legacy Technology: failures to upgrade and patch legacy systems to protect against vulnerabilities and malware, or to address updated and enhanced security standards and requirements.

• New Technology: the adoption of cloud systems (such as SaaS, PaaS and IaaS) as well as other new technology, payment platforms and payment methods, such as mobile apps and contactless payments. For example, the BA data breach resulted from a hack of the ba.com website and mobile app.

• Systems Integration: the integration of cloud and on-premises systems and applications, including payment platforms, for the purposes of such systems operating as a coordinated whole, including enabling the flow of data across systems. For example, the hack of Target’s point of sales devices in 2013, resulting in a loss of personal information of 110 million people, was claimed to result from hackers stealing credentials from a third party aircon systems vendor.  These details were then used to gain access to Target’s wider system via an integrated electronic billing, contract submission and project management platform to which the aircon systems vendor had access.

• Outsourcing: the increasing desire to outsource key functions, including core IT infrastructure and payment processing resulting in increased points of vulnerability. There is a further risk that businesses may then treat PCI DSS compliance as a service provider problem, sticking their heads in the sand hoping that all will be well.  However, ultimate responsibility for ensuring compliance will remain with the customer.

• Open Source Software: the use of open source software in core software systems. Vulnerabilities in open source software are widely reported and are capable of being exploited by hackers.  For example, the massive data breach suffered by Equifax in 2017, exposing the personal information of 147 million people, was claimed to be as result of Equifax failing to patch a disclosed vulnerability in Apache Struts, a common open source web server.

• Compliance Fatigue: there is a real risk of compliance fatigue with businesses developing complex and detailed data protection compliance programmes, that tick all the required boxes, but which may not be fully implemented in practice and/or withstand the scrutiny of a professional security assessment.

• Finite Resources: linked to the above, as the compliance regime expands, financial and human resources are becoming increasingly stretched with businesses struggling to manage the compliance burden.

In the UK, a number of recent security breaches and fines have shone a very bright light on PCI DSS failings.  In particular, in relation to the DSG fine noted above, when considering the technical and organisational provisions within DSG’s wider IT estate, the ICO highlighted an assessment by an information security consultancy in May 2017 (prior to the breach in 2018).  That assessment had noted that the integrity of the POS terminals should not be relied upon and that such terminals may not be compliant with the requirements of the PCI DSS as relating to store networks and POS terminals.

Although the ICO noted that that PCI DSS compliance is not in itself indicative of compliance, the ICO considers it helpful when determining an “appropriate” measure of security in relation to personal data processed by the payment card environment. Furthermore, the guidance on the ICO’s website specifically states:

“Although compliance with the PCI-DSS is not necessarily equivalent to compliance with the GDPR’s security principle, if you process card data and suffer a personal data breach, the ICO will consider the extent to which you have put in place measures that PCI-DSS requires particularly if the breach related to a lack of a particular control or process mandated by the standard.“

In light of the fact that both the recent travel industry breaches involved the loss of payment card details, including card numbers and expiration dates, the ICO will no doubt be paying careful attention to whether those companies complied with their PCI DSS obligations.

However, the Sword of Damocles (in the shape of fines up to of £183m British Airways) will not be falling any time soon, as the ICO has agreed to an extension of the regulatory process until 31 March 2020.  It also seems highly likely that the fines will be reduced, particularly given the resources at these organizations’ disposal, but the ICO is nonetheless likely to wish to flex its muscles in this new GDPR world and we await the outcome with bated breath.

In the meantime, some key points to consider if you process cardholder data:

• Data Protection Compliance Programmes: ensure that PCI DSS compliance forms a key part of that programme and that the systems that process cardholder data are regularly tested for vulnerabilities.

• Contractual Rights: ensure that all relevant contracts include appropriate PCI DSS commitments, including in contracts with any person that may handle cardholder data on your behalf, as well as payment application providers and device manufacturers. Key issues to address include:

  • ongoing commitments to comply with any relevant PCI DSS and other mandated security standards, as updated from time to time;

  • ongoing rights to monitor and verify compliance, including for the purposes of undertaking regular PCI DSS assessments;

  • non-financial remedies for non-compliance, including reporting, cooperation and assistance with investigations, publicity, audit rights, rights to require the service provider to implement additional security measures, etc.. A number of these may be addressed in part by GDPR compliant data protection clauses;

  • financial remedies for non-compliance, including to what you will expect to recover any fines (including fines levied by card brands and regulators) and other losses suffered in connection with a breach and whether these will be covered by any limitations on liability.

• Open Source Software: ensure that the business has clear procedures in place regarding the use of open source software, including in relation to any systems which store, process, and/or transmit cardholder data. As a minimum, these procedures should include a process for monitoring and patching any known vulnerabilities in the open source software.

• Understand your obligations: if you are merchant, your obligations will vary depending on the volume of transaction that you process. Merchants will fall into one of four merchant levels with e.g. level one merchants being required to appoint an independent Qualified Security Assessors (QSA) to undertake an annual report on compliance. A list of approved QSAs can be found here.

• Payment Applications: merchants and service providers must use PCI SSC approved payment applications. A list of approved applications can be found here.

• Payment Systems Integrators: merchants and service providers must use PCI SSC approved payment systems integrators and resellers. A list of approved integrators and resellers can be found here.

• PIN Devices: merchants and service providers must use PCI SSC approved PIN devices. A list of approved devices can be found here.