The impact of the new PCI 4.0 on the former 3.2.1 requirement 12 is in the form of: Reformulation, amendments, merges, moves and removals.

Terminology:

• The term service provider is replaced by "third-party service providers (TPSPs)"
• The term "annually" is replaced by "once every 12 months"
• The term “system breach” is replaced by “compromise” 
• The term “alerts” is replaced by by “suspected or confirmed security incidents.” 
• The term “system breach” is replaced by “suspected or confirmed security incidents.” 

New controls: 13 new controls
4.0 - 12.3.1 requires to perform a targeted risk analysis for any PCI DSS requirement that provides flexibility for how frequently it is performed. 
4.0 - 12.3.2 Requires entities using a Customized Approach to perform a targeted risk analysis for each PCI DSS requirement that the entity meets with the customized approach. 
4.0 - 12.3.3 Requires to document and review cryptographic cipher suites and protocols in use at least once every 12 months. 
4.0 - 12.3.4 - Requires to review hardware and software technologies in use at least once every 12 months. 
4.0 - 12.5.2 Requires to document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. 
4.0 - 12.5.2.1 Requires service providers to document and confirm PCI DSS scope at least once every six months and upon significant change to the in-scope environment. 
4.0 - 12.5.3 - Requires service providers for a documented review of the impact to PCI DSS scope and applicability of controls upon significant changes to organizational structure. 
4.0 - 12.6. 2 Requires to review and update the security awareness program at least once every 12 months. 
4.0 - 12.6.3.1 Requires security awareness trainings to include awareness of threats and vulnerabilities that could impact the security of the CDE. 
4.0 - 12.6.3.2 Requires security awareness trainings to include awareness about the acceptable use of end- user technologies in accordance with Requirement 12.2.1. 
4.0 - 12.9.2 Requires service providers to support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5. 
4.0 - 12.10.4.1 Requires to perform a targeted risk analysis to define the frequency of periodic training for incident response personnel. 
4.0 - 12.10.7 Requires incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected. 

Amendements
4.0 - 12.1.3 Beside defining information security roles and responsibilities for all personnel, this requirement adds that all personnel be aware and acknowledge their information security responsibilities. 
4.0 - 12.6.1 This requirement asks that the implemented security awareness program informs all personnel of their role in protecting the cardholder data beside making them aware of the entity’s information security policy and procedures.
4.0 - 12.6.3 Regarding the delivery of security awareness trainings, this requirement adds the use of Multiple methods of communication are used. 
4.0 - 12.8.5 This requirements asks for a list of PCI DSS requirements shared between the TPSP and the entity, beside the list managed by the entity and managed by the TPSP.
4.0 - 12.10.1 Regarding the content of the incident response plan, this requirement asks for Incident response procedures with specific containment and mitigation activities for different types of incidents. 
4.0 - 12.10.5 Regarding the incident response plan and alerts from security monitoring systems, this requirement asks to monitor change-detection mechanisms for critical files and the change-and tamper-detection mechanism for payment pages. 
4.0 - 12.4.2 Regarding the periodic reviews that service providers have to perform to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures, this requirement asks that those review be performed by personnel other than those responsible for performing the given task and include Configuration reviews for network security controls. 
4.0 - 12.4.2.1 This requirement asks that the conclusions of the periodic review performed by the service providers document remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2.

Removed:
3.2.1 - 12.2 Implement a risk-assessment process that: 

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), 
• Identifies critical assets, threats, and vulnerabilities, and 
• Results in a formal, documented analysis of risk. 

3.2.1 - 12.3 Develop usage policies for critical technologies and define proper use of : 

• 3.2.1 - 12.3.2 Authentication for use of the technology 
• 3.2.1 - 12.3.3 A list of all such devices and personnel with access 
• 3.2.1 - 12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices)
• 3.2.1 - 12.3.6 Acceptable network locations for the technologies 
• 3.2.1 - 12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity 
• 3.2.1 - 12.3.9 Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use

3.2.1 - 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. 
3.2.1 - 12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data
3.2.1 - 12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach. 

Moved: 
3.2.1 - 2.4 Requirement for maintaining an inventory of system components that are in scope for PCI DSS is Moved to 12.5.1
3.2.1 - 11.1.2 Requirement for implementing incident response procedures in the event unauthorized wireless access points are detected is moved to 4.0 - 12.10.5
3.2.1 - 11.5.1 Requirement for Implementing a process to respond to any alerts generated by the change- detection solution is moved to 4.0 - 12.10.5

​Title:
3.2.1 - Maintain a policy that addresses information security for all personnel. 
4.0 - Support Information Security with Organizational Policies and Programs

3.2.1 - 12.1 Establish, publish, maintain, and disseminate a security policy. 
Change: Reformulation

4.0 - 12.1.1 An overall information security policy is: 
Established. 

• Published. 
• Maintained. 
• Disseminated to all relevant personnel, as well as to relevant vendors and business partners. 

3.2.1 - 12.1.1 Review the security policy at least annually and update the policy when the environment changes. 
Change: Reformulation

4.0 - 12.1.2 The information security policy is: 

• Reviewed at least once every 12 months. 
• Updated as needed to reflect changes to business objectives or risks to the environment. 

3.2.1 - 12.2 Implement a risk-assessment process that: 

• Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.), 
• Identifies critical assets, threats, and vulnerabilities, and 
• Results in a formal, documented analysis of risk. 

Change: Removal ​

3.2.1 - 12.3 Develop usage policies for critical technologies and define proper use of these technologies. 
3.2.1 - 12.3.1 Explicit approval by authorized parties 
3.2.1 - 12.3.2 Authentication for use of the technology  - Removed
3.2.1 - 12.3.3 A list of all such devices and personnel with access - Removed
3.2.1 - 12.3.4 A method to accurately and readily determine owner, contact information, and purpose (for example, labeling, coding, and/or inventorying of devices) - Removed
3.2.1 - 12.3.5 Acceptable uses of the technology 
3.2.1 - 12.3.6 Acceptable network locations for the technologies - Removed
3.2.1 - 12.3.7 List of company-approved products 
3.2.1 - 12.3.8 Automatic disconnect of sessions for remote-access technologies after a specific period of inactivity - Removed
3.2.1 - 12.3.9 Activation of remote-access technologies for vendors and business partners only when needed by vendors and business partners, with immediate deactivation after use - Removed
Change:  Reformulation + Removal + Merge

4.0 - 12.2.1 Acceptable use policies for end-user technologies are documented and implemented, including: 

• Explicit approval by authorized parties.
• Acceptable uses of the technology. 
• List of products approved by the company for employee use, including hardware and software. ​

​3.2.1 - 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. 
Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements. 
Change: Removal and replacement by the NEW 4.0 - 3.4.2

4.0 - 3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need. 
Change: NEW to replace 3.2.1 - 12.3.10

3.2.1 - 12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel. 
Change: Reformulation + amendement

4.0 - 12.1.3 The security policy clearly defines information security roles and responsibilities for all personnel, and all personnel are aware of and acknowledge their information security responsibilities. ​

​3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS.
Change : Move under 12.5 

4.0 - 12.5.1 An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.

​3.2.1 - 12.4.1 Additional requirement for service providers only: Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include: 

• Overall accountability for maintaining PCI DSS compliance 
• Defining a charter for a PCI DSS compliance program and communication to executive management 

Change: Reformulation

4.0 - 12.4.1 Additional requirement for service providers only: Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include: 

• Overall accountability for maintaining PCI DSS compliance. 
• Defining a charter for a PCI DSS compliance program and communication to executive management. 

​3.2.1 - 12.5 Assign to an individual or team the following information security management responsibilities: 
3.2.1 - 12.5.1 Establish, document, and distribute security policies and procedures. 
3.2.1 - 12.5.2 Monitor and analyze security alerts and information, and distribute to appropriate personnel. 
3.2.1 - 12.5.3 Establish, document, and distribute security incident response and escalation procedures to ensure timely and effective handling of all situations. 
3.2.1 - 12.5.4 Administer user accounts, including additions, deletions, and modifications. 
3.2.1 - 12.5.5 Monitor and control all access to data. 
Change: Reformulate +merge in a more global perspective

4.0 - 12.1.4 Responsibility for information security is formally assigned to a Chief Information Security Officer or other information security knowledgeable member of executive management. 

​3.2.1 - 12.6 Implement a formal security awareness program to make all personnel aware of the cardholder data security policy and procedures. 
Change: Reformulation + amendement

4.0 - 12.6.1 A formal security awareness program is implemented to make all personnel aware of the entity’s information security policy and procedures and their role in protecting the cardholder data. 

3.2.1 - 12.6.1 Educate personnel upon hire and at least annually. 
3.2.1 - 12.6.2 Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures. 
Change: Reformulate + merge + amendement

4.0 - 12.6.3 Personnel receive security awareness training as follows: 

• Upon hire and at least once every 12 months. 
• Multiple methods of communication are used. 
• Personnel acknowledge at least once every 12 months that they have read and understood the information security policy and procedures. 

​3.2.1 - 12.7 Screen potential personnel prior to hire to minimize the risk of attacks from internal sources. (Examples of background checks include previous employment history, criminal record, credit history, and reference checks.) 
Change: Reformulation

4.0 - 12.7.1 Potential personnel who will have access to the CDE are screened, within the constraints of local laws, prior to hire to minimize the risk of attacks from internal sources. 

3.2.1 - 12.8 Maintain and implement policies and procedures to manage service providers with whom cardholder data is shared, or that could affect the security of cardholder data, as follows: 
Change: Removal

3.2.1 - 12.8.1 Maintain a list of service providers including a description of the service provided. 
Change: Reformulation + Clarification

4.0 - 12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided. ​

3.2.1 - 12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment. 
Change: Reformulation + clarification

4.0 - 12.8.2 Written agreements with TPSPs are maintained as follows: 

• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE. 
• 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. 

​3.2.1 - 12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. 
Change: reformulation

4.0 - 12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement. 

​3.2.1 - 12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. 
Change: Reformulation

4.0 - 12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months. 

3.2.1 - 12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. 
Change: Reformulation + amendement

4.0 - 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.

​3.2.1 - 12.9 Additional requirement for service providers only: Service providers acknowledge in writing to customers that they are responsible for the security of cardholder data the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment. 
Change: Reformulation

4.0 - 12.9.1 Additional requirement for service providers only: TPSPs acknowledge in writing to customers that they are responsible for the security of account data the TPSP possesses or otherwise stores, processes, or transmits on behalf of the customer, or to the extent that they could impact the security of the customer’s CDE. 

3.2.1 - 12.10 Implement an incident response plan. Be prepared to respond immediately to a system breach. 
Change: Removed

3.2.1 - 12.10.1 Create the incident response plan to be implemented in the event of system breach. Ensure the plan addresses the following, at a minimum: 

• Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum 
• Specific incident response procedures 
• Business recovery and continuity 
  procedures 
• Data backup processes 
• Analysis of legal requirements for reporting compromises 
• Coverage and responses of all critical system components 
• Reference or inclusion of incident response procedures from the payment brands. 

Change: Reformulation + Amendement

4.0 - 12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to: 

• Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum. 
• Incident response procedures with specific containment and mitigation activities for different types of incidents. 
• Business recovery and continuity procedures. 
• Data backup processes. 
• Analysis of legal requirements for reporting compromises. 
• Coverage and responses of all critical system components. 
• Reference or inclusion of incident response procedures from the payment brands. 

3.2.1 - 12.10.2 Review and test the plan, including all elements listed in Requirement 12.10.1, at least annually. 
Change: Reformulate

4.0 - 12.10.2 At least once every 12 months, the security incident response plan is: 

• Reviewed and the content is updated as needed. 
• Tested, including all elements listed in Requirement 12.10.1. 

​3.2.1 - 12.10.3 Designate specific personnel to be available on a 24/7 basis to respond to alerts. 
Change: Reformulation

4.0 - 12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents. 

​3.2.1 - 12.10.4 Provide appropriate training to staff with security breach response responsibilities. 
Change: Reformulation + amendement

4.0 - 12.10.4 Personnel responsible for responding to suspected and confirmed security incidents are appropriately and periodically trained on their incident response responsibilities. 

3.2.1 - 12.10.5 Include alerts from security monitoring systems, including but not limited to intrusion-detection, intrusion-prevention, firewalls, and file-integrity monitoring systems. 
3.2.1 - 11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected. 
3.2.1 - 11.5.1 Implement a process to respond to any alerts generated by the change- detection solution. 
Change: Reformulation + Move + Merge + amendement

4.0 - 12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to: 

• Intrusion-detection and intrusion-prevention systems. 
• Network security controls. 
• Change-detection mechanisms for critical files. 
• The change-and tamper-detection mechanism for payment pages.
• Detection of unauthorized wireless access points. 

​3.2.1 - 12.10.6 Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments. 
Change: Reformulate

4.0 - 12.10.6 The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments. 

3.2.1 - 12.11 Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes: 

• Daily log reviews 
• Firewall rule-set reviews 
• Applying configuration standards to new systems 
• Responding to security alerts 
• Change management processes 

Change: Reformulation + amendement

4.0 - 12.4.2 Additional requirement for service providers only: Reviews are performed at least once every three monthsto confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks: 

• Daily log reviews. 
• Configuration reviews for network security controls. 
• Applying configuration standards to new systems. 
• Responding to security alerts. 
• Change-management processes. 

3.2.1 - 12.11.1 Additional requirement for service providers only: Maintain documentation of quarterly review process to include: 

• Documenting results of the reviews 
• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program 

Change: Reformulation + amendement

4.0 - 12.4.2.1 Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented to include: 

• Results of the reviews. 
• Documented remediation actions taken for any tasks that were found to not be performed at Requirement 12.4.2. 
• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program. 

​

3.2.1 - NONE
Change NEW
​
4.0 - 12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes: 

• Identification of the assets being protected. 
• Identification of the threat(s) that the requirement is protecting against. 
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized. 
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized. 
• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed. 
• Performance of updated risk analyses when needed, as determined by the annual review. 

3.2.1 - NONE
Change NEW
​
4.0 - 12.3.2 A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include: 

• Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis). 
• Approval of documented evidence by senior management. 
• Performance of the targeted analysis of risk at least once every 12 months. 

3.2.1 - NONE
Change NEW
​
4.0 - 12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following: 

• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used. 
• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use. 
• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities. 

3.2.1 - NONE
Change NEW

4.0 - 12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following: 

• Analysis that the technologies continue to receive security fixes from vendors promptly. 
• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance. 
• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology. 
• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans. 

​3.2.1 - NONE
Change: NEW

4.0 - 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: 

• 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). 
• Updating all data-flow diagrams per Requirement 1.2.4. 
• Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups. 
• Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE. 
• Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope. 
• Identifying all connections from third-party entities with access to the CDE. 
• 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. 

​3.2.1 - NONE
Change: NEW

4.0 - 12.5.2.1 Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2. 

​3.2.1 - NONE
Change: NEW

4.0 - 12.5.3 Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management. 

3.2.1 - NONE
Change NEW

4.0 - 12.6.2 The security awareness program is: 

• Reviewed at least once every 12 months, and 
• 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. 

​3.2.1 - NONE
Change: NEW
​
4.0 - 12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to: 

• Phishing and related attacks. 
• Social engineering. 

​3.2.1 - NONE
Change: NEW

4.0 - 12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with Requirement 12.2.1. 

​3.2.1 - NONE
Change: NEW

4.0 - 12.9.2 Additional requirement for service providers only: TPSPs support their customers’ requests for information to meet Requirements 12.8.4 and 12.8.5 by providing the following upon customer request: 

• PCI DSS compliance status information for any service the TPSP performs on behalf of customers (Requirement 12.8.4). 
• 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). 

​3.2.1 - NONE
Change: NEW

4.0 - 12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

3.2.1 - NONE
Change NEW

4.0 - 12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include: 

• Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable. 
• Identifying whether sensitive authentication data is stored with PAN. 
• Determining where the account data came from and how it ended up where it was not expected. 
• Remediating data leaks or process gaps that resulted in the account data being where it was not expected. 

The impact of the new PCI 4.0 on the former 3.2.1 requirement 11 is in the form of: Reformulation, amendments, split, move and removal.

​Terminology:

• The term quarterly is replaced by "every three months"

New controls: 6 new controls
4.0 - 11.1.2 requests that roles and responsibilities for performing activities in Requirement 11 be documented, assigned, and understood.
4.0 - 11.3.1.1 requests that vulnerabilities not ranked as high-risk or critical be addressed based on the risk defined in the entity’s targeted risk analysis.
4.0 - 11.3.1.2 requests to perform internal vulnerability scans via authenticated scanning and clarify how it should be done.  
4.0 - 11.4.7 requests that service providers support their customers for external penetration testing (**)
4.0 - 11.5.1.1 request that service providers implement Intrusion-detection and/or intrusion-prevention techniques to detect, alert on/prevent, and address covert malware communication channels (**)
4.0 - 11.6.1 requests that unauthorized changes of headers and the contents of payment pages be detected and responded to. 
(*) Organizations should integrate PCI-DSS requirements in terms of penetration testing in the selection process of service providers to avoid any bad surprise. 
(**) The challenge here is that by definition Covert Channels are intended to be hidden. This point should be clarified by the Council. 

Amended:
4.0 - 11.2.1 requests that whenever automated monitoring is used to detect wireless access point, personnel must be notified via generated alerts(*).
4.0 - 11.4.1 requests that the approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during a penetration testing be documented in the methodology.
4.0 - 11.4.4 request that penetration testing exploitable findings be corrected in accordance with the entity’s assessment of the risk posed by the security issue.
4.0 - 11.3.1 requests Internal vulnerability Scan tool be kept up to date with latest vulnerability information and organizational independence of the testers.
4.0 - 11.3.2 requests that ASV Program Guide requirements for a passing external vulnerability scans are met. 
4.0 - 11.4.2 requests internal penetration testing be performed per the entity’s defined methodology, by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists.
4.0 - 11.4.3 requests external penetration testing be performed per the entity’s defined methodology, by a qualified internal resource or qualified external third-party and that organizational independence of the tester exists.
4.0 - 11.4.5 11.4.6 request penetration tests on segmentation controls to cover all segmentation controls/methods in use, be performed according to the entity’s defined penetration testing methodology, confirm effectiveness of any use of isolation to separate systems with differing security levels, be performed by a qualified internal resource or qualified external third party. 

(*) The challenge with authenticated scanning is the volume of findings these scans typically return, often numbering in the thousands. 

Removed: The following controls are removed for clarity and structure
3.2.1 - 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).  

Moved: 
3.2.1 - 11.1.2 requiring incident response procedures to handle detection of unauthorized wireless access points is moved under 12.10.5
3.2.1 - 11.5.1 requiring a process to respond to alerts generated by the change-detection solution is also moved under 12.10.5

​Title:
3.2.1 - Regularly test security systems and processes. 
4.0 - Test Security of Systems and Networks Regularly 

3.2.1 - 11.1 Implement processes to test for the presence of wireless access points (802.11), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis. 
Change: Reformulation + Amendement 

4.0 - 11.2.1 Authorized and unauthorized wireless access points are managed as follows: 

• The presence of wireless (Wi-Fi) access points is tested for, 
• All authorized and unauthorized wireless access points are detected and identified, 
• Testing, detection, and identification occurs at least once every three months. 
• If automated monitoring is used, personnel are notified via generated alerts.

​3.2.1 - 11.1.1 Maintain an inventory of authorized wireless access points including a documented business justification. 
Change: Reformulation

4.0 - 11.2.2 An inventory of authorized wireless access points is maintained, including a documented business justification. 

3.2.1 - 11.1.2 Implement incident response procedures in the event unauthorized wireless access points are detected. 
Change: MOVED to Requirement 12

4.0 - 12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to: 

• Intrusion-detection and intrusion-prevention systems. 
• Network security controls. 
• Change-detection mechanisms for critical files. 
• The change-and tamper-detection mechanism for payment pages. 
• Detection of unauthorized wireless access points. 

​3.2.1 - 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).  
Change: Removed

4.0 - NONE

3.2.1 - 11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel. 
Change: Reformulation + Amendments

4.0 - 11.3.1 Internal vulnerability scans are performed as follows: 

• At least once every three months. 
• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. 
• Rescans are performed that confirm all high- risk and critical vulnerabilities (as noted above) have been resolved. 
• Scan tool is kept up to date with latest vulnerability information. 
• Scans are performed by qualified personnel and organizational independence of the tester exists. 

3.2.1 - 11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved. 
Change: Reformulation + Amendments

4.0 - 11.3.2 External vulnerability scans are performed as follows: 

• At least once every three months. 
• By a PCI SSC Approved Scanning Vendor (ASV). 
• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met. 
• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan. 

3.2.1 - 11.2.3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel. 
Change: Reformulation + split 

4.0 - 11.3.1.3 Internal vulnerability scans are performed after any significant change as follows: 

• High-risk and critical vulnerabilities (per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are resolved. 
• Rescans are conducted as needed. 
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). 

4.0 - 11.3.2.1 External vulnerability scans are performed after any significant change as follows: 

• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
• Rescans are conducted as needed. 
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV). 

3.2.1 - 11.3 Implement a methodology for penetration testing that includes the following: 

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115) 
• Includes coverage for the entire CDE perimeter and critical systems 
• Includes testing from both inside and outside the network 
• Includes testing to validate any segmentation and scope-reduction controls 
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5 
• Defines network-layer penetration tests to include components that support network functions as well as operating systems 
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months 
• Specifies retention of penetration testing results and remediation activities results. 

Change: Reformulation + Amendement

4.0 - 11.4.1 A penetration testing methodology is defined, documented, and implemented by the entity, and includes: 

• Industry-accepted penetration testing approaches. 
• Coverage for the entire CDE perimeter and critical systems. 
• Testing from both inside and outside the network. 
• Testing to validate any segmentation and scope- reduction controls. 
• Application-layer penetration testing to identify, at a minimum, the vulnerabilities listed in Requirement 6.2.4. 
• Network-layer penetration tests that encompass all components that support network functions as well as operating systems. 
• Review and consideration of threats and vulnerabilities experienced in the last 12 months. 
• Documented approach to assessing and addressing the risk posed by exploitable vulnerabilities and security weaknesses found during penetration testing. 
• Retention of penetration testing results and remediation activities results for at least 12 months. 

3.2.1 - 11.3.1 Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). 
Change: Reformulation + amendments

4.0 - 11.4.3 External penetration testing is performed: 

• Per the entity’s defined methodology 
• At least once every 12 months 
• After any significant infrastructure or application upgrade or change 
• By a qualified internal resource or qualified external third party 
• Organizational independence of the tester exists (not required to be a QSA or ASV). ​

3.2.1 - 11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment). 
Change: Reformulation + amendments

4.0 - 11.4.2 Internal penetration testing is performed: 

• Per the entity’s defined methodology, 
• At least once every 12 months 
• After any significant infrastructure or application upgrade or change 
• By a qualified internal resource or qualified external third-party 
• Organizational independence of the tester exists (not required to be a QSA or ASV). ​

3.2.1 - 11.3.3 Exploitable vulnerabilities found during penetration testing are corrected and testing is repeated to verify the corrections. 
Change: Reformulation + Amendement

4.0 - 11.4.4 Exploitable vulnerabilities and security weaknesses found during penetration testing are corrected as follows: 

• In accordance with the entity’s assessment of the risk posed by the security issue as defined in Requirement 6.3.1. 
• Penetration testing is repeated to verify the corrections. 

3.2.1 - 11.3.4 If segmentation is used to isolate the CDE from other networks, perform penetration tests at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective, and isolate all out-of-scope systems from systems in the CDE. 
Change: Reformulation + amendments

4.0 - 11.4.5 If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: 

• At least once every 12 months and after any changes to segmentation controls/methods 
• Covering all segmentation controls/methods in use. 
• According to the entity’s defined penetration testing methodology. 
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems. 
• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3). 
• Performed by a qualified internal resource or qualified external third party. 
• Organizational independence of the tester exists (not required to be a QSA or ASV). ​

3.2.1 - 11.3.4.1 Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. 
Change: Reformulation + amendments

4.0 - 11.4.6 Additional requirement for service providers only: If segmentation is used to isolate the CDE from other networks, penetration tests are performed on segmentation controls as follows: 

• At least once every six months and after any changes to segmentation controls/methods. 
• Covering all segmentation controls/methods in use. 
• According to the entity’s defined penetration testing methodology. 
• Confirming that the segmentation controls/methods are operational and effective, and isolate the CDE from all out-of-scope systems. 
• Confirming effectiveness of any use of isolation to separate systems with differing security levels (see Requirement 2.2.3). 
• Performed by a qualified internal resource or qualified external third party. 
• Organizational independence of the tester exists (not required to be a QSA or ASV). ​

3.2.1 - 11.4 Use intrusion-detection and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises. 
Keep all intrusion-detection and prevention engines, baselines, and signatures up to date. 
Change: Reformulation

4.0 - 11.5.1 Intrusion-detection and/or intrusion- prevention techniques are used to detect and/or prevent intrusions into the network as follows: 

• All traffic is monitored at the perimeter of the CDE. 
• All traffic is monitored at critical points in the CDE. 
• Personnel are alerted to suspected compromises. 
• All intrusion-detection and prevention engines, baselines, and signatures are kept up to date. 

3.2.1 - 11.5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. 
Change: Reformulation

4.0 - 11.5.2 A change-detection mechanism (for example, file integrity monitoring tools) is deployed as follows: 

• To alert personnel to unauthorized modification (including changes, additions, and deletions) of critical files. 
• To perform critical file comparisons at least once weekly. 

3.2.1 - 11.5.1 Implement a process to respond to any alerts generated by the change- detection solution. 
Change: Moved under 12.10.5

4.0 - 12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to: 

• Intrusion-detection and intrusion-prevention systems. 
• Network security controls. 
• Change-detection mechanisms for critical files. 
• The change-and tamper-detection mechanism for payment pages. 
• Detection of unauthorized wireless access points. 

3.2.1 - 11.6 Ensure that security policies and operational procedures for security monitoring and testing are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 11.1.1 All security policies and operational procedures that are identified in Requirement 11 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

​3.2.1 - None
Change : NEW

4.0 - 11.1.2 Roles and responsibilities for performing activities in Requirement 11 are documented, assigned, and understood. 

3.2.1 - None
Change : NEW

4.0 - 11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at Requirement 6.3.1) are managed as follows: 

• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 
• Rescans are conducted as needed. 

3.2.1 - None
Change : NEW

4.0 - 11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows: 

• Systems that are unable to accept credentials for authenticated scanning are documented. 
• Sufficient privileges are used for those systems that accept credentials for scanning. 
• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with Requirement 8.2.2. 

​3.2.1 - None
Change : NEW

11.4.7 Additional requirement for multi-tenant service providers only: Multi-tenant service providers support their customers for external penetration testing per Requirement 11.4.3 and 11.4.4. 

​3.2.1 - None
Change : NEW

11.5.1.1 Additional requirement for service providers only: Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels. 

3.2.1 - None
Change : NEW

11.6.1 A change- and tamper-detection mechanism is deployed as follows: 

• 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. 
• The mechanism is configured to evaluate the received HTTP header and payment page. 
• The mechanism functions are performed as follows: 
  • –  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). 

The impact of the new PCI 4.0 on the former 3.2.1 requirement 10 is in the form of: Reformulation, Clarification, Change/amendments, Merges

Terminology:

• The term "firewall" is replaced by "Network Security controls"
• The term "Antivirus" is replaced by "Antimalware solution"
• The term "network resources" is replaced by "System components"

New controls: 3 new controls
4.0 - 10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 
4.0 - 10.7.2 The requirement to detect detected, alerted, and addressed promptly failures of critical security control systems that was only applicable to service providers in 3.2.1 is now generalized as a separated requirement. 
4.0 - 10.7.3 The list of actions to be included into the response plan of failures of any critical security controls systems is now generalized to non-service providers as well as service-providers

Amended:
4.0 - 10.6.2  Provides additional information regarding the usage of central time servers 

• One or more designated time servers are in use. 
• Only the designated central time server(s)receives time from external sources. 
• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC). 
• Where there is more than one designated time server, the time servers peer with one another to keep accurate time. 
• Internal systems receive time information only from designated central time server(s). 

4.0 - 10.6.3 Clarify how PCIco expects Time synchronization to be protected 

• Access to time data is restricted to only personnel with a business need and changes to time settings on critical systems are logged, monitored, and reviewed. 

4.0 - 10.2.1.2 Requires to logs any interactive use of application or system accounts as part of actions taken by any individual with administrative access.

Removed: The following controls are removed for clarity and structure
3.2.1 - 10.2 Implement automated audit trails for all system components to reconstruct the following events: 
3.2.1 - 10.5 Secure audit trails so they cannot be altered. 
3.2.1 - 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. 

Moved: NA

Title:
3.2.1 - Track and monitor all access to network resources and cardholder data 
4.0 - Log and Monitor All Access to System Components and Cardholder Data 

3.2.1 - 10.1 Implement audit trails to link all access to system components to each individual user.  
Change: Reformulation

4.0 - 10.2.1 Audit logs are enabled and active for all system components and cardholder data. ​

3.2.1 - 10.2 Implement automated audit trails for all system components to reconstruct the following events: 
Change: REMOVED
​
4.0 - None

​3.2.1 - 10.2.1 All individual user accesses to cardholder data 
Change: Reformulation

4.0 - 10.2.1.1 Audit logs capture all individual user access to cardholder data. 

3.2.1 - 10.2.2 All actions taken by any individual with root or administrative privileges 
Change: Reformulation + Amendement

4.0 - 10.2.1.2 Audit logs capture all actions taken by any individual with administrative access, including any interactive use of application or system accounts. ​

​3.2.1 - 10.2.3 Access to all audit trails 
Change: Reformulation

4.0 - 10.2.1.3 Audit logs capture all access to audit logs. 

​3.2.1 - 10.2.4 Invalid logical access attempts 
Change: Reformulation

4.0 - 10.2.1.4 Audit logs capture all invalid logical access attempts. 

3.2.1- 10.2.5 Use of and changes to identification and authentication mechanisms—including but not limited to creation of new accounts and elevation of privileges—and all changes, additions, or deletions to accounts with root or administrative privileges 
Change: Reformulation

4.0 - 10.2.1.5 Audit logs capture all changes to identification and authentication credentials including, but not limited to: 

• Creation of new accounts. 
• Elevation of privileges. 
• All changes, additions, or deletions to accounts with administrative access. 

3.2.1 - 10.2.6 Initialization, stopping, or pausing of the audit logs 
Change: Reformulation

4.0 - 10.2.1.6 Audit logs capture the following: 

• All initialization of new audit logs, and 
• All starting, stopping, or pausing of the existing audit logs. 

​3.2.1 - 10.2.7 Creation and deletion of system- level objects 
Change: Reformulation

4.0 - 10.2.1.7 Audit logs capture all creation and deletion of system-level objects. 

3.2.1 - 10.3 Record at least the following audit trail entries for all system components for each event
3.2.1 - 10.3.1 User identification 
3.2.1 - 10.3.2 Type of event 
3.2.1 - 10.3.3 Date and time 
3.2.1 - 10.3.4 Success or failure indication 
10.3.5 Origination of event 
10.3.6 Identity or name of affected data, system component, or resource 
Change: Reformulation + Merge

4.0 - 10.2.2 Audit logs record the following details for each auditable event: 

• User identification. 
• Type of event. 
• Date and time. 
• Success and failure indication. 
• Origination of event. 
• Identity or name of affected data, system component, resource, or service (for example, name and protocol). 

​3.2.1 - 10.4 Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. 
Change: Reformulation

4.0 - 10.6.1 System clocks and time are synchronized using time-synchronization technology. 

3.2.1 - 10.4.2 Time data is protected. 
Change: Reformulation + amendement
​
4.0 - 10.6.3 Time synchronization settings and data are protected as follows: 

• Access to time data is restricted to only personnel with a business need. 
• Any changes to time settings on critical systems are logged, monitored, and reviewed. 

3.2.1 - 10.4.1 Critical systems have the correct and consistent time. 
3.2.1 - 10.4.3 Time settings are received from industry-accepted time sources. 
Change: Merge + Reformulation + Amendement

4.0 - 10.6.2 Systems are configured to the correct and consistent time as follows: 

• One or more designated time servers are in use. 
• Only the designated central time server(s)receives time from external sources. 
• Time received from external sources is based on International Atomic Time or Coordinated Universal Time (UTC). 
• The designated time server(s) accept time updates only from specific industry-accepted external sources. 
• Where there is more than one designated time server, the time servers peer with one another to keep accurate time. 
• Internal systems receive time information only from designated central time server(s). ​

3.2.1 - 10.5 Secure audit trails so they cannot be altered. 
Change: REMOVED
​
4.0 - None

​3.2.1 - 10.5.1 Limit viewing of audit trails to those with a job-related need. 
Change: Reformulation

4.0 - 10.3.1 Read access to audit logs files is limited to those with a job-related need. 

3.2.1 - 10.5.2 Protect audit trail files from unauthorized modifications. 
Change: Reformulation + Clarification

4.0 - 10.3.2 Audit log files are protected to prevent modifications by individuals.

​3.2.1 - 10.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter. 
3.2.1 - 10.5.4 Write logs for external-facing technologies onto a secure, centralized, internal log server or media device. 
Change: Reformulation + Merge

4.0 -  10.3.3 Audit log files, including those for external- facing technologies, are promptly backed up to a secure, central, internal log server(s) or other media that is difficult to modify. 

​3.2.1 - 10.5.5 Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 
Change: Reformulation

4.0 - 10.3.4 File integrity monitoring or change-detection mechanisms is used on audit logs to ensure that existing log data cannot be changed without generating alerts. 

​3.2.1 - 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity. 
Change: Removed

4.0 - None

3.2.1 - 10.6.1 Review the following at least daily: 

• All security events 
• Logs of all system components that store, process, or transmit CHD and/or SAD 
• Logs of all critical system components 
• Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.). 

Change: Reformulation

4.0 - 10.4.1 The following audit logs are reviewed at least once daily: 

• All security events. 
• Logs of all system components that store, process, or transmit CHD and/or SAD. 
• Logs of all critical system components. 
• Logs of all servers and system components that perform security functions (for example, network security controls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers). 

​3.2.1 - 10.6.2 Review logs of all other system components periodically based on the organization’s policies and risk management strategy, as determined by the organization’s annual risk assessment. 
Change: Reformulation + Clarification (target risk analysis) 

4.0 - 10.4.2 Logs of all other system components (those not specified in Requirement 10.4.1) are reviewed periodically. 
4.0 - 10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in Requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

​3.2.1 - 10.6.3 Follow up exceptions and anomalies identified during the review process. 
Change: Reformulation

4.0 - 10.4.3 Exceptions and anomalies identified during the review process are addressed. 

​3.2.1 - 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup). 
Change: Reformulation

4.0 - 10.5.1 Retain audit log history for at least 12 months, with at least the most recent three months immediately available for analysis. 

3.2.1 - 10.8 Additional requirement for service providers only: Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of: 

• Firewalls 
• IDS/IPS 
• FIM 
• Anti-virus 
• Physical access controls 
• Logical access controls 
• Audit logging mechanisms 
• Segmentation controls (if used) 

Change: Reformulation + Clarification

4.0 - 10.7.1 Additional requirement for service providers only: Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: 

• Network security controls. 
• IDS/IPS. 
• FIM. 
• Anti-malware solutions. 
• Physical access controls. 
• Logical access controls. 
• Audit logging mechanisms. 
• Segmentation controls (if used). 

3.2.1 - 10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include: 

• Restoring security functions 
• Identifying and documenting the duration (date and time start to end) of the security failure 
• Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause 
• Identifying and addressing any security issues that arose during the failure 
• Performing a risk assessment to determine whether further actions are required as a result of the security failure 
• Implementing controls to prevent cause of failure from reoccurring 
• Resuming monitoring of security controls 

Change: Reformulation + Clarification

4.0 - 10.7.3 Failures of any critical security controls systems are responded to promptly, including but not limited to: 

• Restoring security functions. 
• Identifying and documenting the duration (date and time from start to end) of the security failure. 
• Identifying and documenting the cause(s) of failure and documenting required remediation. 
• Identifying and addressing any security issues that arose during the failure. 
• Determining whether further actions are required as a result of the security failure. 
• Implementing controls to prevent the cause of failure from reoccurring. 
• Resuming monitoring of security controls.

3.2.1 - 10.9 Ensure that security policies and operational procedures for monitoring all access to network resources and cardholder data are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 10.1.1 All security policies and operational procedures that are identified in Requirement 10 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties

4.0 10.1.1 All security policies and operational procedures that are identified in Requirement 10 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

​3.2.1 - NONE
Change: NEW

4.0 - 10.1.2 Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood. 

3.2.1: None
Change: NEW
​
10.4.1.1 Automated mechanisms are used to perform audit log reviews. 

3.2.1 - NONE
Change: NEW
​
4.0 - 10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems: 

• Network security controls. 
• IDS/IPS. 
• Change-detection mechanisms. 
• Anti-malware solutions. 
• Physical access controls. 
• Logical access controls. 
• Audit logging mechanisms. 
• Segmentation controls (if used). 
• Audit log review mechanisms. 
• Automated security testing tools (if used).

Terminology:

• The term "Point of interaction (POI) device" is used for "devices that capture payment card data"
• The abbreviation CDE replaces " ardholder data environment"

​New controls: 3 new controls
4.0 - 9.5.1.2.1 Stating that the definition of  the  frequency of periodic POI device inspections and the type of inspections to perform shall be determined and documented in the entity’s targeted risk analysis.
4.0 - 9.1.2 Requires Roles and responsibilities for performing activities in Requirement 9 to be documented, assigned, and understood. 
4.0 - 9.2.4 requires to lock consoles ijn sensitive areas when not in use. 

Changes:

• No changes

Amended:
4.0 - 9.4.3  Requires to record/log the location to which media are sent out.  

Removed: None

Moved:

• No move

​Get your PCI 4.0 COMPLIANCE DASHBOARD TOOL . Fully aligned with PCI DSS V4.0. It includes the defined approach requirements, the customized approach, applicability notes, purpose, good practices & further information, definition, example and defined testing procedures and prioritization approach. It also provides templates to register your compensating controls, controls met with remediations but also to register your customized Controls, the outcome of the customized approach risk assessments and the risk assessments for the definition of frequency periods as well as to register execution of vulnerability scans and penetration tests.

​Title:
3.2.1 - Restrict physical access to cardholder data 

4.0 - Restrict Physical Access to Cardholder Data 

​3.2.1 - 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. 
Change: Reformulation

4.0 - 9.2.1 Appropriate facility entry controls are in place to restrict physical access to systems in the CDE. 

3.2.1 - 9.1.1 Use either video cameras or access control mechanisms (or both) to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law. 
Change: Reformulation + Clarification

4.0 - 9.2.1.1 Individual physical access to sensitive areas within the CDE is monitored with either video cameras or physical access control mechanisms (or both) as follows: 

• Entry and exit points to/from sensitive areas within the CDE are monitored. 
• Monitoring devices or mechanisms are protected from tampering or disabling. 
• Collected data is reviewed and correlated with other entries. 
• Collected data is stored for at least three months, unless otherwise restricted by law. 

​3.2.1 - 9.1.2 Implement physical and/or logical controls to restrict access to publicly accessible network jacks. 
Change: Reformulation

4.0 - 9.2.2 Physical and/or logical controls are implemented to restrict use of publicly accessible network jacks within the facility. 

​3.2.1 - 9.1.3 Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines. 
Change: Reformulation

4.0 - 9.2.3 Physical access to wireless access points, gateways, networking/communications hardware, and telecommunication lines within the facility is restricted. 

3.2.1 - 9.2 Develop procedures to easily distinguish between onsite personnel and visitors, to include: 

• Identifying onsite personnel and visitors (for example, assigning badges) 
• Changes to access requirements 
• Revoking or terminating onsite personnel and expired visitor identification (such as ID badges). 

Change: Reformulation

4.0 - 9.3.1 Procedures are implemented for authorizing and managing physical access of personnel to the CDE, including: 

• Identifying personnel. 
• Managing changes to an individual’s physical access requirements. 
• Revoking or terminating personnel identification. 
• Limiting access to the identification process or system to authorized personnel. 

3.2.1 - 9.3 Control physical access for onsite personnel to sensitive areas as follows: 

• Access must be authorized and based on individual job function. 
• Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled. 

Change: Reformulation

4.0 - 9.3.1.1 Physical access to sensitive areas within the CDE for personnel is controlled as follows: 

• Access is authorized and based on individual job function. 
• Access is revoked immediately upon termination. 
• All physical access mechanisms, such as keys, access cards, etc., are returned or disabled upon termination. 

3.2.1- 9.4 Implement procedures to identify and authorize visitors. 
Procedures should include the following: 
3.2.1 - 9.4.1 Visitors are authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained. 
3.2.1 - 9.4.2 Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel. 
Change: Reformulation + Merge

4.0 - 9.3.2 Procedures are implemented for authorizing and managing visitor access to the CDE, including: 

• Visitors are authorized before entering. 
• Visitors are escorted at all times. 
• Visitors are clearly identified and given a badge or other identification that expires. 
• Visitor badges or other identification visibly distinguishes visitors from personnel 

​3.2.1 - 9.4.3 Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration. 
Change: Reformulation + Clarification

4.0 - 9.3.3 Visitor badges or identification are surrendered or deactivated before visitors leave the facility or at the date of expiration. 

3.2.1 - 9.4.4 A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as computer rooms and data centers where cardholder data is stored or transmitted. 
Document the visitor’s name, the firm represented, and the onsite personnel authorizing physical access on the log. 
Retain this log for a minimum of three months, unless otherwise restricted by law. 
Change: Reformulation

4.0 - 9.3.4 A visitor log is used to maintain a physical record of visitor activity within the facility and within sensitive areas, including: 

• The visitor’s name and the organization represented. 
• The date and time of the visit. 
• The name of the personnel authorizing physical access. 
• Retaining the log for at least three months, unless otherwise restricted by law. 

​3.2.1 - 9.5 Physically secure all media. 
Change: Reformulation

4.0 - 9.4.1 All media with cardholder data is physically secured.

​3.2.1 - 9.5.1 Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually. 
Change: Reformulation + Split

4.0 - 9.4.1.1 Offline media backups with cardholder data are stored in a secure location. 
4.0 - 9.4.1.2 The security of the offline media backup location(s) with cardholder data is reviewed at least once every 12 months 

​3.2.1 - 9.6 Maintain strict control over the internal or external distribution of any kind of media, including the following: 
3.2.1 - 9.6.2 Send the media by secured courier or other delivery method that can be accurately tracked. 
Change: Reformulation + Merge + Clarification + Amendement

4.0 - 9.4.3 Media with cardholder data sent outside the facility is secured as follows: 

• Media sent outside the facility is logged. 
• Media is sent by secured courier or other delivery method that can be accurately tracked. 
• Offsite tracking logs include details about media location. 

​3.2.1 - 9.6.1 Classify media so the sensitivity of the data can be determined. 
Change: Reformulation

4.0- 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data. 

​3.2.1 - 9.6.3 Ensure management approves any and all media that is moved from a secured area (including when media is distributed to individuals). 
Change: Reformulation

4.0 - 9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals). 

​3.2.1 - 9.7 Maintain strict control over the storage and accessibility of media. 
Change: Reformulation

4.0 - 9.4.5 Inventory logs of all electronic media with cardholder data are maintained. 

​3.2.1 - 9.7.1 Properly maintain inventory logs of all media and conduct media inventories at least annually. 
Change: Reformulation

4.0 - 9.4.5.1 Inventories of electronic media with cardholder data are conducted at least once every 12 months. 

​3.2.1 - 9.8 Destroy media when it is no longer needed for business or legal reasons as follows: 
3.2.1 - 9.8.1 Shred, incinerate, or pulp hard- copy materials so that cardholder data cannot be reconstructed. Secure storage containers used for materials that are to be destroyed. 

Change: Reformulation + Merge
4.0 - 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows: 

• Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed. 
• Materials are stored in secure storage containers prior to destruction. 

3.2.1 - 9.8.2 Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. 
Change: Reformulation + clarification 

4.0 - 9.4.7 Electronic media with cardholder data is destroyed when no longer needed for business or legal reasons via one of the following: 

• The electronic media is destroyed. 
• The cardholder data is rendered unrecoverable  so that it cannot be reconstructed. 

3.2.1 - 9.9 Protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution. 
Change:  Reformulation + clarification

4.0 - 9.5.1 POI devices that capture payment card data via direct physical interaction with the payment card form factor are protected from tampering and unauthorized substitution, including the following: 

• Maintaining a list of POI devices. 
• Periodically inspecting POI devices to look for 
  tampering or unauthorized substitution. 
• Training personnel to be aware of suspicious behavior and to report tampering or unauthorized substitution of devices. 

3.2.1 - 9.9.1 Maintain an up-to-date list of devices. The list should include the following: 

• Make, model of device 
• Location of device (for example, the address of the site or facility where the device is located) 
• Device serial number or other method of unique identification. 

Change: Reformulation

4.0 - 9.5.1.1 An up-to-date list of POI devices is maintained, including: 

• Make and model of the device. 
• Location of device. 
• Device serial number or other methods of unique identification. 

​3.2.1 - 9.9.2 Periodically inspect device surfaces to detect tampering (for example, addition of card skimmers to devices), or substitution (for example, by checking the serial number or other device characteristics to verify it has not been swapped with a fraudulent device). 
Change: Reformulation

4.0 - 9.5.1.2 POI device surfaces are periodically inspected to detect tampering and unauthorized substitution. 

3.2.1 - 9.9.3 Provide training for personnel to be aware of attempted tampering or replacement of devices. Training should include the following: 

• Verify the identity of any third-party persons claiming to be repair or maintenance personnel, prior to granting them access to modify or troubleshoot devices. 
• Do not install, replace, or return devices without verification. 
• Be aware of suspicious behavior around devices (for example, attempts by unknown persons to unplug or open devices). 
• Report suspicious behavior and indications of device tampering or substitution to appropriate personnel (for example, to a manager or security officer). 

Change: Reformulation

4.0 - 9.5.1.3 Training is provided for personnel in POI environments to be aware of attempted tampering or replacement of POI devices, and includes: 

• Verifying the identity of any third-party persons claiming to be repair or maintenance personnel, before granting them access to modify or troubleshoot devices. 
• Procedures to ensure devices are not installed, replaced, or returned without verification. 
• Being aware of suspicious behavior around devices. 
• Reporting suspicious behavior and indications of device tampering or substitution to appropriate personnel. 

3.2.1 - 9.10 Ensure that security policies and operational procedures for restricting physical access to cardholder data are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 9.1.1 All security policies and operational procedures that are identified in Requirement 9 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

​3.2.1 - None
Change: NEW

4.0 - 9.1.2 Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood. 

​3.2.1 - None
Change: New

4.0 - 9.2.4 Access to consoles in sensitive areas is restricted via locking when not in use. 

​3.2.1 - NONE
Change: NEW

4.0 - 9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

Terminology: 

• The term "non-consumer users” is removed. This requirement do not apply to accounts used by consumers (cardholders). 
• The term "authentication credentials" is replaced by "authentication factor"

New controls: 6 new controls: 

• 4.0 - 8.1.2 Specifies that Roles and responsibilities for performing activities in requirement 8 shall be documented, assigned, and understood. 
• 4.0 - 8.3.10.1 Additional requirement for service providers specifying an alternative to the periodic password change
• 4.0 - 8.4.2 Detail how MFA shall be implemented MFA ifor all access into the CDE. 
• 4.0 - 8.6.1 Specifies how accounts used by systems or applications for interactive login, shall be managed.
• 4.0 - 8.6.2 Forbid hard coding of passwords/passphrases for any application and system accounts used for interactive login .
• 4.0 - 8.6.3 Specifies how Passwords/passphrases for any application and system accounts shall be protected.

Changes: 

• 4.0 - 8.3.4 - The number of invalid authentication attempts before locking out a user ID jumps to 10!
• 4.0 - 8.3.6 - Password minimum length jumps to 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). 
• Instead of changing passwords/passphrases at least once every 90 days, organizations could determine access to resources automatically by dynamically analyzing the security posture of accounts.
• 4.0 - 8.2.2 Allows usage of group/shared accounts on an exceptional basis

Amended: 

• 4.0 - 8.3.9 Provides an alternative to the periodic password change 
• 4.0 - 8.2.6 - Require new/reset passwords/passphrases to be changed after first use
• 4.0 - 8.2.2 Specifies conditions for usage of group/shared accounts

Removed: None

Moved: 
The requirement related to the protection of access to databases (3.2.1 - 8.7) has been moved to requirement 4.0-7.2.7

Titre
3.2.1 - Identify and authenticate access to system components 
4.0 - Identify Users and Authenticate Access to System Components 

3.2.1 - 8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data. 
Change:  Reformulation

4.0 - 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed. 

8.1.2 - Control addition, deletion, and modification of user IDs, credentials, and other identifier objects. 
Change: Reformulation + clarification

4.0 - 8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows: 

• Authorized with the appropriate approval. 
• Implemented with only the privileges specified on the documented approval. 

​3.2.1 - 8.1.3 Immediately revoke access for any terminated users. 
Change: Reformulation

4.0 - 8.2.5 Access for terminated users is immediately revoked. 

​3.2.1 - 8.1.4 Remove/disable inactive user accounts within 90 days. 
Change: Reformulation

4.0 - 8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity. 

3.2.1 - 8.1.5 Manage IDs used by third parties to access, support, or maintain system components via remote access as follows: 

• Enabled only during the time period needed and disabled when not in use. 
• Monitored when in use. 

Change: Reformulation

4.0 - 8.2.7 Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows: 

• Enabled only during the time period needed and disabled when not in use. 
• Use is monitored for unexpected activity. 

3.2.1 - 8.1.6 Limit repeated access attempts by locking out the user ID after not more than six attempts. 
3.2.1 - 8.1.7 Set the lockout duration to a minimum of 30 minutes or until an administrator enables the user ID. 
Change: Reformulation + merge + Change

4.0 - 8.3.4 Invalid authentication attempts are limited by: 

• Locking out the user ID after not more than 10 attempts. 
• Setting the lockout duration to a minimum of 30 minutes or until the user’s identity is confirmed 

4.0 - 8.1.8 If a session has been idle for more than 15 minutes, require the user to re-authenticate to re-activate the terminal or session. 
Change: Reformulation + Clarification 

4.0 - 8.2.8 If a user session has been idle for more than 15 minutes, the user is required to re-authenticate to re-activate the terminal or session. 

3.2.1 - 8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: 

• Something you know, such as a password or passphrase 
• Something you have, such as a token device or smart card 
• Something you are, such as a biometric. 

Change: Reformulation

4.0 - 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: 

• Something you know, such as a password or passphrase. 
• Something you have, such as a token device or smart card. 
• Something you are, such as a biometric element.

3.2.1 - 8.2.1 Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. 
Change: Reformulation

4.0 - 8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components. 

3.2.1 - 8.2.2 Verify user identity before modifying any authentication credential—for example, performing password resets, provisioning new tokens, or generating new keys. 
Change: Reformulation

4.0 - 8.3.3 User identity is verified before modifying any authentication factor. 

3.2.1 - 8.2.3 Passwords/passphrases must meet the following: 

• Require a minimum length of at least seven characters. 
• Contain both numeric and alphabetic characters. 
  Alternatively, the passwords/ passphrases must have complexity and strength at least equivalent to the parameters specified above. 

Change: Reformulation +  change

4.0 -  8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: 

• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters). 

3.2.1 - 8.2.4 Change user passwords/passphrases at least once every 90 days. 
Change: Reformulation + amendement + clarification

4.0 - 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: 

• Passwords/passphrases are changed at least once every 90 days, 
  OR 
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. 

4.0 - 8.3.10 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single- factor authentication implementation), then guidance is provided to customer users including: 

• Guidance for customers to change their user passwords/passphrases periodically. 
• Guidance as to when, and under what circumstances, passwords/passphrases are to be changed. 

​3.2.1 - 8.2.5 Do not allow an individual to submit a new password/passphrase that is the same as any of the last four passwords/passphrases he or she has used. 
Change: Reformulation

4.0 - 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. 

3.2.1 - 8.2.6 Set passwords/passphrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use. 
Change: Reformulation + Amendement

4.0 - 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: 

• Set to a unique value for first-time use and upon reset. 
• Forced to be changed immediately after the first use.

​3.2.1 - 8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. 
Change: Reformulation

4.0 - 8.4.1 MFA is implemented for all non-console access into the CDE for personnel with administrative access. 

3.2.1 - 8.3.2 Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third-party access for support or maintenance) originating from outside the entity’s network. 
Change: Reformulation + clarification

4.0 - 8.4.3 MFA is implemented for all remote network access originating from outside the entity’s network that could access or impact the CDE as follows: 

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

3.2.1 - 8.4 Document and communicate authentication policies and procedures to all users including: 

• Guidance on selecting strong authentication credentials 
• Guidance for how users should protect their authentication credentials 
• Instructions not to reuse previously used passwords 
• Instructions to change passwords if there is any suspicion the password could be compromised. 

Change: Reformulation + clarification

4.0 - 8.3.8 Authentication policies and procedures are documented and communicated to all users including: 

• Guidance on selecting strong authentication factors. 
• Guidance for how users should protect their authentication factors. 
• Instructions not to reuse previously used passwords/passphrases. 
• Instructions to change passwords/passphrases if there is any suspicion or knowledge that the password/passphrases have been compromised and how to report the incident.

3.2.1 - 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows: 

• • Generic user IDs are disabled or removed. 
  • Shared user IDs do not exist for system administration and other critical functions. 
  • Shared and generic user IDs are not used to administer any system components. 

Change: Reformulation + change/amendment

4.0 - 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: 

• Account use is prevented unless needed for an exceptional circumstance.
• Use is limited to the time needed for the exceptional circumstance. 
• Business justification for use is documented. 
• Use is explicitly approved by management. 
• Individual user identity is confirmed before access to an account is granted. 
• Every action taken is attributable to an individual user. 

3.2.1 - 8.5.1 Additional requirement for service providers only: Service providers with remote access to customer premises (for example, for support of POS systems or servers) must use a unique authentication credential (such as a password/phrase) for each customer. 
Change: Reformulation
​
4.0 - 8.2.3 Additional requirement for service providers only: Service providers with remote access to customer premises use unique authentication factors for each customer premises. 

3.2.1 - 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: 

• Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. 
• Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. 

Change: Reformulation

4.0 - 8.3.11 Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used: 

• Factors are assigned to an individual user and not shared among multiple users. 
• Physical and/or logical controls ensure only the intended user can use that factor to gain access. 

3.2.1 - 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows: 

• All user access to, user queries of, and user actions on databases are through programmatic methods. 
• Only database administrators have the ability to directly access or query databases. 
• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes). 

Change: MOVED

4.0 - 7.2.6 

3.2.1 - 8.8 Ensure that security policies and operational procedures for identification and authentication are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 8.1.1 All security policies and operational procedures that are identified in Requirement 8 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

3.2.1 - None
Change: NEW
​
4.0 - 8.1.2 Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood. 

3.2.1 - NONE
Change: NEW
​
4.0 - 8.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either: 

• Passwords/passphrases are changed at least once every 90 days, 
  OR 
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. 

​3.2.1 - NONE
Change: NEW

4.0 - 8.4.2 MFA is implemented for all access into the CDE. 

3.2.1 - NONE
Change: NEW

4.0 - 8.5.1 MFA systems are implemented as follows: 

• The MFA system is not susceptible to replay 
  attacks. 
• MFA systems cannot be bypassed by any users, including administrative users unless specifically documented, and authorized by management on an exception basis, for a limited time period. 
• At least two different types of authentication factors are used. 
• Success of all authentication factors is required before access is granted. 

3.2.1 - NONE
Change: NEW

4.0 - 8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows: 

• Interactive use is prevented unless needed for an exceptional circumstance. 
• Interactive use is limited to the time needed for the exceptional circumstance. 
• Business justification for interactive use is documented. 
• Interactive use is explicitly approved by management. 
• Individual user identity is confirmed before access to account is granted. 
• Every action taken is attributable to an individual user. 

 3.2.1 - NONE
Change: NEW

​4.0 - 8.6.2 - Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code. 3.2.1 - NONE

3.2.1 - NONE
Change: NEW

4.0 - 8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows: 

• Passwords/passphrases are changed 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) and upon suspicion or confirmation of compromise. 
• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases. 

Terminology: 

• The term "relevant" is replaced by "applicable"
• the terms "Development environment" and "test environment" are replaced by "Pre-production environments"
• the term "custom code"  is replaced by "bespoke and custom software" 

New controls: 4 new controls: 
4.0 - 7.1.2 requires that roles and responsibilities for performing activities in Requirement 7 are documented, assigned, and understood. 
4.0 - 7.2.4 requires to periodically review appropriateness of all user access and access privileges  and to handle inappropriate access as well as to seek management approval of the appropriateness of remaining access.
4.0 - 7.2.5 requires that all application and system accounts and related access privileges are assigned and managed appropriately. 
4.0 - 7.2.5.1 requires to periodically review appropriateness of all  application and system accounts access and access privileges  and to handle inappropriate access as well as to seek management approval of the appropriateness of remaining access.
Amended: 
4.0 - 7.2.1 requires, in addition to tyhe definition of access, to define an access control model. 

Removed: 
Requirement 3.2.1 - 7.2 has been removed for redundancy reason.
3.2.1 - 7.2  - Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed.

Migrated: One control  from Requirement 8 has been moved into requiremet 7
3.2.1 - 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows: 

• All user access to, user queries of, and user actions on databases are through programmatic methods. 
• Only database administrators have the ability to directly access or query databases. 
• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes). 

Titre
3.2.1 - Restrict access to cardholder data by business need to know 
4.0 - Restrict Access to System Components and cardholder Data by Business Need to Know 

3.2.1 - 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. 
Change:  Split, Clarification, removal
​
4.0 - 7.2.2 Access is assigned to users, including privileged users, based on: 

• Job classification and function. 
• Least privileges necessary to perform job responsibilities. 

3.2.1 - 7.1.1 Define access needs for each role, including: 

• System components and data resources that each role needs to access for their job function 
• Level of privilege required (for example, user, administrator, etc.) for accessing resources 

Change: Reformulation, Clarification + Amendement for the definition of an access control model;

4.0 - 7.2.1 An access control model is defined and includes granting access as follows: 

• Appropriate access depending on the entity’s business and access needs. 
• Access to system components and data resources that is based on users’ job classification and functions. 
• The least privileges required (for example, user, administrator) to perform a job function. 

3.2.1 - 7.1.2 Restrict access to privileged user IDs to least privileges necessary to perform job responsibilities. 
Change: Reformulation + Merge with 3.2.1 - 7.1.3

4.0 - 7.2.2 Access is assigned to users, including privileged users, based on: 

• Job classification and function. 
• Least privileges necessary to perform job responsibilities. 

3.2.1 - 7.1.3 Assign access based on individual personnel’s job classification and function. 
Change: Reformulation + Merge with 3.2.1 -7.1.2

4.0 - 7.2.2 Access is assigned to users, including privileged users, based on: 

• Job classification and function. 
• Least privileges necessary to perform job responsibilities. 

3.2.1 - 7.1.4 Require documented approval by authorized parties specifying required privileges.  
Change: Reformulation

4.0 - 7.2.3 Required privileges are approved by authorized personnel. 

3.2.1 - 7.2 Establish an access control system(s) for systems components that restricts access based on a user’s need to know, and is set to “deny all” unless specifically allowed. 
Change: Removed

3.2.1 - 7.2.1 This access control system(s) must include the following: Coverage of all system components 
Change: Split + Reformulation

4.0 - 7.3.1 An access control system(s) is in place that restricts access based on a user’s need to know and covers all system components. 
4.0 - 7.3.2 This access control system(s) must include the following: The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. 

3.2.1 - 7.2.2 Assignment of privileges to individuals based on job classification and function. 
Change: Reformulation

4.0 - 7.3.2 The access control system(s) is configured to enforce permissions assigned to individuals, applications, and systems based on job classification and function. 

4.0 - 7.2.3 This access control system(s) must include the following: Default “deny-all” setting. 
Change: Reformulation
​
4.0 - 7.3.3 The access control system(s) is set to “deny all” by default. 

3.2.1 - 7.3 Ensure that security policies and operational procedures for restricting access to cardholder data are documented, in use, and known to all affected parties. 
Change: Reformulation
​
4.0 - 7.1.1 All security policies and operational procedures that are identified in Requirement 7 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

3.2.1 - None
Change: NEW

4.0 - 7.2.5 All application and system accounts and related access privileges are assigned and managed as follows: 

• Based on the least privileges necessary for the operability of the system or application. 
• Access is limited to the systems, applications, or processes that specifically require their use. 

3.2.1 - None
Change: NEW. 

4.0 - 7.2.5.1 All access by application and system accounts and related access privileges are reviewed as follows: 

• 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). 
• The application/system access remains appropriate for the function being performed. 
• Any inappropriate access is addressed. 
• Management acknowledges that access remains 
  appropriate. 

3.2.1 - 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows: 

• All user access to, user queries of, and user actions on databases are through programmatic methods. 
• Only database administrators have the ability to directly access or query databases. 
• Application IDs for database applications can only be used by the applications (and not by individual users or other non-application processes). 

Change: Move from req 8 + Reformulation.

4.0 - 7.2.6 All user access to query repositories of stored cardholder data is restricted as follows: 

• Via applications or other programmatic methods, with access and allowed actions based on user roles and least privileges. 
• Only the responsible administrator(s) can directly access or query repositories of stored CHD. 

Terminology: 

• The term "relevant" is replaced by "applicable"
• the terms "Development environment" and "test environment" are replaced by "Pre-production environments"
• the term "custom code"  is replaced by "bespoke and custom software" 

New controls: 4 new controls: 
4.0 - 6.4.3 Require to protect payment pages on the the consumer’s browser.  It  applies primarily to merchant e-commerce and/or processor gateways and virtual terminals which facilitate entry of cardholder information for authorization.  
4.0 - 6.4.2 Requires deployment of an automated technical solution that continually detects and prevents web-based attacks  as of 2025.
4.0 - 6.3.2 Require organizations to manage, create an inventory and document specific application components and services utilized by an application. Organizations  also need need to invest in tools capable of alerting on component vulnerabilities to meet Requirement 4.0 - 6.3.3.
4.0 - 6.1.2 Require to document, assign and understand Roles and responsibilities for performing activities in Requirement 6.
​
Amended: 
4.0 - 6.3.1 Require that new security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs) and that Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. 
4.0 - 6.3.3 Require that applicable non critical or high-security security patches/updates be installed within an appropriate time frame as determined by organizations.

Removed: 
3.2.1 - 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. 

Title
3.2.1 - Develop and maintain secure systems and applications 
4.0 - Develop and Maintain Secure Systems and Software 

3.2.1 - 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities. 

Change:  Reformulation, Clarification and amendement

4.0 - 6.3.1 Security vulnerabilities are identified and managed as follows: 

• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). 
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. 
• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment. 
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered. ​

3.2.1 - 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor- supplied security patches. Install critical security patches within one month of release. 

Change: Reformulation + Amendements/Clarification

4.0 - 6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: 

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

3.2.1 - 6.3 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: 

• In accordance with PCI DSS (for example, secure authentication and logging) 
• Based on industry standards and/or best practices. 
• Incorporating information security throughout the software-development life cycle 

Change: Reformulation.

4.0 - 6.2.1 Bespoke and custom software are developed securely, as follows: 

• Based on industry standards and/or best practices for secure development. 
• In accordance with PCI DSS (for example, secure authentication and logging). 
• Incorporating consideration of information security issues during each stage of the software development lifecycle. 

​3.2.1 - 6.3.1 Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers. 

Change: Removed

3.2.1 - 6.3.2 Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to include at least the following: 

• Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code-review techniques and secure coding practices. 
• Code reviews ensure code is developed according to secure coding guidelines 
• Appropriate corrections are implemented prior to release. 
• Code-review results are reviewed and approved by management prior to release. 

Change: Reformulation + Split + Amendement

4.0 - 6.2.3 Bespoke and custom software is reviewed prior to being released into production or to customers, to identify and correct potential coding vulnerabilities, as follows: 

• Code reviews ensure code is developed according to secure coding guidelines. 
• Code reviews look for both existing and emerging software vulnerabilities. 
• Appropriate corrections are implemented prior to release. 

4.0 - 6.2.3.1 If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are: 

• Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices. 
• Reviewed and approved by management prior to release. 

​3.2.1 - 6.4.1 Separate development/test environments from production environments, and enforce the separation with access controls. 
Change: Reformulation

4.0 - 6.5.3 Pre-production environments are separated from production environments and the separation is enforced with access controls. 

​3.2.1 - 6.4.2 Separation of duties between development/test and production environments 
Change: Reformulation and clarification

4.0 - 6.5.4 Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. 

​3.2.1 - 6.4.3 Production data (live PANs) are not used for testing or development 

Change: Reformulation and clarification.

4.0 - 6.5.5 Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements. 

​3.2.1  - 6.4.4 Removal of test data and accounts from system components before the system becomes active / goes into production. 

Change: Reformulation.

4.0 - 6.5.6 Test data and test accounts are removed from system components before the system goes into production. 

3.2.1 - 6.4.5 Change control procedures must include the following: 
3.2.1 - 6.4.5.1 Documentation of impact. 
3.2.1 - 6.4.5.2 Documented change approval by authorized parties. 
3.2.1 -6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system. 
3.2.1 -6.4.5.4 Back-out procedures. 

Change: reformulation + Merge + Amendements

4.0 - 6.5.1 Changes to all system components in the production environment are made according to established procedures that include: 

• Reason for, and description of the change. 
• Documentation of security impact. 
• Documented change approval by authorized parties. 
• Testing to verify that the change does not adversely impact system security. 
• For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production. 
• Procedures to address failures and return to a secure state. 

​3.2.1 - 6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. 

Change: Reformulation.

4.0 - 6.5.2 Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable. 

3.2.1 - 6.5 Address common coding vulnerabilities in software-development processes as follows: 

• Train developers at least annually in up- to-date secure coding techniques, including how to avoid common coding vulnerabilities. 
• Develop applications based on secure coding guidelines. 

Change: Reformulation, Clarification, Amendement and Split

4.0 - 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: 

• On software security relevant to their job function and development languages. 
• Including secure software design and secure coding techniques. 
• Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software. 

3.2.1 6.5.1 -  6.5.10 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws. 
6.5.2 Buffer overflows 
6.5.3 Insecure cryptographic storage 
6.5.4 Insecure communications 
6.5.5 Improper error handling 
6.5.6 All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1). 
6.5.7 Cross-site scripting (XSS) 
6.5.8 Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions). 
6.5.9 Cross-site request forgery (CSRF) 
6.5.10 Broken authentication and session management. 

Change: clarification + bundle

Moved requirements for addressing common coding vulnerabilities to align all software development content under Requirement 6.2.  
Combined methods to prevent or mitigate common software attacks into a single requirement and generalized the language describing each type of attack. 

4.0 - 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: 

• Injection attacks, including SQL, LDAP , XPath, or other command, parameter, object, fault, or injection-type flaws. 
• Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data. 
• Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation. 
• Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client- side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF). 
• Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms. 
• Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1 

3.2.1 - 6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: 

• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes 
• Installing an automated technical solution that detects and prevents web- based attacks (for example, a web- application firewall) in front of public- facing web applications, to continually check all traffic. 

Change:  Clarification + amendements

4.0 - 6.4.1 For public-facing web applications, new threats and vulnerabilities are addressed on an ongoing basis and these applications are protected against known attacks as follows: 
• Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods as follows: 

• –  At least once every 12 months and after significant changes. 
• –  By an entity that specializes in application security.
• –  Including, at a minimum, all common software attacks in Requirement 6.2.4. 
• –  All vulnerabilities are ranked in accordance with requirement 6.3.1. 
• –  All vulnerabilities are corrected. 
• –  The application is re-evaluated after the corrections 
  OR 

• Installing an automated technical solution(s) that continually detects and prevents web-based attacks as follows: 

• –  Installed in front of public-facing web applications to detect and prevent web- based attacks. 
• –  Actively running and up to date as applicable. 
• –  Generating audit logs. 
• –  Configured to either block web-based attacks or generate an alert that is immediately investigated. 

3.2.1 - 6.7 Ensure that security policies and operational procedures for developing and maintaining secure systems and applications are documented, in use, and known to all affected parties. 

Change: Reformulation.

4.0 - 6.1.1 All security policies and operational procedures that are identified in Requirement 6 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties. 

​3.2.1 - None
Change: NEW. 

4.0 - 6.1.2 Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood. 

​3.2.1 - None
Change: NEW

4.0 - 6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management. 

3.2.1 - None
Change: NEW. This requirement will be superseded by Requirement 6.4.2 after 31 March 2025 when Requirement 6.4.2 becomes effective.  The key update here is that an automated solution is explicitly required ass of 2025.

4.0 - 6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following: 

• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks. 
• Actively running and up to date as applicable. 
• Generating audit logs. 
• Configured to either block web-based attacks or generate an alert that is immediately investigated. 

3.2.1 - None
Change: NEW. 

4.0 - 6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: 

• A method is implemented to confirm that each script is authorized. 
• A method is implemented to assure the integrity of each script. 
• An inventory of all scripts is maintained with written justification as to why each is necessary. 

Impact of the new PCI 4.0 on the former 3.2.1  requirement 5 are in the form of : Reformulation, clarification and amendements.   This version of requirement 5 contains quite more controls than in 3.2.1, mainly through new additions or the split of one control. It also introduces new concepts (for PCI) such as behavioral analysis, real-time scan and phishing attacks. Two controls are subjected to targeted risk analysis.

Terminology: 

• The terms virus  and "anti-virus"  are respectively replaced by "malicious software" and  by "anti-malware". This to onboard malware variants such as worms, trojans, ransomware, spyware, rootkits, adware, backdoors, etc.
• The mention "Actively running" is replaced by "Real-time scanning". This to avoid past misunderstandings. Real-time scanning should be understood as  a type of persistent, on-access scanning. 
• "Behavioral analysis" is incorporated as an accepted anti-malware solution scanning method, as an alternative to traditional periodic (scheduled and on-demand) and real-time (on-access) scans.  Behavior-based malware detection evaluates an object based on its intended actions before it can actually execute that behavior. An object’s behavior, or in some cases its potential behavior, is analyzed for suspicious activities. Attempts to perform actions that are clearly abnormal or unauthorized would indicate the object is malicious, or at least suspicious.”

New controls: 5 new controls: 

• 4.0 - 5.1.2  Generic statement about roles and responsibilities 
• 4.0 - 5.2.3.1 Organizations should perform a periodic assessment to determine which system components should require an anti-malware solution. Assets that are determined not to be affected by malware should be included in a list. The frequency of periodic evaluations of system components not at risk for malware shall be the result of a targeted risk analysis.  
• 4.0 5.3.2.1 The frequency of periodic malware scans shall be the outcome of a target risk analysis.
• 4.0 - 5.3.3 Removable electronic media must be automatically scanned when the media is inserted, connected, or logically mounted. The wording of the requirement, the testing procedures, and the guidance all indicate a requirement to scan the entire media/device upon connection, and not merely scan files on access.
• 4.0-5.4.1Mandatory detection and protection against phishing attacks. By adding this requirement, the PCI Security Standards Council has acknowledged that email is a major attack vector and the most successful attack is phishing. 

​
Split: 
3.2.1 - 5.2 is split into 4.0 - 5.3.1 , 5.3.2 and 5.3.4.

Amendments: 
4.0 - 5.3.1 Require that anti-malware be updated automatically.
4.0 - 5.3.2 Introduce the notion of continuous behavioral analysis of systems or processes. 
4.0 - 5.3.2 In  addition to periodic scanning, "real-time scanning" (on-access) scans  shall also be performed every time an object is downloaded, open, modified. Those running traditional  anti-malware tools, will need to do both periodic and real-time scanning which could introduce additional load to systems in scope. Most modern anti-malware platforms already include both.

​Moved: None

Removed: None

Titre
3.2.1 - Protect all systems against malware and regularly update anti-virus software or programs 
4.0 - Protect all Systems and networks from malicious software 

​3.2.1 - 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). 

Change: Reformulation + Clarification.

4.0 - 5.2.1An anti-malware solution(s) is deployed on all system components, except for those system components identified in periodic evaluations per Requirement 5.2.3 that concludes the system components are not at risk from malware.

3.2.1  - 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and protecting against all known types of malicious software. 

Change: Reformulation.

4.0 - 5.2.2 The deployed anti-malware solution(s): 

• Detects all known types of malware. 
• Removes, blocks, or contains all known types of malware.

3.2.1 - 5.1.2For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. 

Change: Reformulation + Clarification

4.0 - 5.2.3Any system components that are not at risk for malware are evaluated periodically to include the following: 

• A documented list of all system components not at risk for malware. 
• Identification and evaluation of evolving malware threats for those system components. 
• Confirmation whether such system components continue to not require anti-malware protection. 

Notes: 
Organizations must perform a Targeted Risk Analysis (TRA) with the goal of establishing a frequency to review systems not at risk for malware. This review is an evaluation to determine if the threat landscape has changed and therefore may require additional controls outside of traditional anti-malware installations. There are several components which typically do not have or cannot have anti-malware agents installed such as Mainframes, Vendor Appliances, or low-level operating systems such as ESXi (VMware), Kubernetes Clusters, etc. QSAs will be looking for organizations to establish a reasonable frequency based on the TRA and demonstrate the timeframe has been followed. c
Using industry and vendor sources to identify emerging malware and attacks on systems. 

3.2.1 - 5.2Ensure that all anti-virus mechanisms are maintained as follows: 

• Are kept current, 
• Perform periodic scans 
• Generate audit logs which are retained per PCI DSS Requirement 10.7. 

​Change: Reformulation  + Split + amendment

4.0 - 5.3.1The anti-malware solution(s) is kept current via automatic updates. 

4.0 - 5.3.2The anti-malware solution(s): 

• Performs periodic scans and active or real-time 
  scans. 
  OR 
• Performs continuous behavioral analysis of systems or processes. 

4.0 - 5.3.4 Audit logs for the anti-malware solution(s) are enabled and retained in accordance with Requirement 10.5.1.

​3.2.1 - 5.3 Ensure that anti-virus mechanisms are actively running and cannot be disabled or altered by users, unless specifically authorized by management on a case-by-case basis for a limited time period. 

Change: Reformulation.

4.0 - 5.3.5 Anti-malware mechanisms cannot be disabled or altered by users, unless specifically documented, and authorized by management on a case-by-case basis for a limited time period.

3.2.1 - 5.4 Ensure that security policies and operational procedures for protecting systems against malware are documented, in use, and known to all affected parties. 

Change: Reformulation. 

4.0 - 5.1.1 All security policies and operational procedures that are identified in Requirement 5 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties.

3.2.1 None
Change: NEW

4.0 - 5.1.2 Roles and responsibilities for performing activities in Requirement 5 are documented, assigned, and understood. 

3.2.1 - None
Change: NEW

4.0 - 5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

3.2.1 - None
Change: NEW

4.0 5.3.2.1 If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 
Note: This requirement requires  a target risk assessment to  establish a frequency for traditional scanning. QSAs will want to see documented analysis within the TRA and the organizations’ ability to demonstrate the frequency stated has been followed.

3.2.1 - None
Change: NEW
4.0 - 5.3.3 For removable electronic media, the anti- malware solution(s): 

• Performs automatic scans of when the media is inserted, connected, or logically mounted, 
  OR 
• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted. 

Note: 

• Modern anti-malware systems will perform behavioral analysis of any file executed regardless of storage location. Organizations must ensure that traditional anti-virus/malware systems are configured to immediately scan removable media when it is inserted or mounted. 
• Most anti-malware solutions can be configured to scan removable media, though the functionality is usually disabled by default due to user experience implications; scanning a large USB drive with many files can take substantial time, and be quite inconvenient.
• Organizations using a continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted are not required to enable an automatic scan of media upon insertion, connection, or logical mounting.

3.2.1 - None
Change: NEW

4.0-5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks. 
Note:

• These processes and mechanisms must be more than simple warnings about potential phishing. The requirement is for processes and automated mechanisms that cannot just detect phishing attempts but will actually protect end-users.
• This controls  requires actions probably on email servers even if those are outside the PCI CDE. There are solutions out there today, and some cloud-based solutions like Gmail and Microsoft Defender for Office365 already have anti-phishing options included.

Terminology: In this requirement, 
"cardholder data"  is replaced by "PAN's"
"cardholder environment" is replaced by "CDE"

New controls: 
2 controls have been amended to this requirement to: 

• Require assignment and documentation of the Roles and responsibilities for performing activities in Requirement 4 (Req 4.1.2)
• Require an up to date inventory of the keys and certificates used to protect PAN during transmission. Note: this implies that organizations have a clear view of all certificates and keys used and that they can maintained this inventory whenever certificates and keys are rotated and changes. For some organizations this could be quite cumbersome. 

Amendments: 
Requirement 3.2.1 - 4.1 on the use of strong cryptography and security protocols for the transmission of PAN's has been amended to stress that the certificates used for this purpose be valid, not expired  nor revoked. Note: When the sending and receiving parties are different (e.g. merchants and Processors) it is unclear if this control apply also to the sending party. If it is the case, this control may be a bit of a challenge as it the sending party has to validate a certificate on the connection endpoint. Potentially, specific codes will have be to be integrated in applications to do so and invalidate the connection should non-valide certificate be presented by the receiving party. 

Moved:
None

Removed:
None

​Attention point:
Also consider in the scope of Req 4 the following NEW control of Req 3: 3.7.9 Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers.

​Title
3.2.1 - Encrypt transmission of cardholder data across open, public networks 

4.0 - Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks

3.2.1 - 4.1Use strong cryptography and security protocols to safeguard sensitive cardholder data during transmission over open, public networks, including the following: 

• Only trusted keys and certificates are accepted. 
• The protocol in use only supports secure versions or configurations. 
• The encryption strength is appropriate for the encryption methodology in use. 

Change: Reformulation+ Amendement

4.0 - 4.2.1Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks: 

• Only trusted keys and certificates are accepted. 
• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. 
• The protocol in use supports only secure versions or configurations and does not support fallback to, or use of insecure versions, algorithms, key sizes, or implementations. 
• The encryption strength is appropriate for the encryption methodology in use.

3.2.1  - 4.1.1Ensure wireless networks transmitting cardholder data or connected to the cardholder data environment, use industry best practices to implement strong encryption for authentication and transmission. 
Change: Reformulation

4.0 - 4.2.1.2 Wireless networks transmitting PAN or connected to the CDE use industry best practices to implement strong cryptography for authentication and transmission. 

3.2.1 - 4.2Never send unprotected PANs by end- user messaging technologies (for example, e- mail, instant messaging, SMS, chat, etc.). 
Change: Reformulation

4.0 - 4.2.2 PAN is secured with strong cryptography whenever it is sent via end-user messaging technologies.

3.2.1 - 4.3 Ensure that security policies and operational procedures for encrypting transmissions of cardholder data are documented, in use, and known to all affected parties. 
Change: Reformulation

4.0 - 4.1.1 All security policies and operational procedures that are identified in Requirement 4 are: 
• Documented. 

• Kept up to date. 
• In use. 
• Known to all affected parties.

3.2.1 - None
Change: NEW

4.0 - 4.1.2 Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.

3.2.1 - None
Change: NEW

4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained

Change of terminologies: 

• "The first 6 digits of a PAN" is replaced by "BIN".
• "Cardholder data" is replaced by "Account data"

New controls: 
5 controls have been added to this requirement: 

• 4.0 - 3.1.2 Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood. 
• 4.0 - 3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is:  Limited to that which is needed for a legitimate issuing business need and is secured. Encrypted using strong cryptography. 
• 4.0 - 3.5.1.1 Hashes used to render PAN unreadable  shall be keyed cryptographic hashes  with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7. Note: This implies that  organizations using SHA256 for instance for the hashing of PAN's need to use HMAC_SHA256 or similar. 
• 4.0 - 3.7.9 Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers. 

Amendments: 
Multiples controls have been amended to include the following controls:

• The policies and procedures shall cover all locations of stored account data as well as sensitive authentication data (SAD) stored prior to completion of authorization. 
• Disk -level encryption shall be implemented on removable electronic media OR If used for non-removable electronic media, PAN shall also be rendered unreadable. Authentication factors allowing access to unencrypted data are stored securely. Note: This stresses that that column and field-level encryption within the database is acceptable, but databases which encrypt the entire partition (disk) are prohibited.  Organizations which rely on disk encryption to store and/or exchange files will need to implement file-level encryption to protect files on disk. Organization’s using Transparent Disk Encryption to protect database partitions will need to implement column-level encryption for columns which contain cardholder data. 
• Cryptographic keys used in production and test environments shall be different. 
• Inventory of cryptographic components shall cover key management systems (KMS)
• A defined cryptoperiod shall be documented or each key type in use. 

Moved
One control of clause 12 has been moved and restated into requirement 3 (See detailed analysis)

Removed
None

Titre
3.2.1 - Protect stored cardholder data  / 4.0 - Protect Stored Account Data ​

3.2.1 - 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage:

• Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements
• Processes for secure deletion of data when no longer needed
• Specific retention requirements for cardholder data
• A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.

​Change: Reformulation + Amendments

4.0 - 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: 

• Coverage for all locations of stored account data. 
• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. 
• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements. 
• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification. 
• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy. 
• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

3.2.1  - 3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process. 

Change: Reformulation + Amendments 

4.0 - 3.3.1 SAD is not retained after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process. 
4.0 - 3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

3.2.1 - 3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization. This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data 

Change: Reformulation

4.0 - 3.3.1.1 The full contents of any track are not retained upon completion of the authorization process.

3.2.1 - 3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not- present transactions) after authorization. 

Change: Reformulation

4.0 - 3.3.1.2 The card verification code is not retained upon completion of the authorization process.

​3.2.1 - 3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization. 

Change: Reformulation + Clarification

4.0 - 3.3.1.3 The personal identification number (PIN) and the PIN block are not retained upon completion of the authorization process.

3.2.1 - 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN. 

​Change: Reformulation + Clarification

4.0 - 3.4.1 PAN is masked when displayed (the BIN and last four digits are the maximum numberof digits to be displayed), such that only personnel with a legitimate business need can see more thanthe BIN and last four digits of the PAN.

3.2.1 - 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: 

• One-way hashes based on strong cryptography, (hash must be of the entire PAN) 
• Truncation (hashing cannot be used to replace the truncated segment of PAN) 
• Index tokens and pads (pads must be securely stored) 
• Strong cryptography with associated key-management processes and procedures. 

​Change:  Reformulation, Clarification

4.0 - 3.5.1 PAN is rendered unreadable anywhere it is stored by using any of the following approaches: 

• One-way hashes based on strong cryptography of the entire PAN. 
• Truncation (hashing cannot be used to replace the truncated segment of PAN). 

– If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN. 

• Index tokens. 
• Strong cryptography with associated key- management processes and procedures.

3.2.1 - 3.4.1 If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts. 

Change : Reformulation + Amendments + Split

4.0 - 3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows: 

• On removable electronic media OR 
• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1. 

4.0 -  3.5.1.3 If disk-level or partition-level encryption is used (rather than file-, column-, or field--level database encryption) to render PAN unreadable, it is managed as follows: 

• Logical access is managed separately and independently of native operating system authentication and access control mechanisms. 
• Decryption keys are not associated with user accounts. 
• Authentication factors (passwords, passphrases, or cryptographic keys) that allow access to unencrypted data are stored securely.

3.2.1 - 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse: 

Change: Reformulation + Amendments

4.0 - 3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: 

• Access to keys is restricted to the fewest number of custodians necessary. 
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect. 
• Key-encrypting keys are stored separately from data-encrypting keys. 
• Keys are stored securely in the fewest possible locations and forms.

3.2.1 - 3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes: 

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date 
• Description of the key usage for each key 
• Inventory of any HSMs and other SCDs used for key management 

Change : Reformulation + Clarification + Amendment

4.0 - 3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes: 

• Details of all algorithms, protocols, and keys used for the protection of stored account data, including key strength and expiry date. 
• Preventing the use of the same cryptographic keys in production and test environments. 
• Description of the key usage for each key. 
• 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.

3.2.1 - 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians necessary. 

​Change: Reformulation + Merge

4.0 - ​3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: 

• Access to keys is restricted to the fewest number of custodians necessary. 
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect. 
• Key-encrypting keys are stored separately from data-encrypting keys. 
• Keys are stored securely in the fewest possible locations and forms.

3.2.1 - 3.5.3 Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: 

• Encrypted with a key-encrypting key that is at least as strong as the data- encrypting key, and that is stored separately from the data-encrypting key 
• Within a secure cryptographic device (such as a hardware (host) security module (HSM) or PTS-approved point-of-interaction device) 
• As at least two full-length key components or key shares, in accordance with an industry- accepted method 

Change: Reformulation + Split/Shuffling + Redundancy

4.0 - 3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: 

• Access to keys is restricted to the fewest number of custodians necessary. 
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect. 
• Key-encrypting keys are stored separately from data-encrypting keys. 
• Keys are stored securely in the fewest possible locations and forms. 

4.0 - 3.6.1.2 Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times: 

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and that is stored separately from the data- encrypting key. 
• Within a secure cryptographic device (SCD), such as a hardware security module (HSM) or PTS-approved point-of-interaction device. 
• As at least two full-length key components or key shares, in accordance with an industry-accepted method.

3.2.1 - 3.5.4 Store cryptographic keys in the fewest possible locations. 

Change: Reformulation + Redundancy

4.0 - 3.6.1.4 Cryptographic keys are stored in the fewest possible locations. 

4.0 - 3.6.1 Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include: 

• Access to keys is restricted to the fewest number of custodians necessary. 
• Key-encrypting keys are at least as strong as the data-encrypting keys they protect. 
• Key-encrypting keys are stored separately from data-encrypting keys. 
• Keys are stored securely in the fewest possible locations and forms.

3.2.1 - 3.6 Fully document and implement all key- management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following: 

Change: Split

4.0 - 3.7.1 to 3.7.8

3.2.1 - 3.6.1 Generation of strong cryptographic keys 

Change: Reformulation

4.0 - 3.7.1 Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data.

3.2.1 - 3.6.2 Secure cryptographic key distribution 

Change: Reformulation

4.0 - 3.7.2 Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.

3.2.1 - 3.6.3 Secure cryptographic key storage 

​Change: Reformulation

4.0 - 3.7.3 Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data.

3.2.1 - 3.6.4 Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of cipher-text has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57). 

Change: Reformulation + Amendments

4.0 - 3.7.4 Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following: 

• A defined cryptoperiod for each key type in use. 
• A process for key changes at the end of the defined cryptoperiod.

3.2.1 - 3.6.5 Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised. 

​Change: Change: Reformulation + Clarification

3.2.1 - 3.7.5 Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when: 

• The key has reached the end of its defined cryptoperiod. 
• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known. 
• The key is suspected of or known to be compromised. 
  Retired or replaced keys are not used for encryption operations.

​3.2.1 - 3.6.6 If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control. 

Change: Reformulation

4.0 - 3.7.6 Where manual cleartext cryptographic key- management operations are performed by personnel, key-management policies and procedures are implemented include managing these operations using split knowledge and dual control.

3.2.1 - 3.6.7 Prevention of unauthorized substitution of cryptographic keys. 

​Change: Reformulation

4.0  - 3.7.7 Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.

3.2.1 - 3.6.8 Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key- custodian responsibilities 

​Change: Reformulation + Clarification

4.0 - 3.7.8 Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

3.2.1 - 3.7 Ensure that security policies and operational procedures for protecting stored cardholder data are documented, in use, and known to all affected parties. 

Change: Reformulation

4.0 - 3.1.1 All security policies and operational procedures that are identified in Requirement 3 are:
• Documented.
• Kept up to date.
• In use.
• Known to all affected parties.

3.2.1 - 12.3.10 For personnel accessing cardholder data via remote-access technologies, prohibit the copying, moving, and storage of cardholder data onto local hard drives and removable electronic media, unless explicitly authorized for a defined business need. Where there is an authorized business need, the usage policies must require the data be protected in accordance with all applicable PCI DSS Requirements. 

Change: Move and reformulation

4.0  - 3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.

3.2.1 - NONE
Change: NEW

4.0 - 3.1.2 Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.

3.2.1 - None
Change:  NEW

4.0 - 3.3.3 Additional requirement for issuers and companies that support issuing services and store sensitive authentication data: Any storage of sensitive authentication data is: 
Limited to that which is needed for a legitimate issuing business need and is secured. 
Encrypted using strong cryptography.

3.2.1 - None
​Change:  NEW

4.0 - 3.5.1.1 Hashes used to render PAN unreadable  are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.

3.2.1 - None
Change: NEW

4.0 3.6.1.3 Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.

3.2.1 - None
Change: NEW
​
4.0 - 3.7.9 Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers.