The PCI Security Standards Council 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 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.”
As you know, you are responsible for managing all third-party service providers according to PCI DSS Requirement 12.8, including the verification of their compliance status annually.
But what if you find yourself in the service provider role? Within higher education, we often find that the main university campus is providing services, including support staff, networks, computer equipment, and/or point-of-sale devices or terminals for other related organizations on campus, like Athletics or Foundation. Similarly, with hospitality or healthcare entities, there can be one part of the organization that is providing PCI-related services to other affiliates. If these organizations are legally separate entities and have a separate relationship with their acquiring bank with their own Merchant IDs, then the entity providing the payment support services is likely acting as a PCI service provider.
By providing services to these entities, unfortunately, you may be considered a service provider as you are effecting the security of the separate entity’s cardholder data environment. This means that you have now landed yourself with the longest list of requirements, the SAQ D for Service Providers, and you must deliver the completed Attestation of Compliance (AOC) for that SAQ to these entities annually. Just as you collect the AOCs from your service providers each year, you must now validate that you are providing compliant services to your “customer”. The SAQ D for Service Providers includes an additional 21 requirements over and above the SAQ D for Merchants. These requirements include entries covering system configuration, additional documentation, authentication, security control failure management, staff responsibilities, logging, and more.
The PCI Team has been focused on reducing the time and effort required to maintain your PCI compliance so being a PCI service provider is not in line with this goal. Consider working with the affiliate(s) to identify ways that they can support their own PCI program. Options include requiring them to provide their own network, convincing them to move towards a validated P2PE solution (thereby eliminating cardholder data from the environment), or providing their own equipment/maintenance, etc. By moving away from the service provider role, you can greatly reduce the level of effort your organization will have to commit to in order to achieve and attest your overall compliance.
For help discerning whether or not you have a potential role as a service provider, don’t hesitate to reach out to us.
Some additional guidance from our Security Advisor team below:
[Burt]: The Service Provider role is one of those topics like “VOIP being in scope for PCI DSS” that often gets bypassed at Higher Education institutions. The most common areas that can typically give Universities and Colleges reason for “Service Provider role” concern are Alumni/Development/Foundation and Dining. If these areas are separate entities ((e.g. 501 (c) (3)’s)), then common services to look for would be whether the school is providing/managing computer or networking systems. Unfortunately, providing such services can lead an institution down that road of complex PCI DSS requirements being a necessity after performing work at the merchant level to eliminate scope. As always, feel free to talk with your CampusGuard Security Advisor about any questions regarding this piece of PCI Compliance.
