PCI Requirement 3.2.1, 3.2.2 & 3.2.3 – Do Not Store the Track, Service Code, or PIN after Authorization
by Randy Bartels / July 28th, 2017
PCI Requirement 3.2 requires that organizations do not store sensitive authentication data after authorization, even if encrypted. Sensitive authentication data includes full track data (magnetic-stripe data or equivalent on a chip), CAV2/CVC2/CVV2/CID, and PINs/PIN blocks. 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.” If an organization were to store the full track data, it makes it much easier for a malicious individual who has stolen this data to use it to reproduce payment cards and make fraudulent transactions.
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.” Card validation codes protect “card-not-present” transactions like internet, mail order, or telephone order transactions. So, if a malicious individual obtained the card verification code, they can create fraudulent card-not-present transactions.
PCI Requirement 3.2.3 states, “Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.” PIN values, as the PCI DSS states, should only be known to the card owner or issuing bank. If this data is stolen by a malicious individual, they can execute fraudulent PIN-based debit transactions, like ATM withdrawals.
Your assessor should take inventory of all the places your organization could interact with sensitive authentication data. This means working with database administrators, running queries, looking through print media, looking through written media; any place where you’re storing sensitive authentication data, we’re going to look.
It’s important to note that if your clients are sending you sensitive authentication data in any way, you need to work to find a process for them to redact that data before they send it to you. Even if they’re sending this data as part of a data stream or set, this violates the PCI DSS, and your organization keeping this data is in violation of the PCI DSS.
“When we look at Requirement 3.2 of the PCI DSS, it requires that you do not store sensitive authentication data after authorization. You assessor should be working with you and performing an inventory of all the places where you could possibly interact with the sensitive authentication data. Whether it be the CDD, the CID, PIN block data, or track data, assessors will look at where you interact with that data. Even if you don’t interact with that data, we’re still required as assessors to test for this particular requirement. This particular requirement will always be tested for. We’re going to work with your database administrators. We’re going to ask them to run queries for us. We’re going to look at your print media. We’re going to look at your written media. Any place where you’re storing information, we’re going to ask to see that data to make sure that you’re not storing any of the track data, CID, CDD data – any of those 3-digit codes that are on the front or the back of the card. Understand that you may not store this data after authorization, even if encrypted. If your clients are sending you this information, you probably need to work with your clients to have them redact that data before they send it to you. If your clients are providing this information to you as part of a data stream or data set, they are doing so in prohibition of the DSS. If you, in turn, are retaining that data, you are in violation of this requirement. Work with your clients, if they are sending any of this data, to see how they can redact that data from the data set you receive.”
