[PCI DSS 1.x] 3.2 Do not store sensitive authentication data after authorization (even if encrypted).

[READ-ONLY] Archives [RETIRED] PCI DSS v.1.x Questions and Answers Protect Cardholder Data
1

[PCI-DSS] 3.2 Do not store sensitive authentication data after authorization (even if encrypted).
Sensitive authentication data includes the data as cited in the following Requirements 3.2.1 through 3.2.3:

3.2 If sensitive authentication data is received and deleted, obtain and review the processes for deleting the data to verify that the data is unrecoverable.

For each item of sensitive authentication data below, perform the following steps:

2

Document Imaging - CVV

Hi there,

Let’s imagine the following scenario:

A document scanning service provider is in charge of receiving mail forms containing CHD + CVV (since the card is not present) on behalf of one of their customers. The process follows as below:

1 - Forms containing CHD + CVV are received by the SP by mail.
2 - Service provider scans the form and sends it to the customer (via secure ftp) so the card can be charged (whatever the service/product is, i.e. subscribing to a periodic magazine)
3- The CHD information is inputted into the customer system for processing, and the received file is deleted according to PCI-DSS requirements.

Few questions arise:

  • PCI-DSS says that sensitive information cannot be stored AFTER authorization. The scenario proposed above clearly describes a situation BEFORE the authorization. Can the CVV be stored/transmitted anyways?
  • The Service Provider is also responsible for storing customer’s information for a certain period of time; what should be done to protect CHD and CVV in this case?

Regards,

Earth,Air,Fire.

3

Hi,

here my thoughts of that:

Both the service-provider and the merchant needs to make sure that storage (and so access to the scan-files), removal and transfer is secure according to PCI-DSS.

So the service-provider needs to work according to PCI-DSS and needs to design their processes after that (inclusing policies, rules, employee education/security awareness and so on). So the Service provider needs to fullfill the PCI-DSS parts where he provides service. He do not need a partly certification but when the merchant get’s certified the QSA may check the service-provider too.

The merchant needs to do the same in my eyes because he has cardholder-data in the scan-files after transfer in their environment and he needs to make an PCI-DSS-certification depending on his level. And there needs to be an agreement with the service-provider that fullfills the needs of PCI-DSS according to the sharing of cardholder-data.

I do not see any problem in having the CVV in the scans because as you said formally it is “before authorization”. It is not nice to have it that way, but in this case the merchant has no real other chance.

Ingo Fischer

4

The CVV can be stored until authorization, after that it must not be stored. This was so that merchants who process in batch mode could hold on to the CVV until they process their batch and then get authorization which might take a day or two. After that it must not be stored. Thus once there is authorization, all the places the CVV had been stored, whether on paper or in a file, must be cleansed of the CVV. The SP and the merchant must not keep it post-authorization. Paper copies need to be shredded, and any and all files, database records, etc., must be securely erased of the CVV.

BTW, the scanning SP in this case must also be fully PCI compliant, and if they are not, the merchant is liable if one day there is a breach at the SP just as though the merchant themselves did the scanning. The merchant should ensure their contract with the SP is clear on this.

5

Hi,
We have developed a system that allows some groups of users to capture and store credit card details.
These credit card details are used for Hotel booking guarantees. Registrants register for an event (conference, congress etc), indicate their hotel preferences and provide a credit card guarantee.

Now we are running into 1 specific problem with the SAD, more specifically, the CVC.

These credit card details are eventually provided to the various hotels where the bookings are made.
However, the cards do not get charged until either the person checks in or checks out of the hotel.
Some credit cards may never be charged, since the person may even prefer to use a different card or use another payment method at the time of check in or check out itself.

So at the time of storage, everything is pre-auth.
However, we as an entity do not know when one of these cards actually gets charged, so we never actually know when it goes from pre-auth to authorized.
This makes it practially impossible to delete the SAD after authorization, and as a result, some of this data may be stored after authorization.

We have placed a number of mechanisms in place to purge these details.
Mainly, we delete all credit card data after the end of the event.

I have a feeling that this is not PCI compliant as such, but we might get away with some compensating controls.

What is your take on this?

Cheers,
UM