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.

As a continuation to our previous article discussing the impact of pCI 4.0 on Requirement 1, we here below cover Requirement 2. 

​Impact of the new PCI 4.0 on the former 3.2.1  requirement 2 are in the form of : Reformulation, Clarification, Amendement and removal.

New controls: 
2.1.2 about the roles and responsibilities for this requirement
2.3.2  clarifying when the wireless encryption keys shall be changed.

Amendments: 
2.3.1 wireless vendor defaults are changed at installation or are confirmed to be secure
2.2.1 Configuration standards are developed, implemented, and maintained, be updated as new vulnerability issues are identified, be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.
2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

Moved:
3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS ->  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.

Removed:
3.2.1 - 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.

​3.2.1 - 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.
Change:  Reformulation + Clarification

4.0 - 2.2.2 Vendor default accounts are managed as follows:
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.

​3.2.1  - 2.1.1 For wireless environments connected to the cardholder data environment or transmitting cardholder data, change wireless vendor defaults, including but not limited to default wireless encryption keys, passwords, and SNMP community strings.
Change: Reformulation + Clarification + Amendement

4.0 - 2.3.1 For wireless environments connected to the CDE or transmitting account data, all wireless vendor defaults are changed at installation or are confirmed to be secure, including but not limited to:
• Default wireless encryption keys.
• Passwords on wireless access points.
• SNMP defaults.
• Any other security-related wireless vendor defaults.

3.2.1 - NONE
Change : New  + Clarification

4.0 - 2.3.2 For wireless environments connected to the CDE or transmitting account data, wireless encryption keys are changed as follows:
• Whenever personnel with knowledge of the key leave the company or the role for which the knowledge was necessary.
• Whenever a key is suspected of or known to be compromised.

3.2.1 - 2.2 Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Change: Reformulation + Amendments

4.0 - 2.2.1 Configuration standards are developed, implemented, and maintained to:
• Cover all system components.
• Address all known security vulnerabilities.
• Be consistent with industry-accepted system hardening standards or vendor hardening recommendations.
• Be updated as new vulnerability issues are identified, as defined in Requirement 6.3.1.
• Be applied when new systems are configured and verified as in place before or immediately after a system component is connected to a production environment.

​3.2.1 - 2.2.1 Implement only one primary function per server to prevent functions that require different security levels from co-existing on the same server. (For example, web servers, database servers, and DNS should be implemented on separate servers.)
Change:  Reformulation + Clarification

4.0 - 2.2.3 Primary functions requiring different security levels are managed as follows:
• Only one primary function exists on a system component,
OR
• Primary functions with differing security levels that exist on the same system component are isolated from each other,
OR
• Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.

​3.2.1 - 2.2.2 Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system.  Implement security features for any required services, protocols or daemons that are considered to be insecure—for example, use secured technologies such as SSH, S-FTP, TLS or IPSec VPN to protect insecure services such as NetBIOS, file-sharing, Telnet, FTP, etc.

Change: Reformulation + Removal (due to redundancy)

4.0 - 2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

​3.2.1 - 2.2.3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Change:  Reformulation + Amendement

4.0 - 2.2.5 If any insecure services, protocols, or daemons are present:
• Business justification is documented.
• Additional security features are documented and implemented that reduce the risk of using insecure services, protocols, or daemons.

​3.2.1 - 2.2.4 Configure system security parameters to prevent misuse.
Change: Reformulation

4.0 - 2.2.6 System security parameters are configured to prevent misuse.

​3.2.1 - 2.2.5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers.
Change: Bundle

2.2.4 Only necessary services, protocols, daemons, and functions are enabled, and all unnecessary functionality is removed or disabled.

​3.2.1 - 2.3 Encrypt all non-console administrative access using strong cryptography.
Change: Reformulation

4.0 - 2.2.7 All non-console administrative access is encrypted using strong cryptography.

3.2.1 - 2.4 Maintain an inventory of system components that are in scope for PCI DSS.
Change: Moved to Section 12

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 - 2.5 Ensure that security policies and operational procedures for managing vendor defaults and other security parameters are documented, in use, and known to all affected parties.
Change: Reformulation

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

​3.2.1 - 2.6 Shared hosting providers must protect each entity’s hosted environment and cardholder data. These providers must meet specific requirements as detailed in Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers.
Change: Removed

3.2.1 - NONE
Change: NEW

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

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

The impact of the new PCI 4.0 on the 3.2.1 requirement 1 are in the form of Reformulation, Clarification, Splitting / bundling, Scope extension and Removal.

The scope extension expresses itself through terminology changes, namely: 

• Firewall(s) and router(s) are replaced by the notion of "Network Security Control(s) (NSG)". This is related to use of virtualization technologies as well as usage of cloud technologies.
• Internet is replaced by the term more general notion of "Untrusted network"
• Cardholder data environment is enlarged to the notion of "Trusted network".
• Cardholder data is replaced by "account data"

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

It all starts with the Title
3.2.1 - INSTALL AND MAINTAIN A FIREWALL CONFIGURATION TO PROTECT CARDHOLDER DATA
Becomes
4.0 - INSTALL AND MAINTAIN NETWORK SECURITY CONTROLS

3.2.1 - 1.1 Establish firewall and router configuration standards. 
Change: Reformulation + Scope

4.0 - 1.2.1 Configuration standards for Network Security Controls (NSC) rulesets are: 
• Defined.
• Implemented.
• Maintained.

3.2.1 - 1.1.1 A formal process for approving and testing all network connections and changes to the firewall and router configurations
Change: Reformulation + clarification + Scope

4.0 - 1.2.2 All changes to network connections and to configurations of NSCs are approved and managed in accordance with the change control process defined at Requirement 6.5.1.

​3.2.1 - 1.1.2 Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks.
Change: Reformulation 

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

​3.2.1 - 1.1.3 Current diagram that shows all cardholder data flows across systems and networks
Change: Reformulation + Clarification 

4.0 - 1.2.4 An accurate data-flow diagram(s) is maintained that meets the following:
• Shows all account data flows across systems and networks.
• Updated as needed upon changes to the environment.

​3.2.1 - 1.1.4 Requirements for a firewall at each Internet connection and between any demilitarized zone (DMZ) and the internal network zone

Change: Removal due to Redundancy

​3.2 1 - 1.1.5 Description of groups, roles, and responsibilities for logical management of network components
Change: Reformulation + clarification 

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

​3.2.1 - 1.1.6 Documentation of business justification and approval for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure.
Change: Reformulation + Split 

4.0 - 1.2.5 All services, protocols, and ports allowed are identified, approved, and have a defined business need.
+
4.0 - 1.2.6 Security features are defined and implemented for all services, protocols, and ports that are in use and considered to be insecure, such that the risk is mitigated.

​3.2.1 - 1.1.7 Requirement to review firewall and router rule sets at least every six months
Change: Reformulation + Scope

4.0  - 1.2.7 Configurations of NSCs are reviewed at least once every six months to confirm they are relevant and effective.

​3.2.1 - 1.2 Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.
Change: Removal due to Redundancy

​3.2.1 - 1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment.
+
3.2.1 - 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
Change: Reformulation, Split and Clarification

3.2.1 - 4.0 - 1.3.1 Inbound traffic to the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.
+
4.0 - 1.3.2 Outbound traffic from the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.

​3.2.1 - 1.2.2 Secure and synchronize router configuration files.
Change: Reformulation + Clarification

4.0 - 1.2.8 Configuration files for NSCs are:
• Secured from unauthorized access.
• Kept consistent with active network configurations.

​3.2.1  - 1.2.3 Install perimeter firewalls between any wireless networks and the cardholder data environment, and configure these firewalls to deny or control (if such traffic is necessary for business purposes) any traffic from the wireless environment into the cardholder data environment.
Change: Reformulation + Clarification + scope

4.0 - 1.3.3 NSCs are installed between all wireless networks and the CDE, regardless of whether the wireless network is a CDE, such that:
• All wireless traffic from wireless networks into the CDE is denied by default.
• Only wireless traffic with an authorized business purpose is allowed into the CDE.

​3.2.1 - 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.
Change: Reformulation and scope

4.0 - 1.4.1 NSCs are implemented between trusted and untrusted networks.

​3.2.1 - 1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.
+
3.2.1 - 1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.
Change: Reformulation + Bundle + Scope

4.0 - 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
• Stateful responses to communications initiated by system components in a trusted network.
• All other traffic is denied.

​3.2.1 - 1.3.3 Implement anti-spoofing measures to detect and block forged source IP addresses from entering the network.
Change: Reformulation

4.0 - 1.4.3 Anti-spoofing measures are implemented to detect and block forged source IP addresses from entering the trusted network.

​3.2.1 - 1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.
Change: Reformulation + Clarification

4.0 - 1.3.2 Outbound traffic from the CDE is restricted as follows:
• To only traffic that is necessary.
• All other traffic is specifically denied.

​3.2.1 - 1.3.5 Permit only “established” connections into the network.
Change: Reformulation

4.0 - 1.4.2 Inbound traffic from untrusted networks to trusted networks is restricted to:
• Communications with system components that are authorized to provide publicly accessible services, protocols, and ports.
• Stateful responses to communications initiated by system components in a trusted network.
• All other traffic is denied.

​3.2.1 - 1.3.6 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks
Change: Reformation

4.0 - 1.4.4 System components that store cardholder data are not directly accessible from untrusted networks.

​3.2.1 - 1.3.7 Do not disclose private IP addresses and routing information to unauthorized parties.
Change: Reformation + clarification

4.0 - 1.4.5 The disclosure of internal IP addresses and routing information is limited to only authorized parties.

​3.2.1 - 1.4 Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. 
Change: Reformation + clarification + Scope

4.0 - 1.5.1 Security controls are implemented on any computing devices, including company- and employee-owned devices, that connect to both untrusted networks (including the Internet) and the CDE as follows:
• Specific configuration settings are defined to prevent threats being introduced into the entity’s network.
• Security controls are actively running.
• Security controls are not alterable by users of the computing devices unless specifically documented and authorized by management on a case-by-case basis for a limited period

​3.2.1 - 1.5 Ensure that security policies and operational procedures for managing firewalls are documented, in use, and known to all affected parties.
Change: Reformulation + Scope + clarification

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