Latest PCI DSS Standards: Use Third Parties – But at Your Own Risk

Third parties have long been the hidden heroes of the payment card industry, providing specialized, streamlined support to merchants looking to host a website or spin up an app. But that convenience is not without a cost.

According to PCI DSS 4.0 compliance standards, although merchants are free to use third parties, the responsibility for any incurred security liability will be all theirs. When a merchant takes on an outside provider, they are taking on their cybersecurity risk as well.

This, along with other policies, will shape the direction of PCI DSS 4.0 compliance for all involved entities in the years ahead.

On March 31^st, PCI DSS 4.0 Became Officially Enforceable

As of March 31^st, 2025, the PCI DSS 4.0 standard initially introduced in 2022 came fully into effect, making this international regulation fully updated and enforceable. Companies seeking to comply can look to PCI DSS 4.0.1, a clarification of the version 4.0 guidelines that came out in June of last year.

The new requirements established by the PCI Security Standards Council (PCI SSC) hinge on a few new updates to stay ahead of the times. These include broader MFA requirements, stronger password requirements, the mandate to protect all staff against phishing attacks, and additional regulations for e-commerce to combat ongoing threats. Additionally, the updated rules cover the need to keep an eye on covert malware channels via IDS/IPS and to implement more targeted risk assessments, along with foregoing manual log reviews in favor of daily, automated ones.

With a healthy list of positive changes to implement, it would seem merchants and payment card processors would be candidates for offloading some of the burden on others – say, third parties. However, PCI DSS 4.0 makes it clear that this is not an option.

Bearing the Burden of Third-Party Liability

It’s hard to imagine any e-commerce or financial platform that stays afloat without the help of at least some third-party integrations. Estimates of just how many they use a piece range into the hundreds, and HTTP Archive revealed that at least 94% of the websites out there use at least one. When it comes to payment-related applications, online retailers can leverage anything from ready-made web components to pre-built scrips, CRMs, APIs, payment gateways, and more. All of these integrations carry risk, and according to PCI DSS 4.0 regulations, that risk is carried completely by the merchant.

To that end, PCI DSS sub-requirement 12.8.1 requires vendors to maintain a list of all third-party service providers (TSPS), along with the services they provide. Sub-requirement 12.8.3 requires a thorough risk assessment of the TSPS prior to contracting, and 12.8.4 holds that their (the third party’s) PCI DSS compliance status should be re-evaluated every 12 months. Lastly, sub-requirement (12.8.2) states that merchants must store written agreements with any third parties with which account data is shared and acknowledges (in writing) that the third party will maintain adequate security controls over the sensitive information provided.

That said, despite all the safeguards, merchants still must assume full responsibility under the law (PCI DSS standards) for any data breaches or cyber incidents on their watch, regardless of whether they originated in their own internal systems or a third party’s. In practice, that can look like mandated merchant control over all payment page scripts (Requirement 6.4.3), even if that script was outsourced. This makes third-party risk management a crucial skill for vendors choosing to hire out.

As noted by Josh Davies, principal technical manager at Fortra, “[PCI DSS] 4.0 emphasized its focus on third-party service providers, recognizing the efficiencies businesses gain from outsourcing while also making it clear that you cannot outsource responsibility.”

Reducing the Scope of PCI DSS 4.0 Requirements via Third Parties

While merchants can’t run or hide from ultimate PCI DSS responsibility, they can minimize their scope under PCI DSS compliance law. It’s like writing off expenses on your taxes to reduce your overall taxable income; you’re still accountable at tax time but for a lesser amount.

Vendors can reduce their PCI DSS 4.0 scope by limiting the number of systems that interact with cardholder data (CHD) or sensitive authentication data (SAD). This is frequently done via network segmentation, limiting employee access, tokenizing card data after authorization, and encrypting data as soon as it hits the card reader (point-to-point encryption). However, it can also be done by offloading certain in-house responsibilities to external third parties; a tantalizing and much-used option.

However, the caveat remains; even though cardholder data will be in another provider’s systems instead of yours, you are still ultimately responsible for what happens to it while it’s there. The choice is yours. Do you outsource the work and do your due diligence to secure an outside system? Or do you do the work in-house and keep your external security worries to a minimum?

It all depends on how you want to handle your PCI DSS 4.0 compliance.

Want to learn more about complying with PCI DSS 4.0? Download the PCI DSS 4.0 Compliance Whitepaper and make sure you’re on track.