Website Hacked? Don't Panic, But Don't Lie to Your Users

Your website has been hacked. What do you tell your users?

Please don't tell them the site is “down for maintenance” when you know perfectly well that it has been compromised. Being hacked is bad enough; misleading the people who trusted you with their data is considerably worse. 

There are good reasons not to publish every detail while you're investigating an attack. But there is a big difference between saying “we don't know yet” and pretending that nothing happened. And depending on what personal data may have been exposed, there may also be some rather important legal obligations you need to understand.

Here's why honesty matters and why you should probably check the law before putting up that maintenance page.

Take the site offline

Your website has been hacked.

The first thing to do is not panic.

The second thing to do is not lie.

Of course, when a site has been hacked you need to take it offline, investigate what happened, remove the malicious code, restore clean backups, change credentials, check the server and work out how the attacker got in.

There is a long list of things that need doing.

But somewhere in that list should be another item:

Tell the people who need to know what happened.

And tell them the truth.

If someone visits your website and gets a maintenance message, they reasonably assume that somebody is doing routine work. Perhaps you are upgrading Joomla. Perhaps you are changing the template. Perhaps the hosting company is doing some maintenance.

• They don't assume that someone else has potentially had access to their account.
• They don't assume that their personal information might have been accessed.
• They don't assume that the password they use on your site might now need changing.

A fake maintenance message doesn't protect your users. It deprives them of information they may need to protect themselves.

But was it actually a data breach?

There is an important distinction between “the website was hacked” and “personal data was breached”.

Not every successful attack means that somebody has stolen personal information. An attacker might have modified a few files, inserted some spam, defaced the homepage or installed malware without ever accessing a database containing personal data.

But you need to establish that.

You don't get to decide that there wasn't a data breach simply because you didn't notice anything missing.

The UK's Information Commissioner's Office defines a personal data breach broadly. It can involve unauthorised access, disclosure, alteration, destruction or loss of personal data.

So if your website has been compromised, investigate it properly. Don't just restore yesterday's backup and declare victory.

Oh, and check the law

If personal data may have been involved, you have some rather more serious responsibilities.

Under the UK GDPR, if a personal data breach is likely to result in a risk to people's rights and freedoms, the organisation generally has to report it to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it.

If the breach is likely to result in a high risk to individuals, those affected also need to be informed without undue delay. You must also keep a record of personal data breaches, even where you decide that the breach does not need to be reported.

The ICO has a useful guide to this, imaginatively titled Personal data breaches: a guide. Read it. Particularly if you are currently staring at a hacked website wondering what to do next.

And don't assume that you have to have the entire investigation completed before the clock starts ticking. The ICO explicitly recognises that you may not have all the facts within 72 hours. You can report what you know and provide additional information later.

Tell your users

Notice that none of this means “tell everyone about every security incident”. You need to assess the circumstances and the risk. But if people do need to know, tell them.

And tell them in plain English.

There are perfectly good reasons why you might not want to publish every technical detail immediately. You might still be investigating. You might not know exactly what was accessed. You might be dealing with law enforcement. Publishing the precise vulnerability before it has been fixed might be unwise.

That's fine.

You don't have to know everything before you communicate something.

You can say:

“We have identified a security incident affecting our website. We have taken the site offline while we investigate. At this stage we are determining whether any personal information was accessed. We will provide further information as soon as we have established the facts.”

That's honest. It doesn't unnecessarily alarm people. It doesn't speculate. And it doesn't pretend that your website is closed because someone is installing a new extension.

Your users need to know

Suppose users have accounts on your website and you discover that the attacker may have obtained passwords. Those users need to know.

They may need to change their password on your site. More importantly, if they have reused that password somewhere else, they may need to change it there too.

Perhaps you don't store passwords in plaintext. Joomla doesn't. Good. You still need to understand what other information was accessible.

Perhaps the attacker only accessed email addresses. That might seem harmless. Until those users start receiving convincing phishing emails a few days later. Your users cannot take precautions against a threat they don't know exists.

That's one of the reasons the ICO requires affected individuals to be informed without undue delay when a personal data breach is likely to result in a high risk to their rights and freedoms. The purpose isn't to punish an organisation for being hacked. It is to give individuals an opportunity to protect themselves.

“But we're only a small website”

Sorry, that's not a magic exemption. Small organisations can hold plenty of personal data.

A small community website, club, charity, membership organisation or business may have names, email addresses, usernames, addresses, payment information or other personal information sitting in its database.

The size of your website doesn't determine whether the information matters to the people whose information it is. And don't assume that because you are a small organisation nobody will care. Your users certainly will.

Being hacked isn't the embarrassing bit

There is another reason for being honest. Being hacked isn't necessarily a sign that you're incompetent. Websites get hacked.

Software has vulnerabilities. Credentials get stolen. Humans make mistakes. Sometimes you do everything reasonably well and somebody still gets through.

What matters is what you do next. Trying to hide the incident behind a fake maintenance message because you're embarrassed is far worse. It undermines trust precisely when you need it most.

So don't panic

If your website gets hacked:

• Take it offline if necessary.
• Contain the incident.
• Preserve evidence.
• Investigate what happened.
• Restore from a known-good source.
• Fix the vulnerability.
• Change credentials.
• Check what was accessed.
• Assess whether personal data was involved.
• Document your decisions.
• Check your legal obligations.
• And, if people need to know, tell them.

Don't hide a security incident behind a fake maintenance message because you're embarrassed.

A responsible organisation doesn't pretend that nothing happened.

It says:

We were hacked.

This is what we know.

This is what we're doing about it.

This is what you need to do.

And when you don't know something yet, say that too.

Don't panic.

But don't lie.

Footnote: This has been written for UK websites, but the same probably applies to wherever you are in the world. The specific legal requirements will, of course, depend on the country or countries in which you operate and the people whose data you hold. This is not legal advice.