Document Comparison

Note: For SAQ A, Requirement 6.4.3 applies to a merchant’s webpage that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).

• A method is implemented to confirm that each script is authorized.

• Examine inventory records.

• Examine system configurations.

• A method is implemented to assure the integrity of each script.

• An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.

Applicability Notes (continued)

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place with CCW Not Applicable Not in Place This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.

This requirement also applies to scripts in the entity’s webpage(s) that includes a TPSP’s/ payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).

This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on …

Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.

Applicability Notes (continued)

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 11.6 Unauthorized changes on payment pages are detected and responded to.

Note: For SAQ A, Requirement 11.6.1 applies to a merchant’s servers with a webpage that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes).

• To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.

• Examine system settings and mechanism configuration settings.

• Examine monitored payment pages.

• Examine results from monitoring activities.

• Examine the mechanism configuration settings.

• Examine configuration settings.

• If applicable, examine the targeted risk analysis.

• The mechanism is configured to evaluate the received HTTP headers and payment pages.

• The mechanism functions are performed as follows:

• At least once weekly 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).

Scripts in the TPSP’s/payment processor’s embedded payment page/form are the responsibility of the TPSP/payment processor to manage in accordance with this requirement.

This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.

Where the merchant server redirects customers from the merchant website to a TPSP/payment processor (for example, with a URL redirect), the merchant marks this requirement as Not Applicable and completes Appendix C: Explanation of Requirements Noted as Not Applicable.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place This requirement also applies to entities with a webpage(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, one or more inline frames or iframes.) This requirement does not apply to an entity for scripts in a TPSP’s/payment processor’s embedded payment page/form (for example, one or more iframes), where the entity includes a TPSP’s/payment processor’s payment page/form on its webpage.

The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column (of PCI DSS Requirements and Testing Procedures) to prevent and detect unexpected script activities.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place 12.3 Risks to the cardholder data environment are formally identified, evaluated, and managed.

• 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 the frequency or processes defined by the entity to meet the requirement minimize the likelihood and/or impact 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 analyses when needed, as determined by the annual review.

• Examine documented policies and procedures.

PCI DSS Requirement Expected Testing Response♦ (Check one response for each requirement) In Place In Place Not Applicable Not in Place Applicability Notes This requirement is a best practice until 31 March 2025, after which it will be required and must be …