PCI DSS 6.4.3 and 11.6.1: An ANZ Guide for 2026

What do PCI DSS 6.4.3 and 11.6.1 require?

Requirement 6.4.3 covers every payment page script that is loaded and executed in the customer's browser. You need a method to confirm each script is authorised, a method to assure each script's integrity, and an inventory of all scripts with a written business or technical justification for each one.

Requirement 11.6.1 requires a change and tamper detection mechanism. It must alert on unauthorised changes to security-impacting HTTP headers and to the script contents of payment pages as received by the browser. It must run at least weekly, or at a frequency you set through a targeted risk analysis under 12.3.1.

PCI DSS does not mandate a particular technology. The Council's own guidance gives Content Security Policy and Subresource Integrity as examples, alongside commercial script-monitoring tools.

When did these requirements become mandatory?

Requirements 6.4.3, 11.6.1 and 12.3.1 were future-dated in PCI DSS v4.0. They were best practice until 31 March 2025 and have been required since. The Council has used both 31 March and 1 April 2025 in its own communications, which amounts to the same thing: if you validate today, they are in scope.

Is PCI DSS v4.0.1 still current in 2026?

Yes. PCI DSS v4.0.1 was published in June 2024 as a limited revision with no new or deleted requirements, and v4.0 was retired at the end of 2024. In June 2026 the Council opened a request for comments on v4.0.1, open from 3 June to 20 July 2026, which it describes as the start of the next iteration of the standard.

No newer version has been published. Anything describing PCI DSS v5 as released is wrong as of September 2026. Check the Council's document library before any assessment, because errata can be published without much announcement.

What changed in SAQ A in January 2025?

On 30 January 2025 the Council published a revised SAQ A. It removed 6.4.3, 11.6.1 and the supporting 12.3.1 targeted risk analysis from the questionnaire, and replaced them with a new eligibility criterion: the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The Council was explicit that this does not remove or diminish the underlying requirements within PCI DSS. The questions moved; the risk did not. Reading the change as SAQ A merchants no longer need script security is the most common error in this area.

How does an SAQ A merchant confirm it is not susceptible to script attacks?

The Council's FAQ, published in February 2025, gives two routes. You can use techniques such as those described in 6.4.3 and 11.6.1, deployed yourself or by a third party. Or you can obtain confirmation from your PCI DSS compliant payment provider that its embedded payment form, implemented according to its instructions, includes protection against script attacks.

The criterion applies only where your page embeds the provider's payment form, typically as an iframe. It does not apply to full redirects or to fully outsourced links such as a pay-by-email link.

Do 6.4.3 and 11.6.1 apply if we use an iframe or a redirect?

If your page redirects the customer to the provider's payment page, the requirements do not apply to your page.

If your page embeds the provider's iframe, your parent page is still in scope. An iframe does not take the page that hosts it out of scope, because a malicious script on the parent can overlay or replace the form.

In a single-page application, 6.4.3 and 11.6.1 apply to all views, because scripts persist in memory across them. Scripts used for 3-D Secure do not need 6.4.3 validation, but any script used for another purpose does.

What is a targeted risk analysis under 12.3.1, and do we need one?

A 12.3.1 targeted risk analysis is only needed where a requirement explicitly lets you set your own frequency, and you choose to do so. It must identify the assets protected, the threats, the factors that affect likelihood and impact, and justify the frequency chosen. It is reviewed at least every twelve months.

For 11.6.1 the Council's suggested baseline is at least once every seven days. If you run the check weekly, you do not need a targeted risk analysis to justify it. You need one if you run it less often than weekly.

A targeted risk analysis cannot be used to make a fixed-frequency activity happen less often. That requires the customised approach and its separate 12.3.2 analysis.

What evidence will an assessor want?

A current script inventory with a justification for each script, evidence of how each was authorised, and evidence of the integrity method. PCI DSS does not prescribe the format: a spreadsheet can be enough for a simple checkout, while complex sites usually need automated tooling.

Records showing that the 11.6.1 mechanism ran at the required frequency and how alerts were handled. Policies under 6.1.1 and 11.1.1, and defined roles under 6.1.2 and 11.1.2, that cover these activities.

Because third-party scripts change without notice, the Council accepts authorisation as soon as possible after a change as well as before it. That is not a licence to skip it.

Is PCI DSS mandatory in Australia and New Zealand?

Not by statute. PCI DSS is a contractual obligation that flows from the card schemes through your acquirer. The Council itself does not set compliance or validation levels; the brands and acquirers do.

In New Zealand, for example, BNZ's merchant terms require all merchants to be compliant at all times, require validation at levels 1 to 3 and at level 4 on request, and make the merchant liable for scheme fines levied on the bank. Australian acquirers take a similar contractual approach. Read your own merchant agreement for the exact position.

How big is card-not-present fraud in Australia?

According to AusPayNet, card fraud in the year to 30 June 2025 was $854 million, down from $868 million. Domestic card-not-present fraud fell 11.1 percent to $312 million, a record low rate of 75 cents per $1,000 spent. Overseas card-not-present fraud on Australian cards was $434.3 million, at $10.75 per $1,000.

The domestic improvement follows the industry's card-not-present fraud mitigation framework, which has been in place since 1 July 2019 as part of the AusPayNet code set. Merchants whose card-not-present fraud stays above the published thresholds for consecutive quarters can be required by their acquirer to apply strong customer authentication. Confirm the current thresholds with your acquirer, because they are applied through acquirer contracts.

What should we do this quarter?

Establish which pattern your checkout uses: redirect, embedded iframe, or a page you host. That single fact determines whether 6.4.3 and 11.6.1 apply to you and which SAQ you are eligible for.

If they apply, build the script inventory first. Then choose the integrity and detection approach, decide whether weekly monitoring is enough or whether you need a targeted risk analysis, and write the evidence trail as you go rather than at assessment time.

If you rely on your provider under SAQ A, get their confirmation in writing and keep it with your self-assessment.

How GRCLens supports PCI DSS

GRCLens implements PCI DSS v4.0.1 with requirement-level evidence, SAQ and report on compliance workflows, and targeted risk analysis records that carry their review dates. The same control model supports ISO/IEC 27001 and the Essential Eight, so evidence you collect for 6.4.3 and 11.6.1 is reused rather than recreated.

Primary sources

PCI Security Standards Council: PCI DSS v4.0.1; announcement of the revised SAQ A (30 January 2025); FAQ on SAQ A eligibility for scripts (February 2025); information supplement on payment page security and preventing e-skimming (March 2025); Targeted Risk Analysis Guidance (November 2023); request for comments on PCI DSS v4.0.1 (June 2026). AusPayNet card fraud statistics, July 2024 to June 2025. BNZ merchant PCI DSS guidance.

This article is general information. Confirm your obligations with your acquirer and a Qualified Security Assessor.