PCI DSS client-side security checklist

How to use this checklist

The requirement numbers refer to PCI DSS v4.0.1. This list is a study aid written from public PCI SSC material; it is not an assessment, and which items apply to you depends on how you accept payments and on what your acquirer or assessor decides. Read the article on SAQ A, SAQ A-EP and SAQ D first if you are not sure.

1. Scope: know your payment pages

• List every page and step in your flow where card data is entered, or where an embedded payment form is shown.
• Record how each page accepts payment: redirect, iframe or embedded form, or direct post.
• Record which SAQ or report type your acquirer expects, and the reasoning.
• Include pages behind a login, multi-step checkouts and variants shown to some visitors only (for example by country or device).

2. Requirement 6.4.3: manage payment page scripts

• An inventory of every script that runs on each payment page, built from what the browser loads: see how to build a script inventory.
• A written business or technical justification for each script.
• A method to confirm each script is authorized, with a record of who approved it and when.
• A method to assure each script's integrity, such as Subresource Integrity, hashes or a Content Security Policy.
• A way to handle new or changed scripts, including those loaded by a tag manager or by other scripts.

See PCI DSS 6.4.3 explained.

3. Requirement 11.6.1: detect change and tampering

• A mechanism that evaluates the HTTP headers and the contents of payment pages as received by the consumer browser.
• Alerts to named personnel for unauthorized modification, including additions and deletions.
• A run at least once every seven days, or at the frequency in your targeted risk analysis.
• A process for triaging alerts, deciding whether a change was authorized, and responding.
• Records of runs, alerts and decisions kept as evidence.

See PCI DSS 11.6.1 explained and how to detect client-side tampering.

4. Requirement 12.3.1: targeted risk analysis

• If you choose a 11.6.1 frequency other than weekly, a documented targeted risk analysis that supports it.
• A review of that analysis at least once every twelve months.
• Approval of the analysis by the people responsible for the decision.

5. Related controls that reduce the risk

• 6.4.1 and 6.4.2: protection of public-facing web applications. Once its future-dated effective date passed, 6.4.2, an automated technical solution that detects and prevents web-based attacks, took the place of 6.4.1.
• 6.3.2: an inventory of bespoke and custom software and third-party software components, which supports knowing what you run.
• 6.2.4: techniques to prevent or mitigate common software attacks in bespoke and custom software, relevant to XSS and injection.
• 6.3.3: installing applicable security patches on time.
• Strong access control for the people and systems that can publish changes to payment pages, including multi-factor authentication where PCI DSS requires it.
• Security headers that make the page harder to abuse: HTTP security headers for payment pages.

6. Requirement 12.8: third-party service providers

Script, tag manager and payment providers are third parties whose services can affect the security of card data.

• 12.8.1: a list of the third-party service providers (TPSPs) you use, with a description of the service each provides.
• 12.8.2: written agreements in which each TPSP acknowledges its responsibility for the security of the account data it handles or could affect.
• 12.8.3: due diligence before you engage a TPSP.
• 12.8.4: a program to monitor each TPSP's PCI DSS compliance status at least once every twelve months.
• 12.8.5: information about which PCI DSS requirements each TPSP manages, which are yours and which are shared.

7. Incident readiness and evidence

• An incident response plan that covers a suspected skimmer: who decides, how the script is removed, how evidence is preserved, and when the acquirer and card brands are told (requirement 12.10.1 covers the plan).
• An evidence folder or system for each assessment period: inventories, approvals, integrity method evidence, monitoring results, alerts, risk analysis and vendor records.
• A named owner for the payment page scripts, so changes do not go unreviewed.