It’s a simple question: what does PCI DSS allow you to store? The answer is, like most things with PCI DSS, a little complicated. The general approach of the PCI Data Security Standard is to minimize the types of card data that may be stored, and to minimize the amount of time you can store that data. In all cases, card data may only be stored where there’s a business need.
What you are allowed to store depends on a couple of factors:
- Who you are? Are you an issuer, or someone else?
- Has the authorization happened yet?
We need to drill into these scenarios to understand why the PCI SSC defined the rules the way they did. But first, let’s understand how PCI DSS defines the different types of card data.
Contents
PCI Account Data
Normally when talking about PCI DSS, we think of cardholder data. But technically, the standard applies to Account Data, where account data is a combination of Cardholder Data (CHD) and Sensitive Authentication Data (SAD). Both of these are types of card data, but the split exists because some data is considered to be more sensitive than others.
Why is that? When issuers make decisions about whether to approve an auth request, they don’t just look at the card number. They also look at things like the CVC/CVV2 if it’s an online transaction, or the PIN if the card is used at an ATM. These extra pieces of information are needed to decide if it’s a legitimate card or cardholder doing the transaction. But for other use cases, such as doing a chargeback, the PAN is sufficient as you’re not trying to verify a card or a person at that time.
The standard reflects these two different use cases by splitting Account Data into Cardholder Data (needed for many card use cases), and Sensitive Authentication Data (needed only for auth processing).
PCI DSS provides a helpful table which explains what the different types of cardholder data are.
| Cardholder Data | Sensitive Authentication Data |
|---|---|
| Primary Account Number (PAN) | Full track data |
| Cardholder Name | CAV2/CVC2/CVV2/CID |
| Expiration Date | PINs/PIN blocks |
| Service Code |
What most of these fields are should be fairly obvious. One thing that catches people out however is the service code. You may not know, but encoded into the magnetic stripe on the back of a card is a 3 digit code, called the service code. The numbers in this service code define how the issuer intends for the card to be used, for example whether international transactions are allowed.
Why is the service code sensitive? It’s one of the inputs to the algorithm used by a Payment HSM to calculate the card CVC.
The Scenarios
In terms of who you are, for the purpose of storing card data you’re either an issuer or you’re someone else. As to whether an authorization has happened yet, that boils down to whether you’ve received a response from the issuer to an auth request.
Let’s consider these one at a time.
Who are you?
It’s likely that someone reading this document will not be an issuer. For every issuer, there are many merchants. PCI DSS covers all entities in the card payments world, but it’s effectively written to target the merchant use case, with exceptions added for others.
Why does PCI DSS care about whether you’re an issuer to decide what card data you can store? Issuers have to store a list of all the cards that they’ve issued which are still valid. That list has to include enough information to verify any card swiped at a merchant is real. That means records of PAN, PIN (if one is set), CVC/CVV, expiry date, service code, cardholder name.
Note: issuers don’t have to store the actual PIN and CVC/CVV to do this! There are algorithms which allow them to calculate these on the fly, using a payment HSM, encryption keys, and other stored information.
Because of the additional information they need to store, issuers have an exception available to them within the PCI DSS standard. The exception is stated in section 3.2:
It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:
PCI DSS v3.2.1 Requirement 3.2 issuer note
• There is a business justification and
• The data is stored securely
If you’re a merchant or an acquirer, how much cardholder data you are allowed to store depends on whether an authorization has happened. So what is an authorization?
The traditional card processing model is a dual message system. When a customer swipes their card, there is an ‘authorization’ message sent immediately to the issuer, which they can approve or decline. If they approve, a hold for the amount requested is placed on customer funds or credit limit. Later, a second ‘clearing’ message is sent which actually causes the funds to move from the customer account. This completes the transaction.
To perform the authorization, the card is verified. The PAN, expiration date, service code, and SAD such as CVC/CVV and any PIN, are verified to decide if it’s a real card and cardholder transacting. The later clearing process does not need most of these fields, relying on the PAN and the auth code generated during authorization.
With this model, authorization has happened when you receive the initial message back from the issuer approving or declining the authorization. That will happen in just a few seconds after the card swipe, except in some edge cases such as swiping for a small purchase on an airplane.
So what cardholder data can I store?
For legitimate business purposes, you are able to store the following for a defined period of time to meet your business needs:
- Primary Account Number (PAN)
- Cardholder Name
- Expiration Date
- Service Code
If you are not an issuer, you may also store the following data for the very limited time between the card swipe, dip, or tap, and the issuer approving or declining the authorization. If you are an issuer, you can store the following if you have a legitimate business reason to do so and can show you’re doing so securely:
- Full track data
- CAV2/CVC2/CVV2/CID
- PINs and PIN blocks
Understand your business model and use cases well before making any decisions on storing cardholder data. It’s always worth consulting your QSA for their opinion during the planning stage too.