Tokenization is a popular way for merchants to reduce their PCI compliance scope. When they process, store, or transmit cardholder data on their own systems, any part of their infrastructure that touches that data needs to be included in (in scope for) their annual security audit. However, if they tokenize that data and store the random, unrelated token on their system instead, they can reduce the number of components that are in scope, potentially qualifying for a shorter and easier self-assessment questionnaire.
How Does Tokenization Reduce PCI Scope?
Here’s how Jonathan Paolozzi, SEC+, eJPT, Curbstone’s head of cybersecurity explains it:
Payment tokens replace primary account numbers during credit and debit card transactions, limiting the cardholder data environment. Sensitive data is confined to a few specific areas – including, for instance, the EMV terminal where the card is first run or the iFrame where the customer originally enters their information. If the initial entry method can pass the sensitive cardholder data directly to the tokenization service without sending it through the merchant’s own infrastructure, then that cardholder data environment is limited to the initial point of entry and the tokenization system. The merchant is responsible for securing their components, but the tokenization provider is responsible for the data while in transit and while in their vault – eliminating most, if not all, of the security and compliance burden for the merchant.
PCI DSS Tokenization Guidelines
For this approach to be successful, the merchant must use a third-party credit card tokenization solution that is designed and implemented in a way that meets the requirements of the PCI DSS. For instance, the Payment Card Industry specifically requires that:
- Primary account numbers are not retrievable from any component that has been taken out of scope
- Only authorized users, applications, and systems should be able to retrieve the PAN for the associated payment token
- Communications between the requesting application and tokenization system are fully secured
- Any system that can access PAN data or exchange it for a token must be in a PCI-compliant environment
- The tokenization system must be adequately segmented from all networks that are not in scope for PCI
- The data vault itself must meet or exceed PCI DSS requirements
As best practice, merchants should replace cardholder data on their system with tokens wherever they can. They can then reference these tokens as “cards on file” for future transactions. As Paolozzi explains it:
Even with tokenization, missteps in implementation can leave merchants out of PCI compliance. If card data flows through the merchant’s systems before tokenization, those systems stay in scope. Inadequate network segmentation or using an unvalidated tokenization provider can also expose merchants to compliance risk. To truly reduce scope, data must pass directly from the customer to the tokenization service, with no stops in between.
Choosing a PCI-Compliant Tokenization Service Provider (TSP)
Tokenization solutions will always be “in scope” for PCI compliance – whether they’re operated by a third-party tokenization service provider (TSP) or self-managed by the merchant.
The audit burden for an outsourced solution, however, falls on the TSP – not the merchant. And, because all tokenization service providers are considered Level 1 service providers – the highest possible level – those requirements are considerable.
To find solutions that have been recently validated by a Qualified Security Assessor, merchants can search the PCI vendor directory here.
When auditing a payment card tokenization solution for PCI compliance, a QSA confirms that it:
- Validates the identity of all users before granting access
- Tracks and logs all access to – and actions taken within – the system
- Enforces strong data security protocols during transmission and storage
- Provides a mechanism for deleting cardholder data on request
The service provider must also meet other requirements related to their technical and operational security. For instance, the assessor will review the provider’s firewall configurations, password requirements, data retention and disposal policies, masking policies, encryption methods, access restriction policies, and internal testing methods. If all policies and procedures meet the Payment Card Industry’s requirements, the auditor will issue a document called an Attestation of Compliance (AOC), which the TSP will then submit to the card brands.
Do Merchants who Use Payment Tokenization Still Have to Complete Their Own Security Audits?
It’s important to note that even using an outsourced, PCI-compliant tokenization system is not enough for a merchant to completely meet their own security requirements. They still need to complete an annual self-assessment questionnaire and submit it to the card brands to keep their merchant account in good standing. They also need to complete quarterly vulnerability scans (not to be confused with penetration tests) and maintain a documented incident response plan to maintain their compliance. However, this is much easier to accomplish when fewer parts of their environment are considered “in scope.” The shortest, least complicated SAQ (the SAQ-A) can often be completed in a matter of days; in contrast, the longest SAQ-D may require several weeks of dedicated effort. This can be extremely challenging for any business, but especially smaller organizations without full-time compliance resources.
See How Tokenization Can Simplify Your PCI Compliance Efforts
Ready for an easier approach to credit card security and PCI compliance? Contact Curbstone; we’ll help you determine which parts of your environment tokenization can help you take out of scope for PCI reporting and audits.
