PCI V4's New SAQ A - Everything you need to know

PCI V3.2.1 Requirement

PCI V4.0 Requirement

Comments

2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.

2.2.2 Vendor default accounts are managed as follows:
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.

Minor changes to wording.

NEW

6.3.1 Security vulnerabilities are identified and managed as follows:
• New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from  international and national computer emergency response teams (CERTs).
• Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact.
• Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment.
• Vulnerabilities for bespoke and custom, and third-party software (for example operating systems and databases) are covered.

Merchants are required to subscribe to security bulletins of CERTs and relevant vendor to identify applicable vulnerabilities. You must also have a process in place to risk rank these vulnerabilities.

This requirement is not achieved by, nor is it the same as, vulnerability scans performed for

Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated

with each vulnerability

6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.
Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

6.3.3 All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows:
• Critical or high-security patches/updates (identified according to the risk ranking process at Requirement 6.3.1) are installed within one month of release.
• All other applicable security patches/updates are installed within an appropriate time frame as determined by the entity (for example, within three months of release).

Minor changes to wording.

NEW

Best practice until 31 March 2025, after which it will be required

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.

Merchants are required to keep an inventory of any payment page scripts with justification as to why each is necessary.

Merchants are required to make sure scripts are authorized and authenticated. This can be achieved by configuring Content-Security-Policy (CSP) headers as well as Subresource Integrity (SRI) checks for each script. CSP can be set to only load scripts from authorized domains, while SRI ensures scripts loaded into the consumer’s browser match a cryptographic hash of the expected file.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

Some third-party tools may be able to assist.

8.1.1 Assign all users a unique ID before allowing them to access system components or cardholder data.

8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.

Minor changes to wording.

8.1.3 Immediately revoke access for any terminated users.

8.2.5 Access for terminated users is immediately revoked.

Minor changes to wording.

8.2 In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users:
• Something you know, such as a password or passphrase
• Something you have, such as a token device or smart card
• Something you are, such as a biometric

8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors:
• Something you know, such as a password or passphrase.
• Something you have, such as a token device or smart card.
• Something you are, such as a biometric element.

Minor changes to wording.

8.2.3 Passwords/passphrases must meet the following:
• Require a minimum length of at least seven characters.
• Contain both numeric and alphabetic characters.
Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.

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.

The PCI SSC has increased the complexity of password requirements from seven to twelve.

The length increase is best practice until 31 March 2025, after which it will be required

8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows:
• Generic user IDs are disabled or removed.
• Shared user IDs do not exist for system administration and other critical functions.
• Shared and generic user IDs are not used to administer any system components.

8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows:
• Account use is prevented unless needed for an exceptional circumstance.
• Use is limited to the time needed for the exceptional circumstance.
• Business justification for use is documented.
• Use is explicitly approved by management.
• Individual user identity is confirmed before access to an account is granted.
• Every action taken is attributable to an individual user.

The requirement now makes allowances for the use of group or shared accounts under exceptional circumstances.

NEW

8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows:
• Set to a unique value for first-time use and upon reset.
• Forced to be changed immediately after the first use.

Passwords/passphrases must now be set to unique values and change after first use.

NEW

8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.

Password history must now be enforced.

NEW

8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation) then either:
• Passwords/passphrases are changed at least once every 90 days,
OR
• The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly.

Passwords must now be set to expire unless multifactor authentication is enabled or dynamic Zero Trust account mechanisms are in place.

NEW

11.3.2 External vulnerability scans are performed as follows:
• At least once every three months.
• By a PCI SSC Approved Scanning Vendor(ASV).
• Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met.
• Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan.

Quarterly ASV scans are now required by SAQ A. Some merchants may have already been required by their acquirer to provide these.

A list of approver vendors can be found

here.

NEW

11.3.2.1 External vulnerability scans are performed after any significant change as follows:
• Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved.
• Rescans are conducted as needed.
• Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).

Quarterly ASV scans are now required by SAQ A. Some merchants may have already been required by their acquirer to provide these.

A list of approver vendors can be found

here.

NEW

Best practice until 31 March 2025, after which it will be required

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 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).

A change detection mechanism must be put into place to alert staff when HTTP headers and contents are changed.

Note: For SAQ A, Requirement 11.6.1 applies to merchants that include a TPSP’s inline frame (iframe) payment form on the merchant’s website. If a merchant uses URL redirects, where the merchant hosts the page(s) on their website(s) that provides the address (the URL) of the merchant’s payment page/form to the merchant’s customers, the merchant marks this requirement as Not Applicable

12.8.1 Maintain a list of service providers, including a description of the service provided.

12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided.

Minor changes to wording.

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.
Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.

12.8.2 Written agreements with TPSPs are maintained as follows:
• Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
• Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.

Minor changes to wording.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement

Minor changes to wording.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.

Minor changes to wording.

12.8.5 Maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity.

12.8.5 Information is maintained about which PCI  DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity

Minor changes to wording.

12.10.1 Create the incident response plan to be implemented in the event of system breach.

12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or  confirmed security incident.

Minor changes to wording.