Compromising the security of payment information damages reputation, and even the best-equipped firms can experience fraud at some point. The most important thing is to minimize your risk as much as possible while yet adhering to the ever-changing payment card industry standards.
It is essential for payment solutions developers understand how and why their solutions handle cardholder data (CHD). There are many reasons why a solution would want to store sensitive data, short or long-term, including payment processing, transaction history, or recurring billings.
Consumers assume that merchants and financial solutions will handle this data securely to prevent theft and unauthorized use. But the truth is that many traders may not be aware that they are hiding CHD.
The Payment Card Industry Data Security Standard (PCI DSS) is a collection of policies and procedures developed by the Payment Card Industry to improve the security of credit, debit, and cash card transactions and protect cardholders from identity theft.
PCI-DSS requirements, a set of requirements set by the PCI Security Standards Council (PCI SSC) and supported by major card brands, apply to all organizations that store, process, or transmit cardholder data.
PCI-DSS requirements state that cardholder data may only be retained for a legitimate legal, regulatory, or business reason. In other words, if you don’t need cardholder data, you shouldn’t store it.
Those with a genuine business motive to store cardholder data should be aware of the data items that PCI DSS authorizes them to store and the security steps that should be taken to safeguard that data.
It’s vital to note that these assertions only apply to Cardholder Data, such as the 16-digit Primary Account Number (PAN), expiration date, and cardholder name, and not to Sensitive Authentication Data, such as Tracking Data, PIN, PIN Block, and CVV. According to PCI DSS requirements, sensitive Authentication Data (SAD) can never be stored after authorization.
If cardholder data is to be retained, PCI compliance requirements dictate that cardholder data must be rendered unreadable using industry-standard techniques.
What Credit Card Data Does PCI Allow to Store?
Organizations that verify that data designated as Cardholder Data can be stored are allowed to do so (CHD). The 16-digit main account number (PAN), cardholder name, service code, and expiration date are all included in this information. This information is usually seen on the face of the card. It’s important to remember that EMV chip data isn’t Cardholder Data, and it can’t be saved after authorization.
What Credit Card Data Doesn’t PCI Allow Storage?
After a transaction has been authorized, sensitive authentication data (SAD) cannot be stored. This information contains the entire magnetic stripe data on the back of the card and equivalent data on the EMV chip or elsewhere.
SAD also includes CVV or comparable data as well as PIN and PIN blocks. This data is precious to attackers for use in both card-present and card-less environments.
Can you store the 16 digit card numbers, CVV, and expiration dates?
Payment card data is an essential issue for merchants. No matter how big an organization is or how many years they’ve been in the business, if they’re using credit card data, chances are they’re storing it in the wrong place on their devices and systems.
Your customer’s credit card data is sensitive information, and if you process major credit cards, you agree to maintain PCI compliance. PCI compliance requires merchants to take measures to secure payment card data and prevent data breaches.
Here is a summary of what you can and cannot store:
If the data is encrypted, the ones you are allowed to store are as follows:
- PAN (Primary Account Number)
- Cardholder’s name
- Expiration date
- Service code
Even if the data is encrypted, you may NEVER store the following data:
- Sensitive authentication data (Full magnetic stripe information)
- PIN block (Encrypted PIN)
- Card verification value (CVV), also known as three/four-digit service code or card security code
Recommendations for Storing Credit Card Data
Here are some suggestions to think about while establishing and executing credit card transaction management and credit card data storage strategies:
- Sensitive authentication data should never be stored.
- PCI DSS requires primary account numbers (card numbers) to be made unreadable when stored.
- Other than sensitive authentication data, cardholder data should only be kept if there is a valid legal, commercial, or regulatory need.
- Your organization should delete data
- after the minimum retention period has passed unless it is compelling to maintain it.
- Suppose records of card transactions contain information other than cardholder data, and your organization needs this information for a while after the transaction has taken place. In that case, cardholder data should be retained or reorganized to meet PCI DSS requirements.
- Establishing and documenting a process for the storing and management of credit card transactions is essential. This will ensure that all employees know the sensitive data that must be collected, stored, and destroyed. Establishing this process will require consultation with employees who receive, process, and use cardholder data.
What Are the PCI Requirements for Storing Credit Card Data?
PCI DSS requirement three is concerned with storing cardholder data and protecting stored cardholder data.
PCI DSS requirement three can be broken down into multiple sub-requirements. The overarching principle is that limiting, banning, and deleting stored cardholder data eliminates a key target for cybercriminals.
Merchants who do not save cardholder data are far less likely to experience a costly, time-consuming, reputation-damaging data breach.
It’s critical to understand the differences and definitions of Account Data, Cardholder Data, and Sensitive Authentication Data. Account Data refers to all of the information on a credit card. Cardholder Data (CHD) and Sensitive Authentication Data (SAD) are two types of account data (SAD).
The cardholder data includes the 16-digit PAN, expiration date, and cardholder’s name (CHD). This information is usually printed on the front of the card. Cardholder data should only be kept for as long as is necessary to meet legal, regulatory, or business requirements.
Sensitive Account Data (SAD) includes sensitive tracking data held by magnetic stripe, CVV, PIN, and PIN Block. These data can never be stored after authorization. The only entity that can store SAD is an issuer, and it is only allowed to store it under certain conditions and justifications.
We can briefly summarize the PCI DSS requirements regarding card storage below:
PCI DSS Requirement 3.1
PCI DSS requirement 3.1 lays out the methodology that must be applied to ensure that cardholder data is limited to what is required for legal, regulatory, or business needs. This requirement specifies that verifying organizations must develop data retention policies, secure deletion policies, and a quarterly process to identify and remove cardholder data that has exceeded its retention period.
This quarterly period is required regardless of whether the business is aware that it is storing cardholder data. Some many tools and techniques can be used to identify sensitive data. The most common is using a data discovery tool combined with best practices to protect against a physical threat.
PCI DSS Requirement 3.2
PCI DSS requirement 3.2 specifies that Sensitive Authentication Data (SAD) cannot be stored after authorization, even if encrypted. Sensitive Authentication Data (SAD) includes full track data, CVV, and PIN data.
Sensitive Authentication Data is extremely valuable to attackers in fraudulent transactions, both card-present and card-not-present transactions. The only organizations that can store this data are publishers with a legitimate business need for publishing services. Verifiers should create a cardholder data flowchart that documents where and how cardholder data moves or is stored within the system.
PCI DSS Requirement 3.3
PCI DSS Requirement 3.3 specifies that the 16-digit Primary Account Number (PAN) should be masked when displayed. The maximum number that can be shown is the first six and the last four digits. The full PAN is only viewable for users with roles that have a legitimate business need to view the full PAN. This requirement applies to the display of the PAN on screens, paper receipts, and other printouts.
PCI DSS Requirement 3.4
If storage of the PAN is unavoidable, this data must be made unreadable wherever it is stored. PCI DSS explicitly lists acceptable methods for rendering this data unreadable as follows:
- All PAN’s strong one-way hash functions – Also called “hash index,” which displays index data only pointing to records in the database where sensitive data resides.
- Truncate – Remove a data segment, such as showing only the last four digits.
- Index tokens with securely stored pads – An encryption algorithm that combines sensitive plaintext data with a random key or “pad” that only works once.
- Strong Cryptography – Cryptography is defined as the use of mathematical formulas to render plain text data unreadable.
Making the PAN data unreadable means that decrypting the data would be extremely difficult and time-consuming if an attacker gets the data. This means that the data becomes essentially useless to attackers.
PCI DSS Requirement 3.5
PCI DSS requirement 3.5 extends the use of cryptography and requires verification bodies to protect encryption keys from disclosure and misuse and document these procedures.
If an attacker obtains the encryption keys, the data can be decrypted. This applies to key-encryption keys and data encryption keys to limit the possibility of attackers using any of these keys to decrypt data and expose cardholder data.
Encryption keys should be stored in as few places as possible with as few accesses as possible. Verifying organizations should consider external threats, such as hackers or physical threats, and internal threats from employees.
PCI DSS Requirement 3.6
Key management processes for the use of cryptographic keys should be fully documented. Documentation should include the secure generation, distribution, and storage of cryptographic keys. It should also include policies requiring key changes at the end of the crypto period or if the integrity of the key has been weakened.
This weakness can be caused by a team member who has left the organization knowing the clear-text encryption key or when the keys are suspected of being compromised.