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.
PCI Guru 
Thanks for all your insight. In an environment where a call center rep takes payment via a phone and enters it into their local workstation, into an internal web application: Is that local workstation part of the CDE? It technically only processes ‘Pre Authorization’ data as the transaction happens after the card number, etc. has passed into the web application. Thoughts?
While pre-authorization data, the Council and the card brands will tell you that it does bring the workstation into scope for PCI because of the data entry. But the telephone call conversation is also in-scope if that is conducted over VoIP let alone recorded and the SAD/CHD is not redacted.
That said, how much in-scope for the workstation depends on the risk which could be as little as being at risk for a memory scraper or keyboard logger.
Thanks for great article! Would you happen to know how marketplace type businesses (that essentially forward payments to actual vendors) deal with this problem? I.e. they need to store pre-authorization data and pass it on. Would they run an e-wallet type of a setup or are there better architectures out there?
What you describe is, IMVHO, more of an eWallet approach.
I have a Query regarding storage of SAD during pre-auth, do we require Key Management for the Encryption of SAD as per req 3.4, 3.6.
Pre-authorization is a really gray area. You really need to discuss your requirements with your acquiring bank and the card brands (i.e., Visa, MasterCard, American Express, Discover and JCB) that you process. Each will have their own opinion and you will have to work with the lesser of the options those entities provide your organization.
I like this article, but there’s one thing I wanted to ask. Another article on this said pretty much the same thing, but also mentioned that card brands might have specific guidance on how long this data could be retained. Unfortunately, I can’t find any guidance on this from any card brands – have you ever seen any, or heard that such guidance actually exists?
The card brands typically take these issues on a case-by-case basis which is why you have found no formal guidance from them. Merchants and service providers make their business case of their reason to retain pre-authorization data for a designated period of time and the card brands give their blessing, ask for more information and clarification or deny the request.
Requirement 8.7 states:
Seems pretty clear to me that this requirement does not disqualify anyone and is for ALL access including administrators.
Ok, that makes sense – assuming that pre-auth storage without a discussion would probably be unpopular, I guess I’m off to talk to the brands – thanks for that!
It’s been a year since you posted this. Has anything changed in that time? Do you have any other thoughts on the matter?
Would a lodging establishment be able to claim that stored data is I reauthorization data for the purpose of
* a customer’s written consent to a late checkout or late payment incurring a charge of one night’s rate
* a customer’s written consent to a non-cancelled, non-claimed reservation incurring a charge of one night’s rate
The definition of pre-authorization seems clear that these would qualify. I am uneasy about the lack of specific requirements on storage (on paper, in writing, in a pile on top of a desk in a reception area seems to be perfectly permissible though I would consider it undesirable all the same.) This is an unfortunate, but as I have read, necessary situation.
Nothing has changed. Once you have processed the transaction, you are no longer allowed to retain anything other than cardholder name, PAN and expiration date.
How organizations get around that is to use tokenization where the transaction processor can process future transactions such as for subscription renewals and the examples you cite.
Those examples wouldn’t qualify?
No because you have processed a transaction. The trigger point is when the transaction is processed such as at checkout of a hotel. Prior to that point, the data is pre-authorization data and can be stored. However, at checkout, the transaction is processed and the pre-authorization data becomes POST-authorization data and then only the cardholder name, PAN and expiration date can be retained.
I don’t understand. If a customer signs a document saying they agree to being charged if they check out late, a business stores the customer’s information, and nothing is done until the customer does or does not check out late, that is a “processed transaction” according to the PCI DSS? That seems like I reauthorization to me even if it is a bad business practice.
I spent some time trying to define where authorization occurs and the closest I could come was asking an aquirer to run an authorization through the card network to the proper issuer. That does not occur in this example.
What happens at a hotel is that when a guest checks in their card is swiped and a hold for the amount of the stay is placed on the account. That is not a payment transaction. The cardholder data is stored in the hotelier’s system until the guest checks out at which time the bill is presented, the guest agrees to the charges, and then a transaction is run on the card to pay for those charges.
This same process occurs at the gas station. When a customer swipes a card at the pump, the system puts a hold on the card for some dollar amount (typically $75 – $250). When the customer finishes pumping gas, then the transaction is run to pay for the actual amount of the gas.
And what if not even that occurs?
Not following your question here reading the thread. Please explain further.
Can paper storage of cardholder data (Name, PAN, and expiration as a group) be considered pre-authorization data if it is not processed through a machine until actual charges are incurred and then processed through a machine? If so, does the paper media need to be destroyed once the data from it is used for that charge?
At a motel, the desire is to have customers agree to be charged for the night if they
* don’t check out on time or
* make a reservation and no-show without canceling
and charge them accordingly if they complete one of those actions. (This avoids small claims court if/when they refuse to make good on their debt when we call them and ask them to do so.)
Our aquirer only does one-week holds (pre-authorization/authorize-only) and I am trying to determine whether or not I should advise management to request longer holds (my preference but potentially not theirs) or use the afformentioned paper storage.
Yes, paper needs to be securely destroyed once the transaction are processed for the cardholder data (CHD) on that paper. This is why a lot of organizations are putting the CHD at the bottom of their forms so that they can tear it off and securely destroy it without losing the rest of the form.
The hotels that I have stayed at require you to have guests’ cards re-processed every seven days when their processor will not do a hold for longer than seven days. This is standard in most parts of the world except the US.
For not checking out on time, I have seen hotels go to the guest’s room and load up their belongings at check out time and secure them with other luggage being held. The guest then must come to the counter to retrieve their belongs and it is at that time the guest is required to pay for any additional charges. Another option is to lock the guest out of their room which would also force them back to the front desk.
I think as per PCI v2 requirement 3.2.2 CVV data should NOT be stored , even if protected or declared as practicing secure measures to protect them – these should not be stored.
While documenting the ROC, QSA shall also ask the evidence to support that a merchant follows manual/automated methods to remove CVV data after authorization.
That would be nice if we lived in a perfect world, but we do not. Some businesses have no choice because of their business model and the way current cards operate.
As to your second comment, that is already required of QSAs by the PCI DSS and PA-DSS.
Regarding your “final example”, an employer that I once had insisted on keeping my card on file and it really bugged the heck out of me. But, I never give out full PAN plus CVV to any merchant (if I can help it) ahead of time. In most cases they don’t seem to mind and it doesn’t seem to matter!?
Good article thanks. I think it would have helped increase clarity if you pointed out that the card verification code cannot be stored. Your article as written may be interpreted by association, as meaning that the verification code can be stored with the other SAD.
Ah, but that is the rub. When it’s pre-authorization data, you can store everything track data, chip data, CVV, whatever you want as long as it is securely stored and managed. However, once a payment transaction is completed, all of that pre-authorization data MUST be securely deleted and cannot be retained other than the cardholder’s name, PAN and expiration date.
What a lot of people fail to understand is that the physical card is technically considered pre-authorization data by the card brands and the PCI SSC. The brands and the Council do a very poor job of explaining pre-authorization which is why most people do not understand the concept.
Under your rules, after a customer uses their card, they would have to securely destroy it.