Notifiable Data Breaches and Hacked Websites

Who the scheme covers

The Notifiable Data Breaches scheme applies to organisations covered by the Privacy Act. The OAIC's quick reference guide lists Australian Government agencies, businesses and not-for-profits with an annual turnover over $3 million, private sector health service providers, credit reporting bodies, credit providers, and some small businesses with a turnover of $3 million or less, such as recipients of tax file numbers ^[1].

On the OAIC's definition, a small business turns over $3 million a year or less, yet several kinds of small business fall under the Act anyway ^[2]. Among them:

• anyone who provides a health service;
• a business that buys, sells or otherwise trades in people's personal details;
• a contractor delivering services under a contract with the Commonwealth;
• credit reporting bodies and residential tenancy database operators;
• businesses with reporting duties under Australia's anti-money laundering law;
• a business related to another business that the Act covers;
• a business accredited under the Consumer Data Right;
• a business that has chosen to opt in ^[2].

The full list on the OAIC page has a few more categories. If any might apply to you, read it directly.

When a website hack is a data breach

A data breach involves personal information being accessed or disclosed without authorisation, or lost. On a WordPress site, personal information commonly sits in:

• customer accounts on a shop or membership site;
• orders, invoices and delivery addresses;
• contact or quote form entries stored in the database by a form plugin;
• newsletter lists held in a plugin rather than an external service;
• user accounts for staff, including email addresses.

Many hacks never touch this data. A spam injection may only add pages. Others are aimed at it directly, such as scripts that skim card details from a checkout page. The honest answer in most cases is that it depends on what the attacker could reach, and for how long.

What makes a breach eligible

The OAIC explains that a data breach is eligible if it is likely to result in serious harm to one or more individuals, and the organisation has not been able to prevent the likely risk of serious harm with remedial action ^[1]. "Likely" means more probable than not, not merely possible, and the test is applied from the point of view of a reasonable person ^[1].

Remedial action is relevant to websites. If a breach is contained quickly and the information cannot be used, the risk of serious harm may be prevented. That is one reason containment comes first.

The 30-day assessment

If you only suspect an eligible breach, the OAIC says you must take all reasonable steps to complete an assessment within 30 calendar days after becoming aware of the grounds for suspicion ^[1]. If an eligible breach has occurred, you must notify individuals at risk of serious harm and provide a statement to the OAIC as soon as practicable, unless an exception applies ^[1].

The OAIC frames the response in four steps: contain, assess, notify and review ^[1]. Those steps line up neatly with a website recovery: contain the site, establish the facts, notify if required, and fix the cause.

What a website owner should record

An assessment is only as good as its facts. After a hack, try to keep:

1. a full copy of the site's files and database as they were when the problem was found;
2. hosting access logs and any security plugin logs, before they rotate away;
3. a list of administrator accounts, including any the attacker created and when;
4. notes on which plugins stored personal information and how much;
5. the timeline: when the break-in began, when it was noticed and when it was contained.

When we carry out a recovery, our report records these facts as far as the evidence allows. We do not decide whether a breach is eligible; that is your organisation's call, ideally with advice.

Website-specific questions to answer in an assessment

When the incident is a website hack, a few practical questions shape the assessment:

• Did the attacker have administrator access, which usually means they could view orders, users and form entries, or only the ability to change files?
• Did a form plugin store submissions in the database, and if so, how far back?
• Were card details entered on your own pages, or on the payment provider's hosted checkout?
• Is there evidence of data being exported, such as unusual downloads in the logs or a new export plugin?
• How long was the attacker in the site before it was contained?

Clear answers to these, backed by logs and the preserved copy of the site, make the decision about whether the breach is eligible far easier to reach and to explain.

The statutory privacy tort

Since 10 June 2025, individuals can take court action against a person or business that intrudes on their seclusion or misuses information about them, where they had a reasonable expectation of privacy ^[3]. A Queensland Law Society summary sets out the other elements: the invasion must be intentional or reckless, it must be serious, and the public interest in the person's privacy must outweigh competing public interests such as freedom of expression ^[4]. The OAIC notes it does not have a direct role in administering the tort and that people should seek independent legal advice ^[3].

Our reading, which is not legal advice: because the invasion must be intentional or reckless, the tort is aimed mainly at whoever deliberately or recklessly invades someone's privacy, such as the attacker, rather than a business that was itself the victim of a hack. That business may still have duties under the Privacy Act. For a website owner, the practical lesson is the same as for the breach scheme: collect only what you need and protect what you collect.

Working with the people cleaning the site

The person removing malware and the person assessing a possible data breach are often working at the same time, and their goals can pull in different directions. Cleanup wants to remove the bad files quickly. A breach assessment needs to know what those files did before they were removed.

A few habits keep both on track:

• Ask for a full copy of the site and database to be taken before anything is deleted, and keep it somewhere private.
• Ask whoever cleans the site to note what they found and where, in plain language, including any file that appeared to send data elsewhere.
• Keep hosting access logs for the period in question, if your host provides them, before they are rotated away.
• Make one person responsible for the assessment decision. Technical helpers can supply facts, but the business decides whether a breach is eligible and whether to notify.

None of this requires the cleanup to wait. It simply means the evidence is preserved first, so the assessment is based on what actually happened rather than on guesswork afterwards. If you are unsure whether your business is covered or whether a breach is eligible, the OAIC guidance linked in the sources is the place to start, and a lawyer can advise on your situation.

Reducing what a hack can expose

• Do not store form entries in WordPress if they are already emailed to you; many form plugins can switch storage off.
• Delete old customer accounts and orders you no longer need to keep.
• Use a payment provider's hosted checkout so card details never touch your server.
• Limit administrator accounts to the people who need them.

For help after an incident, see our guide to ReportCyber and IDCARE.