For merchants who process card payments exclusively through a third-party payment gateway, SAQ A is the simplest and easiest way to achieve compliance. Many of my customers have managed to limit the scope of their assessment to SAQ A, and I'd be willing to bet a majority of my readers have at least one SAQ A scoped channel. In this article, we'll provide a quick overview of everything you need to know about the recent changes to SAQ A in PCI DSS v4.
Key Changes
- Requirement 6 places a greater emphasis on vulnerability management. Merchants must now subscribe to a CERT and their vendors for alerts/bulletins identifying vulnerabilities in their environment.
- Scripts loaded and executed into the consumer's browser require additional controls to ensure they are authorized and have not been tampered with.
- While authentication controls remain similar, there are noteworthy updates such as the minimum password length being increased to 12 characters and the need for password rotation if it is the sole authentication factor used.
- External vulnerability scans (ASV scans) are now mandatory at least quarterly and after significant changes have been made.
- For merchants who use iFrame integrations, you are now required to implement a change and tamper detection mechanism to prevent unauthorized modifications to the payment page.
Comparison Table: PCI DSS SAQ A Requirements in Versions 3 and 4
PCI V3.2.1 Requirement |
PCI V4.0 Requirement |
Comments |
2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network. |
2.2.2 Vendor default accounts are managed as follows: |
Minor changes to wording. |
NEW |
6.3.1 Security vulnerabilities are identified and managed as follows: |
Merchants are required to subscribe to security bulletins of CERTs and relevant vendor to identify applicable vulnerabilities. You must also have a process in place to risk rank these vulnerabilities.
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 |
6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release. |
6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: |
Minor changes to wording. |
NEW Best practice until 31 March 2025, after which it will be required |
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: |
Merchants are required to keep an inventory of any payment page scripts with justification as to why each is necessary.
Merchants are required to make sure scripts are authorized and authenticated. This can be achieved by configuring Content-Security-Policy (CSP) headers as well as Subresource Integrity (SRI) checks for each script. CSP can be set to only load scripts from authorized domains, while SRI ensures scripts loaded into the consumer’s browser match a cryptographic hash of the expected file.
https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Some third-party tools may be able to assist. |
8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data. |
8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed. |
Minor changes to wording. |
8.1.3 Immediately revoke access for any terminated users. |
8.2.5 Access for terminated users is immediately revoked. |
Minor changes to wording. |
8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: |
8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: |
Minor changes to wording. |
8.2.3 Passwords/passphrases must meet the following: |
8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: |
The PCI SSC has increased the complexity of password requirements from seven to twelve.
The length increase is best practice until 31 March 2025, after which it will be required |
8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows: |
8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: |
The requirement now makes allowances for the use of group or shared accounts under exceptional circumstances. |
NEW |
8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: |
Passwords/passphrases must now be set to unique values and change after first use. |
NEW |
8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. |
Password history must now be enforced. |
NEW |
8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either: |
Passwords must now be set to expire unless multifactor authentication is enabled or dynamic Zero Trust account mechanisms are in place. |
NEW |
11.3.2 External vulnerability scans are performed as follows: |
Quarterly ASV scans are now required by SAQ A. Some merchants may have already been required by their acquirer to provide these.
A list of approver vendors can be found here.
|
NEW |
11.3.2.1 External vulnerability scans are performed after any significant change as follows: |
Quarterly ASV scans are now required by SAQ A. Some merchants may have already been required by their acquirer to provide these.
A list of approver vendors can be found here.
|
NEW Best practice until 31 March 2025, after which it will be required
|
11.6.1 A change- and tamper-detection mechanism is deployed as follows: |
A change detection mechanism must be put into place to alert staff when HTTP headers and contents are changed.
Note: For SAQ A, Requirement 11.6.1 applies to merchants that include a TPSP’s inline frame (iframe) payment form on the merchant’s website. If a merchant uses URL redirects, where the merchant hosts the page(s) on their website(s) that provides the address (the URL) of the merchant’s payment page/form to the merchant’s customers, the merchant marks this requirement as Not Applicable |
12.8.1 Maintain a list of service providers, including a description of the service provided. |
12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided. |
Minor changes to wording. |
12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment. |
12.8.2 Written agreements with TPSPs are maintained as follows: |
Minor changes to wording. |
12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement. |
12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement |
Minor changes to wording. |
12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually. |
12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months. |
Minor changes to wording. |
12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity. |
12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity |
Minor changes to wording. |
12.10.1 Create the incident response plan to be implemented in the event of system breach. |
12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. |
Minor changes to wording. |
For Merchants just starting out, you can purchase our SAQ A Policy Pack to help you meet the SAQ A policy requirements.
In conclusion, SAQ A remains the simplest and easiest way for merchants to achieve compliance with PCI DSS v4. However, the recent changes will require a fair amount of effort before your next assessment.
Note: This article focuses on ecommerce merchants using SAQ A. If you want a MOTO focused article let me know.