One of the common misunderstandings we’ve noticed among merchants is in relation to the proper definition of a PCI Service Provider.  Most companies understand that if they share cardholder data with a third party, that entity is a Service Provider and needs to be covered for DSS requirements 12.8.x.  But there’s another class of Service Providers that often gets overlooked…

The PCI SSC defines PCI Service Providers as:

“Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching of transaction data and cardholder information or both. This also includes companies that provide services to merchants, services providers or members 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. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”

There are several types of managed services organizations that would qualify as a PCI Service Provider.  If your company uses a third party for services that could impact the security of cardholder data, that third party is a PCI Service Provider – even if they don’t have any direct access to cardholder data.

As an example, consider a managed firewall service provider…  A company hired to manage your firewalls may not have any access to cardholder data, but if a mistake is made while changing rules on the firewall, they could inadvertantly expose systems handling cardholder data to the Internet.

Another example is a vendor providing remote support for in-scope systems.  If a third party has administrative level access to in-scope systems in the cardholder data environment, that vendor should also be seen as a PCI Service Provider, for the same reason as above.  They may not be able to directly access cardholder data, but an incorrect change on a server could enable that host to be compromised by someone else and used as a means to gain subsequent access to cardholder data.
As a PCI Service Provider, these third parties would need to maintain full PCI Compliance at all times and provide a signed Attestation of Compliance (AoC) on an annual basis.  There must also be specific language in the contract between the two organizations that makes it clear that the third-party is taking responsibility for protecting the systems handling cardholder data according to the DSS requirements.

Sometimes vendors such as those described here do not understand why they are being classified as a PCI Service Provider and will try to claim they have no such obligations.  In this case, there are a few possibilities to explore:

  1. Try to educate the vendor about why they meet the definition of a PCI Service Provider.  Keep in mind that the scope of their PCI compliance only needs to cover the relevant services being provided, along with any supporting systems, so it may end up being a small part of their overall environment that needs to be PCI compliant.
  2. Consider adjusting the support process so the vendor only provides support via tools like GotoMeeting or WebEx, such that a company employee must manually authorize their connection each time and can monitor everything the third party does on a system in real-time.  In this way, the merchant can maintain full responsibility for the proper security of their in-scope systems and would then not need to list the third party as a PCI Service Provider.
  3. If all else fails, it’s time to start exploring alternative vendors.  If your current vendor refuses to acknowledge responsibility for helping to keep your cardholder data environment safe, it may be an indication that information security and compliance isn’t a significant focus for them.

Jeremy Simon, PCI QSA, CISSP, CISA
Practice Lead, PCI Compliance Services