- Who has to comply: the thresholds that catch a business
- The APPs: your baseline security and destruction duties
- The Notifiable Data Breaches scheme: when a leak becomes a legal event
- PCI DSS: the private standard your contract makes binding
- Consumer law: how you describe charges
- The cost of getting it wrong
- A compliance checklist for card data
- When a lawyer is worth the call
- Start by deciding what you actually need to store
Nearly every Australian business takes card payments, but the moment you store a customer's card number you step into a legal framework that is easy to underestimate. The Privacy Act 1988 (Cth) and its Australian Privacy Principles (APPs) impose security duties on businesses that hold personal information, the Notifiable Data Breaches (NDB) scheme turns a security lapse into a legal event, the PCI DSS standard is written into your merchant agreement, and consumer law governs how you describe charges. Get any of these wrong and you face penalties, a cancelled merchant facility, and a loss of customer trust that is hard to rebuild.
This guide sets out who is caught by each set of rules, what each duty actually requires, what happens if you breach them, and the compliance steps worth taking this quarter. Most small and medium businesses find the safest answer is to stop holding card numbers at all, but you need to know the rules either way.
Who has to comply: the thresholds that catch a business
The rules around card data come from several directions at once, and each has its own trigger.
Start with the Privacy Act. Its APPs bind "APP entities", which includes most businesses whose annual turnover was more than $3 million in the previous financial year. Under s 6D of the Privacy Act 1988 (Cth), a business is a "small business" if its annual turnover was $3 million or less, and small business operators are generally exempt from the APPs. The exemption has significant carve-outs in s 6D(4): a business is still an APP entity if it provides a health service and holds health information, if it discloses personal information for a benefit, service or advantage, if it collects personal information for a benefit, or if it is a contracted service provider for a Commonwealth contract. A credit reporting body is also always covered.
Card data becomes personal information quickly. The Privacy Act protects "personal information", which is information or an opinion about an identified individual, or an individual who is reasonably identifiable. A card number on its own may not identify anyone, but a customer's name, email address or order history combined with their card number certainly does. Once card data is linked to an identifiable person, the APPs treat it like any other personal information, and the NDB scheme applies to it too.
PCI DSS applies by activity, not turnover. The Payment Card Industry Data Security Standard, developed by the PCI Security Standards Council, applies to any business that stores, processes or transmits cardholder data, regardless of size, turnover or industry. There is no $3 million threshold. Even though it is a private industry standard rather than an Australian statute, your merchant facility and gateway agreements will make compliance a binding contract term.
Consumer law adds a layer for everyone. The Australian Consumer Law (ACL), which is Schedule 2 of the Competition and Consumer Act 2010 (Cth), applies to anyone acting in trade or commerce, from a sole trader up. It matters here because of how you present payment terms, recurring billing and surcharges.
A quick self-assessment: if you are a large business, an SME over $3 million in turnover, or a small business in one of the carve-out categories, the Privacy Act duties below apply to you in full. If you are a genuinely exempt small business, the APPs do not bind you, but PCI DSS, your merchant contract and consumer law still do.
The APPs: your baseline security and destruction duties
If you are an APP entity, APP 11 of the Privacy Act 1988 (Cth) sets the baseline. Under APP 11.1, you must take such steps as are reasonable in the circumstances to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. "Reasonable in the circumstances" is a real test, not a slogan: it is assessed against the sensitivity of the information, the size of your business, the cost of safeguards, and the risk of harm. Card data sits at the sensitive end, so the reasonable standard for it is high.
APP 11.2 then requires you to destroy personal information, or ensure it is de-identified, once you no longer need it for any permitted purpose and you are not required by law to keep it. For card data this is the discipline most businesses neglect: keeping card numbers "just in case" a customer wants a refund is not a permitted purpose, and it is exactly the kind of retention that turns a routine breach into a serious one.
In practice, meeting APP 11 for card data means:
- Minimise: collect and keep card data only where there is a genuine operational need, such as a recurring billing arrangement.
- Encrypt: protect card data in transit with TLS and at rest, and manage keys separately from the data.
- Restrict: limit access to the smallest group of staff who need it, use multi-factor authentication for administrators, and log access.
- Retain and delete: set a firm retention schedule and securely delete or de-identify data when the purpose ends.
Transparency is the companion duty. At the point of collection you should tell customers what you are collecting, why, who you share it with, and how long you will keep it, and your privacy policy should describe how payment data is handled. These are the practical mechanisms that make APP compliance demonstrable.
The Notifiable Data Breaches scheme: when a leak becomes a legal event
Part IIIC of the Privacy Act 1988 (Cth) imposes a notification scheme on APP entities. Under s 26WE, an eligible data breach occurs when there is unauthorised access to, or unauthorised disclosure of, personal information, or loss of it in circumstances where unauthorised access or disclosure is likely, and a reasonable person would conclude the access or disclosure would be likely to result in serious harm to any affected individual.
If you become aware that there are reasonable grounds to believe an eligible data breach has happened, s 26WK requires you to prepare a statement setting out your identity and contact details, a description of the breach, the kinds of information concerned, and recommended steps for affected individuals, and to give that statement to the Office of the Australian Information Commissioner (OAIC). Section 26WL then requires you to notify affected individuals, or publish the statement on your website if individual notification is not practicable. Both must happen as soon as practicable after you become aware of the reasonable grounds.
Card data fits the serious harm test more easily than most information because it is directly usable for fraud and identity theft. The assessment is not something to improvise mid-incident: it is worth deciding in advance who will investigate, how you will assess whether a reasonable person would conclude serious harm is likely, and how you will reach affected customers within the statutory timeframe.
PCI DSS: the private standard your contract makes binding
PCI DSS is a global security standard developed by the PCI Security Standards Council, the body set up by the major card schemes. Version 4.0 was released in March 2022 and took full effect on 31 March 2024. It provides a baseline of technical and operational requirements designed to protect cardholder data, and it applies to all entities that store, process or transmit cardholder data.
The critical point for Australian businesses is that PCI DSS binds you through contract even where no statute does. Your merchant facility agreement, acquirer contract or gateway terms will require you to comply, give the provider audit rights, and let it terminate or suspend your facility if you do not. A data breach while you are non-compliant can also shift liability for fraud losses onto you under the card scheme rules.
The most effective way to shrink your PCI DSS burden is tokenisation. Tokenisation replaces the primary account number (PAN) with a non-sensitive token that your systems can store and use for repeat billing, without you ever holding the underlying card number. If you take payments through a hosted payment page or an embedded payment form from a PCI DSS compliant provider, and your systems never receive the PAN, your compliance scope drops dramatically, often to the simplest self-assessment questionnaire available.
Two cautions. First, your gateway's compliance does not make you compliant: your own environment, staff practices, logs and contracts are still in scope. Second, "tokenisation" only helps if it is real tokenisation, not merely masked card numbers that can be reversed, so check what your provider actually offers.
Consumer law: how you describe charges
The ACL applies independently of the privacy rules. Section 18 of the ACL prohibits misleading or deceptive conduct in trade or commerce, and it is a favourite tool of regulators and customers alike. For card-on-file arrangements this bites in the details: renewal dates, billing frequency, cancellation methods and refund terms all need to be stated clearly and prominently before a customer enters their card details, not buried in fine print. A customer who is charged for a subscription they did not realise was recurring, or who cannot find a way to cancel, has a plausible misleading conduct complaint.
Surcharges have their own rule. Under s 55B of the Competition and Consumer Act 2010 (Cth), you must not charge a payment surcharge that is excessive, meaning one that exceeds the permitted surcharge set by the Reserve Bank's payment system standards or regulations. The ACCC enforces this, and the practical test is that a surcharge should not exceed your cost of acceptance for that payment method.
If you run recurring billing or direct debits, the ASIC-administered ePayments Code is also relevant. Financial institutions that subscribe to the Code must comply with it, and its protections flow through to your customers through your acquiring bank, covering areas such as authorisation of recurring transactions and stopping payments. Aligning your billing practices with the Code's expectations, even where it does not bind you directly, is the low-risk way to operate.
The cost of getting it wrong
The penalty regime under the Privacy Act is now severe. Section 13G of the Privacy Act 1988 (Cth) imposes civil penalties for serious interference with privacy: up to $2.5 million for an individual, and for a body corporate the greatest of $50 million, three times the value of any benefit obtained from the conduct, or 30% of adjusted turnover during the breach period. A breach involving card data, which courts may treat as serious given the sensitivity factors in s 13G, can therefore reach eight-figure exposure for mid-sized businesses. Failing to meet the NDB notification duties can itself attract civil penalties, so the breach and the cover-up are each separately punishable.
Outside the Privacy Act, misleading conduct in how you bill customers exposes you to ACL remedies and regulator action, and excessive surcharges attract ACCC enforcement. Your merchant agreement adds a private enforcement layer: termination of your facility, chargeback exposure, and, under the card scheme rules, liability for fraud costs where you were non-compliant with PCI DSS. And the reputational damage from a card data breach, with the mandatory NDB statement describing it publicly, is usually the most expensive part of all.
A compliance checklist for card data
Work through these steps and you will cover most of what the law and your contracts require:
- Map the data flow: know where card numbers enter your systems, where they are stored, who can reach them, and where they leave.
- Tokenise: use a PCI DSS compliant gateway so you can bill repeat customers without holding the PAN, and purge any legacy stored numbers.
- Encrypt and lock down: encrypt in transit and at rest, apply least-privilege access with multi-factor authentication, and disable logging of card fields.
- Document the rules: an information security policy, acceptable use policy and staff training that explicitly bans card numbers in emails, spreadsheets and support tickets.
- Manage vendors: ensure contracts with gateways, CRMs and subscription platforms include security expectations, breach notification duties and sub-processor controls.
- Plan for the breach: a tested incident response plan covering who does what, how you assess serious harm, and how you meet NDB notification within the statutory timeframe.
- Retain and delete: set a retention schedule aligned to your actual needs and securely destroy card data when the purpose ends.
When a lawyer is worth the call
Much of this you can implement with your payment provider and IT team, but several decisions justify professional input. A lawyer can review your merchant and gateway agreements so you know exactly what you have signed up to, including audit rights and breach reporting timelines. They can draft a privacy policy and collection notices that meet the APPs, and data processing agreements that hold your vendors to the same standard. After a suspected breach, a lawyer is the difference between a defensible NDB assessment and a rushed one, because the reasonable grounds and serious harm tests in s 26WE are legal judgments. They can also check your surcharge position and your recurring billing terms against the ACL and the ePayments Code before a customer or regulator does.
Start by deciding what you actually need to store
The rule that surprises most Australian businesses is not the $3 million threshold under the Privacy Act, it is that PCI DSS and your merchant contract bind you from the first card transaction, whatever your size. The practical consequence is that the decision worth making this week is not "how do we store card numbers safely" but "do we need to store them at all". For the vast majority of SMEs the answer is no: route payments through a hosted page from a PCI DSS compliant provider, keep the token, and never let a full card number touch your systems, your inboxes or your spreadsheets. If a genuine business need for card-on-file storage does exist, treat the PAN as your most sensitive data, secure it under APP 11, plan for the NDB notification you hope never to send, and get your contracts and policies reviewed before you go live.