In a PCI DSS audit, all systems, applications, and processes that have access to credit card information—whether encrypted or unencrypted—are considered in scope.

Editor's Note: This article is an extract of the white paper Six Ways to Reduce PCI DSS Audit Scope by Tokenizing Cardholder Data available free from the MC White Paper Center.

Enterprises are seeking ways to simplify and reduce the scope of the Payment Card Industry's Data Security Standard (PCI DSS) compliance by shrinking the footprint where cardholder data is located throughout their organizations. By reducing the scope, these enterprises can dramatically lower the cost and anxiety of PCI DSS compliance and significantly increase the chance of audit success.

Compliance with the PCI DSS is a combination of documented best practices and technology solutions that protect cardholder data across the enterprise. This white paper explores the use of tokenization as a best practice in improving the security of credit card transactions, while at the same time minimizing the cost and complexity of PCI DSS compliance by reducing audit scope.

What Is "In Scope?"

The scope of PCI DSS compliance for any organization is significant both in terms of effort and cost. In a PCI DSS audit, all systems, applications, and processes that have access to credit card information, whether encrypted or unencrypted, are considered in scope. The October 2008 update of the PCI DSS documentation (V1.2) states that companies can reduce the PCI DSS audit scope using network segmentation to isolate the cardholder data in a secure segment. From an application perspective, tokenization functions similarly to network segmentation. These are complementary, not "either/or" approaches for organizations to consider as they map out their data protection and compliance strategies.

Payment Card Industry Data Security Standard V1.2

"Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of the corporate network is not a PCI DSS requirement. However, it is recommended as a method that may reduce:

• The scope of the PCI DSS assessment
• The cost of the PCI DSS assessment
• The cost and difficulty of implementing and maintaining PCI DSS controls
• The risk to an organization (reduced by consolidating cardholder data into fewer, more controlled locations)

Without adequate network segmentation (sometimes called a flat network), the entire network is in scope of the PCI DSS assessment."

Tokenization Unwrapped

With traditional encryption, when a database or application needs to store sensitive data, those values are encrypted, and the resulting cipher text is returned to the original location. With tokenization, a token—or surrogate value—is returned and stored in place of the original data. The token is a reference to the actual cipher text, which is stored in a central data vault. Tokens can be safely used by any file, application, database, or backup medium throughout the organization, minimizing the risk of exposing the actual sensitive data, and allowing business and analytical applications to work without modification.

Organizations that must meet the requirements of PCI DSS are increasingly embracing the compliance benefits of tokenization. Let's take a look at requirement 3.1, which mandates that businesses keep payment data in a minimum number of locations. That is precisely what the tokenization model accomplishes. By using tokenization, businesses are reducing the number of locations where they are retaining cardholder information. Requirements 3.5.1 and 3.5.2 mandate that access to keys be restricted to the fewest number of custodians and that keys be stored securely in the fewest possible locations. With tokenization, encryption is performed centrally when credit card values are tokenized, and keys are centralized on a secure server, optimally addressing these requirements.

Want to learn more? Download the complete white paper Six Ways to Reduce PCI DSS Audit Scope by Tokenizing Cardholder Data from the MC White Paper Center.

as/400, os/400, iseries, system i, i5/os, ibm i, power systems, 6.1, 7.1, V7, V6R1