Sage Advice - Cybersecurity Blog

Continuous PCI Compliance is Here

Everyone uses credit and debit cards (CC) to make purchases. It has become an expected form of financial transaction that is part of the economy around the world. Those very convenient set of numbers on plastic are now being stored as data digits in our ‘virtual’ wallets - on websites like Amazon.com and on our phones in Android Pay and Apple Pay. CC numbers are attached to our subscription services for things like Netflix, iTunes, Dunkin Donuts, and Uber. Today, businesses that do not accept credit cards post notices on their storefronts and at the cash register. For a business with a virtual retail presence it is unheard of to not accept a CC.

All of these conveniences are under-pinned by a web of commercial contracts and industry self-regulation. In 2006, the credit card brands (Visa, MasterCard, Discover, American Express, and JCB) joined together to form the Payment Card Industry Security Standards Council (PCI SSC), an organization that researches and publishes multiple standards on how to manage credit cards. The standards cover a wide range of activities from: writing applications that process CC; how a call center manages customer service representatives; and how merchants from the local fast food franchise to the finest hotel accepts payments from customers.

Here are the chain of relationships involving PCI SSC:

PCI-SSC articulates how business systems and processes are to operate when dealing with CCs.

PCI-SSC certifies Qualified Security Assessors (QSAs), companies that will audit entities that work with credit cards.

A customer opens a CC account from an issuing Bank that is authorized to issue one of the brands.

Vendors, Merchants, and Transaction Processors are expected to adhere to the guidance from PCI-SSC.

Each type of entity that deals with CC transactions has contracts that require adherence and attestation. This is not attestation to PCI-SSC. It is attestation to their corresponding partner.

Consumers use their cards with Merchants who then apply for the transaction to be approved through the various business systems, so that ultimately their Bank credits the merchant account.

What is not covered by PCI SSC?

The relationship between the consumer and the issuing Bank.

The contract relationships between the Vendors, Merchants, and Transaction Processors.

Business process at a Vendor, Merchant, or Transaction Processor that is not involved with CC.

The first published standards from PCI SSC focused on entities having appropriate documentation on how their business addressed CC processing. As the demands to improve transaction and information security ramped up, PCI SSC shifted the focus on successful compliance from paper to process attestation. This shift was seen as an improvement, but was again lacking because organizations could adjust practices to pass attestation and then revert back to non-compliant activities.

As version 3.1, and then 3.2, were published the emphasis tightened. Now, in addition to document compliance, organizations are expected to demonstrate process compliance. Compliance is now framed as an entity maintaining controls on a “Business-as-Usual” continuous basis. This is the new normal expected of merchants and every entity handling a CC.

With version 3.2, PCI SSC is clearly articulating that in all areas of CC activities the participants must be adhering to three principals:

Compliance to all applicable elements of the standard. The ability of organizations to ignore some difficult sections with a ‘document’ has gone away.

Compliance is continuous. Organizations that only achieve annual compliance are not compliant.

Compliance must be proven. Most Merchants self-attest. This means that either on their own, or with the help of a consultant, they file a Self-Attestation Questionnaire (SAQ). The tests and guidance in the latest version of each SAQ have evolved to look for and confirm evidence of the practices required for compliance.

PCI SSC has announced its intention to evolve the technical requirements in the various SAQ documents on a shorter cycle than in the past. Older insecure technical requirements are being phased out. The requirements are much improved in their effectiveness. They are good practices for most organizations to use on the entire enterprise, not just the parts handling CC data. Every entity should know their compliance status and be working towards 100%. While compliance does not inoculate them from a breach, it at least provides the best course of action to avoid a breach.

Issuing Banks are starting to push back on the losses from CC fraud and abuse. Transaction processors and merchants will be facing pressure to cover the losses and contract penalties for being the source of losses. The ultimate penalty for a commercial entity would be exclusion from accepting CC as a form of payment. That is something each entity needs to consider when deciding on the necessary investments in determining compliance and the consequences on not being compliant.

Are Your Service Providers Cyber Secure?

Proper oversight of your third-party service providers is an essential element of your cyber resilience strategy. Tyler Cybersecurity’s Service Provider Cybersecurity Assessment Program supports the management of all your third-party service providers. Our specialized approach helps you create the most efficient review process - saving you time while ensuring compliance.

Request More Information

Subscribe to Email Updates

The Tyler Cybersecurity Lifecycle

Cybersecurity isn’t a destination.

There is no single, straight path that will get you to the point where you can say, “We did it! We’re 100% cyber-secure.”

A more realistic destination is cyber resiliency – the ability to prepare for and adapt to changing conditions, so you can withstand and recover rapidly from disruptions. Achieving cyber resilience depends on what we like to call the cybersecurity lifecycle – an ongoing cycle of interconnected elements that compliment and reinforce one another.