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. 

Impact of the new PCI 4.0 on the former 3.2.1 requirement 7 are in the form of : Reformulation, clarification and amendements, removal and migration.

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.