PCI Compliance Requirements Checklist for Vendor Onboarding

A practical PCI compliance requirements checklist should cover scope, the applicable PCI DSS controls, validation evidence, third-party responsibilities, and ongoing monitoring. For vendor onboarding, the first question is not whether a supplier has a compliance certificate. It is whether the supplier stores, processes, or transmits payment card data—or can affect the security of the cardholder data environment.

Collecting W-9/W-8 forms, bank account details, or identity documents does not by itself make a workflow subject to PCI DSS. Those records need their own protections. Conversely, a vendor with administrative access to payment infrastructure may matter for PCI even if it never receives a card number.

This guide uses PCI DSS v4.0.1. Its previously future-dated requirements became effective on March 31, 2025, as discussed in SecurityMetrics’ guide to the new requirements. Treat the checklist as an operational starting point, not a substitute for the standard or your organization’s required assessment.

Start with scope, not document collection

PCI DSS is an industry security standard, generally enforced through payment-brand and acquiring relationships rather than as a standalone government statute. Validation obligations depend on your role, payment arrangements, and the requirements of the organization accepting your compliance evidence.

Before requesting documents, have the business owner and security team answer these questions:

• What data enters the service? Identify primary account numbers, cardholder names, expiration dates, and any sensitive authentication data.
• Where does it travel? Map forms, APIs, browser scripts, support tickets, logs, exports, backups, and downstream providers.
• What access does the vendor have? Include hosting, remote support, identity administration, and the ability to change payment pages.
• What is outsourced? Distinguish the provider’s controls from customer configuration and operating responsibilities.
• How will compliance be validated? Confirm the applicable Self-Assessment Questionnaire (SAQ) or Report on Compliance (ROC) route with the acquirer or other compliance-accepting entity.

Hosted checkout and tokenization can reduce scope, but neither proves that every connected system is excluded. Security must assess the actual integration, not just the product description.

Keep PCI status separate from tax documentation and KYC/KYB readiness. A vendor can be ready for tax reporting but not approved for payment-system access.

The 12 PCI DSS requirements: an evidence checklist

The standard organizes controls into 12 principal requirements. Drata’s PCI DSS checklist provides an overview of these domains. The table below translates them into review questions; it does not reproduce every subrequirement or determine applicability.

For each applicable row, record an owner, evidence location, review date, and unresolved findings. AP should coordinate the onboarding record; security and system owners should evaluate technical sufficiency.

Pay particular attention to controls that are easy to miss in finance-led procurement: access authentication, payment-page scripts, monitoring, and responsibility for responding to findings. A policy document is not proof that a control operates.

Vendor onboarding checklist: apply Requirement 12.8

Requirement 12.8 addresses third-party service provider management through inventory, agreements, due diligence, compliance monitoring, and responsibility allocation. UpGuard’s explanation of PCI DSS third-party risk requirements details these obligations, including monitoring provider compliance status at least annually.

Maintain a service-level vendor inventory

List relevant providers, the services used, their business owners, access paths, and why they are in scope. Record the contracted legal entity and product, not simply a parent-company name. Different offerings from the same vendor may have different assessment coverage.

Obtain written acknowledgment of responsibility

Check that agreements address the provider’s responsibility for account data it handles or the extent to which it could affect your cardholder data environment. Have legal and security review the wording. Generic confidentiality terms do not necessarily establish PCI responsibilities.

Complete due diligence before engagement

Assess the proposed service before granting production access. Request appropriate compliance evidence and clarify exclusions, dependencies, and customer configuration requirements. Where independent validation is unavailable, escalate to security for a defensible assessment approach rather than accepting a sales assurance.

Monitor compliance status at least annually

Assign an evidence owner and next review date. Also trigger reassessment when the service, integration, access model, or assessment scope changes. An annual calendar reminder alone will not catch a new checkout integration introduced mid-cycle.

Document who owns each applicable control

Create a responsibility matrix identifying provider-owned, customer-owned, and shared requirements. For shared controls, specify the handoff: who generates logs, who reviews alerts, who disables compromised accounts, and who verifies remediation. “Shared” without named tasks is an unresolved responsibility.

How to review a vendor’s compliance evidence

An Attestation of Compliance (AOC) is a useful starting point, but receipt is not approval. Review these fields before closing the onboarding task:

1. Entity and service match: Does the evidence cover the company and service you are contracting with?
2. Assessment role: For outsourced services, request appropriate service-provider evidence. A merchant AOC alone does not establish coverage of services offered to customers.
3. Scope: Are the relevant products, environments, and delivery arrangements included? Identify exclusions.
4. Status and dates: Check the assessment outcome, completion date, and signatures. Ask about material changes since assessment.
5. Customer obligations: Confirm that your team can implement the required configuration, access, and operational controls.
6. Supporting information: Request targeted clarification or relevant assessment details when the AOC leaves a material question unanswered.

Do not substitute a marketing badge or generic “PCI certificate” for appropriate validation documentation. Equally, avoid demanding complete sensitive technical reports when narrower evidence will answer the question.

Track assessment currency, not an invented expiry date. Record the assessment date, your next monitoring deadline, and change triggers separately. A provider’s historical assessment does not prove that today’s integration remains covered.

Turn the checklist into an approval workflow

Use distinct statuses such as not applicable with rationale, evidence requested, security review, approved for defined service, and blocked pending remediation. Avoid a single “compliant” checkbox that hides scope and outstanding work.

For each decision, retain the service identifier, scope rationale, evidence reference, reviewer, decision date, remaining customer controls, and reassessment triggers. An internal exception must not be represented as PCI compliance.

A vendor onboarding portal can be part of the broader intake workflow, but confirm that any system used for security evidence has appropriate access and retention controls. Never ask vendors to upload full card details or security codes as proof of their payment setup.

Hypothetical example: An invoice vendor initially receives invoice totals and masked payment references. Later, it proposes a browser component on your checkout page. Its tax and bank records have not changed, but its security impact has. Reopen PCI scoping and evidence review before deployment rather than relying on the original onboarding approval.

Keep payment-release authority separate, too. PCI evidence does not authenticate a supplier’s bank-change request or prove an invoice is legitimate. Those risks require dedicated accounts payable fraud prevention controls.

Make approval specific—and keep it current

The strongest checklist answers three questions: what is in scope, what evidence supports the decision, and who owns the remaining work. Outsourcing payment processing can reduce your control burden; it does not remove your responsibility to understand the arrangement.

Start with vendors that handle card data or can change payment infrastructure. Build a service-level inventory, close responsibility gaps with security and legal, and prevent production access until the required review is complete. That creates a repeatable onboarding process without treating every supplier as a card processor.

Created with AI assistance. Sources are linked in the article; this content is general information, not legal, tax, or financial advice.