Performing an SAQ D Service Provider version 4.0 Self-Assessment: Updates and changes in the new 4.0 standard.
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.
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.
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.
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.
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:
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:
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:
Descriptions of what is defined as cardholder data and sensitive account data is listed on “page iii” of the report.
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.
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.
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:
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:
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.
3.6.1.1 Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:
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:
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):
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.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:
OR
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 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.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 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.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
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.
A1.1.1 Additional requirement for multi-tenant service providers. Logical separation is implemented as follows:
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:
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.
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.
.svg)
