Performing an SAQ D Service Provider version 4.0 Self-Assessment

Overview

Of all of the changes made to the Self-Assessment Questionnaires with the release of PCI DSS version 4.0, the changes made to the SAQ D Service Provider were the most significant.

In prior versions the SAQ D Merchant and Service Provider reports mostly the same except for the added “Service Provider only requirements” and a few additional reporting sections to complete in the executive summary. The merchant SAQ D version 4.0 report has a few newly-added requirements but remains very similar to the version 3.2.1 SAQ D.

The SAQ D Service Provider version 4.0 report, however, has had significant changes and now requires individuals performing the assessment to explain what observations led to their conclusions, as does the Report on Compliance report. These changes will contribute to a significant increase in time required to perform an assessment and to complete the report.

This post will review what’s different and what’s new in the SAQ D Service Provider report and provide guidance on how to comply with the newly added requirements.

Qualifying Criteria

All SAQs include a list of criteria that are used to define what type of payment channels are eligible to be assessed using that particular SAQ. In PCI DSS version 4.0, it is made clear that the SAQ D Service Provider report is the only SAQ option for service providers.

While the SAQ D Service Provider is the only SAQ option for service providers, not all requirements may be applicable. It is important to define the scope of the assessment and which people, processes and technologies are in-scope. Some service providers will only have a security impacting perspective with a limited applicability to all of the SAQ D Service Provider PCI requirements. There is guidance available on the PCI council website for defining scope as well as recommendations for connected-to service providers who only have a security impacting perspective into their customers cardholder data environment.

Self Attestation Methods

All SAQs can either be self-validated or third-party validated, meaning that you can attest to your PCI compliance or have a Qualified Security Assessor (QSA) assess your compliance status. One of the major changes in the SAQ D Service Provider report is that rather than just checking a box to attest compliance, the entity now must also describe how it has met the requirement. This requires documenting a high-level description of the testing activities performed to verify that a requirement has been met.

There are three types of testing methods that will need to be documented:

• Examine: The entity critically evaluates data evidence. Common examples include documents (electronic or physical), screenshots, configuration files, audit logs, and data files.
• Observe: The entity watches an action or views something in the environment. Examples of observation subjects include personnel performing a task or process, system components performing a function or responding to input, environmental conditions, and physical controls.
• Interview: The entity converses with individual personnel. Interview objectives may include confirmation of whether an activity is performed, descriptions of how an activity is performed, and whether personnel have particular knowledge or understanding.

A response should document what artifacts were examined, descriptions of observations of settings, configurations, code and tests of controls, procedures and functions and a list of people involved and what was discussed. A table on “page v” contains a description of the meaning for each response and how to report the testing performed and is referred to by every requirement in the SAQ D Service Provider response area.

It is likely the intent behind requiring the documentation of the types of testing activities performed is to ensure a higher level of assurance that the entity performed a quality assessment and that the entity’s people, processes and technologies actually abide by the requirements. This demonstration of how the entity has met a requirement will significantly increase the time it takes to fill out a SAQ D.

Network Diagrams

New to the SAQ D Service Provider report is Section 2a which asks the entity to include network diagrams. This is something that is not required in the SAQ D Merchant assessment and was not requested in previous versions of the SAQ D-SP.

The network diagram evidence must satisfy the following stipulations:

• Shows all connections between the CDE and other networks, including any wireless networks..
• Is accurate and up to date with any changes to the environment.
• Illustrates all network security controls that are defined for connection points between trusted and untrusted networks.
• Illustrates how system components storing cardholder data are not directly accessible from the untrusted networks.
• Includes the techniques (such as intrusion-detection systems and/or intrusion-prevention systems) that are in place to monitor all traffic at the perimeter and at critical points in the cardholder data environment.
  

Cardholder Data and SAD Tables

Another addition to the SAQ D-SP report in Section 2a are data tables which the entity will need to complete. This is not required in the SAQ D Merchant but a feature seen in the executive summary of the ROC report.

The storage of cardholder data table requires that an entity list all databases, tables, and files storing account data and provide the following details:

• Data Store: database name, file server name, etc.
• File name(s), Table name(s) and/or Field names.
• Account data elements stored: PAN, expiry, name, etc.
• How the data is secured: encryption and strength, etc.
• How access to the data stores is logged

The storage of SAD table requires that an entity list all databases, tables, and files storing Sensitive Account Data (SAD) and provide the following details:

• Data Store: database name, file server name, etc.
• File name(s), Table name(s) and/or Field names.
• Is SAD stored pre-authorization? (Yes/No)
• Is SAD stored as part of Issuer Functions? (Yes/No)
• How is the data secured: encryption and strength, etc.

Descriptions of what is defined as cardholder data and sensitive account data is listed on “page iii” of the report.

In-scope System Component Types Table

A further addition to the SAQ D-SP in Section 2a is a large table where the entity will need to list all the types of in-scope system components. This is another feature not required in the SAQ D Merchant that is also found in the executive summary of the ROC report.

The in-scope system component types table requires that an entity list all types of system components, the total number of system components, the component vendor, the component product name and version and a description of its role and function in the CDE.

What constitutes a system component is described on Page 10 of the SAQ D Service Provider report. Considering the ample room provided in the report for this information the table could be quite extensive and tedious.

ASV Quarterly Scan Results

A last addition to the SAQ D Service Provider report in Section 2a is a table where the entity lists each quarterly ASV scan performed within the last 12 months. This is something that is not required in the SAQ D Merchant assessment and is a feature in the executive summary of the ROC report.

New Future-Dated Requirements

Future-dated requirements added to version 4.0 SAQ 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 Service Providers 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:

• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization.

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 and 3.3.3 SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

Requirement 3.3.2 and 3.3.3 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 new 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:

• On removable electronic media.

OR

• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.

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.

3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

• Preventing the use of the same cryptographic keys in production and test environments.

While requirement 3.6.1.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 have a documented description of the cryptographic architecture and show evidence that different keys are used in production and test environments. Something to consider are environments where the compliance burden is shared, such as a cloud hosting environment that has a key management service. In this case be sure to review the cloud hosts responsibility summary to confirm what responsibility the host has and what compliance responsibility is left for the entity.

4.2.1 Strong cryptography and security protocols are implemented as follows to safeguard PAN during transmission over open, public networks:

• Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked.

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 anti-virus 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):

• Performs automatic scans of when the media is inserted, connected, or logically mounted,

OR

• Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.

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:

• Is installed in front of public-facing web applications and is configured to detect and prevent web-based attacks.
• Actively running and up to date as applicable.
• Generating audit logs.
• Configured to either block web-based attacks or generate an alert that is immediately investigated.

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:

• A method is implemented to confirm that each script is authorized.
• A method is implemented to assure the integrity of each script.
• An inventory of all scripts is maintained with written justification as to why each is necessary.

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:

• At least once every six months.
• To ensure user accounts and access remain appropriate based on job function.
• Any inappropriate access is addressed.
• Management acknowledges that access remains appropriate.

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:

• Based on the least privileges necessary for the operability of the system or application.
• Access is limited to the systems, applications, or processes that specifically require their use.

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:

• Periodically (at the frequency defines in the entity’s targeted risk analysis)
• The application/system access remains appropriate for the function being performed.
• Any inappropriate access is addressed.
• Management acknowledges that access remains appropriate.

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:

• A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).
• Contain both numeric and alphabetic characters.

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.3.10.1 Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:

• Password/passphrases are changed as least once every 90 days,

OR

• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Requirement 8.3.10.1 is a service provider only requirement that addresses the customer access to the cardholder data. In 8.3.10 it allows you to change the user password/passphrase periodically, however int 8.3.10.1 it states that password/passphrase must be changed every 90 days or be dynamically analyzed. Until March 31, 2025 service providers may meet either requirement 8.3.10 or 8.3.10.1. Additionally, neither of those requirements apply to users accessing their own cardholder data, and 8.3.10.1 doesn’t apply if the password/passphrase is used as the only authentication factor.

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 use is prevented unless needed for an exceptional circumstance.
• Interactive use is limited to the time needed for the exceptional circumstance.
• Business justification for interactive use is documented.
• Interactive use is explicitly approved by management.
• Individual user identity is confirmed before access to account is granted.
• Every action taken is attributable to an individual user.

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:

• Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise.
• Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

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:

• Network security controls.
• IDS/IPS
• Change-detection mechanisms
• Anti-malware solutions.
• Physical access controls.
• Logical access controls.
• Audit logging mechanisms.
• Segmentation controls (if used).
• Audit log review mechanisms.
• Automated security testing tools (if used).

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:

• Restoring security functions.
• Identifying and documenting the duration (date and time from start to end) of the security failure.
• Identifying and documenting the cause(s) of failure and documenting required remediation.
• Identifying and addressing any security issues that arose during the failure.
• Determining whether further actions are required as a result of the security failure.
• Implementing controls to prevent the cause of failure from reoccurring.
• Resuming monitoring of security controls.

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:

• Addressed based on the risk defined in the entity’s targeted risk analysis, which is performed according to all elements specified in requirement 12.3.1.
• Rescans are conducted as needed.

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:

• Systems that are unable to accept credentials for authenticated scanning are documented.
• Sufficient privileges are used for those systems that accept credentials for scanning.
• If accounts used for authenticated scanning can be used for interactive login, they are managed in accordance with requirement 8.2.2.

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.4.7 Additional requirement for multi-tenant service providers only. Multi-tenant service providers support their customers for external penetration testing per requirement 11.4.3 and 11.4.4.

A multi-tenant service provider such as a colocation data center, cloud environment or shared hosting provider must either show evidence that they have conducted a penetration test according to requirement 11.4.3 and 11.4.4 on the customers’ infrastructure or provide prompt access to each of its customers so that they can perform their own penetration test. Evidence provided to customers can include redacted penetration testing results but needs to include sufficient information to prove that all elements of requirement 11.4.3 and 11.4.4 have been met on the customer’s behalf.

11.5.1.1 Additional requirement for service providers only. Intrusion-detection and/or intrusion-prevention techniques detect, alert on/prevent, and address covert malware communication channels.

In order to show evidence of compliance for this requirement you will need to demonstrate the IDS/IPS configuration settings and any alerts and incident response measures to the assessor during the onsite assessment in order to show that it is configured to detect covert malware communication channels from the infected system and the command and control server, such as traffic over NTP, DNS, wifi, Tor network, etc. You will also need to provide related vendor or policy documentation and incident response documentation.

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 is configured to evaluate the received HTTP header and payment page.
• The mechanism is configured to evaluate the received HTTP header and payment page.

The mechanism functions are performed as follows:

• At least once every seven days

OR

• Periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1).

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:

• Identification of the assets being protected.
• Identification of the threat(s) that the requirement is protecting against.
• Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
• Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
• Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
• Performance of updated risk analysis when needed, as determined by the annual review.

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:

• An up-to-date inventory of all cryptographic cipher suites and protocols in use, including purpose and where used.
• Active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use.
• A documented strategy to respond to anticipated changes in cryptographic vulnerabilities.

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:

• Analysis that the technologies continue to receive security fixes from vendors promptly.
• Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.
• Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology.
• Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans.

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.5.2.1 Additional requirement for service providers only. PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment.

Often a company will look to the PCI QSA to define the scope of their CDE. And however helpful the QSA may try to be, the scope of the PCI assessment is owned by the entity and the QSA plays the role of validating that the defined scope is appropriate for the entity’s card data flows or to the extent the entity can impact the security of the cardholder data environment. To show evidence of compliance with this requirement there will need to be a documented scope and a bi-annual confirmation of that scope (or upon a significant change).

12.5.3 Additional requirement for service providers only. Significant changes to organizational structure results in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management.

To show evidence of compliance with this requirement there will need to be a documented internal review of the change to the scope and applicable controls. The assessor will need to see that the results of the documented internal review were communicated with executive management.

12.6.2 The security awareness program is

• Reviewed at least once every 12 months, and
• Updated as needed to address any new threats and vulnerabilities that may impact the security of the entity’s CDE, or the information provided to personnel about their role in protecting cardholder data.

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:

• Phishing and related attacks.
• Social engineering.

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:

• The change and tamper detection mechanism for payment pages

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:

• Determining what to do if PAN is discovered outside the CDe, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable.
• Identifying whether sensitive authentication data is stored with PAN.
• Determining where the account data came from and how it ended up where it was not expected.
• Remediating data leaks or process gaps that resulted in the account data being where it was not expected.

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.

A1.1.1 Additional requirement for multi-tenant service providers. Logical separation is implemented as follows:

• The provider cannot access its customers’ environments with authorization.
• Customers cannot access the provider’s environment without authorization.

For cloud environments and shared hosting platforms, logical separation is required to prevent unauthorized access. A customer in a cloud environment shouldn’t have logical access to the hypervisor, or root admin access on a shared server without authorization. Conversely, a user with access to the hypervisor or shared server shouldn’t be able to log in to any of their customers' servers without prior authorization.

A1.1.4 Additional requirement for multi-tenant service providers. The effectiveness of logical separation controls used to separate customer environments is confirmed at least once every six months via penetration testing:

The assessed entity will need to ensure that there are logical penetration perspectives between the multi-tenant service provider and their customer environments and that the testing perspectives are representative of both the service provider and customer perspectives.

A1.2.3 Additional requirement for multi-tenant service providers. Processes or mechanisms are implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, including:

• Customers can securely report security incidents and vulnerabilities to the provider.
• The provider addresses and remediates suspected or confirmed security incidents and vulnerabilities according to requirement 6.3.1.

Cloud environments and shared hosting platforms will need to provide a secure method for reporting security incidents and vulnerabilities. And the service provider will need to show that they have addressed and remediated the incident or vulnerability according to requirement 6.3.1.

Conclusion

Version 3.2.1 of the PCI DSS will be retired on March 31, 2024. After that date, service providers will be required to use version 4.0 of the SAQ D Service Provider document.

Many of the new requirements address an increased need to property assess and manage risks in the CDE, as well as to place emphasis on securing e-commerce card data flows.

Adding several executive summary items from the v3.2.1 ROC into the v4.0 SAQ D Service Provider document, as well as requiring a reporting response for each requirement item will significantly increase the time it takes to fill out the report.