Pre-Authorization Data – The Card Brands Weigh In

I just wanted to pass along what I have heard thus far on this topic from the various card brands.  I’ll keep updating this post as I get more responses.

American Express (aka Trustwave) came back with the following.

“Per your inquiry regarding the storage of pre-authorized data, from what I can tell the American Express DSOP program currently does not address this topic. However, both the PCI SSC and the card brands (including American Express) have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data. That means encrypting it and restricting access to it. The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data seemingly is not covered by the PCI DSS/DSOP programs at this time, you must do everything you can to protect it.

I hope this somewhat answers your question. I plan on doing more research to find any official documentation regarding the subject.”

MasterCard International followed up with their response.

“Merchants should talk with their acquirers to determine the pre-authorization rules particular to their vertical market and region.”

Visa quoted their Visa International Operating Regulations manual; section Account and Transaction Information Security Requirements VIOR 2.1.E (Updated):

“Ensure that all agents and Merchants do not store any of the following, subsequent to Authorization:
–    Full contents of any data taken from the Magnetic Stripe (on a Card, in a Chip, or elsewhere)
–    Card Verification Value 2 used to verify Card-Absent Transactions
–    PIN or the encrypted PIN block”

Discover has come back with the following.

“Currently the following restrictions apply:

(a) Sensitive Authentication Data obtained in connection with a Card Transaction must not be retained after receipt of an Authorization Response.
(b) Sensitive Authentication Data must not be recorded on Transaction Documentation or any other records or evidence of Card Transaction.
(c) Any processing, transmission, or storage of Cardholder Data must be conducted in accordance with PCI DSS requirements.”

JCB is still to be heard from.

I was deeply disappointed with MasterCard’s response.  Acquiring banks, for the most part, cannot answer basic questions about the PCI DSS, so we are supposed to believe that they are experts on retention of pre-authorization data based on a company’s vertical market and region?  Talk about passing the buck.

I am also surprised that I have yet to see any of the supposedly “very specific rules that prohibit any storage of sensitive authentication data (SAD) and do not make any exceptions.”  Not that I was expecting any as the Council has a tendency of making a mountain out of a molehill at times.

Based on the responses, I would highly recommend that merchants take American Express’ advice and protect pre-authorization data with the same voracity as they do with post-authorization data.

Pre-Authorization Data – The Definitive Answer

Hot off the press from the PCI SSC and this month’s Assessor Newsletter.

Is pre-authorization data in scope for PCI DSS?

PCI DSS applies wherever cardholder data (CHD) and/or sensitive authentication data (SAD) is stored, processed or transmitted, irrespective of whether it is pre-authorization or post-authorization. There are no specific rules in PCI DSS regarding how long CHD or SAD can be stored prior to authorization, but such data must be protected according to PCI DSS while being stored, processed or transmitted.  Use of PTS-validated payment devices and PA-DSS validated payment applications can support PCI DSS compliance for the protection of data prior to authorization.

With respect to SAD, PCI DSS Requirement 3.2 prohibits storage of SAD AFTER authorization, even if encrypted. Whether SAD is permitted to be stored prior to authorization is determined by the individual payment brands, including any related usage and protection requirements.  Any permitted storage of SAD prior to authorization would be subject to strict conditions and controls above those defined in the PCI DSS.  Additionally, several payment brands have very specific rules that prohibit any storage of SAD and do not make any exceptions. To determine payment brand requirements, please contact the individual payment brands directly.

There we have it.  Pre-authorization data is in-scope with a number of caveats as dictated by the individual card brands.

Just to be clear, I have never argued that pre-authorization data was not to be secured with the same diligence as post-authorization data.  I just could not find anything in the PCI DSS that explicitly called out the coverage of pre-authorization data.  Past training had always explicitly referenced that the PCI DSS was for data stored after authorization, i.e., post-authorization.

Now I guess I am off to bug the card brands about their pre-authorization data retention rules if they are not posted out on their merchant security Web pages.

A Conundrum?

Bear with me on this as there is a point.  It just takes a lot of set up to get to that point.

I am working with a client that issues corporate credit cards to its employees.  The PCI SSC has issued FAQ #8715 that states that these corporate cards are not covered by the PCI DSS and that it is up to the individual card brands to dictate the controls required for securing these corporate credit cards.

The card brands are stating that while not covered by the PCI DSS, corporate credit cards do need to be appropriately secured (see requirement 3 for some recommended security methods).  As far as any drivers for securing these cards, the card brands point to any relevant personally identifiable information (PII) laws and regulations.  However, the card brands do point out that any post authorization data related to these corporate credit cards such as billing statements that show the full PAN are in-scope for PCI DSS compliance.

The PCI SSC has just issued a change to the call center FAQ stating that CVV/CVC/CID cannot be retained in digital recordings.  The rationale is that once the transaction is complete, the CVV/CVC/CID information that exists in recordings is now covered by the PCI DSS because it is now post authorization data.

Do you see the conundrum?  Under the logic used regarding the call center, one could argue that a credit card would be considered post authorization data once it is used for a transaction.  Obviously, that cannot happen as the card would have to be redacted and could not be used again.  However, I have a couple of clients that are doing just that and are trying to apply the PCI DSS to their Human Resources and Travel departments because they store the employees’ corporate credit card information including CVV/CVC/CID.

As I have explained it to them, the differentiator in all of this is that in the case of the call center, all of the data in question is under the control of the merchant and therefore the merchant is responsible to ensure the security of the information.  In the case of corporate credit cards, the corporation is not acting as the merchant as they are acting as the customer on behalf of their employees.  As such, they are allowed to have the card information as long as the employee legally acknowledges that fact and that the card information is appropriately secured.

The Missing Link In Call Center Recordings

Client discussions lately have been revolving around the new call center FAQ out on the PCI SSC Web site.  Most of our clients are arguing with us about why pre-authorization data is ending up in scope?  After all, when a customer places an order via the telephone, it is pre-authorization data.  The answer is that it all comes down to timing.

Everyone understands that call centers routinely record calls to ensure service quality.  For those call centers that provide order entry, those recordings have a high likelihood of recording information that the PCI SSC and the card brands consider sensitive such as the cardholder name, primary account number (PAN), expiration date and sometimes CVV/CVC/CID.

Here is where timing becomes important.

A customer calls into a call center to place an order or conduct any other transaction that requires a credit card.  Until that transaction is completed, any cardholder data provided is considered pre-authorization data by the card brands and the PCI SSC and is therefore not covered by the PCI DSS.

Once the transaction is completed, you are now in the post authorization realm and all information is subject to the PCI DSS.  Under requirement 3.2.2 of the PCI DSS, retention of the CVV/CVC/CID is not allowed.  Even though the recording is prior to the completion of the transaction, once that transaction is complete, the information becomes in-scope for PCI compliance and therefore cannot be retained.

The double edged sword in all of this is that you cannot use a compensating control to meet any of the requirements in 3.2.  As a result, your only alternative is to remediate the situation.


Call Center FAQ Changes – AGAIN

Apparently FAQ #5362 was not good enough and has been changed again.  In addition to some additional background information, the “if the data can be queried” language has returned as a qualifier regarding digital recordings.  See my post on this for additional information.

Of course these recordings can be searched.  There are all sorts of commercial and open source tools available for search audio recordings.

All this is going to do in my opinion is cause my clients to use this as an out for not doing the right thing regarding their audio recordings.

Call Center FAQ Significantly Changes

On January 22, 2010 the PCI SSC issued an update to their clarification regarding their FAQ on call centers storing CVV/CVC/CID in their call recordings.  The bottom line is that call centers are no longer allowed to store such cardholder information in recordings that are maintained digitally, regardless of whether they are encrypted.

The new FAQ (#5362) states that:

“It is a violation of PCI DSS requirement 3.2 to store any sensitive authentication data, including card validation codes and values, after authorization even if encrypted.

It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization; as card data can easily be extracted using freely available software.

On an exception basis, storage of CAV2, CVC2, CVV2 or CID codes in an analog format after authorization is allowed; as these recordings cannot be data mined easily. However the physical and logical protections defined in PCI DSS must still be applied to these analog call recording formats.

Audio recording solutions that prevent the storage or facilitate the deletion of CAV2, CVC2, CVV2 or CID codes and other card data are commercially available from a number of vendors. All other recordings containing cardholder data captured by call centers must be protected in accordance with the PCI DSS, including PCI DSS requirement 3.4.”

I am assuming that this change in policy is the result of the PCI SSC determining that, regardless of what we have been told in the latest reports from Verizon Business Services and other sources, there have been breaches of cardholder data that were the result of compromising digital audio recordings.

A big thank you to Emma Jenkins at VeriTape for pointing out this change.

UPDATE:  It appears that the FAQ has been changed again.  It now reads “It is therefore prohibited to use any form of digital audio recording (using formats such as wav, mp3 etc) for storing CAV2, CVC2, CVV2 or CID codes after authorization if that data can be queried; recognizing that multiple tools exist that potentially could query a variety of digital recordings.” adding back the “if that data can be queried” language.  There are plenty of commercial and open source tools that will search audio recordings, so of course this data can be queried.  Not sure of the motive here in this change.

Looking Outside Of “The Box”

I have been struggling with a client recently regarding what is involved in the scope of a PCI compliance assessment.  It appears from these discussions that a lot of people either forget or are unaware that there is more to the PCI DSS than technology.  It also involves a lot of manual procedures as well.  People seem to forget about all of the ancillary activities that surround credit cards.

They forget about the manual processes that can occur when their fancy integrated POS systems are unavailable.  This was driven home a couple of months ago when a client had four locations affected by a telephone line cut.  This outage affected the long line trunks of a couple of major carriers out of a good sized community.  The backup process for this organization is to manually fill out a multi-part, carbonless credit card receipt for the customer and have the customer sign the receipt.  The customer gets a copy and the original is retained by the organization and then manually keyed into the POS system once communications is restored.  During the two and a half hour outage, this organization generated over 2,000 receipts at the four locations.  The kicker in all of this is that the receipts not only contain the cardholder’s name, PAN and expiration date, the clerks have also been instructed to capture the CVV/CVC so that they can prove it was a card present transaction.

My first question was, “What happens to all of those receipts after they get rekeyed into the POS system?”

“Why, they get thrown out,” was the matter of fact reply.

“Do they get shredded?” I asked.

“We do not have shredders out at our stores,” the CFO responded.

I explained that those receipts were in-scope for PCI compliance and since they were just being discarded in the trash, the organization was not in compliance with a number of PCI DSS requirements.  You would have thought I had tossed cold water on them.  They were shocked.  They argued that the PCI DSS was all about computers and storing cardholder data on the computers.  After all, that is why the head of IT was leading the compliance effort.  After a half an hour of discussion, I finally was able to convince them that the PCI DSS was all about everything post-authorization, electronic or manual.

The resolution to this situation was that the organizations now requires that all manual receipts are returned to their Corporate office in the store’s daily balancing bag that is picked up by a commercial security courier every morning.  Once receipts are entered at the store, they are put in the store safe until the courier pickup.  At corporate, the accounting department takes the receipts and, using a “Sharpie,” redacts the PAN to the last four digits and redacts the CVV on the receipt, images the receipt and then puts it in a shredder bin for secure destruction.

A couple of years ago, I was at a client that stores three years worth of manual credit card receipts in an office at their corporate headquarters.  This is a standard office that was meant to hold four people and it could barely hold the one person and the imaging equipment used to image all those receipts.  This office was not locked during business hours and there were no cameras near this office.  Everyone in the facility knew what was stored in this office and since the office had windows, everyone could see into the office.  The corporate facility itself required card key access to gain entry and there is video monitoring on all entrances, the loading dock and the data center.  As usual, the first push back was regarding the fact that the PCI DSS had nothing to do with paper, it was all about electronics.  Even their internal auditors knew this was not true, but the CFO persisted.  After much persuasion, the CFO relented and we began to discuss the situation.

The resolution here was to extend the automated access control system to this office.  We decided that the windows in the office were a deterrent since anyone in the office that did not belong would stand out through the windows as other employees walked by.  The cost of adding video monitoring to this location was determined to be too expensive, so it was not implemented.

My final example is in regards to back office activities.  Last year I had a client that had outsourced all of their credit card processing to a major vendor of such services.  As a result, management felt they were off the hook for PCI compliance.  They explained everything about their outsourcing and then asked, “What can we possibly be responsible for?”  A fair question.

So I asked, “Who takes care of chargebacks and disputes?”

The Vice President of Accounting said that their department handled those, but they were all handled through the third party’s system, so the CHD was not on their organization’s systems.

My next question was, “Do they get any reports or screen shots out of the system to use in researching the chargebacks and disputes as well as for their files to show how the situation was resolved?”

The head of the department said, “Why yes, all of the time.  How else would we be able to do the work and prove to the card brand that we had taken care of the problem?”

I then went into the explanation that all of this research material was to be protected just like the credit card data that was on the third party’s systems.  Again, there was a lot of push back from the accounting people and other management as they felt that all of this was out of scope.  I went back to quoting from the PCI DSS and explained that this was all post-authorization data and was required to be protected.

The resolution to this situation was not so simple.  It turned out that the people handling chargebacks and disputes also handled some other accounting duties within the department, making physically segregating them away from the rest of the department not possible.  What they did was isolate the records for chargebacks and disputes in a locked room with only the department head and the Vice President of Accounting having the keys.  If one of the clerks wanted to work on chargebacks or disputes, they had to sign out the key to get into the room.  When their work was done, they again used the “Sharpie” technique to redact the PAN and CVV/CVC from all paperwork and it was then filed with their completed work.

I hope you now see that there is more to the PCI DSS than technology.  So, the next time you are out looking for cardholder data, do not forget to look outside of the box.

Pre-Authorization Data

Nothing causes more confusion than the discussion of pre-authorization data.  To add to the confusion, the PCI DSS is only relevant for post-authorization data.  In fact, the PCI SSC has a special working group that is developing the standards for pre-authorization data.  And if that is not enough, most people are totally unaware of the concept of pre-authorization data and yet all of us run into it every day.

The first comment I usually get regarding pre-authorization is where do I get the idea that the PCI DSS does not cover pre-authorization data?  At the very first PCI Community Meeting, there was a whole hour long session devoted to pre-authorization data.  It was at this session that the card brands stated that pre-authorization data was not covered by the PCI DSS.  And if you read the PCI DSS, it deals only with the processing, transmission and storage or cardholder data.  While all of these activities occur during the pre-authorization phase, if you really read the PCI DSS, all of the language refers to the transaction after it has been authorized.  However, the current release of the PA-DSS does address pre-authorization data and its protection.

The most common example of pre-authorization data is at your local gas station or convenience store.  When you go to fill up your vehicle and you use a credit card, you swipe your card before you ever pump a drop of fuel.  Have you ever wondered what goes on between that card swipe and you complete filling your vehicle?

When you swipe your credit card, the track data is read and a pre-authorization transaction is sent through to the gas station’s processor for some fixed amount, typically the amount is for approximately $75, more if the station is on an Interstate highway.  This is done to ensure that your credit card has enough left on its limit to pay for your fill up.  Once you complete filling your tank, the pump completes the transaction by submitting the actual cost of the fuel to the processor and the transaction is completed.  However, all the while that you were filling your tank with fuel, the station’s computer system has your credit card data until the transaction is completed.  Until your transaction is approved or declined, the data is considered pre-authorization data.

Another example of pre-authorization data is when you check into a hotel.  When you make your reservation, you provided a credit card for the hotel to guarantee your reservation.  Whether through the hotel’s call center, Web site or the location itself, your credit card information is maintained on file so that you can be charged if you fail to cancel the reservation.

When you finally check in, the front desk clerk swipes your card as part of the check in process.  Based on the number of nights you are staying and some other guest averages, the hotel again issues a pre-authorization transaction to their processor to make sure your credit card will be able to take care of the likely charges for your stay.  All of this is considered pre-authorization.  Your credit card information is not cleared from the hotel’s system until you check out.  As a result, your credit card data can be in the hotel’s systems from a few weeks or months to even years.

There are other examples, but I think you have the picture.  Again, while the PCI DSS currently does not address pre-authorization data, the PCI SSC and the card brands have made it abundantly clear that pre-authorization data is to be protected with the same zeal as post-authorization data.  That means encrypting it and restricting access to it.  The reason the PCI SSC has not issued any directives regarding pre-authorization data yet is that it is a complicated environment and cannot be dealt with in a simple manner with the same approach working for all occurrences.

So, while pre-authorization data is not covered by the PCI DSS, you must do everything you can to protect it.