Customer Data Security Part 2: What You Need to Know about PCI Compliance

person holding credit card


[Estimated read time: 10 minutes]

In part one of our series, we discussed common themes among consumer privacy regulations. In this article, we are taking a look at regulations that have unique characteristics due to their focus on a particular industry sector.

We’ll use the example of PCI DSS, or the Payment Card Industry Data Security Standard. Many of the requirements for PCI DSS fall into some the patterns we discussed in our previous article. But what is notable in this case is the increased focus on a very specific type or class of information: The information required to execute a credit card transaction and access to any related financial records.

What to Expect from PCI DSS

There are some unique aspects of this regulation, beyond what one would expect to see in a privacy compliance regulation.

The first item to consider is that PCI DSS is focused on financial information, specifically data related to credit card transactions and accounts. In this way, it differs from an “umbrella” privacy regulation that would take into account many types of information about a consumer.

Secondly, this category of information is held to a higher standard of privacy control by most regulatory bodies throughout the world. For example, many other privacy regulations restrict the movement of financial data, medical records, national ID’s and, in a number of cases, political and religious affiliations. This is more of a nuance, but the overlap is notable.

Lastly, an individual’s personal identifiers such as credit card numbers, expiration dates, and CVC codes are clearly considered sensitive. However, there are other aspects of one’s identification that may not be as clear to a compliance professional. At issue are the peripheral data elements that help to identify the account holder and the related card’s transactional records to which they are attached. A similar example of extended data utilized for identification can be found in HIPAA-regulated industries. This would include the date of birth, address, etc.

As you’ve probably experienced yourself, it is not unusual for a company to request additional identifying information to confirm that they are working with the actual data subject in question. For example, you may be asked to verify your address when you call your credit card provider for help. This practice has expanded over time in an effort to combat fraud, but the net effect to a business serving consumers is that you have to store that data to use it as a confirmation — adding to the amount of data that you’ll now need to secure.

In each example above, we have what is called Personally Identifiable Information (PII). This is a broader concept and includes information like Social Security Numbers or National ID numbers of any sort, but also things like date of birth, address, customer ID’s and PIN numbers. Again, if you’ve called your credit card company’s customer service line or had a prescription filled recently, you have a good idea about the types of data they use to identify you.

Key Elements of PCI DSS

PCI DSS has evolved over the years, and there have been a number of improvements made to keep the program current and easier to implement. It’s important to understand the essentials of this compliance program if your organization is required to participate. At an extremely high level, some of the key elements are:

  • The 12 Requirements of the PCI DSS Regulatory Program
  • The four classifications of compliance depending upon your organization’s role
  • The concept of “scope” in defining the environments to be audited under regulation

The 12 Requirements of PCI DSS

There are 12 key requirements related to PCI compliance. Each requirement addresses an important area of compliance, information security, and privacy. Many of these themes are familiar and really should be considered best practices for any security-related program. Also notable is that the 12 requirements have a number of sub-requirements attached to them. I generally think of them as categories

  1. Install and maintain a firewall configuration to protect cardholder data
  3. Protect stored cardholder data
  4. Encrypt transmission of cardholder data across open, public networks
  6. Develop and maintain secure systems and applications
  7. Restrict access to cardholder data by business’s need to know
  8. Identify and authenticate access to system components
  9. Restrict physical access to cardholder data
  11. Regularly test security systems and processes
  12. Maintain a policy that addresses information security for all personnel

While these requirements seem pretty straightforward, the next two elements of PCI are a little subtler.

The Four Types of PCI DSS Accreditations

Not all participants working within the realm of PCI are the same. Depending upon where your organization is involved in the consumer service lifecycle, your requirements and the scope of your compliance efforts will differ. The following descriptions are taken directly from the PCI DSS website.

PCI Data Security Standard (DSS)


PIN Transaction Security (PTS) Requirements

The PCI PTS (formerly PCI PED) is a set of security requirements focused on characteristics and management of devices used in the protection of cardholder PINs and other payment processing related activities. Manufacturers must follow these requirements as they design, produce, and transport devices to whomever will use them. Financial institutions, processors, merchants, and service providers should only use devices or components that are tested and approved by the PCI SSC.

Payment Application Data Security Standard (PA-DSS)

The PA-DSS is for software developers and integrators of payment applications that store, process, or transmit cardholder data as part of authorization or settlement when these applications are sold, distributed, or licensed to third parties. Most card brands encourage merchants to use payment applications that are tested and approved by the PCI SSC. Validated applications are listed here.

The PCI Security Standards Council monitors new threats to cardholder data and may issue information supplements and other guidance for compliance. Changes to the PCI Security Standards follow a three-year lifecycle; the newest (version 2.0) was published in October 2010. 

PCI DSS Third Party Service Provider

A third party service provider is any “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data. This also includes companies that provide services that control or could impact the security of cardholder data.” A good example would be cloud-based solutions like Astute. Essentially, this type of participant covers those service providers that support the transaction workflow, but aren’t directly processing card transactions and that aren’t providing the software that is actually executing the transaction with the banking and card entities.

The Concept of Scope

Another important element is defining the scope of your PCI program. Regardless of which type of accreditation you pursue, you’ll be required to define the breadth of the operational and computing environment that is in use throughout the lifecycle of working with your card-holding consumers.

One example is a company with a website that takes credit card orders. This may touch multiple areas of your organization, from the data being stored to the accounting mechanisms you have in place. Your auditors and compliance teams will need to understand the details of these transactions. For instance, your back-office processes may happen in a completely separate environment from your customer-facing website. Instead of broadening your exposure and regulatory cost by including the entirety of your business in your PCI scope, segmenting and isolating the card-oriented operations is a much better approach.

By addressing the card processing and operational elements separately from the day-to-day business environment, you make it much easier to maintain compliance. Bringing an application or single business process into compliance for auditing purposes is hard enough, but trying to bring the wider business and technology elements up to the same compliance levels would be a costly endeavor. For example, if your email services are completely unrelated to your PCI-scoped areas, why spend the time and money to make them so? Not to mention the amount of complexity you’ll be introducing into your business operations by “locking down” your messaging and communications to this degree. (This is not to say you shouldn’t be properly securing your communications systems or ignoring other compliance programs required for those areas.)

Narrowing Your PCI Scope

Looking at the matter internally, you will want to narrow that scope to the smallest footprint possible (realistically and in keeping with the PCI DSS guidance). The key to reducing scope is having fewer places that process the sensitive elements of the consumer’s information and fewer connections to external processes or technical environments. This simplifies your compliance efforts and lowers your “attack profile” from the perspective of your security teams. In many ways, this goes back to the basics of consumer privacy. Don’t collect the data if it isn’t necessary… and if you do, take care of it in the proper manner. This can be a bit of effort up front, both for the business and for the IT organization, but it will be worth it, not just for compliance and peace of mind, but because it also simplifies your operation in the process, producing fewer moving parts that could go awry throughout the course of daily business.

Tokenization Helps Reduce Risk

One of the strategies you can use to accomplish this is called tokenization. Essentially, you minimize the points of interaction with the consumer that require PCI-restricted identifiers or sensitive data by using a single ID or key which then, in turn, references the full set of information required to perform the card transaction. The simplest and most common example is leveraging your company’s banking provider’s card processing services. Most banks that service businesses provide a service and/or technology platform which allows you to separate the consumer credit card information from the consumer data you keep in house. When a card transaction is performed, you are given a unique identifier, but the bank handles all of the card transaction processing and retention of the consumer’s related financial information. All you maintain is the identifying number which acts as a key. The bank manages the sensitive parts of the consumer information, mitigating the need to broaden the scope of what processes and data you need to include in your compliance program while still being able to conduct business with the consumer. Thus you are shrinking the footprint of the business operation and data elements that are in scope for your PCI compliance program.

The end result is that you no longer need to collect and store the card number in the first place. So, instead of your scope being as broad as your customer service department, accounting, reporting services, database system, phone recording systems, etc., by “tokenizing” your interaction with the consumer’s card holder data, you could minimize your scope (and risk) to just the customer service agent taking the call and the process of entering the data on the screen. The transaction is actually occurring on the bank’s systems. (Think of how PayPal decouples the merchant from the card data). Since you never store the sensitive credit card data locally, you can remove a large number of business processes, roles, and technology that might otherwise have to be treated as “top secret” right along with the core credit card information.

In our next article of the series, we will provide some insight into regional consumer privacy regulations around the globe, and how you can prepare your compliance program for those markets.

To learn more about Astute’s suite of solutions, watch this two-minute intro to who we are and what we do. 

Related Content