You have noticed the site doing strange things. Foreign text appeared on a page, customers complain about redirects, Google flags the site as dangerous, or the host wrote to say spam is leaving your server. The natural reaction is to move fast and delete everything first. That is the reaction to avoid.
This article is a plan you can keep ready before anything happens. It is split by the hour, because the first hours decide how much damage is done.
Hour 0 to 1: stop the damage, do not delete the evidence
- Stay calm and name one person to lead the incident. Too many people making decisions at once creates chaos.
- Isolate the problem. Turn on a maintenance mode or take the site offline for a while. The goal is not to "fix" it. The goal is to stop further harm, such as customer data being pulled out.
- Change access. Passwords for hosting, the admin area, the database, FTP/SSH, and email. Do this from a clean device, not from a computer that may be infected.
- Do not delete anything and do not reinstall. Infected files, logs, and the database are evidence. Without them you cannot tell how the attacker got in, and after a restore they come back the same way.
Hour 1 to 4: preserve evidence and find the scope
- Make a full copy of the files and the database (a server snapshot, if the host offers one).
- Save web server, application, and access logs, especially from the last few weeks.
- Find what changed: new or modified files, unknown users in the admin area, suspicious cron jobs, new plugins.
- Look for webshells, small scripts that let the attacker return even after a "cleanup".
- Find out whether personal data was involved. Later duties depend on that.
Hour 4 to 12: restore from a clean state
The safest path is almost always a restore from a verified, clean backup, not "cleaning" an infected site. The steps:
- Pick a backup from before the compromise. The analysis from the previous step helps you choose it.
- Restore the site in a clean environment (a new server or a clean install).
- Close the hole. Update the core, plugins, and themes, and remove what you do not use. A restore without that does not help. See also PHP2Shell: critical PHP vulnerabilities.
- Change every secret: passwords, API keys, payment gateway keys, and the salt values in the configuration.
- Review user accounts and remove any you do not recognise.
- Turn on two-factor sign-in.
If you have no backup, or it is not usable, this is the moment to ask for specialist help. For next time: Backups and ransomware protection.
Hour 12 to 24: communication and notifications
Customers and partners
If customer data may have been affected, tell them promptly, clearly, and without marketing language. Say what happened, what it means for them, and what they should do (change a password, for example).
Notifications
- If personal data has leaked, the GDPR requires the controller to notify the supervisory authority (in Slovakia, the Office for Personal Data Protection) without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to risk the rights and freedoms of people.
- If you are an entity covered by NIS2, stricter and faster deadlines apply. More in NIS2 and cybersecurity in Slovakia.
- If you run an e-shop, consider telling the payment gateway provider as well.
Note: this is not legal advice. If you suspect a personal-data breach, talk to a lawyer or your data protection officer.
Search engines and reputation
If Google has marked your site as dangerous, request a review in Google Search Console after the restore.
What to avoid
- Deleting everything and starting over without finding the cause.
- Restoring a backup without patches. The attacker walks through the same door.
- Sharing new passwords by email or in chat.
- Telling customers that "nothing happened" when you cannot show that.
After the first 24 hours
The incident does not end with the restore. In the following days:
- watch the logs and unusual activity,
- do a short review: how the attacker got in, what failed, and what you will change,
- put regular updates, backups, and monitoring in place.
A checklist you can print
| Step | Done? |
|---|---|
| One person named to lead the incident | ☐ |
| Site in maintenance mode | ☐ |
| Passwords changed from a clean device | ☐ |
| Copy of files, database, and logs | ☐ |
| Scope known (files, accounts, data) | ☐ |
| Restore from a clean backup | ☐ |
| Patches applied and unused plugins removed | ☐ |
| Keys and secrets changed | ☐ |
| 2FA turned on | ☐ |
| Customers and, if needed, authorities informed | ☐ |
| Review and changes for the future | ☐ |
How we can help
We help with incident analysis, restoring websites and e-shops, and setting up security so it does not happen again. If you are dealing with a problem now, write to us and we will try to help as quickly as we can. If you want to be ready in advance, we can put together a simple incident-response plan with you.