PCI DSS Requirements in Australia: The Plain-English Guide for Merchants
Last updated: July 2026 · Prepared and reviewed by the Vintaris security team
If your business takes card payments, PCI DSS applies to you. It is also one of the most over-complicated topics in security, usually explained by people selling certification. This guide is the plain-English version for Australian merchants: what the standard actually requires, which level you sit at, what changed in version 4, and, most usefully, which obligations your payment platform already carries versus the ones that are genuinely yours.
Is PCI DSS a legal requirement in Australia?
No. PCI DSS is not legislation, no Australian law names it. It is a contractual requirement: the card schemes (Visa, Mastercard and others) require it of the banks and payment providers, who pass it down to you through your merchant agreement. The practical effect is similar to law, non-compliance can mean fines passed through by your acquirer, higher processing costs, or losing the ability to take cards, and after a breach involving card data, your compliance status heavily shapes who pays for it. Separately, the Privacy Act and the Notifiable Data Breaches scheme are actual law, and they apply to the same incidents.
The 12 requirements, in plain English
The standard is organised as twelve requirements under six goals. Here is what each really asks:
Network security controls
Firewalls and network rules protecting where card data lives.
Secure configurations
No default passwords or out-of-the-box settings on anything.
Protect stored card data
Ideally, do not store it at all; if you must, encrypt it.
Protect data in transit
Strong encryption whenever card data crosses networks.
Malware protection
Anti-malware on the systems that could touch card data.
Secure systems and software
Patch promptly and build securely.
Restrict access by need
Only people who need card data can reach it.
Identify and authenticate
Individual logins, strong passwords, MFA where required.
Physical security
Control physical access to systems and paper holding card data.
Log and monitor
Record who did what, and keep the records.
Test regularly
Scans and testing that find weaknesses before attackers do.
Security policy and program
Written policies, assigned responsibility, trained staff.
If that list looks familiar, it should: it is largely the same hygiene a good cyber security assessment checks, which is why merchants with sound general security find PCI far less painful than the acronym suggests.
Merchant levels: which one are you?
Your level is set by annual card transaction volume, and it determines how compliance is validated, not what the requirements are.
| Level | Transaction threshold | What validation looks like | Typical Australian example |
|---|---|---|---|
| Level 1 | Over 6 million transactions a year (or previously breached) | Annual on-site assessment by a QSA, quarterly network scans | National chains and major processors |
| Level 2 | 1 to 6 million | Annual self-assessment questionnaire (SAQ), quarterly scans | Large multi-site retailers |
| Level 3 | 20,000 to 1 million ecommerce transactions | Annual SAQ, quarterly scans | Established Australian online retailers |
| Level 4 | Everyone else | Annual SAQ; scans as required by your bank | Most Australian small and mid-market merchants |
The sentence that matters: most Australian merchants are Level 3 or 4, self-assessing, no auditor visits, no certification ceremony, just an honest annual questionnaire and, depending on setup, quarterly scans.
The SAQ: which questionnaire fits your setup
Self-assessment comes in flavours matched to how you take payments. The right SAQ can shrink your obligations dramatically.
Ecommerce fully outsourced to a compliant provider (hosted payment page, redirect or embedded iframe). The shortest questionnaire, and where well-configured platform stores usually land.
Ecommerce where your site affects the payment flow. Longer, and a reason to prefer fully hosted payment pages.
Standalone terminals, no electronic storage. Common for simple in-person setups.
Payment application systems connected to the internet, segmented from other networks, and not storing card data electronically. Stored card data moves you to SAQ D.
Everything else, including anyone storing card data. The longest form, and usually a sign the setup should change rather than the paperwork.
How you configure your store and terminals decides which SAQ you face, which is a design decision, not a paperwork one, and exactly the kind of thing an assessment settles.
What changed in PCI DSS 4.0
Version 4 replaced 3.2.1, with a set of future-dated requirements that have since become mandatory. The changes most relevant to Australian SMB merchants: passwords got stronger (minimum length raised to 12 characters where passwords are used), MFA got broader (required for all access into the cardholder data environment, not just admins), ecommerce pages must be monitored for unauthorised script changes (a direct answer to checkout card-skimming), and the standard now allows a customised approach for mature organisations, which most SMBs should ignore in favour of the defined controls. If your last SAQ predates version 4, expect new questions this cycle.
Logging, audits and the schedule
How often are PCI DSS audits required?
Validation is annual: Level 1 merchants have an annual QSA assessment; everyone else completes their SAQ annually. Many setups also require quarterly external vulnerability scans by an approved scanning vendor (ASV).
Logging requirements
Systems in scope must record access and activity, with logs retained for twelve months, the most recent three months immediately available. In practice, vendor-managed platforms generate and hold most of these logs for you, but ‘the platform probably keeps logs’ is not an answer an assessor, or a forensic investigator, accepts. Know where yours are.
Breach notification: two clocks, not one
PCI DSS carries contractual notification duties: a suspected card-data breach must be reported to your acquiring bank and the card schemes, promptly, with forensic investigation requirements attached. Separately and simultaneously, Australia’s Notifiable Data Breaches scheme runs its own 30-day assessment clock for personal information, and the Privacy Act does not care what your merchant agreement says. A card-data incident in an Australian business triggers both regimes at once, which is why the incident response plan should name both before anything happens. Insurers watch the same territory: card data handling is standard underwriting ground, and our guide to cyber insurance requirements covers how the pieces fit.
What your payment platform handles, and what is genuinely yours
The most useful PCI question an Australian merchant can ask.
Your payment platform typically handles
- Card data encryption and storage
- Payment page security (hosted/redirect setups)
- Platform patching
- Terminal compliance (bank-supplied and modern cloud POS)
- Most in-scope logging
Genuinely yours
- Every password and MFA setting on your accounts
- Who has admin access, including agencies and past staff
- The network your registers sit on
- Your devices and their updates
- Your staff’s habits
- The annual SAQ answers, honestly given
- Knowing what connects to what
Notice what the right-hand column is: ordinary security hygiene. Which is the quiet truth of PCI for most merchants, the platform carries the card-specific machinery, and your real obligations are the same controls that stop ransomware and satisfy your insurer. One piece of work covers all three.
Frequently asked questions
What are the PCI DSS compliance requirements?
Twelve requirements across six goals: secure networks and configurations, protecting stored and transmitted card data, malware protection and secure systems, need-based access with individual authentication, physical security, logging and monitoring, regular testing, and a written security program. Validation is annual, by QSA assessment at Level 1 and self-assessment questionnaire for everyone else.
What are the PCI DSS password requirements?
Under version 4, passwords in the cardholder data environment must be at least 12 characters where passwords are used (systems that genuinely cannot support 12 may use a minimum of 8), with complexity rules, and MFA is required for access into that environment. Individual accounts are mandatory, shared logins fail Requirement 8 outright.
What are the PCI DSS firewall requirements?
Requirement 1 asks for network security controls, firewalls or their modern equivalents, restricting traffic to and from wherever card data lives, with rules documented and reviewed. For platform-hosted merchants this mostly means sensible network separation on your side, especially keeping POS traffic away from guest Wi-Fi.
What are the PCI DSS cryptography requirements?
Stored card data must be rendered unreadable (strong encryption, truncation or tokenisation), and card data in transit over open networks must use strong, current encryption. Most merchants meet this by not storing card data at all and letting the payment platform tokenise it.
Do I need a QSA audit?
Only Level 1 merchants (over 6 million transactions a year, or previously breached) require annual on-site QSA assessment. Most Australian merchants self-assess. If your bank has asked for more than an SAQ, something about your volume or history has changed, worth understanding before responding.
Where can I get the PCI DSS 4.0 requirements PDF?
The official standard and all SAQ documents are free from the PCI Security Standards Council document library at pcisecuritystandards.org. Beware paraphrased versions elsewhere; the council's documents are the source of truth.
Prepared and reviewed by the Vintaris security team. Plain-English security guidance for Australian merchants, funnelled toward the controls that actually reduce risk.
Vintaris provides cybersecurity assessment and advisory services. Vintaris is not a Qualified Security Assessor (QSA), and this guide is general information, not compliance certification or legal advice. Confirm your obligations with your acquiring bank and the PCI Security Standards Council documentation.