Many organisations accepting card payments see SAQ A as the target operating model, as this has the most effect on reducing the PCI DSS requirements with which an organisation must comply. It does not come without risks though, as the third-party service providers you have engaged with must always maintain their compliance to support yours.
So, what remains the same, and what has changed with the arrival of PCI DSS v4.0? The first blog of this series explained the core format changes for all the SAQs, here we turn to the specifics around SAQ A.
Whilst there has been some minor rewording, in practice, it is the same for merchants who already use SAQ A:
What remains the same?
All requirements from the PCI DSS v3.2.1 SAQ A have been transferred to the latest version, although they do have new reference numbers. There are minor variations to the wording, and some previously separate requirements are now grouped together.
What has been removed from SAQ A?
Nothing – there are no requirements found in v3.2.1 of SAQ A that are removed in the newer SAQ A for v4.0.
What has been added to SAQ A?
Merchants that take advantage of SAQ A by implementing an iFrame or redirecting to a compliant service provider must remember that the underlying web server is in their scope.
In v3.2.1 of SAQ A, there were security controls that many security professionals would consider essential that the PCI SSC did not require. The Security Standards Council (SSC) has recognised this, so in PCI DSS version 4.0 several new requirements are particularly relevant to an E-Commerce environment.
Vulnerability Management
Investigations into cardholder and personal data breaches have identified that patching and misconfiguration continue to be the main contributors to these issues. As a result, some requirements supporting minimising vulnerability management risks have become part of SAQ A.
What you need to do straight away:
- Start receiving vulnerability information and acting upon this as appropriate.
- Start running quarterly ASV scans of your public-facing websites.
From 31st March 2025, the following will become mandatory, therefore you should start them without delay, as good practice.
- Protect your public-facing web application against attacks using both governance and technical measures.
- Introduce change and tamper detection mechanisms to your websites. (iFrame only)
At first glance, these may seem time-consuming or expensive. While it is true that the changes do have some financial and process costs, any solution where you enter cardholder payment information should have these basic controls.
When migrating to PCI DSS v4.0 there is a minor quirk to consider – ASV scan frequency. Before exploring this, it is worth recapping the actual requirement for ASV scans, requirement 11.3.2.
For new assessments, it is simple. A single ASV scan is needed for solutions going through initial compliance, with quarterly scans thereafter. What is less clear is how many historic scans are required if moving an existing solution over to the new version.
As with any ambiguity in PCI DSS, a Qualified Security Assessor (QSA) will always recommend that you consult with your acquiring institute and understand their expectations, so be sure to engage with them for guidance on what they are looking for.
Storing Printed Cardholder Data
To be eligible to complete SAQ A, you may only store card data within paper records; no change there, and if you do not have paper records, this will not be applicable. If you do have paper records, you will now need to ensure there are documented policies and procedures for your staff to follow.
This should include topics such as:
- Where records are stored
- What is stored, and why?
- How long is it stored?
- How are records destroyed?
There is a slight nuance in the standard about storing the CVV too, this is future-dated and will be revisited another time.
Users and Passwords
There has been a change around the use of ‘group, shared, or generic accounts’ for practical purposes. Organisations often require server ‘break glass’ accounts for use as a last resort if, for example, their authentication services are down, and they need to log onto a server. These are usually shared local administrator accounts, and PCI DSS v3.2.1 would require a compensating control to be truly faithful to the standard’s requirements.
PCI DSS v4.0 has attempted to address this issue, recognising that the need for an emergency last-resort account can be legitimate. Merchants must not think this change is a green light to an easy life of one shared account per server. These accounts are permitted solely to cover emergencies and exceptional circumstances. There will also need to be good governance around them, and the details describing this are in the PCI DSS.
Weak passwords remain one of the most common causes of a breach, not just in the payment industry but across the board for organisations of all types and sizes. The need to enforce better-quality passwords is widely accepted, and the PCI DSS is no exception.
SAQ A features some uplifts, with explicit requirements around improving password security. Specifically, the length and complexity requirements have increased and how often passwords can be reused. Passwords must be:
- Set to a unique value for first-time use, and whenever reset
- Forced to change after first use
- A minimum of 12 characters in length, including a mixture of alphabetic and numeric characters
- Different to any of the last four passwords used
Organisations should not find these changes challenging to technically enforce, as these features are built into most operating systems.
What next?
Make sure you take the time to fully digest the applicability notes for SAQ A, particularly where they include confirmation of a future data requirement. Also, be mindful that there are a few instances where bullet points from the core PCI DSS v4.0 standard have been omitted within the SAQ, and you may encounter “Bullet intentionally left blank for this SAQ.”
If you need help with making these changes and assessing their impact on your people, processes, and technologies, please reach out to LRQA where we are happy to help as we provide QSA, 3DS and ASV services to merchants and service providers around the world.
Learn more about our PCI DSS services here or contact us to discuss your PCI DSS requirements.