Pre-Authorization And Post-Authorization (Part 2)

I discussed the concept of pre-authorization in a prior post.  Now it is time to cover post-authorization (aka “post-auth”) and the PCI requirements it drives.  Post-authorization is where the PCI DSS got started even though pre-authorization was always present.  That is because it was in post-authorization where merchants were losing cardholder data (CHD).  While this post is mostly about post-authorization, it still contains some important references and points about pre-authorization.

Post-Authorization

First, let us define what we mean by “post-authorization”.  Post-authorization starts immediately once a transaction has been processed and the payment has either been authorized or declined.  It is at this point that only the cardholder name, PAN (encrypted or tokenized) and expiration date are allowed to be stored in any post-authorization systems.

On page 8 of the PCI DSS, the PCI SSC provides an excellent chart on what can be retained and what must not be retained in post-authorization.

However, this chart also creates confusion regarding pre-authorization and post-authorization because it is not labeled as such and that the discussion on this topic occurs after the chart, not before it.  The following is from the second paragraph following the chart and is usually missed.

“Sensitive authentication data must not be stored after authorization, even if encrypted. This applies even where there is no PAN in the environment. Organizations should contact their acquirer or the individual payment brands directly to understand whether SAD is permitted to be stored prior to authorization, for how long, and any related usage and protection requirements.”

The first sentence makes it very clear that SAD must never be stored post-authorization.  The second sentence is to ensure that those entities that tokenize/encrypt the PAN do not think they can store SAD because they technically no longer have the PAN (believe it or not, people do think this is true and then claim it as such).  The last sentence was added to tell merchants to discuss with their acquiring bank whether or not they can store SAD as pre-authorization data.  While technically the merchant should have explicit approval from their acquirer for storing pre-authorization data, I can tell you from experience that very, very few merchants have such evidence.  Not so much because they did not ask (most do not), but even more so because acquiring banks do not recognize their responsibility for providing such approval and therefore are reluctant to provide it.

From a post-authorization perspective, any merchant that is storing SAD in a point of sale (POS) solution as pre-authorization data needs to have a secure delete or destruction process in place to remove the pre-authorization data once the card transaction completes (approval or decline).  But a very important point is that pre-authorization data stored for customer convenience in pre-authorization applications is not affected by this change in status.

For the fuel station example in the pre-authorization discussion, the POS system that is storing the encrypted SAD/CHD while you pump the fuel needs to securely delete that information when you complete pumping and the payment is processed.  In some cases, when you swiped your card at the pump, the system not only did the pre-authorization of your payment, but it also may have tokenized your PAN and now is holding that token, not the SAD/CHD.

To continue on with our hotel example.  The hospitality management system is going to pre-authorize payment and then either encrypt the PAN on that initial swipe/dip at check in or it may tokenize it for storage.  At check out, the PAN is either decrypted or the token is submitted for payment.

Most phone orders have the CHD directly entered into systems no different from any consumer buying something over the internet.  In fact, for a lot of call centers, the order is actually entered into the same Web-site that consumers use.  After all, why reinvent the wheel?

However, with telephone orders, there are going to be rare instances where systems are not available.  In those cases, merchants can take a couple of approaches.  During such an outage, I have clients that do not accept orders.  They tell their customers to call back later when systems are operational.  I have other clients that will take the order on a paper form in the name of customer service.  The forms are securely collected and stored until systems are back online.  The forms are then entered into the system(s) and then the people follow secure destruction procedures of the forms.  The important lesson is that either approach can be used depending on your organization’s customer service desires.  The only issue is ensuring security of the information if you choose the manual form approach.

For facsimile and mail order examples we definitely have the issue of the SAD/CHD existing on paper.  So you need to do something to secure that SAD/CHD once the form has been processed.  For facsimiles, the PCI DSS requires a secure facsimile solution be used.  The simplest way is to have a dedicated facsimile machine that is only used for receipt of orders.  This facsimile machine needs to be placed in a locked room or a locked cabinet so that only authorized personnel can access the facsimiles that come to that machine.

On the more automated side, I have seen simple solutions that utilize an outsourced facsimile solution through a secure gateway.  Customer service personnel can only view and print out the facsimiles to process them.  I have other clients that have sophisticated solutions that start out similar to the secure gateway, but the gateway delivers the facsimiles to secure printing solutions that allow the customer service person to use any printer on the network because they can only print after physically going to a printer and tapping their facility access card against a reader connected to the printer thus securing the output until the user is ready to print it.

In the case of mail orders, those require securing the mail upon receipt in the mail room from the post office.  The orders should be secured until they are picked up by customer service personnel or whomever in the organization is responsible for processing mail orders.  Only a limited number of customer service personnel should be allowed to pick up the mail at the mail room to take to the area for processing.  When picking up the mail, the person picking up should sign a log indicating that the mail was picked up, when it was picked up and by whom.  Once taken back to the processing area, the mail needs to be secured there until it is processed.

The easiest approach is what I call “Sharpie redaction”.  That involves using a black ink permanent marker (i.e., a Sharpie marker) and redacting the PAN to the last four digits, blacking out the three- or four-digit card verification code (if provided), copying the redacted form so that the redacted information cannot be read, filing away the copied form and destroying the original by shredding it.

To avoid the “Sharpie” approach, merchants are modifying their mail order and facsimile forms so that the portion containing the SAD/CHD are either at the top or bottom of the form and can therefore be torn off and securely shredded leaving the rest of the form able to be retained without the SAD/CHD.

These are all just examples.  There are many more ways that can also work.  But I prefer simple methods as that is always the easiest to implement and follow.

The bottom line is that, regardless of pre-auth or post-auth, the data needs to be kept secure and the processes used to secure it need to work in your organization consistently and effectively.

Advertisement