What’s new with third-party service provider management in PCI DSS version 4.0?
Using third-party service providers (TPSPs) to perform services related to credit card processing can be a great way to limit your PCI DSS scope and associated responsibilities. However, TPSPs can also introduce significant risk of data breaches. The Ponemon Institute reports that almost 60% of organizations have experienced a data breach caused by a third party.
Rather than allowing organizations to make assumptions regarding the PCI DSS compliance of TPSPs, the Payment Card Industry Data Security Standard (PCI DSS) has always included requirements for organizations to have an established TPSP oversight process, ensuring the appropriate due diligence is performed prior to onboarding a vendor, and annually thereafter.
Requirement 12.8 of PCI DSS V3.2.1 stipulates the following be included in an organization’s TPSP management program:
- A list of service providers including a description of the service provided
- Written agreements that include an acknowledgment that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment
- An established process for engaging service providers including proper due diligence prior to engagement
- Information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity
- A program to monitor service providers’ PCI DSS compliance status at least annually
To support these objectives, companion Requirement 12.9 of PCI DSS V3.2.1 mandates that TPSPs acknowledge in writing to customers that they are “responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.”
With PCI DSS version V4.0, TPSP support of an entity’s PCI DSS compliance goes even further. In addition to the above stipulations, PCI DSS v4.0 requires that a TPSP provide PCI DSS compliance status information for any service performed on behalf of customers, as well as which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities. This is very good news for organizations who outsource PCI-related services.
Currently under V3.2.1, the merchant organization is responsible for performing the analysis and documenting the responsibilities, with or without assistance from TPSPs. With these new requirements, a TPSP demonstrates its commitment not only to protecting cardholder data but also to helping its customers meet their security and compliance requirements with a PCI DSS responsibilities matrix.
Under v4.0 Requirement 11.4.7, TSPSs must also support customer penetration testing activities. Effective 3/31/2025, Requirement 11.4.7 stipulates that TPSPs must allow access to systems for testing, or to provide evidence that comparable testing has been performed. This will also be important to discuss with your service providers now as you structure agreements that span PCI DSS V4.0.
How Can I Determine Whether a TPSP is Compliant?
The PCI Security Standards Council (PCI SSC) has stated that the only documentation recognized for PCI DSS validation are the official documents from the PCI SSC, such as Attestations of Compliance (AOC) templates, which are available for download from the PCI Security Standards Council website. The use of certificates or other non-PCI SSC-approved documentation are not acceptable. When an organization or merchant reviews a new third-party vendor, they should always request a current AOC prior to the engagement and annually thereafter.
CampusGuard recommends including language in the contract that stipulates that this compliance documentation, along with the PCI DSS responsibilities matrix, be furnished annually.
When reviewing a provided AOC, you will want to note whether:
- A QSA was involved (this is preferred),
- The specific service(s) provided by the vendor are covered by the AOC,
- The date in which the AOC was signed is less than one year ago, and
- The AOC is accurate and complete
If a TPSP will be operating under your Merchant ID (MID), they will need to provide either an AOC from a ROC, or the AOC from the SAQ D for Service Providers (SAQ D-SP). For those service providers that are operating under one of your organization’s MIDs, you are responsible for attesting PCI compliance, which will be informed by the associated PCI DSS responsibilities matrix and agreement.
If you are unsure, your CampusGuard QSA can also help review all this documentation and determine whether the AOC that is provided is appropriate for the specific service(s) offered by the TPSP.
What Due Diligence Should Be Performed on TPSPs Now to Prepare for v4.0?
PCI DSS version 4.0 was released in March of 2022. As we approach one year with the new version available, merchants and TPSPs have already started their transition to 4.0. Many merchants are planning to attest to v4.0 within the next few months. TPSPs who are providing the PCI DSS responsibilities matrix that is required under 4.0 will likely have a competitive edge as they pursue agreements with merchants who appreciate the added clarity afforded by the matrix.
Although a service provider may not be officially required to provide the matrix until 3/31/2024, organizations leveraging a TPSP have an existing PCI DSS Requirement that this matrix addresses. TPSPs have an opportunity to demonstrate their commitment to supporting customer compliance, and at the same time to show they are committed to meeting the upcoming requirement. Similarly, TPSPs should be willing to provide details regarding their plan for v4.0 Requirement 11.4.7 to support penetration testing.
What if Vendors Push Back?
It may be helpful to remind TPSPs that the agreements you are signing now will span the v4.0 effective date. The organization’s overall attestation of compliance to 4.0 is dependent upon vendors being able to produce this information, so finding out now (and documenting) the status of each vendor’s planned transition to PCI DSS v4.0 is necessary.
If a vendor is not willing to produce the required documentation, it may be helpful to learn this now, which may allow time for transitioning to alternative providers prior to the retirement of PCI DSS version 3.2.1 and any overlapping contract renewal or expiration dates. Even if a vendor is merely hosting a link that is redirecting to another TPSP’s payment page, that vendor has PCI DSS compliance responsibilities. Further, if the vendor has the business relationship with you, it falls to them to ensure their subservice providers (including payment processors) are compliant and are willing to speak to which of the remaining PCI DSS responsibilities fall to you.
Some vendors may require that you sign an NDA prior to sharing any compliance documentation or a responsibilities matrix. There may be some legitimate reasons for requiring an NDA for certain information. However, TPSPs should have compliance documentation readily available to share with prospective or current customers, particularly when this information is required for supporting PCI DSS compliance of all parties.
CampusGuard stands ready to help encourage TPSPs to provide this information ahead of PCI DSS V3.2.1 retirement. Organizations should have written agreements with all TPSPs ensuring that they understand and formally agree to their responsibilities and obligations, including those spanning PCI DSS 4.0. CampusGuard can also share sample contract language and work with your teams on these agreements.
Take advantage of your CampusGuard QSA. Include them in conversations with vendors who are unwilling to providing this documentation, or who may be unwilling to acknowledge any of their own (or their subservice provider’s) PCI DSS responsibilities.
TPSPs are ultimately likely to support this approach, even if they seem reluctant at first. Working with customers now on v4.0 compliance gives them an opportunity to demonstrate their compliance maturity, which will in turn provide them with a competitive edge during this transition period—and in the future as PCI DSS compliance requirements evolve.
Additional feedback from the CampusGuard Security Advisor Team:
[Gokturk]: Here are some of the typical responses our clients are getting from their TPSPs when they ask for compliance documentation and a PCI DSS responsibilities matrix:
“We don’t store, transmit, or process our cardholder data. We merely redirect to a payment processor, so we don’t have PCI DSS compliance responsibilities.”
This is an oldie but a goodie. It’s almost as common as “E2EE is the same thing as PCI-validated P2PE!”
Sadly, both statements are incorrect.
“We are unable to share any of our compliance information without an NDA.”
This is common, but it never ceases to confuse me. Does this mean you don’t have any, or is it that you’d rather hide your compliance? Moving on to a more willing TPSP…
“The requirement for us to provide a PCI DSS responsibilities matrix won’t be applicable until PCI DSS 4.0.”
Ok, but our clients have had the burden of attesting to this requirement for years now. How about a little help, especially since this is a requirement for you as of March 31st, 2024?
Does any of this sound familiar? As QSAs, we’re used to encountering pushback from third-party vendors who are hesitant to acknowledge responsibility for certain/any PCI DSS requirements. We were relieved to see that the PCI Council has provided our customers with an “assist” in v4.0. Rather than having to rely on vendors to provide a PCI DSS responsibilities matrix and compliance documentation as a best practice, TPSPs will now be required to do so.
We’ve been busy! We QSAs have been on calls with TPSPs and our clients, supporting their efforts to get this information from reluctant vendors. We’ve been pleased with the responses from many TPSPs who are embracing and running with these new requirements after we engage with them.
The TPSPs who “get it” realize that they can demonstrate their commitment to supporting their customers’ PCI DSS compliance efforts. TPSPs who aren’t yet transitioning to v4.0 may find themselves losing customers.
CampusGuard has your back. Let us know how we can help support your TPSP management efforts and get you ready for PCI DSS 4.0!
For additional guidance regarding your third-party service provider program and how to ensure your organization is prepared for PCI DSS Version 4.0, please reach out to us.