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.
PCI Guru 
Hi PCI Guru, what is your view on the situation where a service provider’s annual PCI assessment is, say, in May, but in Sep they introduce a new service. Most service providers will claim that the new service is PCI compliant, but in reality it is yet to be assessed as PCI compliant. We encounter this a lot, and we expect service providers to perform a QSA assessment for the new server at/before go-live, but service providers push back and say they are only required to undergo an annual assessment. In the past we have required a PCi QSA letter to close the gap and have required the service provider to indemnify us until they complete their next annual assessment, but the PCi SSC FAQ doesn’t appear to have a clear position on this. What is your view?
According to the Council and the card brands, services are expected to be PCI compliant day one, not up to 12 months later. There is no grace period when it comes to PCI.
When a service provider is introducing a new services, the Council and brands expect service providers to be proactive for PCI compliance. Those that I have worked call in the QSA to conduct a Gap Assessment before the service goes live (usually in the final QA cycle) to determine if there are any PCI compliance issues and then how to remediate any issues.
Hi PCI Guru, thanks for your fast reply. Look I’ve been involved with PCI DSS for 9 years myself and I agree 100% with your views, however, aside from your above reply I can’t seem to find any formal written position on this issue via the PCI DSS itself, the PCI SSC, or in the PCI FAQ. This has come up several times at my organisation including most recently last week. We have been working with our PCI QSA on this matter, and the best we could come up with is requesting a letter from the service provider’s PCI QSA stating that the new services were developed and will be hosted in a PCI compliant manner, and that (if nothing changes) they expect that it will be certified as compliant at the next annual PCI compliance assessment. So, if you are aware of an authoritative position/document on this matter (other than your opinion as a leading voice on all matters PCI DSS) can you please send me details? many thanks.
This is where it becomes a discussion with your acquiring bank as to what is acceptable. Your organization cannot just unilaterally accept the risk.
The Council has repeatedly said that PCI compliance is not a prerequisite to working with a service provider. That said, the Council has gone on to say that it is then the merchant’s responsibility to monitor and work with the non-compliant service provider on becoming PCI compliant. They have further said that, when in doubt, you should consult with your acquiring bank.
It is the card brands that mandate working only with PCI compliance of service providers a requirement in their Merchant Agreements and other legal documentation.
Thanks for the second reply. Well if even you can’t find an authoritative PCI SSC document on this topic that I can use to manage service provider behaviours, then it probably doesn’t exist. Yes we are in the process of contacting our acquiring bank about this matter, however, their usual response to PCI questions is “you should seek advice from a PCI QSA” … which is what we’ve already done.
Hi PCI Guru. My company is not a service provider. We are a purchaser only. We do, however, store and transmit credit card information – company credit card numbers. The entire credit card number, CVV, and expiration date. Are we also in scope for PCI?
Good possibility, but I would really have to know more. That said, regardless of PCI, you need to properly secure the cardholder data you store.
This is slightly off topic, but related to using a third party that is non-compliant: We are SAQ-D compliant – and work hard to keep up with the requirements. Recently we decided to look into making use of the services of a keyholding company to respond to our intruder alarm being triggered. While the keyholding would not have anything to do with our cardholder data (which, incidentally we don’t store, but do process), they would have access to the office that houses the CDE. According to the company we use for certification, we will need to put a policy in place defining what the keyholding company may and may not do, and then have a signed agreement with them to this effect. Do you know where I can find an example of such an agreement?
I would concur with your QSA that you need an agreement with the company that would have the key. But I do not have any such legal agreement as an example to share.
Hi PCIGuru,
We are SaaS providers of eCommerce platform and handle payments for each of our customers using their merchant ID and their CC processor (different setup for each customer). We use Spreedly hosted iFrame.
We are definitely Service Providers level 2, based on volume, so we need SAQ-D for Service Providers, but we should be exempt from most of the requirements, including the expensive app penetration testing (11.3)
What requirements are we exempt from as we don’t hold, process or transmit any CHD?
Every QSA gives me a different answer…
Thanks!
Hard to say without going through a scoping exercise and defining exactly those requirements you need to assess which is why you are getting different answers from the QSAs you are speaking.
Hi there! I work ifor a managed services provider and we are having an internal debate. We have two different cloud offerings. In one cloud offering our clients can spin up their own VMs through a web interface and make minor changes to the load balancer and firewell . That cloud has been certified as PCI Level 1 Compliant by an outside QSA and we have an AOC.
Our other cloud is the “compliant” offering where clients can not launch their own VMs and can’t make any changes to the load balancer or network. Everything needs to be done by our engineers.
We have a prospect who is currently PCI Level 1 Certified but does not actually store any credit card data for more than 1 second in memory before the info gets shipped off to 3rd party payment gateways. They got the cert more for marketing than anything else.
I think that they can achieve PCI Level 1 Certification in either environment as long as we spell out the roles and reponsiblities but my management is arguing that they need to be on the one where they don’t have access to do anything themselves. The prospect wants the flexibility of the first cloud offering but also would like to still pass their QSA audits obviously.
Any thoughts?
You are correct as long as the second offering also has a service provider assessment and AOC.
Regardless of the scenario, the QSA will take your AOC for whatever service environment and use the section 2g matrix to match up responsibilities for you and your customer and then conduct their assessment of your customer accordingly.
“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.”
Could you reference the specific PCI FAQs that I can review? Best I can do is FAQ 1220 that points that only documentation from the PCI DSS website is the only valid… “Any other form of certificate or documentation issued for the purposes of illustrating compliance to PCI DSS or any other PCI standard are not authorized or validated, and their use is not acceptable for evidencing compliance. ”
I have a client who’s service provider just wants to point to the Visa Service Provider List.
That is the only proof I am aware of as well.
My rental car company uses TSD rental to process credit cards. We use dial-up for our terminals.
Because we use our computers to access TSD online, and process payments, does this mean we are required to have a network firewall even though our terminals are in a separate line?
Dial up does not need a firewall, so only your PCs need to be firewalled.
But in that case, am i required to meet all PCI DSS requirements for the log management ? I had a brief chat with a third part security consultant, and they recommended to used a online log collection system, however when i had a brief chat with a QSA, she mentioned that i just need to enable logging, and not required to be collected and retained and monitored.
I am quite confused in that perspective !!
If you are going to collect log data, then you are required to centrally collect it, analyze it (i.e., define rules looking for exploits or compromises), generate alerts from those analyses, and finally follow up on those alerts to determine if you have a problem/issue.
Additionally, when you say firewalled, can I used the host-based firewall on a PC of the staff entering CHD to the payment gateway? Do I need to have a dedicated firewall for that?
Yes, a host-based firewall is allowed. That said, it needs to have rules other than the defaults provided by the vendor and automatically configured by OS. That is, you need to actually review it and tweak the configuration if necessary.
“If you are going to collect log data, then you are required to centrally collect it, analyze it (i.e., define rules looking for exploits or compromises), generate alerts from those analyses, and finally follow up on those alerts to determine if you have a problem/issue.”
– Is that PCI DSS requirement to collect logs from all these workstations? It looks like a cumbersome task to collect only OS and AV logs and monitor them, just because the contact centre staff collect the card number over telephony systems and enter that directly to the payment gateway !!
Is this a practical solution, to implement an exhaustive log management solution for this purpose?
Based on my understanding they key that information through a keyboard into the PC. So the risk is that the PC gets compromised by a keyboard logger or a memory scraper. You need to monitor for those sorts of events and then take any PCs out of service if they are suspected of being compromised. That is what the log data is going to help you achieve.
Yeah, that makes sense. Thank you.
I just finished the most infuriating conversation with a QSA. We’re a software company that is providing hosted environments (dedicated or multi-tenant apps) for our customers in AWS who accept credit card payments. We have a software component that facilitates a redirect in a new browser window at the client-side to a payment processor. Since we host multiple customers and forward to different processors, we store our customers’ merchant IDs in our hosting environment. The question I’m asking is: doesn’t this setup make us a Service Provider according to the PCI SSC? The QSA is attempting to say that it’s still “fuzzy” regarding whether we need to be compliant, but I’ve also discovered that he’s never actually worked with a service provider before. Not that I WANT to deal with PCI DSS, but I also don’t want to get this wrong.
Yes, you are a service provider. See SAQ A for what requirements are relevant to your organization. But you will have to fill out a service provider SAQ D and related service provider AOC.
I need a few clarifications.
As a service provider we are managing our Level-1 client’s systems and network in their environment. Client has informed us that they will be facing an onsite PCI audit and we as a service provider will also have to be a part of it and prove our compliance. So when the client has to face PCI audit now:
1. Will all the controls be divided between the client and us – as to who will take care of which controls?
2. But I guess there could be controls where both sides needs to show compliance as well?
3. When it comes to us showing policies and documents – do we need to show the policies that our company has in place or do we need to show our client’s policies and documentations (since we are managing the client’s environment)?
4. If it’s the latter then is my understanding correct that – all the evidences of policies and documentations can be shown by the clients itself in the first place and we as a service provider only need to show that we are managing the systems and network in compliance with those policies?
Thanks,
Ashwin
This is why service providers conduct their own PCI assessment for their services so that they can avoid being audited by every one of your customers’ QSA when your customers get assessed.
Yes, you will need to explain to the QSA the responsibilities for all of the PCI requirements that are relevant to the services you provide. Based on the limited information, you are likely going to have to cover all or part of requirements 1, 2, 3, 4 (maybe), 5, 6.1, 6.2, 7, 8, 9 (physical security), 10, 11, and 12.
You will cover YOUR organization’s policies, standards and procedures. Your customer’s policies, standards and procedures are their problem.
Be prepared to provide examples of configurations of your own systems that are used in the management process as those are connected to your customers’ environments.
1. Is there any way that we can exclude our own systems from the scope?
2. We are the System/Network Admins and Developers for the client. In all PCI audits does the System and Network Admins / Application Developers’ own systems and network segments always remain part of the scope since they have admin rights and connectivity to some system that they maybe managing from their own systems?
3. Hope the scope remains limited to just the specific user’s own system and not all the systems in his/her vlan since other users maybe part of different projects and not have access to the client machines?
4. What about our own In-house IT Team? The Desktop Team have Admin rights on all the workstations, Server Team have Admin rights on all the Servers, Network Team have admin rights on all the Network devices for our Co. irrespective of which customer/project we maybe working for. Does that mean that they will always be included in the scope of all the audits (PCI and others) that our different customers faces?
Thanks,
Ashwin
Sorry, but you are part of your client’s PCI assessment.
Scope will depend on how your network is segmented. My guess is that you will soon be implementing a VLAN and “jump box” between your clients and your network to reduce your scope.
We are an agency that needs o prove PCI Compliance to work with a client. I believe we need to complete SAQ A-EP but I am totally confused on where the SAQ goes and what the following process is to gain compliance. Is there a certificate?
No there is no certificate and if a QSAC tells you that you get one, run away quickly. The SAQ comes with an Attestation Of Compliance (AOC) built into the SAQ as well as a stand-alone version. The AOC is your attestation that you are PCI compliant. As a service provider, you would provide the stand-alone version to any customers that require it. Your full SAQ though goes to your acquiring bank, if you are processing card transactions on behalf of your customers. If you are not processing card transactions, then you would keep it on file should you need it.
Thank you, so as I understand it the process is:
– Identify the SAQ we should complete
– Complete the SAQ
– Submit to the bank (should this be our bank or the client’s?)
Do the bank normally take a cost?
If you are a merchant, you submit your SAQ to your bank. If you provide services to other merchants, then you would prepare an Attestation Of Compliance (AOC) and give your customers your AOC.
As to your question about paying banks, that depends. Banks in North America and Europe typically do not charge when you file unless you have penalties to pay because you never filed. In other parts of the world, I have heard of financial institutions charging a fee for filing to maintain their PCI compliance program.
Would an independent contractor that has logical / physical access to manage in-scope CDE components be required to complete an AoC or would the MSA & Confidentiality Agreement suffice. By definition they are a service provider and could impact the security of the CDE.
I would say that the MSA and confidentiality agreements would cover you legally and I would not require an AOC from them. From a PCI standpoint though, you want to make sure that if they are doing any sort of remote work, they are using multi-factor authentication to access your network and that their PC is appropriately secured and hardened.
Hi Guru,
Quick question on how you are dealing with Service Providers who deal with MasterCard transactions, (essentially the vast majority). The Mastercard definition of service provider levels is now different then VISA.
https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/service-providers-need-to-know.html
Based on their classification it appears they are treating all service providers with the exception of DSE’s as a level 1 service provider and therefore require a QSA assessment.
How are you dealing/enforcing this currently? This is something I’ve been struggling with internally as essential almost all service providers require a ROC under that definition.
Thanks as always for the great articles!
I do not see any change in their stance. They are still calling out 300K or more transactions for a Level 1 Service Provider and less than 300K transactions for a Level 2 service provider just like Visa. MasterCard is explicitly tossing in the Data Storage Entity (DSE) reference (i.e., third parties that process, store or transmit SAD/CHD). It is that DSE reference that is probably getting you twisted but that has always been implied in the definition of service providers by MasterCard and Visa. But at the end of the day, if you are third party managing a merchant’s network with potential access to the datastream and not conducting transactions, then you fall into the Level 2 service provider designation for MasterCard just as with Visa. Otherwise, you will know transaction counts for all of your merchants and then you can figure out where you fall in the Levels.
As usual with the Guru, this is well written and very informative. My only complaint is that it has a clear merchant bias. As a service provider, we deal with many customers asking us to manage devices (servers, switches, routers, firewalls, applications, etc.) without any security/compliance requirements listed in the contract. And then one out of nowhere comes the PCI compliance request for a service that was never sold as compliant and for which no PCI compliance requirements were ever listed in the contracts. My problem with that is wanting PCI compliance for free instead of formalizing it in the contract, as per Req 12.8/12.9, so that it can be costed, properly implemented and then assessed annually using an agreed reporting mechanism.
As a service provider to merchants, we have no legal connection with acquiring banks or brands so these requirements are not magically trickling down to us unless they’re part of contracts.
As a former service provider myself, I put this squarely on your sales people in your organization. They should be instructed to be explicitly asking your existing and prospective customers if they require any special regulatory compliance. Besides PCI, there are requirements in the US such as GLBA, HIPAA, FISMA and the like that all have implications to your organization as a service provider. It is your organization’s responsibility to dig that information out. That way you can make a decision as to whether or not you want to take on a customer.
BTW I find it hard to believe that your lawyers did not include clauses in your contracts regarding regulatory compliance. Any lawyer worth their salt has that sort of language as SOP in every service provider contract I have ever encountered. So you might want to go back and review all of that boiler plate because I am betting that you are on the hook and just do not realize it.
I agree that pre-sales/sales have to be educated about security requirements. Sadly, they’re too often influenced in believing that a SSAE16 (or equivalent) is the answer to everything.
And just to clarify, most of our contracts include references to regulatory compliance which would include GLBA, HIPAA and others (if we were in the US) but these references are about complying with laws and regulations originating from governments, not from the PCI SSC. So, we’re left with contracts with merchants, issuers, acquirers, etc. that have virtually no references to PCI DSS requirements which is a PCI DSS fail right there.
So as I said before, as a service provider to merchants, we have no legal connection with acquiring banks or brands so it’s incorrect to simply assume that these requirements are magically trickling down to us unless they’re part of contracts (which they’re not in most cases).
You may not have direct contracts, but the merchants and service providers you provide services to do have legal contracts that bind them and indirectly you because of how the merchants and service providers are required to manage their third party relationships due to the PCI DSS. I grant you it is an ugly legal mess, but I have seen lawyers do more with much less.
I’m confused regarding the part about service providers with non-compliant issues.
If a merchant has a service provider with non-compliant requirements but which has a remediation program in progress, would you list these requirements as Compliant in the merchant’s RoC?
The Council has repeatedly stated that one organization’s non-compliance does not effect another organization’s compliance.
That said, in your example, the merchant would mark the requirement as ‘Not Applicable’ with the reason being that the third party is responsible for satisfying that requirement. If the merchant is partially responsible for a requirement, you would document those responsibilities and how they complied and then state the rest are the responsibility of the third party.
Mr. Guru, is there anything written about this? (i.e. PCI-DSS FAQ, assessor news).
“The Council has repeatedly stated that one organization’s non-compliance does not effect another organization’s compliance.”
A client of mine will probably find itself in such a situation in the near future and I would like to prep in case.
thank you.
Apparently, the Council has changed their mind about this subject in their FAQ – https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/If-an-entity-uses-a-service-provider-that-is-not-PCI-DSS-compliant-how-does-this-impact-the-entity-s-compliance?q=third+party+compliance&l=en_US&fs=Search&. So I will have to update my understanding based on this new information. That said, this has not been their position prior to this.
Quick question. We already go through PCI compliance validation today as a merchant. However, we have a Cafe onsite (third party) that utilizes our wireless infrastructure (segmented of course), and soon we will begin renting space to tenants. At least one tenant will piggy back on our physical infrastructure and the rest are air gaped (long story). This single tenant will have a call center taking cards. The tenant network is segmented like the cafe above.
What position does that put us in? Are we a service provider because we provide segmented network connectivity and control that equipment? What level?
Thanks so much for your input!
You would be a Level 2 service provider in my book as you have no idea how many transactions flow over your infrastructure. That said, you really need to make sure that you have logical and/or physical segmentation in place for your third parties to access. I would be particularly concerned about your Wi-Fi that is used by your Cafe as that definitely puts you as a service provider and puts any other Wi-Fi users as potential attackers of the Cafe systems.
Hi PCIGuru,
I have a case question. In this article, you mention “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.” In this case, Company A is contracted to be a call center for Company B. Company A’s process is that they take the calls, input the credit card number in Company B’s website/payment site, and click submit which then goes through Company B’s website. Since Company A is handling calls with credit card information, does that count as process or transmitting transactions? In this case would Company A transactions volume be zero?
I guess a better question would be what is considered a transaction?
Thanks for your help!
Service providers that process transactions under a customer’s merchant identifier are not processing transactions for themselves, hence the service provider designation. If they were doing transactions under their own merchant ID, then those would be merchant transactions. The problem comes from the fact that the transaction processor cannot distinguish the transactions processed by the call center (not all calls necessarily result in a charge), versus customers using the Web site, versus the own organization that also runs transactions through the Web site. As a result, they had to come up with some rule and what we have is the rule we have which is that the call center transactions do not count against the call center.
Hi PCIguru,
I have a very similar situation as Company A is contracted to be a call center for Company B. Company A agents log into Company B website to process and submit payments. The CHD data footprint for Company A is fairly small, but yet call recordings are stored. Company A has been notified by Company B’s that they fall under the Third Party Service Provider and to submit a SAQ and the quarterly ASV scans. Given Company A has started the process they do not have any external facing websites nor any IP address that would be in-scope for the SAQ. Will Company A have to provide a ‘blank’ ASV scan? As mentioned above, it appears our company transactions volume would be zero.
Assuming that the Web site is using TLS 1.2 for securing connections, then the only devices in scope for PCI compliance for Company A are the workstations used to enter the data. That is because the connection between the workstation and the Web site is encrypted which then removes anything in between those devices from scope.
As to how Company A reports this is to answer as ‘Not Applicable’ for the external ASV scanning and penetration testing requirements with the reason being that there are no PCI in scope externally facing assets. They would also reflect that in their AOC as well in discussing requirement 11.
Hi PCI Guru
I agree with your stance that that only the workstations should be in scope but this is very similar to an SAQ C-VT scenario where the PCI SSC is clearly extending the scope beyond the workstations (e.g. requirements about firewalls/routers). If it’s acceptable to limit the scope to the workstations when would you have to use the full SAQ C-VT?
The reason C-VT is much more than just the workstation is that you MUST prove that the network is secure to protect the workstation from threats off the internal network because it is on a network with other systems that could be compromised and then used to compromise the workstation.
Quick one for you, on a related note: The shared responsibility statement of 12.8.5
If a payment processor is receiving card data from a merchant, meaning the merchant processed the card data and sent it to the payment processor, can we say there are no shared responsibilities ?
Because I don’t see any requirement in PCI DSS specific about sending card data to payment brands, for example.
As a counter-example, a merchant using redirect hosted payment page would have such shared responsibilities because the merchant is paying the eCommerce gateway to handle the card data for them. Presuming they only receive truncated data in return, then they do not handle CD, nor implement protection measures nor manage encryption keys, nor handle the CVV or all the others in 3.
So Req’s 3 would be services provided by the gateway to the merchant.
But a merchant sending card data to the processor, what kind of agreement do you get ? A statement that ALL requirements are shared ?
Thx,
The card brand merchant agreements are what control the merchant’s responsibilities to the card brands. Then there are processor and possibly gateway contracts that are in place regarding transaction processing/handling. The brands and acquiring banks (as long as they do not provide other services to the merchant) are not considered service providers (see PCI SSC FAQ 1284), so they are not covered by 12.8 and 12.9.
In your redirect example, the merchant is only responsible for the requirements listed in SAQ A and the gateway is responsible for the rest. There would be some shared responsibilities surrounding requirement 8 (user access management) but nothing else.
From my experience with outsourcers, you really need to go through their service offerings and determine where there are shared responsibilities because every service provider is slightly different from another. It is very difficult to make generalities regarding shared responsibilities from one service provider to another.
I am a level 2 service provider; host a site for several merchants using iframes solution with no CHD in my environment. I know I need to do SAQ-D, but many of the controls are NA since I do not process, store or transmit. Two questions: (1) How do I define a CDE if there isn’t any CDH? What do I scan? Pen Test? Etc. CHD is only on the client’s device and gateway… (2) AOC says all responses must be “in the affirmative” to be compliant…does that mean that an “NA” response means I am not compliant? Any help is appreciated.
First the easy question, not applicable (NA) responses are considered “compliant” responses.
Your organization does not have a cardholder data environment (CDE), so there is nothing externally facing to ASV vulnerability scan or penetration test. That said, how do you know with absolute certainty that your clients are only using iFrame solutions for payment processing? Most of my hosting providers have no clue as to what their clients are doing for payment processing. I’m not trying to create an argument, just confirming that you truly know.
I did a poor job of describing the system. A group of businesses hired us to build and maintain a website for them. Their customers come to our site to purchase services. When customer hits “Pay Now”, we push a .js to the customer’s browser (ie, “client”). They enter card info, and the CHD is sent directly to the Gateway provider; we get token back from Gateway, and proceed with transaction using token. Each business has its own Merchant ID, and we are not a party to the transaction. We do not store, process or transmit. BUT, we can impact the security of cardholder data because we control the .js. For example, someone could hack us and reconfigure the code to route cardholder data to Bad Guy. I think SAQ-D is applicable, but how does DSS define CDE/boundary for Pentest, Vuln scans and virtually all of the SAQ line items?
Appreciate any insights. Thank you.
Javascript is not a redirect or an iFrame. Only the use of a redirect or iFrame are out of scope. Everything else, including Javascript, place your server in scope for PCI compliance. You need to read the Council’s Information Supplement on eCommerce (https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_eCommerce_Guidelines.pdf) which is based on a document issued by Visa Europe on the same subject.
Good stuff as always. Only suggestion is the addition of links to the Service Provider Levels for Visa, MC & Discover.
Click to access data-security-compliane-service-providers.pdf
https://www.mastercard.us/en-us/merchants/safety-security/security-recommendations/service-providers-need-to-know.html
https://www.discovernetwork.com/merchants/data-security/service-provider.html
I used to have links to a lot of information provided by the brands, but they changed them so often that I got tired of updating their links. So I only provide the links to their general programs on my brands links page. Thanks for providing them here, but I will guarantee you in 6 months they will no longer work. LOL!
About your approach: 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.
I disagree. To my humble opinion, if a merchant is a Level 1, all its service providers should be audited as well (like any Level 1 SP) regarding on the number of transactions they make.
This is because the auditor of a Level 1 merchant cannot simply take the word of SAQs filled in by SPs. Evidences must be collected from the SPs or they need to be Level 1 certified.
Nice idea. But if you want that approach, then it will be up to you to ensure that all of your service providers are also doing a Level SP assessment.
Do not agree that a Service Provider must process or transmit CHD/SAD to be considered a PSP.
“This also includes companies that provide services that control or could impact the security of cardholder data.”
Thus, even for Service Providers that do not process or transmit any CHD, if they control the systems hosting the payment pages and can indirectly impact the payment flow, they are in scope in my opinion. Example, a Service Provider that only hosts, operates and/or manages a site in which there is an iframe/Re-direct to another PCI Compliant Service Provider is still a PSP.
With that having been said, even though they would be subject to SAQ D – Service Provider or a ROC, their requirements would be limited to those found in SAQ A in my opinion, same as for a merchant having outsourced the entirety of the page according to FAQs 1291 and 1292.
By definition a PSP is payment service provider. Operative word being, “payment”. They do nothing but deal with payments/transactions. So how you think a PSP does not deal with SAD/CHD is beyond me.
See this for the definition. https://en.wikipedia.org/wiki/Payment_service_provider
My bad on PSP. In my parts… we use the acronym PSP as meaning PCI Service Provider… I understand the confusion it caused you…
Looks like you didn’t read the rest of what I wrote though… my point being, even if a Service Provider processes, transmits or stores zero CHD/SAD, if they could impact the payment flow, they are still subject to PCI according to the definition in the glossary… Having re-read your text, I believe you are saying that anyways. Where you lost me is on the service provider transaction levels saying that since such a Service Provider processes 0 transactions, they forever remain a level 2. My view is different in that it is the number of transactions that their merchant clients’ process that must be taken into account instead. As such, a Service Provider that does not process, transmit or store CHD/SAD but can still impact the payment flows of hundreds of clients or other Service Providers who themselves process billions of transactions must still be viewed as a level 1… This as compared to a small Service Provider that has one client that process under 300k transactions… The risk isn’t the same… Hope this is clearer…
Absolutely. If any service provider could compromise the flow of SAD/CHD, then they need to go through a PCI assessment to ensure that thsoe services are compliant. But we need to be careful here because this could quickly get out of hand. As a prime example, the HVAC vendor that is supposed to have been the start of the Target breach. That vendor, while a service provider for Target, had no contact with anything that could have compromised Target’s processing of SAD/CHD. Therefore, there is no reason for them to be required to be PCI compliant and provide a service provider AOC to Target. However, the service provider that is managing a retailer’s firewalls at every location, those firewalls encrypt the network connections to HQ and are relied upon to protect SAD/CHD. That service provider needs to be PCI complaint because their organization has access to unprotected SAD/CHD.
That said, the card brands will tell you that the service provider managing the firewalls can always remain at Level 2 because they never actually process, store or transmit SAD/CHD. The reason is that those service providers lobbied the Council and the Brands for that designation. That said, most go through the full on ROC process because they want to be listed on the Brands’ registry Web sites.
I see, thank you for the clarification. Did not know that. This is why I visit your site!!
What is your comment on a service provider compliance description page like WPEngine: https://wpengine.com/support/wp-engine-and-pci-compliance/
It totally looks like they are saying that if a customer hosts with a redirect, then they are compliant. Is this legit as if they are a service provider, shouldn’t they have to be more compliant?
They can believe they have no skin in the game all they want, but they are part of the process. They have no idea if their customers are following their “recommendations” or not. A lot of their recommended solutions for payment processing use not only iFrames and redirects, but also Java, JavaScript, HTML forms and other solutions that would drag their hosting into PCI scope. These people are living in denial.
Even if you took them at their recommendations, they still have their virtual environment that needs to be assessed as well as requirements 9 and 12.
It looks to me like WPEngine is providing a self-serving statement here
I tell you not to do this, and if you do, well then you heard me saying not to!
And that is not acceptable from a PCI compliance perspective because the service provider cannot rely on such statements. Obviously not a vendor any merchant should deal with.