In this penultimate article in our ongoing series of Analysis of PCI DSS v4.0, we analyze the changes to Requirement 12 in version 4.0, which is part of Group 6 "Maintain an Information Security Policy".
Click here to read the Analysis of DSS DSS v4.0 Part 6: Requirements 10 & 11
Requirement 12: Support Information Security with Organizational Policies and Programs
The last requirement of the PCI DSS describes the administrative and documentary guidelines that must be implemented throughout the lifecycle of physical and logical controls related to the protection of account data. In version 4.0 the name of this requirement was changed to emphasize the need for policies and programs to support information security efforts in the organization, as opposed to the name of the same requirement in version 3.2.1 which only referred to maintaining an information security policy for all personnel.
Along with the requirement name changes, the following controls were updated/added:
- The security policy should clearly include roles and responsibilities related to information security. These responsibilities must be accepted by related personnel (12.3.1).
- A member of the organization's executive management is required to assume information security responsibilities. This role can be the CISO (Chief Information Security Officer) or any other knowledgeable role within the board of directors (12.1.4).
- Unlike PCI DSS v3.2.1 where there were several controls related to the use of critical technologies, in PCI DSS v4.0 these controls have been unified. Now only the existence of acceptable use policies for end-user technologies, the explicit approval by authorized parties, the acceptable uses of such technologies, and the list of products approved by the company for use by its employees, including hardware and software are required (12.2.1).
- Probably one of the most representative changes in PCI DSS Requirement 12 was the focus on the execution of the risk analysis. In PCI DSS v4.0, a specific and targeted risk analysis is required to be performed exclusively on those PCI DSS controls where the entity is allowed to choose the related execution period and where the customized approach is used.
This new approach is called Targeted Risk Analysis which aims to:
- Determine how frequently a requirement with flexible periodicity must be performed to minimize the likelihood of the threat being realized. As a minimum, this risk analysis should be reviewed every 12 months (12.3.1). This control is applicable as of 31 March 2025.
- Review and document the evidence required when the customized approach is used to meet with a particular control. In this case, documented management approval is required and should be performed every 12 months (12.3.2).
- Due to the vulnerabilities identified in cryptographic algorithms, the PCI SSC has included in PCI DSS version 4.0 a specific control to review the security levels of cryptographic algorithms used for the protection of account data
(12.3.3). In this regard, the following is required:
- An up-to-date inventory of all cipher suites and protocols in use, including their rationale and where they are used.
- Monitoring the feasibility of using the algorithms in use.
- Documented strategy for responding to changes in cryptographic vulnerabilities.
- Along the same lines -and to prevent the continued use of obsolete technologies in the organization - a proactive review of hardware and software technologies that will no longer be supported by their manufacturers (End-of-Life - EOL) is required, including a plan approved by Management to remediate obsolete technologies (12.3.4). This control is applicable as of 31 March 2025.
With this, the execution of the company's global risk analysis (as required by PCI DSS v3.2.1) has gone from being a requirement to being a recommendation.
- For service providers, all requirements related to PCI DSS compliance management have been centralized in control 12.4: Responsibilities (12.4.1), review of operational security tasks (12.4.2) and documentation of these results (12.4.2.1).
- The control related to system component inventory in the PCI DSS scope - that was in control 2.4 of PCI DSS v3.2.1 - has been relocated to control 12.5.1 of PCI DSS v4.0.
- To avoid the endless discussion that existed in PCI DSS v3.2.1 related to the responsibility for defining and updating the scope of PCI DSS compliance, in version 4.0 of this standard a new control has been explicitly included (12.5.2) in which the entity must review at least every 12 months (in the case of merchants) and every 6 months (in the case of service providers) the PCI DSS scope, including data flows, diagrams, system components, segmentation controls and connections with third parties.
- For service providers, if there are significant changes to the organizational structure that may impact PCI DSS compliance, their impact on scope and controls is required to be documented and communicated to management (12.5.3).
- In terms of security awareness:
- It is clarified that training should be aligned with the role of each person in account data protection (12.6.1).
- The training material should be reviewed at least every 12 months and updated as necessary (12.6.2).
- Different communication methods can be used for training (12.6.3)
- Training should include threats and vulnerabilities that may impact the security of the CDE (phishing, social engineering, etc.). This control (12.6.3.1) is complementary to control 5.4.1, which defines the technical controls to detect and protect users from phishing attacks. This control is applicable as of 31 March 2025.
- Training shall include the description of acceptable uses of end-user technologies (12.6.3.2). This control is applicable from 31 March 2025.
- It is clarified that security validations prior to hiring employees must be framed within existing legal restrictions (12.7.1). As an interesting point, the guide for this control includes the use of the review of public information and social networks as an element of criteria in the screening process.
- In the management of third-party service providers (TPSPs), the term Service Provider is replaced by Third-party Service Providers (TPSPs), and it is clarified that the fact of incorporating a PCI DSS-compliant TPSP in the service does not make the client entity directly compliant with the standard (12.8.1). Similarly, service providers must provide information about their compliance and the requirements shared and under their responsibility to their customers (12.9.2).
- In the area of incident management, the following are the changes in version 4.0 of the standard:
- It has been clarified that the incident response plan should cover not only confirmed incidents but also suspected events (12.10.1).
- The periodicity of training for incident response personnel should be established based on a specific risk analysis, in accordance with control 12.3.1.
- The incident response plan must monitor and respond to alerts from change- and tamper-detection mechanisms of payment pages (12.10.5). This control is applicable from 31 March 2025.
- Finally, incident response procedures should manage events in which PAN data is detected to be stored in unauthorized locations. This control should define what to do with the PAN data once identified, review whether sensitive authentication data is also involved in addition to the PAN, determine the source of such data, and remediate any existing data leakage. This control is applicable as of 31 March 2025.
New to the Analysis of PCI DSS v4.0 series by Advantio? Follow the links below to catch up on all the articles:
References:
.png)
Comments