The PCI Security Standards Council (SSC) recently published an information supplement on third-party security assurance that provides a set of guidelines for understanding how to manage third-party service provider (TPSP) relationships and PCI DSS compliance requirements. The guidance applies to entities who use or are considering the use of TPSPs and to the TPSPs themselves, who have access to, or can impact the security of cardholder data (CHD) or the cardholder data environment (CDE). The SSC defines an entity as any organization that has the responsibility to protect card data and may leverage a TPSP to support them in card-processing activities or to secure card data.
TPSPs are widely used in most industries. Some of the more prevalent services that are relevant to a CDE include payment gateways, payment processors, colocation services, cloud infrastructure, managed security services, encryption or tokenization services, application hosting, and managed firewall/router service providers. Relying on another party for services can enable an entity to focus on its core strengths, but it does not relieve an entity from the responsibilities for the security of CHD and the CDE.
"Establishing a relationship with any TPSP should start with a due diligence program"
Establishing a relationship with any TPSP should start with a due diligence program that includes determining the scope of the TPSPs involvement with storing, processing, or transmitting CHD and their impact on the security of the CDE. Understanding their involvement helps the entity frame due diligence requirements and risk assessment procedures in relation to the entity’s PCI DSS scope. Each entity must determine the appropriate due diligence process in light of its own CDE.
Understanding the TPSP’s involvement in relation to the entity’s PCI DSS scope provides the basis for determining which requirements the TPSP will be held responsible. Using a TPSP who has already achieved PCI DSS compliance through a separate validation assessment can help the entity’s own PCI validation assessment process. Even where validated TPSPs are used, the entity is still responsible for ensuring the scope of the TPSP’s separate validation assessment is commensurate with the scope of the requirements identified by the entity. BrightLine has seen multiple occurrences of gaps in expectations between the level of service performed by a provider and what that provider has been assessed against under PCI. An example would be where a data center provider performs colocation as well as managed services, yet their compliance reports only cover the physical colocation services.
The following are important areas to consider when engaging a TPSP:
- Set Expectations – Define, agree upon, and document expectations, at least annually and after a change in services.
- Gain Transparency to Scope – An organization should be able to take reasonable steps to determine that the scope of services provided are appropriate and aligned. Based on what the TPSP has claimed, consider having an ISA or QSA review any available evidence to verify the scope is indeed applicable, appropriate, and accurate.
- Establish Communications – Consider establishing a communications schedule whereby important matters are discussed. These items should include, but not be limited to, a discussion of significant changes to the CDE and important changes to personnel, processes, procedures, and methodologies that impact the CDE.
- Request Evidence – When changes are identified by the TPSP and the entity assesses the change as a significant risk, the entity may need to request evidence to verify that appropriate procedures were followed and controls deployed to support changes.
- Obtain Information about PCI DSS Compliance – Validation documentation should be provided at least annually as evidence of PCI DSS compliance. This information should cover the PCI relevant service(s) being delivered by the TPSP to the entity. Examples of appropriate validation documentation for the services being offered may include: Attestation of Compliance (AOC), Self-Assessment Questionnaire (SAQ) and AOC, ASV Scan Report Attestation of Scan Compliance (AOSC), and Payment Card Brand Validated Providers Lists and Websites.
It is recommended an entity perform a thorough risk assessment of any TPSP based on an industry-accepted methodology. Doing so will help an entity understand the risks associated with engaging the TPSP. The supplemental guideline provides TPSP relevant questions and topics to kick start the risk assessment process. The PCI DSS Risk Assessment Guidelines provide further information for conducting a risk assessment and can be referenced by entities looking for more detailed guidance in this process.
An important exercise before engaging with a TPSP is mapping out which PCI DSS requirements will be performed by the TPSP and which will be performed by the entity. A responsibility matrix can be useful to identify the responsibilities and requirements of each party. Appendix A of the information supplement includes high-level discussion points to assist entities and TPSPs determine responsibilities for each requirement. I highly recommend that entities and TPSPs consider utilizing the Appendix in their discussion of the requirements and responsibilities.
As part of the entity’s annual TPSP monitoring and review process, the entity should remember to develop a TPSP monitoring program. The supplemental guidelines provide excellent suggestions for developing the TPSP monitoring program, including information elements to include in the entity’s annual review of its service provider’s PCI DSS compliance. This can be a great resource to assist entities in meeting compliance with Requirement 12.8.1.
PCI DSS compliance is a continuous process, not just a point in time exercise. Developing a TPSP monitoring program is a critical requirement for any entity, especially with regard to managing risks associated with the security of cardholder data. Having a robust TPSP monitoring program can provide additional assurance that TPSP related risks are appropriately managed and that the responsibilities associated with securing CHD and the CDE are known, agreed to, and clearly defined.