After a number of interactions with a variety of people over the last few weeks, it has become obvious that the concept of pre-authorization data is not clear to a lot of people. And just because it is pre-authorization data does not mean that you are not required to protect it. The Council has made it very clear that it is to be protected with the same rigor as post-authorization data.
Pre-authorization is defined as that time when an organization has a customer’s sensitive authentication data (SAD) but has not yet processed it for payment. For most merchants, the time between collecting the SAD and processing it is measured in seconds. For card present transactions, the SAD can be track or chip data. For card not present transactions, it typically includes the cardholder name, primary account number (PAN), expiration date and CVV2/CVC2/CID2.
Here are some situations where that does not always happen that quickly.
Phone, facsimile and mail orders can extend the amount of time between receipt of the SAD and processing by seconds, minutes or even hours. On the bizarre side of things, I encountered at one client people sending their physical cards in the mail for processing of their mail order.
At the fuel pump when a customer swipes their card, the system that manages the payment process will pre-authorize the purchase and then store the SAD until the customer finishes pumping fuel and hangs up the hose to complete the transaction. That could be five to 10 minutes depending on fuel tank size.
In some industries the time of pre-authorization can be weeks, months and in some cases even a year or more. Where this typically occurs is in the airline and hospitality industries.
When a customer makes an airline reservation, the airline will likely pre-authorize your airfare but may not actually charge your card until 7/14/60/90 days before you check in or even until you check in. This can result in your SAD being stored for weeks or even months.
In the hospitality industry, a reservation typically does not cause a charge until a customer checks out even though they are required to have a card on file to hold the reservation. When a customer checks into the property, the hotel’s billing system records the SAD and may also pre-authorize charges, but the actual card transaction is not processed until the customer checks out. I have encountered SAD in hospitality systems that have been stored for more than a year due to reservations for special occasions such as graduations, birthdays, family reunions and anniversaries. New versions of hospitality management systems encrypt pre-authorization data, however older systems did not and the security of the pre-authorization data may not be a rigorous as it should.
eWallet applications are another great example of pre-authorization data. eWallets are just an electronic version of a consumer’s physical wallet. eWallets can be applications on a smartphone/tablet or a specialized device such as Coin. eWallets are not regulated by the Council or the card brands and never will be just as traditional wallets are not regulated. That said, developers of eWallet applications should follow the PA-DSS for developing secure eWallet applications.
The most confusion over pre-authorization data typically occurs over SAD that an organization receives via email. A lot of QSAs get their “undies in a bunch” over this and point to requirement 4.2 as the reason why this is unacceptable. Requirement 4.2 states:
“Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.).”
The operative word in 4.2 is “send”. Requirement 4.2 says nothing about receiving PANs by these methods and the reason is that it is pre-authorization data. That does not mean that the Council recommends receiving PANs via email, IM or similar methods. It is only recognition of what goes on in the real world. There will always be a small percentage of people that will send their cardholder data insecurely and there is little an organization can do to stop it. But even before you start the argument, you need to acknowledge that this data is pre-authorization data because a transaction has yet to be processed.
To keep your email system out of scope, the Council has told QSAs to make sure that organizations have a process to remove the SAD as soon as possible from the system(s) in question. That typically involves the printing of the message, deleting the message from the system and then securely destroying the printed message once the transaction is processed. This is all considered “incidental contact” in the eyes of the Council and the QSA can then consider the system out of scope as long as they can satisfy themselves that the manual process is reliable and consistently executed.
Web sites that store customers’ SAD for future purchases are also dealing in pre-authorization data. Merchants providing such a service should contractually acknowledge their responsibility to protect that data with the same rigor as post-authorization data and that the stored data is only for use for purchases by the customer on the merchant’s Web site.
My final example of pre-authorization data is when an organization’s travel department stores employees’ card data for company travel reservations. The systems used by these departments typically store the cardholder name, PAN, expiration date and the CVV2/CVC2/CID2. When the PCI DSS originally was published, the card brands instructed QSAs that these sorts of systems were not in scope for an organization’s Report On Compliance (ROC). However, as time has passed, some of the card brands now want those systems included in the ROC, so organizations need to contact the card brands to determine if their ROC should include such systems. These systems can be interesting in how little protection they can provide for SAD, so regardless of whether they are included in the organization’s assessment, the organization should review the security of the application against the PCI DSS and mitigate any gaps. As with the aforementioned Web sites that store pre-authorization data, an organization storing SAD for their employees should legally acknowledge their responsibility to protect that data as well as document how it may be used.
The bottom line is that all of these situations involve pre-authorization data and pre-authorization data can include everything recorded on a card’s magnetic stripe or chip. Merchants can store pre-authorization data until a payment transaction is processed. If they do store the pre-authorization data, they are obligated under the PCI DSS to protect it with the same rigor as post-authorization data, i.e., encrypted, extremely limited access, logging, monitoring, etc.
Hopefully we are now all on the same page.
