PCI DSS v4.0 blog entry for September
Timeline for PCI DSS v4.0 migration – What are the next steps?
With March 31, 2024, the end of PCI DSS v3.2.1 is approaching. All merchants accepting payments with cards of the international payment brands Visa, Mastercard, American Express, Discover, JCB, or UnionPay, and all service providers supporting them, should be prepared for PCI DSS v4.0.
But what should be done in particular, and when?
Gap analysis
The first step should be a gap analysis. Anyone who has not yet checked which new requirements come up to them with PCI DSS v4.0 should do so as soon as possible! The reasons are obvious:
- Implementing new requirements will require time and resources.
- PCI DSS professionals who can advise on implementation are already well booked.
During the gap analysis, the new requirements must be read, understood, and aligned with the existing landscape of controls. To understand the requirements, it is extremely helpful to read not only the requirement itself, but also the extensive guidance that the PCI SSC has provided alongside each requirement within the standard:
- The “Guidance” column (to the right of the requirement),
- the objective being pursued by the requirement (below the requirement),
- and, if available, the applicability note (below the requirement).
The introductory chapters of PCI DSS v4.0 and the glossary in Appendix G can also support in understanding terminology and applicability.
If you work with a PCI DSS expert at present, feel free to draw on their expertise and experience within this step already.
Prioritisation
When all open items have been identified, timeframes and responsibilities should be assigned. When assigning timeframes, the following should be considered:
- How long will the implementation take?
The implementation of new technical solutions often takes a long time due to internal dependencies. Often this comes together with low human resources. Issues that are expected to take a long time to implement need to be addressed earlier than those where a quick completion is expected.
- Are targeted risk analyses required?
In v4.0, for many regular tasks the frequency of performance is no longer predefined, but is to be determined by a targeted risk analysis. The implementation of such targeted risk analyses must be coordinated internally and hence requires time.
- Are there periods that are particularly good or bad for implementation?
g. for policy changes, it can make sense to consider document review cycles. For technical changes, it makes sense to consider any freeze periods or release periods that have already been planned. - Is the PCI DSS v4.0 deadline for this requirement 2024 or 2025?
For many fundamentally new requirements in PCI DSS v4.0, the applicability notes state that the requirement is considered best practice until 31 March 2025, after which it is mandatory.
Requirements without this note must be implemented by 31 March 2024 and might therefore require a higher prioritisation
Decisions
For some new requirements, there are different ways to implement them. Examples are:
- Requirement 3.4.2 calls for preventing copying/moving of PAN when accessing remotely (except for personnel with appropriate business need). There can be several ways to implement this, too — e.g. via a setting in RDP when using the remote connection, or by preventing highlighting/copying/mouse-right-clicking on PAN displays on according web pages.
- Requirement 8.4.2 requires multi-factor authentication (MFA) when accessing the Cardholder Data Environment (CDE).Depending on how the access towards the CDE takes place, it may make sense to enforce MFA at network level, at system level, or at application level. This decision must be well weighed with the various parties involved. Several parties may even have to work together on the solution.
Weigh up the impact of different solutions at an early stage!
Tracking and Assessing
Once you have prioritised your tasks and decided on implementation paths: please do not sit back! The person or team responsible for maintaining PCI DSS compliance should stay in contact with the teams responsible for the implementation.
- Are there any enquiries/comprehension issues?
- Do any problems with the implementation arise?
- Is the agreed target date at risk?
As soon as a new solution has been implemented, it should be checked whether it meets the corresponding PCI DSS requirement. External PCI DSS experts can also support with small interim pre-assessments in order to be on the safe side for the next official annual assessment.
Continuous Process
Once a requirement is met, there is no guarantee that it will remain so. Card data usage, technologies and attack vectors change. Already today, PCI DSS v3.2.1 comprises regular tasks for maintaining PCI DSS compliance. With PCI DSS v4.0, this is becoming even more of an ongoing process.
Therefore, get into the habit of putting your controls to the test repeatedly, and of adhering to the timeframes for recurring activities (now precisely defined in chapter 7 of the PCI DSS). This will also make it easier for you to comply with new corresponding requirements, such as e.g.
- 2.4 / 7.2.5.1 Review of user accounts and assigned access rights,
- 3 Review of risk assessments and review of the appropriateness and security of cryptographic algorithms, hardware and software technologies used,
- 5 Validate the PCI DSS application scope; and
- 6.2 Review of the security awareness programme.
Above All: Start!
This is the most important step. If you haven’t started yet, today is the best day to do so. Assemble a team and schedule time.
Should you need any assistance do not hesitate to contact Jana Ehlers via email.