In the early days of PCI DSS, I recall having many conversations with vendors of payment applications and card-related services in which we spent hours persuading and educating providers about their new obligations.  This was before the Payment Application Data Security Standard (PA DSS), which gave us something more concrete to point to in these situations.

Thankfully, these conversations now are a rarity.  However, as the banks extend their compliance focus to level three and four merchants, who may rely on locally grown applications and services, situations still may arise where a vendor does not know about PCI or PA DSS.  Or the vendor simply may not consider their service subject to the standards.

For that matter, you may wonder if you are a service provider yourself!  Many organizations make use of multiple merchant accounts for a variety of legitimate business reasons.  In such circumstances, organizations may wrestle with this question.*

So, how does service provider compliance relate to merchant compliance?  And how is service provider status determined?

Impact on Merchant Compliance

Section 12.8 of the PCI DSS requires merchants sharing cardholder data with service providers to “maintain policies and procedures to formally identify service provider responsibilities for securing cardholder data” and to conduct annual monitoring of the provider’s compliance status.

You may wonder why merchants are charged with policing service providers.  The answer is that the card brands have no direct authority over these players.  As we’ve noted before, the mechanism for propagating the security improvements desired by the payment card industry is through a sort of chain reaction: the card brands require their member banks to enforce PCI with their merchants, whose own compliance is dependent upon their insistence on service provider compliance.

This strategy has been very effective at moving providers toward compliance or out of the business.  In one case, I recall a vendor who became persuaded that their service was in fact in scope.  For this vendor, the hosting service they provided relating to cardholder data was not a significant part of their business.  They quite reasonably chose to stop providing the service rather than undergo the compliance effort.

Service Provider Defined

The PCI DSS Glossary version 2.0 defines a service provider as a “business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. 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. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.”

Naturally, the SSC has made this category incredibly broad.  The key here is in the actual requirement, which refers to a specific class of service providers:  those with whom credit card data is shared.  Others have restated this definition as “any third party that stores, processes, or transmits cardholder data on your behalf.”

This is also the key for those organizations owning multiple merchant accounts.  If the organization holding the accounts is one entity, it is not handling data on behalf of others.  Each of the merchants accounts must still be managed in a PCI compliant manner, but no external service is provided.

Leveraging Service Providers

While monitoring service providers is an additional burden for merchants, there also is the potential to reduce scope, risk, and compliance headaches.  This can be accomplished by migrating unsafe or internally managed processing to an affordable, compliant service provider (when one is available).

Usually, such a move requires business process revision, but this is another place where a burden can become an opportunity.  We have seen successful process improvement initiatives grow out of new service provider relationships.   In one case, a merchant was able to shorten one of their busiest times of the year by weeks while getting better reporting.  In this particular case, the costs of the new, PCI compliant service were more than offset because they were able to reduce their reliance on seasonal workers.

I’ve never heard a PCI compliance initiative described as fun, but they can be used to move an organization forward in domains other than risk management.

*You may also wonder about your merchant level in such situations.  This is determined in conjunction with your bank.  But to meet the intent, the bank should count the transactions in each payment channel to determine the level for the merchant accounts.  In other words, if your organization has three merchant accounts and two of them share the same payment system while the third uses a completely different payment system, compliance and validation requirements should be assessed for the two payment systems.  More detail will be provided in a future article.