Overview
- 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.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.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
Detailed Analysis
3.2.1 - Maintain a policy that addresses information security for all personnel.
4.0 - Support Information Security with Organizational Policies and Programs
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.
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.
- 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.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.
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
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.
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.
- Overall accountability for maintaining PCI DSS compliance
- Defining a charter for a PCI DSS compliance program and communication to executive management
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.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.
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.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.
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.
Change: Removal
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.
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.
Change: reformulation
4.0 - 12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
Change: Reformulation
4.0 - 12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
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.
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.
Change: Removed
- 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.
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.
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.
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.
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 - 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.
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.
- Daily log reviews
- Firewall rule-set reviews
- Applying configuration standards to new systems
- Responding to security alerts
- Change management processes
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.
- Documenting results of the reviews
- Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.