Answers to Common Questions About the Applicability of the PCI DSS to Service Providers
Blog Article Published: 06/22/2022
This blog was originally published by Weaver here.
How does the Payment Card Industry (PCI) Data Security Standard (DSS) apply to service providers? Service providers are entities that are directly involved in the storing, processing, or transmitting of cardholder data on behalf of another entity. They also include other organizations, such as colocation and cloud service providers that may control or could impact the security of cardholder data.
The answer is not always clear, and this creates a lot of confusion in the payment card security space.
Most published guidance relates to merchants: entities that accept card payments for goods or services. But the scope of the standards extends beyond merchants to service providers, who find themselves stuck between contractual or customer requirements and those issued by the PCI Security Standards Council (SSC) or even the card brands (i.e. Visa, MasterCard, American Express, Discover, JCB) themselves.
We get many questions about the DSS and service provider compliance. Here are answers to some of the most common issues:
Our platform has nothing to do with accepting credit card payments and we do not touch cardholder data. Why would the PCI DSS apply to us?
The DSS applies to the people, processes, and technology that store, process, or transmit cardholder data and sensitive authentication data; or could affect the security of that data. As a service provider you may not have control over the data that your customers transmit through your platform, but your customers may be utilizing your platform to support their payment processes, data analytics, or even service a web page for selling goods. All of these may potentially result in shared responsibility of PCI DSS requirements between you and your customers. Your customers may require your platform to be PCI DSS compliant for the areas that you manage within that shared responsibility model so that you do not preclude them from achieving PCI DSS compliance for their environment.
As a service provider should we perform a Self-Assessment Questionnaire-D (SAQ-D) or Report on Compliance (ROC)?
PCI DSS compliance requirements for service providers typically come from a contractual obligation, customer expectation based on your industry, a requirement for membership in a card brand program, or as a marketing push in the form of compliance as a competitive advantage. In the case of membership in a card brand program for example, service providers that process more than 300,000 transactions per year may be required to complete a ROC assessment annually.
There are varying compliance costs between a SAQ-D and ROC based on the level of testing required by an independent Qualified Security Assessor (QSA) company like Weaver. A SAQ-D can be completed independently by your organization or through using a QSA company to facilitate the process through testing and inquiry. A ROC is a full PCI DSS assessment that is completed by a QSA company. The cost of a ROC is higher due to additional testing and reporting requirements for the QSA company.
To determine whether a ROC or SAQ-D is appropriate, you first need to understand the source of the request. If it is coming from a customer or vendor you do business with, there may be flexibility on whether a SAQ-D is appropriate. If dictated by a card brand membership agreement, your organization may have to complete a ROC. There is no hard and fast rule for service providers because it depends on where the request is coming from and whether the requestor agrees with your approach.
I am a service provider that also accepts card payments from my customers, am I considered a merchant or a service provider?
Both! Service providers who accept card payments for their services also would be considered merchants by their acquirer (merchant bank). Compliance requirements set forth for merchants are clear (generally) and can be found on individual card brand websites. The requirements between a SAQ or ROC are determined by transaction volume. You should work with your acquirer to understand your specific PCI DSS compliance requirements as mileage may vary between merchants.
For service providers, this typically means you are completing one PCI DSS assessment for your service and another as a merchant. Network segmentation between your merchant environment and your service environment can help lower the overall compliance burden and any bleed over from acquirer requirements.
About the Author
Kyle is a leader at Weaver for cybersecurity assessments and has a focus on the Payment Card Industry (PCI) Data Security Standard (DSS). He has over nine years of experience in applying complex technical standards and continuous monitoring activities to global cloud offerings. His experience with global cloud offerings has given him a unique ability to translate regulatory and compliance requirements to the continually evolving technology landscape. He also has a wide range of varying industry experience in performing assessments related to System and Organization Controls (SOC), Cloud Security Alliance Security Trust Assurance and Risk (CSA STAR), National Institute of Standards and Technology Cybersecurity Framework (NIST-CSF), Center for Internet Security (CIS) Controls, Electronic Prescriptions for Controlled Substances (EPCS), BSIG Kritis, Sarbanes-Oxley (SOX), and internal audit.
Kyle is a Qualified Security Assessor (QSA), Certified Information Systems Security Professional (CISSP), Certified Cloud Security Professional (CCSP), Certified Information Systems Auditor (CISA), Certified Internal Auditor (CIA) and holds a Certificate of Cloud Security Knowledge (CCSK). Kyle serves with the North Texas ISACA Chapter board and is a member of the Institute of Internal Auditors (IIA). He earned a Master of Science and Bachelor of Science in accounting from the University of Texas at Dallas.
Trending This Week
#1 What are the Most Common Cloud Computing Service Delivery Models?
#2 Zero Trust and AI: Better Together
#3 Top Threat #2 to Cloud Computing: Insecure Interfaces and APIs
#4 101 Guide on Cloud Security Architecture for Enterprises
#5 Demystifying Secure Architecture Review of Generative AI-Based Products and Services
Sign up to receive CSA's latest blogs
This list receives 1-2 emails a month.