If your organization is going to use disk encryption as a means to render data unreadable, you need to comply with PCI Requirement 3.4.1. PCI Requirement 3.4.1 states, “If disk encryption is used (rather than file or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. This requirement applies in addition to all other PCI DSS encryption and key-management requirements.”

The PCI DSS states, “Full disk encryption helps to protect data in the event of physical loss of a disk and therefore may be appropriate for portable devices that store cardholder data.”

The authentication credentials used to decrypt the drive must be separate from the authentication credentials that are used to log into the operating system. The intent behind this requirement is to create a separation so that if the user’s authentication credentials are compromised, that doesn’t automatically give someone access to the data set that has been decrypted.

Using whole disk encryption makes it difficult to meet PCI Requirement 3.4, because, as Jeff Wilder explains, one you’ve booted the system and mounted the drive, there’s transparent data encryption that’s accessible to the end user. The PCI DSS explains, “Disk-level encryption encrypts the entire disk/partition on a computer and automatically decrypts the information when an authorized user requests it. Many disk-encryption solutions intercept operating system read/write operations and carry out the appropriate cryptographic transformations without any special action by the user other than supplying a password or passphrase upon system startup or at the beginning of a session. Based on these characteristics of disk-level encryption, to be compliant with this requirement, the method cannot use the same user account authenticator as the operating system, or use a decryption key that is associated with or derived from the system’s local user account database or general network login credentials.” If you’re using whole disk encryption to meet Requirement 3.4, be prepared to have a conversation with your assessor about the controls that you’re using.

“If you’re going to be using hard disk encryption as a means for meeting the 3.4 Requirement (for rendering your data unreadable) and you’re using whole disk encryption to do that, we have a requirement that the authentication credentials that you use to decrypt the drive be separate from the authentication credentials that are used to log in to your operating system. The reason for this is that if a hacker physically compromises your Windows box, for instance, those decryption keys actually reside on the physical device within the registry. Microsoft BitLocker can be configured appropriately to do this, where you have separate authentication credentials, but the point of this particular requirement is to cause a separation so if the user’s authentication credentials are compromised, that doesn’t automatically give someone access to the data set that has been decrypted. We want to make sure we have separate authentication credentials for doing that. From an assessment perspective, we’re going to talk to the staff and we’re going to look at how you’ve implemented whole disk encryption, if you’ve done so, and make sure that the authentication credentials that are subject to that are separate. As a point of conversation and understanding, it’s going to be necessary that you understand that whole disk encryption, when it mounts the drive, the cardholder data is rendered readable. As part of this test, we still have to see that the cardholder data is rendered unreadable, so using whole disk encryption kind of gets really difficult for meeting Requirement 3.4, which is rendering it unreadable, because once you’ve booted that system and mounted that drive, there’s transparent data encryption that’s used, and it’s accessible to the end user. So just be cognizant of that and if you’re using whole disk encryption to meet this requirement, be prepared to have a conversation with your assessor about the controls that you’re using in order to meet the 3.4 Requirement. “

What is PCI Requirement 3.4?

PCI Requirement 3.4 requires, “Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: one-way hashes based on strong cryptography (hash must be of the entire PAN), truncation (hashing cannot be used to replace the truncated segment of PAN), index tokens and pads (pads must be securely stored), strong cryptography with associated key-management processes and procedures.”

What are Primary Account Numbers (PAN)?

PAN stands for Primary Account Number, and it is the most critical piece of cardholder data when it comes to PCI compliance. Since the PAN can be used in conjunction with other pieces of cardholder data, there are extra steps and regulatory compliance that must be met in order to ensure user data is properly secured.

The PCI DSS says, “The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.”

It should be noted that PCI DSS Requirements 3.3 and 3.4 apply only to PAN. If PAN is stored with other elements of cardholder data, only the PAN must be rendered unreadable according to PCI DSS Requirement 3.4.

How Do I Render PAN Unreadable?

Your assessor should ask what means and methods your organization is using to protect PAN. In any place that PAN is stored, it needs to be rendered unreadable. There are a couple of methods that your organization can use to accomplish this:

  • One-way hashes based on strong cryptography are appropriate to use when there is no need to retrieve the original number, because one-way hashes are irreversible.
  • Truncation permanently removes some of the PAN data so that only a portion (not to exceed the first six and last four digits) of the PAN is stored.
  • Index tokens and pads can be used. The PCI DSS defines them as, “An index token is a cryptographic token that replaces the PAN based on a given index for an unpredictable value. A one-time pad is a system in which a randomly generated private key is used only once to encrypt a message that is then decrypted using a matching one-time pad and key.”
  • Strong cryptography with associated key-management processes and procedures. If the data is encrypted, the assessor needs to verify that you’re using an industry-accepted encryption protocol.
  • Controls that prevent the correlation of hashed and truncated versions of PAN will help to defend against hackers and work to ensure that the original PAN remains unreadable.

What Happens During the PCI Assessment?

We recommend that you take a full inventory of the places where your data resides before the assessment, so that when your PCI audit process begins, you can give your assessor documentation about your systems, files from data repositories, samples of removable media, and samples of audit logs to examine and ensure that the PAN is unreadable.

More PCI-DSS Compliance Resources 

PCI Demystified Video Series 

Beginner’s Guide to PCI Compliance 

When Will You See the Benefit of an Audit? 

PCI Requirement 3.4

There are going to be situations within your organization where you might need to store electronic data that contains sensitive information. Whether this be PCI data or whether this be social security numbers, it’s really in your best interest to ensure that data is encrypted. However, specific to PCI DSS Requirement 3.4, it states that you need to render this media or this information unreadable in any place that it’s stored. There’s a couple of ways that we can go about doing that. We can encrypt that data; if you encrypt it, it needs to be done with a strong protocol.

We can truncate the data; understand that if we truncate the data – where we have 16 digits in the credit card number, the first 6 and the last 4 can be displayed with no problem – if you remove those middle 6 numbers, that information is no longer really considered cardholder data. It can also be hashed with a 1-one hashing algorithm; understand that the hashing algorithm needs to be strong as well. The DSS also talks about using index tokens and pads; we don’t see those often in the assessment field. One of the things we’ll be doing as assessors is asking about how you’re protecting this data. What are the methods and means that you’ve implemented in order to render the information that you have unreadable. If you’re using encryption, we’re going to look at your encryption algorithms.

We’re going to look to see how you’ve actually implemented this. Understand that it is not acceptable to roll your own encryption. Encryptions are often broken and we want to make sure that you’re using an industry-accepted encryption protocol. As part of that, we’re also going to be asking to view that data. If you have it in a database, we’re going to be asking your database administrators to run queries against that data. We’re going to be looking to see that the data is not rendered in clear text. There might be situations where you receive a notification of a charge back from your bank. In situations like that, we often find that people will take and write that cardholder information down in an Excel document in the accounting department.

One of the things that we’d recommend you do, for your own compliance, is to perform a full inventory of all of the places where your data might reside. This would include your accounting department as well as any of the systems that are used to interact with that data. We have tools that we will ask you to run; card recon is one of those tools. We may ask you to run it on a sample of systems and that particular tool will run through all of the assets to try and identify if there is clear text cardholder data there. So it’s important that we protect this information, whether it’s PII data, PHI, financial information that you might retain on behalf of a third party. If you are storing cardholder data to support your business, it needs to be rendered unreadable.

What is PCI Requirement 3.3?

PCI Requirement 3.3 states, “Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.”

What is PAN?

The PCI DSS says, “The primary account number (PAN) is the defining factor for cardholder data. If cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment (CDE), they must be protected in accordance with applicable PCI DSS requirements.”

Why should PAN be masked?

PCI Requirement 3.3 relates to the protection of PAN being displayed, not stored. If full PAN is displayed on computer screens, paper receipts, faxes, reports, or printouts, the data could be stolen by an unauthorized or malicious individual. They could use this information to make fraudulent transactions. By displaying the full PAN only to those with a business justification, your organization will minimize the risk of malicious individuals from stealing or having access to PAN data. Once again, we believe in the mantra of, “If you don’t need it, there shouldn’t be access to it.”

The PCI DSS says, “The masking approach should always ensure that only the minimum number of digits is displayed as necessary to perform a specific business function. For example, if only the last four digits are needed to perform a business function, mask the PAN so that individuals performing that function can view only the last four digits. As another example, if a function needs access to the bank identification number (BIN) for routing purposes, unmask only the BIN digits (traditionally the first six digits) during that function.”

What happens during a PCI assessment?

Your PCI assessor should take inventory of the individuals that would have a business need to see full PAN and what that business need is. If an individual does not need to see the data, an assessor needs to see that the information has been truncated, redacted, or masked. At a maximum, there should be no more than the first 6 and last 4 digits of the PAN being displayed to individuals that do not need to see it.

An assessor will also take inventory of all the places where cardholder data is displayed – this could be a call center, someone printing receipts, etc. Then, your assessor will look at the data to see that that full PAN has been truncated, redacted, or masked.

Learn more about all the PCI DSS requirements in our detailed video series, or contact us with any questions you may have about your organization’s PCI compliance.

“Once again, we go with the mantra of “If we don’t need it, there shouldn’t be access to it.” PCI DSS Requirement 3.3 if individuals do not need access to the full cardholder numbers, it’s expected that you mask that data. We’ll describe what that looks like in a few moments. As an assessor, what we’re going to be looking for is an inventory of the individuals within your organization that would need to see the full cardholder data. It’s often believed that a database administrator, because of the nature of what they’re doing, needs to see the full cardholder data; that’s often a misnomer. Just because a database administrator is a DBA, that doesn’t necessarily grant them the permissions to view cardholder data. What we’re looking for – and this kind of marries into Requirement 7 – is the role of the individual that might be viewing this cardholder data, and understand what it is about their job or function that requires them to view the full cardholder data. In situations where the individuals do not actually need to see the cardholder data, we’re going to look to see that that information is truncated or redacted or masked in some respect. At a maximum, there should only be no more than the first 6 and last 4 characters of the cardholder data being displayed to individuals that do not need to see it. If an individual needs to see it to support their business, that’s quite alright, there’s no problem with that. From an assessment perspective, the assessor is going to look at all places where the cardholder data is displayed. You might have a call center that’s viewing cardholder data, you might be printing cardholder data for receipts – there’s multiple places where this information might be displayed. Once we’ve received that inventory, we’re going to ask to physically look at that data to see that it’s either masked or truncated. Truncated means that we’ve actually moved the data, more than the first 6 or the last 4. Masking is actually how the data is displayed. “

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.”

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.