Requirement 3.1 of the Payment Card Industry Data Security Standard (PCI DSS) requires merchants keep cardholder...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
data storage to a minimum. Develop a data retention and disposal policy. Limit storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in the data retention policy.
To keep, or not to keep -- that is the question. Whether it is nobler in the eyes of your acquiring bank to retain your transaction data, and risk a breach, or to take arms against the conventional wisdom that the merchant must retain massive amounts of private data in order to fend off the odd contested transaction. Ay, there's the rub.
Many banks insist that their merchants retain complete records of all credit card transactions in case there is a disputed transaction. However, all the merchant needs is the authorization number from the processor, the dollar amount and to have checked the customer's identification for a card present transaction, or to get the card verification value code and billing zip code for a card not present at the transaction.
The new PCI DSS version 3.1
On April 15, 2015, the PCI Security Standards Council released PCI DSS version 3.1, calling for merchants to depreciate the Secure Sockets Layer (SSL) and "early" Transport Security Layer (TSL) protocols immediately, as these encryption protocols put payment data at a high level of risk. The new PCI DSS 3.1 version should not be confused with Requirement 3.1 of the PCI DSS.
Here's what you need to know about PCI DSS 3.1:
- PCI DSS 3.1 updates key requirements addressing insecure SSL and early TSL protocols
- By June 30, 2016, merchants cannot use SSL and early TSL protocols as standalone security controls for payment data
- Merchants should immediately cease to use the SSL and/or early TSL protocols in new implementations
- The PCI SSC requires merchants to implement its recommendations for an interim risk mitigation and migration plan, including associated documentation
Yet this topic comes back to haunt us. The National Retail Federation wants the acquiring banks to store the data and provide a code to the merchant which would relieve the merchants of their burden to store the data. But that's just what already exists in the form of the authorization code! One merchant insisted that they must retain the full transaction data -- credit card number, expiration date, etc. -- for seven years. Unless there's been fraud, not even the IRS requires that.
So are there valid reasons to store the data? Possibly. Customers leave their credit card data at Amazon or PayPal, and the benefits to those merchants are clear -- ease of future transactions which presumably increase sales. There are other valid reasons, such as recurring payments. If a merchant does decide to store the data for a legitimate business reason then they are required to protect it.
PCI DSS 3.1 testing procedures
Obtain and examine the company policies and procedures for data retention and disposal, and perform the following:
* Verify that policies and procedures include legal, regulatory, and business requirements for data retention, including specific requirements for retention of cardholder data (for example, cardholder data needs to be held for X period for Y business reasons)
* Verify that policies and procedures include provisions for disposal of data when no longer needed for legal, regulatory, or business reasons, including disposal of cardholder data
* Verify that policies and procedures include coverage for all storage of cardholder data, including database servers, mainframes, transfer directories, and bulk data copy directories used to transfer data between servers, and directories used to normalize data between server transfers
* Verify that policies and procedures include A programmatic (automatic) process to remove, at least on a quarterly basis, stored cardholder data that exceeds business retention requirements, or, alternatively, requirements for an audit, conducted at least on a quarterly basis, to verify that stored cardholder data does not exceed business retention requirements
(Source: PCI Security Standards Council)
What then is the merchant to do?
-- First, have a good set of policies and well-documented business practices. Also encrypt or otherwise protect the data (if the entire card number is stored).
-- Second, have those policies and practices reviewed on a periodic basis (annually at a minimum) by one or more experts in the field. These include law, privacy and security experts.
-- Finally, question yourself over retention in the first place. Is the risk and cost of retention worth the benefits of having the data on hand?
See sidebar for testing procedures.
About the author:
Roger Nebel, CISSP, CISA, works with FTI Consulting, specializing in forensic and litigation consulting. He is based in Washington DC where he leads the Strategic Security practice. Nebel also teaches at the University of Virginia in the graduate information security program. He can be reached at firstname.lastname@example.org. The views expressed in the article are held by the author and are not necessarily representative of FTI Consulting.
Don't miss need-to-know info!
- Security pros at financial organizations can't afford to be the last to know. Sign up for email updates from SearchFinancialSecurity.com and you'll never be behind the curve!