As with the PCI DSS v3.2.1 SAQ D for Merchants, the v4.0 SAQ D for Merchants applies to all other self-assessment eligible merchants not meeting the criteria for any other SAQ type. The examples of merchant environments to which SAQ D may apply are the same as those given In the v3.2.1 SAQ D for Merchants but now referencing ‘account data’ instead of ‘cardholder data’:

The SAQ D for Merchants supports the completion of either a full or partial assessment as ‘Not Tested’ is an available assessment response, in addition to the ‘In Place’, ‘In Place with CCW’ (Compensating Control Worksheet), ‘Not Applicable’ and ‘Not In Place’ responses available in the other SAQ types. ‘Not Tested’ means the requirement was not included for consideration in the merchant’s assessment and was not tested in any way.

A partial assessment is one in which only a subset of Requirements has been assessed; one or more Requirements are marked as ‘Not Tested’. Part 3 of the SAQ D AOC ‘PCI DSS Validation’, provides space to indicate whether a full or a partial PCI DSS assessment was completed. Appendix D must be used to provide an explanation of any requirement that was Not Tested.

Under v3.2.1 a Compliant ‘partial’ assessment was not possible as a ‘Not Tested’ result was not considered an affirmative assessment answer for a Requirement. Now, under v4.0, as long as the merchant subject to the partial assessment has demonstrated compliance with all other Requirements, they can be validated as Compliant.

The v4.0 SAQ D Merchant includes 54 new or additional requirements. 13 requirements are new and effective immediately, 41 are new but future-dated. The most significant of the new or additional Requirements are highlighted below:

Effective Immediately

• Personnel need to be aware of their assigned role and responsibilities to make sure each Requirement is operated / performed (x.1.2, new for Requirements 2 to 11)
• Secure storage of offline media backups with cardholder data (9.4.1.1)
• The assessed entity must document and confirm their PCI DSS scope at least once every 12 months (12.5.2)

Future-dated

• Data retention and disposal policies and procedures to cover any Sensitive Authentication Data (SAD) stored pre-authorization (3.2.1)
• SAD stored electronically prior to completion of authorization is encrypted using strong cryptography (3.3.2)
• When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel (3.4.2)
• Hashes used to render PAN unreadable (per 3.5.1), are keyed cryptographic hashes of the entire PAN (3.5.1.1)
• If disk-level or partition-level encryption is used to render PAN unreadable it is implemented only on removable electronic media (3.5.1.2):
  • Or, if used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1
• Maintain an inventory of trusted keys and certificates used to protect PAN during transmission (4.2.1.1)
• Anti-malware solution for removable electronic media (5.3.3)
• Implement automated mechanisms to detect and protect against phishing attacks, include phishing and social engineering in security awareness training (5.4.1, 12.6.3.1)
• Maintain an inventory of all bespoke software (developed to the entity’s specifications by a third party), custom software (developed by the entity), and third-party software components and include all such software in vulnerability and patch management processes (6.3.1, 6.3.2)
• Manage payment page scripts to ensure each script is necessary, its use authorized and its integrity assured (6.4.3)
• Review user accounts and related access privileges, including third-party/vendor accounts, at least once every six months (7.2.4)
• Manage application and system accounts (7.2.5, 7.2.5.1, 8.6.1, 8.6.2, 8.6.3)
• Minimum of 12 character alphanumeric password length, if passwords/passphrases are used for authentication of users and administrators (8.3.6)
  • Or minimum 8 characters if the system does not support 12 characters
• Additional requirements for multi-factor authentication (MFA) (8.4.2, 8.5.1)
  • MFA to be implemented for all access into the CDE.
  • Configure MFA systems to ensure they are not susceptible to replay attacks, cannot be bypassed by any users without authorization, use at least two different types of authentication factors and grant access only after all authentication factors are successful.
• Implement automated mechanisms to perform audit log reviews (10.4.1.1)
• Failures of critical security control systems are detected, alerted, addressed and responded to promptly (10.7.2, 10.7.3)
  • Now including two additional critical control systems: audit log review mechanisms and automated security testing tools (if used)
• Internal vulnerability scans must be performed via authenticated scanning (11.3.1.2)
• Implement a change- and tamper-detection mechanism to detect and alert on unauthorized modification to the HTTP headers and the contents of payment pages as received by the consumer browser (11.6.1)
  • Security incident response plan (12.10.5) to include monitoring and responding to alerts from the change-and tamper-detection mechanism for payment pages
• Perform targeted risk analyses to determine the frequency a requirement is performed (12.3.1)
  • Applicable to Requirements 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1, 11.6.1.
• Document and review cryptographic cipher suites and protocols in use at least once every 12 months (12.3.3)
• Review hardware and software technologies in use at least once every 12 month (12.3.4)
• Security awareness program to be reviewed and updated at least once every 12 months (12.6.2), and shall include:
  • Awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to: Phishing and related attacks; Social engineering (12.6.3.1)
  • Awareness about the acceptable use of end-user technologies (12.6.3.2)
• Security incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected (12.10.7)