Document Diff - PCI Watch

Added p. 8

PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of cardholder data and/or sensitive authentication data. Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account datafor example, entities that outsource payment operations or management of their cardholder data environment (CDE) 1. Entities that outsource their payment environments or payment operations to third parties remain responsible for ensuring that the account data is protected by the third party per applicable PCI DSS requirements.

Added p. 18

When Cardholder Data and/or Sensitive Authentication Data is Accidentally Received via an Unintended Channel There could be occurrences where an entity receives cardholder data and/or sensitive authentication 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  Securely delete the data and implement measures to prevent the channel from being used in the future for sending such data.

Added p. 21

Note that not all TPSP relationships require that TPSPs provide customers with documentation of how responsibilities are shared between TPSPs and customers. TPSPs are only required to share such documentation if that TPSP is meeting a PCI DSS requirement(s) on the customer’s behalf, if responsibility for meeting a PCI DSS requirement is shared between the TPSP and its customer, or if the TPSP’s service may impact the security of the customer’s cardholder data and/or sensitive authentication data. While a TPSP may not be required to provide its customers with such documentation because there are no shared responsibilities, the TPSP still needs to support customers by providing their PCI DSS compliance status information, so that customers can manage and monitor their TPSPs in accordance with PCI DSS Requirement 12.8.

Added p. 31

Note: Where an entity is being assessed for the first time against a PCI DSS requirement with a defined timeframe, it is considered an initial PCI DSS assessment for that requirement. This means the entity has never undergone a prior assessment to that requirement, where the assessment resulted in submission of a compliance validation document (for example, an AOC, SAQ, or ROC).

For an initial assessment against a requirement that has a defined timeframe, it is not required that the activity has been performed for every such timeframe during the previous year, if the assessor verifies:

Added p. 39

Questions about the use of previous versions should be directed to those organizations that manage compliance programs (such as payment brands and acquirers).

Added p. 46

Configuration standards outline an entity’s minimum requirements for the configuration of its NSCs.

(continued on next page) 1.2.3 An accurate network diagram(s) is maintained that shows all connections between the CDE and other networks, including any wireless networks.

Added p. 55

Good Practice All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications•for example, by restricting source/destination addresses and ports, and blocking of content.

Good Practice All traffic outbound from the CDE, regardless of the destination, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to restrict traffic to only authorized communications•for example, by restricting source/destination addresses and ports, and blocking of content.

Added p. 68

By developing standards, entities ensure their system components will be configured consistently and securely and will address the protection of devices for which full hardening may be more difficult.

Added p. 83

Good Practice It may be acceptable for an entity to store SAD in non- persistent memory for a short time after authorization is complete, if following conditions are met:

• There is a legitimate business need to access SAD in memory after authorization is complete.

• SAD is only ever stored in non-persistent memory (for example, RAM, volatile memory).

• Controls are in place to ensure that memory maintains a non-persistent state.

• SAD is removed as soon as the business purpose is complete. It is not permissible to store SAD in persistent memory.

Applicability Notes Issuers and companies that support issuing services, where there is a legitimate and documented business need to store SAD, are not required to meet this requirement. A legitimate business need is one that is necessary for the performance of the function being provided by or for the issuer. Refer to Requirement 3.3.3 for additional requirements specifically for these entities.

If …

Added p. 88

Refer to Appendix G for the definition of “authorization.” Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact these organizations for any additional criteria.

Issuers and companies that support issuing services, where there is a legitimate and documented business need to store SAD, are not required to meet this requirement. A legitimate business need is one that is necessary for the performance of the function being provided by or for the issuer.

Refer to Requirement 3.3.3 for requirements specifically for these entities.

Added p. 90

A legitimate issuing business need is one that is necessary for the performance of the function being provided by or for the issuer.

The masking approach should always display only the number of digits needed to perform a specific business function. For example, if only the last four digits are needed to perform a business function, PAN should be masked to only show the last four digits. As another example, if a function needs to view the bank identification number (BIN) for routing purposes, unmask only the BIN digits for that function.

Added p. 92

Refer to Appendix G for definitions of “masking” and “truncation.” Further Information For more information about masking and truncation, see PCI SSC’s FAQs on these topics.

Applicability Notes This requirement does not supersede stricter requirements in place for displays of cardholder data• for example, legal or payment brand requirements for point-of-sale (POS) receipts.

Definitions A virtual desktop is an example of a remote-access technology. Such remote access technologies often include tools to disable copy and/or relocation functionality.

Good Practice It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed versions of a PAN. Controls that prevent the correlation of this data will help ensure that the original PAN remains unreadable. Implementing keyed cryptographic hashes with associated key management processes and procedures in accordance with Requirement 3.5.1.1 is a valid additional control to prevent correlation.

Definitions Refer to Appendix G …

Added p. 96

• The system components only have access to one hash value at a time (hash values are not stored on the system)

• There is no other account data stored on the same system as the hashes.

This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. This requirement will replace the bullet in Requirement 3.5.1 for one-way hashes once its effective date is reached.

Customized Approach Objective Encrypted PAN is only decrypted when there is a legitimate business need to access that PAN.

Added p. 98

While disk or partition encryption may still be present on these types of devices, it cannot be the only mechanism used to protect PAN stored on those systems. Any stored PAN must also be rendered unreadable per Requirement 3.5.1•for example, through truncation or a data-level encryption mechanism. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is appropriate only for removable electronic media storage devices.

Disk or partition encryption implementations must also meet all other PCI DSS encryption and key-management requirements.

For issuers and companies that support issuing services: This requirement does not apply to PANs being accessed for real-time transaction processing. However, it does apply to PANs stored for other purposes.

Added p. 106

Further Information See the sources referenced at Cryptographic Key Generation in Appendix G.

Added p. 110

(continued on next page) 3.7.6 Where manual cleartext cryptographic key- management operations are performed by personnel, key-management policies and procedures are implemented, including managing these operations using split knowledge and dual control.

Applicability Notes This control is applicable for manual key- management operations.

Added p. 118

(continued on next page) 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.

The bullet above (for confirming that certificates used to safeguard PAN during transmission over open, public networks are valid and are not expired or revoked) is a best practice until 31 March 2025, after which it will be required as part of Requirement 4.2.1 and must be fully considered during a PCI DSS assessment.

Added p. 122

Good Practice The use of end-user messaging technology to send PAN should only be considered where there is a defined business need and should be controlled through the Acceptable Use Policies for end-user technologies defined by the entity according to Requirement 12.2.1.

Applicability Notes This requirement also applies if a customer, or other third party, requests that PAN is sent to them via end-user messaging technologies.

Added p. 126

Good Practice It is beneficial for entities to be aware of "zero-day" attacks (those that exploit a previously unknown vulnerability) and consider solutions that focus on behavioral characteristics and will alert and react to unexpected behavior.

Good Practice Anti-malware solutions may include a combination of network-based controls, host-based controls, and endpoint security solutions. In addition to signature- based tools, capabilities used by modern anti- malware solutions include sandboxing, privilege escalation controls, and machine learning.

Added p. 130

• prior to being deployed to individual system components.

Added p. 136

Applicability Notes The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS.

Added p. 148

(continued on next page) 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.

For bespoke and custom software, the organization may obtain information about libraries, frameworks, compilers, programming languages, etc. from public trusted sources (for example, special resources and resources from component developers). The organization may also independently analyze third- party components and identify vulnerabilities.

Added p. 151

Good Practice An entity’s inventory should cover all payment software components and dependencies, including supported execution platforms or environments, third- party libraries, services, and other required functionalities.

An entity’s patching cadence should factor in any re- evaluation of vulnerabilities and subsequent changes in the criticality of a vulnerability per Requirement 6.3.1. For example, a vulnerability initially identified as low risk could become a higher risk later. Additionally, vulnerabilities individually considered to be low or medium risk could collectively pose a high or critical risk if present on the same system, or if exploited on a low-risk system that could result in access to the CDE.

Added p. 156

A web application firewall (WAF), which can be either on-premise or cloud-based, installed in front of public-facing web applications to check all traffic, is an example of an automated technical solution that detects and prevents web-based attacks (for example, the attacks included in Requirement 6.2.4). WAFs filter and block non-essential traffic at the application layer. A properly configured WAF helps to prevent application-layer attacks on applications that are improperly coded or configured.

Ensuring that scripts have been explicitly authorized reduces the probability of unnecessary scripts being added to the payment page without appropriate management approval. Where it is impractical for such authorization to occur before a script is changed or a new script is added to the page, the authorization should be confirmed as soon as possible after a change is made.

Where an entity includes a TPSP’s/payment processor’s embedded payment page/form on its webpage, the entity should expect the TPSP/payment processor …

Added p. 161

Definitions Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from pre-production functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems.

Definitions Live PANs refer to valid PANs (not test PANs) issued by, or on behalf of, a payment brand. Additionally, when payment cards expire, the same PAN is often reused with a different expiry date. All PANs must be verified as being unable to conduct payment transactions or pose fraud risk to the payment system before they are excluded from PCI DSS scope. It is the responsibility of the entity to confirm that PANs are not live.

Added p. 170

Good Practice Access rights are granted to a user by assignment to one or several functions. Access is assigned depending on the specific user functions and with the minimum scope required for the job.

Added p. 183

If multiple users share the same authentication credentials (for example, user ID and password), it becomes impossible to trace system access and activities to an individual. In turn, this prevents an entity from assigning accountability for, or having effective logging of, an individual’s actions since a given action could have been performed by anyone in the group with knowledge of the user ID and associated authentication factors.

The ability to associate individuals to the actions performed with an ID is essential to provide individual accountability and traceability regarding who performed an action, what action was performed, and when that action occurred.

Good Practice If shared IDs are used for any reason, strong management controls need to be established to maintain individual accountability and traceability.

(continued on next page) 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:

An …

Added p. 186

Attackers often compromise an existing account and then escalate the privileges of that account to perform unauthorized acts, or they may create new IDs to continue their activity in the background. It is essential to detect and respond when user IDs are created or changed outside the normal change process or without corresponding authorization.

Added p. 197

Applicability Notes This requirement does not apply to in-scope system components where MFA is used.

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 p. 202

Good Practice Implementing MFA for non-console administrative access to in-scope system components that are not part of the CDE will help prevent unauthorized users from using a single factor to gain access and compromise in-scope system components.

Added p. 204

Refer to Appendix G for the definition of “phishing resistant authentication.” This requirement does not 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.

• User accounts that are only authenticated with phishing-resistant authentication factors.

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 to the entity’s network and once when connecting from the entity’s network into the CDE.

Added p. 205

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.

Added p. 208

A replay attack is when an attacker intercepts a valid transmission of data and then resends or redirects this communication for malicious purposes. In MFA implementations, replay attacks are typically used to gain unauthorized access by leveraging legitimate credentials.

Examples of methods to help protect against replay attacks include, but are not limited to:

• Unique session identifiers and session keys

• Time-based, one-time passwords or passcodes

• Anti-replay mechanisms that detect and reject duplicated authentication attempts.

Added p. 210

Definitions Interactive login is the ability for a person to log into a system or application account in the same manner as a normal user account. Using system and application accounts this way means there is no accountability and traceability of actions taken by the user.

Added p. 217

Applicability Notes This requirement does not apply to locations that are publicly accessible by consumers (cardholders).

Added p. 221

Definitions Refer to Appendix G for the definition of “personnel.” One way to identify personnel is to assign them badges.

Added p. 225

Defined Approach Requirements Defined Approach Testing Procedures Purpose If stored in a non-secured facility, backups containing cardholder data may easily be lost, stolen, or copied for malicious intent.

Added p. 231

9.4.7.a Examine the media destruction policy to verify that procedures are defined to destroy electronic media when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

Added p. 233

• Components used only for manual PAN key entry.

• Components used only for manual PAN key entry.

• Commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.

• Commercial off-the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.

These requirements do not apply to:

Added p. 235

(continued on next page) 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution.

Added p. 244

Definitions The functions or activities considered to be administrative are beyond those performed by regular users as part of routine business functions.

Added p. 252

Good Practice Establishing a baseline of normal audit activity patterns is critical to the effectiveness of an automated log review mechanism. The analysis of new audit activity against the established baseline can significantly improve the identification of suspicious or anomalous activities.

Further Information Refer to the Information Supplement: Effective Daily Log Monitoring for additional guidance.

Added p. 267

Even if a company has a policy prohibiting the use of wireless technologies, an unauthorized wireless device or network could be installed without the company’s knowledge, allowing an attacker to enter the network easily and “invisibly.” Detecting and removing such unauthorized access points reduces the duration and likelihood of such devices being leveraged for an attack.

Added p. 268

The requirement applies even when a policy exists that prohibits the use of wireless technology.

Added p. 270

Good Practice Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority. Vulnerabilities identified during internal vulnerability scans should be part of a vulnerability management process that includes multiple vulnerability sources, as specified in Requirement 6.3.1.

Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all applicable vulnerabilities were resolved as part of the three-month vulnerability scan cycle. However, additional documentation may be required to verify non- remediated vulnerabilities are in the process of being resolved.

Added p. 275

Vulnerabilities identified during external vulnerability scans should be part of a vulnerability management process that includes multiple vulnerability sources, as specified in Requirement 6.3.1.

Further Information See the ASV Program Guide on the PCI SSC website.

Added p. 280

A penetration test is not truly a “test” because the outcome of a penetration test is not something that can be classified as a “pass” or a “fail.” The best outcome of a test is a catalog of vulnerabilities and misconfigurations that an entity 11.4.2 Internal penetration testing is performed:

Added p. 281

• Prior experience conducting penetration testing

•for example, the number of years of experience, and the type and scope of prior engagements can help confirm whether the tester’s experience is appropriate for the needs of the engagement.

Added p. 292

By comparing the current version of the HTTP header and the active content of payment pages as received by the consumer browser with prior or known versions, it is possible to detect unauthorized changes that may indicate a skimming attack, or an attempt to disable a control designed to protect against, or to detect, skimming attacks.

Added p. 293

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.

Mechanisms that detect and report on changes to the headers and content of the payment page could include, but are not limited to, a combination of the following techniques:

The above list of mechanisms is not exhaustive, and the use of any one mechanism is not necessarily a full detection and reporting mechanism.

Often, these mechanisms are subscription or cloud- based, but can also be based on custom and bespoke solutions.

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. 298

Good Practice These executive management positions are often at the most senior level of management and are part of the chief executive level or C-level, typically reporting to the Chief Executive Officer or the Board of Directors. Information security knowledge for this executive management role can be indicated by work experience, education, and/or relevant professional certifications. The expectation is that this individual can provide assurance about the implementation of an effective security program and ensure the right technical experts are employed.

Defined Approach Requirements Defined Approach Testing Procedures Purpose Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to the entity’s environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.

(continued on next page) 12.3.1 For each PCI DSS requirement that specifies completion of a targeted risk analysis, the analysis is documented and includes:

Further …

Added p. 310

A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE• for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.

Added p. 315

Entities should consider requiring security awareness training anytime personnel transfer into roles where they can impact the security of cardholder data and/or sensitive authentication data from roles where they did not have this impact.

Added p. 321

Further Information Refer to the Information Supplement: Third-Party Security Assurance for further guidance.

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.

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.

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 …

Added p. 327

The TPSP’s internal policies and procedures related to their customer engagement process and any templates used for written agreements should include provision of an applicable PCI DSS acknowledgement to its customers. The method by which the TPSP provides written acknowledgment should be agreed between the provider and its customers.

Added p. 328

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.

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.

Evidence that a TPSP is meeting PCI DSS requirements is not the same as a written agreement 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.

Added p. 331

Entities should consider how to address all compromises of data within the CDE in their incident response plans, including compromises to account data, wireless encryption keys, encryption keys used for transmission and storage or account data or cardholder data, etc.

Added p. 332

Good Practice The test of the incident response plan can include simulated incidents and the corresponding responses in the form of a “table-top exercise” that includes participation by relevant personnel. A review of the incident and the quality of the response can provide entities with the assurance that all required elements are included in the plan.

Added p. 336

It is important to not just consider elements of the response that did not have the planned outcomes but also to understand what worked well and whether lessons from those elements that worked well can be applied to areas of the plan that did not.

Added p. 339

Multi-tenant service providers are a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web- based hosting services, payment applications, various cloud applications and services, and payment gateway and processor services offered in a shared environment.

Added p. 351

Note: Some PCI DSS requirements in this Appendix have defined timeframes (for example, an activity that is to be performed at least once every three months or six months). For an initial assessment to such requirements, it is not required that an activity has been performed for every such timeframe during the previous year, if the assessor verifies:

Refer to section 7 Descriptions of Timeframes Used in PCI DSS Requirements for additional guidance about initial assessments.

Added p. 357

A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE• for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.

Added p. 373

b) Existing PCI DSS requirements MAY be considered as compensating controls if they are required for another area but are not required for the item under review.

Added p. 378

These sample templates are available on the PCI SSC website.

Added p. 390

See the following PCI DSS v4.x documents for information on reporting legal exceptions:

• The Report on Compliance (ROC) Template and related Attestations of Compliance.

• The Self-Assessment Questionnaires (SAQs) and related Attestations of Compliance.

Note: Where an entity operates in multiple locations, a legal exception may only be claimed for the locations governed by the law, regulation, or regulatory requirement, and may not be claimed for locations in which such law, regulation, or regulatory requirement is inapplicable.

Added p. 393

Phishing Resistant Authentication Authentication designed to prevent the disclosure and use of authentication secrets to any party that is not the legitimate system to which the user is attempting to authenticate (for example, through in-the-middle (ITM) or impersonation attacks). Phishing-resistant systems often implement asymmetric cryptography as a core security control.

Systems that rely solely on knowledge-based or time-limited factors such as passwords or one-time-passwords (OTPs) are not considered phishing resistant, nor are SMS or magic links. Examples of phishing-resistant authentication includes FIDO2.

Added p. 397

Visitor A vendor, guest of any personnel, service worker, or personnel that normally do not have access to the subject area.

Cardholders present in a retail location to purchase goods or services are not considered “visitors.” See Cardholder and Personnel.

Modified p. 5

PCI Data Security Standard

• High Level Overview Build and Maintain a Secure Network and Systems 1. Install and Maintain Network Security Controls. ~~2. Apply Secure Configurations to All System Components.~~

PCI Data Security Standard

• High Level Overview Build and Maintain a Secure Network and Systems 1. Install and Maintain Network Security Controls.

Modified p. 5

~~Protect Account Data 3. Protect Stored Account Data.~~ 4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.

4. Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks.

Modified p. 5

Maintain a Vulnerability Management Program 5. Protect All Systems and Networks from Malicious Software. ~~6. Develop and Maintain Secure Systems and Software.~~

Maintain a Vulnerability Management Program 5. Protect All Systems and Networks from Malicious Software.

Modified p. 5

Implement Strong Access Control Measures 7. Restrict Access to System Components and Cardholder Data by Business Need to Know. ~~8. Identify Users and Authenticate Access to System Components. 9. Restrict Physical Access to Cardholder Data.~~

Implement Strong Access Control Measures 7. Restrict Access to System Components and Cardholder Data by Business Need to Know.

Modified p. 5

Regularly Monitor and Test Networks 10. Log and Monitor All Access to System Components and Cardholder Data. ~~11. Test Security of Systems and Networks Regularly.~~

Regularly Monitor and Test Networks 10. Log and Monitor All Access to System Components and Cardholder Data.

Removed p. 8

PCI DSS requirements apply to entities with environments where account data (cardholder data and/or sensitive authentication data) is stored, processed, or transmitted, and entities with environments that can impact the security of the CDE. Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account data

• for example, entities that outsource payment operations or management of their CDE 1. Entities that outsource their payment environments or payment operations to third parties remain responsible for ensuring that the account data is protected by the third party per applicable PCI DSS requirements.

Modified p. 8

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).~~ This includes all entities involved in payment ~~card~~ account processing ~~• including~~ merchants, processors, acquirers, issuers, and other service providers.

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 and/or sensitive authentication data. This includes all entities involved in payment account processing •including merchants, processors, acquirers, issuers, and other service providers.

Modified p. 8

Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and ~~acquirers). Contact the~~ organizations ~~of interest~~ for any additional criteria.

Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers); contact these organizations for any additional criteria.

Modified p. 9

 If the entity can impact the security of ~~a CDE~~ because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page) some requirements will be applicable.

 If the entity can impact the security of cardholder data and/or sensitive authentication data because the security of an entity’s infrastructure can affect how cardholder data is processed (for example, via a web server that controls the generation of a payment form or page) some requirements will be applicable.

Modified p. 10

Table 3. Account Data Element Storage Requirements Data Elements Storage Restrictions Required to Render Stored Data Unreadable Account Data Cardholder Primary Account Number (PAN) Storage is kept to a minimum as defined in

Table 3. Account Data Element Storage Requirements Data Elements Storage Restrictions Required to Render Stored Data Unreadable Account Data Cardholder Primary Account Number (PAN) Storage is kept to a minimum as defined in Requirement 3.2 Yes, as defined in Requirement 3.5 Cardholder Name Storage is kept to a minimum as defined in Requirement 3.2 2 No Service Code Expiration Date Sensitive Authentication Full Track Data Cannot be stored after authorization as defined in Requirement 3.3.1 3 Yes, data stored until …

Modified p. 11

PCI SSC supports the use of secure payment software within cardholder data environments (CDE) via ~~the Payment Application Data Security Standard (PA-DSS) and~~ the Software Security Framework (SSF), which consists of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. Software that is PCI SSC validated and listed provides assurance that the software has been developed using secure practices and has met a defined set of software security requirements.

PCI SSC supports the use of secure payment software within cardholder data environments (CDE) via the Software Security Framework (SSF), which consists of the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard. Software that is PCI SSC validated and listed provides assurance that the software has been developed using secure practices and has met a defined set of software security requirements.

Modified p. 11

 ~~Validated~~ Software Vendors: The Secure SLC Standard defines security requirements for software vendors to integrate secure software development practices throughout the entire software lifecycle. Software vendors that have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.

 Qualified Software Vendors: The Secure SLC Standard defines security requirements for software vendors to integrate secure software development practices throughout the entire software lifecycle. Software vendors that have been validated as meeting the Secure SLC Standard are listed on the PCI SSC website as a Secure SLC Qualified Vendor.

Modified p. 11

All software that stores, processes, or transmits account data, or that could impact the security of ~~account~~ data ~~or a CDE,~~ is in scope for an entity’s PCI DSS assessment. While the use of validated payment software supports the security of an entity’s CDE, the use of such software does not by itself make an entity PCI DSS compliant. The entity’s PCI DSS assessment should include verification that the software is properly configured and securely implemented to support applicable PCI …

All software that stores, processes, or transmits account data, or that could impact the security of cardholder data and/or sensitive authentication data, is in scope for an entity’s PCI DSS assessment. While the use of validated payment software supports the security of an entity’s CDE, the use of such software does not by itself make an entity PCI DSS compliant. The entity’s PCI DSS assessment should include verification that the software is properly configured and securely implemented to support applicable …

Modified p. 11

Note: PA-DSS and the related program ~~will be~~ retired in October 2022. Refer to the PCI SSC List of Validated Payment Applications for expiry dates for PA-DSS validated applications. ~~After~~ the expiry date, applications are listed as “Acceptable only for Pre-Existing Deployments.” Whether an entity can continue to use a PA-DSS application with an expired listing is at the discretion of organizations that manage compliance programs (such as payment brands and acquirers); entities should contact ~~the~~ organizations ~~of interest~~ for …

Note: PA-DSS and the related program were retired in October 2022. Refer to the PCI SSC List of Validated Payment Applications for expiry dates for PA-DSS validated applications. Since the expiry date, applications are listed as “Acceptable only for Pre-Existing Deployments.” Whether an entity can continue to use a PA-DSS application with an expired listing is at the discretion of organizations that manage compliance programs (such as payment brands and acquirers); entities should contact these organizations for more details.

Modified p. 12

Bespoke and Custom Software All bespoke and custom software that stores, processes, or transmits account data, or that could impact the security of ~~account~~ data ~~or a CDE,~~ is in scope for an entity’s PCI DSS assessment.

Bespoke and Custom Software All bespoke and custom software that stores, processes, or transmits account data, or that could impact the security of cardholder data and/or sensitive authentication data, is in scope for an entity’s PCI DSS assessment.

Modified p. 12

Note: PCI DSS Requirement 6 fully applies to bespoke and custom software that has not been developed and maintained in accordance with one of PCI SSC’s Software Security Framework standards. Entities that use software vendors to develop bespoke or custom software that could impact the security of ~~account~~ data ~~or their CDE~~ are responsible for ensuring those software vendors develop the software according to PCI DSS Requirement 6.

Note: PCI DSS Requirement 6 fully applies to bespoke and custom software that has not been developed and maintained in accordance with one of PCI SSC’s Software Security Framework standards. Entities that use software vendors to develop bespoke or custom software that could impact the security of their cardholder data and/or sensitive authentication data are responsible for ensuring those software vendors develop the software according to PCI DSS Requirement 6.

Modified p. 13

• System components, people, and processes that store, process, ~~and~~ transmit cardholder data and/or sensitive authentication data, and,

• System components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data, and,

Modified p. 13

 System components, people, and processes that could impact the security of ~~the CDE.~~ 4 “System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include but are not limited to:

 System components, people, and processes that could impact the security of cardholder data and/or sensitive authentication data. 4 “System components” include network devices, servers, computing devices, virtual components, cloud components, and software. Examples of system components include but are not limited to:

Modified p. 16

 Scope of the PCI DSS assessment  Cost of the PCI DSS assessment  Cost and difficulty of implementing and maintaining PCI DSS controls  Risk to an organization relative to payment ~~card~~ account data (reduced by consolidating that data into fewer, more controlled locations) Without adequate segmentation (sometimes called a "flat network"), the entire network is in scope for the PCI DSS assessment. Segmentation can be achieved using a number of physical or logical methods, such as properly …

 Scope of the PCI DSS assessment  Cost of the PCI DSS assessment  Cost and difficulty of implementing and maintaining PCI DSS controls  Risk to an organization relative to payment account data (reduced by consolidating that data into fewer, more controlled locations) Without adequate segmentation (sometimes called a "flat network"), the entire network is in scope for the PCI DSS assessment. Segmentation can be achieved using a number of physical or logical methods, such as properly configured …

Modified p. 20

Note: Use of a PCI DSS compliant TPSP does not make a customer PCI DSS compliant, nor does it remove the customer’s responsibility for its own PCI DSS compliance. Even if a customer uses a ~~TPSP to meet all account data functions,~~ that customer remains responsible for confirming its own compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). Customers should contact ~~the~~ organizations ~~of interest~~ for any requirements.

Note: Use of a PCI DSS compliant TPSP does not make a customer PCI DSS compliant, nor does it remove the customer’s responsibility for its own PCI DSS compliance. Even if a customer uses a TPSP, that customer remains responsible for confirming its own compliance as requested by organizations that manage compliance programs (for example, payment brands and acquirers). Customers should contact these organizations for any requirements.

Modified p. 20

Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8 There are many different scenarios where a customer might use one or more TPSPs for functions within or related to the customer’s CDE. In all scenarios where a TPSP is used, the customer must manage and oversee the PCI DSS compliance status of ~~all~~ their TPSPs in accordance with Requirement 12.8, including TPSPs that:

Using TPSPs and the Impact on Customers Meeting PCI DSS Requirement 12.8 There are many different scenarios where a customer might use one or more TPSPs for functions within or related to the customer’s CDE. In all scenarios where a TPSP is used, the customer must manage and oversee all their TPSP relationships and monitor the PCI DSS compliance status of their TPSPs in accordance with Requirement 12.8, including TPSPs that:

Modified p. 20

 Have access to the customer’s CDE,  Manage in-scope system components on the customer’s behalf, and/or  Can impact the security of the customer’s ~~CDE.~~

 Have access to the customer’s CDE,  Manage in-scope system components on the customer’s behalf, and/or  Can impact the security of the customer’s cardholder data and/or sensitive authentication data.

Modified p. 20

Managing ~~TPSPs~~ in accordance with Requirement 12.8 includes performing due diligence, having appropriate agreements in place, identifying which requirements apply to the customer and which apply to the TPSP, and monitoring the compliance status of TPSPs at least annually.

Managing TPSP relationships in accordance with Requirement 12.8 includes performing due diligence, having appropriate agreements in place, identifying which requirements apply to the customer and which apply to the TPSP, and monitoring the compliance status of TPSPs at least annually.

Modified p. 20

Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer ~~monitor~~ their compliance status as specified in the requirement. Therefore, a TPSP does not need to be PCI DSS compliant for its customer to meet Requirement 12.8.

Requirement 12.8 does not specify that the customer’s TPSPs must be PCI DSS compliant, only that the customer monitors their compliance status as specified in the requirement. Therefore, a TPSP does not need to be PCI DSS compliant for its customer to meet Requirement 12.8.

Modified p. 21

Importance of Understanding Responsibilities Between TPSP Customers and TPSPs ~~Customers~~ and TPSPs ~~should~~ clearly identify and understand the following:

Importance of Understanding Responsibilities Between TPSP Customers and TPSPs When a TPSP provides a service that meets a PCI DSS requirement(s) on the customer’s behalf or where that service may impact the security of the customer’s cardholder data and/or sensitive authentication data, it is important that customers and TPSPs clearly identify and understand the following:

Modified p. 21 → 22

When a TPSP provides services that are intended to meet or facilitate meeting a customer’s PCI DSS requirements or that may impact the security of a customer’s ~~CDE,~~ these requirements are in scope for the customer’s PCI DSS assessments. There are two options for TPSPs to validate compliance in this scenario:

When a TPSP provides services that are intended to meet or facilitate meeting a customer’s PCI DSS requirements or that may impact the security of a customer’s cardholder data and/or sensitive authentication data, these requirements are in scope for the customer’s PCI DSS assessments. There are two options for TPSPs to validate compliance in this scenario:

Modified p. 22

If the TPSP does not undergo its own PCI DSS assessment and therefore does not have an AOC, the TPSP is expected to provide specific evidence related to the applicable PCI DSS requirements, so that the customer (or its assessor) is able to confirm the TPSP is meeting those PCI DSS requirements.

If the TPSP does not undergo its own PCI DSS assessment and therefore does not have an AOC, the TPSP is expected to provide specific evidence related to the applicable PCI DSS requirements, so that the customer (or its assessor) is able to confirm that the TPSP is meeting those PCI DSS requirements.

Modified p. 22

~~TPSPs~~ Presence on a Payment Brand List(s) of PCI DSS Compliant Service Providers For a customer that is monitoring a TPSP’s compliance status in accordance with Requirement 12.8, the TPSP’s presence on a payment brand’s list of PCI DSS compliant service providers may be sufficient evidence of the TPSP’s compliance status if it is clear from the list that the services applicable to the customer were covered by the TPSP’s PCI DSS assessment. If it is not clear from the …

TPSP’s Presence on a Payment Brand List(s) of PCI DSS Compliant Service Providers For a customer that is monitoring a TPSP’s compliance status in accordance with Requirement 12.8, the TPSP’s presence on a payment brand’s list of PCI DSS compliant service providers may be sufficient evidence of the TPSP’s compliance status if it is clear from the list that the services applicable to the customer were covered by the TPSP’s PCI DSS assessment. If it is not clear from the …

Modified p. 22

For a customer that is looking for evidence of PCI DSS compliance for requirements that a TPSP meets on a customer’s behalf or where the service provided can impact the security of the customer’s ~~CDE,~~ the TPSP’s presence on a payment brand’s list of PCI DSS compliant service providers is not sufficient evidence that the applicable PCI DSS requirements for that TPSP were included in the assessment. If the TPSP has an PCI DSS AOC, it is expected to provide …

For a customer that is looking for evidence of PCI DSS compliance for requirements that a TPSP meets on a customer’s behalf or where the service provided can impact the security of the customer’s cardholder data and/or sensitive authentication data, the TPSP’s presence on a payment brand’s list of PCI DSS compliant service providers is not sufficient evidence that the applicable PCI DSS requirements for that TPSP were included in the assessment. If the TPSP has an PCI DSS AOC, …

Modified p. 23

Examples of how PCI DSS should be incorporated into BAU activities ~~include~~ but are not limited to:

Examples of how PCI DSS should be incorporated into BAU activities include, but are not limited to:

Modified p. 26

Appropriate selection of the sample depends on what is being considered in examining the sample members. For example, determining the presence of anti-malware on servers known to be affected by malicious software may lead to determining the population to be all servers in the environment, or all servers in the environment that are running a particular operating system, or all servers that are not mainframes, etc. Selection of an appropriate sample would then include representatives of ALL members of the …

Modified p. 30

• Any replacement or major upgrades of hardware ~~and~~ software in the CDE.

• Any replacement or major upgrades of hardware and/or software in the CDE.

Modified p. 30

• Any changes to ~~third party~~ vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

• Any changes to third-party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

Removed p. 31

Note: For an initial PCI DSS assessment (meaning an entity has never undergone a prior assessment), where a requirement has a defined timeframe within which an activity is to occur, it is not required that the activity has been performed for every such timeframe during the previous year, if the assessor verifies:

• The entity has documented policies and procedures for continuing to perform the activity within the defined timeframe.

Modified p. 31

• The activity was performed in accordance with the applicable requirement within the most recent timeframe (for example, the most recent three-month or six-month period), and

 The activity was performed in accordance with the applicable requirement within the most recent timeframe (for example, the most recent three-month or six-month period), and  The entity has documented policies and procedures for continuing to perform the activity within the defined timeframe.

Modified p. 31

For subsequent years after the initial assessment, the activity must have been performed at least once within each required timeframe. For example, an activity required every three months must have been performed at least four times during the previous year at an interval that does not exceed 90-92 days.

For subsequent years after the initial assessment, the activity must have been performed at least once within each required timeframe. For example, an activity required at least every three months must have been performed at least four times during the previous year at an interval that does not exceed 90-92 days.

Modified p. 32

Compensating Controls As part of the defined approach, entities that cannot meet a PCI DSS requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other, or compensating, controls, that sufficiently mitigate the risk associated with the requirement. On an annual basis, any compensating controls must be documented by the entity and reviewed and validated by the assessor and included with the Report on Compliance submission.

Compensating Controls As part of the defined approach, entities that cannot meet a PCI DSS requirement explicitly as stated due to a legitimate and documented technical or business constraint may implement other, or compensating, controls, that sufficiently mitigate the risk associated with not meeting the requirement. On an annual basis, any compensating controls must be documented by the entity and reviewed and validated by the assessor and included with the Report on Compliance submission.

Modified p. 32

Customized ~~Approach~~ Focuses on the Objective of each PCI DSS requirement (if applicable), allowing entities to implement controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. Because each customized implementation will be different, there are no defined testing procedures; the assessor is required to derive testing procedures that are appropriate to the specific implementation to validate that the implemented controls meet the stated Objective.

Customized Focuses on the Objective of each PCI DSS requirement (if applicable), allowing entities to implement controls to meet the requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. Because each customized implementation will be different, there are no defined testing procedures; the assessor is required to derive testing procedures that are appropriate to the specific implementation to validate that the implemented controls meet the stated Objective.

Modified p. 32

The customized approach supports innovation in security practices, allowing entities greater flexibility to show how their current security controls meet PCI DSS objectives. This approach is intended for risk-mature entities that demonstrate a robust risk-management approach to security, including, but not limited to, a dedicated ~~risk- management~~ department or an organization-wide risk management approach.

The customized approach supports innovation in security practices, allowing entities greater flexibility to show how their current security controls meet PCI DSS objectives. This approach is intended for risk-mature entities that demonstrate a robust risk-management approach to security, including, but not limited to, a dedicated risk-management department or an organization-wide risk management approach.

Modified p. 32

Note: For more details, see Appendix D: Customized Approach and ~~Appendix E:~~ Sample Templates to Support Customized ~~Approach.~~

Note: For more details, see Appendix D: Customized Approach and PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website.

Modified p. 33

Figure 4 shows the two validation options for PCI DSS ~~v4.0.~~

Figure 4 shows the two validation options for PCI DSS v4.x.

Modified p. 35 → 34

 Information needed for customers to monitor the TPSPs’ PCI DSS compliance status (to enable the customer to comply with Requirement 12.8), and  Evidence that the TPSP is meeting applicable PCI DSS requirements where the TPSP’s services are intended to meet or facilitate meeting a customer’s PCI DSS requirements, or where those services may impact the security of a customer’s ~~CDE.~~

 Information needed for customers to monitor the TPSPs’ PCI DSS compliance status (to enable the customer to comply with Requirement 12.8), and  Evidence that the TPSP is meeting applicable PCI DSS requirements where the TPSP’s services are intended to meet or facilitate meeting a customer’s PCI DSS requirements, or where those services may impact the security of a customer’s cardholder data and/or sensitive authentication data.

Modified p. 37 → 36

Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers). Entities should contact ~~the~~ organizations ~~of interest~~ to determine any reporting requirements and instructions.

Whether any entity is required to comply with or validate their compliance to PCI DSS is at the discretion of those organizations that manage compliance programs (such as payment brands and acquirers). Entities should contact these organizations to determine any reporting requirements and instructions.

Modified p. 38 → 37

5. Submit the applicable PCI SSC documentation and the Attestation of Compliance, along with any other requested documentation

•such as ASV scan reports

•to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers)).

• such as ASV scan reports

•to the requesting organization (those that manage compliance programs such as payment brands and acquirers (for merchants), or other requesters (for service providers)).

Modified p. 38 → 37

• For instructions about completing reports on compliance (ROC), refer to the PCI DSS Report on Compliance (ROC) Template.

 For instructions about completing reports on compliance (ROC), refer to the PCI DSS Report on Compliance (ROC) Template.

Modified p. 38 → 37

• For instructions about completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines.

 For instructions about completing self-assessment questionnaires (SAQ), refer to the PCI DSS SAQ Instructions and Guidelines.

Modified p. 38 → 37

• For instructions about submitting PCI DSS compliance validation reports, refer to the PCI DSS Attestation of Compliance.

 For instructions about submitting PCI DSS compliance validation reports, refer to the PCI DSS Attestation of Compliance.

Modified p. 41 → 40

Figure 5. Understanding the Parts of the Requirements Applicability Notes apply to both the Defined and Customized Approach. ~~Includes~~ information that affects how the requirement is interpreted in the context of the entity or in scoping. These notes are an integral part of PCI DSS and must be fully considered during an assessment.

Figure 5. Understanding the Parts of the Requirements Applicability Notes apply to both the Defined and Customized Approach. It includes information that affects how the requirement is interpreted in the context of the entity or in scoping. These notes are an integral part of PCI DSS and must be fully considered during an assessment.

Modified p. 41 → 40

For each new PCI DSS ~~v4.0~~ requirement with an extended implementation period.

For each new PCI DSS v4.x requirement with an extended implementation period.

Modified p. 43 → 42

Requirement 1: Install and Maintain Network Security Controls 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood. 1.2 Network security controls (NSCs) are configured and maintained. 1.3 Network access to and from the cardholder data environment is restricted. 1.4 Network connections between trusted and untrusted networks are controlled. 1.5 Risks to the CDE from computing devices that are able to connect to both untrusted networks and the CDE are mitigated.

Requirement 1: Install and Maintain Network Security Controls 1.1 Processes and mechanisms for installing and maintaining network security controls are defined and understood.

Modified p. 47 → 46

Defined Approach Requirements Defined Approach Testing Procedures Purpose The implementation of these configuration standards results in the NSC being configured and managed to properly perform their security function (often referred to as the ruleset). Good Practice These standards often define the requirements for acceptable protocols, ports that are permitted to be used, and specific configuration requirements that are acceptable. Configuration standards may also outline what the entity considers not acceptable or not permitted within its network. Definitions NSCs are key …

Defined Approach Requirements Defined Approach Testing Procedures Purpose The implementation of these configuration standards results in the NSC being configured and managed to properly perform their security function (often referred to as the ruleset).

Removed p. 49

1.2.3.b Examine documentation and interview responsible personnel to verify that the network diagram(s) is accurate and updated when there are changes to the environment. Customized Approach Objective A representation of the boundaries between the CDE, all trusted networks, and all untrusted networks, is maintained and available.

Modified p. 49

~~• A legend or key to explain the diagram.~~ Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network.

Diagrams should be updated by authorized personnel to ensure diagrams continue to provide an accurate description of the network.

Modified p. 50 → 49

~~• Where account data is transmitted and processed, where it is stored, and whether storage is short term or long term.~~ (continued on next page) 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:

(continued on next page) 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:

Modified p. 55

Defined Approach Requirements Defined Approach Testing Procedures Purpose This requirement aims to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner. Good Practice All traffic inbound to the CDE, regardless of where it originates, should be evaluated to ensure it follows established, authorized rules. Connections should be inspected to ensure traffic is restricted to only authorized communications

•for example, by restricting source/destination addresses and ports, and blocking …

Defined Approach Requirements Defined Approach Testing Procedures Purpose This requirement aims to prevent malicious individuals from accessing the entity’s network via unauthorized IP addresses or from using services, protocols, or ports in an unauthorized manner.

Modified p. 57 → 58

Defined Approach Requirements Defined Approach Testing Procedures Purpose Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection. Examples An entity could implement a DMZ, which is a part of the network that manages connections between an untrusted network (for examples of untrusted networks refer to the Requirement 1 Overview) and services …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Implementing NSCs at every connection coming into and out of trusted networks allows the entity to monitor and control access and minimizes the chances of a malicious individual obtaining access to the internal network via an unprotected connection.

Modified p. 58 → 59

Applicability Notes The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols. ~~This requirement does not limit the use of UDP or other connectionless network protocols if state is maintained by the NSC.~~

Applicability Notes The intent of this requirement is to address communication sessions between trusted and untrusted networks, rather than the specifics of protocols.

Modified p. 62 → 63

Defined Approach Requirements Defined Approach Testing Procedures Purpose Computing devices that are allowed to connect to the Internet from outside the corporate environment

•for example, desktops, laptops, tablets, smartphones, and other mobile computing devices used by employees

•are more vulnerable to Internet-based threats. Use of security controls such as host-based controls (for example, personal firewall software or end-point protection solutions), network-based security controls (for example, firewalls, network- based heuristics inspection, and malware simulation), or hardware, helps to protect devices from Internet-based attacks, …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Computing devices that are allowed to connect to the Internet from outside the corporate environment

•for example, desktops, laptops, tablets, smartphones, and other mobile computing devices used by employees

•are more vulnerable to Internet-based threats.

Modified p. 63 → 64

These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active. ~~This requirement applies to employee-owned and company-owned computing devices. Systems that cannot be managed by corporate policy introduce weaknesses and provide …~~

These security controls may be temporarily disabled only if there is legitimate technical need, as authorized by management on a case-by-case basis. If these security controls need to be disabled for a specific purpose, it must be formally authorized. Additional security measures may also need to be implemented for the period during which these security controls are not active.

Modified p. 64 → 65

Requirement 2: Apply Secure Configurations to All System Components 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood. ~~2.2 System components are configured and managed securely. 2.3 Wireless environments are configured and managed securely.~~

Requirement 2: Apply Secure Configurations to All System Components 2.1 Processes and mechanisms for applying secure configurations to all system components are defined and understood.

Modified p. 67 → 68

Defined Approach Requirements Defined Approach Testing Procedures Purpose There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker. ~~By developing standards, entities ensure their system components will be configured consistently and securely, and address the protection of devices for …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose There are known weaknesses with many operating systems, databases, network devices, software, applications, container images, and other devices used by an entity or within an entity’s environment. There are also known ways to configure these system components to fix security vulnerabilities. Fixing security vulnerabilities reduces the opportunities available to an attacker.

Modified p. 68 → 69

Applicability Notes This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults. This requirement also applies where a system component is not installed within an entity’s environment, for example, software and applications that are part of the CDE and are accessed via a cloud subscription service.

Applicability Notes This applies to ALL vendor default accounts and passwords, including, but not limited to, those used by operating systems, software that provides security services, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) defaults.

Modified p. 69 → 70

• Only one primary function exists on a system component, OR

• Only one primary function exists on a system component,

Modified p. 69 → 70

• Primary functions with differing security levels that exist on the same system component are isolated from each other, OR

• Primary functions with differing security levels that exist on the same system component are isolated from each other,

Modified p. 71 → 72

2.2.4.a Examine system configuration standards to verify necessary ~~system~~ services, protocols, and ~~daemons~~ are identified and documented.

2.2.4.a Examine system configuration standards to verify necessary services, protocols, daemons, and functions are identified and documented.

Modified p. 75 → 76

Defined Approach Requirements Defined Approach Testing Procedures Purpose If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network. ~~Good Practice Wireless passwords should be constructed so that they are resistant to offline brute force attacks.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose If wireless networks are not implemented with sufficient security configurations (including changing default settings), wireless sniffers can eavesdrop on the traffic, easily capture data and passwords, and easily enter and attack the network.

Modified p. 77 → 78

Requirement 3: Protect Stored Account Data 3.1 Processes and mechanisms for protecting stored account data are defined and understood. 3.2 Storage of account data is kept to a minimum. 3.3 Sensitive authentication data (SAD) is not stored after authorization. 3.4 Access to displays of full PAN and ability to copy ~~cardholder data~~ are restricted. 3.5 Primary account number (PAN) is secured wherever it is stored. 3.6 Cryptographic keys used to protect stored account data are secured. 3.7 Where cryptography is …

Requirement 3: Protect Stored Account Data 3.1 Processes and mechanisms for protecting stored account data are defined and understood. 3.2 Storage of account data is kept to a minimum. 3.3 Sensitive authentication data (SAD) is not stored after authorization. 3.4 Access to displays of full PAN and ability to copy PAN are restricted. 3.5 Primary account number (PAN) is secured wherever it is stored. 3.6 Cryptographic keys used to protect stored account data are secured. 3.7 Where cryptography is used …

Modified p. 77 → 78

If account data is present in non-persistent memory (for example, RAM, volatile memory), encryption of ~~account data~~ is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. Data should be removed from volatile memory once the business purpose (for example, the associated transaction) is complete. In the case that data storage becomes persistent, all applicable PCI DSS Requirements will apply including encryption of stored data.

If account data is present in non-persistent memory (for example, RAM, volatile memory), encryption of PAN is not required. However, proper controls must be in place to ensure that memory maintains a non-persistent state. Data should be removed from volatile memory once the business purpose (for example, the associated transaction) is complete. In the case that data storage becomes persistent, all applicable PCI DSS Requirements will apply including encryption of stored data.

Modified p. 80 → 81

Defined Approach Requirements Defined Approach Testing Procedures Purpose A formal data retention policy identifies what data needs to be retained, for how long, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. The only account data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code. ~~The storage of SAD data prior to the completion of …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose A formal data retention policy identifies what data needs to be retained, for how long, and where that data resides so it can be securely destroyed or deleted as soon as it is no longer needed. The only account data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code.

Modified p. 81 → 82

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 …~~

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.

Removed p. 82

Applicability Notes This requirement does not apply to issuers and companies that support issuing services (where SAD is needed for a legitimate issuing business need) and have a business justification to store the sensitive authentication data. Refer to Requirement 3.3.3 for additional requirements specifically for issuers. Sensitive authentication data includes the data cited in Requirements 3.3.1.1 through 3.3.1.3.

Modified p. 82 → 83

Defined Approach Requirements Defined Approach Testing Procedures Purpose SAD is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Therefore, the storage of SAD upon completion of the authorization process is prohibited. ~~Definitions The authorization process completes when a merchant receives a transaction response (for example, an approval or decline).~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose SAD is very valuable to malicious individuals as it allows them to generate counterfeit payment cards and create fraudulent transactions. Therefore, the storage of SAD upon completion of the authorization process is prohibited.

Modified p. 82 → 83

3.3.1.a If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not ~~retained~~ after authorization.

3.3.1.a If SAD is received, examine documented policies, procedures, and system configurations to verify the data is not stored after authorization.

Modified p. 83 → 84

~~• Service code.~~ To minimize risk, store securely only these data elements as needed for business.

To minimize risk, store securely only these data elements as needed for business.

Removed p. 86

Applicability Notes Whether SAD is permitted to be stored prior to authorization is determined by the organizations that manage compliance programs (for example, payment brands and acquirers). Contact the organizations of interest for any additional criteria. This requirement applies to all storage of SAD, even if no PAN is present in the environment. Refer to Requirement 3.2.1 for an additional requirement that applies if SAD is stored prior to completion of authorization. This requirement does not apply to issuers and companies that support issuing services where there is a legitimate issuing business justification to store SAD). Refer to Requirement 3.3.3 for requirements specifically for issuers. This requirement does not replace how PIN blocks are required to be managed, nor does it mean that a properly encrypted PIN block needs to be encrypted again. This requirement is a best practice until 31 March 2025, after which it will be required and …

Removed p. 89

Customized Approach Objective PAN displays are restricted to the minimum number of digits necessary to meet a defined business need.

Applicability Notes 3.4.1.b Examine system configurations to verify that full PAN is only displayed for roles with a documented business need, and that PAN is masked for all other requests. This requirement does not supersede stricter requirements in place for displays of cardholder data•for example, legal or payment brand requirements for point-of-sale (POS) receipts. This requirement relates to protection of PAN where it is displayed on screens, paper receipts, printouts, etc., and is not to be confused with Requirement 3.5.1 for protection of PAN when stored, processed, or transmitted.

Modified p. 89 → 91

Defined Approach Requirements Defined Approach Testing Procedures Purpose The display of full PAN on computer screens, payment card receipts, paper reports, etc. can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that the full PAN is displayed only for those with a legitimate business need minimizes the risk of unauthorized persons gaining access to PAN data. ~~Good Practice Applying access controls according to defined roles is one way to limit access to viewing full PAN …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose The display of full PAN on computer screens, payment card receipts, paper reports, etc. can result in this data being obtained by unauthorized individuals and used fraudulently. Ensuring that the full PAN is displayed only for those with a legitimate business need minimizes the risk of unauthorized persons gaining access to PAN data.

Modified p. 89 → 91

3.4.1.a Examine documented policies and procedures for masking the display of PANs to verify:

(continued on next page) 3.4.1.a Examine documented policies and procedures for masking the display of PANs to verify:

Modified p. 90 → 93

Applicability Notes 3.4.2.b Examine configurations for remote-access technologies to verify that technical controls to prevent copy and/or relocation of PAN for all personnel, unless explicitly authorized. Storing or relocating PAN onto local hard drives, removable electronic media, and other storage devices brings these devices into scope for PCI DSS. ~~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.~~

Applicability Notes 3.4.2.b Examine configurations for remote-access technologies to verify that technical controls to prevent copy and/or relocation of PAN for all personnel, unless explicitly authorized. Storing or relocating PAN onto local hard drives, removable electronic media, and other storage devices brings these devices into scope for PCI DSS.

Removed p. 91

Applicability Notes It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) must all be protected. This requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN.

Modified p. 91 → 94

Defined Approach Requirements Defined Approach Testing Procedures Purpose ~~The removal of cleartext~~ stored PAN is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control. Secondary independent control systems (for example governing access to, and use of, cryptography and decryption keys) prevent the failure of a primary access control system leading to a breach of confidentiality of …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Rendering stored PAN unreadable is a defense in depth control designed to protect the data if an unauthorized individual gains access to stored data by taking advantage of a vulnerability or misconfiguration of an entity’s primary access control.

Modified p. 91 → 94

• PCI SSC’s Tokenization Product Security Guidelines ~~(https://www.pcisecuritystandards.org/docume nts/Tokenization_Product_Security_Guidelines .pdf)~~

• PCI SSC’s Tokenization Product Security Guidelines (https://www.pcisecuritystandards.org/documents/T okenization_Product_Security_Guidelines.pdf)

Removed p. 92

Refer to the following for more information about HMAC, CMAC, and GMAC, respectively: NIST SP 800-107r1, NIST SP 800-38B, and NIST SP 800-38D).

See NIST SP 800-107 (Revision 1): Recommendation for Applications Using Approved Hash Algorithms §5.3.

Modified p. 92 → 94

This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) must all be protected. This requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN. This requirement is considered a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Applicability Notes This requirement applies to PANs stored in primary storage (databases, or flat files such as text files spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs).

Modified p. 92 → 95

3.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures.

3.5.1.1.a Examine documentation about the hashing method used to render PAN unreadable, including the vendor, type of system/process, and the encryption algorithms (as applicable) to verify that the hashing method results in keyed cryptographic hashes of the entire PAN, with associated key management processes and procedures. Customized Approach Objective Cleartext PAN cannot be determined from hashes of the PAN.

Modified p. 92 → 95

~~Applicability Notes~~ 3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7.

3.5.1.1.b Examine documentation about the key management procedures and processes associated with the keyed cryptographic hashes to verify keys are managed in accordance with Requirements 3.6 and 3.7.

Modified p. 95 → 99

3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods.

3.5.1.3.b Examine files containing authentication factors (passwords, passphrases, or cryptographic keys) and interview personnel to verify that authentication factors that allow access to unencrypted data are stored securely and are independent from the native operating system’s authentication and access control methods. Customized Approach Objective Disk encryption implementations are configured to require independent authentication and logical access controls for decryption.

Modified p. 95 → 99

Applicability Notes Disk or partition encryption implementations must also meet all other PCI DSS encryption and ~~key- management~~ requirements.

Applicability Notes Disk or partition encryption implementations must also meet all other PCI DSS encryption and key-management requirements.

Modified p. 96 → 100

Defined Approach Requirements Defined Approach Testing Procedures Purpose Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data. Good Practice Having a centralized key management system based on industry standards is recommended for managing cryptographic keys. Further Information The entity’s key management procedures will benefit through alignment with industry requirements, Sources for information on cryptographic key management life cycles include:

Defined Approach Requirements Defined Approach Testing Procedures Purpose Cryptographic keys must be strongly protected because those who obtain access will be able to decrypt data.

Modified p. 96 → 100

Applicability Notes This requirement applies to keys used to ~~encrypt~~ stored account data and to key-encrypting keys used to protect data-encrypting keys. The requirement to protect keys used to protect stored account data from disclosure and misuse applies to both data-encrypting keys and key- encrypting keys. Because one key-encrypting key may grant access to many data-encrypting keys, the key-encrypting keys require strong protection measures.

Applicability Notes This requirement applies to keys used to protect stored account data and to key-encrypting keys used to protect data-encrypting keys.

Modified p. 97 → 101

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, ~~as outlined in~~ Requirement 12.3.4.

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, to support meeting Requirement 12.3.4.

Modified p. 97 → 102

Applicability Notes This requirement applies only when the entity being assessed is a service provider. In cloud HSM implementations, responsibility for the cryptographic architecture according to this Requirement will be shared between the cloud provider and the cloud customer. The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement …

The bullet above (for including, in the cryptographic architecture, that the use of the same cryptographic keys in production and test is prevented) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.6.1.1 and must be fully considered during a PCI DSS assessment.

Modified p. 98 → 103

• As at least two full-length key components or key shares, in accordance with an ~~industry-accepted~~ method.

• As at least two full-length key components or key shares, in accordance with an industry- accepted method.

Modified p. 98 → 104

~~Applicability Notes It is not required that public keys be stored in one of these forms. Cryptographic keys stored as part of a key management system (KMS) that employs SCDs are acceptable.~~ A cryptographic key that is split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

A cryptographic key that is split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

Modified p. 98 → 104

• Using an approved random number generator and within an SCD, OR

• Using an approved random number generator and within an SCD,

Modified p. 100 → 106

Defined Approach Requirements Defined Approach Testing Procedures Purpose Use of strong cryptographic keys significantly increases the level of security of encrypted account data. ~~Further Information See the sources referenced at "Cryptographic Key Generation in Appendix G.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Use of strong cryptographic keys significantly increases the level of security of encrypted account data.

Modified p. 102 → 109

• The key is suspected of or known to be compromised. ~~Retired or replaced keys are not used for encryption operations.~~

• The key is suspected of or known to be compromised.

Modified p. 103 → 110

~~Applicability Notes This control is applicable for manual key- management operations or where key management is not controlled by the encryption product.~~ A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

A cryptographic key that is simply split into two parts does not meet this requirement. Secret or private keys stored as key components or key shares must be generated via one of the following:

Modified p. 103 → 110

• Using an approved random number generator and within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device, OR

• Using an approved random number generator and within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device,

Modified p. 104 → 111

Defined Approach Requirements Defined Approach Testing Procedures Purpose If an attacker is able to substitute an entity’s key with a key the attacker knows, the attacker will be able to decrypt all data encrypted with that key. Good Practice The encryption solution should not allow for or accept substitution of keys from unauthorized sources or unexpected processes. Controls should include ensuring that individuals with access to key components or shares do not have access to other components or shares that …

Defined Approach Requirements Defined Approach Testing Procedures Purpose If an attacker is able to substitute an entity’s key with a key the attacker knows, the attacker will be able to decrypt all data encrypted with that key.

Modified p. 104 → 111

3.7.7.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define prevention of unauthorized substitution of cryptographic keys. ~~3.7.7.b Interview personnel and/or observe processes to verify that unauthorized substitution of keys is prevented.~~

3.7.7.a Examine the documented key-management policies and procedures for keys used for protection of stored account data and verify that they define prevention of unauthorized substitution of cryptographic keys.

Modified p. 106 → 114

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and documented. 4.2 PAN is protected with strong cryptography during transmission The use of strong cryptography provides greater assurance in preserving data confidentiality, integrity, and non-repudiation.

Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks 4.1 Processes and mechanisms for protecting cardholder data with strong cryptography during transmission over open, public networks are defined and understood.

Modified p. 109 → 117

Defined Approach Requirements Defined Approach Testing Procedures Purpose Sensitive information must be encrypted during transmission over public networks because it is easy and common for a malicious individual to intercept and/or divert data while in transit. Good Practice The network and data-flow diagrams defined in Requirement 1 are useful resources for identifying all connection points where account data is transmitted or received over open, public networks. While not required, it is considered a good practice for entities to also encrypt …

PAN transmissions can be protected by encrypting the data before it is transmitted, or by encrypting the session over which the data is transmitted, or both. While it is not required that strong cryptography be applied at both the data level and the session level, it is strongly recommended. If encrypted at the data level, the cryptographic keys used for protecting the data can be managed in accordance with Requirements 3.6 and 3.7. If the data is encrypted at the …

Modified p. 109 → 117

4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected.

4.2.1.d Examine system configurations to verify that keys and/or certificates that cannot be verified as trusted are rejected. Customized Approach Objective Cleartext PAN cannot be read or intercepted from any transmissions over open, public networks.

Modified p. 111 → 119

~~• Wireless technologies, including Wi-Fi, Bluetooth, cellular technologies, and satellite communications.~~ Further Information Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use. ~~For more information about strong cryptography and secure protocols, see industry standards and best practices such as NIST SP 800-52 and SP 800-57.~~

Further Information Vendor recommendations and industry best practices can be consulted for information about the proper encryption strength specific to the encryption methodology in use.

Modified p. 114 → 122

~~Applicability Notes This requirement also applies if a customer, or other third-party, requests that PAN is sent to them via end-user messaging technologies.~~ There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of 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 delete the cardholder data and implement …

There could be occurrences where an entity receives unsolicited cardholder data via an insecure communication channel that was not intended for transmissions of 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 delete the cardholder data and implement measures to prevent the channel from being used for cardholder data.

Modified p. 115 → 123

Requirement 5: Protect All Systems and Networks from Malicious Software 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood. 5.2 Malicious software (malware) is prevented, or detected and addressed. 5.3 Anti-malware mechanisms and processes are active, maintained, and monitored. 5.4 Anti-phishing mechanisms protect users against phishing attacks.

Requirement 5: Protect All Systems and Networks from Malicious Software 5.1 Processes and mechanisms for protecting all systems and networks from malicious software are defined and understood.

Modified p. 115 → 123

Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, ~~and~~ rootkits, malicious code, scripts, and links.

Examples include viruses, worms, Trojans, spyware, ransomware, keyloggers, rootkits, malicious code, scripts, and links.

Modified p. 117 → 126

Defined Approach Requirements Defined Approach Testing Procedures Purpose There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an anti- malware solution that is updated regularly, new forms of malware can be used to attack systems, disable a network, or compromise data. Good Practice It is beneficial for entities to be aware of "zero- day" attacks (those that exploit a previously unknown vulnerability) and consider solutions that focus on behavioral characteristics and …

Defined Approach Requirements Defined Approach Testing Procedures Purpose There is a constant stream of attacks targeting newly discovered vulnerabilities in systems previously regarded as secure. Without an anti- malware solution that is updated regularly, new forms of malware can be used to attack systems, disable a network, or compromise data.

Modified p. 119 → 128

~~• A strategy to add malware protection for any system types for which malware protection has become necessary.~~ Trends in malware should be included in the identification of new security vulnerabilities at Requirement 6.3.1, and methods to address new trends should be incorporated into the entity’s configuration standards and protection mechanisms as needed.

Trends in malware should be included in the identification of new security vulnerabilities at Requirement 6.3.1, and methods to address new trends should be incorporated into the entity’s configuration standards and protection mechanisms as needed.

Modified p. 121 → 130

Defined Approach Requirements Defined Approach Testing Procedures Purpose For an anti-malware solution to remain effective, it needs to have the latest security updates, signatures, threat analysis engines, and any other malware protections on which the solution relies. Having an automated update process avoids burdening end users with responsibility for manually installing updates and provides greater assurance that anti-malware protection mechanisms are updated as quickly as possible after an update is released. Good Practice Anti-malware mechanisms should be updated via a …

Defined Approach Requirements Defined Approach Testing Procedures Purpose For an anti-malware solution to remain effective, it needs to have the latest security updates, signatures, threat analysis engines, and any other malware protections on which the solution relies.

Modified p. 123 → 132

5.3.2.1.b Examine documented results of periodic malware scans and interview personnel to verify scans are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement.

5.3.2.1.b Examine documented results of periodic malware scans and interview personnel to verify scans are performed at the frequency defined in the entity’s targeted risk analysis performed for this requirement. Customized Approach Objective Scans by the malware solution are performed at a frequency that addresses the entity’s risk.

Modified p. 123 → 132

Applicability Notes This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2. ~~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.~~

Applicability Notes This requirement applies to entities conducting periodic malware scans to meet Requirement 5.3.2.

Modified p. 124 → 133

• Performs automatic scans of when the media is inserted, connected, or logically mounted, OR

• Performs automatic scans of when the media is inserted, connected, or logically mounted,

Modified p. 125 → 135

~~• the~~ reason for taking such action should be understood and approved by an appropriate management representative. Any disabling or altering of ~~anti-malware~~ mechanisms, including on administrators’ own devices, should be performed by authorized personnel. It is recognized that administrators have privileges that may allow them to disable ~~anti-malware~~ on their own computers, but there should be alerting mechanisms in place when such software is disabled and then follow up that occurs to ensure correct processes were followed. ~~Examples Additional …~~

Good Practice Where there is a legitimate need to temporarily disable a system’s anti-malware protection

•for example, to support a specific maintenance activity or investigation of a technical problem

•the reason for taking such action should be understood and approved by an appropriate management representative. Any disabling or altering of anti- malware mechanisms, including on administrators’ own devices, should be performed by authorized personnel. It is recognized that administrators have privileges that may allow them to disable anti- malware on their own …

Modified p. 126 → 136

Applicability Notes This requirement applies to the automated mechanism. It is not intended that the systems and services providing such automated mechanisms (such as email servers) are brought into scope for PCI DSS. The focus of this requirement is on protecting personnel with access to system components in- scope for PCI DSS. Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this …

Meeting this requirement for technical and automated controls to detect and protect personnel against phishing is not the same as Requirement 12.6.3.1 for security awareness training. Meeting this requirement does not also meet the requirement for providing personnel with security awareness training, and vice versa.

Modified p. 128 → 138

Requirement 6: Develop and Maintain Secure Systems and Software 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood. 6.2 Bespoke and custom software are developed securely. 6.3 Security vulnerabilities are identified and addressed. 6.4 Public-facing web applications are protected against attacks. 6.5 Changes to all system components are managed securely.

Requirement 6: Develop and Maintain Secure Systems and Software 6.1 Processes and mechanisms for developing and maintaining secure systems and software are defined and understood.

Modified p. 128 → 138

Code repositories that store application code, system configurations, or other configuration data that can impact the security of ~~account~~ data ~~or the CDE~~ are in scope for PCI DSS assessments.

Code repositories that store application code, system configurations, or other configuration data that can impact the security of cardholder data and/or sensitive authentication data are in scope for PCI DSS assessments.

Modified p. 131 → 141

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment. Good Practice Understanding how sensitive data is handled by the application

•including when stored, transmitted, and in memory

•can help identify where data needs to be protected. PCI DSS requirements must be considered when developing software to meet those requirements by design, rather than trying …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without the inclusion of security during the requirements definition, design, analysis, and testing phases of software development, security vulnerabilities can be inadvertently or maliciously introduced into the production environment.

Modified p. 133 → 143

• Analysis of insecure code structures that may contain potential vulnerabilities related to common software attacks identified in ~~Requirements 6.2.5.~~

• Analysis of insecure code structures that may contain potential vulnerabilities related to common software attacks identified in Requirement 6.2.4.

Modified p. 133 → 143

Applicability Notes This requirement for code reviews applies to all bespoke and custom software (both internal and ~~public-facing),~~ as part of the system development lifecycle. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement 6.4. Code reviews may be performed using either manual or automated processes, or a combination of both.

Applicability Notes This requirement for code reviews applies to all bespoke and custom software (both internal and public facing), as part of the system development lifecycle.

Modified p. 134 → 144

~~Applicability Notes Manual code reviews can be conducted by knowledgeable internal personnel or knowledgeable third-party personnel.~~ An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management.

An individual that has been formally granted accountability for release control and who is neither the original code author nor the code reviewer fulfills the criteria of being management.

Modified p. 135 → 145

• automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms. See the PCI Perspectives blog article “Beware of Account Testing Attacks.” Researching and documenting software engineering techniques or other methods helps to define how software developers prevent or mitigate various software attacks by features or countermeasures they build into software. This might include identification/authentication mechanisms, access control, input validation routines, etc. Developers should be familiar with different types of vulnerabilities and potential attacks and …

• automated attacks that are actively exploited in payments and abuse identification, authentication, or authorization mechanisms. See the PCI Perspectives blog article “Beware of Account Testing Attacks.” (continued on next page) 6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

Removed p. 137

Applicability Notes 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.

Modified p. 137 → 147

Defined Approach Requirements Defined Approach Testing Procedures Purpose Classifying the risks (for example, as critical, high, medium, or low) allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited. Good Practice Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization’s environment and risk-assessment strategy. When an entity is assigning its risk rankings, it should consider using a formal, objective, …

Modified p. 137 → 147

Customized Approach Objective New system and software vulnerabilities that may impact the security of ~~account~~ data ~~or the CDE~~ are monitored, cataloged, and risk assessed.

Customized Approach Objective New system and software vulnerabilities that may impact the security of cardholder data and/or sensitive authentication data are monitored, cataloged, and risk assessed.

Modified p. 141 → 152

• ~~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. 141 → 152

• All other applicable security patches/updates are installed within an appropriate time frame as determined by the ~~entity (for example, within three months~~ of ~~release).~~

• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity’s assessment of the criticality of the risk to the environment as identified according to the risk ranking process at Requirement 6.3.1.

Modified p. 142 → 154

• The application is re-evaluated after the ~~corrections~~ OR

• The application is re-evaluated after the corrections. OR

Modified p. 142 → 154

• If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that ~~public-facing~~ web applications are reviewed in accordance with all elements of this requirement specific to the tool/method. OR

• If manual or automated vulnerability security assessment tools or methods are in use, examine documented processes, interview personnel, and examine records of application security assessments to verify that public- facing web applications are reviewed in accordance with all elements of this requirement specific to the tool/method.

Modified p. 143 → 155

Applicability Notes This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2. ~~This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.~~

Applicability Notes This assessment is not the same as the vulnerability scans performed for Requirement 11.3.1 and 11.3.2.

Modified p. 144 → 156

Applicability Notes This new requirement will replace Requirement 6.4.1 once its effective date is reached. ~~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.~~

Applicability Notes This new requirement will replace Requirement 6.4.1 once its effective date is reached.

Removed p. 145

Customized Approach Objective Unauthorized code cannot be present in the payment page as it is rendered in the consumer’s browser.

Applicability Notes This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. 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.

Modified p. 145 → 157

• 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.

Modified p. 145 → 157

6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement.

6.4.3.b Interview responsible personnel and examine inventory records and system configurations to verify that all payment page scripts that are loaded and executed in the consumer’s browser are managed in accordance with all elements specified in this requirement. Customized Approach Objective Unauthorized code cannot be executed in the payment page as it is rendered in the consumer’s browser.

Modified p. 147 → 159

Defined Approach Requirements Defined Approach Testing Procedures Purpose Change management procedures must be applied to all changes

•including the addition, removal, or modification of any system component

•in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. ~~Good Practice Approval by authorized parties confirms that …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Change management procedures must be applied to all changes

•including the addition, removal, or modification of any system component

•in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes.

Modified p. 148 → 160

• Systems are protected with required controls

•for example, file integrity monitoring (FIM), ~~anti-malware,~~ patches, and audit logging.

• Systems are protected with required controls

•for example, file integrity monitoring (FIM), anti- malware, patches, and audit logging.

Modified p. 153 → 165

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood. ~~7.2 Access to system components and data is appropriately defined and assigned. 7.3 Access to system components and data is managed via an access control system(s).~~

Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know 7.1 Processes and mechanisms for restricting access to system components and cardholder data by business need to know are defined and understood.

Modified p. 153 → 165

These requirements do not apply to consumers (cardholders). ~~Refer to Appendix G for definitions of PCI DSS terms.~~

These requirements do not apply to consumers (cardholders).

Modified p. 154 → 165

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 7.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 7. While it is important to define the specific policies or procedures called out in Requirement 7, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating …

Refer to Appendix G for definitions of PCI DSS terms. Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 7.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 7. While it is important to define the specific policies or procedures called out in Requirement 7, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important to update policies and procedures as needed to address changes in …

Modified p. 156 → 168

Defined Approach Requirements Defined Approach Testing Procedures Purpose Defining an access control model that is appropriate for the entity’s technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights. Good Practice A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing mission- …

Good Practice A factor to consider when defining access needs is the separation of duties principle. This principle is intended to prevent fraud and misuse or theft of resources. For example, 1) dividing mission- critical functions and information system support functions among different individuals and/or functions, 2) establishing roles such that information system support activities are performed by different functions/individuals (for example, system management, programming, configuration management, quality assurance and testing, and network security), and 3) ensuring security personnel administering …

Modified p. 157 → 169

• Which activities each job function needs to perform (for example, read/write or query). Once job functions, resources, and activities per job functions are defined, individuals can be granted access accordingly. Examples Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs.

Access control models that entities can consider include role-based access control (RBAC) and attribute-based access control (ABAC). The access control model used by a given entity depends on their business and access needs.

Modified p. 160 → 172

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. See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts. 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.

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. 161 → 173

7.2.5.b Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement. ~~Customized Approach Objective Access rights granted to application and system accounts are limited to only the access needed for the operability of that application or system.~~

7.2.5.b Examine privileges associated with system and application accounts and interview responsible personnel to verify that application and system accounts and related access privileges are assigned and managed in accordance with all elements specified in this requirement.

Modified p. 163 → 175

Applicability Notes This requirement applies to controls for user access to query repositories of stored cardholder data. ~~See Requirements 7.2.5 and 7.2.5.1 and 8.6.1 through 8.6.3 for controls for application and system accounts.~~

Applicability Notes This requirement applies to controls for user access to query repositories of stored cardholder data.

Modified p. 164 → 177

Defined Approach Requirements Defined Approach Testing Procedures Purpose A default setting of “deny all” ensures no one is granted access unless a rule is established specifically granting such access. Good Practice It is important to check the default configuration of access control systems because some are set by default to “allow all,” thereby permitting access unless/until a rule is written to specifically deny it.

Good Practice It is important to check the default configuration of access control systems because some are set by default to “allow all,” thereby permitting access unless/until a rule is written to specifically deny it.

Modified p. 165 → 178

Requirement 8: Identify Users and Authenticate Access to System Components 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood. 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle. 8.3 Strong authentication for users and administrators is established and managed. 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE 8.5 Multi-factor authentication (MFA) systems are configured to prevent misuse. 8.6 Use of …

Requirement 8: Identify Users and Authenticate Access to System Components 8.1 Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.

Removed p. 166

• Point-of-sale accounts

• Accounts with administrative capabilities

• System and application accounts

• All accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by employees, contractors, consultants, internal and external vendors, and other third parties (for example, for providing support or maintenance services). Certain requirements are not intended to apply to user accounts 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). When items do not apply, they are noted directly within the specific requirement. These requirements do not apply to accounts used by consumers (cardholders). Refer to Appendix G for definitions of PCI DSS terms.

Modified p. 167 → 179

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 8.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 8. While it is important to define the specific policies or procedures called out in Requirement 8, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating …

 Point-of-sale accounts  Accounts with administrative capabilities  System and application accounts  All accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by employees, contractors, consultants, internal and external vendors, and other third parties (for example, for providing support or maintenance services). Certain requirements are 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 …

Modified p. 169 → 182

Defined Approach Requirements Defined Approach Testing Procedures Purpose The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls. By ensuring each user is uniquely identified, instead of using one ID for several employees, an organization can maintain individual responsibility for actions and an effective record in the audit log per employee. In addition, this will assist with issue resolution and containment when misuse or malicious …

Defined Approach Requirements Defined Approach Testing Procedures Purpose The ability to trace actions performed on a computer system to an individual establishes accountability and traceability and is fundamental to establishing effective access controls.

Modified p. 170 → 183

• ~~Account~~ use is prevented unless needed for an exceptional circumstance.

• ID use is prevented unless needed for an exceptional circumstance.

Modified p. 170 → 183

8.2.2.c Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement. Customized Approach Objective All actions performed by users with ~~generic, system,~~ or ~~shared~~ IDs are attributable to an individual person.

8.2.2.c Interview system administrators to verify that shared authentication credentials are only used when necessary, on an exception basis, and are managed in accordance with all elements specified in this requirement. Customized Approach Objective All actions performed by users with group, shared, or generic IDs are attributable to an individual person.

Modified p. 170 → 183

Applicability Notes This requirement is not intended to apply to user accounts within 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 within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.

Modified p. 171 → 184

Defined Approach Requirements Defined Approach Testing Procedures Purpose Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services. If a service provider uses the same authentication factors to access multiple customers, all the service provider’s customers can easily be compromised if an attacker compromises that one factor. Criminals know this and deliberately target service providers looking for a shared authentication factor that gives them remote access to many …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Service providers with remote access to customer premises typically use this access to support POS POI systems or provide other remote services.

Modified p. 171 → 185

Applicability Notes This requirement applies only when the entity being assessed is a service provider. This requirement is not intended to apply to service providers accessing their own shared services environments, where multiple customer environments are hosted. If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.

If service provider employees use shared authentication factors to remotely access customer premises, these factors must be unique per customer and managed in accordance with Requirement 8.2.2.

Modified p. 173 → 187

Defined Approach Requirements Defined Approach Testing Procedures Purpose Allowing third parties to have 24/7 access into an entity’s systems and networks in case they need to provide support increases the chances of unauthorized access. This access could result in an unauthorized user in the third party’s environment or a malicious individual using the always-available external entry point into an entity’s network. Where third parties do need access 24/7, it should be documented, justified, monitored, and tied to specific service reasons. …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Allowing third parties to have 24/7 access into an entity’s systems and networks in case they need to provide support increases the chances of unauthorized access. This access could result in an unauthorized user in the third party’s environment or a malicious individual using the always-available external entry point into an entity’s network. Where third parties do need access 24/7, it should be documented, justified, monitored, and tied to specific service reasons.

Modified p. 173 → 188

~~Customized Approach Objective Third party~~ remote access cannot be used except where specifically authorized and use is overseen by management.

Third-party remote access cannot be used except where specifically authorized and use is overseen by management.

Modified p. 174 → 189

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). This requirement is not meant to prevent legitimate activities from being performed while the console/PC is unattended.~~

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. 175 → 190

Defined Approach Requirements Defined Approach Testing Procedures Purpose When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s). Good Practice A common approach for a malicious individual to compromise a system is to exploit weak or nonexistent authentication factors (for example, passwords/passphrases). Requiring strong authentication factors helps protect against this attack. Further Information See fidoalliance.org for more information …

Defined Approach Requirements Defined Approach Testing Procedures Purpose When used in addition to unique IDs, an authentication factor helps protect user IDs from being compromised, since the attacker needs to have the unique ID and compromise the associated authentication factor(s).

Modified p. 175 → 190

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). This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements. A digital certificate is a valid option for “something you have” if it is unique for a particular user.

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. 176 → 192

• for example, calling a help desk and acting as a legitimate user

•to have an authentication factor changed so they can use a valid user ID. Requiring positive identification of a user reduces the probability of this type of attack succeeding. Good Practice Modifications to authentication factors for which user identity should be verified include but are not limited to performing password resets, provisioning new hardware or software tokens, and generating new keys. Examples Methods to verify a user’s identity …

• for example, calling a help desk and acting as a legitimate user

•to have an authentication factor changed so they can use a valid user ID.

Modified p. 177 → 193

8.3.4.b Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed. ~~Customized Approach Objective An authentication factor cannot be guessed in a brute force, online attack.~~

8.3.4.b Examine system configuration settings to verify that password parameters are set to require that once a user account is locked out, it remains locked for a minimum of 30 minutes or until the user’s identity is confirmed.

Modified p. 177 → 193

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. 178 → 194

• 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. 179 → 195

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.

Removed p. 181

Applicability Notes This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements. 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 does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.

Modified p. 182 → 199

Defined Approach Requirements Defined Approach Testing Procedures Purpose Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. Good Practice Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase …

Good Practice Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password.

Modified p. 182 → 199

Applicability Notes This requirement applies only when the entity being assessed is a service provider. This requirement does not apply to accounts of consumer users accessing their own payment card information. This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective.

Applicability Notes This requirement applies only when the entity being assessed is a service provider.

Removed p. 185

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. 185 → 202

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase. ~~Definitions Using one factor twice (for example, using two separate passwords) is …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requiring more than one type of authentication factor reduces the probability that an attacker can gain access to a system by masquerading as a legitimate user, because the attacker would need to compromise multiple authentication factors. This is especially true in environments where traditionally the single authentication factor employed was something a user knows such as a password or passphrase.

Removed p. 186

Applicability Notes This requirement does not apply to:

Modified p. 186 → 203

8.4.2.a Examine network and/or system configurations to verify MFA is implemented for all access into the CDE.

8.4.2.a Examine network and/or system configurations to verify MFA is implemented for all non-console access into the CDE.

Removed p. 188

• 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.

Modified p. 188 → 206

8.4.3.b Observe personnel (for example, users and administrators) connecting remotely to the network and verify that multi-factor authentication is required.

8.4.3.b Observe personnel (for example, users and administrators) and third parties connecting remotely to the network and verify that multi-factor authentication is required. Customized Approach Objective Remote access to the entity’s network cannot be obtained by using a single authentication factor.

Modified p. 188 → 207

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. If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not …

If remote access is to a part of the entity’s network that is properly segmented from the CDE, such that remote users cannot access or impact the CDE, MFA for remote access to that part of the network is not required. However, MFA is required for any remote access to networks with access to the CDE and is recommended for all remote access to the entity’s networks.

Modified p. 189 → 208

Defined Approach Requirements Defined Approach Testing Procedures Purpose Poorly configured MFA systems can be bypassed by attackers. This requirement therefore addresses configuration of MFA system(s) that provide MFA for users accessing system components in the CDE. Definitions Using one type of factor twice (for example, using two separate passwords) is not considered multi- factor authentication. Further Information For more information about MFA systems and features, refer to the following: PCI SSC’s Information Supplement: Multi-Factor Authentication PCI SSC’s Frequently Asked Questions …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Poorly configured MFA systems can be bypassed by attackers. This requirement therefore addresses configuration of MFA system(s) that provide MFA for users accessing system components in the CDE.

Modified p. 189 → 209

~~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.

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.

Removed p. 190

Defined Approach Requirements Defined Approach Testing Procedures Purpose Like individual user accounts, system and application accounts require accountability and strict management to ensure they are used only for the intended purpose and are not misused. Attackers often compromise system or application accounts to gain access to cardholder data. Good Practice Where possible, configure system and application accounts to disallow interactive login to prevent unauthorized individuals from logging in and using the account with its associated system privileges, and to limit the machines and devices on which the account can be used. Definitions System or application accounts are those accounts that execute processes or perform tasks on a computer system or application and are not typically accounts that an individual logs into. These accounts usually have elevated privileges that are required to perform specialized tasks or functions. Interactive login is the ability for a person to log into a system or …

Modified p. 191 → 211

Applicability Notes Stored passwords/passphrases are required to be encrypted in accordance with PCI DSS Requirement 8.3.2. ~~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.~~

Applicability Notes Stored passwords/passphrases are required to be encrypted in accordance with PCI DSS Requirement 8.3.2.

Modified p. 192 → 212

• Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly (see Requirement 8.3.9). All these elements affect the level of risk for application and system accounts and might impact the security of systems accessed by the system and application accounts. (continued on next page) 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:

• Whether the security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly (see Requirement 8.3.9).

Modified p. 192 → 212

8.6.3.b Examine the entity’s targeted risk analysis for the change frequency and complexity for passwords/passphrases ~~used~~ for ~~interactive login to~~ application and system accounts to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1 and addresses:

8.6.3.b Examine the entity’s targeted risk analysis for the change frequency and complexity for passwords/passphrases for application and system accounts to verify the risk analysis was performed in accordance with all elements specified in Requirement 12.3.1 and addresses:

Modified p. 192 → 212

Customized Approach Objective 8.6.3.c Interview responsible personnel and examine system configuration settings to verify that passwords/passphrases for any application and system accounts ~~that can be used for interactive login~~ are protected against misuse in accordance with all elements specified in this requirement.

Customized Approach Objective 8.6.3.c Interview responsible personnel and examine system configuration settings to verify that passwords/passphrases for any application and system accounts are protected against misuse in accordance with all elements specified in this requirement.

Removed p. 194

1. Requirements that specifically refer to sensitive areas are intended to apply to those areas only. 2. Requirements that specifically refer to the cardholder data environment (CDE) are intended to apply to the entire CDE, including any sensitive areas residing within the CDE. 3. Requirements that specifically refer to the facility are referencing the types of controls that may be managed more broadly at the physical boundary of a business premise (such as a building) within which CDEs and sensitive areas reside. These controls often exist outside a CDE or sensitive area, for example a guard desk that identifies, badges, and logs visitors. The term “facility” is used to recognize that these controls may exist at different places within a facility, for instance, at building entry or at an internal entrance to a data center or office space. Refer to Appendix G for definitions of “media,” “personnel,” “sensitive areas” and …

Modified p. 194 → 214

Requirement 9: Restrict Physical Access to Cardholder Data 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood. 9.2 Physical access controls manage entry into facilities and systems containing cardholder data. 9.3 Physical access for personnel and visitors is authorized and managed. 9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed. 9.5 Point of interaction (POI) devices are protected from tampering and unauthorized substitution.

Requirement 9: Restrict Physical Access to Cardholder Data 9.1 Processes and mechanisms for restricting physical access to cardholder data are defined and understood.

Modified p. 195 → 214

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 9.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 9. While it is important to define the specific policies or procedures called out in Requirement 9, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating …

1. Requirements that specifically refer to sensitive areas are intended to apply to those areas only. Each entity should identify the sensitive areas in its environments to ensure the appropriate physical controls are implemented. 2. Requirements that specifically refer to the cardholder data environment (CDE) are intended to apply to the entire CDE, including any sensitive areas residing within the CDE. 3. Requirements that specifically refer to the facility are referencing the types of controls that may be managed more …

Modified p. 197 → 217

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without physical access controls, unauthorized persons could potentially gain access to the CDE and sensitive information, or could alter system configurations, introduce vulnerabilities into the network, or destroy or steal equipment. Therefore, the purpose of this requirement is that physical access to the CDE is controlled via physical security controls such as badge readers or other mechanisms such as lock and key. ~~Good Practice Whichever mechanism meets this requirement, it must be …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without physical access controls, unauthorized persons could potentially gain access to the CDE and sensitive information, or could alter system configurations, introduce vulnerabilities into the network, or destroy or steal equipment. Therefore, the purpose of this requirement is that physical access to the CDE is controlled via physical security controls such as badge readers or other mechanisms such as lock and key.

Modified p. 199 → 219

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without appropriate physical security over access to wireless components and devices, and computer networking and telecommunications equipment and lines, malicious users could gain access to the entity’s network resources. Additionally, they could connect their own devices to the network to gain unauthorized access to the CDE or systems connected to the CDE. ~~Additionally, securing networking and communications hardware prevents malicious users from intercepting network traffic or physically connecting their own devices to …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without appropriate physical security over access to wireless components and devices, and computer networking and telecommunications equipment and lines, malicious users could gain access to the entity’s network resources. Additionally, they could connect their own devices to the network to gain unauthorized access to the CDE or systems connected to the CDE.

Modified p. 200 → 221

Defined Approach Requirements Defined Approach Testing Procedures Purpose Establishing procedures for granting, managing, and removing access when it is no longer needed ensures non-authorized individuals are prevented from gaining access to areas containing cardholder data. In addition, it is important to limit access to the actual badging system and badging materials to prevent unauthorized personnel from making their own badges and/or setting up their own access rules. ~~Good Practice It is important to visually identify the personnel that are physically …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Establishing procedures for granting, managing, and removing access when it is no longer needed ensures non-authorized individuals are prevented from gaining access to areas containing cardholder data. In addition, it is important to limit access to the actual badging system and badging materials to prevent unauthorized personnel from making their own badges and/or setting up their own access rules.

Modified p. 203 → 224

Defined Approach Requirements Defined Approach Testing Procedures Purpose A visitor log documenting minimum information about the visitor is easy and inexpensive to maintain. It will assist in identifying historical physical access to a building or room and potential access to cardholder data. Good Practice When logging the date and time of visit, including both in and out times is considered a best practice, since it provides helpful tracking information and provides assurance that a visitor has left at the end …

Defined Approach Requirements Defined Approach Testing Procedures Purpose A visitor log documenting minimum information about the visitor is easy and inexpensive to maintain. It will assist in identifying historical physical access to a building or room and potential access to cardholder data.

Modified p. 203 → 224

9.3.4.a Examine the visitor ~~log~~ and interview responsible personnel to verify that a visitor ~~log is~~ used to record physical access to the facility and sensitive areas.

9.3.4.a Examine the visitor logs and interview responsible personnel to verify that visitor logs are used to record physical access to both the facility and sensitive areas.

Modified p. 203 → 224

9.3.4.b Examine the visitor ~~log~~ and verify that the ~~log contains:~~

9.3.4.b Examine the visitor logs and verify that the logs contain:

Modified p. 204 → 225

9.4.1.1.b Examine logs or other documentation and interview responsible personnel at the storage location to verify that offline media backups are stored in a secure location.

9.4.1.1.b Examine logs or other documentation and interview responsible personnel at the storage location to verify that offline media backups are stored in a secure location. Customized Approach Objective Offline backups cannot be accessed by unauthorized personnel.

Modified p. 206 → 228

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time. ~~9.4.5 Inventory logs of all electronic media with cardholder data are maintained.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without careful inventory methods and storage controls, stolen or missing electronic media could go unnoticed for an indefinite amount of time.

Modified p. 208 → 230

9.4.6.a Examine the ~~periodic~~ media destruction policy to verify that procedures are defined to destroy ~~hard-copy~~ media with cardholder data when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

9.4.6.a Examine the media destruction policy to verify that procedures are defined to destroy hard- copy media with cardholder data when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

Removed p. 209

9.4.7.a Examine the periodic media destruction policy to verify that procedures are defined to destroy electronic media when no longer needed for business or legal reasons in accordance with all elements specified in this requirement.

Removed p. 210

Applicability Notes These requirements apply to deployed POI devices used in card-present transactions (that is, a payment card form factor such as a card that is swiped, tapped, or dipped). This requirement is not intended to apply to manual PAN key-entry components such as computer keyboards. This requirement is recommended, but not required, for manual PAN key-entry components such as computer keyboards. This requirement does not apply to commercial off- the-shelf (COTS) devices (for example, smartphones or tablets), which are mobile merchant-owned devices designed for mass-market distribution.

Modified p. 210 → 232

Defined Approach Requirements Defined Approach Testing Procedures Purpose Criminals attempt to steal payment card data by stealing and/or manipulating card-reading devices and terminals. Criminals will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card data every time a card is entered. ~~They will also try to add “skimming” components to the outside of devices, which are designed to capture payment …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Criminals attempt to steal payment card data by stealing and/or manipulating card-reading devices and terminals. Criminals will try to steal devices so they can learn how to break into them, and they often try to replace legitimate devices with fraudulent devices that send them payment card data every time a card is entered.

Modified p. 210 → 232

Customized Approach Objective The entity has defined procedures to protect and manage ~~point of interaction~~ devices. Expectations, controls, and oversight for the management and protection of POI devices are defined and adhered to by affected personnel.

Customized Approach Objective The entity has defined procedures to protect and manage point-of-interaction devices. Expectations, controls, and oversight for the management and protection of POI devices are defined and adhered to by affected personnel.

Removed p. 211

9.5.1.1.c Interview personnel to verify the list of POI devices is updated when devices are added, relocated, decommissioned, etc. Customized Approach Objective The identity and location of POI devices is recorded and known at all times.

Modified p. 216 → 240

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and documented. 10.2 Audit logs are implemented to support the detection of anomalies and suspicious activity, and the forensic analysis of events. 10.3 Audit logs are protected from destruction and unauthorized modifications. 10.4 Audit logs are reviewed to identify anomalies or suspicious activity. 10.5 Audit log history is retained …

Requirement 10: Log and Monitor All Access to System Components and Cardholder Data 10.1 Processes and mechanisms for logging and monitoring all access to system components and cardholder data are defined and understood.

Modified p. 216 → 240

This requirement applies to user activities, including those by employees, contractors, consultants, and internal and external vendors, and other third parties (for example, those providing support or maintenance services). ~~These requirements do not apply to user activity of consumers (cardholders). Refer to Appendix G for definitions of PCI DSS terms.~~

This requirement applies to user activities, including those by employees, contractors, consultants, and internal and external vendors, and other third parties (for example, those providing support or maintenance services).

Modified p. 217 → 240

Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 10.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 10. While it is important to define the specific policies or procedures called out in Requirement 10, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important to update policies and procedures as needed to address changes in processes, technologies, and business objectives. For this reason, consider updating …

These requirements do not apply to user activity of consumers (cardholders). Refer to Appendix G for definitions of PCI DSS terms. Defined Approach Requirements Defined Approach Testing Procedures Purpose Requirement 10.1.1 is about effectively managing and maintaining the various policies and procedures specified throughout Requirement 10. While it is important to define the specific policies or procedures called out in Requirement 10, it is equally important to ensure they are properly documented, maintained, and disseminated. Good Practice It is important …

Modified p. 219 → 243

Defined Approach Requirements Defined Approach Testing Procedures Purpose Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation. Logging and analyzing security-relevant events enable an organization to identify and trace potentially malicious activities. Good Practice When an entity considers which information to record in their logs, it …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Audit logs must exist for all system components. Audit logs send alerts the system administrator, provides data to other monitoring mechanisms, such as intrusion-detection systems (IDS) and security information and event monitoring systems (SIEM) tools, and provide a history trail for post-incident investigation.

Modified p. 219 → 243

Defined Approach Requirements Defined Approach Testing Procedures Purpose It is critical to have a process or system that links user access to system components accessed. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account to access cardholder data. ~~Good Practice A record of all individual access to cardholder data can identify which accounts may have been compromised or misused.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose It is critical to have a process or system that links user access to system components accessed. Malicious individuals could obtain knowledge of a user account with access to systems in the CDE, or they could create a new, unauthorized account to access cardholder data.

Modified p. 220 → 244

Defined Approach Requirements Defined Approach Testing Procedures Purpose Malicious individuals will often perform multiple access attempts on targeted systems. Multiple invalid ~~login attempts may be an indication of an unauthorized user’s attempts to “brute force” or guess a password.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Malicious individuals will often perform multiple access attempts on targeted systems. Multiple 10.2.1.4 Audit logs capture all invalid logical access attempts.

Modified p. 222 → 248

Defined Approach Requirements Defined Approach Testing Procedures Purpose Audit log files contain sensitive information, and read access to the log files must be limited only to those with a valid business need. This access includes audit log files on the originating systems as well as anywhere else they are stored. ~~Good Practice Adequate protection of the audit logs includes strong access control that limits access to logs based on “need to know” only and the use of physical or network …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Audit log files contain sensitive information, and read access to the log files must be limited only to those with a valid business need. This access includes audit log files on the originating systems as well as anywhere else they are stored.

Modified p. 223 → 249

Defined Approach Requirements Defined Approach Testing Procedures Purpose Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected, even if the system generating the logs becomes compromised. Writing logs from external-facing technologies such as wireless, network security controls, DNS, and mail servers, reduces the risk of those logs being lost or altered. Good Practice Each entity determines the best way to back up log files, whether via one or …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Promptly backing up the logs to a centralized log server or media that is difficult to alter keeps the logs protected, even if the system generating the logs becomes compromised.

Modified p. 229 → 256

Defined Approach Requirements Defined Approach Testing Procedures ~~Good Practice~~ Retaining historical audit logs for at least 12 months is necessary because compromises often go unnoticed for significant lengths of time. Having centrally stored log history allows investigators to better determine the length of time a potential breach was occurring, and the possible system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach. ~~Examples Methods that allow logs to …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Retaining historical audit logs for at least 12 months is necessary because compromises often go unnoticed for significant lengths of time. Having centrally stored log history allows investigators to better determine the length of time a potential breach was occurring, and the possible system(s) impacted. By having three months of logs immediately available, an entity can quickly identify and minimize impact of a data breach.

Modified p. 230 → 257

Defined Approach Requirements Defined Approach Testing Procedures Purpose Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of events, which is crucial for forensic analysis following a breach. ~~For post-incident forensics teams, the accuracy and consistency of time across all systems and the time of each activity are critical in determining how the …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Time synchronization technology is used to synchronize clocks on multiple systems. When clocks are not properly synchronized, it can be difficult, if not impossible, to compare log files from different systems and establish an exact sequence of events, which is crucial for forensic analysis following a breach.

Modified p. 232 → 260

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE. Good Practice The specific types of failures may vary, depending on the function of the device system component and technology in use. Typical failures include a system ceasing to perform its security function or not functioning in …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.

Modified p. 232 → 260

Applicability Notes This requirement applies only when the entity being assessed is a service provider. ~~This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025.~~

Applicability Notes This requirement applies only when the entity being assessed is a service provider.

Modified p. 233 → 261

Applicability Notes This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1. ~~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.~~

Applicability Notes This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.

Modified p. 235 → 264

Requirement 11: Test Security of Systems and Networks Regularly 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood. 11.2 Wireless access points are identified and monitored, and unauthorized wireless access points are addressed. 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed. 11.4 External and internal penetration testing is regularly performed, and exploitable vulnerabilities and security weaknesses are corrected. 11.5 Network intrusions and unexpected file changes are detected and responded to. …

Requirement 11: Test Security of Systems and Networks Regularly 11.1 Processes and mechanisms for regularly testing security of systems and networks are defined and understood.

Modified p. 235 → 264

Vulnerabilities are being discovered continually by malicious individuals and researchers, ~~and~~ being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment. ~~Refer to Appendix G for definitions of PCI DSS terms.~~

Vulnerabilities are being discovered continually by malicious individuals and researchers, as well as being introduced by new software. System components, processes, and bespoke and custom software should be tested frequently to ensure security controls continue to reflect a changing environment.

Modified p. 238 → 267

Defined Approach Requirements Defined Approach Testing Procedures Purpose Implementation and/or exploitation of wireless technology within a network are common paths for malicious users to gain unauthorized access to the network and cardholder data. Unauthorized wireless devices could be hidden within or attached to a computer or other system component. These devices could also be attached directly to a network port, to a network device such as a switch or router, or inserted as a wireless interface card inside a system …

Modified p. 238 → 268

~~Applicability Notes The requirement applies even when a policy exists that prohibits the use of wireless technology since attackers do not read and follow company policy.~~ Methods used to meet this requirement must be sufficient to detect and identify both authorized and unauthorized devices, including unauthorized devices attached to devices that themselves are authorized.

Methods used to meet this requirement must be sufficient to detect and identify both authorized and unauthorized devices, including unauthorized devices attached to devices that themselves are authorized.

Modified p. 241 → 270

Defined Approach Requirements Defined Approach Testing Procedures Purpose Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification. Good Practice Vulnerabilities posing the greatest risk to the environment (for example, ranked high or critical per Requirement 6.3.1) should be resolved with the highest priority. Multiple scan reports can be combined for the quarterly …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Identifying and addressing vulnerabilities promptly reduces the likelihood of a vulnerability being exploited and the potential compromise of a system component or cardholder data. Vulnerability scans conducted at least every three months provide this detection and identification.

Modified p. 241 → 270

• ~~High-risk and~~ critical ~~vulnerabilities (per~~ the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

Modified p. 241 → 270

• Rescans are performed that confirm all ~~high- risk~~ and critical vulnerabilities (as noted above) have been resolved.

• Rescans are performed that confirm all high-risk and all critical vulnerabilities (as noted above) have been resolved.

Modified p. 241 → 270

11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk and critical vulnerabilities ~~(identified~~ in PCI DSS Requirement 6.3.1) are resolved.

11.3.1.b Examine internal scan report results from each scan and rescan run in the last 12 months to verify that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) are resolved.

Modified p. 243 → 272

11.3.1.1.a Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk or critical ~~per~~ the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.

11.3.1.1.a Examine the entity’s targeted risk analysis that defines the risk for addressing all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) to verify the risk analysis was performed in accordance with all elements specified at Requirement 12.3.1.

Modified p. 243 → 272

11.3.1.1.b Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk or critical ~~per~~ the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.

11.3.1.1.b Interview responsible personnel and examine internal scan report results or other documentation to verify that all other applicable vulnerabilities (those not ranked as high-risk vulnerabilities or critical vulnerabilities according to the entity’s vulnerability risk rankings at Requirement 6.3.1) are addressed based on the risk defined in the entity’s targeted risk analysis, and that the scan process includes rescans as needed to confirm the vulnerabilities have been addressed.

Modified p. 243 → 272

Customized Approach Objective Lower ranked vulnerabilities (lower than ~~high~~ or critical) are addressed at a frequency in accordance with the entity’s risk.

Customized Approach Objective Lower ranked vulnerabilities (lower than high-risk or critical) are addressed at a frequency in accordance with the entity’s risk.

Modified p. 243 → 272

Applicability Notes The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized. ~~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.~~

Applicability Notes The timeframe for addressing lower-risk vulnerabilities is subject to the results of a risk analysis per Requirement 12.3.1 that includes (minimally) identification of assets being protected, threats, and likelihood and/or impact of a threat being realized.

Modified p. 244 → 273

11.3.1.2.c If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2. ~~Customized Approach Objective Automated tools used to detect vulnerabilities can detect vulnerabilities local to each system, which are not visible remotely.~~

11.3.1.2.c If accounts used for authenticated scanning can be used for interactive login, examine the accounts and interview personnel to verify the accounts are managed following all elements specified in Requirement 8.2.2.

Modified p. 245 → 274

• ~~High-risk and~~ critical ~~vulnerabilities (per~~ the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

• Vulnerabilities that are either high-risk or critical (according to the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved.

Modified p. 245 → 274

11.3.1.3.b Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that high-risk and critical vulnerabilities ~~as defined~~ in Requirement ~~6.3.1~~ were resolved.

11.3.1.3.b Interview personnel and examine internal scan and rescan reports to verify that internal scans were performed after significant changes and that all high-risk vulnerabilities and all critical vulnerabilities (defined in PCI DSS Requirement 6.3.1) were resolved.

Modified p. 246 → 275

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).

Modified p. 249 → 278

Defined Approach Requirements Defined Approach Testing Procedures Purpose Attackers spend a lot of time finding external and internal vulnerabilities to leverage to obtain access to cardholder data and then to exfiltrate that data. As such, entities need to test their networks thoroughly, just as an attacker would do. This testing allows the entity to identify and remediate weakness that might be leveraged to compromise the entity’s network and data, and then to take appropriate actions to protect the network and …

Modified p. 249 → 279

~~Customized Approach Objective~~ A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker.

(continued on next page) A formal methodology is defined for thorough technical testing that attempts to exploit vulnerabilities and security weaknesses via simulated attack methods by a competent manual attacker.

Modified p. 250 → 279

Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks. Testing from outside the network (or “external penetration testing”) means testing the exposed external perimeter of trusted networks, and critical systems connected to or accessible to public network infrastructures.

Applicability Notes Testing from inside the network (or “internal penetration testing”) means testing from both inside the CDE and into the CDE from trusted and untrusted internal networks.

Removed p. 251

• Specific penetration testing certifications, which may be an indication of the tester’s skill level and competence. (continued on next page) 11.4.2 Internal penetration testing is performed:

Modified p. 251 → 280

11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.2.b Interview personnel to verify that the internal penetration test was performed by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists (not required to be a QSA or ASV). Customized Approach Objective Internal system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats and ensure that significant changes do not introduce unknown vulnerabilities.

Modified p. 251 → 281

• Organizational independence of the tester exists (not required to be a QSA or ~~ASV). (continued on next page)~~ 11.4.3.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.

• Organizational independence of the tester exists (not required to be a QSA or ASV) 11.4.3.a Examine the scope of work and results from the most recent external penetration test to verify that penetration testing is performed according to all elements specified in this requirement.

Modified p. 251 → 281

11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external ~~third-party~~ and that organizational independence of the tester exists (not required to be a QSA or ASV).

11.4.3.b Interview personnel to verify that the external penetration test was performed by a qualified internal resource or qualified external third party and that organizational independence of the tester exists (not required to be a QSA or ASV).

Modified p. 252 → 281

External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.

Customized Approach Objective External system defenses are verified by technical testing according to the entity’s defined methodology as frequently as needed to address evolving and new attacks and threats, and to ensure that significant changes do not introduce unknown vulnerabilities.

Modified p. 257 → 287

Defined Approach Requirements Defined Approach Testing Procedures Purpose Intrusion-detection and/or intrusion-prevention techniques (such as IDS/IPS) compare the traffic coming into the network with known “signatures” and/or behaviors of thousands of compromise types (hacker tools, Trojans, and other malware), and then send alerts and/or stop the attempt as it happens. Without a proactive approach to detect unauthorized activity, attacks on (or misuse of) computer resources could go unnoticed for long periods of time. The impact of an intrusion into the CDE …

Modified p. 258 → 287

Mechanisms to detect real-time suspicious or anomalous network traffic that may be indicative of threat actor activity are implemented. Alerts generated by these mechanisms are responded to by personnel, or by automated means that ensure that system components cannot be compromised as a result of the detected activity.

Customized Approach Objective Mechanisms to detect real-time suspicious or anomalous network traffic that may be indicative of threat actor activity are implemented. Alerts generated by these mechanisms are responded to by personnel, or by automated means that ensure that system components cannot be compromised as a result of the detected activity.

Removed p. 260

• Additional critical files determined by entity (for example, through risk assessment or other means). Examples Change-detection solutions such as file integrity monitoring (FIM) tools check for changes, additions, and deletions to critical files, and notify when such changes are detected.

Modified p. 260 → 291

~~Applicability Notes~~ For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change- detection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change- detection mechanisms such as file integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity (that is, the merchant or service provider).

Removed p. 261

• At least once every seven days

Modified p. 261 → 292

Defined Approach Requirements Defined Approach Testing Procedures Purpose Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms. ~~Therefore, the only place to detect changes or indicators of malicious activity is in the consumer browser as the page is constructed and all JavaScript interpreted. By …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Many web pages now rely on assembling objects, including active content (primarily JavaScript), from multiple internet locations. Additionally, the content of many web pages is defined using content management and tag management systems that may not be possible to monitor using traditional change detection mechanisms.

Modified p. 261 → 292

• 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. 261 → 292

• 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. 261 → 292

~~• 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).

Modified p. 262 → 293

• Violations of the Content Security Policy (CSP) can be reported to the entity using the ~~report- to~~ or report-uri CSP directives.

• Violations of the Content Security Policy (CSP) can be reported to the entity using the report-to or report-uri CSP directives.

Modified p. 262 → 293

• Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel. ~~Often, these mechanisms are subscription or cloud-based, but can also be based on custom and bespoke solutions.~~

• Reverse proxies and Content Delivery Networks can detect changes in scripts and alert personnel.

Modified p. 262 → 293

The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the Guidance column to prevent and detect unexpected script activities. ~~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.~~

The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the Guidance column to prevent and detect unexpected script activities.

Modified p. 263 → 294

Requirement 12: Support Information Security with Organizational Policies and Programs 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current. 12.2 Acceptable use policies for end-user technologies are defined and implemented. 12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed. 12.4 PCI DSS compliance is managed. 12.5 PCI DSS scope is documented and validated. 12.6 Security awareness education is an ongoing activity. 12.7 Personnel …

Requirement 12: Support Information Security with Organizational Policies and Programs 12.1 A comprehensive information security policy that governs and provides direction for protection of the entity’s information assets is known and current.

Modified p. 263 → 294

For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors, and consultants with security responsibilities for protecting account data or that can impact the security of ~~account~~ data. ~~Refer to Appendix G for definitions of PCI DSS terms.~~

For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors, and consultants with security responsibilities for protecting account data or that can impact the security of cardholder data and/or sensitive authentication data.

Modified p. 264 → 294

Defined Approach Requirements Defined Approach Testing Procedures Purpose An organization’s overall information security policy ties to and governs all other policies and procedures that define protection of cardholder data. The information security policy communicates management’s intent and objectives regarding the protection of its most valuable assets, including cardholder data. Without an information security policy, individuals will make their own value decisions on the controls that are required within the organization which may result in the organization neither meeting its legal, …

Refer to Appendix G for definitions of PCI DSS terms. Defined Approach Requirements Defined Approach Testing Procedures Purpose An organization’s overall information security policy ties to and governs all other policies and procedures that define protection of cardholder data. The information security policy communicates management’s intent and objectives regarding the protection of its most valuable assets, including cardholder data. Without an information security policy, individuals will make their own value decisions on the controls that are required within the organization …

Removed p. 266

Defined Approach Requirements Defined Approach Testing Procedures Purpose To ensure someone with sufficient authority and responsibility is actively managing and championing the organization’s information security program, accountability and responsibility for information security needs to be assigned at the executive level within an organization. Common executive management titles for this role include Chief Information Security Officer (CISO) and Chief Security Officer (CSO

• to meet this requirement, the CSO role must be responsible for information security). These positions are often at the most senior level of management and are part of the chief executive level or C-level, typically reporting to the Chief Executive Officer or the Board of Directors. Good Practice Entities should also consider transition and/or succession plans for these key personnel to avoid potential gaps in critical security activities.

Modified p. 267 → 299

Defined Approach Requirements Defined Approach Testing Procedures Purpose End-user technologies are a significant investment and may pose significant risk to an organization if not managed properly. Acceptable use policies outline the expected behavior from personnel when using the organization’s information technology and reflect the organization’s risk tolerance These policies instruct personnel on what they can and cannot do with company equipment and instruct personnel on correct and incorrect uses of company Internet and email resources. Such policies can legally protect …

Modified p. 268 → 300

Defined Approach Requirements Defined Approach Testing Procedures Purpose Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures. This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk …

The risk analysis identifies the specific assets, such as the system components and data

•for example, log files, or credentials

•that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from

•for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat

•for example, exposure to untrusted networks, complexity of environment, …

Modified p. 268 → 300

• 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. 271 → 303

• ~~A documented strategy~~ to respond to anticipated changes in cryptographic vulnerabilities.

• Documentation of a plan, to respond to anticipated changes in cryptographic vulnerabilities.

Modified p. 271 → 303

~~Applicability Notes The requirement applies to all cryptographic suites and protocols used to meet PCI DSS requirements.~~ 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.

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.

Modified p. 273 → 305

~~Applicability Notes This requirement applies only when the entity being assessed is a service provider.~~ Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. ~~Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization.~~

Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure.

Modified p. 276 → 308

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a current list of all system components will enable an organization to define the scope of its environment and implement PCI DSS requirements accurately and efficiently. Without an inventory, some system components could be overlooked and be inadvertently excluded from the organization’s configuration standards. ~~Good Practice If an entity keeps an inventory of all assets, those system components in scope for PCI DSS should be clearly identifiable among the other assets. …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a current list of all system components will enable an organization to define the scope of its environment and implement PCI DSS requirements accurately and efficiently. Without an inventory, some system components could be overlooked and be inadvertently excluded from the organization’s configuration standards.

Modified p. 276 → 308

12.5.1.b Interview personnel to verify the inventory is kept current.

12.5.1.b Interview personnel to verify the inventory is kept current. Customized Approach Objective All system components in scope for PCI DSS are identified and known.

Modified p. 277 → 309

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.). (continued on next page) 12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.).

Modified p. 277 → 309

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, ~~card-present,~~ card-not-present, and e-commerce).

• Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card- present, card-not-present, and e-commerce).

Modified p. 278 → 310

~~• for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.~~ Further Information For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation.

Further Information For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation.

Modified p. 281 → 314

• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s ~~CDE,~~ or the information provided to personnel about their role in protecting cardholder data.

• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s cardholder data and/or sensitive authentication data, or the information provided to personnel about their role in protecting cardholder data.

Modified p. 283 → 316

~~• Where and how to report suspected phishing and social engineering activity.~~ An emphasis on reporting allows the organization to reward positive behavior, to optimize technical defenses (see Requirement 5.4.1), and to take immediate action to remove similar phishing emails that evaded technical defenses from recipient inboxes.

An emphasis on reporting allows the organization to reward positive behavior, to optimize technical defenses (see Requirement 5.4.1), and to take immediate action to remove similar phishing emails that evaded technical defenses from recipient inboxes.

Modified p. 283 → 316

Applicability Notes See Requirement 5.4.1 for guidance on the difference between technical and automated controls to detect and protect users from phishing attacks, and this requirement for providing users security awareness training about phishing and social engineering. These are two separate and distinct requirements, and one is not met by implementing controls required by the other one. ~~This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a …~~

Applicability Notes See Requirement 5.4.1 for guidance on the difference between technical and automated controls to detect and protect users from phishing attacks, and this requirement for providing users security awareness training about phishing and social engineering. These are two separate and distinct requirements, and one is not met by implementing controls required by the other one.

Modified p. 285 → 318

Defined Approach Requirements Defined Approach Testing Procedures Purpose Performing thorough screening prior to hiring potential personnel who are expected to be given access to the CDE provides entities with the information necessary to make informed risk decisions regarding personnel they hire that will have access to the CDE. Other benefits of screening potential personnel include helping to ensure workplace safety and confirming information provided by prospective employees on their resumes. Good Practice Entities should consider screening for existing personnel anytime …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Performing thorough screening prior to hiring potential personnel who are expected to be given access to the CDE provides entities with the information necessary to make informed risk decisions regarding personnel they hire that will have access to the CDE.

Modified p. 286 → 319

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface. ~~Examples Different types of TPSPs include those that:~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface.

Modified p. 286 → 319

• Could impact the security of the entity’s ~~CDE~~ (such as vendors providing support via remote access, and bespoke software developers).

• Could impact the security of the entity’s cardholder data and/or sensitive authentication data (such as vendors providing support via remote access, and bespoke software developers).

Removed p. 287

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. 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.

Modified p. 287 → 320

• 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. 289 → 324

~~Applicability Notes~~ Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.

Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.

Removed p. 292

Applicability Notes This requirement applies only when the entity being assessed is a service provider. 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.

Modified p. 292 → 327

Defined Approach Requirements Defined Approach Testing Procedures Purpose In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between TPSPs and their customers about their applicable PCI DSS responsibilities. The acknowledgment of the ~~TPSPs~~ evidences ~~their~~ commitment to maintaining proper security of account data that it obtains from its ~~clients. The method by which the TPSP provides written acknowledgment should be agreed between the provider and its~~ customers.

Defined Approach Requirements Defined Approach Testing Procedures Purpose In conjunction with Requirement 12.8.2, this requirement is intended to promote a consistent level of understanding between TPSPs and their customers about their applicable PCI DSS responsibilities. The acknowledgment from the TPSP evidences the TPSP’s commitment to maintaining proper security of the account data that it obtains from its customers.

Modified p. 293 → 329

• PCI DSS compliance status information ~~for any service the TPSP performs on behalf of customers~~ (Requirement 12.8.4).

• PCI DSS compliance status information (Requirement 12.8.4).

Modified p. 293 → 329

• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement ~~12.8.5).~~

• Information about which PCI DSS requirements are the responsibility of the TPSP and which are the responsibility of the customer, including any shared responsibilities (Requirement 12.8.5), for any service the TPSP provides that meets a PCI DSS requirement(s) on behalf of customers or that can impact security of customers’ cardholder data or sensitive authentication data.

Modified p. 295 → 331

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities. ~~Good Practice The incident response plan should be thorough and contain all the key elements for stakeholders (for example, legal, communications) to allow the entity …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without a comprehensive incident response plan that is properly disseminated, read, and understood by the parties responsible, confusion and lack of a unified response could create further downtime for the business, unnecessary public media exposure, as well as risk of financial and/or reputational loss and legal liabilities.

Modified p. 296 → 332

~~• Tested, including all elements listed in Requirement 12.10.1.~~ Customized Approach Objective The incident response plan is kept current and tested periodically.

Customized Approach Objective The incident response plan is kept current and tested periodically.

Modified p. 298 → 334

Defined Approach Requirements Defined Approach Testing Procedures Purpose Each entity’s environment and incident response plan are ~~different~~ and the approach will depend on a number of factors, including the size and complexity of the entity, the degree of change in the environment, the size of the incident response team, and the turnover in personnel. ~~Performing a risk analysis will allow the entity to determine the optimum frequency for training personnel with incident response responsibilities.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Each entity’s environment and incident response plan are different, and the approach will depend on a number of factors, including the size and complexity of the entity, the degree of change in the environment, the size of the incident response team, and the turnover in personnel.

Modified p. 302 → 339

All service providers are responsible for meeting PCI DSS requirements for their own environments as applicable to the services offered to their customers. In addition, multi-tenant service providers must meet the requirements in this Appendix. Multi-tenant service providers are a type of third-party service provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, …

Note: Even though a multi-tenant service provider may meet these requirements, each customer is still responsible to comply with the PCI DSS requirements that are applicable to its environment and validate compliance as applicable. Often, there are PCI DSS requirements for which responsibility is shared between the provider and the customer (for perhaps different aspects of the environment). Requirements 12.8 and 12.9 delineate requirements specific to the relationships between all third-party service providers (TPSPs) and their customers, and the responsibilities …

Modified p. 303 → 340

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without controls between the provider’s environment and the customer’s environment, a malicious actor within the provider’s environment could compromise the customer’s environment, and similarly, a malicious actor in a customer environment could compromise the provider and potentially other of the provider’s customers. Multi-tenant environments should be isolated from each other and from the provider’s infrastructure such that they can be separately managed entities with no connectivity between them. Good Practice Providers should …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without controls between the provider’s environment and the customer’s environment, a malicious actor within the provider’s environment could compromise the customer’s environment, and similarly, a malicious actor in a customer environment could compromise the provider and potentially other of the provider’s customers.

Modified p. 305 → 342

Applicability Notes The testing of adequate separation between customers in a multi-tenant service provider environment is in addition to the penetration tests specified in Requirement 11.4.6. ~~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.~~

Applicability Notes The testing of adequate separation between customers in a multi-tenant service provider environment is in addition to the penetration tests specified in Requirement 11.4.6.

Modified p. 306 → 343

Defined Approach Requirements Defined Approach Testing Procedures Purpose Log information is useful for detecting and troubleshooting security incidents and is invaluable for forensic investigations. Customers therefore need to have access to these logs. ~~However, log information can also be used by an attacker for reconnaissance, and so a customer’s log information must only be accessible by the customer that the log relates to.~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Log information is useful for detecting and troubleshooting security incidents and is invaluable for forensic investigations. Customers therefore need to have access to these logs.

Modified p. 309 → 347

Defined Approach Requirements Defined Approach Testing Procedures Purpose POS POI terminals used in card-present environments can continue using SSL/early TLS when it can be shown that the POS POI terminal is not susceptible to the currently known exploits. Good Practice However, SSL is outdated technology and could be susceptible to additional security vulnerabilities in the future; it is therefore strongly recommended that POS POI terminals be upgraded to a secure protocol as soon as possible. If SSL/early TLS is not …

Defined Approach Requirements Defined Approach Testing Procedures Purpose POS POI terminals used in card-present environments can continue using SSL/early TLS when it can be shown that the POS POI terminal is not susceptible to the currently known exploits.

Modified p. 309 → 347

Applicability Notes This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.1.2 and A2.1.3 apply to POS POI service providers. ~~The allowance for POS POI terminals that are not currently susceptible to exploits is based on currently known risks. If new exploits are introduced to which POS POI terminals …~~

Applicability Notes This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant. This requirement is not intended for service providers who serve as the termination or connection point to those POS POI terminals. Requirements A2.1.2 and A2.1.3 apply to POS POI service providers.

Removed p. 312

Note: Some requirements have defined timeframes (for example, at least once every three months or at least once every six months) within which certain activities are to be performed. For initial assessment to this document, it is not required that an activity has been performed for every such timeframe during the previous year, if the assessor verifies:

Modified p. 312 → 351

For subsequent years after the initial assessment, an activity must have been performed within each required ~~timeframe (for~~ example, an activity required every three months must have been performed at least four times during the previous year at an interval that does not exceed ~~90 days).~~

For subsequent years after the initial assessment, an activity must have been performed within each required timeframe. For example, an activity required at least every three months must have been performed at least four times during the previous year at an interval that does not exceed 90-92 days.

Modified p. 313 → 352

Defined Approach Requirements Defined Approach Testing Procedures Purpose Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Good Practice Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. Responsibility for the PCI DSS compliance program may be assigned to …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Executive management assignment of PCI DSS compliance responsibilities ensures executive- level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities.

Modified p. 313 → 352

• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least once every 12 months. ~~PCI DSS Reference: Requirement 12 A3.1.1.a Examine documentation to verify executive management has assigned overall accountability for maintaining the entity’s PCI DSS compliance.~~

• Providing updates to executive management and board of directors on PCI DSS compliance initiatives and issues, including remediation activities, at least once every 12 months.

Modified p. 314 → 353

~~• A process for performing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions.~~ PCI DSS Reference: Requirements 1-12 A3.1.2.a Examine information security policies and procedures to verify that processes are defined for a formal PCI DSS compliance program that includes all elements specified in this requirement.

PCI DSS Reference: Requirements 1-12 A3.1.2.a Examine information security policies and procedures to verify that processes are defined for a formal PCI DSS compliance program that includes all elements specified in this requirement.

Modified p. 315 → 354

~~• Managing business-impact analysis to determine potential PCI DSS impacts for strategic business decisions.~~ PCI DSS Reference: Requirement 12 A3.1.3.a Examine information security policies and procedures and interview personnel to verify that PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel in accordance with all elements of this requirement.

PCI DSS Reference: Requirement 12 A3.1.3.a Examine information security policies and procedures and interview personnel to verify that PCI DSS compliance roles and responsibilities are specifically defined and formally assigned to one or more personnel in accordance with all elements of this requirement.

Modified p. 316 → 355

A3.1.4 Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance responsibilities (as identified in A3.1.3). PCI DSS Reference: Requirement 12 A3.1.4.a Examine information security policies and procedures to verify that PCI DSS and/or information security training is required at least once every 12 months for each role with PCI DSS compliance responsibilities.

A3.1.4 Up-to-date PCI DSS and/or information security training is provided at least once every 12 months to personnel with PCI DSS compliance responsibilities (as identified in A3.1.3).

Removed p. 317

• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope.

Modified p. 317 → 356

Defined Approach Requirements Defined Approach Testing Procedures Purpose Frequent validation of PCI DSS scope helps to ensure PCI DSS scope remains up to date and aligned with changing business objectives, and therefore that security controls are protecting all appropriate system components. Good Practice Accurate scoping involves critically evaluating the CDE and all connected system components to determine the necessary coverage for PCI DSS requirements. Scoping activities, including careful analysis and ongoing monitoring, help to ensure that in-scope systems are appropriately …

Defined Approach Requirements Defined Approach Testing Procedures Purpose Frequent validation of PCI DSS scope helps to ensure PCI DSS scope remains up to date and aligned with changing business objectives, and therefore that security controls are protecting all appropriate system components.

Modified p. 317 → 356

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.). (continued on next page) A3.2.1 PCI DSS scope is documented and confirmed for accuracy at least once every three months and upon significant changes to the in- scope environment. At a minimum, the scoping validation includes:

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.).

Modified p. 317 → 356

• Identifying all data flows for the various payment stages (for example, authorization, capture, settlement, chargebacks, and refunds) and acceptance channels (for example, ~~card-present,~~ card-not-present, and e-commerce).

• Identifying all data flows for the various payment stages (for example, authorization, capture, settlement, chargebacks, and refunds) and acceptance channels (for example, card- present, card-not-present, and e-commerce).

Modified p. 317 → 356

~~• Identifying all connections to third-party entities with access to the CDE.~~ (continued on next page) A3.2.1.a Examine documented results of scope reviews and interview personnel to verify that the reviews are performed:

(continued on next page) A3.2.1.a Examine documented results of scope reviews and interview personnel to verify that the reviews are performed:

Modified p. 318 → 357

• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope. ~~PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12.~~

• Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.

Modified p. 318 → 357

In addition to internal systems and networks, all connections from third-party entities

•for example, business partners, entities providing remote support services, and other service providers

•need to be identified to determine inclusion for PCI DSS scope. Once the in-scope connections have been identified, the applicable PCI DSS controls can be implemented to reduce the risk of a third-party connection being used to compromise an entity’s CDE. ~~A data discovery tool or methodology can be used to facilitate identifying all sources and locations …~~

In addition to internal systems and networks, all connections from third-party entities

•for example, business partners, entities providing remote support services, and other service providers

•need to be identified to determine inclusion for PCI DSS scope. Once the in-scope connections have been identified, the applicable PCI DSS controls can be implemented to reduce the risk of a third-party connection being used to compromise an entity’s CDE.

Modified p. 318 → 357

~~• for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured.~~ Further Information Refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation for additional guidance.

Further Information Refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation for additional guidance.

Modified p. 319 → 358

~~• Documented sign-off of the results of the impact assessment by responsible personnel (as defined in A3.1.3).~~ PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 A3.2.2 Examine change documentation and interview personnel to verify that for each change to systems or networks the PCI DSS scope impact is determined, and includes all elements specified in this requirement.

PCI DSS Reference: Scope of PCI DSS Requirements; Requirements 1-12 A3.2.2 Examine change documentation and interview personnel to verify that for each change to systems or networks the PCI DSS scope impact is determined, and includes all elements specified in this requirement.

Removed p. 320

• for example, file integrity monitoring, anti-malware, patches, and audit logging.

Modified p. 320 → 359

• Systems are protected with required controls

• Systems are protected with required controls •for example, file integrity monitoring, antimalware, patches, and audit logging.

Modified p. 320 → 359

• Sensitive authentication data is not stored, and ~~that~~ all account data storage is documented and incorporated into data-retention policy and procedures.

• Sensitive authentication data is not stored, and all account data storage is documented and incorporated into data-retention policy and procedures.

Modified p. 320 → 359

~~A3.2.2.1 Upon completion of a change, all relevant PCI DSS requirements are confirmed to be implemented on all new or changed systems and networks, and documentation is updated as applicable.~~ PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 Examine change records and the affected systems/networks, and interview personnel to verify that all relevant PCI DSS requirements were confirmed to be implemented and documentation updated as part of the change.

PCI DSS Reference: Scope of PCI DSS Requirements; Requirement 1-12 A3.2.2.1 Examine change records and the affected systems/networks, and interview personnel to verify that all relevant PCI DSS requirements were confirmed to be implemented and documentation updated as part of the change.

Modified p. 321 → 360

A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls. PCI DSS Reference: Requirement 12 A3.2.3 Examine policies and procedures to verify that a change to organizational structure results in formal a review of the impact on PCI DSS scope and applicability of controls.

A3.2.3 Changes to organizational structure result in a formal (internal) review of the impact to PCI DSS scope and applicability of controls.

Modified p. 322 → 361

• The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate the CDE from all out- of-scope systems. ~~PCI DSS Reference: Requirement 11 A3.2.4 Examine the results from the most recent penetration test to verify that the test was conducted in accordance with all elements specified in this requirement.~~

• The penetration testing verifies that segmentation controls/methods are operational and effective, and isolate the CDE from all out- of-scope systems.

Modified p. 323 → 362

~~• helps to ensure that previously unknown locations of cleartext PAN are detected and properly secured. Examples~~ A data-discovery process can be performed via a variety of methods, including, but not limited to 1) commercially available data-discovery software, 2) an in-house developed data-discovery program, or 3) a manual search. A combination of methodologies may also be used as needed. ~~Regardless of the method used, the goal of the effort is to find all sources and locations of cleartext PAN (not …~~

A data-discovery process can be performed via a variety of methods, including, but not limited to 1) commercially available data-discovery software, 2) an in-house developed data-discovery program, or 3) a manual search. A combination of methodologies may also be used as needed.

Modified p. 323 → 362

~~• Addresses the potential for cleartext PAN to reside on systems and networks outside the currently defined CDE.~~ PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine the documented data-discovery methodology to verify it includes all elements specified in this requirement.

PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.a Examine the documented data-discovery methodology to verify it includes all elements specified in this requirement.

Modified p. 324 → 363

• The effectiveness of data-discovery methods is confirmed at least once every 12 months. ~~PCI DSS Reference: Scope of PCI DSS Requirements A3.2.5.1.a Interview personnel and review documentation to verify:~~

• The effectiveness of data-discovery methods is confirmed at least once every 12 months.

Modified p. 326 → 365

~~• Generating audit logs and alerts upon detection of cleartext PAN leaving the CDE via an unauthorized channel, method, or process.~~ PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12 A3.2.6.a Examine documentation and observe implemented mechanisms to verify that the mechanisms are in accordance with all elements specified in this requirement.

PCI DSS Reference: Scope of PCI DSS Requirements, Requirement 12 A3.2.6.a Examine documentation and observe implemented mechanisms to verify that the mechanisms are in accordance with all elements specified in this requirement.

Modified p. 327 → 366

~~• Procedures for remediating data leaks or process gaps, as necessary, to prevent any data loss.~~ PCI DSS Reference: Requirement 12 A3.2.6.1.a Examine documented response procedures to verify that procedures for responding to the attempted removal of cleartext PAN from the CDE via an unauthorized channel, method, or process include all elements specified in this requirement:

PCI DSS Reference: Requirement 12 A3.2.6.1.a Examine documented response procedures to verify that procedures for responding to the attempted removal of cleartext PAN from the CDE via an unauthorized channel, method, or process include all elements specified in this requirement:

Modified p. 328 → 367

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without formal processes for the prompt (as soon as possible) detection, alerting, and addressing of critical security control failures, failures may go undetected or remain unresolved for extended periods. In addition, without formalized time- bound processes, attackers will have ample time to compromise systems and steal account data from the CDE. ~~Good Practice The specific types of failures may vary, depending on the function of the device system component and technology in …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Without formal processes for the prompt (as soon as possible) detection, alerting, and addressing of critical security control failures, failures may go undetected or remain unresolved for extended periods. In addition, without formalized time- bound processes, attackers will have ample time to compromise systems and steal account data from the CDE.

Modified p. 328 → 367

~~• Automated code review tools (if used). This bullet is a best practice until its effective date; refer to Applicability Notes below for details.~~ PCI DSS Reference: Requirements 1-12 A3.3.1.a Examine documented policies and procedures to verify that processes are defined to promptly detect, alert, and address critical security control failures in accordance with all elements specified in this requirement.

PCI DSS Reference: Requirements 1-12 A3.3.1.a Examine documented policies and procedures to verify that processes are defined to promptly detect, alert, and address critical security control failures in accordance with all elements specified in this requirement.

Modified p. 329 → 368

~~A3.3.1.2~~ Failures of any critical security control systems are responded to promptly. Processes for responding to failures in security control systems include:

A3.3.1.1 Failures of any critical security control systems are responded to promptly. Processes for responding to failures in security control systems include:

Modified p. 329 → 368

~~• Resuming monitoring of security controls.~~ PCI DSS Reference: Requirements 1-12 ~~A3.3.1.2.a~~ Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond promptly to a security control failure in accordance with all elements specified in this requirement.

PCI DSS Reference: Requirements 1-12 A3.3.1.1.a Examine documented policies and procedures and interview personnel to verify processes are defined and implemented to respond promptly to a security control failure in accordance with all elements specified in this requirement.

Modified p. 329 → 368

~~A3.3.1.2.b~~ Examine records to verify that security control failures are documented to include:

A3.3.1.1.b Examine records to verify that security control failures are documented to include:

Modified p. 330 → 369

A3.3.2 Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the organization’s PCI DSS requirements. ~~PCI DSS Reference: Requirements 2, 6, 12.~~

A3.3.2 Hardware and software technologies are reviewed at least once every 12 months to confirm whether they continue to meet the organization’s PCI DSS requirements.

Modified p. 331 → 370

~~• Retention of records and documentation for at least 12 months, covering all BAU activities.~~ PCI DSS Reference: Requirements 1-12 A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities in accordance with all elements specified in this requirement.

PCI DSS Reference: Requirements 1-12 A3.3.3.a Examine policies and procedures to verify that processes are defined for reviewing and verifying BAU activities in accordance with all elements specified in this requirement.

Modified p. 332 → 371

Defined Approach Requirements Defined Approach Testing Procedures Purpose Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access. ~~This review provides another opportunity to ensure that accounts for all terminated users have been removed (if any were missed at the time of termination), as well as to …~~

Defined Approach Requirements Defined Approach Testing Procedures Purpose Regular review of access rights helps to detect excessive access rights remaining after user job responsibilities change, system functions change, or other modifications. If excessive user rights are not revoked in due time, they may be used by malicious users for unauthorized access.

Modified p. 332 → 371

A3.4.1 User accounts and access privileges to in- scope system components are reviewed at least once every six months to ensure user accounts and access privileges remain appropriate based on job function, and that all access is authorized. ~~PCI DSS Reference: Requirement 7 A3.4.1 Interview responsible personnel and examine supporting documentation to verify that:~~

A3.4.1 User accounts and access privileges to in- scope system components are reviewed at least once every six months to ensure user accounts and access privileges remain appropriate based on job function, and that all access is authorized.

Modified p. 333 → 372

~~• Response to alerts in accordance with documented response procedures.~~ PCI DSS Reference: Requirements 10, 12 A3.5.1.a Examine documentation and interview personnel to verify a methodology is defined and implemented to identify attack patterns and undesirable behavior across systems in a prompt manner, and includes all elements specified in this requirement.

PCI DSS Reference: Requirements 10, 12 A3.5.1.a Examine documentation and interview personnel to verify a methodology is defined and implemented to identify attack patterns and undesirable behavior across systems in a prompt manner, and includes all elements specified in this requirement.

Modified p. 334 → 373

Note: All compensating controls must be reviewed and validated for sufficiency by the assessor who conducts the PCI DSS assessment. The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. Entities should be aware that a given compensating control will not be effective in all environments. a. Existing PCI DSS requirements CANNOT be considered as compensating controls if they are …

a) Existing PCI DSS requirements CANNOT be considered as compensating controls if they are already required for the item under review. For example, passwords for non-console administrative access must be sent encrypted to mitigate the risk of intercepting cleartext administrative passwords. An entity cannot use other PCI DSS password requirements (intruder lockout, complex passwords, etc.) to compensate for lack of encrypted passwords, since those other password requirements do not mitigate the risk of interception of cleartext passwords. Also, the other …

Removed p. 337

 Perform and document a targeted risk analysis (PCI DSS Requirement 12.3.2) for each customized control, including all information specified in the Targeted Risk Analysis Template in Appendix E2.

Modified p. 337 → 376

 Document and maintain evidence about each customized control, including all information specified in the Controls Matrix Template in ~~Appendix E1.~~

 Document and maintain evidence about each customized control, including all information specified in the Controls Matrix Template in PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website  Perform and document a targeted risk analysis (PCI DSS Requirement 12.3.2) for each customized control, including all information specified in the Targeted Risk Analysis Template in PCI DSS v4.x: Sample Templates to Support Customized Approach on the PCI SSC website.

Removed p. 339

E1 Sample Controls Matrix Template The following is a sample controls matrix template that an entity may use to document their customized implementation.

As described in Appendix D: Customized Approach, entities using the customized approach must complete a controls matrix to provide details for each implemented control that explain what is implemented, how the entity has determined that the controls meet the stated objective of a PCI DSS requirement, how the control provides at least the equivalent level of protection as would be achieved by meeting the defined requirement, and how the entity has assurance about the effectiveness of the control on an ongoing basis.

The assessor uses the information within each controls matrix to plan and prepare for the assessment.

This sample controls matrix template includes the minimum information to be documented by the entity and provided to the assessor for a customized validation. While it is not required that this specific …

Removed p. 340

Entity describes how the implemented control(s) meets the stated Customized Approach Objective of the PCI DSS requirement.

<Entity describes how the control meets the stated customized approach objective of the PCI DSS requirement, and summarizes related results> Entity describes testing it performed and the results of that testing that demonstrates the control(s) meets the objective of the applicable requirement.

<Entity describes the testing it performed to prove the control meets the stated objective of the PCI DSS requirement, and summarizes related results> Entity briefly describes the results of the separate targeted risk analysis it performed that explains the control(s) implemented and describes how the results verify the control(s) provides at least an equivalent level of protection as the defined approach for the applicable PCI DSS requirement. See the separate Targeted Risk Analysis Template for details on how to document this risk analysis.

Removed p. 341

<Entity describes how it ensures the control is maintained and how the control's effectiveness is assured.> E2 Sample Targeted Risk Analysis Template The following is a sample targeted risk analysis template an entity may use for their customized implementation. While it is not required that an entity follow this specific format, its customized approach documentation must include all the information defined in this template.

As described in Appendix D: Customized Approach and in accordance with PCI DSS Requirement 12.3.2, an entity using the customized approach must provide a detailed targeted risk analysis for each requirement the entity is meeting with the customized approach. The risk analysis defines the risk, evaluates the effect on security if the defined requirement is not met, and describes how the entity has determined that the controls provide at least an equivalent level of protection as provided by the defined PCI DSS requirement.

The assessor uses the information …

Removed p. 343

3. Analyze any changes to the LIKELIHOOD of the mischief occurring, leading to a breach in confidentiality of cardholder data 3.1 Describe the factors detailed in the Control Matrix that affect the likelihood of the mischief occurring.

• How successful the controls will be at preventing the mischief

• How the controls detailed in the Control Matrix reduce the likelihood of the mischief occurring 3.2 Describe the reasons the mischief may still occur after the application of the customized control.

• The typical reasons for the control to fail, the likelihood of this, and how could it be prevented

• How resilient the entity’s processes and systems are for detecting that the control(s) are not operating normally?

• How a threat actor could bypass this control

• what steps would they need to take, how hard is it, would the threat actor be detected before the control failed? How has this been determined?

Removed p. 343

• The justification for the assessment documented at 3.3.

• The criteria and values used for the assessment documented at 3.3.

4. Analyze any changes to the IMPACT of unauthorized access to account data 4.1 For the scope of system components that this solution covers what volume of account data would be at risk of unauthorized access if the solution failed? 4.1.1 Number of stored PANs Maximum at any one time 4.1.2 Number of PANs processed or transmitted over a 12-month period 4.2 Description of how the customized controls will directly:

• Reduce the number of individual PANs compromised if a threat actor is successful, and/or

• Allow quicker notification of the PANs compromised to the card brands.

Impact to the payment ecosystem is directly related to the number of accounts compromised and how quickly any compromised PANs can be blocked by the card issuer. Entity describes how the customized controls achieve the following if …

Removed p. 345

PCI DSS requirements/objectives apply as usual. Software developed and maintained in accordance with the Secure SLC Standard may support the customized approach for Requirement 6.3 objectives. While use of software developed and maintained in accordance with the Secure SLC Standard provides assurance that the vendor makes security patches and software updates available in a timely manner, the entity retains responsibility for ensuring that patches and updates are installed in accordance with PCI DSS requirements.

Modified p. 346 → 380

PCI DSS Requirements How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure Software How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure SLC Standard ~~6.4 Public-facing web applications~~ are ~~protected against attacks.~~

PCI DSS Requirements How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure Software How PCI DSS Requirements Apply to Software Developed and Maintained in Accordance with the Secure SLC Standard 6.3 Security vulnerabilities are identified and addressed.

Modified p. 348 → 383

~~Administrative Access Elevated or increased privileges granted to an account for that account to manage systems, networks, and/or applications.~~ Administrative access can be assigned to an individual’s account or a built-in system account. Accounts with administrative access are often referred to as “superuser,” “root,” “administrator,” “admin,” “sysadmin,” or “supervisor-state,” depending on the particular operating system and organizational structure.

Administrative access can be assigned to an individual’s account or a built-in system account. Accounts with administrative access are often referred to as “superuser,” “root,” “administrator,” “admin,” “sysadmin,” or “supervisor-state,” depending on the particular operating system and organizational structure.

Removed p. 349

Cardholder Customer to which a payment card is issued to or any individual authorized to use the payment card.

Modified p. 349 → 384

• Something you know, such as a password or ~~passphrase~~

• Something you know, such as a password or passphrase,

Modified p. 349 → 384

• Something you have, such as a token device or smart ~~card~~

• Something you have, such as a token device or smart card,

Modified p. 349 → 384

~~• Something you are, such as a biometric element.~~ The ID (or account) and authentication factor together are considered authentication ~~credentials.”~~ See Account and Authentication Credential.

The ID (or account) and authentication factor together are considered authentication credentials. See Account and Authentication Credential.

Modified p. 349 → 384

Authorization In the context of access control, authorization is the granting of access or other rights to a user, program, or process. Authorization defines what an individual or program can do after successful authentication. ~~In the context of a payment card transaction, authorization refers to the authorization process, which completes when a merchant receives a transaction response (for example, an approval or decline).~~

Authorization In the context of access control, authorization is the granting of access or other rights to a user, program, or process. Authorization defines what an individual or program can do after successful authentication.

Modified p. 349 → 384

BAU Acronym for “Business as Usual.” Bespoke and Custom Software Bespoke software is developed for the entity by a third party on the entity’s behalf and per the entity’s specifications. ~~Custom software is developed by the entity for its own use.~~

BAU Acronym for “Business as Usual.” Bespoke and Custom Software Bespoke software is developed for the entity by a third party on the entity’s behalf and per the entity’s specifications.

Modified p. 349 → 385

Cardholder Data (CHD) At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code. ~~See Sensitive Authentication Data for additional data elements that might be transmitted or processed (but not stored) as part of a payment transaction.~~

Cardholder Data (CHD) At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code.

Modified p. 350 → 385

• The system components, people, and processes that store, process, or transmit cardholder data or sensitive authentication ~~data and/or~~

• The system components, people, and processes that store, process, or transmit cardholder data and/or sensitive authentication data, and,

Modified p. 351 → 386

• An exchange agreement of a shared secret. ~~See Strong Cryptography.~~

• An exchange agreement of a shared secret.

Modified p. 351 → 387

Data-Flow Diagram A diagram showing how data flows through an ~~application, system, or network.~~

Data-Flow Diagram A diagram showing how and where data flows through an entity’s applications, systems, networks, and to/from external parties.

Modified p. 352 → 388

Entity ~~Term~~ used to represent the corporation, organization, or business which is undergoing ~~a PCI DSS~~ assessment.

Entity In the context of a PCI DSS assessment, a term used to represent the corporation, organization, or business which is undergoing an assessment.

Modified p. 353 → 388

FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data from one computer to another through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords and file contents are sent unprotected and in ~~clear text.~~ FTP can be implemented securely via SSH or other technology.

FTP Acronym for “File Transfer Protocol.” Network protocol used to transfer data from one computer to another through a public network such as the Internet. FTP is widely viewed as an insecure protocol because passwords and file contents are sent unprotected and in cleartext. FTP can be implemented securely via SSH or other technology.

Modified p. 353 → 389

Interactive Login The process of an individual providing authentication credentials to directly log into an application or system account.

Interactive Login The process of an individual providing authentication credentials to directly log into an application or system account. Using interactive login means there is no accountability or traceability of actions taken by that individual.

Modified p. 354 → 390

Masking Method of concealing a segment of PAN when displayed or printed. Masking is used when there is no business need to view the entire PAN. Masking relates to protection of PAN when displayed on screens, paper receipts, printouts, etc. ~~See Truncation for protection of PAN when electronically stored, processed, or transmitted.~~

Masking Method of concealing a segment of PAN when displayed or printed. Masking is used when there is no business need to view the entire PAN. Masking relates to protection of PAN when displayed on screens, paper receipts, printouts, etc.

Modified p. 354 → 390

Merchant For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any PCI SSC Participating Payment Brand as payment for goods and/or services. A merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant …

A merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers.

Modified p. 356 → 392

Payment Page A web-based user interface containing one or more form elements intended to capture account data from a consumer or submit captured account ~~data.~~ The payment page can be rendered as any one of:

Payment Page A web-based user interface containing one or more form elements intended to capture account data from a consumer or submit captured account data, for purposes of processing and authorizing payment transactions. The payment page can be rendered as any one of:

Modified p. 356 → 393

PCI DSS Acronym for “Payment Card Industry Data Security Standard.” Personnel Full-time and part-time employees, temporary employees, contractors, and consultants with security responsibilities for protecting account data or that can impact the security of ~~account~~ data.

PCI DSS Acronym for “Payment Card Industry Data Security Standard.” Personnel Full-time and part-time employees, temporary employees, contractors, and consultants with security responsibilities for protecting account data or that can impact the security of cardholder data and/or sensitive authentication data. See Visitor.

Removed p. 357

QSA Acronym for “Qualified Security Assessor.” QSAs are qualified by PCI SSC to perform PCI DSS on-site assessments. Refer to the QSA Qualification Requirements for details about requirements for QSA Companies and Employees.

Modified p. 358 → 395

Sensitive Authentication Data (SAD) Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card ~~validation~~ verification ~~codes/values,~~ full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.

Sensitive Authentication Data (SAD) Security-related information used to authenticate cardholders and/or authorize payment card transactions. This information includes, but is not limited to, card verification codes, full track data (from magnetic stripe or equivalent on a chip), PINs, and PIN blocks.

Modified p. 358 → 395

Service Provider Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This includes payment gateways, payment service providers (PSPs), and independent sales organizations (ISOs). This also includes companies that provide services that control or could impact the security of ~~cardholder data.~~ Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities. ~~If an entity …~~

Service Provider Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data (CHD) and/or sensitive authentication data (SAD) on behalf of another entity. This includes payment gateways, payment service providers (PSPs), and independent sales organizations (ISOs). This also includes companies that provide services that control or could impact the security of CHD and/or SAD. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting …

Modified p. 359 → 396

System Components Any network devices, servers, computing devices, virtual components, or software included in or connected to the CDE, or that could impact the security of ~~the CDE.~~

System Components Any network devices, servers, computing devices, virtual components, or software included in or connected to the CDE, or that could impact the security of cardholder data and/or sensitive authentication data.

Modified p. 360 → 397

Truncation Method of rendering a full PAN unreadable by removing a segment of PAN data. Truncation relates to protection of PAN when electronically stored, processed, or transmitted. ~~See Masking for protection of PAN when displayed on screens, paper receipts, etc.~~

Truncation Method of rendering a full PAN unreadable by removing a segment of PAN data. Truncation relates to protection of PAN when electronically stored, processed, or transmitted.

Document Comparison

Content Changes