Hacked Website: What to Do in the First Few Hours
A hacked website needs to be handled in order: isolate the site to stop the damage, immediately change every administrative password, restore a clean backup from before the incident, identify and fix the exploited vulnerability, then assess whether personal data was compromised so you can meet the GDPR notification obligation if needed. Following this order prevents restoring the site only to have it hacked again right away.
The real problem: panic wastes valuable time
Discovering that your site has been hacked usually triggers a panic reaction that pushes people to act out of order: deleting files at random, changing the displayed content without understanding the cause, or, at the other extreme, doing nothing at all for fear of making things worse. Both extremes are counterproductive. The good news is that the vast majority of website hacks (especially on CMS platforms like WordPress) follow known patterns and can be resolved with a methodical procedure, without needing highly specialized expertise.
The real emergency isn't fixing everything within the hour — it's stopping the damage from spreading: preventing the malicious content from continuing to display, keeping the attacker from retaining access, and stopping Google from indexing fraudulent pages that would durably harm the site's search rankings.
The checklist to follow, in order
- Take the site offline or put it into maintenance mode immediately, to stop exposing the malicious content to visitors and to Google's crawlers.
- Change every administrative password: CMS, hosting, database, FTP, and the domain name if access at that level is in doubt. A compromised password reused elsewhere needs to be changed everywhere it's used.
- Revoke suspicious access: admin accounts created without your approval, unknown API keys or tokens, unrecognized third-party app connections.
- Identify the extent of the damage: modified pages, added files, injected redirects, altered database. Comparing against the last clean backup helps pinpoint exactly what changed.
- Restore a backup taken before the incident, checking that it's genuinely clean (a backup taken after the initial breach may already contain the vulnerability or the malicious code).
- Identify and fix the root cause: outdated plugin, weak password, a known vulnerability left unpatched. Skipping this step keeps the risk of a repeat attack high.
- Update the entire site (CMS, themes, plugins) before bringing it back online for good.
- Assess the impact on personal data and trigger the GDPR notification procedure if necessary.
- Monitor the site over the following days to confirm the attacker hasn't retained any residual access.
The GDPR notification obligation in case of a data leak
If the hack exposed personal data belonging to your users or customers (emails, addresses, passwords, payment information), the GDPR imposes a precise procedure, not an option:
- Notification to the relevant data protection authority within 72 hours of discovering the breach, unless the risk to the affected individuals is judged negligible.
- Informing the affected individuals if the breach poses a high risk to their rights and freedoms (for example, exposed passwords or banking data).
- Documenting the incident, even without a mandatory notification: the nature of the breach, the data involved, the measures taken. This documentation may be requested during a subsequent audit.
A hack that only affects the site's appearance (defacement, a redirect) without any access to data doesn't trigger this obligation, but the actual extent of the damage should be properly assessed before ruling it out too quickly.
Identifying the cause to prevent it happening again
The most common causes of hacks on a professional website remain known, avoidable vulnerabilities: an outdated plugin or theme, a weak or reused password, no two-factor authentication on the admin panel, or shared hosting compromised through another site on the same server. A quick audit of these points after an incident is usually enough to identify the entry point without deep technical expertise.
What needlessly slows down bringing the site back online
- Restoring a backup without checking that it predates the breach, which reintroduces the vulnerability.
- Bringing the site back online before changing every password, leaving an open door for the attacker.
- Ignoring the server logs, which often contain precise clues about the intrusion method.
- Not notifying the host, who may have useful information (other sites affected on the same server, alerts already detected on their end).
Key takeaways
- The procedure follows a precise order: isolate, change access credentials, restore a clean backup, fix the cause, assess the impact on data.
- Restoring a backup without identifying the cause exposes you to a quick repeat hack, sometimes through the same vulnerability.
- A personal data leak requires notifying the relevant authority within 72 hours and, depending on the risk, informing the affected individuals.
- Most website hacks exploit known vulnerabilities (outdated plugin, weak password), not sophisticated attacks.
- A recent, tested backup is the single factor that most speeds up recovery after an incident.
Frequently asked questions
Should I take my site fully offline while I deal with the problem? Often yes, temporarily. Maintenance mode or taking the site offline stops the malicious content from continuing to display or being indexed while you handle the incident.
Do I need to notify the data protection authority if my site is hacked? Only if personal data has been compromised. The GDPR then requires notification within 72 hours, and informing the affected individuals if the risk to them is high.
Can I restore the site without knowing how it was hacked? It's risky: if the vulnerability isn't fixed, the site can be hacked again quickly, sometimes through the same method. Identifying the cause before bringing it back online avoids repeating the incident.
How long does it take to bring a hacked website back online? With a recent clean backup and a quickly identified cause, the site can be back online within a few hours. Without a usable backup, it can take several days.
In summary
A hacked website isn't an irreversible disaster: a methodical procedure (isolate, secure access, restore, fix the cause) usually gets it back online within a few hours to a few days. The best preparation happens upstream, with regular, tested backups that make this checklist much faster to execute. The VeryAppi subscription website plan includes the monitoring and backups that limit the impact of this kind of incident.
Frequently asked questions
›Should I take my site fully offline while I deal with the problem?
Often yes, temporarily. Putting the site into maintenance mode or taking it offline stops the malicious content from continuing to display to visitors or being indexed by Google while you handle the incident. Once the cause is fixed and a clean backup restored, the site can go back online.
›Do I need to notify the data protection authority if my site is hacked?
Only if personal data has been compromised (leak, unauthorized access). In that case, the GDPR requires notifying the relevant authority within 72 hours of discovering the breach, and informing the affected individuals if the risk to them is high. A hack that doesn't involve personal data doesn't trigger this obligation.
›Can I restore the site without knowing how it was hacked?
Technically yes, but it's risky: if the exploited vulnerability isn't fixed, the site will likely be hacked again quickly, sometimes through the same method. Identifying the cause before or during the restore avoids repeating the incident identically.
›How long does it take to bring a hacked website back online?
It depends on the severity and on whether a recent clean backup is available. With a reliable backup and a cause identified quickly, the site can be back online within a few hours. Without a usable backup, rebuilding it can take several days.