PCI Requirement 3.2 – Do Not Store Sensitive Authentication Data after Authorization
by Randy Bartels / July 28th, 2017
PCI Requirement 3.2 states, “Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely.”
Organizations in compliance with the PCI DSS should never store sensitive authentication data after authorization. Why? This data, which includes full track data, card validation codes or values, and PIN data, is incredibly valuable to malicious individuals because it helps them create counterfeit payment cards and fraudulent transactions. This is why PCI Requirement 3.2 is so important.
As the PCI Requirement 3.2 states, it’s permissible for issuing banks and service providers for issuers to retain sensitive authentication data, but it must be kept securely. The PCI DSS outlines this by stating, “Entities that issue payment cards or that perform or support issuing services will often create and control sensitive authentication data as part of the issuing function. It is allowable for companies that perform, facilitate, or support issuing services to store sensitive authentication data only if they have a legitimate business need to store such data.” If retained for a legitimate business reason, the information must be encrypted, access to the data must be restricted, and the information must be so protected that it cannot be found in the hands of unauthorized individuals.
When the PCI DSS describes sensitive authentication data, it’s referring to data like full track data, payment card validation codes or values, and PIN data. Sensitive authentication data is valuable to hackers because it helps them create counterfeit payment cards and fraudulent transactions.
Along with PCI Requirement 3.2 comes three sub-requirements:
- PCI Requirement 3.2.1 states, “Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data.”
- PCI Requirement 3.2.2 states, “Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization.”
- PCI Requirement 3.2.3 states, “Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.”
As an organization, you should never be storing sensitive authentication data after authorization. However, there are certain circumstances (if you’re a merchant or if you’re supporting issuers or if you’re an issuing bank) where there might be the need to do so. In those situations, if your organization is an issuing bank, or as a service provider you’re supporting issuers, it’s acceptable that you retain sensitive authentication information. However, this information needs to be securely kept. So we’re looking for, from an assessor perspective, that this information is encrypted, that you’re restricting access to it, and that this information does not ever get into the hands of unauthorized individuals. If you do not fall under one of these categories – an issuing bank, a service provider supporting an issuing bank – you may not retain sensitive authentication data after authorization, even if the data is encrypted. You should not be retaining if for reoccurring transactions. You do not need those CVV Values after the authorization. If you’re using them for reoccurring transactions, contact your acquiring bank and they will help you work through that. They will give you a specific authorization code or process where you can use the CVV or sensitive authentication data the first time, and then after that you won’t need to submit it again for your discount rate. So once again, you should not be storing sensitive authentication data after authorization, even if encrypted.
