The purpose of Requirement 3 is to ensure that stored cardholder data is adequately protected against unauthorized access and theft. This requirement mandates that organizations implement strong security controls to safeguard cardholder data when it is at rest, whether stored in databases, files, or on removable media.
Requirement 3 aims to:
- Minimize the storage of cardholder data by implementing data retention and disposal policies.
- Prohibit the storage of sensitive authentication data after authorization.
- Protect stored cardholder data through encryption, hashing, masking, or truncation.
- Secure cryptographic keys used to protect stored cardholder data.
- Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
Requirement 3.1: Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures, and processes.
Purpose:
Requirement 3.1 ensures that organizations minimize the storage of cardholder data by implementing data retention and disposal policies, procedures, and processes. This requirement helps organizations reduce the risk of unauthorized access to sensitive cardholder data by limiting the amount of data stored and the duration of storage to what is necessary for legal, regulatory, and business requirements.
Good Practice / Guidance:
3.1.1 Data Retention and Disposal Policies:
Organizations should establish and maintain documented policies, procedures, and processes for data retention and disposal. These policies should cover all cardholder data storage and include specific requirements for data retention, secure deletion of data when no longer needed, and a quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.
3.1.2 Limiting Data Storage and Retention:
The amount of cardholder data stored and the retention time should be limited to what is required for legal, regulatory, and business purposes. Organizations should identify their business needs and any applicable legal or regulatory obligations to define appropriate retention requirements. After authorization, the only cardholder data that may be stored is the primary account number (PAN), which must be rendered unreadable, along with the expiration date, cardholder name, and service code.
3.1.3 Secure Deletion of Data:
When cardholder data is no longer needed, it should be securely deleted using methods that ensure the data cannot be recovered. This process can be automated, manual, or a combination of both. For example, organizations can implement a programmatic procedure (automatic or manual) to locate and remove data and/or perform a manual review of data storage areas.
By adhering to the principle of "if you don't need it, don't store it," organizations can significantly reduce the risk of unauthorized access to cardholder data. Regularly reviewing and updating data retention and disposal policies, procedures, and processes helps ensure that cardholder data is not retained longer than necessary and is securely deleted when no longer needed.
Requirement 3.2: Do not store sensitive authentication data after authorization (even if encrypted).
Purpose:
Requirement 3.2 prohibits the storage of sensitive authentication data after authorization, even if the data is encrypted. Sensitive authentication data includes the full track data from the magnetic stripe or chip, the card verification code or value, and the PIN or PIN block. This requirement aims to prevent the unauthorized use of this data to create counterfeit payment cards or generate fraudulent transactions.
Good Practice / Guidance:
3.2.1 Prohibition of Sensitive Authentication Data Storage:
Organizations should not store sensitive authentication data after authorization, as this data can be used by malicious actors to create counterfeit payment cards and initiate fraudulent transactions. If an organization receives sensitive authentication data, it must render the data unrecoverable upon completion of the authorization process.
3.2.2 Exception for Issuers and Issuing Support Companies:
Issuers and companies that support issuing services may store sensitive authentication data if there is a legitimate business justification, and the data is stored securely in accordance with all PCI DSS and specific payment brand requirements. However, these organizations should be aware that all PCI DSS requirements still apply to them.
3.2.3 Handling of Specific Sensitive Authentication Data:
Requirement 3.2 provides specific guidance on the handling of different types of sensitive authentication data:
- Do not store the full contents of any track from the magnetic stripe or chip.
- Do not store the card verification code or value used to verify card-not-present transactions.
- Do not store the personal identification number (PIN) or the encrypted PIN block.
Organizations should thoroughly examine their systems, processes, and data flows to ensure that sensitive authentication data is not being stored after authorization. This includes reviewing all potential data storage locations, such as transaction logs, history files, debugging logs, and database schemas, to confirm that this data is securely deleted and rendered unrecoverable.
Requirement 3.3: 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 the full PAN.
Purpose:
Requirement 3.3 mandates the masking of the primary account number (PAN) when displayed, limiting the visibility of the full PAN to only personnel with a legitimate business need. This requirement aims to prevent unauthorized individuals from gaining access to the full PAN, reducing the risk of sensitive cardholder data being compromised.
Good Practice / Guidance:
3.3.1 Masking of PAN:
When displaying PAN, organizations should mask the digits such that only the first six and last four digits are visible. This masking applies to all displays of PAN, including but not limited to computer screens, payment card receipts, faxes, and paper reports. Masking the PAN helps protect the data from unauthorized viewing and reduces the risk of it being obtained and used fraudulently.
3.3.2 Access to Full PAN:
Access to the full PAN should be limited to personnel with a legitimate business need. Organizations should document the roles that require access to the full PAN and provide a clear justification for each role's need to view this sensitive data. All other roles should only have access to the masked PAN.
3.3.3 Documenting and Implementing Masking Procedures:
Organizations should establish and maintain written policies and procedures for masking the PAN when displayed. These policies should include the roles authorized to access the full PAN, the business justification for this access, and the requirement for all other roles to view only the masked PAN. The masking policies and procedures should be implemented consistently across all systems and processes where PAN is displayed.
It is important to note that Requirement 3.3 does not supersede stricter requirements for displaying cardholder data, such as those set by legal or payment card brand requirements for point-of-sale (POS) receipts.
Requirement 3.4: Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: [...]
Purpose:
Requirement 3.4 ensures that the primary account number (PAN) is rendered unreadable wherever it is stored, including on portable digital media, backup media, and in logs. This requirement aims to protect the PAN from unauthorized access and reduce the risk of sensitive cardholder data being compromised in the event of a data breach.
Good Practice / Guidance:
3.4.1 Methods for Rendering PAN Unreadable:
Organizations should use one of the following methods to render PAN unreadable:
- One-way hashes based on strong cryptography, with the hashing performed on the entire PAN.
- Truncation, with hashing used to replace the truncated segment of PAN.
- Index tokens and pads, with the pads being securely stored.
- Strong cryptography, with associated key-management processes and procedures.
3.4.2 Protection of PANs in Storage:
PANs should be rendered unreadable wherever they are stored, including in primary storage (e.g., databases, files) and non-primary storage (e.g., backups, audit logs, exception logs). This ensures that even if an attacker gains access to stored data, they will be unable to retrieve the original PAN.
3.4.3 Correlation of Hashed and Truncated PANs:
If hashed and truncated versions of the same PAN are present in an organization's environment, additional controls must be implemented to ensure that these versions cannot be correlated to reconstruct the original PAN. It is important to note that it is relatively easy for a malicious actor to reconstruct the original PAN if they have access to both the truncated and hashed versions of the PAN.
3.4.4 Disk Encryption:
If disk encryption is used instead of file- or column-level database encryption, the encryption solution should not use the same user account authenticator as the operating system or rely on decryption keys derived from an organization's local user account database or general network login credentials. Decryption keys should also not be tied to user accounts.
Organizations should carefully consider the appropriate encryption and key management practices to ensure that stored PANs remain unreadable and secure. Regular reviews of encryption implementations and key management processes help maintain the effectiveness of these safeguards.
Requirement 3.5: Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse.
Purpose:
Requirement 3.5 mandates the documentation and implementation of procedures to protect encryption keys used for securing stored cardholder data. The purpose of this requirement is to prevent the disclosure and misuse of keys, which could lead to the unauthorized access and decryption of sensitive cardholder data.
Good Practice / Guidance:
3.5.1 Documented Key Management Procedures:
Organizations should establish and maintain documented procedures for managing encryption keys used to protect stored cardholder data. These procedures should include:
- Restricting access to keys to the fewest number of custodians necessary.
- Storing keys securely in the fewest possible locations and forms.
- Ensuring that key-encrypting keys are at least as strong as the data-encrypting keys they protect.
- Storing key-encrypting keys separately from data-encrypting keys.
3.5.2 Use of Strong Key-Encrypting Keys:
Key-encrypting keys, if used, must be at least as strong as the data-encrypting keys they protect. This ensures that the key-encrypting keys provide an appropriate level of security for the data-encrypting keys and the cardholder data they ultimately protect.
3.5.3 Secure Storage of Keys:
Encryption keys should be stored securely in the fewest possible locations and forms. This can be achieved by:
- Encrypting keys with a key-encrypting key that is at least as strong as the data-encrypting key and storing the key-encrypting key separately from the data-encrypting key.
- Storing keys within secure cryptographic devices, such as hardware security modules (HSMs) or PTS-approved point-of-interaction devices.
- Storing keys as at least two full-length key components or key shares, in accordance with industry-accepted methods.
3.5.4 Restricting Access to Keys:
Access to encryption keys should be restricted to the fewest number of key custodians necessary for the organization's operations. The distribution of key access helps prevent any single individual from having complete control over the keys and the encrypted cardholder data.
3.5.5 Cryptographic Architecture Documentation (Additional Requirement for Service Providers):
Service providers should maintain documentation detailing their cryptographic architecture, including:
- All algorithms, protocols, and keys used for the protection of cardholder data, along with their key strengths and expiration dates.
- Description of the key usage for each key.
- Inventory of any hardware security modules (HSMs) and other secure cryptographic devices (SCDs) used for key management.
This documentation helps service providers understand and manage their cryptographic systems effectively, ensuring the ongoing protection of cardholder data.
By implementing strong key management practices and regularly reviewing and updating their key management procedures, organizations can significantly reduce the risk of key disclosure and misuse, and protect the confidentiality of stored cardholder data.
Requirement 3.6: Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data.
Purpose:
Requirement 3.6 ensures that organizations have comprehensive and well-documented key-management processes and procedures for cryptographic keys used to encrypt cardholder data. The purpose of this requirement is to maintain the security and integrity of the encryption keys throughout their lifecycle, from generation to retirement, preventing unauthorized access, misuse, or compromise of the keys and the encrypted data they protect.
Good Practice / Guidance:
3.6.1 Documented Key Management Processes and Procedures:
Organizations should fully document and implement all key-management processes and procedures for cryptographic keys used to encrypt cardholder data. These processes and procedures should cover the entire key lifecycle, including:
- Generation of strong cryptographic keys.
- Secure key distribution.
- Secure key storage.
- Periodic key changes and cryptoperiod definitions.
- Retirement or replacement of keys as necessary.
- Procedures for the use of split knowledge and dual control for manual key-management operations.
- Prevention of unauthorized key substitution.
- Key custodian responsibilities.
3.6.2 Industry-Accepted Standards:
Key-management processes and procedures should be based on industry-accepted standards, such as those published by NIST or other recognized authorities. Adhering to these standards helps ensure that the organization's key-management practices are robust, secure, and aligned with best practices.
3.6.3 Regular Review and Update:
Key-management processes and procedures should be regularly reviewed and updated to ensure they remain effective and relevant in the face of evolving threats and changes in the organization's environment. This includes updating procedures when new technologies or best practices emerge, or when changes in the organization's infrastructure or processes occur.
3.6.4 Communication and Awareness:
All relevant personnel should be made aware of and trained on the organization's key-management processes and procedures. This includes key custodians, who should formally acknowledge their understanding and acceptance of their responsibilities.
3.6.5 Retirement or Replacement of Keys:
Processes and procedures should be in place for the secure retirement or replacement of cryptographic keys when their integrity has been weakened, they are suspected of being compromised, or when personnel with knowledge of the keys leave the organization. Retired or replaced keys should be securely archived if they need to be retained, and these keys should only be used for decryption/verification purposes, not for encryption operations.
3.6.6 Split Knowledge and Dual Control for Manual Key Operations:
If manual clear-text key-management operations are used, they must be managed using split knowledge and dual control. Split knowledge ensures that no single person has access to the entire key, while dual control requires at least two people to perform key-management operations, with no one person having access to another's authentication materials.
3.6.7 Prevention of Unauthorized Key Substitution:
Procedures should be in place to prevent the unauthorized substitution of cryptographic keys. This helps maintain the integrity of the keys and ensures that only authorized keys are used for encrypting and decrypting cardholder data.
3.6.8 Key Custodian Responsibilities:
Key custodians should be required to formally acknowledge that they understand and accept their key-custodian responsibilities. This acknowledgment should be documented and helps ensure that key custodians are aware of their obligations in managing and protecting cryptographic keys.
By addressing these additional aspects of key management, organizations can further strengthen their key-management processes and procedures, reducing the risk of key compromise and unauthorized access to encrypted cardholder data.
Requirement 3.7: Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties.
Purpose:
Requirement 3.7 ensures that organizations have documented security policies and operational procedures for protecting stored cardholder data and that these policies and procedures are actively used and known to all relevant personnel. The purpose of this requirement is to maintain a consistent and effective approach to securing stored cardholder data and to ensure that all affected parties understand their roles and responsibilities in protecting this sensitive information.
Good Practice / Guidance:
3.7.1 Documentation of Security Policies and Operational Procedures:
Organizations should document their security policies and operational procedures for protecting stored cardholder data. This documentation should be clear, comprehensive, and easily accessible to all affected parties. The policies and procedures should cover all aspects of cardholder data protection, including data retention and disposal, encryption, key management, access control, and incident response.
3.7.2 Active Use of Policies and Procedures:
The documented security policies and operational procedures should be actively used by all relevant personnel. This means that the policies and procedures should be integrated into the organization's day-to-day operations and that all affected parties should be following them consistently. Organizations should ensure that personnel are aware of and adhering to these policies and procedures on a continuous basis.
3.7.3 Communication and Awareness:
All affected parties should be made aware of the organization's security policies and operational procedures for protecting stored cardholder data. This can be achieved through regular communication, training, and updates to ensure that everyone remains informed of their responsibilities and any changes to the policies and procedures.
To verify compliance with Requirement 3.7, an organization should:
- Examine documentation to ensure that security policies and operational procedures for protecting stored cardholder data are documented.
- Interview personnel to verify that the documented policies and procedures are in use and known to all affected parties.
- Confirm that personnel are aware of and following these policies and procedures on a continuous basis.
By documenting, implementing, and ensuring that all affected parties are aware of and following security policies and operational procedures for protecting stored cardholder data, organizations can maintain a strong security posture and reduce the risk of data breaches. This ongoing commitment to security helps safeguard sensitive cardholder information and demonstrates compliance with PCI DSS requirements.
Read about Requirement 2 here.
