Finding out your website has been compromised is one of the worst feelings you can have as a site owner. Your stomach drops, your mind races, and you have no idea where to start. I have been there myself, and I can tell you that the first few hours after discovering a breach are absolutely critical. What you do next will determine whether you recover quickly or end up dealing with the fallout for months.
This guide walks you through the exact steps you need to take after a security breach, from the immediate damage control right through to long-term prevention. Whether you run a small business site or manage multiple web properties, these steps apply to you.
Take a Deep Breath and Assess the Damage
Before you start deleting files or changing passwords in a panic, stop and figure out what actually happened. You need to understand the scope of the breach before you can fix it properly.
Start by checking your server access logs. Look for unusual login attempts, unfamiliar IP addresses, or requests to files that should not be getting traffic. If you are running WordPress, check for recently modified files, especially in the wp-content/uploads directory, since attackers love hiding malicious scripts there disguised as image files.
A few years back, I was managing a client site that got hit through an outdated contact form plugin. The attacker had uploaded a PHP shell to the uploads folder and was using it to send spam. The site looked perfectly normal from the front end. We only caught it because the hosting provider flagged unusual outbound email activity. That experience taught me that breaches are not always obvious, and sometimes the damage is happening quietly in the background.
Check whether any customer data was accessed. Look at database logs if you have them. Review file modification timestamps. Document everything you find, because you will need this information later.
Contain the Breach Immediately
Once you have a rough picture of what happened, your priority is stopping the bleeding. Take these steps as fast as possible.
Take the site offline temporarily. Yes, this hurts, but it prevents further damage to your visitors and your reputation. A simple maintenance page is better than serving malware to your customers.
Change every password. I mean every single one. Your hosting control panel, FTP accounts, database passwords, CMS admin accounts, and any API keys connected to the site. Do not reuse old passwords. Use a password manager to generate strong, unique credentials for each one.
Revoke all active sessions. Force every logged-in user to re-authenticate. If the attacker has an active session cookie, this kills their access immediately.
Contact your hosting provider. Let them know what happened. They can often help identify the entry point from their side and may have backups or logs you do not have access to.
Clean Up and Restore
Now comes the tedious part. You need to remove everything the attacker left behind, and you have to be thorough about it.
If you have a clean backup from before the breach, restoring from that backup is usually the safest route. But do not just restore and call it a day. Whatever vulnerability the attacker exploited is still in that backup, so you need to patch it before going live again.
If you do not have a clean backup, you will need to manually clean the compromised files. Look for obfuscated PHP code, base64-encoded strings in places they should not be, new user accounts you did not create, and modified core files. On WordPress sites, compare your core files against fresh copies from wordpress.org. Any difference is suspicious.
Check your database too. Attackers sometimes inject malicious JavaScript into stored content, creating persistent XSS attacks that survive file-level cleanups.
Patch the Vulnerability That Got You Hacked
This is where many people make a critical mistake. They clean up the mess but never figure out how the attacker got in. If you skip this step, you will get breached again, probably within days.
Common entry points include outdated plugins and themes, weak admin passwords, exposed configuration files, unpatched server software, and insecure file permissions. Go through each one systematically.
Update everything. Your CMS, every plugin, every theme, your PHP version, your server operating system packages. Remove any plugin or theme you are not actively using. Each one is an attack surface you do not need.
Review your file permissions. On a Linux server, your web files should generally be owned by the correct user, and directories should be set to 755 while files should be 644. The wp-config.php file should be 600 or 640. Overly permissive settings are an open invitation.
Strengthen Your Defenses Going Forward
Recovery is only half the job. You need to make sure this does not happen again.
Set up automated security scanning. Manual checks are fine, but they are not realistic on a daily basis. Tools like ScanVigil can run over 150 security tests on your site every day, catching vulnerabilities before attackers find them. It covers everything from SQL injection and XSS testing to WordPress-specific checks and SSL analysis. Having something like this running in the background means you are not relying on luck or memory to keep your site safe.
Enable two-factor authentication on every admin account. This single step blocks the vast majority of brute-force and credential-stuffing attacks.
Implement a web application firewall. A WAF filters malicious traffic before it reaches your site. It will not catch everything, but it raises the bar significantly for attackers.
Set up regular automated backups. Store them off-site, not on the same server as your website. Test your backups periodically by actually restoring them. A backup you have never tested is a backup you cannot trust.
Monitor your SSL/TLS configuration. An expired or misconfigured certificate erodes trust and can expose data in transit.
Communicate Honestly With Your Users
If user data was potentially exposed, you have a legal and ethical obligation to notify affected individuals. Under GDPR, you have 72 hours to report certain breaches to authorities.
Be transparent. Explain what happened, what data may have been affected, what steps you have taken, and what users should do on their end, like changing their passwords. People are far more forgiving of an honest disclosure than they are of finding out you tried to sweep it under the rug.
Common Questions After a Breach
How do I know if my site is still compromised? Run a thorough security scan after cleanup. If you cleaned manually, scan multiple times over the following week. Attackers often leave multiple backdoors, and missing even one means they can come right back.
Should I rebuild the site from scratch? If the breach was severe and your codebase is heavily customized, a rebuild might actually be faster and safer than trying to clean everything. For standard CMS sites, a clean backup restore plus patching is usually sufficient.
How long does recovery take? For a straightforward breach on a small site, you can be back online within a day. Complex breaches with data exposure can take weeks when you factor in forensics, legal obligations, and communication.
Can I prevent all future breaches? No security is absolute. But you can make your site a much harder target. Automated daily scanning, prompt updates, strong authentication, and good backups will protect you against the vast majority of attacks. Most attackers go after easy targets, so even basic hardening makes a real difference.
The bottom line is this: a breach does not have to be the end of the world. Handle it methodically, learn from it, and put proper monitoring in place so you catch problems early. The sites that stay secure long-term are not the ones that never get attacked. They are the ones that detect and respond fast.