[in]security blog

Why do some Issuers believe they don’t need to be PCI DSS compliant?

Written by David Gamey | Jul 20, 2021 2:07:00 AM

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:

  1. Make sure you have senior management support
  2. Find and document your scope
  3. Determine your applicable requirements (i.e. your footprint)
  4. Find and exploit ways to simplify your compliance through de-scoping and reducing applicability
  5. Identify gaps, Establish and follow a roadmap
  6. Monitor changes to the business, your scope, and your compliance

Learn More:

The Rules

Acquiring-side Breaches

Issuing-side Breaches
View full post