PCI compliance rules for storing credit card numbers

Saturday, January 03, 2015

Protecting your customers’ data

One of the most important parts of running a business is accepting payments from customers. And while traditional cash and checks are great, your customers now expect you to accept credit card and debit card payments. In the course of accepting credit card payments, you may need to store your customers’ credit card data. So, how do you ensure that you’re keeping it safe and protecting it from hackers and data breaches? In this article, we’ll look at the payment card industry data security standards (PCI DSS) that dictate how you need to store credit card data, what you’re allowed to store, and when you can store it. To start, let’s discuss PCI DSS in greater detail.

What is PCI DSS?

When it comes to credit card transactions, the payment card industry wants to do its part to protect consumers in payment applications. As a result, in 2006, the major credit card brands – Visa, Mastercard, American Express, and Discover – created the Payment Card Industry Security Standards Council (PCI SSC). This council drafted and implemented specific rules to improve the security of credit, debit, and cash card transactions, and protect cardholders from identity theft. These standards are known as PCI DSS and they apply to all organizations that store, process, or transmit customer card details. It’s important to note that the payment card brands and acquirers are responsible for enforcing compliance, not the council itself. In order to be in compliance, there are 12 general requirements for certification:

  • Install and maintain a firewall configuration to protect cardholder data.
  • Do not use vendor-supplied defaults for system passwords and other security parameters.
  • Protect stored cardholder data.
  • Encrypt transmission of cardholder data across open, public networks.
  • Use and regularly update anti-virus software or programs.
  • Develop and maintain secure systems and applications.
  • Restrict access to cardholder data through business need to know.
  • Assign a unique ID to each person with computer access.
  • Restrict physical access to cardholder data.
  • Track and monitor all access to network resources and cardholder data.
  • Regularly test security systems and processes.
  • Maintain a policy that addresses information security for all personnel.

Now that you know more about PCI DSS, let’s talk about when you’re allowed to store customers’ credit card data.

When can you store customer information?

It’s important to know that storing customers’ credit card information poses more of a cybersecurity risk than not storing their data. However, there are some circumstances in which your business may store credit card data. PCI DSS requirements state that you may store some credit card information for legitimate legal, regulatory, or business reasons. While this may vary, a typical business reason would be if you offer subscription-based services or recurring billing. If you do have a business need to store customer information, you’ll still need to understand what data you can store and what other compliance requirements you may need to fulfill. Let’s look at the data you are able to store.

What customer card data can you store?

If your business is storing credit card information, there’s a limit as to what data you can retain. The PCI DSS sets forth that you can store the data that’s normally found on the front of a credit card, and it’s often called Cardholder data (CHD). While this may not be the case for all credit cards, the majority of them have all of this data on the front. Here’s what you are able to store as a business:

  • Card number
  • Cardholder name
  • Service code
  • Expiration date

It’s important to note that EMV chip data is not considered cardholder data and cannot be stored. This data is known as Sensitive Authentication Data (SAD) and cannot be stored after authorization of a transaction, even if the data is encrypted. This data includes the following:

  • Authentication data
  • PIN code or PIN block
  • CVV2/CID/CVC2 (verification/security code on back of card)

Now you know what data you can and can’t store, let’s dive into some of the specific PCI DSS rules to see how they affect compliance.

A few PCI DSS compliance rules

Rule 3.1

This requirement helps to lay out the methodology for ensuring cardholder data storage is limited to necessary legal, regulatory, or business cases. It states that validating entities have to develop specific data retention policies, secure deletion policies, and a quarterly process to identify and remove cardholder data that exceeds the retention period. This process has to happen whether or not the entity is aware they’re storing cardholder data. Many companies utilize a data discovery tool to identify this data, coupled with best practices to prevent a physical data compromise.

Rule 3.2

This requirement states that Sensitive Authentication Data (SAD) can’t be stored after an authorized transaction, even if the data is encrypted. This SAD includes full magnetic stripe data, CVV, and PIN data. Obviously, this data is very valuable to fraudsters in both card present and card-not-present (CNP) transactions. There’s only one category of entities that can retain this data – the card issuers; and they must have a legitimate business reason related to their role as an issuer. Validating entities that store SAD must create a cardholder data flow diagram to demonstrate where and how the cardholder data they have access to moves through their system and is stored.

Rule 3.3

This requirement states that the 16-digit Primary Account Number (PAN) has to be masked when it’s displayed. The maximum number of digits that can be displayed are the first six and last four digits. The only exception to this rule is when users whose roles include a legitimate business purpose need to access the data and view the entire PAN. Otherwise, a PAN cannot be displayed in full on screens, paper receipts, or any other printouts.

Rule 3.4

This requirement states that if your business cannot avoid storing a PAN, that data must be rendered unreadable wherever it’s stored. There are acceptable methods for rendering this data unreadable, as explicitly stated by PCI DSS. These methods are:

  • Strong one-way hash functions of the entire PAN
    • Also called the “hashed index”, which displays only index data that point to records in the database where sensitive information actually resides.
  • Truncation
    • Removing a data segment, such as showing only the last four digits.
  • Index tokens with securely stored pads
    • An encryption algorithm that combines sensitive plain text data with a random key or “pad” that works only once.
  • Strong cryptography
    • Cryptography is defined as the use of mathematical formulas to render plain text data unreadable.

Rendering PAN data unreadable means that if an attacker were to obtain the data, it would be extremely difficult and time-consuming to decrypt it. This is in an effort to render the data essentially useless to any attackers.

Rule 3.5

This requirement states that validating entities take the steps necessary to protect encryption keys from disclosure and misuse; they must also document their procedures. If an attacker gets ahold of the encryption keys, they’ll be able to decrypt the card data. Therefore, limiting the possibility of attackers to use any of these keys to decrypt the data is paramount. Cryptographic keys have to be stored in the fewest locations possible and with the least number of individuals having access. The validating entity needs to consider threats from the outside as well as threats from the inside of the organization.

Rule 3.6

This requirement states that key management processes for the use of cryptographic keys must be completely documented. This documentation includes secure key generation, distribution and storage of cryptographic keys, policies that require key changes at the end of the cryptoperiod, or as a result of a disintegration of key integrity. This weakening could be a result of a team member with knowledge of the clear text encryption key leaving the company, or if a key is suspected to be compromised.

PCI DSS compliance is an integral part of securing your business and your customers from cybercriminal attacks. While there’s a lot that you’ll need to ensure you’re doing to remain PCI compliant, you don’t have to do it alone. That’s because many businesses choose to work with a third-party payment gateway, merchant account service provider, or payment processing partner to help them maintain PCI DSS compliance. They’ll do all of the hard work of maintaining compliance and storing card information (if needed) so you can focus more on what you do best – running your business.


Ready to work with a payment processor who can help you with PCI DSS compliance?

Heartland is the point of sale, payments and payroll solution of choice for entrepreneurs that need human-centered technology to sell more, keep customers coming back and spend less time in the back office. Nearly 1,000,000 businesses trust us to guide them through market changes and technology challenges, so they can stay competitive and focus on building remarkable businesses instead of managing the daily grind. Learn more at heartland.us.