How to Secure Your CDE and Achieve PCI DSS Compliance

Successfully securing cardholder data should be top of mind as businesses try to keep up with the rise of data regulations and the resulting increased focus on consumer privacy. The process of securing a cardholder data environment (CDE) and ensuring it is compliant with the Payment Card Industry Data Security Standard (PCI DSS) can be stressful, confusing, and potentially expensive, as maintaining compliance can sometimes call for unexpected resources.

This blog will cover common questions regarding how to secure the systems where organizations store PCI (CDE) to achieve PCI DSS compliance. This should provide a starting point that informs your decision-making process, empowering you to construct a plan to protect CDEs and obtain PCI DSS compliance without breaking the bank or losing customer loyalty due to ineffective security measures.

First, we need to understand what Payment Card Information (PCI) data refers to. PCI data is considered all information stored on and in credit, debit, or prepaid cards issued by one of the five card brands that form the Payment Card Industry Security Standards Council (PCI SSC)–American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc. The PCI DSS divides PCI data into two categories:

The PCI SSC defines cardholder data as the primary account number (PAN) by itself or the PAN in addition to any of the following card information:

• Cardholder name
• Expiration date
• Service code

Magnetic-stripe data

Data elements on a card’s magnetic stripe that use secure cryptographic processes to protect data integrity on the stripe and reveal any alteration or counterfeiting. Terms for this vary by card brand and are listed below:

• Card authentication value (CAV) is used by JCB payment cards.
• Card validation code (PAN CVC) is used by MasterCard payment cards.
• Card verification value (CVV) is used by Visa and Discover payment cards.
• Card security code (CSC) is used by American Express payment cards.

Printed security features

The three-digit value printed in the signature panel area on the back of Discover, JCB, MasterCard, and Visa payment cards, as well as the four-digit unembossed number printed above the PAN on the face of American Express payment cards, is uniquely associated with each physical card and ties the PAN to plastic. The terms for this vary by card brand and are listed below:

• Card identification number (CID) is used by American Express and Discover payment cards.
• Card authentication value 2 (CAV2) is used by JCB payment cards.
• Card validation code 2 (PAN CVC2) is used by MasterCard payment cards.
• Card verification value 2 (CVV2) is used by Visa payment cards.

The CDE is composed of the people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data. This includes all entities that handle or have access to cardholder data in an organization, and it also applies to third parties, such as service providers and other vendors, that interact with the organization’s cardholder data or CDE. The PCI DSS includes specific requirements for securing electronic payment and authentication data residing on all physical and virtual components in a CDE, such as:

• Network components including firewalls, switches, routers, access points, network appliances, and security appliances
• Point-of-sale (POS) systems including payment terminals, cash registers, card readers, or any other system that processes PCI data from a customer
• Servers including web servers, application servers, database servers, authentication servers, mail servers, proxy servers, network time protocol servers, and domain name servers
• All internal and external applications
• Virtual components including virtual machines, virtual switches, virtual routers, virtual appliances, virtual applications, virtual desktops, and hypervisors
• Third-party IT systems

The PCI SSC established the PCI DSS to help ensure that proper protection of customer cardholder data was a priority for organizations. There are 12 requirements laid out in the PCI DSS. These PCI compliance requirements fall under six overarching categories that provide an overview of the security controls necessary for PCI compliance. Some of these requirements provide specific instructions directing organizations on steps to take to protect their CDE. For a more in-depth look at PCI compliance requirements, see our PCI compliance solutions page or download our free PCI DSS Compliance Guide.

The PCI DSS dictates different compliance levels depending on the number of transactions an organization is conducting per year. Also, the size and scope of a CDE directly affect how much risk an organization is responsible for regarding a data breach. The larger the CDE, the more assets there are to fall under the PCI CDE scope of compliance for PCI DSS and will, therefore, need to be secured. You can find more information about the different levels of compliance on our PCI compliance solutions page.

The process for securing and self-maintaining a fully compliant CDE is no easy task and requires a unique skill set to be successful. It can take ample resources and time that some organizations simply cannot afford as it distracts from their main business objectives. However, there are external options available for securing sensitive data within your CDE that allow organizations to focus on their business and have peace of mind regarding achieving and maintaining PCI DSS compliance. For many organizations, outsourcing this process is a more secure and cost-effective solution for their compliance needs.

IXOPAY is an Oklahoma-based, PCI-compliant data security company that specializes in protecting sensitive data to strengthen our clients’ security postures while future-proofing their operations. Founded by two former Qualified Security Assessors (QSAs), IXOPAY was built to be a resilient and adaptable security solution that supports improved business outcomes.

Our tokenization platform allows us to protect clients’ sensitive data by removing it from their environments and exchanging it for nonsensitive data called “tokens.” Sensitive data can be captured via a secure API call or batch file whose contents can then be tokenized and returned to the client for use within its CDE–”or any other database or internal system–without bringing it into PCI DSS compliance scope.

Learn more about the tokenization process as a whole and learn what IXOPAY can offer businesses looking to secure their CDE while maintaining PCI DSS compliance.