The recent PCI DSS v4.0 has some important changes for eCommerce merchants that use a redirect or iframe to reduce scope to Self-Assessment Questionnaire A (SAQ A). Even though the merchant’s website that meets the criteria for SAQ A does not transmit account data, the website does affect where account data is transmitted. We have seen PCI DSS requirements for these merchants steadily increase over PCI DSS versions, and it’s no surprise that there are more requirements in SAQ A for PCI DSS v4.0.
Organisations can start using v4.0 now, although it becomes mandatory from 31st March 2024, when PCI DSS v3.2.1 retires. The latest documetents for PCI DSS and SAQ can be found over on the PCI SSC website.
In the meantime, our expert team have provided a review on the eCommerce requirements in SAQ A v3.2.1. We have then highlighted new ecommerce requirements in SAQ A v4.0 below.
SAQ A v3.2.1 Ecommerce Requirements
SAQ A v3.2.1 has 24 requirements, with 9 requirements specific to eCommerce channels
summarised as follows:
| Requirement | Summary |
| 2.1 | Change or remove vendor defaults prior to installing a system (2 sub-requirements). |
| 6.2 | Install security patches on all system components and software; install critical security patches within one month of release (2 sub-requirements). |
| 8.1.1 | Assign users a unique ID. |
| 8.1.3 | Revoke access immediately for any terminated users. |
| 8.2 | All users have a password (or token, or biometric). |
| 8.2.3 | Password parameters configured to require a minimum of seven characters with both letters and numbers (or equivalent complexity). |
| 8.5 | No group or shared accounts or passwords. |
These requirements apply to the web server, which may include the operating system, web applications, and other systems on the server.
Please note that not all iframe solutions may meet the criteria for SAQ A for v3.2.1 or v4.0, depending on how they work and how the payment page may be configured, so it is worth checking against SAQ A criteria.
Additionally, the tables of SAQ A requirements in this blog only include those relating to eCommerce; other requirements include managing paper receipts (if applicable), managing service providers (the redirect or iframe must be to a compliant payment service provider’s payment page), and having a PCI DSS incident response plan.
PCI DSS v4.0 – SAQ A v4.0 Ecommerce Requirements
SAQ A v4.0 has 31 requirements, with 17 requirements specific to eCommerce channels summarised as follows:
| Requirement | Summary |
| 2.2.2 | Change vendor defaults prior to installing a system. |
| 6.3.1 | Install security patches on all system components and software. |
| 6.3.3 | Install critical security patches within one month of release. |
| 6.4.3 | Payment page scripts are authorised, integrity checked and are inventoried (best practice until 31st March 2025, then required) – applies to page redirected from or containing iframe. |
| 8.2.1 | Assign users a unique ID. |
| 8.2.2 | No group or shared accounts or passwords (unless exceptional, time-limited, approved, documented, and action attributable to individual). |
| 8.2.5 | Revoke access immediately for any terminated users. |
| 8.3.1 | All users have a password (or token, or biometric). |
| 8.3.5 | Passwords initially set (or reset) to unique value and forced change on first use. |
| 8.3.6 | Password parameters configured to require a minimum of twelve characters with both letters and numbers (best practice until 31st March 2025, then required; can use minimum of seven characters with both letters and numbers until then). |
| 8.3.7 | Passwords cannot be the same as any of the last four used. |
| 8.3.9 | If multi-factor authentication (MFA) not used, then passwords are changed every 90 days (or dynamic analysis of account security posture). |
| 11.3.2 | Quarterly external vulnerability scans from an ASV on websites on the web server, with re-scans as required until passing scans. |
| 11.3.2.1 | External vulnerability scans after any significant change, with re-scans until no more vulnerabilities with CVSS 4.0 or above. |
| 11.6.1 | For use of iframes hosting the payment service provider’s payment page, a change and tamper detection mechanism to alert personnel to changes to HTTP headers or payment page contents; the mechanism must work at least every 7 days (best practice until 31st March 2025, then required). |
As with PCI DSS v3.2.1 these requirements apply to the web server, which may include the operating system, web applications, and other systems on the server. Scope and architecture may vary, and it is important to verify the exact boundaries to determine what systems are included in the assessment for SAQ A.
The new requirements are highlighted in the table above, with some needing significant additional work. These new requirements are as follows:
Requirement 6.4.3
Requirement 6.4.3 requires that you manage JavaScript files included on pages that host the iframe or are the source of the redirect; for example, Google Analytics, third party Ad scripts, or CDN hosted scripts, are especially important. Although this is best practice rather than a requirement until end of Q1 2025, this PCI DSS bulletin from 2019 explains the types of risks:
Requirement 8.3.5
Requirement 8.3.5 is enforcing the common practice of having a unique initial password that is forced on first logon, with the same process for password resets.
Requirement 8.3.6
Requirement 8.3.6 has updated the minimum required characters for passwords to twelve, although again, best practice rather than a requirement until end of Q1 2025. However, this should be straightforward to do from now. This needs to be technically enforced.
Requirement 8.3.7
Requirement 8.3.7 is when changing a password, requiring that it cannot be the same as any of the last four used. This needs to be technically enforced.
Requirement 8.3.9
Requirement 8.3.9 means password changes every 90 days, although use of MFA precludes this. MFA should be common practice and easy to implement for most eCommerce platforms.
Requirement 11.3.2
Requirement 11.3.2 for quarterly external vulnerability scans by an ASV is mandatory, and this is not future dated, you need to start quarterly scanning as soon as you transition to PCI DSS v4.0. The scans need to be done on the web sites on the merchant web server, and you need passing scans every quarter.
Requirement 11.6.1
Requirement 11.6.1 for a change and tamper detection mechanism for the page hosting the iframe only applies to iframes that host the payment service provider’s payment page. This is best practice until end of Q1 2025, when it becomes a requirement. This requirement needs careful consideration, and there are some solutions described in the PCI DSS v4.0 guidance column for this requirement.
What should I do next?
There are significant changes in SAQ A for PCI DSS v4.0 for eCommerce merchants, even though the merchant does not store, process, or transmit account data; clearly the merchant web server still has a potential impact on the security of account data.
Although some changes are future dated to 2025 before becoming mandatory and PCI DSS v3.2.1 doesn’t retire until 2024, it is good practice to further protect your web sites now if you are not already.
Some simple ways to do this include:
- Multi-factor authentication for all accounts
- Passwords with a minimum of twelve characters
- Quarterly vulnerability scans
- Restricting and managing external JavaScript and CSS files
- Change or tamper detection on pages hosting iframes
Need a helping hand?
Dionach can help you with transitioning to PCI DSS v4.0 by providing you with a PCI DSS v.4.0 gap analysis. This will ensure you know what options you may have and the changes you will need to make to meet the new requirements.
For more information on our PCI DSS v4.0 gap analysis services, please don’t hesitate to get in touch with our team.
