1
Now that the PCI DSS v4.0 deadline has passed, it’s time to start assessing and reporting on the new requirements.
What are some of the PCI DSS v4.0 reporting requirements to consider?
Though the March 31, 2024 PCI DSS v4.0 reporting deadline has passed, the countdown has begun for the future-dated requirements that become mandatory on March 31, 2025. Assessors will need to move to the new methods of evaluation. With this evaluation change comes new requirements that affect how the assessment and reporting is done within the PCI DSS SAQs (Self Assessment Questionnaires). Some specifics include consideration for any new “customized approach” controls that may be used in the assessment. Customized controls (technologies and innovations) must continue to meet the security objectives of the requirements they are aligned with, and could involve extra assessment time needed to conduct an AOC (attestation of compliance).
Secondly, extra analysis time and effort will be needed to ensure adequate attention is given to assess and report on the many new and updated requirements in PCI v.4.0. There are new requirements around threat detection and prevention, authentication, and administrative control that will need to be built into the reporting process. Old reporting templates that are possibly built into automation programs or custom applications will need to be fitted with the applicable new requirements that come became effective on March 31, 2024.
2
Understand the main and relevant changes in the new version of the standard that will affect your new assessment reporting requirements.
PCI DSS v.4.0 has one of the largest number of changes to the standard, with over 200 updates. As of March 31, 2024, assessments will have to incorporate these new changes. There are requirements with new rewording, order, and brand new sections included. There are many net “new” requirements that have been introduced as well. Some of these new requirements have been introduced as a best practice and will come into effect in 2025, only a year after the standard is introduced. Those particular new requirements did not become mandatory on March 31, 2024, but the analysis of such requirements chould be necessary in order to effectively complete one’s report on compliance successfully.
As we mentioned before, one of the major changes is the introduction of the new customized approach to assessment, which allows for alternate controls to be used to satisfy compliance. This introduces new flexibility to comply with requirements that businesses already have a mature stance on.
Some of the other changes include:
Additional controls targeted at detection and prevention of the current threats against payment systems.
A move from “firewall” to “network security controls” in Requirement 1 to reflect the advancement of new security technologies available.
Updated authentication and password requirements for those that work within or could impact the CDE (Card Data Environment).
Additional scrutiny around process and policy as it pertains to the role and responsibilities of stakeholders to ensure compliance with the standard. This is aligned with the industry’s move toward better defining the governance perspective of an enterprise in satisfying security policy and compliance requirements.
New documentation requirements such as 12.5.2 (the entity’s PCI scope must be documented and confirmed annually), which is substantial as it requires a complete scoping process, adding scrutiny and time requirements to compliance and assessment if the process was traditionally done in-line with the audit.
Requirement 11.3.2.1 says vulnerability scans must be completed after significant changes. This is another substantial change as it requires more frequency and scrutiny of the vulnerability and gaps assessment process. This change is directly in-line with wider moves towards more proactive vulnerability prioritization, ranking, and remediation.
As a first step, companies can start to incorporate the new controls in parallel with their existing 3.2.1 assessments to understand what their posture will look like against version 4.0., and where they can save time and effort using the new approach to assessment.
3
Review your company’s overall PCI DSS scope and understand how it has changed.
Another compelling change in PCI DSS v.4.0 is the expansion of what is considered in-scope for PCI DSS, adding new elements to assessments.
The increased scope in v4.0 includes:
- In requirement 3, the addition of personal account data: data which could include user IDs, identifying information and other forms of account data that could be associated with credit card data.
- Network security controls rather than only firewalls in requirement 1 which could add to the technologies that need to be assessed. (i.e., NSCs are now required between all wireless networks and the CDE, even if the wireless network is part of the CDE, according to Requirement. 1.3.3)
Businesses need to ensure they have considered all the assets, systems, users, and processes that could now impact their compliance operations. Let’s dive into a few things you should be thinking about.
Update the enterprise inventory to ensure all systems are up to date and relevant to your BAUs (Business as Usual).
An inventory of all hardware and software components that are in scope for PCI DSS is necessary to support PCI DSS Requirement 2 in both 3.2.1 and 4.0.
Having an up-to-date inventory of all systems and components within the cardholder data environment— and one that can be reassessed as needed—will help to ensure that you are reporting on your PCI posture and how it may change when moving from the 3.2.1 to the 4.0 version of the standard.
For version 4.0, the added flexibility of a dynamic, continuously updated feed of enterprise inventory—over previous snapshots gathered on a periodic basis—will provide acceleration to your assessment when your PCI DSS scope changes or grows. A proactive view of all your enterprise assets with their relation to each other will help to ensure you have irrefutable evidence at the ready when producing your report on PCI compliance.
Review existing compensating controls to ensure they are still compliant and relevant when moving over to the new requirements.
Compensating controls that have been used to temporarily meet PCI DSS compliance need to be reviewed under normal circumstances. Particular attention must be paid to review these compensating controls when moving to 4.0, as some compensating controls may no longer fulfill the new standard. And systems that have changed in utility or risk may need to be addressed to ensure you remain compliant under the new standard.
For example, a good place to start would be to review and report on any EOL systems (i.e., Windows 7) that may be within your environment or those that will become EOL. They can wreak havoc on compensating controls that are in place to maintain PCI DSS compliance.
Review vulnerability assessment systems and policies to ensure they will be adequate to meet the new requirements introduced within PCI DSS v.4.0.
PCI DSS v.4.0 has introduced a new level of vulnerability prioritization with the addition of requirement 6.2.1, and 6.3.1.
6.2.1 Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
- In accordance with PCI DSS (for example, secure authentication and logging)
- Based on industry standards and/or best practices.
- Incorporating information security throughout the software-development life cycle
Note: this applies to all software developed internally as well as bespoke or custom software developed by a third party.
6.3.1 Security vulnerabilities are identified and managed as follows:
- New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs).
- Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
- Risk rankings identify, at a minimum, all vulnerabilities considered to be high-risk or critical to the environment.
- Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.
With the additional scope of business types and enterprise assets now in focus, you will need to apply extra rigor to the process of vulnerability identification and risk ranking and ensure that you have clear and definitive evidenced-based-data to back up your findings.
Additionally, make sure that you have the technology in place to perform gap analysis and vulnerability identification aligned with your security stack if you are a SAQ A merchant, who will now have to perform vulnerability exercises under the new version of the standard. Examples of such technology that could enable these merchants would be configuration control and management based solutions fueled by security gap or vulnerability intelligence engines providing the overall view of missing controls across the security stack.
Revisit systems that were included within the retail freeze and check they have the latest security patches or controls.
Most retail merchants will have systems that have gone into retail freeze during the holiday period which happened to take place a few months before the PCI DSS 4.0 reporting deadline. As both highly utilized retail systems and backup architecture is brought back into the fold after the holiday, ensure these systems are in a state that will enable PCI DSS 4.0 compliance. Run an additional inventory check on such systems for risk to the enterprise in order to avoid any possible roadblocks or barriers to your assessment program.
4
Revisit technologies and processes that move your enterprise to continuous compliance control monitoring.
Another major theme within the new 4.0 version of the standard is to move your enterprise closer to continuous compliance assessment with evidence-based-data to back up your findings. (i.e., Requirement 6.3.1 “This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability”
The days of intermittent and point in time compliance reporting are over. So when assessing change management, inventory control, baseline security, and configuration management, use solutions that can monitor evolving baselines, assess change when it happens, triangulate vulnerabilities to assets continuously, and report on deltas of risk.
Review or create a risk assessment program that can be accessed at any point in your compliance journey.
In the 4.0 release, the risk assessment is not merely a process that’s performed in requirement 12 any longer, but an ongoing task built into the entire framework of the standard. Security control risk tolerance and risk to controls are measured carefully in most requirements as indicators of your cybersecurity posture. If you haven’t thought of creating a risk assessment program, even at a basic level, it’s a good time to review that process and get started. The 3.2.1 version of the PCI DSS lays out examples of the risk assessment in requirement 12.2 and is a good place to start to learn how to run it as a formal program.