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

PCI Requirement 3.1 requires organizations to securely delete data that is not required to be retained for business or legal requirements. Why is complying with PCI Requirement 3.1 important? So that cardholder data cannot be recreated by malicious individuals.

PCI Requirement 3.1 states that organizations should, “Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes…” PCI Requirement 3.1 aligns with the methodology of many other PCI requirements: If you don’t need it, get rid of it. It is acceptable to retain data that’s required by contract, for business reasons, or for legal reasons. However, if you’re retaining cardholder data that is not required, it becomes a liability for your organization. The PCI DSS states, “In order to define appropriate retention requirements, an entity first needs to understand their own business needs as well as any legal or regulatory obligations that apply to their industry, and/or that apply to the type of data being retained.”

During a PCI assessment, assessors need to examine your data retention and disposal policies, which should outline what data needs to be retained, where that data resides, why you’re keeping it, and the length of time that you’re keeping it. Then, assessors will survey the data you have within your custody. Taking inventory is an important part of the assessment process; whether it’s physical print media or electronic, assessors need to see where the data is located. Then, after taking a sample of the data, assessors will compare the life of that data against your organization’s data retention and disposal policies.

PCI DSS Data Retention Requirements

When the PCI DSS describes data retention requirements, it stipulates that cardholder data storage should be kept to a minimum. If you don’t need it, get rid of it. Unless cardholder data needs to be retained for business or legal reasons, it needs to be securely deleted. When it gets past this point, it becomes a liability to your business.

Your organization’s data retention and disposal policies, procedures, and standards should document how you securely delete information. Assessors expect that if data has been securely deleted, it can never be recreated. Print media should be shredded and electronic data should be overwritten on a hard drive. The process of securely deleting information should be done either manually or by an automatic process and should be done at least quarterly.

“Continuing on with the mantra of, “If you don’t need it, you should get rid of it,” we have to look at the assets or the information that you have within your custody. If you’re storing credit card data, storing medical data, or storing client data because it’s required by contract, for business reasons, for legal reasons – whatever the reason is, it’s alright, there’s nothing wrong with that – however, if you’re maintaining this information and it’s not required that you do so, it becomes a liability to your organization. PCI Requirement 3.1 states that if you don’t need the data, you need to get rid of it. There’s a couple of requirements around what that looks like. You either have to have a manual process where you’re manually going through and looking at your physical inventory. You might have printed media, perhaps, residing in an offsite storage facility. You might have electronic data residing in a database or in flat files somewhere. When we start with the assessment of Requirement 3.1, we’re going to ask for your Data Retention and Disposal Policies. These Data Retention Policies should state the type of data that you’re keeping, why you’re keeping it, and the length of time that you’re keeping this data. The assessor will perform an inventory of where this data is located. Whether it be electronic or whether it be physical print media, we’re going to be performing an inventory of where that media is at. We’re going to be sampling that data, then comparing the life of that data against your Retention Policies and Procedures. Once again, if you need the data, there’s no problem with keeping it. However, if you don’t need it, it should be disposed of. We’re then going to look at your Data Disposal Policies, Procedures, Standards, and documentation and look at how you’re securely removing that information. This process of removing that information should be done at least quarterly. It needs to be either a manual or automatic process, but the process needs to be run quarterly. We’re going to look to see that you securely delete that data, understanding that “delete” is different than the “secure delete” function. When the term “secure delete” is used, we’re looking to ensure that the data can never ever be recreated or re-rendered. If it’s print media, we’re looking to see that it’s been turned into confetti. If it’s electronic media, we’re looking to see that the data has been overwritten on a hard drive. Requirement 3.1 requires that if you do not need the data to support your business or your legal requirements, that data needs to be removed. “