PCI DSS v4.0 introduced some changes to each of the self-assessment questionnaires (SAQs). There is no change to the list of self-assessment questionnaires, and they have broadly the same eligibility criteria.
Below is a summary table showing the SAQs and the number of requirements for each of the related PCI DSS versions.
Although it seems there are less v4.0 requirements, many of the sub-requirements in v3.2.1 have been kept and are in a bullet list with a single tick box for the requirement. Organisations still need to address each of the specific bullet points in each requirement and perform each of the bullet points in the expected testing.
Number of requirements for each SAQs for PCI DSS v3.2.1 and PCI DSS v4.0
| SAQ | V3.2.1 Reqs. | v4.0 Reqs. | Eligibility Criteria | Additional Information |
|---|---|---|---|---|
| SAQ A | 24 | 31 | All storage, processing and transmission of account data outsourced | E-commerce websites still have requirements that apply to the web server |
| SAQ A-EP | 192 | 151 | All processing of account data outsourced except for the payment page | CDE requirements apply to the e-commerce websites |
| SAQ B | 41 | 27 | Dial-up payment terminals only | Not for network connected payment terminals |
| SAQ B-IP | 87 | 49 | Standalone payment terminals on isolated network | B-IP requiring network controls and isolation means P2PE is a better option |
| SAQ P2PE | 33 | 21 | Payments via payment terminals from a validated P2PE solution | All controls are implemented from the P2PE instruction Manual |
| SAQ C | 161 | 132 | Payment applications such as POS that are isolated from other systems | Isolation can be done through network segmentation |
| SAQ C-VT | 84 | 54 | Virtual payment terminal (such as web browser on a PC) isolated from other systems | Isolation can be done through network segmentation |
| SAQ D Merchants | 330 | 252 | Merchants not eligible for other SAQs | Some controls may not be applicable |
| SAQ D Service Providers | 369 | 278 | All service providers (service providers are not eligible for merchant SAQs) | Some controls may not be applicable |
General SAQ Changes
Organisations can start using v4.0 now, although it becomes mandatory from 31st March 2024, when PCI DSS v3.2.1 retires. Although some new controls are future dated to 2025 before becoming mandatory, it is good practice to implement and assess these new controls. Requirements marked with an asterisk (*) in each of the following SAQ sections are those future dated new requirements.
The SAQs now define Account Data, which is Cardholder Data (CHD) and/or Sensitive Authentication Data (SAD). PCI DSS covers organisations that store, process or transmit Account Data. Regardless of the SAQ, merchants should understand the scope of the PCI DSS requirements which is defined in section 4 of the document PCI DSS Requirements and Testing Procedures v4.0.
Response options for each requirement are: In Place, In Place with CCW, Not Applicable, and Not In Place. CCW stands for Compensating Controls Worksheet. Although PCI DSS allows a custom approach for many of the requirements, this is not allowed for self-assessment questionnaires. Each of the requirements must be met if they are applicable, although Compensating Controls can still be used for legitimate technical or business constraints.
The attestation in SAQ D for Merchants and SAQ D for Service Providers now includes an option for full or partial PC DSS assessments, with partial for any Not Tested requirements. An example of where an organisation may have a partial assessment is if they are working towards compliance by completing one or more milestones using the prioritized approach tool. This partial assessment does not apply to other SAQs.
For specific wording and section changes from PCI DSS v3.2.1 to PCI DSS v4.0, the PCI SSC have a document named Summary of Changes from PCI DSS Version 3.2.1 to 4.0 in the PCI SSC Document Library.
SAQ A
SAQ A is for merchants that outsource all storage, processing, and transmission of account data. The SAQ A eligibility criteria now require specific checking of the compliance of third-party service providers (TPSPs) through their Attestations of Compliance (AOCs), and that the AOCs cover services used by the merchant.
SAQ A changes for ecommerce are explained in the separate Dionach article PCI DSS 4 – E-commerce Changes for SAQ A Explained. Apart from those significant changes for e-commerce, there are no other changes in SAQ A for those that outsource all storage, processing, and transmission of account data.
SAQ A-EP
SAQ A-EP is for e-commerce merchants outsource all storage, processing and transmission of account data except that they control the website payment page.
As with SAQ A, the SAQ A-EP eligibility criteria now requires specific checking of the compliance of TPSPs through their AOCs, and that the AOCs cover services used by the merchant. TPSPs would include the e-commerce payment service providers. Further to that, most new requirements are future dated (signified by an asterisk), and are as follows:
Requirement 3.2.1* adds that merchants are responsible for determining how TPSPs meet this requirement for account data retention. Requirement 3.3 clarifies that SAD storage applies to any account data stored on paper.
Requirement 6.3.2 now requires an inventory of bespoke and custom software and third-party software components.
Requirement 6.4.3* requires that you manage script files like JavaScript that are included on payment pages that the merchant hosts; for example, Google Analytics, third-party advertising scripts, or CDN hosted scripts, are especially important.
Requirement 6.4.2 will require an automated solution to protect web applications such as a web application firewall; this was one of two options in PCI DSS v3.2.1 and becomes the only option from the end of Q1 2025.
Requirement 7.2.4* needs at least six-monthly user account access reviews.
Section 8 now includes a new password and reset password controls in 8.3.5*, as well as a minimum of 12 alphanumeric characters for passwords in 8.3.6*, and MFA enforced for all access to the CDE in 8.4.2*. With e-commerce websites, it is likely that organisations already enforce MFA for all access to the CDE. There are additional requirements for application or system accounts in 8.6 restricting the use of interactive application accounts, no hardcoding of passwords, and periodic changes: again, mandatory from Q1 2025.
Section 9.4 clarifies that media applies to merchants with paper records that may contain account data.
Requirement 10.4.1.1* now requires that automated mechanisms are used to perform audit log reviews, not manual, which is allowed in v3.2.1.
Requirement 11.6.1* needs a change and tamper detection mechanism for the payment pages on the web servers. This requirement needs careful consideration, and there are some solutions described in the guidance column within PCI DSS v4.0 for this requirement.
Requirement 12.3.1* requires targeted risk analysis on any requirement with flexible frequency, such as 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1 and 11.6.1. This requires comprehensive and specific documentation.
Requirement 12.6.3.1* needs security awareness training to include awareness of phishing and social engineering attacks.
Requirement 12.10.1 for an incident response plan has guidance that 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. 12.10.3 mandates that specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
SAQ B
SAQ B is for those using dial-up payment terminals only, connected via an analogue phone line, which is not so common anymore; some countries have already switched off PSTN, with the UK planning to switch off PSTN in 2025.
Section 3 clarifies that protecting stored cardholder data relates to paper records that include account data, and that if the card verification value is written down, it is destroyed or properly obscured immediately after the transaction is complete.
Section 9 also clarifies that media with cardholder data relates to paper records such as receipts or reports.
Section 12 no longer includes 12.3.1, 12.3.3 and 12.3.5, which required usage policies for critical technologies, with explicit approval, a list of personnel with access, and acceptable use of technologies respectively.
Section 12 includes guidance that the security policy, security awareness program, and incident response plan should be consistent with the size and complexity of the merchant’s operations.
SAQ B-IP
SAQ B IP is for standalone payment terminals on an isolated network, where payment terminals are not connected to other systems on the merchant network. Merchants should consider SAQ P2PE rather than SAQ B-IP where possible, given that there are fewer requirements in SAQ P2PE.
Section 1 refers to network security controls rather than firewalls specifically, however the requirements are largely the same.
As with SAQ B, section 3 clarifies that protecting stored cardholder data relates to paper records that include account data, and that if the card verification value is written down, it is destroyed or properly obscured immediately after the transaction is complete.
There are no section 4 requirements in the new SAQ B-IP that require encryption of cardholder data during transmission over public networks.
Section 6 clarifies that addressing security vulnerabilities relates to the merchant’s firewalls and routers, but that the merchant should also check with the entity managing the payment terminals how they meet the section 6 requirement for payment terminals.
Sections 8 and 9 now specifically require policies and procedures: 8.1.1 requires policies and procedures for access to system components, and 9.1.1 requires policies and procedures for protecting paper media with cardholder data and for protecting payment terminals.
Quarterly external vulnerability scans are still required, however 11.3.2 states that these scans must be performed at least once every three months, with no leeway now between quarters.
As with SAQ B, section 12 no longer includes 12.3.1, 12.3.3 and 12.3.5, which required usage policies for critical technologies, with explicit approval, a list of personnel with access, and acceptable use of technologies respectively. Section 12 now includes guidance that the security policy, security awareness program, and incident response plan should be consistent with the size and complexity of the merchant’s operations.
SAQ P2PE
SAQ P2PE is for payments via payment terminals from a validated P2PE solution. As you would expect, the eligibility criteria still require that the merchant has implemented all controls in the P2PE Instruction Manual (PIM) as provided by the P2PE Solution Provider.
Section 3 clarifies that protecting stored cardholder data relates to paper records that include account data, and that if the card verification value is written down, it is destroyed or properly obscured immediately after the transaction is complete. Section 3.2.1* now includes a requirement to protect any sensitive authentication data that may be stored on paper prior to the completion of authorization.
SAQ C
Payment application systems such as point of sale (POS) systems that are isolated from other systems in the merchant environment.
Section 1 refers to network security controls rather than firewalls specifically, however the requirements are largely the same.
Section 2 requires one primary function per system component rather than one primary function implemented per server or virtual system component, with further flexibility if functions with different security levels are secured to the level required by the function with the highest security need.
Section 3 clarifies that protecting stored cardholder data relates to paper records that include account data, and that if the card verification value is written down, it is destroyed or properly obscured immediately after the transaction is complete. If account data is written down, policies and procedures are also required.
Requirement 4.2.1* now requires that certificates that are used to safeguard the PAN during transmission over public networks are valid and not expired or revoked.
Section 5 refers to anti-malware solutions rather than antivirus software, and requires policies and procedures in 5.1.1 for protecting systems from malicious software.
Requirement 5.2.3 needs system components that are not at risk for malware to be in a documented list and periodic confirmation that these system components continue to not require anti-malware protection. Requirement 5.2.3.1* needs a targeted risk analysis to determine the frequency of the periodic evaluation of system components that are not at risk for malware.
Requirement 5.3.2 has an option for continuous behavioural analysis of systems or processes, not just periodic scans and active scans by anti-malware solutions. Requirement 5.3.2.1* needs a targeted risk analysis to determine the frequency of the scans for anti-malware solutions, if performed.
Requirement 5.3.3* needs scans or continuous behavioural analysis for electronic media such as external portable storage.
Requirement 5.4.1* needs processes and automated mechanisms are in place to detect and protect personnel against phishing attacks; if external systems meet this requirement, such as email servers, these are not brought into scope for other PCI DSS requirements.
Section 6.2 is new for SAQ C and requires that merchants with bespoke or custom software have procedures for secure software development based on industry standards (6.2.1), that developers are trained at least every 12 months (6.2.2), that code reviews are independent of the code author and are approved by management (6.2.3.1), and that development procedures prevent the OWASP top ten (6.2.4).
Requirement 6.5.1 specifies the need for formal document control, with requirement 6.5.2 needing applicable PCI DSS requirements to be confirmed as in place for any significant change.
Requirement 7.2.4* needs at least six-monthly user account access reviews.
Sections 8, 9 and 10 now specifically require policies and procedures: 8.1.1 requires policies and procedures for access to system components, and 9.1.1 requires policies and procedures for protecting paper media with cardholder data and for protecting POS terminals. 10.1.1 requires policies and procedures for logging and monitoring.
Section 8 now includes a new password and reset password controls in 8.3.5*, as well as a minimum of 12 alphanumeric characters for passwords in 8.3.6*, and MFA enforced for all access to the CDE in 8.4.2*. There are additional requirements for application or system accounts in 8.6 restricting use of interactive application accounts, no hardcoding of passwords, and periodic changes: again, mandatory from Q1 2025.
Section 9.4 clarifies that media applies to merchants with paper records that may contain account data.
Requirement 10.4.1.1* now requires that automated mechanisms are used to perform audit log reviews, not manual, which is allowed in v3.2.1.
Quarterly external vulnerability scans are still required, however 11.3.2 states that these scans must be performed at least once every three months, with no leeway now between quarters. Specifically, at least once every 90 to 92 days, or on the nth day of each third month.
Requirement 12.3.1* requires a targeted risk analysis on any requirement with flexible frequency, such as 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1 and 11.6.1. This requires comprehensive and specific documentation.
Requirement 12.6.3.1* needs security awareness training to include awareness of phishing and social engineering attacks.
Requirement 12.10.1 for an incident response plan has guidance that 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. 12.10.3 mandates that specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
SAQ C-VT
SAQ C-VT applies a virtual payment terminal, such as a web browser on a PC, isolated from other systems.
Section 1 refers to network security controls rather than firewalls specifically, however the requirements are largely the same. SAQ v3.2.1 required personal firewall software for portable computing devices such as laptops that may connect to the CDE and the internet; v4.0 has generalised this to security controls for the portable computing devices to prevent threats from being introduced into the entity’s network.
Section 2 requires one primary function per system component rather than one primary function implemented per server or virtual system component, with further flexibility if functions with different security levels are secured to the level required by the function with the highest security need.
Sections 3, 8 and 9 now specifically require policies and procedures for each of the relevant requirements in the corresponding section.
Section 4 now has reduced requirements, with only strong cryptography required for wireless networks connected to the CDE.
Section 5 refers to anti-malware solutions rather than antivirus software and requires policies and procedures in 5.1.1 for protecting systems from malicious software.
Requirement 5.2.3 needs system components that are not at risk for malware to be in a documented list and to periodically confirm that these system components continue to not require anti-malware protection. Requirement 5.2.3.1* needs a targeted risk analysis to determine the frequency of the periodic evaluation of system components that are not at risk for malware.
Requirement 5.3.2 has an option for continuous behavioural analysis of systems or processes, not just periodic scans and active scans by anti-malware solutions. Requirement 5.3.2.1* needs a targeted risk analysis to determine the frequency of the scans for anti-malware solutions, if performed.
Requirement 5.3.3* needs scans or continuous behavioural analysis for electronic media such as external portable storage.
Requirement 5.4.1* needs processes and automated mechanisms are in place to detect and protect personnel against phishing attacks; if external systems meet this requirement, such as email servers, these are not brought into scope for other PCI DSS requirements.
Section 8 now requires a minimum of 12 alphanumeric characters for passwords in 8.3.6*.
Section 9.4 clarifies that media applies to merchants with paper records that may contain account data.
Section 11 has been removed from SAQ C-VT, so penetration testing to verify segmentation is no longer specifically required.
Requirement 12.3.1* requires targeted risk analysis on any requirement with flexible frequency, such as 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1 and 11.6.1. This requires comprehensive and specific documentation.
Requirement 12.6.3.1* needs security awareness training to include awareness of phishing and social engineering attacks.
Requirement 12.10.1 for an incident response plan has guidance that 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. 12.10.3 mandates that specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.
SAQ D for Merchants
SAQ D for Merchants applies to merchants not eligible for other SAQs, and includes all PCI DSS requirements except for those only applicable to service providers.
The changes are essentially the Summary of Changes from PCI DSS Version 3.2.1 to 4.0, available on the PCI SSC website. Please see the other SAQs above for a selection of the new requirements
SAQ D for Service Providers
SAQ D for Service Providers includes all PCI DSS requirements, some of which may not be applicable.
SAQ D for Service Providers has grown somewhat for PCI DSS v4.0. Section 2a now requires:
- Network diagrams that show connections between the CDE and other networks, show security controls, and show traffic monitoring.
- Details of all locations that store account data or SAD.
- Details of types of system components, which include network devices, servers, computing devices, virtual components, cloud components, and software.
- Quarterly external ASV scan results.
The PCI DSS changes are essentially the Summary of Changes from PCI DSS Version 3.2.1 to 4.0, available on the PCI SSC website
Summary
Many of the changes to the SAQs for PCI DSS v4.0 have been incremental and are future dated. There are no significant changes to specific SAQs except for SAQ D for Service Providers which has significantly more documentation requirements.