In our exploration of PCI DSS v4.0’s changes, we’ve reached the heart of the matter – Requirement 3: Protect Stored Account Data. While the previous two requirements focused on network and access control, Requirement 3 tackles the crucial issue of securing sensitive cardholder information once it’s captured and stored. So, let’s get started! To learn more about the other requirements of PCI DSS, check out our comprehensive guide on the “12 requirements of PCI DSS.”
So, what’s the purpose of Requirement 3?
It boils down to minimizing the risk of data breaches and maximizing the security of cardholder information. This is achieved through a multi-pronged approach:
-
Data Encryption:
Requirement 3 mandates the use of strong cryptographic controls such as encryption for stored cardholder data. This means that even if a malicious actor gains access to the data, they would not be able to read or use it without the decryption keys.
-
Limited Data Storage:
Organizations are encouraged to limit the amount of stored cardholder data to the minimum necessary for business function. This reduces the potential damage in case of a data breach.
-
Masking:
When displaying cardholder data, Requirement 3 stipulates that only the minimum necessary amount of data should be shown. For example, only the last four digits of a PAN may be displayed.
-
Key Management:
Requirement 3 also covers the secure management of cryptographic keys used for encryption of cardholder data. This includes secure storage, periodic key changes, retirement of old or suspected compromised keys, and prevention of unauthorized key substitutions.
In essence, Requirement 3 aims to create a data security fortress around cardholder information. By minimizing its presence, rendering it unreadable when not actively used, and rigorously validating its protection, organizations significantly reduce the risk of data breaches and ensure the trust of their customers.
Changes in Requirement 3 from PCI DSS v3.2.1 to v4.0:
Now, let’s delve into the modifications introduced in Requirement 3 from v3.2.1 to v4.0.
| PCI DSS v3.2.1 | PCI DSS v4.0 | |
|---|---|---|
| Requirement and Testing Procedures | 3.2.a Review policies and interview staff at issuing entities to confirm justified storage of sensitive authentication data. 3.2.b Inspect data storage and system setups at issuing entities to ensure sensitive authentication data security. | 3.3.3 Issuers storing sensitive authentication data should limit storage to business needs, ensure security, and use strong encryption. 3.3.3.a Review policies and interview staff at issuing entities to confirm justified storage of sensitive authentication data. 3.3.3.b Inspect data storage and system setups at issuing entities to ensure sensitive authentication data security. |
| Requirement and Testing Procedures | 3.1 Minimize cardholder data storage by implementing policies, procedures, and processes for data retention and disposal. This includes: Storing only the minimum data required for legal, regulatory, and business needs Having specific retention periods for cardholder data Securely deleting unneeded data Quarterly identifying and deleting stored cardholder data exceeding defined retention periods. 3.1.a Confirm CHD storage policies for data retention and disposal. Ensure data storage and retention align with legal, regulatory, and business needs. Review specific cardholder data retention requirements. Verify secure data deletion processes. Validate quarterly process for deleting excess stored cardholder data. 3.1.b Interview staff to confirm: All cardholder data locations are in the data retention and disposal processes. A quarterly process exists to delete stored cardholder data. The quarterly process is performed for all cardholder data locations. 3.1.c For selected system components storing cardholder data: Check files and system records to ensure stored data doesn’t exceed policy requirements. Monitor the deletion mechanism to confirm secure data deletion. | 3.1.2 Understand and assign roles for Requirement 3 activities. 3.1.2.a Confirm assignment of roles for Requirement 3 activities through documentation review. 3.1.2.b Ensure understanding and assignment of roles for Requirement 3 activities through personnel interviews. 3.2.1 Implement minimal account data storage policies. Cover all stored account data locations. Protect sensitive authentication data before authorization. Restrict data storage and retention to legal, regulatory, and business needs. Define account data retention requirements with business justification. Establish secure deletion processes for unneeded account data. Perform quarterly checks to delete or render unrecoverable excess data. 3.2.1.a Review policies and interview staff to confirm process compliance. 3.2.1.b Verify policy compliance of data storage and retention in system components. 3.2.1.c Ensure data recovery is impossible through mechanism observation. 3.3.2 Before authorization, SAD is encrypted electronically. Confirm this by examining data stores, system settings, and vendor documents. |
| Requirement and Testing Procedures | 3.3 Display PAN masked (only the first six and last four digits), visible in full only to personnel with a legitimate business need. 3.3.a Review policies and procedures for PAN masking to verify: Roles needing access to more than the first six/last four digits of the PAN are documented with a legitimate business need. PAN is masked when displayed, visible in full only to authorized personnel. Unauthorized roles see only masked PANs. 3.3.b Check system configurations to ensure that full PAN is displayed only for users/roles with a documented business need and masked for all other requests. 3.3.c Check PAN displays to confirm that PANs are masked when displaying cardholder data, and only those with a legitimate business need can see more than the first six/last four digits of the PAN. | 3.4.1 Only personnel with a legitimate business need can see more than the BIN and last four digits of the PAN, which are masked when displayed. 3.4.1.a Policies and procedures for PAN masking should be examined to verify: Roles needing access to more than the BIN and last four digits of the PAN are documented with a legitimate business need. PAN is masked when displayed, visible in full only to authorized personnel. Unauthorized roles see only masked PANs. 3.4.1.b System configurations should be checked to ensure that full PAN is displayed only for roles with a documented business need and masked for all other requests. This doesn’t override stricter requirements for cardholder data displays, such as legal or payment brand requirements for POS receipts. 3.4.1.c Displays of PAN should be examined to confirm that PANs are masked when displayed, and only those with a legitimate business need can see more than the BIN and/or last four digits of the PAN. |
| Requirement and Testing Procedures | 3.4 Make PAN unreadable wherever stored (including portable digital media, backup media, and logs) using methods like one-way hashes, truncation, index tokens and pads, or strong cryptography. 3.4.a Review system documentation to verify PAN is rendered unreadable using methods like one-way hashes, truncation, index tokens and pads, or strong cryptography. 3.4.b Check several tables or files from data repositories to confirm PAN is unreadable. 3.4.c Check a sample of removable media to ensure PAN is unreadable. 3.4.d Check a sample of audit logs to confirm PAN is unreadable or not present. 3.4.e If hashed and truncated PAN versions exist, verify controls prevent their correlation to reconstruct the original PAN. | 3.5.1 PAN is made unreadable using methods like one-way hashes, truncation, index tokens, or strong cryptography. If hashed and truncated versions of the same PAN exist, additional controls prevent correlation to reconstruct the original PAN. 3.5.1.a Review system documentation to verify PAN is rendered unreadable using specified methods. 3.5.1.b Check data repositories and audit logs to confirm PAN is unreadable. 3.5.1.c If hashed and truncated PAN versions exist, verify controls prevent their correlation to reconstruct the original PAN. |
| Requirement and Testing Procedures | 3.5.1 For service providers: Maintain a documented cryptographic architecture, including details of all algorithms, protocols, keys, their usage, and an inventory of Hardware Security Modules (HSMs) and other Secure Cryptographic Devices (SCDs) used for key management. Verify through interviews and document review that a cryptographic architecture description exists, including: Details of all algorithms, protocols, and keys used for cardholder data protection, including key strength and expiry date Key usage description for each key Inventory of HSMs and other SCDs used for key management. | 3.6.1.1 For service providers: Maintain a documented cryptographic architecture, including details of all algorithms, protocols, keys, their usage, and an inventory of Hardware Security Modules (HSMs), Key Management Systems (KMS), and other Secure Cryptographic Devices (SCDs). Prevent the use of identical keys in production and test environments. Verify the existence of this document through interviews and documentation review. Ensure it includes all specified elements. |
| Requirement and Testing Procedures | 12.3.10 For remote-access users, restrict data handling on local and removable media unless explicitly allowed. If allowed, ensure data protection as per PCI DSS Requirements. 12.3.10.a Confirm policies prohibit data handling on local and removable media during remote access. 12.3.10.b For authorized personnel, ensure policies require PCI DSS compliant data protection. | 3.4.2 With remote-access technologies, technical controls prevent PAN copying or relocation, except for authorized personnel with a legitimate business need. 3.4.2.a Review policies and evidence for technical controls that prevent PAN copying or relocation onto local or removable media. Verify that: Controls prevent unauthorized PAN copying or relocation. A list exists of authorized personnel to copy or relocate PAN. 3.4.2.b Check remote-access technology configurations to confirm controls prevent PAN copying or relocation, unless authorized. 3.4.2.c Through observation and interviews, confirm only authorized personnel with a legitimate business need can copy or relocate PAN. |
Also Read : PCI DSS Requirement 2
New requirement:
3.5.1.1 The process of rendering PAN unrecognizable involves using keyed cryptographic hashes that cover the entire PAN. This process is governed by key-management procedures and protocols that align with Requirements 3.6 and 3.7.
- 3.5.1.1.a Review the documentation detailing the hashing method employed to render PAN unrecognizable. This includes information about the vendor, system/process type, and encryption algorithms (where applicable). The review should confirm that the hashing method results in keyed cryptographic hashes of the entire PAN, supported by associated key management processes and procedures.
- 3.5.1.1.b Review the documentation detailing the key management procedures and processes associated with the keyed cryptographic hashes. This review should confirm that keys are managed in line with Requirements 3.6 and 3.7.
- 3.5.1.1.c Inspect data repositories to confirm that the PAN has been rendered unrecognizable.
- 3.5.1.1.d Review audit logs, including payment application logs, to confirm that the PAN has been rendered unrecognizable
Purpose: The elimination of stored PAN in cleartext is a secondary control measure designed to protect the data if an unauthorized individual gains access to stored data by exploiting a vulnerability or misconfiguration in an entity’s primary access control. Independent secondary control systems (for example, those governing access to, and use of, cryptography and decryption keys) prevent a breach of stored PAN confidentiality due to the failure of a primary access control system.
New requirement:
3.5.1.2 If encryption at the disk-level or partition-level (as opposed to file-, column-, or field-level database encryption) is employed to render PAN unrecognizable, it should be implemented in the following manner:
- On removable electronic media,
OR
- If used for non-removable electronic media, PAN should also be rendered unrecognizable using another mechanism that meets Requirement 3.5.1.
- 3.5.1.2.a
Review encryption processes to confirm that, if disk-level or partition-level encryption is employed to render PAN unrecognizable, it is implemented in the following manner:
- On removable electronic media,
OR
- If used for non-removable electronic media, review the encryption processes used to confirm that PAN is also rendered unrecognizable using another method that meets Requirement 3.5.1.
- 3.5.1.2.b
Review configurations and/or vendor documentation and observe encryption processes to confirm that the system is configured according to vendor documentation, resulting in the disk or partition being rendered unrecognizable.
Also Read:- PCI DSS Requirement 4
Purpose: Disk-level and partition-level encryption typically encrypts the entire disk or partition using the same key, with all data automatically decrypted when the system runs or when an authorized user requests it. For this reason, disk-level encryption is not suitable for protecting stored PAN on computers, laptops, servers, storage arrays, or any other system that provides transparent decryption upon user authentication.
You can also watch the video on PCI DSS Requirement 2:
Conclusion:
In this post, we’ve examined PCI DSS Requirement 3 and its evolution from v3.2.1 to v4.0. This requirement, focusing on protecting stored account data, has seen significant changes, underlining the need for organizations to stay current and compliant.
PCI DSS’s goal extends beyond compliance; it’s about creating a secure environment that earns customer trust. We trust this post has shed light on the changes in PCI DSS v4.0.
Stay tuned for our next post on the updated PCI DSS requirements. Until then, stay secure and compliant!
Lets us help you
Need help navigating PCI DSS v4.0? We have been active in the PCI DSS space since 2008 and even certify payment brand. Our PCI DSS services provide assurance on card security controls, with offerings for both product platform and backend services attestation.
We have a dedicated team of auditors and a separate team for consulting/advisory assignments to even help our esteemed clients to define processes and achieve compliance.
We have completed multiple PCI DSS 4.0 certifications too right from scoping to Readiness Assessment, Advisory and Final Certification.
We are vendor neutral and have a strict no-outsourcing policy. We can also assist you with the technical assessments needed for PCI DSS Compliance – Vulnerability Assessment, Penetration Testing, Network Segmentation Testing, Network Architecture Review, Firewall Assessment, Secure Configuration Assessment, Web and Mobile Application Security Assessment, and Secure Code Review.
