Meeting PCI DSS Third-Party Service Provider Requirements

All third-party service providers with access to cardholder data – including shared hosting providers – must adhere to PCI DSS. Here’s an overview of the areas to assess now that version 4.0 is in force.
By:
Scott Lang
,
VP, Product Marketing
April 02, 2024
Share:
Blog pci march 2020

Originally developed in 2004 and now on version 4.0, the Payment Card Industry Data Security Standard (PCI DSS) aims to enhance cardholder data security and facilitate the broad adoption of consistent data security measures worldwide. The standard applies to all entities that store, process, or transmit cardholder data. With 12 requirements across six areas, the standard is designed to ensure that organizations have the proper controls and procedures in place to secure cardholder data.

Specific to third-party risk management, Requirement 12: Support Information Security with Organizational Policies and Programs, section 12.8: Risk to information assets associated with third-party service provider (TPSP) relationships is managed, indicates that third-party service providers (TPSPs) are responsible for ensuring that data is protected per the applicable PCI DSS requirements and that they are compliant. PCI defines third-party service providers as those entities to which organizations have outsourced::

  • their payment operations, or;
  • the management of systems (such as routers, firewalls, databases, physical security, and/or servers) that are involved in transmitting, housing, or protecting cardholder data.

Third-Party Service Provider Requirements in PCI DSS v4.0

The PCI standard requires organizations to manage their third-party service providers (TPSPs), including:

  • Performing due diligence on third-party service provider data security controls and practices
  • Having appropriate third-party service provider agreements in place to enforce controls
  • Identifying which third-party data security controls and requirements apply
  • Monitoring the compliance of third-party service providers at least annually

It is important to note that TPSPs are responsible for demonstrating their PCI DSS compliance as requested by organizations. The standard says that there are two (2) primary ways to validate compliance, including:

  • Annual assessments: The TPSP undergoes an annual PCI DSS assessment and provides evidence to its customers to show that the TPSP meets the applicable PCI DSS requirements.
  • Multiple, on-demand assessments: If a TPSP does not undergo an annual PCI DSS assessment, it must undergo assessments upon request of its customers and/or participate in each of its customers’ PCI DSS assessments, with the results of each review provided to the respective customer(s).

Bottom line: The underlying requirements for third-party service provider management include assessing and continuously monitoring TPSPs.

While PCI DSS does not have legal authority, and compliance does not ensure against data breaches, it is mandatory for any business processing credit or debit card transactions.

Uncover Key TPRM Requirements in PCI DSS

A Checklist for Compliance: PCI DSS 4.0 and Third-Party Service Provider Management examines service provider requirements in PCI DSS v4.0 and offers recommendations for compliance.

Read Now
Featured resource pci checklist

PCI DSS Requirements

Please see the list below for a summary of the third-party-related PCI DSS guidance, and best practices for addressing these requirements. For the purposes of this blog (and considering the breadth of the PCI standard) only requirement 12.8 is reviewed.

Please be sure to review the entire PCI DSS standard to determine how each requirement applies to your business.

Requirement 12.8

Risk to information assets associated with third-party service provider (TPSP) relationships is managed.

12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.

Build comprehensive third-party service provider profiles that include vendor firmographic details, geographic location, fourth-party technologies in use, and recent operational and financial insights. Start by importing third-party service providers into a central management system via a spreadsheet template or through an API connection to an existing procurement or vendor management solution, eliminating error-prone, manual processes. Then, provide a simple intake form to all stakeholders responsible for managing third parties so that all have input to a centralized third-party profile. This should be available to everyone via email invitation, without requiring any training or solution expertise.

12.8.2 Written agreements with TPSPs are maintained as follows:

  • Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
  • Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.

Centralize the distribution, discussion, retention, and review of vendor contracts to automate the contract lifecycle and ensure key clauses are enforced.

  • Centrally track all contracts and contract attributes such as type, key dates, value, reminders, and status – with customized, role-based views
  • Use workflow (based on user or contract type) to automate the contract management lifecycle
  • Automate reminders and overdue notices to streamline contract reviews
  • Centralize contract discussion and comment tracking
  • Store contracts and documents with role-based permissions and audit trails of all access
  • Enable version control tracking that supports offline contract and document edits
  • Leverage role-based permissions that enable allocation of duties, access to contracts, and read/write/ modify access

With this capability, you can ensure clear responsibilities and right-to-audit clauses are articulated in the vendor contract, and SLAs tracked and managed accordingly.

12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.

Start by quantifying inherent risks for all third parties. Criteria used to calculate inherent risk for third-party prioritization includes:

  • Type of content required to validate controls
  • Criticality to business performance and operations
  • Location(s) and related legal or regulatory considerations
  • Level of reliance on fourth parties
  • Exposure to operational or client-facing processes
  • Interaction with protected data
  • Financial status and health
  • Reputation

From this inherent risk assessment, your team can automatically tier suppliers; set appropriate levels of further diligence; and determine the scope of ongoing assessments.

Rule-based tiering logic enables vendor categorization using a range of data interaction, financial, regulatory, and reputational considerations.

12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.

Look for solutions that feature a large library of pre-built templates for third-party risk assessments – including those specifically built around PCI. Assessments can be conducted at the time of supplier onboarding, contract renewal, or at any required frequency (e.g., quarterly, or annually) depending on material changes in the relationship.

Assessments are managed centrally and backed by workflow, task management, and automated evidence review capabilities to ensure that your team has visibility into third-party risks throughout the relationship lifecycle.

Importantly, include built-in remediation recommendations based on risk assessment results to ensure that your third parties address risks in a timely and satisfactory manner and can provide the appropriate evidence to auditors.

As part of this process, continuously track and analyze external threats to third parties. Monitor the Internet and dark web for cyber threats and vulnerabilities, as well as public and private sources of reputational, sanctions, and financial information. All monitoring data should be correlated with assessment results and centralized in a unified risk register for each vendor, streamlining risk review, reporting, remediation, and response initiatives.

The Prevalent Difference

The Prevalent Third-Party Risk Management Platform can help organizations address the third-party service provider requirements published in the PCI standard by:

  • Providing a central platform to automate the onboarding, inventory, and management of all third-party service providers.
  • Building a comprehensive third-party service provider profile for all internal stakeholders that includes continuously updated cyber, business, financial, compliance, and reputational insights.
  • Centralizing the distribution, discussion, retention, and review of third-party service provider contracts to ensure that key security requirements are included, agreed upon, and enforced with key performance indicators (KPIs).
  • Gauging inherent risk to inform third-party service provider profiling, tiering, and categorization – and determining the appropriate scope and frequency of ongoing due diligence activities.
  • Automating risk assessments and remediation across every stage of the third-party service provider lifecycle.
  • Continuously tracking and analyzing external threats to third-party service providers by monitoring the Internet and dark web for cyber threats and vulnerabilities.
  • Simplifying PCI audit reporting with centralized assessments, monitoring, and evidence management.

For more on how Prevalent can help simplify third-party service provider management under PCI DSS, request a demonstration today.

Tags:
Share:
Leadership scott lang
Scott Lang
VP, Product Marketing

Scott Lang has 25 years of experience in security, currently guiding the product marketing strategy for Prevalent’s third-party risk management solutions where he is responsible for product content, launches, messaging and enablement. Prior to joining Prevalent, Scott was senior director of product marketing at privileged access management leader BeyondTrust, and before that director of security solution marketing at Dell, formerly Quest Software.

  • Ready for a demo?
  • Schedule a free personalized solution demonstration to see if Prevalent is a fit for you.
  • Request a Demo