A PCI service provider may look trustworthy because it was validated once, but old evidence does not prove current protection. Merchants often rely on payment vendors, gateways, platforms, processors, hosting providers, and managed service providers long after the original PCI documentation has expired or no longer matches the service being used.
That creates a dangerous gap. An outdated AOC, expired scan report, old security certificate, or unreviewed compliance file can create the impression that vendor risk is controlled when nobody has actually checked whether the provider remains compliant today.
Vendor trust must be renewed with current evidence. In payment environments, expired proof is not proof.
Expired PCI Evidence Turns Vendor Trust Into Risk
Merchants often keep vendor compliance documents in a folder and treat them as permanent evidence. That is where the problem begins.
A payment vendor may have provided a PCI AOC during onboarding. A processor may have shared scan results before launch. A gateway may have sent a compliance statement during contract review. A hosted platform may have shown security documentation during procurement. Those documents may have been valid at the time, but PCI evidence is not meant to sit untouched forever.
When evidence expires, vendor trust becomes assumption. The merchant may continue relying on the provider while the provider’s compliance status, service scope, technology stack, scanning results, or security posture has changed. A vendor may have added new systems, changed hosting environments, expanded APIs, altered TLS configurations, or introduced new subcontractors. If the merchant does not review updated evidence, it may not know whether the original compliance position still applies.
PCI SSC’s Third-Party Security Assurance guidance emphasizes the importance of monitoring third-party service providers over time, not only during selection. That is directly relevant to merchants that depend on payment providers, ecommerce platforms, processors, gateways, cloud services, or managed vendors that can affect payment data.
A vendor’s compliance file should answer a current question: does this PCI service provider remain validated for the service we use today? If the file cannot answer that, it is not evidence. It is history.
A Vendor’s Scan Pass Does Not Prove Full PCI Compliance
A passing scan can be useful, but it does not prove full PCI DSS compliance by itself.
A PCI vulnerability scan checks certain externally accessible systems for known vulnerabilities. It can help identify issues such as exposed services, weak configurations, missing patches, outdated software, or other scan-detectable risks. But a scan does not describe every control the vendor operates. It does not replace a full PCI assessment, responsibility matrix, AOC, service description, or evidence showing which systems and services are covered.
This is a common misunderstanding in vendor reviews. A provider may send a “passed” scan result, and the merchant may treat it as full vendor compliance evidence. That is not enough. The merchant still needs to know whether the vendor is a PCI service provider, whether the service used by the merchant is included in the provider’s PCI assessment, whether the AOC is current, and which responsibilities remain with the merchant.
PCI SSC’s glossary defines an Attestation of Compliance as the official PCI SSC form used by merchants and service providers to attest to the results of a PCI DSS assessment, as documented in a Self-Assessment Questionnaire or Report on Compliance. A scan report and an AOC serve different purposes. One may support a technical requirement; the other helps attest to the assessment result.
A scan pass should therefore be treated as one evidence item, not the whole evidence package. Strong vendor compliance evidence connects scan results, AOC coverage, service scope, responsibilities, remediation records, and review notes into one defensible record.
Quarterly ASV Scans Need Calendar Ownership
Recurring evidence fails when nobody owns the calendar.
Approved Scanning Vendor scans and other periodic PCI evidence need clear tracking. A merchant should know when the vendor’s latest scan was performed, when the next scan is due, when the report expires, who receives the report, who reviews it, and what happens if the vendor does not provide updated evidence on time.
PCI SSC’s resource guide on vulnerability scans and Approved Scanning Vendors explains that PCI DSS has long included external vulnerability scan requirements conducted by PCI Approved Scanning Vendors and notes that ASV scan requirements were added to SAQ A in PCI DSS v4.x to address breaches targeting SAQ A merchant environments. That makes scan tracking especially important for merchants relying on hosted or low-scope payment models.
A compliance calendar should not sit only with one person who remembers renewal dates. Staff change roles. Vendors change contacts. Renewal emails get missed. A processor, assessor, customer, or internal audit team may ask for evidence at short notice. If the merchant then discovers that the vendor’s ASV scan is outdated, the issue becomes urgent and harder to explain.
Quarterly PCI scan evidence should have ownership. Someone should track scan dates, expiration dates, responsible contacts, reminder workflows, escalation paths, and review outcomes. If a scan is late or missing, the merchant should know before an external party asks.
The cost of expired evidence is not only noncompliance. It is the loss of confidence in the vendor-risk process.
Failed PCI Scans Reveal Vendor Security Weaknesses
A failed PCI scan should not be treated as a paperwork inconvenience.
A scan failure may reveal technical weaknesses that affect payment-system security. Common failure areas can include outdated software, exposed services, unnecessary open ports, weak encryption, expired certificates, insecure configurations, missing security headers, vulnerable web applications, or unresolved known vulnerabilities.
Not every failed scan means payment data is exposed. But every failed scan deserves investigation. A vendor that provides payment-related services should be able to explain what failed, why it failed, which systems were affected, whether those systems are in PCI scan scope, what remediation was completed, and when a clean rescan was achieved.
A scan failure also tells merchants something about vendor discipline. Did the provider detect the issue before the scan? Did it communicate clearly? Did it remediate quickly? Did it provide updated evidence? Did it explain whether the affected system supports payment processing, reporting, authentication, APIs, hosted checkout, or administrative access?
Payment provider PCI compliance is not only about having a document. It is also about how the provider handles issues when controls fail. A vendor that hides scan failures, delays remediation, or refuses to explain scope can create third-party payment provider risk even if the issue appears technical.
Merchants should treat failed scan evidence as a risk review trigger, not a box to chase.
Vendor Scope Must Include Every Internet-Facing Payment System
Vendor evidence is only useful if it covers the right systems.
A scan report or AOC may look valid, but the merchant still needs to confirm what it actually covers. The scan scope should include relevant internet-facing payment systems, payment-related services, hosted platforms, APIs, administrative portals, customer payment pages, and environments that support or connect to cardholder data processing.
The same principle applies to a PCI service provider AOC. The merchant should confirm that the service it uses appears within the provider’s validated scope. A provider may have several products, regions, platforms, or environments. The AOC may cover one service but not another. A scan may cover production domains but not an admin portal. A service description may cover payment processing but not reporting tools, support dashboards, or hosted add-ons.
This is where vendor scope review becomes essential. Merchants should compare the evidence against the real payment architecture. Which domains do customers use? Which APIs connect payment systems? Which portals do staff access? Which cloud environments host payment services? Which systems support checkout, refunds, recurring billing, tokenization, reporting, or dispute workflows?
A vendor’s evidence should match the systems that matter to the merchant. If the scan scope or AOC leaves out a payment-relevant system, the merchant should not assume the omission is harmless.
PCI evidence management requires more than storing documents. It requires reading them against the actual payment environment.
Out-of-Scope Claims Need Proof, Not Assumptions
Vendors may say certain systems are out of scope, but merchants should ask how that conclusion was reached.
An out-of-scope claim may be valid. A system may be properly segmented, isolated from payment data, unrelated to the cardholder data environment, or unable to affect payment processing. But the claim should be supported by evidence, not just a statement.
Scope exclusions should be backed by service descriptions, data-flow diagrams, segmentation evidence, system architecture notes, written explanations, and clear boundaries showing why the excluded system cannot affect the payment environment. If a system has network connectivity, administrative access, shared credentials, API links, reporting functions, or operational dependence on payment services, the out-of-scope claim deserves closer review.
PCI segmentation evidence matters because weak segmentation can create false comfort. A vendor may believe a system is separate from payment processing, but if it can connect to payment systems or affect security controls, the merchant needs to understand the risk.
Out-of-scope does not mean “not discussed.” It means the vendor can explain why the system is excluded and provide enough evidence for the merchant to assess that conclusion.
A merchant does not need to become the vendor’s assessor. But it does need enough evidence to avoid accepting scope claims blindly.
Expired Certificates and Weak TLS Can Break Vendor Trust
Expired certificates and weak TLS settings are not minor technical details when a vendor supports payment systems.
A payment vendor may operate hosted portals, APIs, checkout services, reporting dashboards, payment links, customer-facing pages, or administrative systems. If those services rely on expired certificates, weak encryption, outdated TLS versions, or poor certificate management, the issue can affect customer trust, scan results, and confidence in the vendor’s security discipline.
A browser warning on a payment-related page can immediately damage trust. Customers may abandon payment. Staff may hesitate to use the portal. Payment operations may be disrupted while teams confirm whether the system is safe. Even when no cardholder data is exposed, certificate problems create evidence that the vendor’s operational controls may not be working as expected.
TLS PCI compliance should therefore be reviewed as part of vendor evidence. A vendor that handles payment-related services should be able to show that externally facing systems use appropriate cryptography, current certificates, and secure configurations. If a quarterly PCI scan failed because of weak TLS or certificate problems, the merchant should ask what failed, when it was fixed, and whether the affected service was connected to the payment environment.
A certificate expiring once may be a mistake. A vendor repeatedly missing certificate renewals or leaving weak encryption unresolved suggests a larger control problem.
Rescans Must Prove the Vendor Actually Fixed the Risk
A vendor saying “we fixed it” is not enough.
If a PCI scan failed, the merchant should request evidence that the issue was remediated and rescanned successfully. The vendor should be able to provide updated scan results, remediation notes, affected-system details, revised scope information where needed, and confirmation that the failing issue no longer appears.
This is especially important when the failed scan involved internet-facing payment systems, APIs, customer portals, hosted checkout infrastructure, or administrative interfaces used by the merchant. A remediation claim without a clean rescan leaves the merchant with uncertainty. The issue may have been partially fixed, fixed in one environment but not another, or fixed in a way that introduced a new weakness.
PCI SSC’s Approved Scanning Vendor resources explain that ASVs conduct external vulnerability scanning services to validate adherence with PCI DSS external scanning requirements. That makes the rescan an evidence event, not a casual follow-up. If the original scan failed, the vendor needs to close the loop with results that show the risk has been addressed.
Merchants should also ask whether the failed issue affected other customers, related environments, shared infrastructure, or connected services. A vulnerability in one payment-facing system may reveal a configuration pattern across the vendor’s platform.
Vendor risk is not closed when the vendor replies. It is closed when the evidence supports closure.
Vendor Evidence Needs Records, Dates, and Review Notes
Vendor PCI evidence should be organized enough that the merchant can prove it is being monitored.
A strong evidence file should show current AOCs, ASV scan results, remediation records, responsibility matrices, contracts, scope notes, review dates, owner names, approval decisions, and follow-up actions. The goal is not to collect documents for decoration. The goal is to show that payment vendor compliance is reviewed, understood, and acted on.
Evidence management should also include dates. When was the AOC issued? Which assessment period does it cover? When was the ASV scan performed? When is the next quarterly PCI scan due? When did the merchant review the document? Who approved continued use of the vendor? Were any issues found? Were follow-up actions completed?
Without review notes, evidence can become difficult to trust. A file may contain an AOC, but no one knows whether it covers the right service. A scan report may exist, but no one knows whether it passed or whether the scan scope matched the merchant’s payment use case. A responsibility matrix may exist, but no one knows whether it was reviewed after the integration changed.
PCI evidence management should make the merchant’s decision defensible. If a processor, assessor, customer, or internal leader asks why the vendor is trusted, the answer should be based on current records, not memory.
Training Helps Teams Catch Expired PCI Evidence Early
Expired PCI evidence is often a process failure, not a technical mystery.
A procurement team may collect vendor documents during onboarding, then never request updates. A finance team may rely on a payment provider without knowing the AOC has expired. An ecommerce team may add a new payment feature without checking whether the provider’s evidence covers it. IT may receive scan results but not understand whether the scope includes payment systems. Compliance may own the PCI file but lack visibility into vendor changes.
Teams working through Third-Party Payment Provider Risk And PCI Responsibility can build practical habits around PCI service provider evidence, PCI AOC review, ASV scans, quarterly PCI scan tracking, vendor scope review, remediation evidence, responsibility matrices, and payment vendor compliance. This training is useful for compliance, procurement, finance, ecommerce, IT, security, and payment teams because each group may control part of the vendor-risk process.
Training should help teams understand that provider evidence has a lifecycle. It must be requested, reviewed, stored, dated, monitored, and refreshed. It should also teach teams to recognize warning signs: expired AOCs, missing scan reports, vague scope language, failed scans without rescans, unsupported out-of-scope claims, weak TLS findings, and unclear responsibility boundaries.
A vendor’s PCI evidence should never expire quietly.
Conclusion
Your vendor’s PCI evidence is only useful if it is current, relevant, and reviewed.
A PCI service provider may have been compliant during onboarding, but merchants cannot rely forever on old documents. Expired AOCs, outdated scan reports, failed PCI scans, weak TLS findings, unclear scope, unsupported out-of-scope claims, and missing rescan evidence can all turn vendor trust into payment risk.
A scan pass does not prove full PCI compliance. A failed scan is not just paperwork. An AOC is not useful if it does not cover the service the merchant actually uses. An out-of-scope claim is not enough without proof. A vendor’s “fixed” response needs updated evidence.
Strong PCI vendor risk management depends on records, dates, owners, review notes, escalation paths, and training. Merchants should know which vendors support payment data, which systems are covered, when evidence expires, who reviews it, and what happens when proof is missing or failed.
Payment vendor compliance should be monitored, not assumed.
FAQs
What Is a PCI Service Provider?
A PCI service provider is an organization that stores, processes, transmits, or can affect the security of cardholder data or payment processing services on behalf of another entity.
What Is PCI Vendor Risk?
PCI vendor risk is the risk created when a third-party provider affects payment systems, cardholder data, payment workflows, or PCI compliance responsibilities.
What Is a PCI AOC?
A PCI AOC, or Attestation of Compliance, is an official PCI SSC form used to attest to the results of a PCI DSS assessment as documented in an SAQ or Report on Compliance.
Why Does an Expired PCI AOC Matter?
An expired PCI AOC matters because it may no longer prove that the vendor’s current services, systems, and controls are validated for the merchant’s payment use case.
Does a Passed ASV Scan Prove Full PCI Compliance?
No. A passed ASV scan supports external vulnerability scanning requirements, but it does not prove full PCI DSS compliance by itself.
What Should Merchants Do After a Vendor PCI Scan Failed?
Merchants should request remediation notes, updated scan results, rescan evidence, affected-system details, and confirmation that the issue was fixed before closing the vendor risk.
Why Is PCI Scan Scope Important?
PCI scan scope is important because scan results are useful only if they include the relevant internet-facing payment systems, APIs, portals, hosted platforms, and services connected to payment processing.
How Can Weak TLS Affect Payment Vendor Trust?
Weak TLS, expired certificates, and poor certificate management can cause scan failures, browser warnings, payment disruption, and questions about the vendor’s security discipline.
What Should Vendor Compliance Evidence Include?
Vendor compliance evidence should include current AOCs, ASV scan results, remediation records, responsibility matrices, contracts, scope notes, review dates, and approval decisions.
Why Is PCI Responsibility Training Important?
PCI responsibility training helps teams track vendor evidence, review AOCs, monitor scans, challenge scope gaps, and catch expired PCI documentation before it becomes a compliance problem.
