Guide
Website hacked? What to do first, a guide for small businesses
If your website has been hacked, the order matters: preserve evidence first, lock the attacker out second, clean up third. In practice that means not deleting anything in a hurry, telling your host or agency, changing every password from a device you trust, putting the site into maintenance mode if needed and then restoring it from a backup taken before the attack. After that you ask Google to review any warning through Search Console and work out whether the incident has to be reported under the GDPR. This guide walks you through the first hours and days, no IT department required.
- Typical signs are redirects to unfamiliar sites, spam pages in Google results, browser warnings, unknown admin accounts and emails from your hosting provider.
- Do not delete straight away: back up files, database and logs first. They are what tells you later how the attacker got in.
- Change passwords only from a device that cannot be affected. Any password stored on the hacked server should be treated as known.
- Restoring a backup from before the attack is the safest route. But unless the hole is closed, the site will soon be hacked again.
- If personal data was involved, for example from contact forms or an online shop, you may have to notify the data protection authority within 72 hours (Art. 33 GDPR).
Spotting the signs
How a hack usually shows itself.
Go to sectionThe first hours
Seven steps in the right order.
Go to sectionCheck and clean up
Backup, files, database, accounts.
Go to sectionRemoving the Google warning
Requesting a review in Search Console.
Go to sectionReporting and liability
GDPR, police, documentation.
Go to sectionWhen to get help
Where doing it yourself stops working.
Go to sectionHow to tell your website has been hacked
Most attacks on small websites are nothing personal: automated tools scan the internet for sites with known weaknesses. The attacker usually wants to use your site quietly, for spam, redirects to scam pages or malware. That is why a hack is often noticed late, and often by someone else first.
| Sign | What may be behind it | How to check |
|---|---|---|
| Visitors end up on unfamiliar sites | Injected code that redirects only some visitors, for example only mobile users or only people arriving from Google | Open your site on a phone via a Google search, not only by typing the address |
| Strange pages in Google results | Spam pages under your domain, for example pharmacy adverts or pages in Japanese characters | Search Google for site:your-domain.com and look through the results |
| A warning in the browser or in Search Console | Google has found malware, phishing or hacked content on your site | Search Console, “Security issues” section; without an account: Site Status in the Google Transparency Report |
| Admin accounts you do not recognise | The attacker has created a permanent way back in | Go through the user list in your site’s admin area for accounts you cannot place |
| An email from your host | Your provider has noticed malicious code, spam being sent or unusual load, and may already have suspended the site | Read it carefully and check with your host via the phone number or customer account you already know, not via links in the email |
| Customers report odd emails or form replies | Your contact form or mailbox is being abused for spam | Check sent mail and form settings |
One sign on its own is not proof. Watch out for one trap, though: an email saying “your website has been hacked” and pushing you to click a link may itself be a scam. Always verify such messages through a channel you already know.
The first hours: seven steps in the right order
The natural reflex is to delete everything suspicious immediately. That is exactly what you should not do. Clean up first and you destroy the traces that show how the attacker got in, and without that answer the door stays open for next time.
1. Stay calm and keep notes
Write down, with times, what you noticed, whom you told and what you did, plus screenshots. You will need these notes for your host, your insurer and any data protection report.
2. Preserve evidence instead of deleting it
Have a full copy of the website files and a database export made, along with the web server logs. Many hosts keep logs for only a few days. Store the copy separately and never restore it, it is for investigation only.
3. Tell your host, agency or platform
Your host can see things you cannot, such as server-level access, and has often already reacted. If an agency looks after the site, inform it straight away. On site builders such as Shopify, Wix or Jimdo, the platform’s support team is your first point of contact.
4. Change passwords from a clean device
Change the logins for the website admin area, hosting account, database, FTP/SFTP, domain management and the mailbox used for password resets. Do it from a device that cannot be affected, such as a different computer or your phone. If malware sits on your work computer, it will simply capture the new password too. Wherever possible, switch on two-factor authentication at the same time, meaning a second code on top of the password.
5. Take the site offline for now
If the site serves malicious code or sends visitors to scam pages, switch it to maintenance mode or ask your host to suspend it. That protects your visitors and stops the attacker from carrying on. A short maintenance page does far less damage to your reputation than a site that sends customers to fraudsters.
6. Remove unknown access
Lock unknown user accounts and document them before deleting them. Also check who else has access: former contractors, connected apps, API keys. On site builders these are often called “staff accounts” or “apps”.
7. Keep an eye on the data protection clock
A 72-hour period starts when you become aware of a breach of personal data. Establish early whether form submissions, customer accounts or orders could be affected. Details in the section Reporting and liability.
Site builder or agency: what changes
On site builders such as Shopify, Wix or Jimdo, the platform runs the servers and software. A “hack” there is usually a taken-over account: someone guessed or phished your password. The key steps are changing the password, enabling two-factor authentication, reviewing staff accounts and installed apps and contacting the platform’s support. You do not have to examine files or servers yourself.
If an agency runs your site, you are still responsible for the data. Ask specific questions: Which weakness was the way in? Which data could be reached? Which backup was restored? Get the answers in writing.
Check and clean up: back to a known good state
There are two ways to clean up. Which one fits depends on whether you have a backup that was definitely made before the attack.
| Route | When it fits | What to watch out for |
|---|---|---|
| Restore a backup from before the attack | You have a complete backup that demonstrably predates the first sign | Content added since then is lost or has to be re-entered by hand. Apply all updates and close the hole immediately afterwards, or the site will soon be hacked again. |
| Clean the live system | There is no clean backup, or the attack began before the oldest one | Laborious and error-prone. Attackers usually leave several backdoors, and one that is missed is enough for the next break-in. |
Timing is what matters. Many break-ins are only noticed weeks later, by which point the most recent backup is often already compromised. Compare the backup date with the earliest sign, such as the creation date of an unknown account or the modification date of an unfamiliar file.
Whichever route you take, these checks belong in it:
- Users: go through every account with admin or editor rights. Each one must belong to a person you know.
- Files: new or recently changed program files, especially in places that should only hold images, such as the uploads folder.
- Database: injected scripts and links in pages, posts and settings, new redirects, content that is not yours.
- Extensions: plugins, themes or apps you do not recognise, and those that have not been updated for a long time. An update alone does not remove files or accounts that were already planted.
- Server settings: altered redirect rules (on Apache servers in the
.htaccessfile) and new scheduled tasks. - Domain and email: whether the records in your domain management (DNS) still point to your server, and whether forwarding rules you did not create have been added to your mailbox.
For WordPress we have already covered the technical details: the order of steps after a break-in in the “Suspected compromise” section of our PHP2Shell article, and long-term hardening in our guide WordPress security, including verifying file checksums and renewing the security keys in wp-config.php.
The most important question during clean-up is not “what did the attacker leave behind?” but “how did they get in?”. Typical answers are an outdated plugin, a guessed or reused password, a stolen account belonging to a former contractor, or outdated server software. As long as that question is open, any clean-up is only temporary.
Getting the Google warning removed
If Google has flagged your site as hacked or dangerous, the warning does not disappear on its own once the site is clean. You have to request a review. According to Google, it works like this:
Set up Search Console
You need to have verified ownership of your website in Google Search Console. If your agency did that so far, ask to be added as an owner.
Read the “Security issues” report
Google names the type of problem and gives sample URLs. The list is not exhaustive: the problem has to be fixed across the whole site, not just on the pages listed.
Clean up first, then request
Fix every reported issue, close the hole and test your fixes. According to Google, requesting a review while the problem persists only prolongs the process.
“Request review”
Request the review in the report and describe what the problem was, what you did about it and how the result can be seen. Do not submit a second request until the decision arrives by email.
Google states that reviews take from a few days to several weeks, depending on the type of issue. Without a Search Console account, you can look up your domain’s current status in the Site Status tool of the Google Transparency Report.
Reporting and liability
This section is an overview and not legal advice. For your specific case, consult your data protection officer or a lawyer.
Notifying the data protection authority (Art. 33 GDPR)
If personal data was affected, such as contact form enquiries, customer accounts, orders or newsletter addresses, you must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach. In Germany that is usually the data protection authority of your federal state. Notification is only unnecessary if the breach is unlikely to result in a risk to the people concerned. If you report later, you have to give reasons for the delay.
- Documentation is always required. Even if you do not notify, Art. 33(5) GDPR requires you to record the incident, its facts, its effects and the action taken. Your notes from step 1 are the start.
- Informing the people affected is required under Art. 34 GDPR where the breach is likely to result in a high risk to them, for example if login details or payment information may have been exposed.
- Early beats complete. If you do not have all the information yet, Art. 33(4) GDPR allows you to provide it in phases without undue further delay.
Reporting to the police
Filing a criminal complaint is optional but can be worthwhile, for example for your insurer or if customer data is being misused. In Germany, every federal state has a Central Office for Cybercrime (Zentrale Ansprechstelle Cybercrime, ZAC) for businesses. It provides an initial assessment and starts the criminal investigation. The list is on polizei.de.
What the BSI provides
Germany’s Federal Office for Information Security (BSI) offers small and medium-sized businesses an IT emergency card, “What to do in IT emergencies”, a printable notice supplemented by a catalogue of emergency management measures. Both are mainly useful for being prepared next time.
Liability in brief
Under Art. 82 GDPR, anyone who suffers damage as a result of an infringement of the GDPR can claim compensation. The only way out of liability is to prove that you are not in any way responsible for the event that caused the damage. Whether and how that applies to you depends on the circumstances. In practice, a clean record of what you did before and after the incident is your best footing. If you have cyber insurance, check your policy for the deadline to report a claim and inform the insurer early.
Afterwards: making sure it does not happen again
A cleaned site is only safe once the way in is closed. The basics apply to every website: keep software and extensions up to date and delete what you do not use, use two-factor authentication for every admin account, keep backups off the server and test the restore, and use Search Console as an early warning system. For WordPress, our guide WordPress security covers every point with a checklist.
When to get help
Much of this guide you can do yourself as a business owner: change passwords, inform your host, check accounts, have a backup restored. Professional help is worth it as soon as one of these applies:
- You do not know how the attacker got in, or the site was hacked again after a clean-up.
- There is no backup that definitely predates the attack.
- Customer data, payment information or login details may have been exposed, and you need to assess the scope for a report.
- Other systems can be reached through the website, such as a shop back end, inventory system or customer portal.
- Your service provider cannot answer the questions about the way in, the scope and the clean-up in writing.
We help small businesses assess an incident technically, answer the question of how the attacker got in and harden the site afterwards, with a load and stress test within an agreed scope if you want one. After the clean-up, a penetration test within a scope agreed in writing checks whether the hole is closed and whether there are other ways in. Every finding comes with evidence and a suggested fix, and a retest follows once you have made your corrections. We tailor the scope to your site and prepare an individual quote.
Has your website been hacked?
Tell us in an initial call what you have noticed and what has happened so far. We will tell you plainly which steps make sense now and where we can help.
Request an emergency website checkThis guide does not replace an assessment of your individual case. CyberSec42 provides independent technical security testing. It is not an accredited certification body and does not provide legal advice.
Frequently asked questions
How can I find out whether my website has been hacked?
Open the site on a phone via a Google search, search Google for site:your-domain.com, check the “Security issues” section in Search Console and look through the user list in your admin area for unknown accounts. Many hacks are deliberately inconspicuous, so a glance at the home page is not enough.
Should I delete the hacked site straight away?
No. Back up files, database and server logs first. Otherwise you lose the traces that show how the attacker got in. Put the site into maintenance mode or have your host suspend it instead.
Is restoring a backup enough?
Only if the backup definitely predates the attack and you close the hole afterwards. A backup brings back the old site, but also the old weakness. Without updates and new passwords, the site is often hacked again quickly.
Do I have to report a website hack to the data protection authority?
If personal data may be affected, for example from contact forms, customer accounts or a shop, usually yes: without undue delay and, where feasible, within 72 hours (Art. 33 GDPR). The duty only falls away if the breach is unlikely to result in a risk to the people concerned. You must document the incident in any case. This is not legal advice.
How long does it take Google to remove the warning?
Once you have requested a review in Search Console, Google states a few days to several weeks, depending on the type of issue. Only submit the request once the whole site is clean, otherwise processing takes longer.
Further reading
- Website security check in 8 steps
- Shopify store security: what merchants have to do themselves
- WordPress security: the practical guide for businesses
- PHP2Shell: What the critical PHP flaws mean for WordPress sites
- Vulnerability Assessment: what it is and when you need one
- Service: penetration testing with verified findings
Sources
- EUR-Lex: Regulation (EU) 2016/679 (GDPR), Articles 33, 34 and 82
- Google Search Console Help: Security issues report
- Google: Request a review (help for hacked sites)
- Google Transparency Report: Site Status
- German Police: Central Offices for Cybercrime (ZAC) for businesses (in German)
- BSI: IT emergency card “What to do in IT emergencies”