Document Comparison
PCI-DSS-v4-0-SAQ-A-EP-r2.pdf
→
PCI-DSS-v4-0-1-SAQ-A-EP.pdf
93% similar
81 → 83
Pages
21624 → 21994
Words
85
Content Changes
Content Changes
85 content changes. 35 administrative changes (dates, page numbers) hidden.
Added
p. 2
Updated an SAQ Eligibility Criteria that the merchant has confirmed “their TPSP(s) are PCI DSS compliant for the services used by the merchant” rather than that the merchant has reviewed the TPSP(s)’ AOCs.
Added ASV Resource Guide to section “Additional PCI SSC Resources.” Added SAQ Completion Guidance to Requirements 6.4.3 and 11.6.1.
Added ASV Resource Guide to section “Additional PCI SSC Resources.” Added SAQ Completion Guidance to Requirements 6.4.3 and 11.6.1.
Added
p. 7
Note: A legal exception is a legal restriction due to a local or regional law, regulation, or regulatory requirement, where meeting a PCI DSS requirement would violate that law, regulation, or regulatory requirement.
PCI Data Security Standard Requirements and Testing Procedures (PCI DSS) Guidance on Scoping Guidance on the intent of all PCI DSS Requirements Details of testing procedures Guidance on Compensating Controls Appendix G: Glossary of Terms, Abbreviations, and Acronyms SAQ Instructions and Guidelines Information about all SAQs and their eligibility criteria How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs) Guidance and information about SAQs.
PCI Data Security Standard Requirements and Testing Procedures (PCI DSS) Guidance on Scoping Guidance on the intent of all PCI DSS Requirements Details of testing procedures Guidance on Compensating Controls Appendix G: Glossary of Terms, Abbreviations, and Acronyms SAQ Instructions and Guidelines Information about all SAQs and their eligibility criteria How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs) Guidance and information about SAQs.
Added
p. 15
Defined. Implemented. Maintained.
Added
p. 24
Applicability Notes (continued) (cont.) Part of this Applicability Note was intentionally removed as it does not apply to SAQ A-EP assessments.
Added
p. 40
This requirement also applies to scripts in the entity’s webpage(s) that includes a TPSP’s/ payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).
This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.
Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.
Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 6.5 Changes to all system components are managed securely.
This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.
Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.
Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 6.5 Changes to all system components are managed securely.
Added
p. 51
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• User accounts that are only authenticated with phishing-resistant authentication factors.
• User accounts that are only authenticated with phishing-resistant authentication factors.
Added
p. 56
Applicability Notes Part of this Applicability Note was intentionally removed as it does not apply to SAQ A-EP assessments.
Added
p. 63
Note: For SAQ A-EP, Requirement 11 applies to merchant servers and networks that host the payment page(s) provided from the merchant’s website to the customer’s browser.
Added
p. 69
Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.
Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place This requirement also applies to entities with a webpage(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes.) This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.
Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place This requirement also applies to entities with a webpage(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes.) This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.
Added
p. 74
The TPSP’s written acknowledgment is a confirmation that states the TPSP is responsible for the security of the account data it may store, process, or transmit on behalf of the customer or to the extent the TPSP may impact the security of a customer’s cardholder data and/or sensitive authentication data.
Modified
p. 2
Rearranged, retitled, and expanded information in the “Completing the Self-Assessment Questionnaire” section (previously titled “Before You Begin”).
Rearranged, retitled, and expanded information in the “Completing the Self- Assessment Questionnaire” section (previously titled “Before You Begin”).
Modified
p. 2
September 2023 4.0 2 Removed erroneous SAQ Completion Guidance at Requirement 11.6.1 - it is not applicable to SAQ A-EP merchants.
September 2023 4.0 2 Removed erroneous SAQ Completion Guidance at Requirement 11.6.1 − it is not applicable to SAQ A-EP merchants.
Modified
p. 4
The merchant accepts only e-commerce transactions; All processing of account data, with the exception of the payment page, is entirely outsourced to a PCI DSS compliant third-party service provider (TPSP)/payment processor; The merchant’s e-commerce website does not receive account data but controls how customers, or their account data, are redirected to a PCI DSS compliant TPSP/payment processor; If the merchant website is hosted by a TPSP, the TPSP is compliant with all applicable PCI DSS requirements …
Modified
p. 5
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). Cardholder data and sensitive authentication data are considered account data and are defined as follows:
PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of cardholder data and/or sensitive authentication data. Cardholder data and sensitive authentication data are considered account data and are defined as follows:
Modified
p. 5
Section 1: Assessment Information (Parts 1 & 2 of the Attestation of Compliance (AOC) • Contact Information and Executive Summary).
Modified
p. 5
•Self-Assessment Questionnaire A-EP.
Section 2
•Self-Assessment Questionnaire A-EP.
•Self-Assessment Questionnaire A-EP.
Modified
p. 5
Section 3: Validation and Attestation Details (Parts 3 & 4 of the AOC • PCI DSS Validation and Action Plan for Non-Compliant Requirements (if Part 4 is applicable)).
Modified
p. 5
5. Submit the SAQ and AOC, along with any other requested documentation•such as ASV scan reports•to the requesting organization (those organizations that manage compliance programs such as payment brands and acquirers).
5. Submit the SAQ and AOC, along with any other requested documentation
•such as ASV scan reports
•to the requesting organization (those organizations that manage compliance programs such as payment brands and acquirers).
•such as ASV scan reports
•to the requesting organization (those organizations that manage compliance programs such as payment brands and acquirers).
Modified
p. 5
Examine: The merchant critically evaluates data evidence. Common examples include documents (electronic or physical), screenshots, configuration files, audit logs, and data files.
Modified
p. 5
Observe: The merchant watches an action or views something in the environment. Examples of observation subjects include personnel performing a task or process, system components performing a function or responding to input, environmental conditions, and physical controls.
Removed
p. 7
Note: A legal restriction is one where meeting the PCI DSS requirement would violate a local or regional law or regulation.
Removed
p. 8
• Guidance on Scoping
• Guidance on the intent of all PCI DSS Requirements
• Details of testing procedures
• Guidance on Compensating Controls
• Information about all SAQs and their eligibility criteria
• How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)
• Guidance and information about SAQs.
Online PCI DSS Glossary
• PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines
• Guidance on a variety of PCI DSS topics including:
• Guidance on the intent of all PCI DSS Requirements
• Details of testing procedures
• Guidance on Compensating Controls
• Information about all SAQs and their eligibility criteria
• How to determine which SAQ is right for your organization Frequently Asked Questions (FAQs)
• Guidance and information about SAQs.
Online PCI DSS Glossary
• PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines
• Guidance on a variety of PCI DSS topics including:
Modified
p. 8
Online PCI DSS Glossary PCI DSS Terms, Abbreviations, and Acronyms Information Supplements and Guidelines Guidance on a variety of PCI DSS topics including:
Modified
p. 8
− Understanding PCI DSS Scoping and Network Segmentation − Third-Party Security Assurance − Multi-Factor Authentication Guidance − Best Practices for Maintaining PCI DSS Compliance Getting Started with PCI • Resources for smaller merchants including:
− Understanding PCI DSS Scoping and Network Segmentation − Third-Party Security Assurance − Multi-Factor Authentication Guidance − Best Practices for Maintaining PCI DSS Compliance Getting Started with PCI Resources for smaller merchants including:
Modified
p. 8
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org).
− Guide to Safe Payments − Common Payment Systems − Questions to Ask Your Vendors − Glossary of Payment and Information Security Terms − PCI Firewall Basics − ASV Resource Guide These and other resources can be found on the PCI SSC website (www.pcisecuritystandards.org).
Modified
p. 11
Facility Type Total number of locations (How many locations of this type are in scope) Location(s) of facility (city, country) Example: Data centers 3 Boston, MA, USA Part 2e. PCI SSC Validated Products and Solutions Does the merchant use any item identified on any PCI SSC Lists of Validated Products and Solutions? Provide the following information regarding each item the merchant uses from PCI SSC’s Lists of Validated Products and Solutions.
Facility Type Total number of locations (How many locations of this type are in scope) Location(s) of facility (city, country) Example: Data centers 3 Boston, MA, USA Part 2e. PCI SSC Validated Products and Solutions Does the merchant use any item identified on any PCI SSC Lists of Validated Products and Solutions♦? Provide the following information regarding each item the merchant uses from PCI SSC’s Lists of Validated Products and Solutions.
Modified
p. 11
PCI SSC listing reference number Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components appearing on the PCI SSC website (www.pcisecuritystandards.org)⎯for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Payment Applications (PA- DSS), Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS (SPoC) solutions, and Contactless Payments …
PCI SSC listing reference number Expiry date of listing (YYYY-MM-DD) YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD YYYY-MM-DD ♦ For purposes of this document, ”Lists of Validated Products and Solutions” means the lists of validated products, solutions, and/or components, appearing on the PCI SSC website (www.pcisecuritystandards.org)for example, 3DS Software Development Kits, Approved PTS Devices, Validated Payment Software, Point to Point Encryption (P2PE) solutions, Software-Based PIN Entry on COTS (SPoC) solutions, Contactless Payments on COTS (CPoC) solutions, and …
Modified
p. 12
• Manage system components included in the scope of the merchant’s PCI DSS assessment⎯for example, via network security control services, anti-malware services, security incident and event management (SIEM), contact and call centers, web-hosting services, and IaaS, PaaS, SaaS, and FaaS cloud providers.
• Manage system components included in the scope of the merchant’s PCI DSS assessmentfor example, via network security control services, anti-malware services, security incident and event management (SIEM), contact and call centers, web-hosting services, and IaaS, PaaS, SaaS, and FaaS cloud providers.
Modified
p. 14
The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and has confirmed that TPSP(s) are PCI DSS compliant for the services used by the merchant.
The merchant has confirmed that TPSP(s) are PCI DSS compliant for the services used by the merchant.
Removed
p. 15
• Kept up to date.
• In use.
• Interview personnel.
• Examine configuration settings.
• In use.
• Interview personnel.
• Examine configuration settings.
Modified
p. 15
Documented. Kept up to date. In use. Known to all affected parties.
Modified
p. 15
Examine documentation. Interview personnel.
Modified
p. 15
Examine configurations standards. Examine configuration settings.
Modified
p. 16
Shows all account data flows across systems and networks. Updated as needed upon changes to the environment.
Removed
p. 17
• All other traffic is specifically denied.
• All other traffic is specifically denied.
• All other traffic is specifically denied.
Modified
p. 17
To only traffic that is necessary. All other traffic is specifically denied.
Modified
p. 17
To only traffic that is necessary. All other traffic is specifically denied.
Modified
p. 17
All wireless traffic from wireless networks into the CDE is denied by default. Only wireless traffic with an authorized business purpose is allowed into the CDE.
Removed
p. 25
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place Where account data is stored by a TPSP (for example, in a cloud environment), entities are responsible for working with their service providers to understand how the TPSP meets this requirement for the entity. Considerations include ensuring that all geographic instances of a data element are securely deleted. The bullet above (for coverage of SAD stored prior to completion of authorization) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.2.1 and must be fully considered during a PCI DSS assessment.
Modified
p. 27
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public
Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks
Modified
p. 27
PCI DSS Requirement Expected Testing (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented.
PCI DSS Requirement Expected Testing (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and understood.
Removed
p. 28
Applicability Notes There could be occurrences where an entity receives cardholder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data. In this situation, the entity can choose to either include the channel in the scope of their CDE and secure it according to PCI DSS or implement measures to prevent the channel from being used for cardholder data.
Modified
p. 28
A self-signed certificate may also be acceptable if the certificate is issued by an internal CA within the organization, the certificate’s author is confirmed, and the certificate is verified
•for example, via hash or signature
•and has not expired.Note that self-signed certificates where the Distinguished Name (DN) field in the “issued by” and “issued to” field is the same are not acceptable.
•for example, via hash or signature
•and has not expired.
Applicability Notes A self-signed certificate may also be acceptable if the certificate is issued by an internal CA within the organization, the certificate’s author is confirmed, and the certificate is verified
•for example, via hash or signature
•and has not expired.
•for example, via hash or signature
•and has not expired.
Removed
p. 33
Applicability Notes This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as e-mail servers) are brought into scope for PCI DSS.
Modified
p. 33
The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.
Applicability Notes The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.
Modified
p. 34
Note: For SAQ A-EP, Requirement 6 applies to webservers that host the payment page(s) provided from the merchant's website to the customer's browser.
Note: For SAQ A-EP, Requirement 6 applies to merchant server(s) that host the payment page(s) provided from the merchant's website to the customer's browser.
Modified
p. 37
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place This requirement is not achieved by, and is in addition to, performing vulnerability scans according to Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
Modified
p. 37
• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
• Patches/updates for critical vulnerabilities (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
Modified
p. 38
• At least once every 12 months and after significant changes. • By an entity that specializes in application security.
• Including, at a minimum, all common software attacks in Requirement 6.2.4.
• All vulnerabilities are ranked in accordance with Requirement 6.3.1.
• Including, at a minimum, all common software attacks in Requirement 6.2.4.
• All vulnerabilities are ranked in accordance with Requirement 6.3.1.
• At least once every 12 months and after significant changes.
Modified
p. 38
• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows:
Modified
p. 40
Note: For SAQ A-EP, Requirement 6.4.3 applies to the payment page(s) provided from the merchant's website to the customer's browser.
Note: For SAQ A-EP, Requirement 6.4.3 applies to any scripts on the payment page(s) provided from the merchant's website to the customer's browser.
Modified
p. 40
• An inventory of all scripts is maintained with written justification as to why each is necessary.
• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
Removed
p. 42
Applicability Notes (continued) ♦ Refer to the “Requirement Responses” section (page v) for information about these response options.
Modified
p. 43
Applicability Notes This requirement applies to all user accounts and related access privileges, including those used by personnel and third parties/vendors, and accounts used to access third-party cloud services.
Modified
p. 44
Note: For SAQ A-EP, Requirement 8 applies to merchant webservers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
Note: For SAQ A-EP, Requirement 8 applies to merchant servers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
Modified
p. 45
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.2.2 Group, shared, or generic IDs, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
Modified
p. 45
• Account use is prevented unless needed for an exceptional circumstance.
• ID use is prevented unless needed for an exceptional circumstance.
Modified
p. 46
Applicability Notes 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 (such as IDs used by cashiers on point-of-sale terminals).
Applicability Notes 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.
Modified
p. 47
Applicability Notes 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 (such as IDs used by cashiers on point-of-sale terminals).
Applicability Notes 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.
Modified
p. 48
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
• User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
Modified
p. 49
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.
Removed
p. 50
MFA is considered a best practice for non-console administrative access to in-scope system components that are not part of the CDE.
Modified
p. 50
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3.9 (cont.) This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.3.9 (cont.) This requirement does not apply to in-scope system components where MFA is used.
Modified
p. 50
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 (such as IDs used by cashiers on point-of-sale terminals).
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. This requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.
Modified
p. 51
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.2 MFA is implemented for all access into the CDE.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.2 MFA is implemented for all non-console access into the CDE.
Modified
p. 51
MFA is required for both types of access specified in Requirements 8.4.2 and 8.4.3. Therefore, applying MFA to one type of access does not replace the need to apply another instance of MFA to the other type of access. If an individual first connects to the entity’s network via remote access, and then later initiates a connection into the CDE from within the network, per this requirement the individual would authenticate using MFA twice, once when connecting via remote access …
Modified
p. 51
MFA for remote access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
MFA for access into the CDE can be implemented at the network or system/application level; it does not have to be applied at both levels. For example, if MFA is used when a user connects to the CDE network, it does not have to be used when the user logs into each system or application within the CDE.
Removed
p. 52
• All remote access by all personnel, both users and administrators, originating from outside the entity’s network.
• All remote access by third parties and vendors.
• All remote access by third parties and vendors.
Modified
p. 52
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows:
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 8.4.3 MFA is implemented for all remote access originating from outside the entity’s network that could access or impact the CDE.
Modified
p. 52
• Observe personnel (for example, users and administrators) connecting remotely to the network.
• Observe personnel (for example, users and administrators) and third parties connecting remotely to the network.
Modified
p. 52
Applicability Notes The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE.
Applicability Notes The requirement for MFA for remote access originating from outside the entity’s network applies to all user accounts that can access the network remotely, where that remote access leads to or could lead to access into the CDE. This includes all remote access by personnel (users and administrators), and third parties (including, but not limited to, vendors, suppliers, service providers, and customers).
Modified
p. 57
• Examine the periodic media destruction policy.
• Examine the media destruction policy.
Modified
p. 63
Applicability Notes For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
Applicability Notes For the initial PCI DSS assessment against this requirement, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s).
Removed
p. 68
Applicability Notes E-commerce skimming code or techniques cannot be added to payment pages as received by the consumer browser without a timely alert being generated. Anti-skimming measures cannot be removed from payment pages without a prompt alert being generated.
Modified
p. 68
Note: For SAQ A-EP, Requirement 11.6.1 applies to webservers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
Note: For SAQ A-EP, Requirement 11.6.1 applies to merchant web servers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
Modified
p. 68
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
Modified
p. 68
• The mechanism is configured to evaluate the received HTTP header and payment page.
• The mechanism is configured to evaluate the received HTTP headers and payment pages.
Modified
p. 68
• At least once every seven days OR
• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
• At least once weekly OR
• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).
Modified
p. 69 → 70
Note: Requirement 12 specifies that merchants have information security policies for their personnel, but these policies can be as simple or complex as needed for the size and complexity of the merchant’s operations. The policy document must be provided to all personnel so they are aware of their responsibilities for protecting payment terminals, any paper documents with account data, etc. If a merchant has no employees, then it is expected that the merchant understands and acknowledges their responsibility for security …
Note: Requirement 12 specifies that merchants have information security policies for their personnel, but these policies can be as simple or complex as needed for the size and complexity of the merchant’s operations. The policy document must be provided to all personnel so they are aware of their responsibilities for protecting payment terminals, any paper documents with cardholder data and/or sensitive authentication data, etc. If a merchant has no employees, then it is expected that the merchant understands and acknowledges …
Modified
p. 70 → 72
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
• Resulting analysis that determines, and includes justification for, how the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact of the threat being realized.
Modified
p. 71 → 73
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place Applicability Notes This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place 12.6 Security awareness education is an ongoing activity.
Modified
p. 72 → 74
• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
• Written agreements include acknowledgments from TPSPs that TPSPs are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that the TPSP could impact the security of the entity’s cardholder data and/or sensitive authentication data.
Modified
p. 72 → 74
Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Applicability Notes The exact wording of an agreement will depend on the details of the service being provided, and the responsibilities assigned to each party. The agreement does not have to include the exact wording provided in this requirement.
Modified
p. 72 → 74
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (is not the same as a written acknowledgment specified in this requirement. For example, a PCI DSS Attestation of Compliance (AOC), a declaration on a company’s website, a policy statement, a responsibility matrix, or other evidence not included in a written agreement is not a written acknowledgment.
Modified
p. 80 → 82
PCI DSS Self-Assessment Questionnaire A-EP, Version 4.0, was completed according to the instructions therein.
PCI DSS Self-Assessment Questionnaire A-EP, Version 4.0.1, was completed according to the instructions therein.