PCI DSS Requirement 3: Protect stored cardholder data explained

PCI DSS Requirement 3 focuses on protecting stored cardholder data. It outlines specific measures that organizations must implement to safeguard sensitive information like credit card numbers. Requirement 3 mandates the encryption of stored cardholder data, ensuring that if this data is accessed, it remains unreadable and unusable to unauthorized individuals. Additionally, it emphasizes the importance of securely managing cryptographic keys used for encryption, including key generation, storage, and distribution. By adhering to Requirement 3, organizations can mitigate the risk of data breaches.

PCI DSS Requirement 3.1: Processes and mechanisms for protecting stored account data are defined and understood

This section is split into 3.1.1 and 3.1.2. Let's explore these in detail.

PCI DSS Requirement 3.1.1

PCI DSS Requirement 3.1.1 revolves around minimizing the storage of cardholder data (CHD) and sensitive authentication data (account data), and ensuring its secure disposal.

According to this requirement:

• Store only what's needed: Businesses should only store the minimum amount of CHD necessary for legal, regulatory, or business purposes. Don't hold onto data longer than required.
• Define retention periods: Establish clear guidelines for how long you'll retain different types of CHD based on specific needs (e.g., transaction data for tax purposes).
• Secure deletion process: Implement procedures for securely deleting CHD when it reaches the end of its retention period. This ensures sensitive data isn't lingering in your systems.
• Regular reviews: Conduct quarterly checks to identify and securely delete any CHD that exceeds the defined retention limits.

How to meet this compliance requirement:

Business implications

• Inadequate data protection processes can lead to costly data breaches, damaging your reputation, causing financial loss, and potentially legal repercussions.
• Entities will have to define retention periods and store only what's necessary.

Best practices to meet this requirement

• Develop comprehensive policies and procedures: Document clear and detailed policies outlining how you protect stored account data. These should cover areas like data retention, access controls, encryption practices, and incident response.
• Regular reviews and updates: Review and update your policies and procedures regularly to reflect changes in your business, technology, and the evolving threat landscape.
• Employee training and awareness: Train all personnel who handle or access CHD on your data protection policies and procedures. Regular training helps ensure everyone understands their role in protecting sensitive information.
• Accessibility and communication: Make sure your policies and procedures are readily accessible to all relevant personnel. Communicate these procedures clearly and effectively to ensure everyone is aware of their responsibilities.

PCI DSS Requirement 3.1.2

PCI DSS Requirement 3.1.2 ensures that everyone involved in handling CHD understands their specific duties and accountabilities regarding data security. Clearly defined roles and responsibilities are crucial for effectively implementing and maintaining PCI DSS controls.

This is because without formal assignment of roles and responsibilities, personnel may lack awareness of their daily tasks, leading to potential neglect of critical activities. Documentation of roles and responsibilities can be integrated into policies and procedures or kept in separate records. To ensure clarity, entities can incorporate a process where personnel acknowledge their acceptance and comprehension of their designated roles and duties.

One approach to document roles and responsibilities is through a responsibility assignment matrix, which outlines individuals' roles as responsible, accountable, consulted, or informed (often referred to as a RACI matrix).

How to meet this compliance requirement

Business implications

• Ineffective data security: Unassigned or unclear data security roles can lead to critical security tasks being overlooked or improperly performed. This increases the risk of data breaches and non-compliance with PCI DSS.
• Accountability gaps: In the event of a security incident, it can be difficult to identify who is responsible if roles and responsibilities are not clearly defined.

Best practices to meet this requirement

• Document roles and responsibilities: Create a formal document outlining data security roles and responsibilities. This can be part of your overall PCI DSS policy or a separate document.
• Assign roles and accountabilities: Clearly assign specific data security tasks and accountabilities to relevant personnel.
• Communicate expectations: Ensure all personnel understand their assigned roles and responsibilities. Regular communication and training are essential.

PCI DSS Requirement 3.2 Storage of account data is kept to a minimum

PCI DSS Requirement 3.2 focuses on protecting sensitive authentication data (SAD) after a transaction is authorized. This means once the transaction is processed, the institution cannot store any data, even if it's encrypted, that can be used to create a fake card. This translates to two main restrictions:

• No magnetic stripe data: The data on the back of the card can be copied to create duplicates. Therefore, do not store full track data or magnetic stripe information after transaction or authorization.
• No personal identification numbers (PINs) or encrypted PIN blocks: PINs are used for ATM withdrawals or transaction. Do not store this information after transaction, as it can be used for fraudulent transactions.

The account data storage is kept to a minimum with stricter data retention and disposal policy implementation. The data retention and disposal policies, procedures, and processes should:

• Cover all locations of stored account data including cloud environments and third-party service provider (TPSP) environments.
• Limit and set the data storage amount and retention time required just to meet the business requirements. In certain retention requirement cases, such as the temporary card number issuing for recurring payments and saving cardholder verification for future transactions, the retention period including the justification for why the account data is being retained should be documented.
• Define processes for secure deletion or making account data unrecoverable as per the retention policy.
• Set a process to check if the stored account data that is exceeding the defined retention period is being deleted at least once in three months.

How to meet this compliance requirement

Business implications

Entities must define a process to:

• Examine the data retention and disposal policies, procedures, and processes and keep them updated.
• Examine files and systems where account data is stored to verify that the data storage amount and retention time are not exceeding the requirements defined in the data retention policy.
• Set up mechanisms to ensure that account data is unrecoverable post deletion or disposal.
• Ensure that the TPSP, especially when account data is stored in the cloud environment, is ensuring and adhering to the data retention policy of the entity.

Best practices to meet PCI DSS requirement 3.2

• Ensure that account data including the primary account number or PAN (which is rendered unreadable), expiration date, card holder name, and service code are stored after authorization.
• Ensure to define data retention time, storage amount, and disposal policy of account data prior to the completion of the transaction or authorization process. Ensure that the retention time is kept to a minimum.
• While discovering the locations of stored account data, consider the possibility of data being moved and stored in different locations than originally defined. Include all systems, processes, and users with access to the data for data discovery.
• Define the retention requirements and time limits according to your business, legal requirements, or any other regulatory obligations that apply to your industry or the type of data being retained.
• Automate the data deletion process so that the SAD is deleted upon reaching the defined retention limit.
• Note that the deletion function in most operating systems is not a secure deletion process, as OSs allow data to be recovered. Therefore, set up a process or implement an application for secure deletion that makes the data unrecoverable.

Exceptions for issuers and supporting companies

• Business justification: Card issuing banks and companies that support issuing services like payment processors can store the sensitive CHD, but only if they have a documented business justification (a documented business justification refers to a formally recorded rationale explaining why specific access to CHD or SAD is necessary for a given role or function within an organization). Examples could include:
  • Issuing temporary card numbers for recurring payments
  • Enabling features like cardholder verification for future transactions.
• Strict security requirements: If storing this data, issuers and supporting companies must secure it strictly. This likely involves using strong encryption methods and robust access controls.

This requirement is further split into 3.2.1, 3.2.2, and 3.2.3. Let's explore these in detail.

PCI DSS Requirement 3.2.1

PCI DSS Requirement 3.2.1 specifically targets the storage of track data from magnetic stripe cards or similar data from chip cards.

• What is track data? This refers to the information encoded on the magnetic stripe on the back of a card or its equivalent in chip cards. It can be broken down into tracks 1 and 2, containing various cardholder details.
• Full track data after authorization: After a transaction is authorized (approved), businesses should not store the complete track data from the card, even if encrypted. This data should be rendered unrecoverable after authorization is complete.

While the full track data shouldn't be stored, there are some exceptions for specific data elements that can be retained with proper justification:

• Cardholder name
• PAN: Usually the last four digits are displayed, the rest is masked
• Expiration date
• Service code

The requirement emphasizes storing only these essential elements and minimizing the amount of data retained.

How to meet this compliance requirement

Business implications

• An entity identifying locations of stored account data should consider all processes and personnel with access to the data, as data could have been moved and stored in different locations than originally defined.
• To establish suitable retention requirements, an entity must first comprehend its business needs and any legal or regulatory obligations relevant to its industry or the type of data being retained.

Best practices to meet this requirement

• Develop a data retention policy: Define a clear data retention policy that outlines what data you will store, for how long, and how it will be disposed of securely.
• Minimize data collection: Only collect the CHD that is absolutely necessary for your business needs. Avoid storing unnecessary data fields like security codes (CVVs) or full PAN.
• Regular data reviews and purges: Regularly review your stored CHD to identify and remove any data that is no longer required.
• Secure disposal of data: When disposing of CHD, use secure methods that ensure the data is unrecoverable. This may involve shredding physical media or secure deletion of electronic data.

PCI DSS Requirement 3.3: SAD is not stored after authorization

Requirement 3.3 is further split into requirement 3.3.1, 3.3.2, and 3.3.3.

PCI DSS Requirement 3.3.1

This requirement prohibits the storage of SAD after a transaction is authorized. SAD refers to any data elements used to verify cardholder identity during a transaction, such as:

• Card verification value (CVV)
• PINs
• One-time passwords (OTPs)
• Challenge codes

Importance

• Security: Storing SAD after authorization creates a high-value target for attackers. If compromised, it can be used to create counterfeit cards and conduct fraudulent transactions.
• Compliance: The PCI DSS strictly prohibits SAD storage to protect CHD and reduce the risk of breaches.

Business Implications

Entities cannot address this requirement using the customized approach.

Best practices to meet this requirement

• Securely transmit SAD: Transmit SAD directly to the payment processor during authorization without storing it on your systems.
• Mask or render unrecoverable: If a temporary storage requirement exists for technical reasons, mask or render the SAD unrecoverable immediately after completing authorization.
• Document procedures: Clearly document your policies and procedures regarding SAD handling to ensure all personnel understand the prohibition on storage.
• Employee training: Train staff on PCI DSS requirements and the importance of not storing SAD.

How to meet this compliance requirement

Requirement 3.3.1 is further divided into requirements 3.3.1.1, 3.3.1.2, and 3.3.1.3. Let's explore these in detail.

Requirement 3.3.1.1

This requirement focuses on protecting sensitive magnetic stripe data on the back of cards. It prohibits storing the complete track data after a transaction is authorized. Track data refers to the information encoded on the magnetic stripe, which can include:

• Track 1: Typically contains the cardholder account number, expiration date, service code, and issuing cardholder bank information.
• Track 2: Often includes the account number, expiration date, and service code.
• Track 3: Less commonly used, may contain additional cardholder and cardholder bank information.

Requirement 3.3.1.2

his requirement strictly prohibits storing the card verification codes (CVCs) after a transaction is authorized. The CVC is a critical security feature that helps verify cardholder identities during card-not-present transactions (online or phone orders). Storing the CVC poses a significant security risk if compromised.

• CVC importance: The CVC serves as an extra layer of security for card-not-present transactions. It's a unique code that is not part of the embossed data on the card and needs to be entered separately during transactions.
• Security risk: If an attacker steals the CVC along with the card number and expiration date, they can potentially conduct fraudulent transactions. Eliminating CVC storage reduces this risk.
• Requirement scope: This requirement applies to all systems and processes that handle CHD, including authorization systems, logs, databases, and any temporary storage locations.

Requirement 3.3.1.3

This requirement emphasizes the critical importance of not storing PINs or PIN blocks after a transaction is authorized. PINs are used for cardholder verification during ATM withdrawals and in-store purchases with chip and PIN technology. Storing them poses a significant security risk.

• PIN security: PINs are crucial for safeguarding cardholder accounts. They should only be known to the cardholder and the entity that issued the card.
• PIN block: During authorization, PINs are usually converted into encrypted "PIN blocks" for secure transmission. However, even encrypted PIN blocks should not be stored.
• Security risk: If an attacker steals a PIN or PIN block, they can potentially conduct fraudulent transactions at ATMs or chip and PIN-enabled terminals.

PCI DSS Requirement 3.3.2

SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography

This requirement focuses on protecting SAD electronically stored before a transaction is authorized. SAD refers to critical data elements used for cardholder verification, such as:

• CVV
• PINs
• OTPs
• Challenge codes

While the PCI DSS discourages storing any SAD, some technical scenarios might necessitate temporary storage before authorization. This requirement mandates using strong cryptography to safeguard this sensitive data during that time.

Importance of Strong Encryption:

• Encryption scrambles data into an unreadable format using a dedicated key. Only authorized personnel with the correct key can decrypt it back to its original form.
• Strong cryptography significantly reduces the risk of attackers stealing and deciphering stored SAD, even if they breach your systems.

How to meet this compliance requirement

Business implications

• Weak encryption for SAD can be easily compromised, leading to data breaches and significant financial losses due to fraudulent transactions.
• This requirement does not apply to issuers and companies that provide issuing services, where there is a legitimate business justification for storing SAD.

Best practices to meet this requirement

• Strong encryption algorithms: Use approved and robust cryptographic algorithms like AES-256 to encrypt SAD at rest and in transit.
• Key management: Implement secure key management practices to safeguard the confidentiality of your encryption keys. This includes secure storage, access controls, and regular key rotation.
• Separate encryption key (optional): Consider using a separate cryptographic key for encrypting SAD compared to the key used for encrypting PANs. This adds an extra layer of security.
• Regular security testing: Conduct regular security testing to identify and address vulnerabilities in your systems that could compromise encrypted SAD.

PCI DSS Requirement 3.3.3

Additional requirement for issuers and companies supporting issuing services

This requirement applies specifically to issuers (card-issuing banks) and companies that support issuing services (e.g., card processors). It focuses on the storage of SAD by these entities. SAD refers to critical data elements used for cardholder verification, such as:

• CVV
• PINs
• OTPs
• Challenge codes

Key points

• Limited storage: Issuers can only store SAD if it's absolutely necessary for a legitimate business need related to the issuing process (e.g., card activation, replacement).
• Secure storage: Any stored SAD must be securely protected using appropriate security measures.
• Encryption (best practice until further notice): While not yet mandatory, the PCI DSS recommends encrypting all stored SAD using strong cryptography. This becomes a requirement at a later date.

How to meet this compliance requirement

Business implications

Organizations storing SAD must securely protect it using appropriate security measures.

Best practices to meet this requirement

• Minimize storage: Only store SAD for essential issuing processes and delete it as soon as it's no longer needed.
• Secure storage: Implement robust security measures to protect stored SAD, such as access controls, encryption (becomes mandatory later), and regular security testing.
• Documented justification: Maintain documented evidence justifying the business need for storing any SAD.

PCI DSS Requirement 3.4: Access to displays of full PAN and ability to copy PAN is restricted

Requirement 3.4 is further divided into 3.4.1 and 3.4.2. Let's explore these in detail.

PCI DSS Requirement 3.4.1

This requirement focuses on restricting access to and display of full PANs. PANs are sensitive data and exposing them can lead to fraudulent activities. The PCI DSS mandates measures to ensure only authorized personnel with a legitimate business need can see the full PAN.

• PAN masking: This involves displaying only a portion of the PAN—typically the bank identification number (BIN) and the last four digits—while concealing the rest. This reduces the risk of unauthorized individuals obtaining the full PAN if they gain access to a screen or printout.
• Access controls: Organizations must implement controls to restrict access to displaying full PANs. This includes defining authorized roles with legitimate business needs and ensuring unauthorized personnel can only see masked PANs.

How to meet this compliance requirement

Business implications

• Displaying only the last four digits and the BIN: This masks a significant portion of the PAN while still allowing for basic card identification for some business purposes.
• Restricting access to the full PAN based on roles and needs: Only personnel with job duties requiring them to view the complete PAN (e.g., fraud investigators) should be granted the necessary access privileges.
• Masking PANs reduces the potential for accidental data exposure through printouts, error messages, or other situations where full PAN visibility is not necessary.

Best practices to meet this requirement

• Documented policy: Create a documented policy outlining roles authorized to see full PANs and their legitimate business needs.
• Masking implementation: Implement system configurations to ensure only authorized roles can see full PANs and all others see masked versions.
• Access controls: Enforce access controls to restrict unauthorized access to full PAN displays.
• Minimized display: Only display the minimum number of PAN digits necessary for the specific business function (e.g., last four digits for verification).

PCI DSS Requirement 3.4.2 : Restrict copying and relocation of PAN during remote access

This requirement focuses on preventing unauthorized copying or relocation of PAN when using remote access technologies. Remote access allows personnel to connect to a computer system from a remote location. Uncontrolled copying or relocation of PANs during remote access sessions can increase the risk of data breaches.

• Technical controls: Organizations must implement technical controls within their remote access technologies to prevent all personnel (except those explicitly authorized) from copying or relocating PAN data.
• Authorized personnel: Only personnel with a documented, legitimate business need and explicit authorization should be allowed to copy or relocate PANs during remote access sessions.

How to meet this compliance requirement

Business implications

• Businesses must develop and document policies and procedures that outline the technical controls in place to prevent unauthorized actions. This includes maintaining a list of authorized personnel.
• Organizations may need to reconfigure their remote access technologies to enforce these technical controls. This might involve software updates, implementing new security tools, or changing access protocols.
• While enhancing security, businesses must balance this with operational efficiency. Overly stringent controls can slow down legitimate business processes. Companies need to find a balance that ensures security without hindering productivity.

Best practices to meet this requirement

• Technical safeguards: Implement technical controls in your remote access solutions to prevent unauthorized copying or relocation of PANs. This might include features like:
  • Disabling clipboard functionality for PAN data.
  • Disabling file transfer capabilities for PAN data.
  • Data encryption during remote sessions.
• Documented policy: Create a documented policy outlining the restrictions on copying/relocating PANs during remote access and the approval process for authorized personnel.
• Access controls: Enforce access controls to ensure only authorized personnel have access to functionalities that could allow copying or relocating PANs.

PCI DSS Requirement 3.5: The PAN is secured wherever it is stored

This requirement is further subdivided into sections 3.5.1, 3.5.1.1, 3.5.1.2, and 3.5.1.3. Let's explore these in detail.

PCI DSS Requirement 3.5.1: Render the PAN unreadable in storage (using approved methods)

This requirement focuses on protecting PAN stored electronically. It mandates that organizations render PAN data unreadable using any of the approved methods outlined in the standard. This significantly reduces the risk of unauthorized individuals accessing and deciphering stored PANs even if they breach your systems.

Approved methods for rendering PAN unreadable:

• One-way hashes: Cryptographic algorithms are used to generate a unique, irreversible string (hash) from the entire PAN. This hash cannot be mathematically converted back to the original PAN.
• Truncation: This involves removing a specific number of digits (typically the middle digits) from the PAN. However, simply truncating and storing both the truncated portion and the hash is not sufficient. Additional controls are required to prevent correlating these fragments and reconstructing the original PAN.
• Index tokens: These are unique identifiers that replace the PAN in storage systems. They have no inherent value outside the system and cannot be used to reconstruct the original PAN.
• Strong cryptography: This involves encrypting the PAN using robust algorithms and secure key management practices.

How to meet this compliance requirement

Business implications

• The main purpose of this requirement is to prevent unauthorized access to sensitive CHD. By rendering PAN unreadable, businesses significantly reduce the risk of data breaches and fraud.
• Businesses need to implement one or more of the following methods to render PAN unreadable: one-way hashes, truncation, index tokens, or strong cryptography.
• Strong cryptographic solutions and associated key management processes must be established and maintained, which may require significant technical expertise and resources.
• Effective implementation of this requirement is a critical component of a broader risk management strategy. It helps protect against data breaches, which can have severe financial and reputational consequences.

Best practices to meet this requirement:

• Choose an approved method: Select one of the approved methods (hashing, truncation with controls, index tokens, or strong cryptography) to render PANs unreadable in storage.
• Strong cryptography (if applicable): If using encryption, ensure you employ robust algorithms (e.g., AES-256) and implement secure key management practices.
• Control truncation: If using truncation, implement additional controls to prevent correlation between truncated segments and their corresponding hashes, thus preventing reconstruction of the original PAN.
• Document your approach: Document the chosen method for rendering PANs unreadable and the justification for your selection.

PCI DSS Requirement 3.5.1.1: Use keyed cryptographic hashes for PAN

This requirement is an extension of Requirement 3.5.1, which mandates rendering PANs unreadable in storage. Specifically, it focuses on the hashing method used for this purpose. Prior to April 1, 2025, it's a best practice, but afterwards, it will become a mandatory requirement.

This requirement emphasizes using keyed cryptographic hashes for rendering PANs unreadable.

• Keyed hashing: A cryptographic key is used in the hashing algorithm, making it significantly more secure than traditional hashing. This key adds an extra layer of protection, preventing attackers from easily reversing the hash and obtaining the original PAN.
• Strong cryptographic strength: The hashing algorithm and key length should provide a minimum cryptographic strength of 128 bits (as recommended by the National Institute of Standards and Technology (NIST).
• Key management: Secure key management practices are crucial to protect the cryptographic keys used for hashing. This aligns with Requirements 3.6 and 3.7 of the PCI DSS, which address key management controls.

How to meet this compliance requirement

Business implications

• Organizations must document the hashing methods and key management procedures used to render PAN unreadable. Regular audits are necessary to verify compliance.
• Strong cryptographic protection of PAN simplifies incident response by reducing the risk of sensitive data being compromised.
• As this requirement is considered a best practice until March 31, 2025, businesses that implement it early can stay ahead of regulatory changes and industry standards.

Best practices to meet this requirement

• Use keyed hashing algorithms: Implement hashing algorithms that incorporate a cryptographic key, such as hash-based message authentication code (HMAC), cipher message authentication code (CMAC), or Galois/Counter Mode (GMAC).
• Strong cryptographic strength: Ensure the chosen hashing algorithm and key length provide at least 128 bits of cryptographic strength. Refer to NIST guidelines for recommendations.
• Secure key management: Implement robust key management practices as outlined in PCI DSS Requirements 3.6 and 3.7. This includes secure key generation, storage, rotation, and access controls.

PCI DSS Requirement 3.5.1.2: Restrictions on disk-level encryption for PAN (best practice until March 31, 2025, after which it will be required)

This requirement focuses on using disk-level or partition-level encryption to render PANs unreadable in storage. It outlines limitations on this approach and emphasizes the need for additional safeguards.

• Disk-level encryption: Encrypting the entire disk or partition where PANs reside can be a security measure. However, the PCI DSS restricts its use for PAN protection.
• Removable media: Disk-level encryption is only acceptable for rendering PANs unreadable on removable electronic media (e.g., USB drives).
• Non-removable media: If using disk-level encryption on non-removable media (e.g., server hard drives), an additional mechanism (like truncation or file-level encryption) must be used to render PANs unreadable independent of the encryption.

How to meet this compliance requirement

Business implications

• Systems must be configured to enforce this requirement, which may involve updates to databases, storage solutions, and data processing workflows.
• Organizations need to document their policies and procedures that ensure compliance with this requirement, detailing how they avoid the coexistence of truncated and hashed PANs.

Best practices to meet this requirement

• Removable media: If using disk-level encryption for removable media containing PANs, ensure no other storage mechanisms are used.
• Non-removable media: For non-removable media, implement an additional mechanism (like truncation or file-level encryption) to render PANs unreadable independent of the disk-level encryption.
• Strong encryption (if applicable): If using disk-level encryption, ensure it employs robust algorithms and adheres to PCI DSS encryption and key management requirements.

PCI DSS Requirement 3.5.1.3: Secure management of disk-level encryption (for PAN storage)

This requirement focuses on additional security measures required when using disk-level or partition-level encryption to render PANs unreadable in storage. These measures aim to prevent unauthorized access to decrypted PAN data even if an attacker gains access to a user account on the system.

• Independent logical access controls: The system implementing disk-level encryption must enforce separate and independent logical access controls for decrypting PAN data. This means using a dedicated authentication process distinct from the native operating system login mechanism.
• Dissociation of decryption keys: Decryption keys used to access unencrypted PAN data must not be directly associated with individual user accounts. This prevents attackers who compromise a user account from automatically gaining access to decrypted PANs.
• Secure storage of authentication factors: Authentication factors (passwords, passphrases, or cryptographic keys) used for accessing unencrypted PAN data must be stored securely. This includes mechanisms to prevent unauthorized access to these factors.

How to meet this compliance requirement

Business implications

• Encryption scrambles CHD, making it undecipherable without the proper decryption key. This significantly reduces the risk of compromising sensitive data even if physical storage devices are stolen or lost.
• Encryption and decryption processes can add overhead to system performance, impacting disk read/write speeds.
• Disk-level encryption alone might not be sufficient for comprehensive data security. Additional measures like strong access controls and network security are still essential.

Best practices to meet this requirement

• Independent authentication: Implement a dedicated authentication process for decrypting PAN data, separate from the operating system login. This might involve multi-factor authentication or hardware security modules (HSMs).
• Separate decryption keys: Manage decryption keys independently of user account credentials. Consider HSMs for secure key storage and access control.
• Secure authentication factors: Store passwords, passphrases, or cryptographic keys used for decryption securely. Implement strong password policies, encryption at rest, and access restrictions for these factors.

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

This requirement is further subdivided into sections 3.6.1, 3.6.1.1, 3.6.1.2, 3.6.1.3, and 3.6.1.4. Let's explore these in detail.

PCI DSS Requirement 3.6.1: Implement procedures to protect cryptographic keys

This requirement emphasizes the critical importance of protecting cryptographic keys used to encrypt stored account data (including PANs). Strong key management practices are essential to prevent unauthorized access and misuse of these keys, which could lead to decryption and exposure of sensitive data.

• Restricted access: Access to cryptographic keys should be limited to the absolute minimum number of authorized personnel who genuinely need them for their job functions. This minimizes the risk of unauthorized access and potential misuse.
• Strong key-encrypting keys: The keys used to encrypt the data-encrypting keys (key-encrypting keys) must be at least as strong as the data-encrypting keys themselves. This ensures a layered security approach and prevents brute-force attacks targeting the key-encrypting keys.
• Separate storage: Data-encrypting keys and key-encrypting keys must be stored securely and separately. This prevents a single point of failure if one key is compromised.
• Minimized storage locations: Keys should be stored in the fewest possible physical locations and formats to reduce the attack surface and simplify control measures.

How to meet this compliance requirement

Business implications

Key management processes like key rotation, access controls, and audit trails add some overhead to system administration. Key management processes like key rotation, access controls, and audit trails add some overhead to system administration.

Best practices to meet this requirement

• Develop key management policies: Establish documented policies and procedures outlining how cryptographic keys are managed, accessed, stored, and rotated.
• Restrict key access: Implement strict access controls to limit access to keys only to authorized personnel based on the principle of least privilege.
• Strong key-encrypting keys: Use strong cryptographic algorithms and key lengths for both data-encrypting and key-encrypting keys.
• Separate key storage: Store data-encrypting keys and key-encrypting keys securely in separate locations (physical or logical). Consider HSMs for secure key storage.
• Minimize storage locations: Minimize the number of locations where keys are stored and the number of formats they exist in (e.g., avoid storing keys on individual workstations).

PCI DSS Requirement 3.6.1.1: Document and describe the cryptographic architecture (service providers)

This requirement applies specifically to service providers and focuses on documenting the cryptographic architecture used to protect stored account data (including PANs). This documentation helps understand the security controls in place and facilitates ongoing management.

• Detailed documentation: Service providers must maintain a documented description of their cryptographic architecture. This document should detail all algorithms, protocols, and cryptographic keys used for data protection. It should also include:
  • Key strength and expiration dates for each key.
  • A description of each key's specific purpose.
  • An inventory of any HSMs, key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management (including type and location).
• Preventing shared keys (best practice until March 31, 2025): The documented architecture should describe how the service provider prevents using the same cryptographic keys in both production and test environments. This helps to ensure that a compromise in the test environment doesn't expose keys used in production. This becomes mandatory after March 31, 2025.

How to meet this compliance requirement

Business implications

• Incomplete or inaccurate documentation of the cryptographic architecture can hinder understanding of security controls and make it difficult to identify vulnerabilities or implement necessary updates.
• Service providers need to develop and maintain detailed documentation of all cryptographic components, including algorithms, keys, and security modules.
• Ensuring that cryptographic keys are not reused in both production and test environments prevents potential security breaches. This requires robust key management practices and possibly separate KMSs for different environments.

Best practices to meet this requirement

• Develop a cryptographic architecture document: Create a comprehensive document outlining your cryptographic architecture. Include details of algorithms, protocols, keys, key management devices, and key usage.
• Maintain accurate documentation: Regularly update the cryptographic architecture document to reflect any changes in algorithms, keys, or security devices.
• Prevent shared keys in production and test environments (before March 31, 2025): Implement controls to prevent using the same cryptographic keys in both production and test environments. This becomes mandatory after March 31, 2025.
• Automate reporting (optional): Consider using automated reporting mechanisms to streamline the process of maintaining accurate information about cryptographic attributes.

PCI DSS Requirement 3.6.1.2: Secure storage of secret and private keys (for stored account data)

This requirement focuses on the secure storage of secret and private cryptographic keys used to encrypt and decrypt stored account data (including PANs). It outlines acceptable storage methods to prevent unauthorized access and potential exposure of these keys.

• Strong encryption or SCD storage: Secret and private keys must be stored in one of the following secure forms:
  • Encrypted with a key-encrypting key (at least as strong as the data-encrypting key) and stored separately.
  • Within a secure cryptographic device (SCD) like an HSM or a PTS-approved point-of-interaction device.
  • Split into at least two full-length key components or key shares, generated using a secure method following an industry-accepted standard.
• Separate storage of key-encrypting keys: When using key-encrypting keys, they must be:
  • At least as strong as the data-encrypting keys they protect.
  • Stored separately from the data-encrypting keys to prevent a single point of compromise.

How to meet this compliance requirement

Business implications

• Ensuring that cryptographic keys are securely stored reduces the risk of unauthorized access and potential data breaches.
• Organizations must invest in appropriate storage solutions for cryptographic keys, such as HSMs or other SCDs.
• Ensuring that system configurations support the secure storage of cryptographic keys may require updates to existing systems and processes.

Best practices to meet this requirement

• Implement secure key storage: Choose one of the approved methods for storing secret and private keys:
  • Encrypt them with strong key-encrypting keys and store them separately.
  • Utilize HSMs or PTS-approved devices for key storage.
  • Split keys into secure key components or shares following an industry standard.
• Strong key-encrypting keys: If using key-encrypting keys, ensure they are at least as strong as the data-encrypting keys they protect.
• Separate key storage: Store key-encrypting keys separately from the data-encrypting keys they protect.

PCI DSS Requirement 3.6.1.3: Restrict access to cleartext cryptographic keys

This requirement emphasizes the importance of strictly limiting access to cleartext (unencrypted) cryptographic key components used to protect stored account data (including PANs). Minimizing access reduces the risk of unauthorized individuals gaining access to keys and potentially decrypting sensitive data.

• Limited access: Access to cleartext cryptographic key components must be restricted to the absolute minimum number of personnel who genuinely require it for their job duties. This principle of least privilege helps to minimize the attack surface.
• Justification for access: Each individual granted access to cleartext key components should have a documented justification for needing such access based on their job responsibilities (e.g., key creation, rotation, or management).

How to meet this compliance requirement

Business implications

• Businesses need to implement strict access control policies and regularly update access lists to ensure compliance.
• Organizations must maintain detailed audit trails of key access, making it easier to verify compliance during audits.
• Clear definitions and documentation of key custodian roles and responsibilities are necessary.
• By restricting access, businesses can reduce the overhead associated with managing and securing cryptographic keys.

Best practices to meet this requirement

• Least privilege access control: Implement strict access controls to ensure only authorized personnel with documented justification can access cleartext key components.
• Key custodian roles: Define specific key custodian roles responsible for creating, altering, rotating, distributing, or otherwise managing encryption keys. Grant access to cleartext key components only to those fulfilling these roles.
• Minimize custodians: Ideally, restrict access to cleartext key components to a very small number of personnel within the organization.

PCI DSS Requirement 3.6.1.4: Minimize cryptographic key storage locations

This requirement focuses on minimizing the number of physical locations where cryptographic keys used to protect stored account data (including PANs) are stored. This helps to simplify key management, reduce the attack surface, and minimize potential vulnerabilities.

• Limited storage locations: Cryptographic keys should be stored in the fewest possible physical locations. This reduces the complexity of key management and minimizes the number of potential points of compromise.
• Justification for additional locations: Any additional key storage locations should have a clear business justification.

Business implications

• Spreading keys across multiple locations can increase the complexity of key management and make it more difficult to maintain control and ensure security.
• Each additional storage location introduces a potential vulnerability that could be exploited by attackers.
• Implementation of centralized and secure storage solutions such as HSMs or secure vaults.

Best practices to meet this requirement

• Centralized key management: Consider implementing a centralized KMS to consolidate key storage and simplify access controls.
• Minimize locations: Evaluate the need for each location where keys are stored. Eliminate unnecessary storage locations and consolidate keys where possible.
• Justification for expansion: If additional storage locations are necessary, ensure they have a clear business justification and implement appropriate security measures.

PCI DSS 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

This requirement is further subdivided into sections 3.7.1, 3.7.2, 3.7.3, 3.7.4, 3.7.5, 3.7.6, 3.7.7, 3.7.8, and 3.7.9. Let's explore these in detail.

PCI DSS 3.7.1: Generate strong cryptographic keys (for stored account data)

This requirement emphasizes the critical importance of using strong cryptographic keys to protect stored account data (including PANs). Strong keys significantly increase the difficulty of decryption by unauthorized individuals, safeguarding sensitive data.

• Documented key generation policy: You must have documented key management policies and procedures that define the generation of strong cryptographic keys for protecting stored account data.
• Strong key generation methods: The documented policy should specify the use of strong key generation methods that meet industry standards. These methods typically involve using cryptographically secure pseudo-random number generators (CSPRNGs).

How to meet this compliance requirement

Business implications

• Using strong, unpredictable keys significantly increases the effort and resources required for attackers to crack the encryption and access CHD.
• Securing cryptographic keys effectively might require additional technical expertise or involvement from qualified personnel.

Best practices to meet this requirement

• Develop a key management policy: Establish documented key management policies and procedures that outline the process for generating strong cryptographic keys.
• Specify strong key generation methods: Define the use of strong key generation methods in your policy. This might involve referencing industry standards or specific algorithms (e.g., using a CSPRNG).
• Regular key rotation: Implement a key rotation schedule to periodically generate and replace existing keys. This reduces the risk of compromised keys being used for extended periods.

PCI DSS 3.7.2: Securely distribute cryptographic keys (for stored account data)

This requirement focuses on ensuring the secure distribution of cryptographic keys used to protect stored account data (including PANs). Secure distribution methods prevent unauthorized access or interception of keys during the transfer process.

• Documented distribution policy: You must have documented key management policies and procedures that define secure methods for distributing cryptographic keys.
• Authorized custodians only: Keys should be distributed only to authorized key custodians identified in Requirement 3.6.1.2 (those with a documented need to access the keys).
• Secure distribution methods: The documented policy should specify the use of secure distribution methods that protect the confidentiality and integrity of the keys during transfer. This might involve encrypted channels, secure key storage containers, or specific key injection procedures.

How to meet this compliance requirement

Business implications

• Secure key distribution minimizes the chances of unauthorized individuals gaining access to the keys, which would render CHD encryption ineffective.
• Implementing and maintaining robust key management processes can make system administration more complex.

Best practices to meet this requirement:

• Develop a key management policy: Establish documented key management policies and procedures that outline the process for securely distributing cryptographic keys.
• Define secure distribution methods: Specify secure methods for key distribution in your policy. This might involve:
  • Using encrypted channels (e.g., secure file transfer protocols).
  • Distributing keys in secure key storage containers.
  • Implementing specific key injection procedures that minimize exposure during transfer.
• Restrict distribution to authorized personnel: Ensure keys are only distributed to authorized key custodians with a documented need to access them.

PCI DSS 3.7.3: Securely store cryptographic keys (for stored account data)

This requirement emphasizes the importance of securely storing cryptographic keys used to protect stored account data (including PANs). Secure storage practices minimize the risk of unauthorized access, theft, or misuse of keys, which could potentially compromise sensitive data.

• Documented storage policy: You must have documented key management policies and procedures that define secure methods for storing cryptographic keys.
• Strong security controls: The documented policy should specify the use of strong security controls to safeguard keys throughout their life cycle. This might involve HSMs, secure key storage containers, or encryption at rest.
• Separate storage (optional): While not explicitly required, storing key-encrypting keys separately from data-encrypting keys is a recommended best practice to add an extra layer of security.

How to meet this compliance requirement

Business implications

• Proper key storage significantly reduces the risk of attackers compromising the keys and potentially decrypting CHD.
• Secure key storage solutions may make key management processes more complex for system administrators.

Best practices to meet this requirement

• Develop a key management policy: Establish documented key management policies and procedures that outline the process for securely storing cryptographic keys.
• Define secure storage methods: Specify secure storage methods for keys in your policy. This might involve:
  • Utilizing HSMs
  • Using secure key storage containers with strong access controls
  • Encrypting keys at rest
• Separate key storage (optional): Consider storing key-encrypting keys separately from data-encrypting keys for an additional layer of protection.

PCI DSS 3.7.4: Implement cryptographic key rotation

This requirement focuses on the critical security practice of rotating cryptographic keys used to protect stored account data (including PANs). Key rotation involves replacing existing keys with new ones after a predefined period (cryptoperiod). This mitigates the risk of compromised keys being used for extended periods.

• Documented key rotation policy: You must have documented key management policies and procedures that define a key rotation strategy. This policy should include:
  • A defined cryptoperiod for each type of key used (based on industry best practices and recommendations from application vendors or key owners).
  • A clear process for changing keys at the end of their defined cryptoperiod.
• Regular key changes: Keys must be changed regularly according to the defined cryptoperiod to minimize the risk of compromise. Cryptoperiods should be based on industry best practices and consider factors like key strength and potential threats.

How to meet this compliance requirement

Business implications

• Secure key storage and timely key changes mandated by these requirements significantly strengthen CHD protection by reducing the window of opportunity for attackers to exploit compromised keys.
• Organizations need to establish defined cryptoperiods for different key types and rotate keys before they reach the end of their cryptoperiod to minimize risks.

Best practices to meet this requirement

• Develop a key rotation policy: Establish documented key management policies and procedures that define a key rotation strategy.
• Define cryptoperiods: Specify a defined cryptoperiod for each key type based on industry best practices and vendor recommendations. Consider factors like key strength and potential threats when determining cryptoperiod lengths.
• Implement a key rotation process: Outline a clear process for changing keys at the end of their cryptoperiod. This might involve automated key rotation mechanisms or manual procedures with defined timelines.
• Regular reviews: Regularly review key rotation policies and cryptoperiods to ensure they remain aligned with industry best practices and address evolving security threats.

PCI DSS 3.7.5: Retire, replace, or destroy compromised keys (for stored account data)

This requirement focuses on the proper handling of cryptographic keys used to protect stored account data (including PANs) when they are no longer considered secure. It outlines specific scenarios where keys should be retired, replaced, or destroyed to minimize the risk of unauthorized access to sensitive data.

• Documented key retirement policy: You must have documented key management policies and procedures that define the process for retiring, replacing, or destroying keys under specific circumstances. These circumstances include:
  • Keys reaching the end of their defined cryptoperiod (as required in PCI DSS 3.7.4).
  • Keys suspected or known to be compromised (e.g., due to a security incident).
  • Weakened key integrity (e.g., when personnel with knowledge of a cleartext key component leave the company).
• Secure key retirement/replacement: Retired or replaced keys must not be used for encryption operations. They can be securely archived if necessary (e.g., using a key-encryption key).
• Clear process definition: The documented policy should clearly define the process for identifying keys needing retirement, replacement, or destruction, and the specific actions to be taken in each scenario.

How to meet this compliance requirement:

Business implications

• If a cryptographic key is suspected or known to be compromised, it should be immediately revoked and replaced to prevent unauthorized decryption of CHD.
• When personnel with knowledge of a key component leave the organization, the key should be rotated to ensure continued data security.

Best practices to meet this requirement

• Develop a key retirement policy: Establish documented key management policies and procedures that define the process for retiring, replacing, or destroying keys under specific circumstances.
• Define key retirement triggers: Include clear triggers in your policy for key retirement, replacement, or destruction, such as:
  • End of cryptoperiod.
  • Suspected or confirmed key compromise.
  • Weakened key integrity (e.g., personnel changes).
• Outline a retirement/replacement process: Clearly define the process for identifying keys needing action and the specific steps to be taken (e.g., secure deletion, secure archiving with encryption).
• Regular reviews: Conduct regular reviews of key management practices to ensure they are effective in identifying and handling compromised keys.

PCI DSS 3.7.6: Implement split knowledge and dual control for manual cleartext key management

This requirement focuses on safeguarding cleartext cryptographic keys (unencrypted keys) used to protect stored account data (including PANs) when manual key management operations are involved. It mandates the use of split knowledge and dual control techniques to minimize the risk of unauthorized access to sensitive keys.

• Split knowledge and dual control: When manual operations involving cleartext keys are performed, your documented key management policies and procedures must define the use of split knowledge and dual control.
• Split knowledge explained: This involves dividing the key into multiple components, where each authorized individual only knows their assigned component. No single person possesses the complete key.
• Dual control explained: This requires the involvement of at least two authorized individuals to perform any key management operation involving cleartext keys. Both individuals must authenticate themselves before the operation can proceed.
• Secure key generation: Key components or shares must be generated using a secure method, such as an approved random number generator within a secure cryptographic device (HSM) or following industry standards like ISO 19592.

How to meet this compliance requirement

Business implications

• Implementing and maintaining split knowledge and dual control processes can add complexity and overhead to key management workflows.
• Depending on the existing workforce structure, assigning separate roles and potentially increasing the number of personnel involved in key management tasks might incur additional costs.

Best practices to meet this requirement

• Develop a key management policy: Establish documented key management policies and procedures that define the use of split knowledge and dual control for manual cleartext key management operations.
• Define key splitting and access controls: Specify how keys will be split into components and how access to these components will be controlled. This might involve assigning unique key components to different authorized personnel and requiring two individuals to be present for any key management operation.
• Secure key generation: Ensure key components or shares are generated using a secure method as outlined in the requirement (e.g., HSM, approved random number generator, following ISO 19592).
• Regular reviews: Regularly review key management practices to ensure they remain effective in protecting cleartext keys.

PCI DSS 3.7.7: Prevent unauthorized key substitution (for stored account data)

This requirement emphasizes the critical importance of preventing unauthorized substitution of cryptographic keys used to protect stored account data (including PANs). Key substitution refers to replacing a legitimate key with a different one without authorization. This could allow attackers to decrypt sensitive data.

• Documented prevention policy: You must have documented key management policies and procedures that define controls to prevent unauthorized key substitution.
• Focus on encryption solutions: Your policy should address how the chosen encryption solution helps prevent unauthorized key substitution. This might involve features like:
  • Secure key injection processes.
  • Access controls that limit who can modify keys.
  • Tamper-evident mechanisms within the encryption solution.
• Personnel access controls: Ensure individuals with access to key components or shares cannot access other components or shares needed to derive the complete key. This reinforces the principles of split knowledge and dual control.

How to meet this compliance requirement

Best practices to meet this requirement

• Develop a key management policy: Establish documented key management policies and procedures that define controls to prevent unauthorized key substitution.
• Focus on encryption solution security: Analyze your chosen encryption solution and document how its features prevent unauthorized key substitution (e.g., secure key injection, access controls).
• Implement access controls: Implement access controls to ensure individuals with access to key components cannot access other components needed to reconstruct the complete key.
• Regular reviews: Conduct regular reviews of key management practices to ensure they remain effective in preventing unauthorized key substitution.

PCI DSS 3.7.8: Document and acknowledge key custodian responsibilities

This requirement emphasizes the importance of formally documenting key custodian responsibilities and ensuring they understand and accept these responsibilities. Key custodians are individuals entrusted with managing cryptographic keys used to protect stored account data (including PANs).

• Documented responsibilities: Your documented key management policies and procedures must clearly define the responsibilities of key custodians. This might include:
  • Key generation, distribution, storage, rotation, and destruction procedures.
  • Reporting security incidents involving keys.
  • Maintaining confidentiality of key components.
• Formal acknowledgement: Key custodians must formally acknowledge (in writing or electronically) that they have read, understood, and accepted their responsibilities as outlined in the documented policies.

How to meet this compliance requirement

Business implications

• Data breaches: Key custodian negligence or lack of awareness can lead to compromised keys and potential data breaches. This results in significant financial losses, reputational damage, and potential fines.
• Compliance fines: Failing to meet PCI DSS requirements can lead to fines from payment card brands.

Best practices to meet this requirement

• Develop a key management policy: Establish documented key management policies and procedures that clearly define key custodian responsibilities.
• Define an acknowledgment process: Outline a formal process for key custodians to acknowledge their responsibilities. This could involve signing a physical document or electronically acknowledging receipt of the policy.
• Regular training and awareness: Provide regular training sessions for key custodians to ensure they understand their responsibilities and the importance of secure key management practices.
• Periodic reaffirmation: Consider requiring periodic reaffirmations (e.g., annually) from key custodians to acknowledge their ongoing commitment to their responsibilities.

PCI DSS 3.7.9: Document and share secure key management guidance (service providers only)

This requirement applies specifically to service providers who share cryptographic keys with their customers for transmitting or storing account data (including PANs). It emphasizes the importance of providing these customers with documented guidance on securely transmitting, storing, and updating the shared keys.

• Document secure key management practices: You must create documented guidance that outlines secure practices for your customers to follow when:
  • Transmitting shared cryptographic keys (e.g., secure protocols, encryption methods).
  • Storing shared keys (e.g., secure storage locations, access controls).
  • Updating shared keys (e.g., key rotation procedures, secure communication channels).
• Distribute guidance to customers: This documented guidance must be distributed to all your customers who receive shared cryptographic keys.

How to meet this compliance requirement

Business implications (for service providers)

• Customer data breaches: Failure to provide proper guidance on secure key management can increase the risk of customer data breaches. If a customer mismanages shared keys, they become vulnerable to unauthorized access. This can lead to significant reputational damage, potential fines for both you and your customer, and loss of customer trust.
• Compliance fines: Failing to meet PCI DSS requirements can lead to fines from payment card brands.

Best practices to meet this requirement (for service providers)

• Develop key management guidance: Create clear and concise documentation outlining secure practices for transmitting, storing, and updating shared cryptographic keys.
• Reference industry standards: Consider referencing relevant industry standards in your guidance document (e.g., NIST SP 800-57, ISO 11568).
• Distribute guidance to customers: Provide the documented guidance to all customers who receive shared cryptographic keys. This can be done electronically or through physical copies.
• Regular updates: Regularly review and update your key management guidance document to reflect any changes in your practices or industry standards.