My website has been hacked

Contain first, assess second, clean third. The common and expensive mistake is to reverse the order — reinstalling or restoring immediately, which destroys the evidence of how it happened and usually leaves the way in open.

This page is the response sequence. Why small business sites are targeted at all is a separate question, covered in the security guides.

The first hour

1. Take it offline or put a holding page up. A compromised site may be serving malware, spam or a phishing page to your customers, and every hour it runs adds to the damage to people who trusted your address.

2. Change passwords, starting with the domain registrar. Registrar, hosting, platform administrator, email, and any account that shares the password with them. The registrar first, because control of the domain is the account with the most consequence.

3. Do not delete anything. The modified files, the new administrator account, the server logs — these are how you find out what happened and whether it is finished. Deleting them turns a diagnosable incident into a guess.

4. Tell the host. Most have handled it many times, some will identify it immediately, and if they suspended the account they already know something you do not.

5. Write down the timeline. When it was noticed, what was seen, what changed in the fortnight before. This is what the person cleaning it will ask for first.

Assessing what actually happened

Four questions decide how large the incident is, and they are worth answering before anyone starts cleaning.

Question	Why it matters
How did they get in?	If this is not answered, it happens again
What was changed?	Determines what cleaning means
Was anything taken?	Decides whether obligations attach
Is it still happening?	Decides whether offline stays offline

The usual entry points are an out-of-date platform, plugin or theme; a weak or reused administrator password; and credentials taken from a compromised computer belonging to someone with access. The first is the most common by a wide margin and is a maintenance failure rather than a sophisticated attack.

The cleaning, and why restoring a backup is not it

Restoring a backup is only a fix when two things are true: the backup predates the compromise, and the way in has been closed. If either is false, the same outcome arrives again within days on the same unpatched software.

The order that works:

1. Identify and close the entry point — update the software, remove the vulnerable component, change the credentials.
2. Restore or clean the files, from a backup you have confirmed is clean.
3. Remove any accounts that were created, and any scheduled tasks that were added.
4. Reset every password again, after the cleaning, because credentials captured during the compromise are still valid otherwise.
5. Check whether search engines or browsers have flagged the site, and request a review once it is clean.

Step 5 is often forgotten and is the one customers see. A site can be clean for a week and still show a browser warning because nobody asked for it to be re-checked.

Not the same thing as a “data breach” in the news

A website being hacked and a large-scale data breach reported on the news are related but different: a national headline about a breach usually describes a large organisation’s systems being compromised at scale, while this page is about a single small-business website that has been hacked. The response sequence above is the same regardless of size, but the reporting obligations discussed below turn on what was actually accessed on your own site, not on unrelated cyber incidents you may have read about elsewhere.

The Australian obligations, stated carefully

If customer personal information may have been accessed, this stops being only a technical problem.

The Privacy Act 1988 and the Australian Privacy Principles govern what an organisation must do with personal information it holds, and there is a notifiable data breaches scheme attached to it. Whether the Act applies to your business, whether what happened is a breach within the meaning of the scheme, and what you are required to do are all questions that depend on facts this page does not have — including your turnover, what information you hold and what was actually accessed.

The honest instruction is: if there is any prospect that customer personal information was involved, take advice promptly rather than deciding from a web page. This page is general information and is not legal advice.

Two practical points that are not legal advice. Keep the evidence, because the assessment depends on it. And do not tell customers “no data was accessed” until somebody has actually established that, because a reassurance that turns out to be wrong is worse than the original incident.

If the site takes payments

A store that processes card details, or that could have been modified to capture them, is a materially more serious incident. Card data handling carries its own obligations through the payment schemes and through whoever provides the payment gateway. Contact the payment provider early rather than late — they have processes for this and they would rather hear from you than from a card issuer.

What it costs, and who does it

Cleaning a compromised site is specialist work priced by the hour, and the hours depend on what was done rather than on the size of the site. It is not usually within an ordinary maintenance retainer, and a retainer that includes it will say so.

Where the compromise happened because updates were not applied, and updates were somebody’s contractual responsibility, that is a conversation to have separately and in writing. What a maintenance arrangement should actually contain is on what website maintenance actually is.

Preventing the repeat

Updates applied on a schedule, two-factor authentication on the accounts that matter, unique passwords, removal of components that are no longer used, and backups that have been restored at least once as a test. A backup nobody has ever restored is an assumption rather than a backup, and it is the assumption that fails during exactly this incident.

What to do next

If it is happening now: offline, passwords, registrar first, delete nothing, call the host. If it is not happening now, check when your platform and its components were last updated. That single date predicts this incident better than anything else, and where responsibility for it sits is on the maintenance page.