PCI DSS v4.0.1 in Australia: What Is Now Mandatory and What Trips Merchants Up

There is a comfortable story some Australian merchants are still telling themselves about PCI DSS v4: that the big deadline is somewhere ahead of them.

It is not. It was 31 March 2025.

Version 3.2.1 retired on 31 March 2024. Version 4.0.1, published on 11 June 2024 as a limited revision with clarifications rather than new requirements, has been the only active version since 31 December 2024. And of the 64 new requirements introduced in v4.x, 51 were future-dated and became mandatory on 31 March 2025.

Every requirement in the standard is now in force. There is nothing left to defer.

That matters because a lot of Australian organisations completed a v4 self-assessment questionnaire or a Report on Compliance during the transition window, marked the future-dated items as "not yet applicable", and have not revisited them since. If that describes your last assessment, your next one will look materially different.

This article walks through what the future-dated requirements actually ask for, the ones that consistently catch merchants out, and how PCI DSS interacts with Australian privacy obligations. If you want the short version: client-side script control, authenticated internal scanning, and MFA into the whole cardholder data environment are where most of the pain sits.

First, a word on how PCI works in Australia

PCI DSS has no Australian statutory backing. There is no local regulator enforcing it, no legislation that makes it a legal obligation, and no ACSC or OAIC mandate behind it.

It reaches you through contract. Your acquiring bank requires it, because the card schemes require it of them. The technical requirements are identical worldwide. What varies locally is how your acquirer defines your merchant level, what validation evidence they want, and what they do when you fall short.

Two practical consequences follow.

One: your acquirer is the authority on your obligations, not a blog and not a consultant. If you are unclear on your merchant level or your required validation method, ask them in writing.

Two: PCI compliance is not Privacy Act compliance. We come back to this at the end, because it is the single most common misunderstanding we encounter in Australian assessments.

What actually changed in v4.x

Version 4.0 restructured the standard around two ideas.

Customised approach. Alongside the defined approach, where you implement the requirement as written, v4 lets you meet the stated objective of a requirement through a different control, provided you document a targeted risk analysis and your assessor validates that the objective is met. This is genuinely useful for organisations with mature but non-standard architectures. It is also more work, not less, and it is not a shortcut for organisations that simply have not implemented the control.

Targeted risk analysis. A number of requirements no longer prescribe a frequency and instead ask you to determine one through a documented risk analysis, reviewed at least annually. This shifts effort from doing the thing to justifying how often you do it.

Version 4.0.1 then arrived in June 2024. It is a limited revision. It corrects errors, clarifies wording and reorganises some guidance. It adds no new requirements and removes none. If someone tells you the upgrade from v4.0 to v4.0.1 requires a control uplift, they are mistaken.

The future-dated requirements now in force

These are the v4.x requirements that became mandatory on 31 March 2025, grouped by the problem they solve.

Client-side and payment page security

6.4.3 - Payment page scripts must be managed. You must maintain an inventory of every script that loads and executes in the consumer's browser on a payment page, authorise each one, and assure its integrity.

11.6.1 - Change and tamper detection. You must deploy a mechanism that detects unauthorised modification to the HTTP headers and content of payment pages as received by the consumer browser, and alerts on it.

These two are the response to Magecart-style digital skimming, and together they are the most commonly failed pair in the standard. They are hard for a reason: most e-commerce payment pages load a long tail of third-party scripts through tag managers, analytics tools, chat widgets and marketing pixels, and very few organisations have ever inventoried them, let alone authorised them individually.

If you take one thing from this article, make it a script inventory for your payment pages.

6.4.2 - Automated technical solution for public-facing web applications. A WAF or equivalent automated solution is now required for public-facing web applications. Annual manual review plus penetration testing is no longer an acceptable alternative.

Authentication and access

8.4.2 - MFA for all access into the cardholder data environment. Not just remote access. Not just administrative access. All access into the CDE. This is a significant scope expansion for organisations that implemented MFA on the VPN and stopped there, and it frequently surfaces service accounts and internal jump paths nobody had considered.

8.3.6 - Minimum password length of 12 characters, or 8 where the system cannot technically support 12, and containing both numeric and alphabetic characters.

8.6.1, 8.6.2, 8.6.3 - Application and system accounts. Additional conditions apply to accounts that can be used for interactive login. Passwords for application and system accounts must not be hard-coded into scripts, configuration files or source code, and must be changed periodically based on a targeted risk analysis. Hard-coded credentials are endemic in older integration code, and this requirement is why several organisations we have worked with ended up standing up a secrets manager.

7.2.4 - User accounts and access privileges reviewed at least every six months.

7.2.5 - Application and system accounts and their access privileges reviewed periodically, at a frequency you determine through a targeted risk analysis.

Vulnerability management

11.3.1.1 - Vulnerabilities not ranked high-risk or critical must still be managed. You cannot simply close them as out of scope. You need a documented approach, informed by a targeted risk analysis, that addresses them and rescans as appropriate.

11.3.1.2 - Internal vulnerability scans must be authenticated. Unauthenticated internal scanning no longer satisfies the requirement. Systems that cannot accept credentials need to be documented as exceptions.

6.3.2 - Inventory of bespoke and custom software and third-party components, maintained to support vulnerability and patch management. In practice this is a software bill of materials obligation for the components in your payment applications.

Cryptography and data protection

3.5.1.2 - Disk-level and partition-level encryption no longer counts as encryption at rest for primary account numbers on non-removable electronic media. Full disk encryption on a running server protects against physical theft, not against a logged-in attacker, and the standard now says so. If your control narrative for stored PAN was "the volume is encrypted", it needs revisiting.

4.2.1 - Certificates used to transmit PAN over open public networks must be valid and not expired or revoked.

4.2.1.1 - Maintain an inventory of trusted keys and certificates used for those transmissions.

Malware and phishing

5.2.3.1 - Periodically evaluate systems not normally considered at risk from malware, at a frequency determined by targeted risk analysis, to confirm that assessment still holds.

5.3.3 - Anti-malware controls for removable electronic media, either automatic scanning on insert or continuous behavioural analysis.

5.4.1 - Processes and automated mechanisms to detect and protect personnel from phishing attacks. Note the wording: automated mechanisms, not awareness training alone. Training is required elsewhere. This requirement asks for technical controls.

Programme governance and review

12.3.3 - Annual review of cryptographic suites and protocols in use, with active monitoring of industry trends for emerging weaknesses. This is where post-quantum planning starts to show up in assessments.

12.3.4 - Annual review of all hardware and software technologies in use, checking whether anything is unsupported, end of life, or no longer receiving security fixes, with a documented plan for remediation.

12.6.2 - Annual review and update of the security awareness programme, explicitly covering phishing, social engineering and acceptable use of end-user technologies.

12.10.7 - Incident response procedures for PAN discovered where it is not expected. You need a defined response for the moment someone finds cardholder data in a log file, a support ticket, a shared drive or a test database. This is a very common real-world event and almost nobody had a procedure for it before v4.

Where Australian merchants most often get caught

From assessments we have supported, five patterns recur.

Scope creep nobody documented. Call recordings that captured card numbers. A support tool where agents pasted PANs into tickets. A backup that quietly includes a table nobody knew held card data. Requirement 12.10.7 exists precisely because this happens, and requirement 12.5.2's annual scope confirmation is what surfaces it. Do the scope exercise properly and you avoid unpleasant surprises later.

Third-party scripts on payment pages. As above. Marketing teams add tags through a tag manager without a security review, and the payment page inherits them. Requirements 6.4.3 and 11.6.1 make this visible.

MFA that stops at the perimeter. Requirement 8.4.2 catches internal administrative paths, service-to-service authentication and jump hosts that were previously exempt.

Targeted risk analyses that do not exist. Multiple requirements now depend on a documented TRA to justify a frequency. Assessors ask for them. If you set a quarterly cadence with no analysis behind it, you have not met the requirement even though you are doing the activity.

Treating a compliant SAQ as a security outcome. A validated self-assessment questionnaire tells your acquirer you met the standard on the day you signed it. It does not tell you your environment is secure, and it does not survive a change to your payment flow. Reassess when the flow changes, not only when the anniversary arrives.

PCI DSS is not Privacy Act compliance

This is worth stating plainly because it costs Australian organisations real money when they get it wrong.

Cardholder data is almost always also personal information under the Privacy Act 1988. That means APP 11.1 applies concurrently and independently: you must take reasonable steps to protect the personal information you hold from misuse, interference, loss, unauthorised access, modification and disclosure. The Notifiable Data Breaches scheme applies too.

The two regimes do not map onto each other. PCI DSS is narrow, prescriptive and contractual. It protects a specific data type through a specific control set, validated on a cycle. The Privacy Act is broad, principles-based and legal. It covers all personal information you hold, asks for reasonable steps rather than named controls, and is enforced by a regulator with civil penalty powers.

You can be fully PCI compliant and still fall short of APP 11, because APP 11 covers the customer names, addresses, dates of birth, transaction histories and identity documents sitting outside your cardholder data environment. In a breach, the OAIC will ask about those.

The practical answer is to run PCI DSS inside a broader information security management system rather than beside it. If you already hold ISO 27001 certification, most of the PCI governance requirements in Requirement 12 map onto controls you have already implemented, and the ISMS gives you the scope, risk and asset management structure that PCI assumes but does not build for you.

What about the next version?

We have not seen a confirmed PCI Security Standards Council announcement of a v4.1 or v5.0 timeline, and we would not plan against a date you see quoted without checking the Council's own site.

What we would plan for is the direction of travel. The v4 changes point clearly towards continuous validation rather than annual point-in-time assessment, towards client-side and supply chain security, and towards risk-justified frequencies rather than prescribed ones. Building for that direction is a better investment than waiting for the next version number.

A sensible next step

If your last assessment predates 31 March 2025, or if it marked future-dated requirements as not yet applicable, the useful thing to do is a gap review against the full current standard rather than a fresh SAQ.

Start with the three that cause the most rework: the payment page script inventory for 6.4.3 and 11.6.1, the MFA scope expansion under 8.4.2, and authenticated internal scanning under 11.3.1.2. Those three tend to determine how long the rest of the programme takes.

Talk it through with us

CyberNinja provides PCI DSS advisory and readiness support for Australian and New Zealand merchants and service providers, including scope reduction, gap assessment and remediation planning, and integration with ISO 27001 where you already have an ISMS. Get in touch for a scoping conversation.

This article is general guidance, not a substitute for advice from a Qualified Security Assessor or your acquiring bank, and reflects the position as at August 2026. Your validation requirements depend on your merchant level and your acquirer. Confirm the current requirement text against the PCI Security Standards Council document library.

Sources