PCI DSS Requirement 3: Protect Stored Account Data

Public exposure of stored account and transaction data, either intentional or unintentional, can cause serious damage to a merchant. This is why the PCI SSC has created requirement three of the PCI DSS, which outlines the means and methods of protecting this sensitive data. 

Encryption, masking, hashing, and tokenization - to name a few - are critical ways to protect account data and are necessary for maintaining compliance. This is because, by properly protecting this data, you can safeguard against it getting into the wrong hands, as its stored form is effectively useless for malicious individuals.

However, following the first rule of sensitive data is also paramount here: collecting and storing only absolutely necessary data, nothing more. Doing so limits the value of the data should it ever be decrypted.

For additional details on all 12 of the Requirements, read our PCI DSS Requirements overview.

Requirement 3 Details and Sections

PCI DSS Requirement 3 has seven total sections that detail specifics on protecting stored account data.

The requirement sections are:

• Requirement 3.1: The processes and mechanisms to protect stored account data are defined and understood.
• Requirement 3.2: Account data storage is kept to a minimum.
• Requirement 3.3: Sensitive authentication data (SAD) is not stored after authorization.
• Requirement 3.4: Access to full primary account number (PAN) and the ability to copy cardholder data are restricted.
• Requirement 3.5: PAN is secured wherever it is stored.
• Requirement 3.6: Cryptographic keys used to protect stored account data are secured.
• Requirement 3.7: Whenever cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented.

Requirement 3.1: The processes and mechanisms to protect stored account data are defined and understood.

All companies that need to maintain PCI compliance should comprehensively outline all the policies and procedures necessary to protect stored account data. Without this, critical responsibilities could be missed, and account data could be inadvertently exposed.

Defined approach requirements include:

• Requirement 3.1.1: All security policies and operational procedures identified in Requirement 3 are documented, up-to-date, in use, and known to all impacted parties.
• Requirement 3.1.2: Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.

Requirement 3.2: Account data storage is kept to a minimum.

A good data security practice is to store only data that is absolutely necessary to keep; otherwise, do not store it. PCI DSS 4.0 makes this practice a requirement, and offers guidelines around retention time for stored data, as well as the confirmation that deleted data has been properly removed.

Defined approach requirements include:

Requirement 3.2.1: Account data storage is kept to a minimum through data retention and disposal policies, procedures, and processes that include at least the following:

• Coverage for all locations of stored account data.
• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization.
• Limiting data storage amount and retention time to that which is required for legal or business requirements.
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.
• A process for verifying, at least quarterly, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable. 

Requirement 3.3: Sensitive authentication data (SAD) is not stored after authorization.

Requirement 3.3 prohibits storing SAD after the authorization process has completed. This requirement is meant to prevent malicious parties from taking the data to generate counterfeit payment cards for fraudulent transactions.

Defined approach requirements include:

• Requirement 3.3.1: SAD is not retained after authorization, even if encrypted. All SAD is rendered unrecoverable upon completion of the authorization process.
  • Requirement 3.3.1.1, Requirement 3.3.1.2, Requirement 3.3.1.3: The full contents of any track, the card verification code, and the personal identification number (PIN) are not retained upon completion of the authorization process.
• Requirement 3.3.2: SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography. 
• Requirement 3.3.3: (Additional requirement for issuers and companies that support issuing services) Any stored sensitive authentication data is limited to that which is needed for a legitimate issuing business need and is secured and encrypted using strong cryptography.

Requirement 3.4: Access to full primary account number (PAN) and the ability to copy cardholder data are restricted.

Displaying the full primary account number (PAN) on receipts, screens, and devices can result in the data getting into the wrong hands; therefore, this should be used only when necessary. Likewise, access to the PAN should only be available to those with explicit authorization and requirement to do so.

Defined approach requirements include:

• Requirement 3.4.1: The PAN is masked when displayed and only personnel with a legitimate business need can see more than the Bank Identification Number (BIN) and last four digits of the PAN.
• Requirement 3.4.2: When using remote access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need. 

Requirement 3.5: PAN is secured wherever it is stored.

As outlined in most sections of Requirement 3, storage of plaintext data should be avoided to reduce the value of the data itself should it ever get into a malicious individual’s hands. This section is no different, with requirements to avoid storage of the cleartext PAN and details on the cryptography requirements for stored PAN.

Defined approach requirements include:

• Requirement 3.5.1: PAN is rendered unreadable everywhere it is stored by using any of the following approaches:
  • One-way hashes based on strong cryptography of the entire PAN,
  • Truncation (hashing cannot be used to replace the truncated segment of PAN),
  • Index tokens, or
  • Strong cryptography with associated key-management processes and procedures. 
• Requirement 3.5.1.1: Hashes used to render PAN unreadable are keyed cryptographic hashes of the entire PAN, with associated key-management processes.
• Requirement 3.5.1.2: If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only on removable electronic media, or it is also rendered unreadable via another mechanism that meets Requirement 3.5.1. 
• Requirement 3.5.1.3: If disk-level or partition-level encryption is used (rather than file-, column-, or field-level database encryption) to render PAN unreadable, it is managed as follows:
  • Logical access is managed separately and independently of native operating system authentication and access control mechanisms.
  • Decryption keys are not associated with user accounts.
  • Authentication passwords and keys that allow access to unencrypted data are stored securely. 

Requirement 3.6: Cryptographic keys used to protect stored account data are secured.

Cryptographic keys must be strongly protected as anyone who gains access to them will be able to decrypt the underlying data. This is powerful, and can become devastating to a merchant if the keys get in the wrong hands.

Defined approach requirements include:

• Requirement 3.6.1: Procedures are implemented to protect stored account data against disclosure and misuse, by protecting cryptographic keys through means that include:
  • Requirement 3.6.1.2: Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times:
    • Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key.
    • Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device.
    • As at least two full-length key components or key shares, in accordance with an industry-accepted method. 
  • Requirement 3.6.1.3: Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary. 
  • Requirement 3.6.1.4: Cryptographic keys are stored in the fewest possible locations. 

Requirement 3.7: Where cryptography is used to protect stored account data, key management processes and procedures covering all aspects of the key lifecycle are defined and implemented. 

Following data security best practices, cryptographic keys should always be protected by means that can best ensure sensitive data remains secure and in the hands of the appropriate parties only.

Defined approach requirements include:

• Requirement 3.7.1: Key-management policies and procedures are in place that include generation of strong cryptographic keys used to protect stored account data.
• Requirement 3.7.2: These policies include secure distribution of cryptographic keys used to protect stored account data. 
• Requirement 3.7.3: These policies include secure storage of cryptographic keys used to protect stored account data. 
• Requirement 3.7.4: These policies are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:
  • A defined time period for each key type in use.
  • A process for key changes at the end of the defined cryptoperiod.
• Requirement 3.7.5: These policies include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:
  • The key has reached the end of its defined cryptoperiod.
  • The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.
  • The key is suspected of or known to be compromised.
  • Retired or replaced keys are not used for encryption operations.
• Requirement 3.7.6: Where manual cleartext cryptographic key-management operations are performed by personnel, these policies include managing these operations using split knowledge and dual control.
• Requirement 3.7.7: These policies include the prevention of unauthorized substitution of cryptographic keys.
• Requirement 3.7.8: These policies include that custodians of the cryptographic key formally acknowledge (in writing or electronically) that they understand and accept their responsibilities.

How Basis Theory can help you Satisfy PCI DSS Requirement 3

Securing cardholder data in a CDE satisfies many PCI DSS requirements and provides companies greater control and flexibility over their payment stack. However, building and maintaining the necessary infrastructure and programs can require hundreds of thousands of dollars and months to implement and assess. Basis Theory provides the platform, infrastructure, and tools to secure cardholder data in minutes and without these costs and distractions.

As a PCI Level 1 compliant service provider, Basis Theory extends an independently assessed and approved CDE to customers. Combined with a suite of configurable tools, services, and tokens, companies can collect, secure, and share credit cards without bringing their systems into scope. This approach allows companies to avoid the costs and distractions associated with 95% of the requirements in the Payment Card Industry Data Security Standard (PCI DSS) while retaining complete control over their cardholder data.

*PCI DSS Requirement information contained in this post is for educational purposes only and references material from the guide "Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0" published by the PCI SSC in March 2022. Please refer to the PCI Security Standards Council website for the complete, up-to-date, accurate requirements.