.svg){kind=icon}
.svg)
PCI DSS v4 Mix and Match
Timeline
PCI DSS v4 was released in March 2022, and SAQs and supporting documents in April 2022, with a smaller update in December 2022.
With the release of PCI DSS 4.0, the sunset date for PCI DSS v3.2.1 was set to March 31, 2024, with future date new requirements coming into play on March 31, 2025. This means that you can validate using PCI DSS 3.2.1 until the sunset date and that you are expected to adhere to the PCI DSS 4.0 standard as of April 1, 2024.
In the same capacity, you can exclude future-dated requirements from validation up until March 31, and you are expected to have the new future-dated requirements implemented on April 1, 2025.
At first glance, this seems like a rather long transformation period; however, there are a few things to consider.
- New requirements that have long lead implementation times.
- Budgets are needed to support the implementation or improvement of controls.
- Resources needed to make the required changes.
VikingCloud performs over 1000 assessments annually, and up to 99% of the entities we assess use a Third Party Service Provider (TPSP). This means that it is more than likely that you are in that situation.
This could impact your transformation to PCI DSS 4.0.
When you embark on your PCI DSS v4 transformation, you will likely use a TPSP validated under v3.2.1 of the standard. Although they would still have to adhere to the new version of the standard as of April 1st, , 2024, a TPSP might provide you with an AoC showing compliance with PCI DSS 3.2.1 up to March 31st, 2025.
In what ways might this impact your transformation to PCI DSS v4? First of all, there is an official FAQ that was updated as late as November 2022.
If you are using a payment service provider to process all your transactions, FAQ 1282 is clear; however, there are instances where you might run into some challenges. In addition, there might be further guidance released on the topic from the SSC. You should, however, plan for the worst and hope for the best. Iâ'll expand on this by providing a few instances where you might run into challenges and what you can do to address them.
When you are outsourcing part of your environment to a TPSP and you are validating using PCI DSS v4 of the standard and your TPSP has been validated using PCI DSS 3.2.1, there will be an obvious mismatch when it comes to a responsibility matrix as the numbering between the version of the standard has changed.
You will then have to work with your TPSP in one of the following ways:
- Ask your TPSP to provide an up-to-date responsibility matrix based on PCI DSS v4 of the standard.
- Work with your TPSP to define the requirements and controls that belong to you, the service provider, or are shared using your v4 responsibility matrix and their v3.2.1 responsibility matrix.
With the introduction of new requirements in PCI DSS v4 and the updated SAQs, there are cases where a TPSP validated under 3.2.1 still has to implement controls that meet the intent of requirements in PCI DSS v4.
Scenario
Merchants accepting card-not-present transactions where iFrame or re-direct is implemented using a Payment Service Provider validated under PCI DSS 3.2.1 and a TPSP validated under PCI DSS 3.2.1 for services provided and they are providing an e-Commerce environment as part of their services.
The merchant will likely validate compliance using SAQ A or applicable requirements in a level 1 assessment where a RoC is the outcome.
Regarding your Payment Service Provider providing the hosted payment pages, it is relatively straightforward, and it should not matter if they are compliant with PCI DSS v3.2.1 or PCI DSS v4.0.
If, however, you are using a TPSP to host your eCommerce site, it's not so straightforward. For example, let's take a look at the requirement to perform ASV scans. The TPSP may check the box that they are responsible for ASV scans, however, that may cover only the service provided as they scan their own websites, but it is unlikely that it covers your website. In this scenario, you would be responsible for scanning your website“ see diagram below.
You need to check the AoC and the responsibility matrix to do the mapping and, in some cases, even the RoC to ensure you understand what you need to do and what is on the TPSP.
Let's continue looking at the ASV scans, as this relates to PCI DSS v4 and SAQ A.
First, PCI DSS 3.2.1 and v4 of the standard say that web redirection servers are in scope of PCI DSS. SAQs for v4 were released in April, with an update in December 2022.
What does this mean?
As you transform into adhering to PCI DSS v4.0, your eCommerce website and specifically the part that provides the redirect or the iFrame needs to be scanned by an ASV as per requirement PCI DSS v4 requirement 11.3.2.
If you are outsourcing your eCommerce website to a TPSP, and they are validated using PCI DSS 3.2.1, I suggest you either ensure they start to perform ASV scans or you ensure they are performed, all depending on responsibilities and contracts, etc.
If you are new to performing ASV scans, please ensure to whitelist the ASV IP, or else you risk having a challenge with interference due to your security controls.
Conclusion
- Start your transformation to PCI DSS 4.0 as soon as possible.
- Plan to have the transformation to PCI DSS v4.0 for applicable requirements no later than March 31st, 2024.
- Kickstart projects to implement controls for the future dated requirements and have them implemented no later than March 31st, 2025.
- Work with your TPSP to ensure you agree on who is responsible for what and that you have the responsibilities documented.
Contact the VikingCloud team to find out more about how we can help your organization's transformation to PCI DSS v4.0.
.webp)
