Why do some Issuers believe they don’t need to be PCI DSS compliant?
Posted by David Gamey on 19 Jul 2021.
Documents from the PCI Council, MasterCard, and Visa clearly indicate that Issuers are required to be PCI DSS compliant (see Learn More below). Yet many people in the card issuing industry are either unaware or confused about this. None of these requirements are new and many have been in-place for more than a decade. What could be responsible for the confusion? And what does it all mean?
PCI DSS receives a great deal of attention from organizations on the acquiring side of the payment card industry. Merchant banks, payment processors, merchants, and their service providers have been the primary focus of the card brand compliance programs since the inception of the PCI DSS standard in late 2004. The major concern of these programs was to stem the increasing tide of breaches in this side of the industry (see Acquiring-side Breaches below). There were several reasons why these organizations were seen as risky:
- They vastly outnumbered Issuers and so there were far more places to steal cards from
- The large number of entities meant controls were inconsistent
- The growth of e-commerce and the poor state of Internet security
- Awareness of account data compromise risks was low as was their perceived risk
- They weren’t directly on the hook for breaches
- Small margins and lean organizations meant many organizations outsourced software and processing and had little awareness of how their systems worked
These factors and the rise in major breaches over the first decade of the PCI DSS (first in e-commerce and later in POS systems), kept the focus squarely on the acquiring side of the industry.
In effect, Issuers caught a compliance break because they were less of a risk. Specifically:
- There were fewer of them
- They were directly impacted by account compromises
- They were more focused on fraud mitigation and protection hitting their bottom line
- Their security processes were more mature
- Many of their processes are outsourced to third parties with special compliance requirements (e.g. card production)
- A number of large issuing service providers were demonstrating their compliance annually
Consequently, Issuers are expected to be compliant but have never been required to demonstrate compliance on a regular basis. Given all of this it’s easy to see how compliance could be considered a contracting issue or someone else’s problem.
While requirements to validate compliance vary from card brand to card brand, it can be required. Visa requires DSS assessments if a member changes their VisaNet end point. A data breach requires a forensic review against the DSS. Closed loop brands such as Amex don’t have third party issuers and have their own rules reporting to themselves. And while Issuer breaches are rarer, they are not unheard of. Not only are breaches at issuing banks less common, they are frequently smaller, often exploiting third-parties and non-core systems, and target PII and bank accounts directly (rather than credit cards). Finally, information on issuer breaches tends to be less accurate, detailed, and complete.
None of this lets Issuers out of their DSS responsibilities. And even though they might not be required to validate compliance today, they still need to run a program including
- management third party compliance
- understanding their flows and controls
- understanding if they have any compliance gaps
- effective risk management
- being ready to demonstrate compliance when needed
Some people will argue that nothing much has changed since PCI first emerged and that Issuers are still low risk and should get a pass. While it’s true that Issuers may be at lower risk of breach than other card entities that isn’t the entire story. The threat landscape is dramatically different including:
- Acceleration of the vulnerability-patch arms race and increasing frequency of zero-day vulnerabilities
- The emergence of nation-state threat actors, ransomware, and ransomware as a service operators
- The rapid evolution of ransomware operators to exfiltrate and wipe data, publicly shame their victims, and sell or dump their data
- Security improvements on the acquiring side of the industry that may not have been matched on the Issuing side
- Increases in insider and supply-chain attacks
For organizations not required to validate, gaps can easily fly under the radar. Gaps in logging and security testing are common in organizations that have never validated. Why would anyone expect this to be different for Issuers.
In the end, organizations that become complacent about risk management may find their non-compliance leads to a data breach.
When you need to start the deep dive into PCI DSS, we suggest you read https://controlgap.com/blog/6-Ways-to-Deal-with-the-Magnitude-of-PCI-DSS which looks at the following:
- Make sure you have senior management support
- Find and document your scope
- Determine your applicable requirements (i.e. your footprint)
- Find and exploit ways to simplify your compliance through de-scoping and reducing applicability
- Identify gaps, Establish and follow a roadmap
- Monitor changes to the business, your scope, and your compliance
[FAQ 1217] Does the PCI DSS apply to issuers? https://pcissc.secure.force.com/faq/articles/FrequentlyAskedQuestion/Does-the-PCI-DSS-apply-to-issuers
- “Each payment card brand manages their own PCI DSS compliance programs that may include, for example, who must validate compliance, merchant and service provider levels, and due dates.”
[DSS 321] PCI DSS v3.2.1 https://www.pcisecuritystandards.org/documents/PCIDSSv3-2-1.pdf
- “PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process, or transmit cardholder data and/or sensitive authentication data.”
- “It should be noted that all PCI DSS requirements apply to issuers, and the only exception for issuers and issuer processors is that sensitive authentication data may be retained if there is a legitimate reason to do so.”
- Requirement 3.2 explicitly addresses issuers.
[Visa#1] Issuers and Payment Card Industry Security Standards (Undated) https://usa.visa.com/content/dam/VCOM/global/partner-with-us/documents/issuers-and-payment-card-industry-security-standards.pdf
- “All organizations, and their Agents, that store, process or transmit Visa account data are required to comply with the PCI DSS. (Visa Rules ID#0002228). This is inclusive of issuers.”
[Visa#2] Issuers’ Payment Card Industry Data Security Standard Frequently Asked Questions (2011) https://usa.visa.com/dam/VCOM/download/merchants/bulletin-issuer-pci-dss-faq-03312011.pdf
- “All Visa issuing and acquiring members and their sponsored agents, processors and/or service providers that store, process or transmit card data are required to comply with the PCI DSS.”
[Visa#3] visa-international-operating-regulations-main.pdf (2013) https://usa.visa.com/dam/VCOM/download/merchants/visa-international-operating-regulations-main.pdf
- VisaNet Processor Contracts require compliance with PCI DSS.
- Visa members are required to be compliant with PCI DSS, A Visa Issuer is defined as a member that issues Visa Cards.
[MC#1] New Cybersecurity Standards & Programs Chapter (2019) https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/New-Cybersecurity-Standards-and-Programs-Chapter-v1.0-FINAL-1.pdf
- “PCI DSS is required for all issuers and acquirers, although validation of compliance to Mastercard is not required”
- Egghead.com – e-tailer / 3.7M cards / 2000 https://en.wikipedia.org/wiki/Egghead_Software
- Card Systems Solutions - processor / 40M cards / 2005 https://privacyrights.org/resources/2005-cardsystems-security-breach-affecting-40-million-cardholders
- TJX Companies – merchant / 94M cards / 2007 https://en.wikipedia.org/wiki/TJ_Maxx, https://www.zdnet.com/article/wi-fi-hack-caused-tk-maxx-security-breach/
- The Home Depot – merchant 56M cards / 2014 https://krebsonsecurity.com/2014/09/banks-credit-card-breach-at-home-depot/
- Target – merchant / 40M cards / 2013 https://krebsonsecurity.com/2014/05/the-target-breach-by-the-numbers/
- Heartland - acquirer / 160M cards / 2007 https://krebsonsecurity.com/2013/07/hacker-ring-stole-160-million-credit-cards/
- Magecart breaches: TicketMaster, British Airways, and many more from 2015 and beyond https://www.zdnet.com/article/ticketmaster-breach-was-part-of-a-larger-credit-card-skimming-effort-analysis-shows/
- Capital One - 106M cards / 2019 https://www.nytimes.com/2019/07/29/business/capital-one-data-breach-hacked.html
- Citibank – 360K cards / 2011 https://www.bankinfosecurity.com/citi-breach-360k-card-accounts-affected-a-3760
- JP Morgan Chase - 2013 https://www.reuters.com/article/us-jpmorgan-cybersecurity-idUSKBN0K105R20141223
- Bank of America - 2011, 2020 https://blog.trendmicro.com/bank-of-america-loses-10-million-in-data-breach/, https://www.infosecurity-magazine.com/news/data-breach-at-bank-of-america/
- Fifth Third Bank - 2018 https://www.infosecurity-magazine.com/news/us-bank-slammed-for-breach/
- Discover – 2018 https://www.scmagazine.com/home/security-news/data-breach/discover-financial-services-notifies-customers-of-data-breach-incident/