LBMC is a proud PCI Qualified Security Assessor Company and has been a part of the PCI compliance community since the inception of the PCI Data Security Standard (PCI DSS). Our team of skilled and experienced QSAs have conducted assessments and consulting engagements for both merchants and service providers of all sizes across all major industries. 

The QSA Perspective Series is a six-part blog series sharing our perspective on understanding, interpreting, and applying the PCI DSS. The series topics will include:

  • The Cardholder Data Environment
  • Connected-To / Security Impacting Systems
  • Network and Dataflow Diagrams
  • Service Providers and Nested Third Parties
  • Cloud Auditing – Is it really that different?
  • Cloud Auditing – AWS, Azure, Clients – Who is responsible for what?

The goal of the series is to share knowledge and provide our perspective on the fundamentals of compliance and how these fundamentals can be applied to help entities achieve and maintain PCI DSS compliance. It is our hope that this series provides valuable insight into how QSAs interpret the PCI DSS and approach compliance assessments.

Cardholder Data Environment

To successfully plan, conduct, and complete an assessment, it is essential to accurately define the scope of compliance. This scope, in PCI parlance, is called the Cardholder Data Environment. The PCI Security Standards Council has established that it is the entity’s responsibility to define their Cardholder Data Environment, or CDE, so that the PCI control requirements can be properly applied and successfully assessed. Though simple in concept, accurately defining the CDE is most often the greatest challenge to an entity seeking compliance as well as to assessors. This is why scope validation is among the very first activities conducted in an assessment. Without a properly defined CDE, the boundaries of the assessment cannot be established and, therefore, there can be no confidence that the assessment has included all relevant card payment operations and components. Unfortunately, many assessments, particularly for entities pursuing their initial attestation, are negatively impacted because the CDE has not been defined correctly.

So, what does the PCI DSS have to say about defining the CDE? Very simply, it states that “the CDE is comprised of people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.” While a simple statement, it nevertheless leaves room for misinterpretation. Cardholder data, or CHD, consists of the full Primary Account Number, or PAN, which is the 16-digit string found on the front or back of your credit card, the cardholder’s name, expiration date, and/or service code. The service code is generally encoded into the magnetic stripe and should not be confused with the card’s security code, which is the 3- or 4-digit code often printed on the back of the card. While all of these values are considered CHD, the PCI DSS considers the PAN “the defining factor for cardholder data.” If the full PAN is not present, then the other elements are not considered CHD. You read that right; even if the cardholder’s name, expiration date and/or service code are present, if the full PAN is not included, then you do not have cardholder data. Conversely, if the full PAN is accompanied by the name, expiration date and/or service code, then all those elements are considered CHD to be secured in accordance with the PCI DSS. By the way, you may have picked up on the term full PAN in these definitions. If no more than the first 6 and last 4 digits of the PAN are present, that is not considered the PAN. Any more than that is considered the equivalent of the full PAN.

Sensitive Authentication Data, or SAD is the card’s security-related information including full track data (encoded on the magnetic stripe or chip), card security code, PINs, and PIN blocks. These elements are used to authenticate cardholders and/or authorize payment card transactions.

The point of beginning with these definitions is that they are the foundational elements for determining an entity’s scope of PCI compliance. The entity and their assessor must identify all instances of cardholder data to be able to define and validate the cardholder data environment. Now, recall that the PCI Council also established that the CDE is comprised of people, processes and technology. This means that it’s not just computer systems and networks to be considered in scope, but also the people that interact with CHD and the processes and technologies, whether manual or automated, that these people use to facilitate credit card payments and all associated activities. It is an essential exercise in defining the CDE to interview people, observe their processes, and include each in the assessment. Although an entity may have any number of people and processes in their CDE, here are just a few common examples:

  • Customer Service Agents
  • Retail Store Associates
  • Accounting Department Personnel
  • Mailroom Personnel
  • IT Systems Administrators
  • Software Developers
  • Database Administrators

Here are some common processes these people (or the systems they administer) may conduct:

  • Customer service agents taking payments over the phone
  • Retail cashiers swiping cards through payment terminals
  • Accounting support staff processing refunds and chargebacks
  • Mailroom staff scanning written payment slips
  • Systems administrators installing point-of-sale systems
  • Software developers creating APIs for web-based payments
  • Database administrators querying payment data tables

And, finally, the technologies used in these processes may include:

  • Voice-over-IP phone systems
  • Call recording software
  • Point-of-sale systems and external payment terminals
  • Cloud-based Software-as-a-Service applications
  • Printers and scanners
  • Various server platforms e.g., file, database, mainframe, etc.
  • Network switches and routers

Now, you might be thinking, “This is all good information, but isn’t it the assessor’s job to define this scope for me?” As a matter of fact, the PCI DSS clearly establishes the shared nature of determining that the CDE is been accurately defined. According to the PCI DSS,

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope. The entity retains documentation that shows how PCI DSS scope was determined. The documentation is retained for assessor review and/or for reference during the next annual PCI DSS scope confirmation activity. For each PCI DSS assessment, the assessor is required to validate that the scope of the assessment is accurately defined and documented.”

In short, the entity is responsible for identifying the CDE and determining their scope of compliance, and the assessor’s role is to validate what the entity determines. Together the two parties arrive at an accurately defined CDE before beginning the assessment.

Common Errors in PCI DSS Scoping

It bears repeating that, although simple in concept, accurately defining the CDE is most often the greatest compliance challenge. Here are some common errors entities, and even assessors, make when defining and validating the CDE and scope of compliance:

  • Omitting non-standard or support processes (e.g., mailroom, accounting) from scope.
  • Overlooking locations such as storage closets or offsite records facilities where hardcopy cardholder data is stored.
  • Excluding third parties involved in accepting payments or administering systems.
  • Assuming encrypted data is out of scope (even encrypted data is cardholder data).
  • Using incorrect and/or incomplete network and data flow diagrams to represent the CDE.
  • Maintaining incomplete inventories of all systems that store, process, or transmit cardholder data.

Conclusion

You may recall the old data processing adage, garbage in, garbage out. It applies to defining an entity’s CDE for assessing PCI compliance as well. If an entity’s CDE is not accurately defined, then the results of the assessment will not be accurate. Entities and their assessors are responsible for understanding what qualifies and cardholder data and then carefully and methodically identifying all people, processes, and technologies involved in payment processes. In the next entry in this series, we will consider another element of the PCI DSS’s scoping criteria: connected-to and security-impacting systems.