When an organization outsources services that touch payment card data, such as processing, storage, or transmission—the responsibility for data protection doesn't transfer. It remains with the organization. This makes third-party risk management (TPRM) a critical requirement for PCI DSS compliance and preventing data breaches.

The Payment Card Industry Data Security Standard (PCI DSS) is a globally recognized set of controls and testing procedures developed by the PCI Security Standards Council (PCI SSC) to protect cardholder data. This blog focuses on how third-party involvement impacts PCI DSS compliance, the new requirements under versions 4.0 and 4.0.1, and how organizations can avoid financial and reputational losses from third-party-induced breaches.

PCI DSS: Definition and Applicability

PCI DSS applies to any entity merchant, service provider, or third party—that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD).

Cardholder Data (CHD) includes:

1. Primary Account Number (PAN)

2. Cardholder Name

3. Expiration Date

4. Service Code

Sensitive Authentication Data (SAD) includes:

1. Full track data (from the magnetic stripe or chip)

2. Card verification codes (CAV2, CVC2, CVV2, CID)

3. PINs and PIN blocks

Even if an entity does not store PAN, specific PCI DSS requirements may still apply if:

1. The entity transmits or processes card data.

2. A third party handles any part of the CHD or SAD.

3. The entity's systems can impact the security of a Cardholder Data Environment (CDE).

Why Third-Party Risk Matters in PCI DSS

Third-party vendors often have direct or indirect access to cardholder data or the systems that process, transmit, or store it, making them attractive targets for cyber attackers. According to IBM's 2023 Cost of a Data Breach Report, third-party involvement accounted for over 60% of breaches in the payment ecosystem, with an average breach cost of $4.76 million.

Attackers exploit weak links in the supply chain to bypass primary defenses. As a result, organizations that fail to evaluate and manage third-party risk face exposure to:

1. Regulatory fines for non-compliance

2. Operational disruptions

3. Irreversible reputational damage

PCI DSS version 4.0 addresses these challenges by embedding third-party risk governance within its core structure.

PCI DSS Controls Addressing Third-Party Risk

PCI DSS v4.0 introduces a comprehensive set of controls related to third-party risk under Requirement 12. These controls require entities to ensure that their vendors and partners maintain security practices that align with PCI DSS principles.

Requirement 12: Support Information Security with Organizational Policies and Programs

12.8—Maintain and enforce policies and procedures to manage service providers: Organizations must document and maintain a list of all third-party service providers. Based on the nature of the service provided, each provider must be evaluated for its ability to comply with applicable PCI DSS requirements. This also includes determining whether the service provider stores, processes, or transmits cardholder data or can affect the security of the CDE.

12.8.1 – Maintain a list of service providers: The list must be kept up to date and include contact information, a description of services provided, and identification of access levels to systems or data. Documentation should also specify which PCI DSS requirements apply to each service provider.

12.8.2—Maintain written agreements with security requirements: Written contracts must explicitly outline information security responsibilities, including breach reporting timelines, access restrictions, and assurance of compliance with applicable PCI DSS controls. This control ensures that legal accountability is clearly defined between the customer and the third party.

12.8.3—Acknowledge responsibilities for PCI DSS compliance: Each third party must formally acknowledge, in writing, its obligations under PCI DSS. This includes recognizing its responsibility for protecting cardholder data and agreeing to fulfill applicable security controls, which can be validated through an Attestation of Compliance (AOC).

12.8.4 – Monitor service provider PCI DSS compliance annually: Organizations must establish a process to assess each service provider's PCI DSS compliance periodically. This can include requesting ROCs or AOCs, performing onsite audits, or reviewing the results of independent assessments. Monitoring activities must be documented and repeated at least annually.

12.8.5 – Define responsibility assignments: Organizations must maintain a responsibility matrix that allocates which PCI DSS controls are the responsibility of the customer, the service provider, or shared between both. This documentation should be regularly updated and reviewed during assessments.

12.9.2 – Support customer compliance efforts: Service providers must provide information necessary to assist customers in demonstrating compliance. This includes supplying audit documentation, facilitating interviews, and enabling access to systems during assessments.

These controls build a framework where shared responsibility, transparency, and continuous evaluation are essential to safeguarding the cardholder data environment.

What Changed in PCI DSS v4.0.1?

PCI DSS v4.0.1 introduced updates to clarify language, enhance implementation guidance, and adjust requirements based on industry feedback. While the structural requirements remained essentially unchanged, the updates include:

1. Clarified Shared Responsibility: There is additional emphasis on documenting and validating shared control environments between organizations and third parties.

2. Enhanced Definitions: New terms such as "Phishing-Resistant Authentication," "Legal Exception," and "Visitor" were added to clarify and align with evolving security terminology.

3. Revised Patch Management Criteria: Requirement 6.3.3 now focuses on patching timelines for critical vulnerabilities rather than including critical and high ones.

4. Updated Requirements for Cryptographic Key Protection: Requirement 3.5.1.1 now includes updated guidance for keyed hashes and custom approaches.

5. Improved Supporting Templates: The appendices were expanded to include sample templates and examples of customized approaches, which help organizations meet requirements in unique environments.

These clarifications further reinforce the importance of ensuring third-party accountability through clear contracts, thorough documentation, and regular compliance validation.

How Genesis Platform Helps You Comply with PCI DSS 

Genesis Platform enables organizations to align their third-party risk workflows with PCI DSS controls. While the responsibility for compliance remains with the organization, Genesis supports this by:

1. Maintaining a centralized and updated vendor inventory with risk classifications.

2. Mapping vendors to applicable PCI DSS requirements and tracking AOC/ROC submissions.

3. Offering templated responsibility matrices for quick compliance role allocation.

4. Supporting storage of written agreements and compliance evidence for auditing.

Genesis reduces manual effort and improves visibility into vendor-related compliance gaps, ensuring alignment with PCI DSS Requirement 12 series obligations.