PCI DSS v4.0: What Changed for Encryption, Tokenization, and Third-Party Provider Validation

The Payment Card Industry Data Security Standard (PCI DSS) version 4.0 introduced changes to encryption, tokenization, and third-party validation requirements that shift accountability squarely onto executive leadership. Organizations that process, store, or transmit cardholder data must now demonstrate active governance over technologies and service providers that were previously treated as technical implementation details.

The consequence of inadequate oversight is not a failed audit. It is a breach notification, regulatory enforcement action, card brand fines, and potential loss of merchant processing privileges. These are business continuity events that no technical team can remediate after the fact.

What Changed in PCI DSS v4.0

PCI DSS v4.0 represents the first major update since 2018. While earlier versions established baseline technical controls, version 4.0 emphasizes organizational accountability, third-party oversight, and continuous validation.

Three areas saw material expansion:

• Point-to-point encryption (P2PE) and tokenization now require documented validation that solutions meet PCI standards, not just vendor assertions
• Third-party service providers must be actively managed under Requirement 12.9, with written agreements, monitoring, and regular reviews
• Organizations must maintain current inventories of all service providers with access to cardholder data and document their applicable PCI DSS requirements

The standard does not permit delegating accountability. If a payment processor, gateway, or technology vendor experiences a compromise that exposes your cardholder data, your organization remains responsible under PCI DSS regardless of contractual indemnification.

Why Encryption and Tokenization Matter to Executive Leadership

Encryption and tokenization are not interchangeable. They serve different security functions, have different implementation risks, and create different compliance obligations.

Point-to-point encryption protects cardholder data in transit from the point of capture (typically a payment terminal) to a secure decryption environment. Properly implemented P2PE reduces PCI scope by ensuring plaintext card data never exists in your environment. Improperly implemented P2PE creates a false sense of security while leaving data exposed at endpoints or intermediate systems.

Tokenization replaces sensitive card data with a non-sensitive equivalent. The token has no exploitable value outside your specific system. Effective tokenization also reduces scope, but only if the tokenization system itself is isolated, properly secured, and the tokens are genuinely random and non-reversible.

Both technologies shift risk to the vendor operating them. PCI DSS v4.0 now requires leadership to verify that shift actually occurred and continues to be maintained.

Requirement 12.9: Third-Party Service Provider Management

Requirement 12.9 establishes that organizations must maintain an inventory of all third-party service providers with access to cardholder data or that could affect the security of cardholder data. This includes payment processors, gateways, tokenization vendors, hosting providers, managed service providers, and any other entity with network access to in-scope systems.

The requirement mandates:

• Written agreements acknowledging service provider responsibility for securing cardholder data they possess or could affect
• Documentation of which PCI DSS requirements each provider is responsible for meeting
• A process for engaging with service providers, including at least annual monitoring of their PCI DSS compliance status
• Maintenance of current information about which service providers are in use and what services they provide

Many organizations discover during assessment that they cannot produce this documentation. Contracts reference security obligations generically. IT teams cannot confirm which vendors have what access. No single owner tracks provider compliance status. The organization has deployed tokenization or P2PE but cannot demonstrate that the solution meets PCI standards or that the vendor remains compliant.

This is a governance failure, not a technical one.

Who Owns This and What Adequate Ownership Looks Like

PCI DSS compliance ultimately resides with the organization's executive leadership, typically the CFO or COO. The standard does not recognize technical implementation as sufficient. It requires documented policy, assigned responsibility, and evidence of oversight.

Adequate ownership means:

• A named executive accountable for the organization's PCI compliance program, with authority to enforce requirements across business units
• Written policies governing service provider selection, contracting, and ongoing monitoring
• A current, maintained inventory of all service providers with cardholder data access or security responsibility
• Documented evidence of each provider's PCI compliance status, reviewed at least annually
• A process for validating that encryption and tokenization implementations meet PCI standards before deployment and continuously thereafter
• Regular reporting to the board or executive committee on compliance status, provider risk, and gaps requiring remediation

Many organizations assign PCI responsibility to IT or information security teams without executive sponsorship, policy authority, or budget. These teams can implement controls but cannot compel business units to change vendor relationships, cannot negotiate contract terms with legal, and cannot report compliance risk at a level that drives action.

The gap is strategic leadership, not technical capability.

The Connection to Vendor and Third-Party Oversight

PCI DSS Requirement 12.9 overlaps substantially with broader third-party risk management obligations. Organizations subject to other regulations—GDPR, HIPAA, GLBA, state data breach notification laws—face similar requirements to validate vendor security controls and maintain evidence of due diligence.

The practical challenge is that these requirements are managed by different teams, against different frameworks, with different documentation standards. Procurement tracks contracts. IT tracks access. Legal tracks liability. Information security tracks technical controls. Compliance tracks audit findings. No single function sees the complete picture or can answer the question a board member will ask: which vendors pose unacceptable risk and what are we doing about it?

Organizations that implement [virtual CISO (vCISO) leadership](/vciso/) establish a single point of accountability for this question. A vCISO operates at the executive level, with authority to align vendor management across procurement, legal, IT, and compliance functions, translate technical findings into business risk, and report status in terms leadership can act on.

What Leadership Should Do Next

If your organization processes cardholder data, these actions should occur within the next 90 days:

• Identify the named executive accountable for PCI compliance. If no executive currently owns this, designate one in writing with explicit authority and budget.
• Inventory every third-party service provider with access to cardholder data or systems in scope for PCI. Include payment processors, gateways, tokenization vendors, hosting providers, and managed service providers. Document what access each has and which PCI requirements they are responsible for meeting.
• Obtain and review current PCI compliance documentation from every service provider on that inventory. An Attestation of Compliance (AOC) or equivalent evidence dated within the last 12 months is the baseline. If a provider cannot produce this, that is a material gap requiring immediate attention.
• If your organization uses point-to-point encryption or tokenization, confirm in writing that the solution is validated against PCI P2PE or PCI TSP standards. Vendor marketing claims are not evidence. Request the PCI listing or validation letter.
• Review existing service provider contracts for written acknowledgment of PCI responsibility. If contracts are silent or reference security only generically, amendments are required.
• Establish a documented process for ongoing monitoring of service provider compliance. Annual review is the minimum; higher-risk providers warrant quarterly or continuous oversight.
• Report current status to the board or executive committee, including identified gaps, remediation timelines, and resource requirements.

Organizations that cannot complete these steps internally typically lack the executive-level security leadership required to meet PCI DSS v4.0 obligations. The solution is not additional audit services or technical consulting. It is strategic governance: someone with the authority to set policy, align cross-functional efforts, make risk decisions, and report to leadership in business terms.

If your organization needs clarity on accountability, current gaps, or how to establish adequate oversight without adding permanent headcount, a confidential consultation with Heights Consulting Group can provide that assessment. We offer this once, at the point where it is actually useful. Contact us to schedule a discussion.