5 min read

The ENTITY (a scary PCI monster)

Picture of David Gamey David Gamey : Oct 31, 2019 10:07:00 PM

pci

If you're subject to PCI DSS you need to understand "The ENTITY". We aren't talking about a horror movie. Instead we are talking about something potentially far scarier - your networks, servers, workstations, applications, people, process, responsibilities, third parties, and your contractual relationships. In this article we hope to show you how to understand and tame "The ENTITY" in the context of PCI DSS.

If you are new to PCI, you can be forgiven for thinking that the DSS is mostly about data, technology and process. It's just as important to understand the boundaries of your responsibilities. And for that you need to understand the contractual landscape. To properly understand the boundaries of The ENTITY you need to follow the money (i.e. the contract chain). To do that we need to start at the top.

PCI DSS is mandated by the Card Brands that founded PCI - namely American Express, Discover, JCB, MasterCard, and Visa. Each maintains their own compliance programs based on PCI Standards. Each Card Brand sets their own rules for who must validate, how often, and by which method. They are also responsible for setting any incentives and penalties. These responsibilities and liabilities are built into their operating regulations, and their contracts.

Card Brands often don't have direct contracts with merchants and cardholders. Instead they pass on responsibilities indirectly through Issuers (to cardholders) and Acquirers (to merchants). Any of these organizations can contract to service providers (Third parties). When you use third party services you must understand not only who provides the service to you, but also who holds the contract for that service. You must also ensure that you pass on responsibility in any of the contracts you accept. Failure to do so makes you non-compliant.

By way of example, a merchant under contract to an Acquirer might use a third party e-commerce provider. That third party could provide services under contract directly to the merchant or indirectly via the acquirer. In both cases the responsibilities under PCI between the merchant and third party will be very similar. However, the responsibilities for due diligence, and monitoring of compliance, and any liability will be different depending on who holds the contracts.

During an assessment, your assessor (e.g. a QSA) will be interested in the documented responsibilities in your agreements and in a detailed formal responsibility matrix that breaks down specific DSS responsibilities in detail (See DSS requirements 12.8 and 12.9. Also see some of the PCI resources at the bottom of this article). QSA's are generally not interested in liabilities as that is best left to lawyers. These matrices need to be crystal clear as to which party does what down to the DSS requirement level. If some requirements are shared then that also needs to be documented. And if requirements do not apply, those too need to be documented with a rationale.

Why so much detail and rigor? Many of the requirements in PCI DSS have been born out of failure. People are busy and compliance isn't always at the top of their focus. People with good intentions make assumptions and mistakes. Complexity fosters mistakes. And a few people are less than candid and may want to slip something by an assessor or their management.

Consider an example: a company outsources their cardholder data environment to a compliant data center so they can focus on their business. Job Done?

But what does that service provider actually do? Providing compliant co-location is not overly difficult.
Who patches the operating systems? Applications? Or provides remote support? Perhaps the service provider does this at your request - but are they doing it compliantly?
Maybe the service provider does all the patching but needs your cooperation to get maintenance windows to apply those patches. This is a shared responsibility. If you fail to grant these, who will be to blame?
Are the services provided by the third party standardized or customized just to you? Are they trying to do you favours? Maybe their standard services are compliant, but what of the custom services?

Maybe this is all on them, maybe it is shared, and maybe it's all on you. Without a well-defined set of responsibilities, you could completely fail a critical control. Just imagine, during your annual assessment, how painful it would be to discover that you are on the hook for a large number of unexpected compliance activities.

In your due diligence, you may want to consider what level of assurance you may need from your third parties. Consider:

Small or medium sized merchants using a large service provider that must complete annual assessments and a Report on Compliance (RoC) seems an easy judgement call.
But what if you are a large merchant requiring a RoC? Do you really want to rely on small service provider who provides a self-assessment questionnaire (SAQ)? Should you seek a RoC? Is there something else in between that will make you comfortable with that risk?
What if your service provider doesn't want to validate themselves? Did you know that their services must now be assessed within your scope? How comfortable are you with that situation and risk?

Perhaps you are using newer tech like Cloud or Containers to run your payments. Just because they are new and different doesn't mean they don't need to be compliant. New-tech evangelists and sales people will sometimes try and claim they are somehow different, misunderstood, and that regulations shouldn't apply. After all that is the nature of disruption. However, nothing could be further from the truth. Any service, product, or solution needs to be fit for purpose. It is a fair observation that new-tech may require some reinterpretation in the light of standards and legal requirements; however, no one ever said compliance is easy. Many cloud providers understand this and have taken on the challenge of helping their customers with their due diligence.

The bottom line is that if something - a service, a solution, or a product - can't support your legal and contractual requirements then it simply isn't fit and they are selling snake-oil. Is it really a silver bullet that can slay your monster? Are they really as advertised and promised? Remember, if you buy these and they don't measure up, you will have failed in your due diligence. While nobody wants to be a Neanderthal, it is often prudent to have a healthy skepticism and possibly a second opinion when dealing with compliance.

There are literally hundreds of companies that have been breached. Every week we report on multiple breaches. This isn't a club you want to join. You can be sure that in the unpleasant case of a breach, these relationships will be looked at just as closely as the technologies and processes. Regardless of fault, the press will not be kind and will use the most visible company names in their headlines.

Once you understand the boundaries of your ENTITY, you can dive into the details of your networks, technologies, processes, and people and work out your scope. Below we've linked to a number of articles and resources to help you understand both your ENTITY and scope.

We trust you have found this useful and your ENTITY is now less scary.

If you are having trouble defining the boundaries of your ENTITY or understanding your scope, please contact us. We are here to help.