This has recently become a very hot topic as more and more businesses get serious about controlling their supply chains not only for PCI but for information security in general. It has only taken three years after the Target breach for organizations to really understand that their computer systems and networks are all part of a larger technology ecosystem and that their security depends on the security of everyone else they are connected. This post provides guidance for service providers and merchants alike.
The first question that can come up is what is the difference between a third party and a service provider? Technically there is no difference. “Third party” is a term that comes from the financial audit industry which is where I first encountered it a long time ago. Third parties are those outside organizations that provide services under contract to another organization. Examples can include services such as office cleaning, facility management, mailroom management, lock box services, secure document destruction, human resources and a whole host of other business services.
In today’s complex corporate structures, functions such as information technology or human resources as well as whole business units can be separate legal entities and provide business services to other parts of the corporation. While not truly outside organizations, for regulatory assessments they may also be treated as third party organizations. I have a number of large clients that take this approach because it simplifies their audit/assessment and compliance reporting processes. However if a merchant or service provider is going to take such an approach, it should be discussed with their acquiring bank and/or the card brands to obtain their formal approval before assessing and reporting under that approach.
What Organizations Are Service Providers?
The next question that comes up is what organizations qualify as a third party service provider under PCI? The PCI SSC defines a service provider in the PCI DSS Glossary as:
“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”
Under that definition any third party organization that directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) are service providers. Examples of these organizations are transaction gateways, transaction processors and some loyalty program providers. One notable exception is acquiring banks. Acquiring banks are only third parties if they provide services in addition to being an acquiring bank such as card terminal management and transaction processing.
Where things get messy is third party service providers that do not directly come into contact with SAD or CHD but could come into contact with it. While I have written two posts on this topic, there still seem to be a lot of managed service providers in denial over whether they need to be PCI compliant. The bottom line is that if you are a service provider and you could impact the security of SAD/CHD, you must comply with the PCI standard (see PCI SSC FAQ 1092).
But that is where complaints and arguments from such peripheral service providers focus. Most have no idea if their customers need PCI compliance unless they ask or get asked by a customer. As a result, they tend to argue that because they do not know they do not need to comply. Unfortunately, ignorance and/or lack of knowledge are not a valid reason to not be PCI compliant. That is why it is incumbent for all service providers to ask every customer and prospective customer if they require PCI, HIPAA, GLBA or any other regulatory compliance so that the service provider can ensure that they can properly comply with those requirements.
Service Provider Levels Explained
Service providers, like merchants, are categorized into levels by the card brands. The most commonly referenced service provider levels are those defined by Visa, MasterCard and Discover.
- Level 1 service providers conduct 300,000+ transactions annually on behalf of their customers, and
- Level 2 service providers conduct less than 300,000 transactions annually for their customers.
JCB and American Express have their own service provider level definitions, but there are very, very few service providers that only process exclusively for those brands. If you are one of those rare service providers, I would tell you to visit the appropriate brand’s Web site and review their service provider level definitions.
Level 1 service providers must conduct a PCI assessment that results in a service provider Report On Compliance (ROC) and related Attestation Of Compliance (AOC). That assessment can be conducted by a QSA or an ISA just as with merchant PCI ROCs. Level 2 service providers can use either the service provider SAQ D or create a service provider ROC.
These levels also add confusion to those service providers that do not process or transmit any transactions. As they rightfully point out, their transaction volume is zero. I then point out to them that zero is less than 300,000, so they are considered a Level 2 service provider. Problem and confusion solved.
The most important thing to understand about service provider levels are that if your organization is a service provider level 1 for any card brand, your organization is a level 1 for all card brands.
The next important thing to note about these assessment processes is that they must use the service provider specific SAQ D, ROC and AOC forms. I cannot tell you the number of times I have gotten a service provider’s AOC and/or SAQ/ROC and it is not the service provider specific version. More on this topic later.
The Global Registries
Once we get these third parties to admit they are in scope for PCI compliance, the next issue that typically comes up is in regards to the card brand global registries for service providers. Both Visa and MasterCard have public registries of service providers on their respective Web sites. These are strictly marketing schemes run by the respective brands and it is not mandatory that service providers be listed on either of these lists. Since they are marketing schemes, they have no real meaning regarding any merchant organization’s PCI compliance and are not a substitute for getting an AOC from a service provider. What they do provide is a quick way for merchants to find PCI compliant service providers providing services they wish to outsource. As a result, a lot of service providers like to be listed on these Web sites just so that merchants will consider them.
To be listed on either of these Web sites, the service provider must have a PCI QSA (an ISA cannot be used) conduct an assessment and then the QSA must file the resulting compliant ROC and AOC with the appropriate card brand. In the case of service providers that process or transmit SAD/CHD, they will have a relationship with a bank that must sponsor the service provider with the brands to get listed on the Web site. For service providers that do not have a relationship with a bank because they do not process or transmit SAD/CHD, those service providers must contact the appropriate card brand who will then sponsor them. Once approved by the brand, the service provider then pays a fee to be listed. To stay listed on the brands Web site, the service provider must annually revalidate their compliance using a QSA, have the QSA file their compliant ROC/AOC with the brand and pay a renewal fee.
To add confusion for service providers, Visa also maintains a separate, private inventory of service providers. This list is for Visa and their acquiring banks to reference and is not available to the public. Visa is trying to ensure that all service providers are tracked for their annual PCI compliance even if they do not register for their public Global Registry. So if you are a service provider and are filing a service provider SAQ D/ROC or you do not register for the public Global Registry, you will be asked to fill out information for this private Visa service provider inventory.
Service Provider AOC Issues
The most common AOC problem we encounter with service providers is that they only assess some of their services provided, not all of their services. For third party run data centers the most common requirements assessed are requirements 9 (physical security) and 12 (policies) but no other requirements are assessed even if that same firm provides managed services such as network security, network monitoring, virtualization, server management and network management. I will address this situation later on in the post when discussing service providers that do not have a PCI assessment.
The next most common problem is that the AOC provided to the merchant is not a service provider AOC. The biggest problem this mistake creates is that there is no way to know what services provided to the merchant were assessed for PCI compliance. Then you have a very embarrassing conversation for all involved as you inform the service provider that their PCI compliance is reported on the wrong form(s). Worse is the fact that most times this results in a whole new assessment being conducted because service provider requirements were not assessed and too much time (i.e., more than 90 days) has passed since the assessment was completed.
With the introduction of v3 of the PCI DSS, the service provider AOC has had a number of changes to facilitate merchants’ evaluation of the service provider’s PCI compliance. The first change was to list not only what services were assessed in section 2a, but what services were not assessed. Then for each service that was assessed, the QSA/ISA is required to individually document in separate sections of 2g of the AOC which of the 12 requirements were tested for each service.
Which brings us to the third most common problem. The AOC does not document each service individually in section 2g. As I stated earlier, this was a change with v3, but many QSAs/ISAs did follow the instructions in the section. In addition, the Council has not helped this situation as the AOC document is locked so adding additional sections for 2g are not possible using the Council’s form. The Council’s advice is to copy that section and then paste additional sections as necessary to the end of the AOC.
Another situation that we occasionally run into is service providers that have gone through the PCI assessment process but refuse to provide their customers with a copy of their AOC. Reasons for not providing the AOC vary (from the stupid to the absolutely idiotic), but it happens more often than I would like to admit. The PCI SSC has repeatedly reinforced at their Community Meetings and in FAQs that if a service provider has been independently assessed, they must provide their service provider AOC to their customers. If you encounter such a situation, I would recommend contacting the appropriate card brands and complaining to them about the service provider particularly if that service provider is listed on the card brands’ public Global Registry. In most cases, such complaints will result in the brand suspending the service provider’s listing until they comply.
The last problem we encounter with AOCs is their timing and availability. In a perfect world, every service provider would have an AOC less than a year old available for every customer. But in the real world, a merchant conducting their assessment encounters service providers that either: (a) are also in the process of conducting their assessment, (b) had their assessment delayed and will not be able to provide an AOC by the time the merchant’s assessment is completed, or (c) does not have an AOC.
The first two conditions are timing issues and should not be a problem unless the service provider has not been compliant in the past. As the Council has repeatedly pointed out, no organization’s PCI compliance is affected by the PCI compliance of any other organization. In addition, the Council has also said that the PCI assessment process are not conducted to the standard of an AICPA SSAE 16 assessment which needs reliance on third party assessments. As a result, you need to work with your QSA/ISA, bank and service providers to agree to an approach to handling these first two conditions. My recommendation is as long as there is close to a year between assessments (give or take 30 to 60 days), I would accept whatever current AOC is available from the service provider. For situations where there is going to be significant differences in time, I would consult with your acquiring bank or the card brands.
It is the third condition that creates the most heartburn for a merchant and the service provider. In this situation, a merchant has no choice but to include that service provider as part of the scope of their PCI assessment (see PCI SSC FAQs 1065 and 1290). Most of the time, this is covered under the service provider’s contract under a section regarding regulatory and legal compliance audits and assessments. The service provider agrees to allow the merchant’s staff or authorized representatives to conduct any audits/assessments whenever required. In very rare situations, I have encountered older contracts that do not have such audit/assessment provisions and it becomes a painful issue to get the service provider to comply with the assessment process.
However, this third condition creates a larger scope and will result in increased costs for a merchant’s PCI assessment. Sometimes that increase can be extremely significant if the service provider is doing a substantial amount of the work that needs to be evaluated such as hosting and managing a merchant’s IT environment. While QSAs try to minimize the occurrence of this sort of situation when scoping engagements, they still encounter it as the merchant is confused and does not understand the implication of their decision to use a non-PCI compliant service provider and their responsibilities under the PCI DSS and their Merchant Agreement. As a result, the QSA does not get accurate answers to their scoping questions and does not find out about the service provider’s involvement until they are performing the assessment.
Non-PCI Compliant Service Providers
Before discussing this, I first need to dispel a myth. Nowhere does the PCI DSS require a merchant to use only PCI compliant service providers (see PCI SSC FAQ 1312). That is a requirement specified by certain card brands in their Merchant Agreements (most notably Visa and MasterCard). Therefore not using PCI compliant service providers does not and should not result in a PCI compliance issue provided they are assessed as part of the merchant’s assessment as stated earlier.
Getting back to the topic at hand. As an example, you have a service provider AOC and it says that section 8 is not compliant (with the latest changes in v3.2 for service providers, this is a situation that is becoming more and more common.) As a merchant, what do you do?
This is where requirements 12.8 and 12.9 come into play as part of an organization’s vendor management process. As part of your organization’s vendor management process you should have the following processes, at a minimum, in place.
- Have a complete inventory of service providers including the date of their last AOC, expected receipt date of their next AOC, and whether the current AOC was PCI compliant. If not PCI compliant, it should note for each service provider those areas of non-compliance and the dates each area will be compliant.
- For any non-PCI compliant service providers, periodic meetings need to be held with the non-compliant service provider to obtain updates on their remediation efforts. Depending on the duration and complexity of the project(s), these meetings may be conducted quarterly, monthly or even weekly. However notes need to be kept for all of these calls and information updated as to the project(s) status. These updates should not be suspended until the service provider is judged PCI compliant.
- Any adverse changes in remediation efforts status should result in a review of the service provider and possibly result in seeking a new PCI compliant service provider.
- To be judged compliant, the service provider must have a QSA/ISA submit proof (for example, a letter outlining evaluation procedures followed with a revised AOC) that they have evaluated the remediation efforts and that those efforts are complete and the PCI requirements in question have been judged PCI compliant.
The most important take away in this whole discussion regarding non-PCI compliant service providers is that it does not affect the PCI compliance of the organization using the service provider. That said, anyone following such procedures outlines above should be prepared to provide their acquiring bank and/or card brands with proof of all of these monitoring activities.
As with all topics related to PCI compliance, this one is no different and there will be nuances to all of these discussions. But hopefully you now understand all of the basics regarding third party service providers.