.svg){kind=icon}
.svg)
Treating vendor security like a handshake deal can be risky for any business. If your business accepts payment cards and relies on external companies for services such as payment processing, web hosting, or customer engagement, you are still responsible for PCI DSS compliance.
PCI DSS compliance doesn’t magically disappear just because a third party is “handling it.”
Even smaller merchants—often assumed to be off the radar—can find themselves at greater risk if vendors aren’t properly vetted, documented, and monitored. In fact, outsourcing can sometimes expand your compliance scope, not shrink it, if those vendors introduce new systems or store cardholder data on your behalf.
Here’s what the PCI DSS says about third-party service providers (TPSPs), what you’re still responsible for as the merchant, and how to avoid common mistakes when outsourcing any part of your cardholder data environment (CDE).
Who Counts as a Third-Party Service Provider?
According to the PCI Security Standards Council, a third-party service provider (TPSP) is any third party entity, acting as a service provider on behalf of another entity, that stores, processes, transmits, or can impact the security of payment card account data—even if it never touches the data directly (source).
This includes payment processors, hosting providers, e-commerce platforms, analytics tools, and any third parties that manage in-scope systems and devices on your behalf—including vendors who ask you to add scripts onto your e-commerce websites.
For instance, an e-commerce merchant outsourcing all account data functions through use of an embedded third-party hosted payment form (iFrame) within their website (the ‘parent page’) must still ensure that both first (your) and third-party (their) scripts cannot be attacked to compromise customer card data (script-related FAQ).
Even your acquirer—the financial institution that processes card transactions—can be considered a TPSP under PCI DSS Requirements 12.8 and 12.9 if they provide you with other services, such as your e-commerce payment gateway (source).
What You’re Still on the Hook For
Let’s clarify: Outsourcing a PCI function doesn’t mean outsourcing the liability. Handing off your payment processing or IT infrastructure to a third-party vendor does not absolve your business of PCI DSS responsibilities. The standard is explicit—if a vendor’s service can affect payment card account data security, you remain fully accountable.
In the eyes of the PCI Security Standards Council, your job doesn’t end when you hire a vendor. It starts there.
PCI DSS Requirements 12.8 and 12.9 outline exactly what merchants must do to keep third-party relationships above board:
- Maintain a complete inventory of all TPSPs and the services each provides.
And not just the ones who process payments directly—any vendor that can impact your cardholder data environment (CDE) must be included, including computer or server systems (IT) support providers, managed network providers, web and cloud hosts, analytics platforms, and even script-based service providers embedded in your website.
You’ll also need to include other third parties, like vendors providing support via remote access, bespoke software, or mobile app developers, or providers of off-site storage or secure disposal of hard-copy materials.
- Assign someone in your organization to manage each vendor relationship.
This person must ensure each vendor has acknowledged their responsibility for the security of the payment card data they store, process, and/or transmit on your behalf, or to the extent they could impact the security of that data. They need to engage your TPSPs to ensure each of them is aware of and meeting your PCI DSS expectations—not just once, but on an ongoing (annual) basis.
- Include explicit PCI DSS responsibilities in every contract.
If your contract doesn’t spell out what your vendor must do to maintain PCI DSS compliance, you’re exposed. There is no gray area, no finger-pointing; the obligations to comply with PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible must be clearly defined in writing.
- Regularly monitor each vendor’s compliance and performance.
The PCI DSS compliance status of each TPSP should be verified at least once every 12 months. For TPSPs that undergo their own PCI DSS assessment, ask for updated Attestations of Compliance (AOCs). Review them and verify that the assessment scope covers the services provided. If a TPSP does not have an AOC, request and review evidence related to the applicable PCI DSS requirements for which they are responsible.
According to PCI SSC FAQ 1065, TPSPs must be able to provide evidence of compliance with the specific PCI DSS requirements relevant to the services they deliver—especially if those services could impact cardholder data or sensitive authentication data. Document your reviews. This isn’t busywork—it’s your paper trail if a breach occurs.
Even if your vendor tells you they’re “PCI compliant,” it doesn’t mean they’re compliant for the exact services they’re delivering to you. Many AOCs only cover specific systems or configurations, locations, or services, and those might not match the setup they’ve provided you with or where they provide it from. This is common with cloud services where there are many different services and options and only some of them are PCI DSS compliant.
And here’s a hidden risk many small businesses miss: Even if a third party claims PCI DSS compliance, that doesn’t automatically reduce your burden. You’re still responsible for verifying the scope and relevance of their compliance—and that their controls align with your own risk posture (source).
In short, the checklist doesn’t stop once you engage a TPSP. You must ensure the third-party vendor is walking the talk—and you need proof. Because when there’s a breach or compliance issue, regulators, card brands, or your acquiring bank won’t be calling your vendor first. They’ll be calling you.
What Proof Should Vendors Provide?
Any vendor claiming PCI DSS compliance should back it up with documentation—which starts with an Attestation of Compliance (AOC). This is not a formality. It’s the single most important proof that a third-party service provider has been assessed by a PCI Qualified Security Assessor (QSA) and found to be compliant for their specific services.
The AOC is essentially your vendor’s compliance résumé. And like any résumé, you need to read between the lines.
Here’s what you should look for—and insist on—when reviewing a vendor’s AOC:
- AOC for the current PCI DSS version (v4.0 or v4.0.1).
PCI DSS v3.2.1 was sunset in 2024. If a vendor is still waving around an AOC for v3.2.1, it’s not valid for compliance. This could mean their controls haven’t been updated for new requirements, or they have not had a recent assessment — and you may be liable for that gap (source).
- Clarity on what services are covered.
Some vendors only validate a subset of their operations. If you’re using a service that’s adjacent to their validated offering but not explicitly listed in the AOC, you’re on thin ice. Always confirm that the service you’re paying for is within the scope of their compliance. To go further, request a PCI DSS Requirements Responsibility Matrix. This document outlines every applicable PCI DSS requirement and clarifies whether it’s your responsibility, the vendor’s responsibility, or shared. Without it, you’re flying blind on who’s accountable for managing and monitoring compliance, detecting and responding when something breaks.
- Redactions? Ask why.
Redacted AOCs are common—but they’re not a free pass. According to the PCI SSC, redacting sensitive infrastructure details is acceptable, but anything that obscures scope, services, or compliance status should be treated as a red flag. (Redaction FAQ). And under PCI DSS v4.x Requirement 12.9.2, third-party service providers are required to respond to customer requests for information that supports their PCI DSS compliance. That includes providing clarity on which requirements they’re responsible for, which are shared, and which fall on you—the customer. If they can’t or won’t provide that? You’ve got a trust problem, not just a documentation issue.
- Proof that the AOC is still valid.
Compliance isn’t a once-and-done thing. AOCs expire after 12 months. Make sure your vendor’s documentation is current, and schedule periodic reviews (at least once every 12 months) as part of your vendor management process.
The Wrong AOC? Wrong Vendor.
Not all AOCs are created equal. If a third-party vendor sends you an Attestation of Compliance for Merchants—instead of one for Service Providers—that’s not valid proof of compliance for services they’re offering to you.
This is a common red flag, especially with digital agencies, hosting providers, or e-commerce developers who integrate hosted payment pages. Even if they provide an SAQ A with a Merchant AOC, it’s not sufficient to demonstrate PCI DSS compliance for the services they provide to your business.
At a minimum, these vendors must complete SAQ D for Service Providers or have a QSA-issued AOC for Service Providers if they impact or manage systems that touch cardholder data or sensitive authentication data.
Always verify the AOC type. If it says Merchant and they’re acting as a Service Provider, send it back. Politely. But firmly. And finally:
- Beware of compliance theater.
A PDF with logos and compliance buzzwords means nothing without a QSA-signed AOC. PCI SSC does not recognize certificates of compliance as proof of PCI DSS validation (source). The only documents that matter are the Attestation of Compliance (AOC) and the Report on Compliance (ROC)—and even then, you need to read them carefully.
Also note: Not all AOCs are QSA-signed. Some third-party service providers self-assess using SAQ D for Service Providers, which is allowed under the card brands’ compliance programs for certain types of TPSPs —but it’s also a signal to dig deeper. If a vendor chooses to self-assess instead of undergoing a formal QSA audit, you should request additional documentation and clarity, including a PCI DSS Requirements Responsibility Matrix (PCI DSS 12.8.5) and a willingness to respond to due diligence requests (PCI DSS 12.9.2). And don’t assume that being listed as “PCI Certified” on a website means the whole operation is covered—ask for the paperwork.
If your vendor is lagging on their PCI DSS version, doesn’t know what’s in their AOC, or gives vague answers about scope, it’s not just a risk to your payment card account data—it’s a risk to your business continuity. Because when regulators or forensic investigators start asking questions, you’ll be the one answering them.
Questions Every Merchant Should Ask Their Vendors
Choosing a third-party provider isn’t just a matter of comparing features or price—it’s a compliance-critical decision. If you don’t ask the right questions before signing the contract, you can inherit risk without knowing it.
Fortunately, the PCI Security Standards Council has already done some of the homework for you. Their “Small Merchant Questions to Ask Your Vendors” guide outlines essential questions that help small businesses vet potential partners—and avoid costly blind spots.
Here are the non-negotiable questions every merchant should be asking:
- Are you currently PCI DSS validated?
If a third party stores, processes, or transmits payment card account data on your behalf, they should be PCI DSS validated—and able to produce current documentation to prove it. No vendor should hesitate or waffle here.
But for TPSPs that don’t directly handle payment card account data—like those managing in-scope components or with access to your cardholder data environment (CDE)—formal validation isn’t strictly required by the PCI DSS or card brands. Still, it’s in your best interest to ask anyway. Why? Because validation provides assurance that they understand the PCI DSS requirements that apply to them—and the potential impact they have on your compliance.
- Can we review your latest Attestation of Compliance (AOC)?
You’re not being rude—you’re doing your job. If a vendor won’t share this or can’t explain what it covers, they’re not a responsible partner.
- When was your last PCI DSS assessment?
Compliance has an expiration date. If the vendor’s last review was over 12 months ago, it’s stale—and your risk profile just went up.
- Which of your services are included in your compliance scope?
Don’t assume all offerings are covered. Ask specifically whether your implementation of their product or service falls within the PCI-assessed scope.
- How do you manage your subcontractors or downstream vendors?
It’s not just your vendor you need to worry about. Your e-commerce developer, for example, might build your storefront but outsource hosting to a third-party cloud provider. That hosting provider might, in turn, use someone else’s Content Delivery Network (CDN) or monitoring service.
It is important for you to understand whether any of your TPSPs have 'nested' relationships with other 'secondary' TPSPs to deliver the service provided. While your obligation under Requirement 12.8.4 extends only to monitoring the compliance status of your directly contracted 'primary' TPSPs, you should also review your TPSPs’ reliance on and compliance monitoring of nested 'secondary' TPSPs.
- What’s your incident response plan?
If something goes wrong, do they notify you? How fast? Do they have service-level agreements (SLAs) for reporting breaches? What if their plan is “we’ll get back to you”?
These questions aren’t optional—they’re your due diligence obligation as a merchant. Asking them protects your business, helps you stay compliant, and shows your acquirer, card brands, or internal stakeholders that you take third-party risk seriously.
And here’s the real kicker: You should be re-asking these questions at least once a year, even vendors with solid answers today can fall behind tomorrow.
Reduce Your Risk Without Raising Costs
Just because you’re a small merchant doesn’t mean you’re powerless in the face of PCI DSS. In fact, the smartest move you can make is to design your systems and vendor relationships to reduce your PCI DSS scope from day one.
Scope is everything. The more people, processes, systems, and vendors that can touch payment card account data—or influence its security—the larger your compliance burden becomes. However, you can drastically limit your obligations by choosing vendors and technical setups that keep sensitive data out of your environment altogether.
Leverage SAQ A Wherever Possible
If your business qualifies for Self-Assessment Questionnaire (SAQ) A, you can significantly simplify your PCI DSS compliance assessment. SAQ A is designed for merchants who fully outsource payment processing to PCI DSS compliant third-party service providers or payment processors—and who don’t store, process, or transmit payment card account data themselves in any form.
This applies not only to e-commerce merchants, but also to mail/telephone order (MOTO) merchants who outsource payment acceptance to a third-party call center, order fulfillment provider, or use pay-by-link solutions to accept MOTO customer payments via a fully outsourced TPSP hosted payment page.
To qualify as an SAQ A e-commerce merchant:
- Your payment page/form delivered to your customer’s browser must be hosted by a PCI DSS compliant third-party service provider, scenarios include:
- Merchant website redirects to a PCI DSS compliant hosted payment page
- Merchant website embeds a PCI DSS compliant hosted payment page or form (using one or more iFrames)
- Merchant website is fully outsourced, the TPSP/payment processor handles all aspects of the website's operations, payment account data collection and processing.
- No payment card account data can be electronically stored, processed, or transmitted on your own systems.
- You must ensure any scripts or iframes used are isolated and cannot be manipulated to compromise customer data.
(Note: Per FAQ 1588, this specific script security eligibility criterion does not apply to merchants who fully redirect to a compliant third party or fully outsource their e-commerce operations.)
That last part is critical. If your TPSP injects scripts into your checkout process—especially inline or cross-domain JavaScript—you may instantly lose SAQ A eligibility. PCI DSS guidance makes it clear: Merchants are responsible for controlling and monitoring all third-party scripts on their websites, even if those scripts are implemented by a service provider. Merchants with a webpage that includes a TPSP’s/payment processor’s embedded payment page/form (e.g. in an iFrame) must be able to confirm their website is not susceptible to script attacks in order to meet the SAQ A eligibility criteria.
Options to achieve that include obtaining confirmation from the TPSP/payment processor providing the embedded payment page/form that their solution, when implemented per their instructions, includes techniques that protect your website. Or implementing a solution or techniques yourself to protect your e-commerce webpage from scripts targeting payment card account data.
The techniques set out in PCI DSS requirements 6.4.3 and 11.6.1, though not explicitly included in the SAQ A, are a potential approach:
Under Requirement 6.4.3, merchants must manage payment page scripts to ensure each script is necessary, its use authorized, and its integrity assured.
And Requirement 11.6.1 takes it further: You must implement a change- and tamper-detection mechanism to detect and alert on any unauthorized changes to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser—to prevent tampering, skimming, or injection attacks.
For e-commerce merchants, the PCI SSC E-commerce Guidance for requirements 6.4.3 and 11.6.1 is a must-read. It clarifies which merchant setups require these controls, and where responsibility lies—even when third parties are involved.
Bottom line: If you’re embedding anything that runs code on your payment pages, you’re on the hook to make sure it’s safe, scoped, and monitored. Period.
Use PCI SSC Guidance to Build a Defensible Vendor Process
If you don’t already have a vendor security management process, the PCI SSC has provided the blueprint. Two foundational resources:
These guides walk through how to:
- Define and document roles and responsibilities between you and your vendors.
- Conduct risk-based reviews of vendor services.
- Establish clear communication and breach notification expectations.
- Build an evidence trail that shows you’re taking compliance seriously—even if you’re not storing card data yourself.
And it doesn’t stop there. The PCI SSC FAQ database offers practical answers to real-world edge cases—especially when dealing with third-party service providers. Some of the most relevant ones include:
- FAQ 1065 – What counts as “demonstrating PCI DSS compliance”?
- FAQ 1576 – What evidence should a TPSP give you?
- FAQ 1578 – Why TPSPs can’t rely on merchant SAQ eligibility criteria.
- FAQ 1579 – Do PCI DSS requirements apply if a TPSP doesn’t touch payment card account data directly?
- FAQ 1580 – What is the assessment scope for those TPSPs that can indirectly impact the security of payment card account data?
- FAQ 1592 – Are script providers considered TPSPs?
This process doesn’t require a dedicated compliance officer or a cybersecurity budget. It just requires intentional choices and a willingness to say no to vendors who can’t provide the right assurances.
Keep It Lean, But Don’t Cut Corners
Minimizing your PCI DSS scope isn’t about shortcuts—it’s about intelligent design. The right architecture, paired with the right vendors, can save significant resources and dramatically reduce your exposure if something goes wrong.
Because at the end of the day, while you don’t have to secure what you never touch; you need to ensure your compliant TPSPs fulfill their PCI DSS responsibilities. Because if you let non-compliant vendors manage elements of your payment acceptance or risky code inside your payment flow, you’re not just expanding the scope—you’re inviting unnecessary risk.
Final Word: You Can’t Outsource the Blame
It might be tempting to trust that your vendors “have it handled,” especially when they throw around the words PCI DSS compliant. But shared risk doesn’t mean shared responsibility—the merchant always carries the final burden.
Make sure you:
- Vet your vendors before signing.
- Collect and review up-to-date evidence of PCI DSS compliance—specifically tied to the services they provide and the applicable PCI DSS requirements.
- Limit scope when possible.
- Monitor vendor compliance over time.
When something goes wrong, your business is on the hook—no matter who clicks “Accept.”
Don’t let third-party risks sneak past your defenses. Whether you’re sorting through AOCs, vetting a new provider, or wondering if your current setup qualifies for SAQ A—you don’t have to do it alone.
Contact the VikingCloud team today for expert guidance on managing vendor risk, reducing your PCI DSS scope, and staying one step ahead of compliance headaches.
.webp)
