My website has been hacked: what to do in the first 24 hours

How to tell if your site has actually been hacked

Not every strange thing that happens to a website is a hack. A broken plugin update, a caching glitch, or a misconfigured redirect can all produce symptoms that look alarming without any malicious involvement. Before you panic, take a moment to assess what is actually happening.

The clearest signs of a genuine compromise are: visitors being redirected to unrelated sites (particularly spam, gambling, or adult content sites) without any legitimate explanation; browser warnings from Chrome, Firefox, or Safari telling visitors your site may be dangerous; your hosting provider sending you a security notification or suspending your account; Google Search Console flagging your site as containing malware or hacked content; or unexpected administrator accounts appearing in your CMS that you did not create.

There are subtler signs worth checking as well. Log into Google Search Console and look at the Coverage and Security Issues sections. A sudden spike in indexed pages, particularly pages with unusual titles or content you do not recognise, is a strong indicator of SEO spam injection — a common attack that adds hidden pages to your site to redirect search engine traffic. Similarly, if your page load times have become dramatically slower without any obvious cause, it may be because your server is being used to run malicious processes or send spam email.

If you are running WordPress, check Users → All Users for accounts you do not recognise, and check Plugins → Installed Plugins for anything unfamiliar. Attackers often install backdoor plugins to maintain access after the initial breach is cleaned up. You can also visit your site through Google's Safe Browsing checker to see if it has been flagged.

The first thirty minutes: immediate triage steps

Once you have confirmed something is wrong, your first job is to stop the bleeding. This means two things: containing the damage, and preserving the evidence you will need for cleanup and, potentially, for regulatory reporting.

Decide whether to take the site offline

If your site is actively redirecting visitors to harmful content, exposing customer data, or running code that could harm users, taking it offline is the right call. Most hosting control panels have a way to put the site in maintenance mode, or your host can help you do this. A temporary outage is far less damaging to your business than continuing to serve malicious content to customers.

If the compromise is more subtle — injected content that is not immediately visible to visitors, for example — you may be able to leave the site up while you investigate. Use your judgment, but err on the side of caution if customer data is involved.

Change all passwords immediately

Change the passwords for every account that could give access to your site: your CMS admin account, your hosting control panel, your FTP or SFTP credentials, and your database password if you manage it directly. Do this before you do anything else, because any investigation you conduct is pointless if the attacker still has a working login. Use unique, strong passwords for each account — a password manager makes this manageable.

Also change the password for the email account associated with your domain and hosting, since attackers who control that address can reset every other password.

Preserve evidence before cleaning

This step is easy to forget in the rush to fix things, but it matters. Before you restore from backup or delete anything, take screenshots of what you are seeing. Download your server access logs from your hosting control panel (look for “Raw Access Logs” or similar in cPanel). Note the date and time you discovered the issue. If your host sends you a security notification, keep a copy.

This documentation is useful for understanding how the breach happened, and it may be required if you end up needing to notify affected individuals or file a report with a regulatory body.

Contact your hosting provider

Your host has seen this before and has tools you do not. Most Canadian hosting providers have a security or abuse team that can scan your server, identify malicious files, and advise on next steps. If your host suspends your account due to a security issue, their suspension notification will usually include instructions for how to begin the remediation process. Follow them.

Your breach notification obligations under Canadian law

If personal information about your customers or employees was involved in the breach — names, email addresses, payment details, health information, or any other data that could identify an individual — you may have legal obligations under Canada's private sector privacy law. This is an area where taking it seriously from the start is far less painful than ignoring it and dealing with the consequences later.

PIPEDA and mandatory breach reporting

The Personal Information Protection and Electronic Documents Act (PIPEDA), which applies to most private-sector organizations operating in Canada, requires you to report certain data breaches to the Office of the Privacy Commissioner of Canada (OPC) and to notify affected individuals. This obligation applies to breaches that involve a “real risk of significant harm” to individuals.

The phrase “real risk of significant harm” is the key threshold. Significant harm includes bodily harm, humiliation, financial loss, identity theft, negative effects on credit, and loss of employment or business opportunities. The OPC considers the sensitivity of the information and the probability that it will be misused. If breached data includes something like payment card numbers, SIN numbers, medical information, or account passwords, the bar is almost certainly met. If the breach involved only encrypted email addresses and no evidence of misuse, the analysis is more nuanced.

What you need to do

Under PIPEDA breach regulations, you must maintain a record of every security breach involving personal information, regardless of whether the breach meets the reporting threshold. This record must be kept for 24 months and made available to the OPC on request.

If the breach does meet the threshold, you must notify the OPC “as soon as feasible” after you have determined that the breach has occurred. There is no fixed number of days specified in the legislation, but “as soon as feasible” is interpreted to mean promptly after you have enough information to make the required report. Sitting on the information for weeks is not compliant. You must also notify affected individuals directly — in plain language, explaining what happened, what information was involved, and what steps you are taking.

Quebec businesses should also be aware that Quebec's Law 25 (Act Respecting the Protection of Personal Information in the Private Sector) has its own breach notification requirements that are stricter than PIPEDA in some respects, including a 72-hour notification window to the Commission d’accès à l’information for incidents presenting a risk of serious injury.

If you are unsure whether your breach triggers reporting obligations, consult a lawyer with privacy law experience. The cost of a short consultation is far less than the cost of a compliance failure.

Clean up or rebuild from scratch?

Once the immediate crisis is contained, you face a decision: attempt to clean and repair the compromised site, or wipe it entirely and rebuild from a known-good backup. Both approaches have merit depending on your situation.

When cleaning makes sense

Cleaning a compromised site involves identifying and removing all malicious files, closing the vulnerability that was exploited, and verifying that no backdoors remain. This approach is faster than a full rebuild and preserves any configuration work you or a developer have done that is not captured in a backup.

Cleaning is most viable when you can identify exactly how the breach occurred, when the scope of the compromise is limited and clearly defined, and when you have or can hire someone with the technical skill to be thorough. A partial cleanup — removing the visible symptoms without finding every backdoor — often results in re-infection within days or weeks.

When rebuilding is the right call

Rebuilding from a clean backup is often the more reliable choice, even if it takes longer. If you have a verified clean backup from before the compromise, restoring it and then applying all the hardening measures in the next section gives you a site you can trust. You know exactly what is on it because you put it there.

Rebuilding is the right call when the compromise was extensive, when you cannot determine when it began (meaning all your recent backups may be infected), when the site is running significantly outdated software that needs a proper upgrade anyway, or when you simply do not have the expertise to be confident a cleanup was thorough. A site that looks clean but still has a backdoor is worse than a site that is temporarily offline while you rebuild properly.

Hardening your site after recovery

Recovery is not complete when the malicious content is gone. It is complete when you have closed the vulnerability that was exploited and added the layers of protection that will make the next attempt significantly harder. This is the part most people are tempted to skip because the immediate crisis is over — but skipping it almost guarantees a repeat incident.

Passwords and two-factor authentication

If you changed passwords in the triage phase but did not enable two-factor authentication, do it now. Every administrator account on your CMS, your hosting control panel, and the email account associated with your domain should have 2FA active. This single measure eliminates most credential-based attacks. For WordPress, plugins like WP 2FA handle this in a few minutes. Your hosting provider likely supports 2FA for cPanel or their own dashboard — check under security settings.

Plugin and theme audit

Go through every plugin and theme on your site. Delete anything you do not recognise, anything that is no longer being maintained by its developer, and anything you installed for a purpose that no longer applies. Check the remaining plugins against vulnerability databases like WPScan or Patchstack to confirm none have known unpatched issues. Update everything to the latest version.

File permissions

Incorrect file permissions on a web server can allow uploaded files to execute as code, which is a common attack vector. Directories should generally be set to 755 and files to 644 on a standard Linux server. Your hosting provider or a developer can verify these settings for you. In WordPress specifically, the wp-config.php file should be set to 600 (owner read/write only) since it contains your database credentials.

Web application firewall

A web application firewall (WAF) sits in front of your site and blocks known malicious request patterns before they reach your server. For WordPress, Wordfence includes a WAF in its free tier. Cloudflare's free plan includes basic WAF functionality and has the added benefit of masking your server's real IP address, which makes certain types of targeted attacks harder to execute.

Preventing it from happening again

The uncomfortable truth about website security is that most successful attacks exploit things site owners knew they should have fixed but did not get around to. Outdated software, reused passwords, no backups, no monitoring — these are not exotic oversights. They are the normal state of a site that has been running for a few years with no dedicated technical oversight.

Prevention is not glamorous. It is a recurring list of tasks: apply updates when they come out, not when you get around to it; verify that backups are actually running and actually restorable; check Google Search Console periodically for warnings; use strong unique passwords everywhere. None of this requires technical expertise. It requires the discipline to treat your website as the business asset it is rather than a brochure you set up once and forgot about.

If you do not have the time or inclination to manage this yourself, there are professionals and managed hosting providers who will do it for you. The cost of a monthly maintenance agreement is a fraction of the cost of a breach response — the labour, the potential regulatory fines, the customer notifications, and the reputational damage. Treating security as an ongoing operating cost rather than a one-time project is the right frame.

The good news is that Canadian small business websites are rarely targeted individually. You are far more likely to be swept up in an automated campaign exploiting a known vulnerability than to be specifically attacked. That means the defences that work are consistent and well-understood — and applying them puts you in a different category from the majority of sites that get compromised.