Given the operational efficiency and low overhead cost, collaboration with a Vendor Third Party for the processing of online payments is very common. However, like a double-edged sword, outsourcing business operations and services can be a huge risk for Merchants dealing with them. One of the major risks that merchants often deal with Vendor Third Party collaboration is the online payment card-related cybercrimes.
Ensuring implementation of high-level security standards and compliance with PCI DSS from the vendor can be challenging. Typically for large business and enterprises, incurring the heavy cost of PCI DSS comprehensive implementation and ongoing compliance is not a big deal, but for smaller business such as Independent Service Organizations or Third Party Service providers, mostly with a staff strength of 50-100 people, it gets very difficult and expensive to maintain such ongoing expenses. This is when Vendor Third-Party Risk Management plays a key role in minimizing risks.
Explaining what Vendor Third-Party Risk Management is all about in this blog, we have also shared details on the PCI DSS Requirement 12 on Vendor Third-Party Risk Management. But let us first understand who is a vendor third party in the payment card industry.
Who is a Vendor Third Party?
In the payment card industry, a vendor third party is any service provider or vendor who stores, processes or transmits cardholder data (CHD) on behalf of the merchant. Since they have access to sensitive card data their operations have a direct security impact on the cardholder data environment (CDE). For those reasons, merchants need to evaluate their risk before proceeding with any vendor for business collaboration. Merchants need to have in place a vendor third-party risk management to mitigate risk and ensure compliance. So, now that we know who is a vendor, let us further move on to understand about vendor third party risk management.
What is Vendor Third-Party Risk Management?
Vendor Third-party Risk Management (VTPRM) is a risk management process that specifically focuses on identifying and mitigating risks concerning vendors that businesses collaborate with for outsourced services. It is a process of evaluating the vendors and service providers, to determine the risk exposure and the security measures that they have in place. It is an essential and integral process in various compliance and cyber security programs. Specifically, in PCI DSS, merchants are expected to have in place vendor third-party risk management programs to track and monitor all their vendors and service providers dealing with sensitive card data. Further, as per PCI DSS requirements, vendors are also expected to ensure compliance with the payment security standard.
That said, it is also important to note that Vendor Third-party Risk Management is confused and interchangeably used with Third-party Risk Management programs. However, they are two different programs wherein Vendor Third-party Risk Management just focuses on vendors and service providers whereas Third-party Risk Management encompasses evaluating all types of third parties. The scope of the Vendor Third-party Risk Management program greatly depends on the organization, its industry, and the regulatory and compliance requirements. But in general Vendor Third-Party, Risk Management is seen as a best practice in cyber security and compliance programs including PCI DSS.
What does PCI DSS say about Vendor Third-Party Risk Management?
PCI DSS Compliance applies to any organization that deals with card data, be it processing, storing, or transmitting card data. In that sense, PCI DSS applies to vendor third party and service providers offering outsourced services. So, organizations that have outsourced their payment operations, system management, and data processing services are required to also ensure that vendors are compliant with PCI DSS requirements.
PCI Council in its PCI DSS requirement 12.8 requires merchants to manage their third-party vendors. The requirement focuses on vendor management and also mandates organizations develop and execute policies and processes to manage vendors and service providers having access to cardholder data. The below-given table explains the PCI DSS 12.8 Requirement concerning vendor management briefly. These are requirements which are additionally applicable to Third Party vendors. So, these are not the only requirements but are required additionally.
| PCI DSS v3.2.1 | PCI DSS v4.0 | |
|---|---|---|
| Requirement and Testing Procedures | 3.2.a Review policies and interview staff at issuing entities to confirm justified storage of sensitive authentication data. 3.2.b Inspect data storage and system setups at issuing entities to ensure sensitive authentication data security. | 3.3.3 Issuers storing sensitive authentication data should limit storage to business needs, ensure security, and use strong encryption. 3.3.3.a Review policies and interview staff at issuing entities to confirm justified storage of sensitive authentication data. 3.3.3.b Inspect data storage and system setups at issuing entities to ensure sensitive authentication data security. |
| Requirement and Testing Procedures | 3.1 Minimize cardholder data storage by implementing policies, procedures, and processes for data retention and disposal. This includes: Storing only the minimum data required for legal, regulatory, and business needs Having specific retention periods for cardholder data Securely deleting unneeded data Quarterly identifying and deleting stored cardholder data exceeding defined retention periods. 3.1.a Confirm CHD storage policies for data retention and disposal. Ensure data storage and retention align with legal, regulatory, and business needs. Review specific cardholder data retention requirements. Verify secure data deletion processes. Validate quarterly process for deleting excess stored cardholder data. 3.1.b Interview staff to confirm: All cardholder data locations are in the data retention and disposal processes. A quarterly process exists to delete stored cardholder data. The quarterly process is performed for all cardholder data locations. 3.1.c For selected system components storing cardholder data: Check files and system records to ensure stored data doesn’t exceed policy requirements. Monitor the deletion mechanism to confirm secure data deletion. | 3.1.2 Understand and assign roles for Requirement 3 activities. 3.1.2.a Confirm assignment of roles for Requirement 3 activities through documentation review. 3.1.2.b Ensure understanding and assignment of roles for Requirement 3 activities through personnel interviews. 3.2.1 Implement minimal account data storage policies. Cover all stored account data locations. Protect sensitive authentication data before authorization. Restrict data storage and retention to legal, regulatory, and business needs. Define account data retention requirements with business justification. Establish secure deletion processes for unneeded account data. Perform quarterly checks to delete or render unrecoverable excess data. 3.2.1.a Review policies and interview staff to confirm process compliance. 3.2.1.b Verify policy compliance of data storage and retention in system components. 3.2.1.c Ensure data recovery is impossible through mechanism observation. 3.3.2 Before authorization, SAD is encrypted electronically. Confirm this by examining data stores, system settings, and vendor documents. |
| Requirement and Testing Procedures | 3.3 Display PAN masked (only the first six and last four digits), visible in full only to personnel with a legitimate business need. 3.3.a Review policies and procedures for PAN masking to verify: Roles needing access to more than the first six/last four digits of the PAN are documented with a legitimate business need. PAN is masked when displayed, visible in full only to authorized personnel. Unauthorized roles see only masked PANs. 3.3.b Check system configurations to ensure that full PAN is displayed only for users/roles with a documented business need and masked for all other requests. 3.3 Display PAN masked (only the first six and last four digits), visible in full only to personnel with a legitimate business need. 3.3.a Review policies and procedures for PAN masking to verify: Roles needing access to more than the first six/last four digits of the PAN are documented with a legitimate business need. PAN is masked when displayed, visible in full only to authorized personnel. Unauthorized roles see only masked PANs. 3.3.b Check system configurations to ensure that full PAN is displayed only for users/roles with a documented business need and masked for all other requests. 3.3.c Check PAN displays to confirm that PANs are masked when displaying cardholder data, and only those with a legitimate business need can see more than the first six/last four digits of the PAN. | 3.4.1 Only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN, which are masked when displayed. 3.4.1.a Policies and procedures for PAN masking should be examined to verify: Roles needing access to more than the BIN and last four digits of the PAN are documented with a legitimate business need. PAN is masked when displayed, visible in full only to authorized personnel. Unauthorized roles see only masked PANs. 3.4.1.b System configurations should be checked to ensure that full PAN is displayed only for roles with a documented business need and masked for all other requests. This doesn’t override stricter requirements for cardholder data displays, such as legal or payment brand requirements for POS receipts. 3.4.1.c Displays of PAN should be examined to confirm that PANs are masked when displayed, and only those with a legitimate business need can see more than the BIN and/or last four digits of the PAN. |
| Requirement and Testing Procedures | 3.4 Make PAN unreadable wherever stored (including portable digital media, backup media, and logs) using methods like one-way hashes, truncation, index tokens and pads, or strong cryptography. 3.4.a Review system documentation to verify PAN is rendered unreadable using methods like one-way hashes, truncation, index tokens and pads, or strong cryptography. 3.4.b Check several tables or files from data repositories to confirm PAN is unreadable. 3.4.c Check a sample of removable media to ensure PAN is unreadable. 3.4.d Check a sample of audit logs to confirm PAN is unreadable or not present. 3.4.e If hashed and truncated PAN versions exist, verify controls prevent their correlation to reconstruct the original PAN. | 3.5.1 PAN is made unreadable using methods like one-way hashes, truncation, index tokens, or strong cryptography. If hashed and truncated versions of the same PAN exist, additional controls prevent correlation to reconstruct the original PAN. 3.5.1.a Review system documentation to verify PAN is rendered unreadable using specified methods. 3.5.1.b Check data repositories and audit logs to confirm PAN is unreadable. 3.5.1.c If hashed and truncated PAN versions exist, verify controls prevent their correlation to reconstruct the original PAN. |
| Requirement and Testing Procedures | 3.5.1 For service providers: Maintain a documented cryptographic architecture, including details of all algorithms, protocols, keys, their usage, and an inventory of Hardware Security Modules (HSMs) and other Secure Cryptographic Devices (SCDs) used for key management. Verify through interviews and document review that a cryptographic architecture description exists, including: Details of all algorithms, protocols, and keys used for cardholder data protection, including key strength and expiry date Key usage description for each key Inventory of HSMs and other SCDs used for key management. | 3.6.1.1 For service providers: Maintain a documented cryptographic architecture, including details of all algorithms, protocols, keys, their usage, and an inventory of Hardware Security Modules (HSMs), Key Management Systems (KMS), and other Secure Cryptographic Devices (SCDs). Prevent the use of identical keys in production and test environments. Verify the existence of this document through interviews and documentation review. Ensure it includes all specified elements. |
| Requirement and Testing Procedures | 12.3.10 For remote-access users, restrict data handling on local and removable media unless explicitly allowed. If allowed, ensure data protection as per PCI DSS Requirements. 12.3.10.a Confirm policies prohibit data handling on local and removable media during remote access. 12.3.10.b For authorized personnel, ensure policies require PCI DSS compliant data protection. | 3.4.2 With remote-access technologies, technical controls prevent PAN copying or relocation, except for authorized personnel with a legitimate business need. 3.4.2.a Review policies and evidence for technical controls that prevent PAN copying or relocation onto local or removable media. Verify that: Controls prevent unauthorized PAN copying or relocation. A list exists of authorized personnel to copy or relocate PAN. 3.4.2.b Check remote-access technology configurations to confirm controls prevent PAN copying or relocation, unless authorized. 3.4.2.c Through observation and interviews, confirm only authorized personnel with a legitimate business need can copy or relocate PAN. |
Final Thought
Due diligence, Documentation of compliance evidence, and monitoring vendor third party forms the fundamental pillars of Vendor Third-Party Risk Management. Ultimately Vendor Third-Party Risk Management is all about conducting the required due diligence, engaging with vendors ensuring complete accountability with documents of contracts, and agreements, in place, and monitoring them from time to time. Ensuring vendors meet the PCI DSS requirements is one way of ensuring they have taken measures to safeguard customer card data.
Narendra Sahoo (PCI QPA, PCI QSA, PCI SSF ASSESSOR, CISSP, CISA, CRISC, 27001 LA) is the Founder and Director of VISTA InfoSec, a global Information Security Consulting firm, based in the US, Singapore & India. Mr. Sahoo holds more than 25 years of experience in the IT Industry, with expertise in Information Risk Consulting, Assessment, & Compliance services. VISTA InfoSec specializes in Information Security audit, consulting and certification services which include GDPR, HIPAA, CCPA, NESA, MAS-TRM, PCI DSS Compliance & Audit, PCI PIN, SOC2 Compliance & Audit, PDPA, PDPB to name a few. The company has for years (since 2004) worked with organizations across the globe to address the Regulatory and Information Security challenges in their industry. VISTA InfoSec has been instrumental in helping top multinational companies achieve compliance and secure their IT infrastructure.
