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

[admin]

[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:

[EarthAirFire]

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.

[apollon]

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

[Roger Nebel]

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.