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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
See Also: How do I Protect the Stored Payment Cardholder Data?<\/strong><\/a><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: How To Store Credit Card Information<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What Are the Parts of a Debit or Credit Card and How Do They Work?<\/strong><\/a><\/p>\n\n\n\n If cardholder data is to be retained, PCI compliance requirements dictate that cardholder data must be rendered unreadable using industry-standard techniques.<\/p>\n\n\n\n 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<\/a> data isn’t Cardholder Data, and it can’t be saved after authorization.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: What are the Acceptable Formats for Truncation of PAN<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n Here is a summary of what you can and cannot store:<\/p>\n\n\n\n If the data is encrypted, the ones you are allowed to store are as follows:<\/p>\n\n\n\n Even if the data is encrypted, you may NEVER store the following data:<\/p>\n\n\n\n Here are some suggestions to think about while establishing and executing credit card transaction management and credit card data storage strategies:<\/p>\n\n\n\n PCI DSS requirement three<\/a> is concerned with storing cardholder data and protecting stored cardholder data.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n See Also: PCI Requirements for Storing Credit Card Information on Paper<\/a><\/strong><\/p>\n\n\n\n Merchants who do not save cardholder data are far less likely to experience a costly, time-consuming, reputation-damaging data breach.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n We can briefly summarize the PCI DSS requirements regarding card storage below:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n See Also: What Are the PCI DSS Encryption Requirements<\/a><\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\nWhat Credit Card Data Does PCI Allow to Store?<\/strong><\/h2>\n\n\n\n
What Credit Card Data Doesn’t PCI Allow Storage?<\/strong><\/h2>\n\n\n\n
Can you store the 16 digit card numbers, CVV, and expiration dates?<\/strong><\/h2>\n\n\n\n
\n
\n
Recommendations for Storing Credit Card Data<\/strong><\/h2>\n\n\n\n
\n
What Are the PCI Requirements for Storing Credit Card Data?<\/strong><\/h2>\n\n\n\n
PCI DSS Requirement 3.1<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 3.2<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 3.3<\/strong><\/h3>\n\n\n\n
PCI DSS Requirement 3.4<\/strong><\/h3>\n\n\n\n
\n
PCI DSS Requirement 3.5<\/strong><\/h3>\n\n\n\n