Requirement 3.1 of the PCI Data Security Standard (DSS) requires merchants keep cardholder 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.
 |
| 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) |
|
|
|
|
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.
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.
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.
A merchant should store the minimum necessary to meet the documented business needs for cardholder data. In addition, ensure that any storage is done securely and in compliance with all statutes, regulations, contractual obligations, and in accordance with your privacy policy.
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 roger.nebel@fticonsulting.com. The views expressed in the article are held by the author and are not necessarily representative of FTI Consulting.
