Achieving compliance with the Payment Card Industry Data Security Standard (PCI DSS) is tedious and cumbersome, and in many cases will require a great deal of effort for businesses. There’s the initial effort and sometimes cost required to secure cardholder data (CHD). There are the tasks involved to secure, monitor and manage the cardholder data environment (CDE), such as defining policies and procedures to implement technology solutions.
The scope of PCI DSS also includes any third-party service providers (TPSPs) that have access to cardholder data or the cardholder data environment, store or process cardholder data on their customers’ behalf, or could impact the security of cardholder data.
What does it all mean? It means that you need to pay attention to TPSPs!
We cannot ignore TPSPs in today’s world. Almost all businesses outsource one or more services to TPSPs.
The PCI Security Standards Council and the payment card brands are rightfully concerned about the security of cardholder data. So the scope of the PCI DSS covers all the people, processes and technologies that either store, process or transmit cardholder data, and this includes third-party service providers.
If a TPSP stores, processes or transmits cardholder data for you, or could affect its security, that service comes under the PCI DSS scope of assessment. Some examples of services are call centres, hosting, cloud services, storage, payment gateways, media handling, encryption, infrastructure, physical security, HR functions, routing and firewalling, and monitoring.
Working with third-party service providers can be challenging and must be dealt with diligently.
It is obvious then that you should select service providers who are PCI DSS compliant for the services they are offering. They should agree to adhere to your contract requirements of meeting compliance to ensure cardholder data security.
Policies and procedures must be established between your business and your service providers for all applicable security requirements, and proper measures should be developed to manage, monitor and report on the requirements.
Due diligence in selecting service providers saves you from running into problems later and it reduces the cost and effort required to achieve PCI DSS compliance.
Figure 1: Due Diligence Process
Reference: Third-Party Security Assurance Special Interest Group, PCI Security Standards Council
According to PCI DSS requirement 12.8.5, it is important to know who is responsible for what: “Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.”
A PCI DSS responsibility summary will outline a clear idea of who is responsible for what. You can use this document as a starting point to identify participating service providers and then to identify their level of compliance against each service they are providing.
PCI DSS v4.0.1 also requires you to keep a list of your TPSPs, have written agreements with them, carry out due diligence before engaging them, and monitor their PCI DSS compliance status at least once every 12 months. For Australian organisations regulated by APRA, CPS 234 adds a similar expectation to assess the information security capability of third parties that manage information assets on their behalf.
In many cases, entities working towards PCI DSS compliance have already chosen their service providers, and due to contract obligations they are either not able to change from non-compliant service providers to PCI DSS-compliant ones, or they’re unable to push the TPSPs to complete their own PCI DSS assessment.
If you are working with non-compliant third-party service providers or you suspect they might not be compliant, we can help. It’s a process, which you probably wouldn’t want to handle on your own.
StickmanCyber will assess the services of the third-party service providers that are relevant to your business (and in the scope of PCI DSS).
If we find that they are not PCI DSS compliant, then we can look at remediating the shortcomings. If there are multiple non-compliant service providers involved, this might add time and costs to the project.
Once we have identified TPSPs that are non-compliant, we can help service providers achieve compliance. StickmanCyber has successfully dealt with this in a few PCI DSS projects.
Where we found third-party service providers – and their multilevel subcontractors – who were not compliant, we used our experience to speak with both the client and service providers about the situation.
Then, we simplified the whole procedure of compliance. We educated our client and their service providers on how to meet PCI DSS requirements and conditions by completing the PCI DSS Self-Assessment Questionnaire (SAQ). This is a tool which helps both merchants and service providers to figure out if they comply with the Payment Card Industry Data Security Standard.
This is a winning situation for everyone. You can validate your own PCI DSS compliance, as all your third-party service providers are properly compliant.
At StickmanCyber, we have successfully completed such a project.
The service providers are now in a much better situation. They may have been reluctant to choose PCI DSS compliance due to a lack of knowledge and education. Now, they’ve been educated and are compliant, and they can now confidently attract more customers, through being able to officially demonstrate their PCI DSS compliance capability for the services they are providing.
And you’ve created a better partnership with your suppliers in a situation where you’ve both gained a successful outcome.
Is your business looking to get PCI DSS compliant? StickmanCyber’s PCI DSS compliance service deploys a 5-step methodology to help you build trust with your customers and support secure transactions with PCI DSS compliance. Book a free consultation today.
No. PCI DSS v4.0.1 states that using a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own compliance. A compliant provider covers only the requirements it manages for the services you use. You still need to meet and validate the requirements that remain your responsibility.
Ask for the provider’s PCI DSS Attestation of Compliance (AOC) covering the services you use, together with a responsibility matrix showing which requirements it manages. If a provider hasn’t completed its own PCI DSS assessment, it can supply other evidence instead, such as allowing your assessor to review its services as part of your assessment.
Not on its own. The PCI Security Standards Council says that compliance certificates are not recognised for PCI DSS validation. Only its official documents, such as the Report on Compliance, the AOC and the Self-Assessment Questionnaire, are accepted. If a provider sends a certificate, ask for its AOC instead.
At least once every 12 months. Requirement 12.8.4 asks you to run a program that monitors each TPSP’s PCI DSS compliance status at least annually. You only need to monitor the services you actually receive that are in scope, and it’s good practice to recheck when a provider’s services or your use of them changes.
Under Requirement 12.8.2, the agreement should include the provider’s acknowledgement that it is responsible for the security of the account data it stores, processes or transmits for you, or could affect. An AOC, a statement on a provider’s website or a responsibility matrix doesn’t count as that written acknowledgement on its own.
A nested service provider is a provider that your provider relies on, such as a hosting company used by your payment gateway. PCI DSS v4.0.1 says the primary TPSP is responsible for managing and monitoring any secondary TPSPs it uses, so ask your providers how they oversee their own suppliers.