Document Comparison
PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r2.pdf
→
PCI-DSS-v4-0-to-v4-0-1-Summary-of-Changes-r1.pdf
7% similar
36 → 11
Pages
11159 → 3511
Words
51
Content Changes
From Revision History
- June 2024
- August 2024 1 Errata update to add “Clarification or Guidance” Change Type for Requirement 6.5.5.
- August 2024 © 2024 PCI Security Standards Council, LLC. All rights reserved. Page ii Table of Contents
- August 2024 © 2024 PCI Security Standards Council, LLC. All rights reserved. Page 1 1
- August 2024 © 2024 PCI Security Standards Council, LLC. All rights reserved. Page 2 2 Change Types
- August 2024 © 2024 PCI Security Standards Council, LLC. All rights reserved. Page 3 PCI DSS Section
Content Changes
51 content changes. 44 administrative changes (dates, page numbers) hidden.
Added
p. 4
The tables included herein summarize the changes for PCI DSS v4.0.1 from PCI DSS v4.0. The summary is organized as follows:
Change Types- provides an overview of the types of changes.
Summary of General Changes - includes descriptions of general changes made throughout.
Change Types- provides an overview of the types of changes.
Summary of General Changes - includes descriptions of general changes made throughout.
Added
p. 5
Update and clarify guidance, including changes to align with subsequent publications (e.g., the v4.0 Quick Reference Guide and recently published FAQs).
Remove Definitions in Guidance if also included in the Glossary and refer to Glossary (Appendix G) instead.
Add references to the Glossary for newly defined glossary terms and for existing glossary terms that did not previously have references.
Change “impact the security of the CDE” to “impact the security of cardholder data and/or sensitive authentication data”, throughout the standard where appropriate.
Update Testing Procedures to align with updated Requirement wording, as needed.
Remove Definitions in Guidance if also included in the Glossary and refer to Glossary (Appendix G) instead.
Add references to the Glossary for newly defined glossary terms and for existing glossary terms that did not previously have references.
Change “impact the security of the CDE” to “impact the security of cardholder data and/or sensitive authentication data”, throughout the standard where appropriate.
Update Testing Procedures to align with updated Requirement wording, as needed.
Added
p. 5
PCI DSS Section Change from PCI DSS v4.0 to PCI DSS v4.0.1
Section 3, Relationship between PCI DSS and PCI SSC Software Standards Reword note to reflect the retirement of PA-DSS.
Update “Validated Software Vendors” to “Qualified Software Vendors.”
Section 4, Scope of PCI DSS Requirements Add sub-section, When Cardholder Data and/or Sensitive Authentication Data is Accidentally Received via an Unintended Channel, to incorporate content previously included in Requirement 4.2.1 Applicability Note.
Section 4, Scope of PCI DSS Requirements Sub-section, Importance of Understanding Responsibilities Between TPSP Customers and TPSPs Clarify this sub-section applies if a TPSP provides a service that meets customers’ PCI DSS requirements or if that service may impact the security of customers’ cardholder data and/or sensitive authentication data.
Section 3, Relationship between PCI DSS and PCI SSC Software Standards Reword note to reflect the retirement of PA-DSS.
Update “Validated Software Vendors” to “Qualified Software Vendors.”
Section 4, Scope of PCI DSS Requirements Add sub-section, When Cardholder Data and/or Sensitive Authentication Data is Accidentally Received via an Unintended Channel, to incorporate content previously included in Requirement 4.2.1 Applicability Note.
Section 4, Scope of PCI DSS Requirements Sub-section, Importance of Understanding Responsibilities Between TPSP Customers and TPSPs Clarify this sub-section applies if a TPSP provides a service that meets customers’ PCI DSS requirements or if that service may impact the security of customers’ cardholder data and/or sensitive authentication data.
Added
p. 6
Clarify that TPSPs must provide customers with documentation about responsibilities only if the TPSP provides a service that meets customers’ PCI DSS requirements or if that service may impact the security of customers’ cardholder data and/or sensitive authentication data.
Section 7, Description of Timeframes Used in PCI DSS Requirements Clarify the Significant Change description.
Clarify that it is considered an initial PCI DSS assessment only when an entity is being assessed for the first time against a PCI DSS requirement with a defined timeframe.
Section 8, Approaches for Implementing and Validating PCI DSS Update Customized Approach references to include the Sample Templates to Support the Customized Approach on the PCI SSC website.
Update the colors and font in Figure 4 and update from “ROC Reporting Template” to “ROC Template.”
Section 13, Additional References Remove URL links.
Section 14, PCI DSS Versions Remove reference to PCI DSS v3.2.1 since it is now retired and clarify that PCI …
Section 7, Description of Timeframes Used in PCI DSS Requirements Clarify the Significant Change description.
Clarify that it is considered an initial PCI DSS assessment only when an entity is being assessed for the first time against a PCI DSS requirement with a defined timeframe.
Section 8, Approaches for Implementing and Validating PCI DSS Update Customized Approach references to include the Sample Templates to Support the Customized Approach on the PCI SSC website.
Update the colors and font in Figure 4 and update from “ROC Reporting Template” to “ROC Template.”
Section 13, Additional References Remove URL links.
Section 14, PCI DSS Versions Remove reference to PCI DSS v3.2.1 since it is now retired and clarify that PCI …
Added
p. 6
PCI DSS Requirement Description of change Change Type
Requirement 1 1.2.2 Add Purpose that was erroneously missing. Clarification or Guidance
Requirement 3 3.3.1 Update Applicability Note for issuers and companies that support issuing services that any SAD storage is based on “a legitimate and documented business need.” Add description of legitimate business need.
Add Good Practice to address when it may be acceptable to store SAD in non-persistent memory.
Clarification or Guidance Update requirement from “SAD is not retained after authorization” to “SAD is not stored after authorization” to align with use of “stored” elsewhere in requirement section 3.3.
PCI DSS Requirement Description of change Change Type 3.3.2 Clarify Applicability Note for issuers and companies that support issuing services that any SAD storage is based on “a legitimate and documented business need.” Add description of legitimate business need.
Update Definitions to align the description of “authorization process” with “authorization” definition in the Glossary.
Clarification or Guidance 3.3.3 …
Requirement 1 1.2.2 Add Purpose that was erroneously missing. Clarification or Guidance
Requirement 3 3.3.1 Update Applicability Note for issuers and companies that support issuing services that any SAD storage is based on “a legitimate and documented business need.” Add description of legitimate business need.
Add Good Practice to address when it may be acceptable to store SAD in non-persistent memory.
Clarification or Guidance Update requirement from “SAD is not retained after authorization” to “SAD is not stored after authorization” to align with use of “stored” elsewhere in requirement section 3.3.
PCI DSS Requirement Description of change Change Type 3.3.2 Clarify Applicability Note for issuers and companies that support issuing services that any SAD storage is based on “a legitimate and documented business need.” Add description of legitimate business need.
Update Definitions to align the description of “authorization process” with “authorization” definition in the Glossary.
Clarification or Guidance 3.3.3 …
Added
p. 10
PCI DSS Requirement Description of change Change Type Add three Applicability Notes to clarify how the requirement applies to an entity’s webpage(s) and a TPSP’s/payment processor’s embedded payment page(s)/form(s).
Expand Purpose to include more details about what can be detected when comparing HTTP headers and content of payment pages received by the consumer browser.
Clarify Examples that mechanisms that detect and report on changes to headers and content of payment pages “could include, but are not limited to, a combination of the following techniques”. Add that the list of mechanisms provided in Examples is not exhaustive.
Requirement 12 12.1.4 Remove examples of common executive management titles for this role from Purpose.
Move description that these positions are often at the most senior level of management to Good Practice.
Add guidance about how information security knowledge for this executive management role can be indicated under Good Practice.
Clarify that the resulting analysis determines and justifies how the …
Expand Purpose to include more details about what can be detected when comparing HTTP headers and content of payment pages received by the consumer browser.
Clarify Examples that mechanisms that detect and report on changes to headers and content of payment pages “could include, but are not limited to, a combination of the following techniques”. Add that the list of mechanisms provided in Examples is not exhaustive.
Requirement 12 12.1.4 Remove examples of common executive management titles for this role from Purpose.
Move description that these positions are often at the most senior level of management to Good Practice.
Add guidance about how information security knowledge for this executive management role can be indicated under Good Practice.
Clarify that the resulting analysis determines and justifies how the …
Added
p. 11
Clarification or Guidance Appendices Appendix A1 Update clause in Overview from “connections to payment gateways and processors” to “payment gateway and processor services offered in a shared environment.” Clarification or Guidance Appendix A3 Update section in Overview that covers defined timeframes to reflect wording in Section 7 and refers to Section 7 for guidance about initial assessments.
Clarification or Guidance Appendix D Update to refer to PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website rather than Appendix E.
Update from “Use of the customized approach must be completed by a QSA or ISA and documented in accordance…” to “Use of the customized approach must be documented by a QSA or ISA in accordance…” Clarification or Guidance Appendix E Remove Customized Approach sample templates and use Appendix E to note the templates are available on the PCI SSC website.
Structure or format Appendix G Add definitions for “Legal …
Clarification or Guidance Appendix D Update to refer to PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website rather than Appendix E.
Update from “Use of the customized approach must be completed by a QSA or ISA and documented in accordance…” to “Use of the customized approach must be documented by a QSA or ISA in accordance…” Clarification or Guidance Appendix E Remove Customized Approach sample templates and use Appendix E to note the templates are available on the PCI SSC website.
Structure or format Appendix G Add definitions for “Legal …
Modified
p. 1
Payment Card Industry Data Security Standard Summary of Changes from PCI DSS Version 3.2.1 to 4.0 Revision 2
Payment Card Industry Data Security Standard Summary of Changes from PCI DSS Version 4.0 to 4.0.1
Removed
p. 2
December 2022 2 Errata update to add a description of the change made to Requirement 6.3.3 and to correct the entry in the Summary of New Requirements table for Requirement 3.6.1.1.
Removed
p. 4
This Summary of Changes is organized as follows:
Additional Changes per Requirement - summarizes additional changes made in requirements 1-12 and the appendices.
Summary of New Requirements - lists all new requirements, the entity to which the new requirement applies (that is, all entities or service providers only), and the effective date of the new requirement.
Additional Changes per Requirement - summarizes additional changes made in requirements 1-12 and the appendices.
Summary of New Requirements - lists all new requirements, the entity to which the new requirement applies (that is, all entities or service providers only), and the effective date of the new requirement.
Modified
p. 4
Summary of General Changes to PCI DSS Introductory Sections - includes descriptions of changes made for each affected section.
Modified
p. 4
Summary of General Changes to PCI DSS Requirements - summarizes changes made throughout the requirements, testing procedures, and guidance.
Summary of Changes to PCI DSS Requirements - includes descriptions of changes made throughout the requirements, testing procedures, and guidance.
Removed
p. 5
PCI DSS Applicability Information
PCI DSS Applicability Information Added sub-headings to increase readability. Clarified that some PCI DSS requirements may apply for entities that do not store, process, or transmit primary account number (PAN). Clarified that terms account data, sensitive authentication data (SAD), cardholder data, and PAN are not interchangeable and are used intentionally in PCI DSS. Clarified table with commonly used elements of cardholder data and SAD, whether storage is permitted, and whether data must be rendered unreadable.
Clarification or guidance Relationship between PCI DSS and PA-DSS Relationship between PCI DSS and PCI SSC Software Standards Refocused section on relationship between PCI DSS and PCI SSC software standards, with mention of PA-DSS (retiring in October 2022).
Evolving requirement Scope of PCI DSS Requirements Scope of PCI DSS Requirements Clarified applicability of PCI DSS requirements and the definition of cardholder data environment (CDE). Expanded examples of system components to which PCI DSS applies; …
PCI DSS Applicability Information Added sub-headings to increase readability. Clarified that some PCI DSS requirements may apply for entities that do not store, process, or transmit primary account number (PAN). Clarified that terms account data, sensitive authentication data (SAD), cardholder data, and PAN are not interchangeable and are used intentionally in PCI DSS. Clarified table with commonly used elements of cardholder data and SAD, whether storage is permitted, and whether data must be rendered unreadable.
Clarification or guidance Relationship between PCI DSS and PA-DSS Relationship between PCI DSS and PCI SSC Software Standards Refocused section on relationship between PCI DSS and PCI SSC software standards, with mention of PA-DSS (retiring in October 2022).
Evolving requirement Scope of PCI DSS Requirements Scope of PCI DSS Requirements Clarified applicability of PCI DSS requirements and the definition of cardholder data environment (CDE). Expanded examples of system components to which PCI DSS applies; …
Modified
p. 5
Clarification or guidance Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Clarification or Guidance Updates to wording, explanation, definition, additional guidance, and/or instruction to increase understanding or provide further information or guidance on a particular topic.
Removed
p. 6
Clarification or guidance Scope of PCI DSS Requirements: Wireless Scope of PCI DSS Requirements: Wireless Clarified that rogue wireless detection (Requirement 11.2.1) must be performed even if wireless is not used in the CDE and even if the entity has a policy that prohibits its use.
Clarification or guidance Scope of PCI DSS Requirements: Encrypted Cardholder Data and Impact on PCI DSS Scope Added sub-section and related content. Clarification or guidance Scope of PCI DSS Requirements: Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers Added new sub-section and related content. Clarification or guidance Scope of PCI DSS Requirements: Use of Third-party Service Providers/Outsour cing Scope of PCI DSS Requirements: Use of Third-party Service Providers Retitled sub-section, added new content, and reorganized existing content under new sub- headings.
Clarification or guidance Best Practices for Implementing PCI DSS into Business-as- Usual Processes Best Practices for Implementing PCI DSS into …
Clarification or guidance Scope of PCI DSS Requirements: Encrypted Cardholder Data and Impact on PCI DSS Scope Added sub-section and related content. Clarification or guidance Scope of PCI DSS Requirements: Encrypted Cardholder Data and Impact to PCI DSS Scope for Third-Party Service Providers Added new sub-section and related content. Clarification or guidance Scope of PCI DSS Requirements: Use of Third-party Service Providers/Outsour cing Scope of PCI DSS Requirements: Use of Third-party Service Providers Retitled sub-section, added new content, and reorganized existing content under new sub- headings.
Clarification or guidance Best Practices for Implementing PCI DSS into Business-as- Usual Processes Best Practices for Implementing PCI DSS into …
Removed
p. 7
Clarification or guidance Description of Timeframes Used in PCI DSS Requirements New section to clarify frequencies and timeframes specified in PCI DSS and related expectations. Added explanation of “significant change.” Clarification or guidance Approaches for Implementing and Validating PCI DSS New section to explain and illustrate the two approaches, defined and customized, for implementing and validating PCI DSS.
Evolving requirement Compensating Controls Approaches for Implementing and Validating PCI DSS Moved content to this section, at a sub-heading under “Defined Approach.” Structure or format Protecting Information About Entity’s Security Posture New section to describe how entities may handle sensitive artifacts from their PCI DSS assessment.
Clarification or guidance Testing Methods for PCI DSS Requirements New section to describe the testing methods used in each PCI DSS Testing Procedures and corresponding expected activities to be performed by the assessor.
PCI DSS Assessment Process
PCI DSS Assessment Process Includes minor clarifications. Moved note that starts “PCI DSS …
Evolving requirement Compensating Controls Approaches for Implementing and Validating PCI DSS Moved content to this section, at a sub-heading under “Defined Approach.” Structure or format Protecting Information About Entity’s Security Posture New section to describe how entities may handle sensitive artifacts from their PCI DSS assessment.
Clarification or guidance Testing Methods for PCI DSS Requirements New section to describe the testing methods used in each PCI DSS Testing Procedures and corresponding expected activities to be performed by the assessor.
PCI DSS Assessment Process
PCI DSS Assessment Process Includes minor clarifications. Moved note that starts “PCI DSS …
Removed
p. 8
Structure or format Updated overview sections and added guidance at the start of each requirement section. Clarification or guidance Added numbered requirement description headings throughout each requirement to organize and describe the requirements that fall under it.
Structure or format Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headings.
Structure or format Rephrased directive requirements to be objective. Evolving requirement Moved examples from requirements or testing procedures into the guidance column. Structure or format Removed references to sampling from testing procedures. Clarification or guidance Shortened testing procedures by clarifying testing is to be done “in accordance with all elements specified in this requirement” to minimize redundancy between requirements and testing procedures.
Clarification or guidance Enhanced testing procedures to clarify level of validation expected for each requirement. Clarification or guidance Reformatted requirements and testing procedures and made minor wording changes for readability
• for example, content from …
Structure or format Renumbered requirements and testing procedures and reorganized requirements due to the addition of numbered requirement description headings.
Structure or format Rephrased directive requirements to be objective. Evolving requirement Moved examples from requirements or testing procedures into the guidance column. Structure or format Removed references to sampling from testing procedures. Clarification or guidance Shortened testing procedures by clarifying testing is to be done “in accordance with all elements specified in this requirement” to minimize redundancy between requirements and testing procedures.
Clarification or guidance Enhanced testing procedures to clarify level of validation expected for each requirement. Clarification or guidance Reformatted requirements and testing procedures and made minor wording changes for readability
• for example, content from …
Modified
p. 8
Clarification or guidance Updated language in requirements and/or corresponding testing procedures for alignment and consistency.
Clarification or Guidance 8.2.2 Update “account” to “ID” in requirement and guidance to align with the Customized Approach Objective.
Removed
p. 9
Requirement 1- General Updated principal requirement title to reflect the focus on “network security controls.” Replaced “firewalls” and “routers” with “network security controls” to support a broader range of technologies used to meet the security objectives traditionally met by firewalls.
Evolving requirement 1.1.5 1.1.2 Replaced requirement for “Description of groups, roles, and responsibilities for management of network components” with general requirement for roles and responsibilities for Requirement 1.
Evolving requirement 1.1 1.2.1 Refocused former “null” requirement (all content pointed to other requirements) on defining, implementing, and maintaining configuration standards for network security control rulesets.
Clarification or guidance 1.1.1 1.2.2 Clarified that changes are managed in accordance with the change control process defined at Requirement 6.5.1.
Clarification or guidance 1.1.4 Removed redundant requirement. Clarification or guidance 1.1.6 1.2.5 1.2.6 Separated into two requirements to clarify intent of each.
Clarification or guidance 1.1.7 1.2.7 Clarified the intent of reviewing configurations of network security controls at least once …
Evolving requirement 1.1.5 1.1.2 Replaced requirement for “Description of groups, roles, and responsibilities for management of network components” with general requirement for roles and responsibilities for Requirement 1.
Evolving requirement 1.1 1.2.1 Refocused former “null” requirement (all content pointed to other requirements) on defining, implementing, and maintaining configuration standards for network security control rulesets.
Clarification or guidance 1.1.1 1.2.2 Clarified that changes are managed in accordance with the change control process defined at Requirement 6.5.1.
Clarification or guidance 1.1.4 Removed redundant requirement. Clarification or guidance 1.1.6 1.2.5 1.2.6 Separated into two requirements to clarify intent of each.
Clarification or guidance 1.1.7 1.2.7 Clarified the intent of reviewing configurations of network security controls at least once …
Modified
p. 9 → 10
Clarification or guidance 1.2 Removed “null” requirement (all content pointed to other requirements).
Clarification or Guidance 12.3.3 Update third bullet of requirement to “Documentation of a plan” (rather than a “A documented strategy”) to align with wording in Requirement 12.3.4.
Removed
p. 10
Clarification or guidance 1.4 1.5.1 Clarified that the intent is to implement security controls on any computing device that connects to both untrusted networks and the CDE.
Modified
p. 10 → 8
Clarification or guidance 1.3.6 1.4.4 Clarified the intent is that system components storing cardholder data are not directly accessible from untrusted networks.
Clarification or Guidance 8.3.9 Clarify Applicability Note that the requirement does not apply to in-scope system components where MFA is used.
Removed
p. 11
Requirement 2 - General Updated principal requirement title to reflect that the focus is on secure configurations in general, and not just on vendor-supplied defaults.
Clarification or guidance 2.1.2 New requirement for roles and responsibilities. This requirement is effective immediately for all v4.0 assessments Evolving requirement 2.1 2.2.2 Clarified that the intent is to understand whether vendor default accounts are in use and to manage them accordingly.
Clarification or guidance 2.2.2 2.2.5 2.2.4 Combined requirements to align similar topics. Structure or format 2.2.3 2.2.5 Clarified that the intent of the requirement is if any insecure services, protocols, or daemons are present.
Clarification or guidance 2.1.1 2.3.1 2.3.2 Split requirement for changing all wireless vendor defaults into two requirements to clarify the focus of each.
Clarification or guidance 2.4 12.5.1 Moved requirement to align related content. Structure or format 2.6 Removed “null” requirement (all content pointed to other requirements).
Requirement 3 - General Updated principal requirement …
Clarification or guidance 2.1.2 New requirement for roles and responsibilities. This requirement is effective immediately for all v4.0 assessments Evolving requirement 2.1 2.2.2 Clarified that the intent is to understand whether vendor default accounts are in use and to manage them accordingly.
Clarification or guidance 2.2.2 2.2.5 2.2.4 Combined requirements to align similar topics. Structure or format 2.2.3 2.2.5 Clarified that the intent of the requirement is if any insecure services, protocols, or daemons are present.
Clarification or guidance 2.1.1 2.3.1 2.3.2 Split requirement for changing all wireless vendor defaults into two requirements to clarify the focus of each.
Clarification or guidance 2.4 12.5.1 Moved requirement to align related content. Structure or format 2.6 Removed “null” requirement (all content pointed to other requirements).
Requirement 3 - General Updated principal requirement …
Removed
p. 11
Evolving requirement 3.1 3.2.1 New requirement bullet to address SAD stored prior to completion of authorization through implementation of data retention and disposal policies, procedures, and processes. This bullet is a best practice until 31 March 2025.
Evolving requirement 3.3.2 New requirement to encrypt SAD that is stored electronically prior to completion of authorization. This requirement is a best practice until 31 March 2025.
Evolving requirement 3.3.2 New requirement to encrypt SAD that is stored electronically prior to completion of authorization. This requirement is a best practice until 31 March 2025.
Modified
p. 11 → 10
Clarification or guidance 2.2.1 2.2.3 Clarified the intent of the requirement for managing primary functions that require different security levels.
Clarification or Guidance 12.3.1 Clarify that the requirement applies only to those PCI DSS requirements that specify completion of a targeted risk analysis.
Removed
p. 12
Clarification or guidance 3.3 3.4.1 Clarified that PAN is masked when displayed such that only personnel with a business need can see more than the BIN/last four digits of the PAN.
Evolving requirement 12.3.10 3.4.2 New requirement for technical controls to prevent copy and/or relocation of PAN when using remote- access technologies. Expanded from former Requirement 12.3.10. This requirement is a best practice until 31 March 2025.
Evolving requirement 3.4 3.5.1 Removed pads from the “Index tokens and pads” bullet for rendering PAN unreadable.
Evolving requirement 3.5.1.1 New requirement for keyed cryptographic hashes when hashing is used to render PAN unreadable. This requirement is a best practice until 31 March 2025.
Evolving requirement 3.5.1.2 New requirement that disk-level or partition-level encryption is used only to render PAN unreadable on removable electronic media or, if used on non- removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement 3.5.1. This …
Evolving requirement 12.3.10 3.4.2 New requirement for technical controls to prevent copy and/or relocation of PAN when using remote- access technologies. Expanded from former Requirement 12.3.10. This requirement is a best practice until 31 March 2025.
Evolving requirement 3.4 3.5.1 Removed pads from the “Index tokens and pads” bullet for rendering PAN unreadable.
Evolving requirement 3.5.1.1 New requirement for keyed cryptographic hashes when hashing is used to render PAN unreadable. This requirement is a best practice until 31 March 2025.
Evolving requirement 3.5.1.2 New requirement that disk-level or partition-level encryption is used only to render PAN unreadable on removable electronic media or, if used on non- removable electronic media, the PAN is also rendered unreadable via a mechanism that meets Requirement 3.5.1. This …
Removed
p. 14
Evolving requirement 5.3.3 New requirement for a malware solution for removable electronic media. This requirement is a best practice until 31 March 2025.
Evolving requirement 5.4.1 New requirement to detect and protect personnel against phishing attacks. This requirement is a best practice until 31 March 2025.
Requirement 6 - General Updated principal requirement title to include “software” rather than “applications.” Clarified that Requirement 6 applies to all system components, except for Requirement 6.2, which applies only to bespoke and custom software.
Evolving requirement 6.3 6.2.1 Moved requirement for developing software securely to align all software development content under Requirement 6.2.
Structure or format Replaced “internal and external” with “bespoke and custom” software. Clarified that this requirement applies to software developed for or by the entity for the entity’s own use and does not apply to third-party software.
Clarification or guidance 6.5 6.2.2 Moved the elements of Requirement 6.5 for training of software developers to align …
Evolving requirement 5.4.1 New requirement to detect and protect personnel against phishing attacks. This requirement is a best practice until 31 March 2025.
Requirement 6 - General Updated principal requirement title to include “software” rather than “applications.” Clarified that Requirement 6 applies to all system components, except for Requirement 6.2, which applies only to bespoke and custom software.
Evolving requirement 6.3 6.2.1 Moved requirement for developing software securely to align all software development content under Requirement 6.2.
Structure or format Replaced “internal and external” with “bespoke and custom” software. Clarified that this requirement applies to software developed for or by the entity for the entity’s own use and does not apply to third-party software.
Clarification or guidance 6.5 6.2.2 Moved the elements of Requirement 6.5 for training of software developers to align …
Removed
p. 15
Clarification or guidance 6.3 Moved requirements for identifying security vulnerabilities and protecting system components from vulnerabilities via patching under Requirement 6.3.
Structure or format 6.1 6.3.1 Added a bullet to clarify applicability to vulnerabilities for bespoke and custom and third-party software.
Clarification or guidance 6.3.2 New requirement to maintain an inventory of bespoke and custom software. This requirement is a best practice until 31 March 2025.
Evolving requirement 6.2 6.3.3 Changed the applicable security patches to be installed within one month of release from “critical security patches” to “critical or high-security patches/updates.” Evolving requirement 6.6 6.4.1 Moved requirement for addressing new threats and vulnerabilities for public-facing web applications under Requirement 6.4.
Structure or format 6.4.2 New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment …
Structure or format 6.1 6.3.1 Added a bullet to clarify applicability to vulnerabilities for bespoke and custom and third-party software.
Clarification or guidance 6.3.2 New requirement to maintain an inventory of bespoke and custom software. This requirement is a best practice until 31 March 2025.
Evolving requirement 6.2 6.3.3 Changed the applicable security patches to be installed within one month of release from “critical security patches” to “critical or high-security patches/updates.” Evolving requirement 6.6 6.4.1 Moved requirement for addressing new threats and vulnerabilities for public-facing web applications under Requirement 6.4.
Structure or format 6.4.2 New requirement to deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks. This new requirement removes the option in Requirement 6.4.1 to review web applications via manual or automated application vulnerability assessment …
Removed
p. 16
Clarification or guidance 6.4.2 6.5.4 Changed term from “development/test and production” to “production and pre-production” environments. Changed term “separation of duties” and clarified that separation of roles and functions between production and pre-production is intended to provide accountability so that only approved changes are deployed.
Clarification or guidance 6.4.3 6.5.5 Changed term from “testing or development” to “pre- production” environments. Clarified that live PANs are not used in pre- production environments except where all applicable PCI DSS requirements are in place.
Requirement 7 - General Updated principal requirement title to include system components and cardholder data.
Evolving requirement 7.1 7.2.1 7.2.2 7.2.3 Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement.
Clarification or guidance 7.1.2 7.1.3 7.2.2 Combined requirements for assigning access based on job classification and function, and least privileges.
Structure or format 7.1.4 7.2.3 Clarified requirement is about approval of required privileges by …
Clarification or guidance 6.4.3 6.5.5 Changed term from “testing or development” to “pre- production” environments. Clarified that live PANs are not used in pre- production environments except where all applicable PCI DSS requirements are in place.
Requirement 7 - General Updated principal requirement title to include system components and cardholder data.
Evolving requirement 7.1 7.2.1 7.2.2 7.2.3 Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement.
Clarification or guidance 7.1.2 7.1.3 7.2.2 Combined requirements for assigning access based on job classification and function, and least privileges.
Structure or format 7.1.4 7.2.3 Clarified requirement is about approval of required privileges by …
Modified
p. 16 → 9
Clarification or guidance 7.1.1 7.2.1 Clarified requirement is about defining an access control model.
Clarification or Guidance 9.2.1 Add Applicability Note that this requirement does not apply to locations that are publicly accessible by consumers (cardholders).
Removed
p. 17
Evolving requirement 8.7 7.2.6 Moved requirement since it aligns better with the content in Requirement 7.
Removed
p. 17
Requirement 8 - General Standardized on terms “authentication factor” and “authentication credentials.” Removed “non-consumer users” and clarified in the overview that requirements do not apply to accounts used by consumers (cardholders).
Clarification or guidance Removed note in overview that listed requirements that do not apply to user accounts with access to only one card number at a time to facilitate a single transaction and added that note to each related requirement.
Structure or format 8.1.2 New requirement for roles and responsibilities. This requirement is effective immediately for all v4.0 assessments.
Clarification or guidance 8.5 8.2.2 Changed focus of requirement to allow use of shared authentication credentials, but only on an exception basis.
Evolving requirement Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Clarification or guidance 8.2.2 8.2.3 Moved requirements for …
Clarification or guidance Removed note in overview that listed requirements that do not apply to user accounts with access to only one card number at a time to facilitate a single transaction and added that note to each related requirement.
Structure or format 8.1.2 New requirement for roles and responsibilities. This requirement is effective immediately for all v4.0 assessments.
Clarification or guidance 8.5 8.2.2 Changed focus of requirement to allow use of shared authentication credentials, but only on an exception basis.
Evolving requirement Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Clarification or guidance 8.2.2 8.2.3 Moved requirements for …
Modified
p. 17 → 8
Requirement 8
• General Update the following statement in the Overview and in Applicability Notes for several requirements: “Certain requirements are not intended to apply to user accounts on point-of- sale terminals that have access to only once card number at a time to facilitate a single transaction” to add italicized wording and to remove the example included in parentheses.
• General Update the following statement in the Overview and in Applicability Notes for several requirements: “Certain requirements are not intended to apply to user accounts on point-of- sale terminals that have access to only once card number at a time to facilitate a single transaction” to add italicized wording and to remove the example included in parentheses.
Removed
p. 18
Structure or format Increased the number of invalid authentication attempts before locking out a user ID from six to 10 attempts.
Evolving requirement 8.2.6 8.3.5 Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1.
Evolving requirement 8.2.6 8.3.5 Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1.
Removed
p. 18
Evolving requirement 8.2.5 8.3.7 Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Structure or format 8.4 8.3.8 Moved content about communicating user authentication policies and procedures under Requirement 8.3.
Structure or format 8.2.4 8.3.9 Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation). Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. Added a note that this requirement does not apply to service providers’ customer accounts, but does apply to accounts for service provider personnel.
Structure or format 8.4 8.3.8 Moved content about communicating user authentication policies and procedures under Requirement 8.3.
Structure or format 8.2.4 8.3.9 Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation). Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction. Added a note that this requirement does not apply to service providers’ customer accounts, but does apply to accounts for service provider personnel.
Removed
p. 19
Evolving requirement 8.2.4.b 8.3.10 Moved content from a former testing procedure to a requirement for service providers to provide guidance to customers about changing passwords/ passphrases. Added a note that this requirement will be superseded by Requirement 8.3.10.1 once Requirement 8.3.10.1 becomes effective.
Structure or format 8.3.10.1 New requirement for service providers only
• if passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts. This requirement is a best practice until 31 March 2025. Added a note that this requirement does not apply to accounts of consumer users accessing their payment card information. Added a note that this requirement will supersede Requirement 8.3.10 once it becomes effective, and until that date, service providers may meet either Requirement 8.3.10 or 8.3.10.1.
Evolving requirement 8.6 8.3.11 Moved …
Structure or format 8.3.10.1 New requirement for service providers only
• if passwords/passphrases are the only authentication factor for customer user access, then passwords/passphrases are either changed at least once every 90 days or access to resources is automatically determined by dynamically analyzing the security posture of the accounts. This requirement is a best practice until 31 March 2025. Added a note that this requirement does not apply to accounts of consumer users accessing their payment card information. Added a note that this requirement will supersede Requirement 8.3.10 once it becomes effective, and until that date, service providers may meet either Requirement 8.3.10 or 8.3.10.1.
Evolving requirement 8.6 8.3.11 Moved …
Removed
p. 20
Evolving requirement 8.6.2 New requirement for not hard-coding passwords/passphrases into files or scripts for any application and system accounts that can be used for interactive login. This requirement is a best practice until 31 March 2025.
Evolving requirement 8.6.3 New requirement for protecting passwords/passphrases for application and system accounts against misuse. This requirement is a best practice until 31 March 2025.
Requirement 9 - General In the overview, clarified the three different areas covered in Requirement 9 (sensitive areas, CDE, and facilities). Throughout, clarified whether each requirement applies to the CDE, sensitive areas, or facilities.
Evolving requirement 9.1 9.2.4 Added a requirement to address a former testing procedure bullet to restrict access to consoles in sensitive areas via locking when not in use.
Clarification or guidance 9.2 9.3.1 9.3.2 Split requirement for identifying personnel and visitors into separate requirements, Requirements 9.3.1 and 9.3.2 respectively.
Structure or format 9.4 9.4.1 9.4.2 9.3.2 Combined requirements for authorizing …
Evolving requirement 8.6.3 New requirement for protecting passwords/passphrases for application and system accounts against misuse. This requirement is a best practice until 31 March 2025.
Requirement 9 - General In the overview, clarified the three different areas covered in Requirement 9 (sensitive areas, CDE, and facilities). Throughout, clarified whether each requirement applies to the CDE, sensitive areas, or facilities.
Evolving requirement 9.1 9.2.4 Added a requirement to address a former testing procedure bullet to restrict access to consoles in sensitive areas via locking when not in use.
Clarification or guidance 9.2 9.3.1 9.3.2 Split requirement for identifying personnel and visitors into separate requirements, Requirements 9.3.1 and 9.3.2 respectively.
Structure or format 9.4 9.4.1 9.4.2 9.3.2 Combined requirements for authorizing …
Removed
p. 21
Clarification or guidance 9.4.5 9.4.5.1 Removed requirement for procedures for strict control over storage and accessibility of media (9.7) and merged the procedures into the related requirements. Split requirement for maintaining media inventory logs and conducting media inventories annually into 2 requirements.
Clarification or guidance 9.8 9.8.1 9.8.2 9.4.6 9.4.7 Removed requirement for procedures for media destruction when media is no longer needed (9.8) and merged the procedures into the related requirements. Clarified options for destroying media when no longer needed includes either destruction of electronic media or rendering cardholder data unrecoverable.
Clarification or guidance 9.9 9.5.1 Clarified the focus of the requirement is on “Point-of- interaction (POI) devices that capture payment card data via direct physical interaction with the payment card form factor.” Clarified that this requirement applies to deployed POI devices used in card-present transactions.
Clarification or guidance 9.5.1.2.1 New requirement to define the frequency of periodic POI device inspections based …
Clarification or guidance 9.8 9.8.1 9.8.2 9.4.6 9.4.7 Removed requirement for procedures for media destruction when media is no longer needed (9.8) and merged the procedures into the related requirements. Clarified options for destroying media when no longer needed includes either destruction of electronic media or rendering cardholder data unrecoverable.
Clarification or guidance 9.9 9.5.1 Clarified the focus of the requirement is on “Point-of- interaction (POI) devices that capture payment card data via direct physical interaction with the payment card form factor.” Clarified that this requirement applies to deployed POI devices used in card-present transactions.
Clarification or guidance 9.5.1.2.1 New requirement to define the frequency of periodic POI device inspections based …
Removed
p. 21
• 10.3.4 Moved audit log protection requirements under Requirement 10.3.
Removed
p. 22
• 10.4.3 Moved requirements for audit log reviews under Requirement 10.4.
Structure or format 10.4.1.1 New requirement for the use of automated mechanisms to perform audit log reviews. This requirement is a best practice until 31 March 2025.
Evolving requirement 10.4.2.1 New requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) This requirement is a best practice until 31 March 2025.
Evolving requirement 10.7 10.5.1 Moved requirement for audit log history to 10.5.1. Structure or format 10.4 10.4.1
• 10.4.3 10.6.1
• 10.6.3 Moved and reorganized requirements for time synchronization under 10.6.
Structure or format 10.8 10.7.1 Moved requirement for service providers to detect, alert, and promptly address failures of critical control systems to Requirement 10.7.1.
Structure or format 10.7.2 New requirement for all entities to detect, alert, and promptly address failures of critical security control systems. This requirement is a best …
Structure or format 10.4.1.1 New requirement for the use of automated mechanisms to perform audit log reviews. This requirement is a best practice until 31 March 2025.
Evolving requirement 10.4.2.1 New requirement for a targeted risk analysis to define the frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) This requirement is a best practice until 31 March 2025.
Evolving requirement 10.7 10.5.1 Moved requirement for audit log history to 10.5.1. Structure or format 10.4 10.4.1
• 10.4.3 10.6.1
• 10.6.3 Moved and reorganized requirements for time synchronization under 10.6.
Structure or format 10.8 10.7.1 Moved requirement for service providers to detect, alert, and promptly address failures of critical control systems to Requirement 10.7.1.
Structure or format 10.7.2 New requirement for all entities to detect, alert, and promptly address failures of critical security control systems. This requirement is a best …
Removed
p. 23
Requirement 11 - General Minor update to principal requirement title. Clarification or guidance 11.1.2 New requirement for roles and responsibilities. This requirement is effective immediately for all v4.0 assessments.
Evolving requirement 11.1 11.2.1 Clarified the intent of the requirement is to manage both authorized and unauthorized wireless access points. Clarified that this requirement applies even when a policy exists to prohibit the use of wireless technology.
Clarification or guidance 11.3.1.1 New requirement to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans. This requirement is a best practice until 31 March 2025.
Evolving requirement 11.3.1.2 New requirement to perform internal vulnerability scans via authenticated scanning. This requirement is a best practice until 31 March 2025.
Evolving requirement 11.2.3 11.3.1.3 11.3.2.1 Separated requirement to perform internal and external vulnerability scans and rescans after any significant changes into a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1).
Structure …
Evolving requirement 11.1 11.2.1 Clarified the intent of the requirement is to manage both authorized and unauthorized wireless access points. Clarified that this requirement applies even when a policy exists to prohibit the use of wireless technology.
Clarification or guidance 11.3.1.1 New requirement to manage all other applicable vulnerabilities (those not ranked as high-risk or critical) found during internal vulnerability scans. This requirement is a best practice until 31 March 2025.
Evolving requirement 11.3.1.2 New requirement to perform internal vulnerability scans via authenticated scanning. This requirement is a best practice until 31 March 2025.
Evolving requirement 11.2.3 11.3.1.3 11.3.2.1 Separated requirement to perform internal and external vulnerability scans and rescans after any significant changes into a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1).
Structure …
Removed
p. 24
Evolving requirement 11.6.1 New requirement to deploy a change-and-tamper- detection mechanism to alert for unauthorized modifications to the HTTP headers and contents of payment pages as received by the consumer browser. This requirement is a best practice until 31 March 2025.
Structure or format 11.1.2 12.10.5 Moved requirement for incident response procedures if unauthorized wireless access points are detected to align with other incident response items.
Structure or format 11.5.1 12.10.5 Moved requirement to respond to alerts generated by the change-detection solution to align with other the incident response items.
Requirement 12 - General Updated principal requirement title to reflect that the focus is on organizational policies and programs that support information security.
Clarification or guidance 12.2 Removed requirement for a formal organization-wide risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).
Evolving requirement 12.4 12.1.3 Added formal acknowledgment by personnel of their responsibilities.
Evolving requirement 12.5 12.5.1
• 12.5.5 12.1.4 Clarified that responsibilities …
Structure or format 11.1.2 12.10.5 Moved requirement for incident response procedures if unauthorized wireless access points are detected to align with other incident response items.
Structure or format 11.5.1 12.10.5 Moved requirement to respond to alerts generated by the change-detection solution to align with other the incident response items.
Requirement 12 - General Updated principal requirement title to reflect that the focus is on organizational policies and programs that support information security.
Clarification or guidance 12.2 Removed requirement for a formal organization-wide risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).
Evolving requirement 12.4 12.1.3 Added formal acknowledgment by personnel of their responsibilities.
Evolving requirement 12.5 12.5.1
• 12.5.5 12.1.4 Clarified that responsibilities …
Removed
p. 25
Evolving requirement 12.3.1 New requirement to perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it is performed. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.3.2 New requirement for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. This requirement is effective immediately for all entities undergoing a v4.0 assessment and using a customized approach.
Evolving requirement 12.3.3 New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.3.4 New requirement to review hardware and software technologies in use at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.11 12.11.1 12.4.2 12.4.2.1 Moved requirements for reviews to …
Evolving requirement 12.3.2 New requirement for entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. This requirement is effective immediately for all entities undergoing a v4.0 assessment and using a customized approach.
Evolving requirement 12.3.3 New requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.3.4 New requirement to review hardware and software technologies in use at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.11 12.11.1 12.4.2 12.4.2.1 Moved requirements for reviews to …
Removed
p. 26
Evolving requirement 12.6 12.6.1 Clarified that the intent is that all personnel are aware of the entity’s information security policy and their role in protecting cardholder data.
Clarification or guidance 12.6.2 New requirement to review and update (as needed) the security awareness program at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.6.1 12.6.2 12.6.3 Merged requirements for security awareness training. Structure or 12.6.3.1 New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.6.3.2 New requirement for security awareness training to include awareness about the acceptable use of end- user technologies in accordance with Requirement 12.2.1. This requirement is a best practice until 31 March 2025.
• 12.8.5 Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the use of …
Clarification or guidance 12.6.2 New requirement to review and update (as needed) the security awareness program at least once every 12 months. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.6.1 12.6.2 12.6.3 Merged requirements for security awareness training. Structure or 12.6.3.1 New requirement for security awareness training to include awareness of threats and vulnerabilities that could impact the security of the CDE. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.6.3.2 New requirement for security awareness training to include awareness about the acceptable use of end- user technologies in accordance with Requirement 12.2.1. This requirement is a best practice until 31 March 2025.
• 12.8.5 Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the use of …
Removed
p. 27
Clarification or guidance 12.8.5 12.8.5 Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity.
Clarification or guidance 12.9.2 New requirement for service providers to support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. This requirement is effective immediately for all v4.0 assessments.
Structure or format 12.10.1 12.10.1 Replaced “system breach” and “compromise” with “suspected or confirmed security incident.” Clarification or guidance 12.10.3 12.10.3 Replaced “alerts” with “suspected or confirmed security incidents.” Clarification or guidance 12.10.4 12.10.4 Replaced “system breach” with “suspected or confirmed security incidents.” Clarification or guidance 12.10.4.1 New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.10.5 11.1.2 11.5.1 12.10.5 …
Clarification or guidance 12.9.2 New requirement for service providers to support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. This requirement is effective immediately for all v4.0 assessments.
Structure or format 12.10.1 12.10.1 Replaced “system breach” and “compromise” with “suspected or confirmed security incident.” Clarification or guidance 12.10.3 12.10.3 Replaced “alerts” with “suspected or confirmed security incidents.” Clarification or guidance 12.10.4 12.10.4 Replaced “system breach” with “suspected or confirmed security incidents.” Clarification or guidance 12.10.4.1 New requirement to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. This requirement is a best practice until 31 March 2025.
Evolving requirement 12.10.5 11.1.2 11.5.1 12.10.5 …
Removed
p. 28
Evolving requirement Appendix A1 Appendix A1 - General Updated principal requirements title to reflect focus on multi-tenant service providers. Updated requirement overview to describe multi- tenant service providers and their environments, and to clarify responsibilities between multi-tenant service providers and their customers. Updated “shared hosting provider” to “multi-tenant hosting provider” throughout.
Clarification or guidance A1 Removed “null” requirement (all content pointed to other requirements).
Structure or format A1.1.1 New requirement for to implement logical separation between providers’ environments and customers’ environments. This requirement is a best practice until 31 March 2025.
Evolving requirement A1.1.4 New requirement to confirm, via penetration testing, the effectiveness of logical separation controls used to separate customer environments. This requirement is a best practice until 31 March 2025.
Evolving requirement A1.2.3 New requirement for the implementation of processes and mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities. This requirement is a best practice until 31 March …
Clarification or guidance A1 Removed “null” requirement (all content pointed to other requirements).
Structure or format A1.1.1 New requirement for to implement logical separation between providers’ environments and customers’ environments. This requirement is a best practice until 31 March 2025.
Evolving requirement A1.1.4 New requirement to confirm, via penetration testing, the effectiveness of logical separation controls used to separate customer environments. This requirement is a best practice until 31 March 2025.
Evolving requirement A1.2.3 New requirement for the implementation of processes and mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities. This requirement is a best practice until 31 March …
Removed
p. 29
Clarification or guidance A3.2.1 A3.2.1 Updated the elements included for PCI DSS scope documentation and confirmation to align with new PCI DSS Requirement 12.5.2.
Evolving requirement A3.3.1 New requirement bullet to detect, alert, and report failures of automated log review mechanisms. New requirement bullet to detect, alert, and report failures of automated code review tools. These bullets are best practices until 31 March 2025.
Evolving requirement Appendix B: Compensating Controls Appendix B: Compensating Controls Clarified that compensating controls may be considered when an entity cannot meet a PCI DSS requirement explicitly as written, due to “legitimate and documented technical or business constraints.” Updated item 2 to mention the Customized Approach Objective and its use to understand the intent of most PCI DSS requirements. Clarified the intent of item 4 is to address the risk imposed by not adhering to the PCI DSS requirement. Added item 6 to clarify that compensating controls are …
Evolving requirement A3.3.1 New requirement bullet to detect, alert, and report failures of automated log review mechanisms. New requirement bullet to detect, alert, and report failures of automated code review tools. These bullets are best practices until 31 March 2025.
Evolving requirement Appendix B: Compensating Controls Appendix B: Compensating Controls Clarified that compensating controls may be considered when an entity cannot meet a PCI DSS requirement explicitly as written, due to “legitimate and documented technical or business constraints.” Updated item 2 to mention the Customized Approach Objective and its use to understand the intent of most PCI DSS requirements. Clarified the intent of item 4 is to address the risk imposed by not adhering to the PCI DSS requirement. Added item 6 to clarify that compensating controls are …
Modified
p. 29 → 7
Clarification or guidance Appendix D: Customized Approach New Appendix to explain and provide instructions for the Customized Approach.
Clarification or Guidance 3.5.1.2 Add a Customized Approach Objective to provide flexibility for meeting this requirement.
Removed
p. 30
• E1 Sample Controls Matrix Template
• E2 Sample Targeted Risk Analysis Template.
Clarification or guidance Appendix F: Leveraging the PCI Software Security Framework to Support Requirement 6 New Appendix to describe how an entity can meet several requirements in Requirement 6 by use of bespoke or custom software that is developed and maintained in accordance with one of PCI SSC’s Secure Software Standards.
Clarification or guidance Appendix G: PCI DSS Glossary of Terms, Abbreviations, and Acronyms New Appendix for the PCI DSS v4.0 Glossary. General updates to the Glossary include:
• Added new terms based on updated requirements or based on feedback,
• Removed common terms that can be readily found with other sources,
• Removed terms not used in PCI DSS v4.0,
• Shortened acronym definitions.
Clarification or guidance Appendix D: Segmentation and Sampling of Business Facilities/ System Components Removed Appendix and moved former content to sections titled “Segmentation” and “For Assessors: Sampling for PCI DSS …
• E2 Sample Targeted Risk Analysis Template.
Clarification or guidance Appendix F: Leveraging the PCI Software Security Framework to Support Requirement 6 New Appendix to describe how an entity can meet several requirements in Requirement 6 by use of bespoke or custom software that is developed and maintained in accordance with one of PCI SSC’s Secure Software Standards.
Clarification or guidance Appendix G: PCI DSS Glossary of Terms, Abbreviations, and Acronyms New Appendix for the PCI DSS v4.0 Glossary. General updates to the Glossary include:
• Added new terms based on updated requirements or based on feedback,
• Removed common terms that can be readily found with other sources,
• Removed terms not used in PCI DSS v4.0,
• Shortened acronym definitions.
Clarification or guidance Appendix D: Segmentation and Sampling of Business Facilities/ System Components Removed Appendix and moved former content to sections titled “Segmentation” and “For Assessors: Sampling for PCI DSS …
Removed
p. 35
A1.1.1 The multi-tenant service provider confirms access to and from customer environment is logically separated to prevent unauthorized access.
A1.1.4 The multi-tenant service provider confirms effectiveness of logical separation controls used to separate customer environments at leave once every six months via penetration testing.
A1.1.4 The multi-tenant service provider confirms effectiveness of logical separation controls used to separate customer environments at leave once every six months via penetration testing.
Removed
p. 36
A3.3.1 Failures of the following are detected, alerted, and reported in a timely manner: Automated log review mechanisms Automated code review tools.
Totals: 53 11 13 51 Grand Total: 64
Totals: 53 11 13 51 Grand Total: 64