PCI DSS 6.4.3 and 11.6.1 are the two PCI DSS v4.0.1 requirements aimed at e-skimming, where attackers slip malicious JavaScript into a checkout page and copy card numbers as customers type them. Requirement 6.4.3 is about control: you know every script on your payment page, you have authorized it, and you can show it hasn’t been altered. PCI DSS 11.6.1 is about detection: something watches the page as browsers receive it and alerts a person when scripts or security-relevant HTTP headers change without authorization.
Both have been mandatory since 31 March 2025 for merchants that validate with SAQ A-EP, SAQ D or a Report on Compliance (ROC). Since January 2025, SAQ A merchants face a related eligibility criterion instead. This guide is general information, not QSA or legal advice. Your acquirer and assessor have the final say.
What does PCI DSS 6.4.3 actually require?
PCI DSS v4.0.1 states that “all payment page scripts that are loaded and executed in the consumer’s browser” are managed so that:
- 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 a written business or technical justification for why each one is necessary.
The applicability notes in v4.0.1 make two points. First, the requirement covers scripts from your own environment and from third and fourth parties: your analytics tag, the chat widget, and anything those tags load in turn. Second, if your page embeds a payment form from a third-party service provider (TPSP) or processor, for example in an iframe, the scripts inside that iframe are the provider’s responsibility. The scripts on your page around the iframe are still yours.
The standard itself is in the PCI SSC document library. PCI SSC’s FAQ on 3DS scripts and 6.4.3 adds one carve-out. Merchants don’t need to validate 3DS scripts against 6.4.3, because the merchant and the 3DS provider already have a trust relationship. Any script that does more than 3DS work is still in scope.
What does PCI DSS 11.6.1 require?
PCI DSS 11.6.1 requires a change- and tamper-detection mechanism that:
- alerts personnel to unauthorized modification (including indicators of compromise, changes, additions and deletions) of the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser;
- is configured to evaluate the received HTTP headers and payment pages;
- runs at least weekly, or at the frequency defined in your targeted risk analysis performed under Requirement 12.3.1.
“As received by the consumer browser” matters. Checking files on your server doesn’t prove what a shopper’s browser loaded. “Security-impacting headers” usually means Content-Security-Policy and similar headers, so an attacker loosening your CSP is a change 11.6.1 should catch.
When did 6.4.3 and PCI DSS 11.6.1 become mandatory?
Both were “best practice” until 31 March 2025 and have been required since then. PCI SSC confirmed the date in its January 2025 SAQ A announcement, which also names Requirement 12.3.1, the targeted risk analysis that supports a non-weekly 11.6.1 frequency. In March 2025 the Council published an information supplement, Payment Page Security and Preventing E-Skimming, with implementation guidance for both requirements. The supplement adds no new requirements.
Who has to comply with 6.4.3 and PCI DSS 11.6.1?
Which requirements you validate depends on how your checkout is built and which SAQ your acquirer accepts. If you’re not sure, start with which PCI SAQ do I need.
| How you take card payments online | Typical validation | 6.4.3 and PCI 11.6.1 |
|---|---|---|
| Full redirect to a processor’s hosted payment page | SAQ A | Not in SAQ A. The script eligibility criterion does not apply to redirects (FAQ 1588) |
| Processor iframe or hosted fields embedded in your page | SAQ A | Not in SAQ A, but you must confirm your site is “not susceptible to attacks from scripts” |
| Your page controls the card form or sends card data to a processor through JavaScript | SAQ A-EP | Yes, both |
| You store, process or transmit card data on your own systems | SAQ D | Yes, both |
| Large merchants assessed by a QSA | ROC | Yes, both |
What changed for SAQ A in January 2025?
On 30 January 2025, PCI SSC removed 6.4.3, 11.6.1 and 12.3.1 from SAQ A. In their place it added an eligibility criterion: the merchant must confirm its site is “not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” FAQ 1588 (February 2025) explains that the criterion applies only when your page embeds a provider’s payment form, such as an iframe. You can meet it in either of two ways:
- use techniques like those in 6.4.3 and 11.6.1, deployed by you or a third party; or
- get confirmation from your PCI DSS compliant payment provider that its embedded form, implemented according to its instructions, protects the payment page from script attacks.
The requirements themselves are still in the standard. In August 2026, PCI SSC revised FAQ 1331 to say SAQ eligibility criteria should not be used to decide which requirements apply in a ROC unless your compliance-accepting entity explicitly agrees. For a detailed SAQ A walkthrough, read SAQ A and the PCI DSS 4.0.1 script requirements.
What evidence will a QSA or assessor expect?
PCI SSC doesn’t publish a single evidence checklist, and assessors differ. The table below reflects the requirement text and common assessor practice (practitioner guidance, not a PCI SSC list).
| Requirement element | Evidence assessors typically ask for | Common approach |
|---|---|---|
| 6.4.3 inventory | A list of every script on each payment page, including third- and fourth-party scripts, with a written business or technical justification for each | Spreadsheet or tool-generated inventory, reviewed on a schedule |
| 6.4.3 authorization | Records showing who approved each script and when, plus a technical control that blocks unapproved scripts | Change tickets or approval log; CSP script-src allowlist |
| 6.4.3 integrity | Proof that scripts haven’t been altered: hashes, pinned versions or monitoring of contents | Subresource Integrity (SRI) for static files; hash monitoring for scripts that change |
| PCI 11.6.1 detection | A description of the mechanism, what it evaluates (headers and script contents as received by the browser) and who gets the alerts | Monitoring service, CSP violation reporting, or a scripted check |
| PCI 11.6.1 frequency | Logs showing the check ran at least weekly, or a documented 12.3.1 targeted risk analysis for another interval | Scheduled scans with retained history |
| PCI 11.6.1 response | Examples of alerts and how they were investigated or closed | Alert tickets, incident notes |
Two points come up often. Keep history, because an assessment covers a period, not just today. And keep inventory, approvals and alerts on the same page set. An inventory of /checkout paired with monitoring of the home page doesn’t line up.
Which approaches work, and what are the trade-offs?
The information supplement and the PCI DSS guidance column describe several techniques. No single one covers everything, so most merchants combine two or three.
| Approach | Helps with | Strengths | Limits |
|---|---|---|---|
| Content Security Policy (CSP) | 6.4.3 authorization; reporting can support PCI 11.6.1 | Free, enforced by the browser, blocks unlisted script sources | An allowlist trusts a whole host, not a file; it needs upkeep as vendors change; report-uri reports are noisy and can be forged |
| Subresource Integrity (SRI) | 6.4.3 integrity | Free; the browser refuses a script whose hash doesn’t match | Works only for static, versioned files. Many vendor tags change in place and publish no hash |
| Manual review | Inventory; can support PCI 11.6.1 | No tooling cost | Slow and error-prone. It sees your view, not what every browser gets, and a weekly person-dependent process is easy to miss. Many assessors expect an automated mechanism |
| Third-party monitoring tools | Both requirements | Automated inventory, change alerts, history and reports | Ongoing cost; agent-based tools add a script of their own; coverage varies (crawler vs in-browser) |
| Iframes / hosted fields | Reduces scope | Card entry happens on the provider’s domain, so the provider manages scripts in the frame | Scripts on your surrounding page still matter; under SAQ A you still need to satisfy the script criterion |
| Full redirect | Removes your page from the payment flow | Simplest; the FAQ 1588 criterion doesn’t apply | Less control over checkout design; possible conversion impact |
CSP decides where scripts may come from; SRI decides which exact file is acceptable. Where a vendor doesn’t support SRI, document the exception and rely on monitoring for that script’s integrity.
What is the lowest-cost way for a small merchant to comply?
If you’re a small merchant asking for the cheapest way to comply with 6.4.3, the cheapest control is usually having fewer scripts to control. In rough order of cost:
- Get the card form off your page. Move to a full redirect or a processor’s iframe or hosted fields. Redirect merchants on SAQ A don’t face the script criterion. Iframe merchants on SAQ A can usually ask their processor for the FAQ 1588 confirmation. Ask in writing and keep the reply.
- Strip the payment page. Remove analytics, heatmaps, chat and A/B testing tags from checkout. Every script you remove is one you don’t have to justify, pin or monitor.
- Write the inventory. For the scripts that remain, record the URL, owner, purpose, approver and date. A spreadsheet is acceptable evidence when it is accurate and kept up to date.
- Deploy a strict CSP and SRI. Both are free headers or attributes. Start in report-only mode, fix what breaks, then enforce. Avoid
unsafe-inlineandunsafe-evalon payment pages. - Automate the weekly check. A scheduled job that fetches the page, hashes each script and diffs headers is cheap to run. The real cost is maintaining it and keeping its logs. A low-cost monitoring service is often cheaper than staff time.
- Ask your MSP. If an IT provider manages your website, see what to expect from an MSP on PCI.
Don’t buy enterprise client-side security if steps 1 and 2 leave only two or three scripts.
How does CardSecurity approach payment page security?
CardSecurity practices this on its own checkout. Card entry runs in Payroc Hosted Fields, so CardSecurity never sees card numbers, and CardSecurity’ payment pages use a strict Content Security Policy. CardSecurity is also building payment page monitoring for merchant-hosted checkout pages, aimed at 6.4.3 and PCI DSS 11.6.1 evidence. It is in development and not yet generally available. CardSecurity provides supporting evidence only. It does not certify compliance.
Frequently asked questions
Does a Content Security Policy satisfy PCI DSS 6.4.3 on its own?
Usually not. A CSP script-src allowlist is a strong authorization control, but it trusts whole hosts rather than specific files, so it doesn’t prove integrity. You still need a written inventory with justifications and an integrity method such as Subresource Integrity or content monitoring. Many merchants pair CSP with SRI where vendors allow it, and use monitoring for scripts that change in place.
How often must the PCI DSS 11.6.1 check run?
At least weekly, or at the frequency set in a targeted risk analysis done under Requirement 12.3.1. If you pick a longer interval, the risk analysis must be documented and justified. Most merchants simply run the check weekly or more often, and keep the run history and alerts as evidence for the assessment period.
Do SAQ A merchants need 6.4.3 and PCI 11.6.1?
Not as SAQ A line items since the January 2025 revision. If your page embeds a processor’s iframe or hosted fields, though, you must confirm your site isn’t susceptible to script attacks. Per FAQ 1588, you do that with techniques like those in 6.4.3 and 11.6.1, or with written confirmation from your payment provider. Full-redirect merchants are not subject to that criterion.
If I use an iframe, who is responsible for the scripts?
Scripts inside the provider’s iframe are the provider’s responsibility under the v4.0.1 applicability notes. Scripts on your own page around the iframe stay your responsibility, because a malicious script there could overlay or replace the frame. That’s why SAQ A-EP, SAQ D and ROC merchants with embedded forms still apply 6.4.3 and 11.6.1 to the parent page.
Can I comply with PCI 11.6.1 by checking the page manually?
The requirement asks for a “mechanism” that alerts personnel. A manual review can work in principle, but it’s hard to evidence and easy to skip. Many assessors expect an automated, scheduled check of the headers and script contents the browser receives, with retained logs. Confirm with your assessor before relying on a manual process.
If you want to see how CardSecurity plans to cover script inventory, approvals and change alerts across your checkout pages, read about payment page monitoring and request early access.