PCI DSS v4.0.1 for Australian merchants: levels, SAQ selection and scope reduction

The Payment Card Industry Data Security Standard governs how cardholder data is handled by anyone who stores, processes or transmits it. Australian merchants encounter it through their acquiring bank rather than through legislation, which is why so many businesses discover their obligations only when a bank sends a compliance notice.

The current version is PCI DSS v4.0.1, published in June 2024 and now the only active version — v4.0 was retired at the end of 2024 (checked August 2026). See the PCI Security Standards Council's standard page and its document library for the current forms.

PCI DSS is a contract, not a statute

No Australian Act requires PCI DSS compliance. The standard binds you through the card scheme rules, which your acquiring bank passes down in your merchant agreement. The consequences of non-compliance are therefore contractual and commercial — monthly non-compliance fees, higher interchange, remediation costs after an incident, and in the worst case termination of card acceptance.

That does not mean Australian law is absent. If a card data breach exposes personal information, the Notifiable Data Breaches scheme applies on its own terms and its own clock; see the step-by-step NDB walkthrough and use the NDB timer if you are already in an incident. Security of personal information is separately governed by APP 11. For payment-specific consumer protections, the ePayments Code sits alongside, and is explained in the ePayments Code guide.

Who decides your merchant level

Not you, and not the PCI Security Standards Council. Merchant levels are set by the card brands, and your acquiring bank tells you which one applies. The Council writes the standard and the validation forms; it does not assign levels.

Levels are driven by annual transaction volume, and the thresholds differ between brands — Visa and Mastercard commonly use six million transactions a year for Level 1, while American Express applies a lower threshold. Broadly:

Two practical points. First, a merchant of any size can be pushed to Level 1 by a card brand following a compromise — level is a risk judgement, not purely arithmetic. Second, if you are a service provider rather than a merchant, a separate service provider level scheme applies with its own thresholds. Ask your acquirer to confirm your level in writing; it is the only authoritative answer.

Choosing the right self-assessment questionnaire

The SAQ you complete is determined by how you accept payments, and it dictates how many of the standard's requirements you are answerable for. Choosing the wrong one is the most common validation error, and it is usually a choice made optimistically.

The Council republished all SAQ types for v4.0.1, and acquirers expect the v4.0.1 forms for any attestation period covering March 2025 or later.

What changed on 31 March 2025

PCI DSS v4 introduced 64 new requirements. Thirteen applied immediately on adoption. The remaining 51 were future-dated and became mandatory on 31 March 2025. That date has passed: any assessment performed since is scored with all 64 in scope, and no best-practice or transition period remains for any of them (checked August 2026).

The future-dated set is heavily weighted toward e-commerce and toward evidence of ongoing operation rather than point-in-time configuration. The two most disruptive for online merchants are:

• Requirement 6.4.3 — inventory and integrity management of scripts loaded and executed in the consumer's browser on payment pages, with authorisation for each script and justification for its necessity.
• Requirement 11.6.1 — a change and tamper detection mechanism that alerts on unauthorised modification to the HTTP headers and content of payment pages as received by the consumer's browser.

Both exist because of client-side skimming attacks, where the merchant's own servers are untouched and the theft happens in the customer's browser. Traditional server-side controls do not detect them.

The SAQ A eligibility trap for e-commerce

This is the detail that catches Australian e-commerce merchants who assumed the fully outsourced model kept them out of scope.

The Council removed requirements 6.4.3 and 11.6.1 from SAQ A effective 31 March 2025 — and replaced them with a new eligibility criterion. To use SAQ A, the merchant must confirm that all elements of the payment page or form delivered to the customer's browser originate only and directly from a PCI DSS compliant third-party service provider or payment processor, and that the merchant has confirmed its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

The requirements did not disappear. They moved from the requirement list into the entry gate. If you cannot make that confirmation, you are not eligible for SAQ A at all and must validate against SAQ A-EP, which carries a far larger requirement set and a materially higher cost. In practice, a checkout page that loads analytics, chat widgets, tag managers or A/B testing scripts alongside a hosted payment iframe is exactly the fact pattern that puts SAQ A eligibility in doubt.

The remediation is architectural, not documentary: get third-party scripts off the payment page, or accept SAQ A-EP and build the script inventory and page-change detection the standard requires.

Scope reduction: the only lever that materially cuts cost

Everything in PCI DSS is priced by scope — the systems, people and processes that store, process or transmit account data, plus anything connected to or that could affect the security of that environment. Reducing scope is the only structural way to reduce cost.

The proven techniques, in rough order of effect:

1. Never store the primary account number. Storage pulls in encryption, key management, retention and secure deletion requirements. Use the acquirer's or gateway's tokenisation and store the token.
2. Use a hosted payment page or iframe delivered wholly by a compliant provider. This is the difference between SAQ A and SAQ A-EP, and it is worth an architecture change.
3. Deploy validated point-to-point encryption in card-present environments. Where the terminal encrypts at the point of interaction and you never see clear-text data, SAQ P2PE applies.
4. Segment the network. Isolate any remaining cardholder data environment so the rest of the corporate network is out of scope. Segmentation must be tested, not merely asserted.
5. Strip third-party scripts from checkout. Directly protects SAQ A eligibility and reduces client-side attack surface.
6. Eliminate telephone card capture, or isolate it. Call recording that captures card numbers drags the contact centre and its recording platform into scope.

The annual validation cycle and where Australian law bites

Validation is annual and its components are dictated by your level and SAQ:

• Annual — SAQ and Attestation of Compliance, or a Report on Compliance and Attestation for Level 1.
• Quarterly — external vulnerability scans by an Approved Scanning Vendor where the SAQ requires them, with passing scans for four consecutive quarters.
• Annual or on significant change — penetration testing where the SAQ requires it; segmentation testing where segmentation is relied on to reduce scope.
• Ongoing — the operational requirements, which are the majority of the future-dated set and are tested against evidence across the period, not on the day.

Note the asymmetry between PCI DSS and Australian law during an incident. PCI obligations run through your acquirer under your merchant agreement, on the scheme's timeline. The Notifiable Data Breaches obligation runs on the Privacy Act's own timeline regardless of what your acquirer is doing, and other reporting duties may apply depending on your sector — the cyber incident notification tool maps which ones are triggered. Build the incident response plan to satisfy both, because in a live compromise you will not have time to reconcile two different clocks.