If your business stores, processes or transmits card payment data, PCI DSS compliance applies to you. It’s the security standard the card brands enforce on every merchant that touches cardholder data. The good news for most Australian SMEs: with the right payment setup, your obligations are smaller than you’d think.
What PCI DSS actually is
PCI DSS stands for the Payment Card Industry Data Security Standard. It’s not Australian law or a government regulation. It’s a contractual standard maintained by the PCI Security Standards Council, owned by the major card brands: Visa, Mastercard, American Express, Discover and JCB. When you signed your merchant agreement, you agreed to comply with it.
The current version is PCI DSS 4.0.1, a minor revision of version 4.0. The old v3.2.1 standard was retired in March 2024, and the future-dated v4 requirements that were optional during the transition became mandatory from 31 March 2025. So if you ticked “best practice, not yet required” against those controls at your last assessment, that grace period is over. The v4 requirements push harder on multi-factor authentication for all access into the cardholder environment, tighter password rules, anti-phishing controls and scripts on payment pages.
Who has to comply
The rule is blunt: any business that stores, processes or transmits cardholder data must comply, whether you take ten transactions a year or ten thousand. A florist in Camberwell on an EFTPOS terminal is in scope, just as a national retailer is. The standard scales, but never switches off.
Cardholder data means the primary account number (the long number on the front of the card) plus cardholder name and expiry date. A stricter category, sensitive authentication data, covers the full magnetic stripe, the CVV/CVC code and the PIN. That must never be stored after a transaction is authorised, full stop. A surprising number of Australian SMEs breach this by keeping card details in an email, spreadsheet or CRM note.
The four merchant levels
Merchants are sorted into four levels by annual card transaction volume. The level decides how you validate, from a heavyweight external audit at the top to a self-assessment at the bottom. The Visa and Mastercard tiers below are the ones almost everyone uses.
| Level | Annual transaction volume (per card brand) | How you typically validate |
|---|---|---|
| Level 1 | Over 6 million transactions | Annual on-site audit by a Qualified Security Assessor (QSA), plus quarterly network scans |
| Level 2 | 1 million to 6 million | Annual Self-Assessment Questionnaire (SAQ), often QSA-reviewed, plus quarterly scans |
| Level 3 | 20,000 to 1 million (e-commerce) | Annual SAQ plus quarterly scans |
| Level 4 | Under 20,000 e-commerce, or up to 1 million total | Annual SAQ; scans where applicable |
The overwhelming majority of Melbourne SMEs are Level 4: no auditor turns up at your door. You validate by completing the correct Self-Assessment Questionnaire and, depending on your setup, running quarterly external vulnerability scans through an Approved Scanning Vendor.
Self-Assessment Questionnaires in plain English
The SAQ is a checklist you fill in to attest that you meet the relevant controls. There are several types, and using the wrong one means answering hundreds of irrelevant questions or, worse, under-scoping your risk.
- SAQ A — for merchants who have fully outsourced all cardholder data handling to a compliant third party and never see the card number: the e-commerce shop that redirects customers to Stripe, Square or a hosted payment page. The shortest questionnaire, and where you want to be.
- SAQ A-EP — for e-commerce merchants whose site doesn’t receive card data directly but controls how the payment page is delivered, for example loading the payment fields via JavaScript from a provider. Your site can affect transaction security, so you carry more responsibility.
- SAQ B — for merchants using standalone dial-out or IP EFTPOS terminals, or imprint machines, with no electronic card data storage. Common for cafes, trades and small retail.
- SAQ C — for merchants with an internet-connected payment application, where card data is processed through your own network but not stored. More controls apply because your environment is exposed.
- SAQ D — the full questionnaire, for everyone who doesn’t fit the simpler categories, including any merchant that stores cardholder data. It covers all applicable requirements and is the most demanding.
The practical goal is to engineer your way down to SAQ A or SAQ B. The further down you sit, the fewer controls you have to build, evidence and maintain.
How compliant providers and tokenisation shrink your scope
“Scope” is the most important word in PCI DSS. It covers every system, person and process that touches cardholder data, or connects to systems that do. So the smartest strategy isn’t building more controls, it’s keeping card data out of your environment entirely.
Two levers do most of the work. The first is a compliant payment provider. If you take payments through a PCI-certified gateway like Stripe, Square, Tyro or Eway, and your systems never see the raw card number, you’ve handed the hardest parts of the standard to a provider built to meet them. That’s the gap between a 20-question SAQ A and a 300-question SAQ D.
The second lever is tokenisation. Instead of storing a customer’s card number for repeat billing, the provider stores it and hands you back a meaningless token. You charge the card by sending the token, never the real number. Because the token is worthless to an attacker, the systems holding it generally fall out of scope. For any business doing subscriptions, retainers or saved-card checkouts, it’s the cleanest way to keep recurring payments running.
Where Australian SMEs trip up
We see the same handful of mistakes again and again across Melbourne, and nearly all are avoidable.
- Storing card details in email, spreadsheets or CRM notes. A customer phones through a card number and a staff member jots it into an Outlook draft “to process later”. That single act pulls your mail platform and CRM into scope and often breaches the rule against storing the CVV.
- Assuming the payment provider’s compliance covers you. Stripe being compliant doesn’t make you compliant; you still complete your own SAQ. Outsourcing reduces your obligations; it doesn’t delete them.
- Treating it as a once-a-year form. PCI DSS 4.0.1 expects controls to operate continuously, not just on assessment day.
- Conflating it with the Privacy Act. Your obligations to the Office of the Australian Information Commissioner (OAIC) under the Notifiable Data Breaches scheme are separate. A card data breach can trigger both; meeting one doesn’t satisfy the other.
A professional services firm in Hawthorn we work with had been emailing client card numbers internally for years to process annual retainer invoices. We moved them to tokenised, saved-card billing through their gateway and wiped the historical card data out of their mail and accounting systems, dropping them from SAQ D to a short SAQ A.
How an MSP handles the technical side
For businesses that can’t fully outsource card handling, real engineering work is involved, and that’s where an MSP earns its keep.
Network segmentation
The fastest way to cut scope where card data does flow is segmentation: isolating the cardholder data environment from the rest of your network with firewalls and VLANs, so a compromise of the office Wi-Fi can’t reach the payment systems. Done correctly, it takes dozens of machines out of scope. Done badly, your entire flat network is in scope. This is core to our cybersecurity services and overlaps with the controls we deploy under our Essential Eight compliance work.
Logging and monitoring
Version 4 is strict about logging. You need to capture access to cardholder systems, retain those logs, and actually review them, not just generate them. For most SMEs that means feeding logs into a SIEM with alerting, which is what our security operations team runs. When a bank or assessor asks for six months of access logs, having them already searchable is the difference between a quick answer and a panic.
The everyday technical controls
The rest is the disciplined IT hygiene that underpins the whole standard: MFA on every account that can reach the cardholder environment, prompt patching, hardened firewall rules, anti-malware, encrypted transmission of card data and tightly controlled access. None of it is glamorous; all of it is the work, and the controls slip the moment no one owns them. As a Melbourne managed IT services provider founded in 2014, with 13 Australian-employed engineers and a 24/7 NOC in Tecoma, TechAssist keeps them running year-round, not just at audit time.
Frequently asked questions
Is PCI DSS a legal requirement in Australia?
Not directly. There’s no Australian statute that says “thou shalt be PCI compliant”. It’s a contractual obligation you accepted in your merchant agreement. Non-compliance can mean fines passed on by your acquirer, higher transaction fees, or in serious cases losing the ability to take card payments. A breach can also trigger separate obligations under the OAIC’s Notifiable Data Breaches scheme.
We only take payments through Square. Are we still in scope?
Yes, but your scope is small. If card data never lands in your own systems, you’ll typically complete the short SAQ A and confirm you don’t store card details anywhere. The risk is staff quietly creating shadow records, a card number in an email or spreadsheet, which drags other systems back into scope.
How often do we have to validate, and what’s the easiest way to stay compliant?
Validation is annual for most merchants: you complete the relevant SAQ each year, plus quarterly external vulnerability scans through an Approved Scanning Vendor if your setup requires them. The underlying controls are expected to operate year-round under PCI DSS 4.0.1. The single biggest thing you can do to make it easier is get card data out of your environment, using a compliant gateway and tokenisation so you never handle the raw card number.
Getting it sorted
For most Melbourne SMEs, PCI DSS compliance is far more achievable than the standard’s bulk suggests, provided you keep card data out of your hands and lock down whatever’s left. If you’re not sure which SAQ applies, or you suspect card numbers are lurking in your email and CRM, that’s worth fixing before an incident forces the issue. Get in touch with our team and we’ll map your scope and the controls you need.