Merchants who do not qualify to assess their PCI DSS compliance using any of the simpler self-assessment questionnaires are required to use the SAQ D to validate their compliance.
Merchants who do not qualify to assess their PCI DSS compliance using any of the simpler self-assessment questionnaires are required to use the SAQ-D to validate their compliance. This would include merchants who support both online and card-present payment flows. The SAQ-D-Merchant includes all PCI DSS compliance requirements except for a few that apply only to service providers. In this blog we will review some of the changes that have been made to the SAQ-D as part of the PCI DSS version 4 implementation.
Future-dated requirements added to PCI DSS version 4.0 are considered best practice until March 31, 2025. Entities are not required to validate compliance to these requirements until that date.
Depending upon the size and complexity of your environment, it may take considerable effort to implement some of these new requirements. It is recommended that SAQ-D Merchants begin now to plan for the implementation of the following new requirements:
3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:
Requirement 3.2.1 has several bullet points to satisfy, but the one listed just above is new for PCI v4.0 and is considered a best practice until March 31, 2025. In order to satisfy this requirement you should have documented policies, procedures and processes to handle any pre-authorization sensitive authentication data that is stored. Sensitive Authentication Data is defined as: full track data (magnetic-stripe data or equivalent on a chip), card verification code, or PINs or PIN blocks.
3.3.2 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.
Requirement 3.3.2 refers to pre-authorization SAD and requires that it be encrypted when stored. Typically, data that is in memory is temporary and in transit to or from a data store and isn’t usually considered SAD data storage. In order to satisfy this requirement you should have vendor documentation on the encryption strength and encrypting method used as well as demonstrate to the assessor the data stores and the system configurations for those data stores. Sensitive Authentication Data is defined as: full track data (magnetic-stripe data or equivalent on a chip), card verification code, or PINs or PIN blocks.
3.4.2 When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel, except for those with documented, explicit authorization and a legitimate, defined business need.
Working from home has become a more common practice and accessing the cardholder data environment remotely poses some unique security concerns. While the PCI SSC has written up FAQs on their website in order to clarify the extent of PCI scope in a work from home or remote location, this requirement seeks to prevent any intentional or unintentional copying or access to cardholder data by those who are not explicitly authorized and have a defined business need. The requirement further clarifies “Storing or relocating PAN onto local hard drives, removable electronic media, and other storage devices brings these devices into scope for PCI DSS”. As an example of who you may want to confirm explicit authorization has been granted, consider accounting or staff who accesses the payment gateway but have full access to the card number in order to process a refund or troubleshoot a transaction, or developers who at times will have access to unencrypted live PAN data in order to troubleshoot an issue, or employees who receive cardholder data over the phone and enter it into a website or payment terminal from home. And then security controls should be in place to deny anyone without explicit authorization access to PAN or the ability to copy PAN
3.5.1.1 Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1), are keyed cryptographic hashes of the entire PAN, with associated key-management processes and procedures in accordance with Requirements 3.6 and 3.7.
If there are partial hashes of PAN or if a weak hash is used then there is the security risk that the hashing algorithm could be broken and clear text PAN be accessed. A cryptographic hash such as a SHA-256 with RSA 2048 encryption is a common cryptographic hash used that would satisfy this requirement. This requirement applies to PANs stored in primary storage (databases, or flat files such as text file and spreadsheets) as well as non-primary storage (backup, audit logs, exception, or troubleshooting logs) and must all be protected. Additionally, this requirement does not preclude the use of temporary files containing cleartext PAN while encrypting and decrypting PAN.
3.5.1.2 If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:
OR
While disk encryption may still be present on these types of devices, it cannot be the only mechanism used to protect PAN stored on those systems. Any stored PAN must also be rendered unreadable per Requirement 3.5.1—for example, through truncation or a data- level encryption mechanism. Full disk encryption helps to protect data in the event of physical loss of a disk and therefore its use is appropriate only for removable electronic media storage devices. Media that is part of a data center architecture (for example, hot-swappable drives, bulk tape-backups) is considered non-removable electronic media to which Requirement 3.5.1 applies. Disk or partition encryption implementations must also meet all other PCI DSS encryption and key-management requirements.
4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:
While requirement 4.2.1 has other bullet points, this bullet point listed above is new and is a best practice until March 31, 2025 after which it will be required. In order to satisfy this requirement you should show evidence that the SSL/TLS certs used to transmit cardholder data over open, public networks are valid and not revoked. Something to consider is that if you are using a self-signed cert for development and a SSL/TLS cert for the production environment then be sure that the production environment doesn’t also (and likely incidentally) accept self-signed certs to transmit or receive cardholder data. Additionally, you’ll want to confirm your firewall or load balancer settings only allow for strong cryptography for the transmission of cardholder data over HTTPS, such as TLS 1.2 or TLS 1.3.
4.2.1.1 An inventory of the entity’s trusted keys and certificates used to protect PAN during transmission is maintained.
In order to show evidence of compliance for 4.2.1.1 an entity will need to maintain a current inventory of the trusted keys and certificates used to protect PAN during transmission.
5.2.3.1 The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
In order to show evidence of compliance for 5.2.3.1 an entity will need to include components that are not at risk for malware in their risk assessment and also provide a list of these components so the assessor can compare the list of systems with anti-virus deployed with that list to confirm that antivirus is deployed all systems that have not been defined as components not at risk for malware.
5.3.3 For removable electronic media, the anti-malware solution(s):
OR
Requirement 5.3.3 can be considered an evolving requirement for malware prevention. Malware protection in place in the environment should be configured to either automatically scan removable electronic media (USB drives, external hard drives, SSD memory cards, etc.) when mounted or the malware solution should be continuously performing behavioral analysis to provide automatic malware protection for these connected media types.
5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.
Phishing attacks are becoming more prevalent and more sophisticated in recent years. While employee training is critical to preventing successful phishing attacks from negatively affecting the security of a merchant’s environment, technical controls should be added to provide more layers of protection against these attacks. For requirement 5.4.1, it is recommended that merchants implement a combination of approaches to prevent spoofing attacks. Anti-fishing tactics include anti-spoofing technologies (domain-based message authentication, domain keys identified mail, and sender policy framework) and phishing email blocking or link scrubbing technologies.
6.3.2 An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
In order to show evidence of compliance for 6.3.2 an entity will need to compile and maintain an inventory of bespoke and custom software, and any third-party software components incorporated into the bespoke and custom software. Additionally the entity will need to show how that inventory is used to help with vulnerability and patch management. It’s important to update vulnerabilities found in “bespoke” and custom software and to know what services or solutions are integrated with it. While this requirement is a best practice, after March 31, 2025 it will be required.
6.4.2 For public-facing web applications, an automated technical solution is deployed that continually detects and prevents web-based attacks, with at least the following:
Requirement 6.4.2 is a best practice until 31 March 2025, after which it will be required and will replace the current 6.4.1 requirement. In requirement 6.4.1 there is an option to have a manual vulnerability security assessment for public-facing web applications, which will go away and only an automated technical solution will be allowed going forward. Typically this requirement is satisfied by a Web Application Firewall placed in front of the web server or just behind a load balancer. Be sure the WAF solution is set up to generate audit logs and is sending them to a central logging server.
6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
Requirement 6.4.3 applies to the page(s) on the merchant’s website(s) that are used to redirect the customer's browser to the TPSP's payment page. To comply with Requirement 6.4.3, merchants must implement policies and procedures for managing third or fourth-party scripts implemented on the webpage(s) used to redirect traffic to the payment page. Scripts that may seem harmless can have their functionality altered without the merchant’s knowledge. Such scripts may be able to be used to upload malicious scripts that could be used to perform an e-commerce skimming attack even though the merchant’s website was not designed to capture or transmit cardholder data.
Scripts may be verified by manual or automated processes. Tools such as Content Security Policy (CSP), Sub-Resource Integrity (SRI), or proprietary script management systems can be used to help meet the intent of this requirement.
7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:
In order to show evidence of compliance for this requirement you will want to show that a bi-annual user account and access privileges review happens and has management acknowledgement or signoff. It may work well to pair this up with a bi-annual firewall ruleset review or rotate quarterly between a firewall review and a user access privilege review.
7.2.5 All application and system accounts and related access privileges are assigned and managed as follows:
In order to show evidence of compliance for 7.2.5 you will need to confirm the application and system accounts only have the access and privileges necessary for their function. If you give an account access to more than is needed or privileges more than is used you will run the risk of a compromised application or system account being accessed and doing things they shouldn’t.
7.2.5.1 All access by application and system accounts and related access privileges are reviewed as follows:
Requirement 7.2.5.1 addresses the risk and threats associated with improper access granted to an application or system account. You need to define internally how often to review these system and application accounts and integrate the findings of the review into your risk assessment. Management will need to attest that the access granted is appropriate.
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:
Requirement 8.3.6 is an evolving PCI DSS requirement. In version 3.2.1, passwords were required to be at least 7 characters in length consisting of a mix of numeric and alphabetic characters. Beginning on March 31, 2025, the password length requirement is increased to 12 characters in most instances while the password complexity requirement remains unchanged.
8.4.2 MFA is implemented for all access into the CDE.
In requirement 8.4.2, multi-factor authentication is required for all access into the CDE. However, this requirement does not apply to application or system accounts performing automated functions or user accounts on POI terminals that have access to only one card number at a time to facilitate a single transaction. MFA is required for both access into the CDE and for remote access originating outside the entity’s network that could access or impact the CDE (requirement 8.4.3).
8.5.1 Multi-factor authentication (MFA) systems are configured to prevent misuse.
Multi-factor authentication solutions need to be implemented securely and cannot be susceptible to replay attacks, user permission bypass (unless authorized and documented), have to use two different types of factors, and success of all authentication factors is required before access is granted.
8.6.1 If accounts used by systems or applications can be used for interactive login, they are managed as follows:
Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. These accounts often come with local admin privileges and even some domain privileges that could allow these accounts access to other systems. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
8.6.2 Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.
Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. If you hard code the authentication credentials or include them in a configuration file or custom source code then anyone who has access to that code or configuration file can then obtain the interactive login credentials and possibly gain local admin privileges and privileges across the domain. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
8.6.3 Passwords/passphrases for any application and system accounts are protected against misuse as follows:
It’s common for application and system accounts to be overlooked and forgotten. To show evidence of compliance for this requirement you will need to perform a risk assessment (NIST 800-30 would suffice) and make sure that it includes the risk posed by not changing or infrequently changing an application or system account or not having sufficient complexity for that password. After the risk assessment has been performed you will also need to show the policy created to address the application and system account password risks. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and 7.2.5.1 all relate to controls for application and system accounts.
9.5.1.2.1 The frequency of periodic POI device inspections and the type of inspections performed is defined in the entity’s target risk analysis, which is performed according to all elements specified in Requirement 12.3.1.
To show evidence of compliance for this requirement you will need to perform a risk assessment (NIST 800-30 would suffice) and make sure that it includes the risk posed by infrequent POI device inspections and the type of inspection performed. In addition to the risk assessment you will also need to show documented evidence that the periodic device inspections have been performed.
10.4.1.1 Automated mechanisms are used to perform audit log reviews (at least once daily).
10.4.2.1 The frequency of periodic log reviews for all other system components (not defined in requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in requirement 12.3.1.
Because of the vast amounts of logging data collected it becomes almost impossible to manually review it and so PCI is requiring you to use an automated solution that scans through the logs and looks for anomalies or issues. To show evidence of compliance for 10.4.2.1 you will need to assess the risk of the frequency in which periodic reviews for all other systems not defined in 10.4.1 are considered, and create a documented policy and procedure to address that risk.
10.7.2 Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
In order to show evidence of compliance for this requirement you will need to provide documentation of the process and demonstrate for the assessor the detection and alerting processes during the PCI assessment.
10.7.3 Failures of critical security control systems are responded to promptly, including but not limited to:
In order to show evidence of compliance for this requirement you will need to provide documentation of the process and any tickets or records related to a critical security control failure.
11.3.1.1 All other applicable vulnerabilities (those not ranked as high-risk or critical per the entity’s vulnerability risk rankings defined at requirement 6.3.1) are managed as follows:
In order to show evidence of compliance for this requirement you will need to show that the risk assessment required in 12.3.1 includes the applicable vulnerabilities that are not considered high-risk or critical but that still pose a low or medium risk. You will also need to provide a copy of the internal scan reports.
11.3.1.2 Internal vulnerability scans are performed via authenticated scanning as follows:
Authenticated scanning (whether host-based or network based) allows the internal vulnerability scanning tool the appropriate privileges to access CDE system information that is not exposed externally or without the proper privileges. If the accounts used for scanning can be used for interactive login, such as local admin on the systems or across a domain, then they are also subject to requirement 8.2.2. A system inventory should include whether a system such as a security appliance, mainframe or container or any other system is not able to accept credentials for authenticated scans. These systems that cannot accept credentials for authenticated scanning are not applicable for this requirement.
11.6.1 A change and tamper-detection mechanism is deployed as follows:
To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
The mechanism functions are performed as follows:
OR
This requirement applies to SAQ-A merchants who make use of a third-party iframe to perform payment capture and to the service providers to perform a similar function. If the merchant’s website is configured to redirect the customer’s browser to the TPSP’s payment acceptance page, they would mark this requirement as Not Applicable.
Similar to Requirement 6.4.3, a TSPS-provided iframe on a merchant’s website must be protected from e-commerce skimming attacks. Requirement 11.6.1 requires merchants to implement change detection procedures and technologies to alert personnel to unauthorized modifications to the HTTP headers and contents of the page(s) used to house the TPSP iframe. Such tamper-detection mechanisms must run at least weekly to look for unauthorized modifications to these critical web pages. The SecurityMetrics Shopping Cart Monitor can be used to help meet the intent of this requirement.
12.3.1 Each PCI DSS requirement that provides flexibility for how frequently it is performed has been included in your documented risk assessment, and should include:
A good way to satisfy this requirement is to do a NIST 800-30 risk assessment and include the threat events posed by the PCI requirements throughout the report, along with a baseline of threat events provided in the NIST 800-30 guidance document and any threat events that have or could occur to your environment based on the people, processes and technologies used. The risk assessment should include a spreadsheet of threat events and their corresponding risk determination. The risk assessment should have management signoff and have CDE-wide (ideally organization-wide) contribution and should be a living document that is periodically updated. Ideally the risk assessment document would be used to justify security control expenditures and to prioritize mitigation and risk-treatment efforts. A rigorous risk assessment and resulting documentation would satisfy the risk aspects of requirements: 1.2.6, 2.2.5, 5.2.3, 5.2.3.1, 5.3.2.1, 6.3.1, 6.3.3, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1, 11.3.1.1, 11.3.1.3, 11.4.1, 11.4.4, 11.6.1, 12.3.1, 12.7.1, 12.8, 12.10.4.1, A2.1.2, and Appendix B: Compensating Controls Worksheet (4. Identified Risk).
12.3.3 Cryptographic cipher suites and protocols in use are documented and reviewed at least once every 12 months, including at least the following:
As a check to ensure that data is not transmitting over insecure protocols or encrypted with insecure cryptographic cipher suites, requirement 12.3.3 requires companies to document and monitor all ciphers and protocols in use at least annually. Additionally, companies should have a procedure in place to respond to cryptographic vulnerabilities so that it’s possible to change from one suite to another.
12.3.4 Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following:
Managing the hardware and software technologies in use in the CDE will ensure that end-of-life and vulnerable software and hardware are continuously being updated to a compliant state. In order to show evidence of compliance the assessor will want to see that you are receiving security notices and fixes, and documenting end-of-life plans and have a documented plan approved by senior management to remediate insecure and outdated technologies.
12.6.2 The security awareness program is
To show evidence of compliance with this requirement the assessor will need to see the security awareness program content and will need to see evidence of the annual reviews (such as meeting notes, updates to the security awareness version table, etc.)
12.6.3.1 Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:
As discussed in requirement 5.4.1 above, companies should be taking a defense-in-depth approach to prevent phishing and other social engineering-related attacks. To be compliant with requirement 12.6.3.1, a merchant’s security awareness training program needs to include education on how to detect, react to, and report phishing and social engineering attempts. It is also recommended that members of the merchant’s incident response team are made aware of how to properly respond to notifications of these types of attacks against the organization.
12.6.3.2 Security awareness training includes awareness about the acceptable use of end-user technologies in accordance with requirement 12.2.1.
To show evidence of compliance with this requirement the assessor will need to see the security awareness program content.
12.10.4.1 The frequency of periodic training for incident response personnel is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in requirement 12.3.1.
To show evidence of compliance with this requirement the assessor will need to see the risk assessment documentation.
12.10.5 The security incident response plan includes monitoring and responding to alerts from security monitoring systems, including but not limited to:
In addition to the other bullet points this new bullet point is future dated to take effect on March 31, 2025. In order to show evidence of compliance for this requirement the entity will need to provide details in the incident response plan that addresses a change detection mechanism for payment capture pages.
12.10.7 Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:
In order to show evidence of compliance for this requirement the company will need to have a documented incident response procedure and provide any records of response actions being followed if an incident has occurred.
In addition to newly added requirements, several existing PCI DSS requirements were enhanced. These enhanced/evolving requirements include the following:
All security policies and operational procedures for said requirements are:
Well-documented security policies and procedures can help merchants maintain a PCI DSS-compliant environment if employees working in the environment are aware of policies and procedures that apply to their job responsibilities. PCI DSS Requirements 1.1.1, 2.1.1, 3.1.1, … 12.1.1 focus on ensuring policies related to these sections are up to date and are distributed to affected parties.
For example, for Requirement 3, a merchant should have a defined data retention policy that prohibits any electronic storage of cardholder data within the merchant environment and defines data retention and data destruction procedures for any physical media containing cardholder data.
While merchants have always been responsible for defining the scope of their PCI DSS environment, PCI DSS version 4.0 has added a requirement designed to verify a comprehensive scoping exercise is performed on an annual basis and after any significant change is made to the CDE.
During the scoping exercise merchants will identify all people, processes, technologies, and system components that comprise their CDE. A thorough review and documentation of all payment flows will need to be performed and documented. Network diagrams, card flow diagrams, system inventories will need to be created/updated as part of this process.
Version 3.2.1 of the PCI DSS will be retired on March 31, 2024. After that date, merchants performing self-assessments will be required to use version 4.0 of the Self-Assessment Questionnaires.
The SAQ-D is the most comprehensive self-assessment questionnaire available for merchants. Many of the controls listed in the SAQ-D may be difficult to interpret and implement. Should you need assistance validating compliance to the SAQ-D, SecurityMetrics has multiple resources available to assist you.
.svg)
