How to respond to a website security incident?

To respond to a website security incident, stay calm and work through a clear sequence: confirm what is happening, contain the damage so it cannot spread, preserve evidence before you change anything, remove the attacker's access and the root cause, restore the site from a known-good state, notify anyone you are required to tell, and then review what went wrong so it does not happen again. Acting in that order prevents the two most common mistakes, which are wiping evidence in a panic and restoring a site that is still vulnerable.

An incident might be a defaced homepage, a spam redirect, a suspicious new admin account, a malware warning in Google, a leaked database, or simply a strange spike in traffic from your server. This article gives you a practical incident response process you can follow under pressure, with commands and checks for WordPress and Linux-hosted sites. It focuses on the process itself; if you need a detailed cleanup walkthrough for a hacked WordPress site, pair this with a dedicated recovery guide.

What Counts as a Website Security Incident?

A security incident is any event that threatens the confidentiality, integrity, or availability of your website or the data it holds. Common examples include:

• Unauthorised access: Unknown admin users, unfamiliar SSH keys, or logins from unexpected locations.
• Malicious code: Injected scripts, spam links, redirects, backdoor files, or crypto-mining code.
• Data exposure: A leaked database, publicly accessible backups, or stolen customer information.
• Defacement: Visible changes to your pages that you did not make.
• Service disruption: Denial-of-service attacks or resource abuse that takes the site offline.
• Account compromise: A hijacked hosting, registrar, DNS, or email account.
• Blacklisting: Browser warnings, search engine flags, or your host suspending the account for abuse.

Not every alert is an incident. A single failed login is normal background noise. A successful login from an account nobody recognises is an incident.

The Incident Response Lifecycle

Most professional frameworks, including NIST's incident handling guidance, describe a similar lifecycle:

1. Preparation: Having backups, logs, contacts, and a plan ready before anything happens.
2. Detection and analysis: Recognising the incident and understanding its scope.
3. Containment: Limiting the damage.
4. Eradication: Removing the attacker's access and the cause.
5. Recovery: Returning to normal operation safely.
6. Post-incident review: Learning and improving.

The steps below follow this lifecycle in a way that fits a typical website.

Step 1: Confirm and Assess the Incident

Before you take drastic action, spend a few minutes establishing what you are dealing with. Write down everything as you go, including times, since you will need it later.

Ask these questions:

• What did you observe? A redirect, a warning email, unfamiliar files, odd behaviour in the admin area?
• When did it start? Check when you first noticed and whether anything changed around that time, such as an update or new plugin.
• What is affected? One page, the whole site, other sites on the same server, the database, email?
• Is it ongoing? Is the attacker still active, for example creating new files or sending spam?
• Is personal data involved? Customer records, form submissions, user accounts, or payment information?

A few quick checks on a WordPress site can help confirm suspicions. From the site's root directory:

# List administrator accounts
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Check core files against official checksums
wp core verify-checksums

# Check plugins from WordPress.org against their checksums
wp plugin verify-checksums --all

# Find PHP files modified in the last 7 days
find . -type f -name "*.php" -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

The -printf option is available in GNU find, which is standard on Linux servers.

Step 2: Assemble Your Response Team

Even on a one-person website, decide who needs to be involved. Depending on the incident, that might include:

• Your developer or agency, who understands how the site is built.
• Your hosting provider's support team, who can see server-level logs and may already know about the issue.
• A security specialist or cleanup service, if the incident is beyond your expertise.
• The business owner or decision-maker, who can approve taking the site offline or notifying customers.
• A legal or data protection adviser, if personal data may have been exposed.

Agree on one person to coordinate and make decisions, and keep a shared timeline document that everyone updates.

Step 3: Contain the Damage

Containment is about stopping the incident from getting worse while keeping as much evidence as possible. Choose actions that fit the severity:

1. Put the site into maintenance mode or take it offline: If visitors are being redirected to malware or data is actively leaking, taking the site offline temporarily is usually the right call. With WP-CLI:

   wp maintenance-mode activate
   

   Some infections can interfere with maintenance mode, so you may need to block traffic at the host, CDN, or firewall level instead.

2. Change critical passwords from a clean device: Start with your hosting control panel, SFTP and SSH, database, registrar, DNS, and email accounts. If your own computer may be compromised, use a different device.

3. Log everyone out of WordPress: Destroy all active sessions and rotate the authentication keys and salts, which invalidates existing login cookies:

   wp user session destroy --all
   wp config shuffle-salts
   

4. Disable suspicious accounts: Rather than deleting unknown admin users straight away, downgrade them to a role with no capabilities or change their passwords, so you keep a record for analysis.

5. Revoke API keys and tokens: Regenerate keys for payment gateways, email services, and other integrations that may have been exposed in configuration files.

6. Isolate other sites: If multiple websites share the same server or hosting account, assume they may also be affected and check them.

Step 4: Preserve Evidence

Before you start deleting files or restoring backups, take a snapshot of the compromised state. This lets you investigate how the attacker got in, supports any legal or insurance claim, and helps you if you need to report a breach.

Create an archive of the site files, a database dump, and copies of the logs, and store them outside the web root:

mkdir -p ~/incident-2026-09-27

# Archive the site files
tar -czf ~/incident-2026-09-27/site-files.tar.gz -C /var/www example.com

# Export the database
wp db export ~/incident-2026-09-27/database.sql --path=/var/www/example.com

# Copy web server logs (paths vary by server)
sudo cp /var/log/nginx/access.log* /var/log/nginx/error.log* ~/incident-2026-09-27/

Adjust paths for your server. On Apache, logs are usually in /var/log/apache2/ on Debian and Ubuntu, or /var/log/httpd/ on RHEL-based systems. On shared hosting, download logs from your control panel. Many hosts keep logs for only a few days, so do this early.

Also take screenshots of anything visible, such as defaced pages, browser warnings, or suspicious admin screens, and note the time.

Treat the evidence archive as sensitive. It contains your database and possibly malware, so do not upload it anywhere public or open infected files on your everyday machine.

Step 5: Investigate the Root Cause

Knowing how the attacker got in is essential. If you clean the site without closing the entry point, you will likely be compromised again.

Common root causes to investigate include:

• A vulnerable plugin or theme: Compare your installed versions against vulnerability databases such as WPScan or Patchstack.
• Stolen or weak credentials: Look for successful logins in your security plugin's logs or the server access logs, especially to wp-login.php or xmlrpc.php.
• A compromised hosting or FTP account: Ask your host for login history for the control panel, SFTP, and SSH.
• Cross-contamination: Another site on the same account may have been the original target.
• Nulled or pirated themes and plugins: These frequently ship with built-in backdoors.

Searching access logs for requests around the time files changed can reveal the attack path:

# Requests that posted data to PHP files, excluding normal admin traffic
grep "POST" access.log | grep "\.php" | grep -v "wp-admin/admin-ajax.php" | tail -n 100

If you cannot identify the cause with confidence, that is a strong reason to bring in a specialist.

Step 6: Eradicate the Threat

Once you understand the scope, remove everything the attacker left behind and fix the weakness they used:

1. Replace core files: Reinstall WordPress core from an official source rather than trying to clean individual files.
2. Reinstall plugins and themes: Download fresh copies from official sources, and remove anything you do not use.
3. Remove malicious files and code: Check the uploads folder, wp-config.php, .htaccess, and must-use plugins for injected code.
4. Clean the database: Look for unknown admin users, injected scripts in posts and options, and suspicious scheduled events.
5. Patch the entry point: Update or remove the vulnerable plugin, close the exposed service, or enforce strong authentication.
6. Rotate all credentials again: Now that the attacker's access is removed, change passwords and keys once more to be sure.

If you have a clean backup from before the compromise, restoring it can be faster than cleaning. Just make sure the backup predates the initial intrusion, not only the visible symptoms, and patch the vulnerability before bringing it online.

Step 7: Recover and Monitor

Bring the site back online carefully:

• Scan the cleaned site with a malware scanner before going live.
• Confirm that all software is updated and hardening is in place.
• Disable maintenance mode and test key pages, forms, and logins.
• If Google or another service flagged your site, request a review once you are confident it is clean. In Google Search Console, this is under Security & Manual Actions > Security Issues.
• Watch logs, file changes, and user accounts closely for the next few weeks. Attackers sometimes return to test whether their access still works.

Step 8: Notify the Right People

Depending on what happened, you may need to tell others:

• Regulators: Under GDPR and UK GDPR, personal data breaches that pose a risk to individuals must be reported to the supervisory authority within 72 hours of becoming aware of them. Other regions have their own laws with different timelines.
• Affected users or customers: If their data was exposed and the risk to them is high, tell them what happened, what data was involved, and what they should do.
• Your payment provider: If card data may have been compromised, contact your acquirer or payment processor immediately.
• Your host: If you have not already, so they can check the wider infrastructure.
• Your insurer: If you have cyber insurance, most policies require prompt notification.

Be honest and specific in your communications. Vague statements tend to cause more concern than clear facts.

Step 9: Run a Post-Incident Review

Within a week or two of recovery, sit down and review the incident while it is still fresh. Keep it blameless and focused on improvement:

1. What happened? Build a timeline from first intrusion to full recovery.
2. How did the attacker get in? Document the root cause.
3. What worked well? Perhaps backups were ready or alerts fired quickly.
4. What slowed you down? Missing logs, unknown passwords, unclear responsibilities?
5. What will you change? Turn each lesson into a concrete action with an owner and a deadline.

Update your security checklist and incident response plan with what you learned.

Preparing Before the Next Incident

The fastest incident responses happen when preparation is already done. Make sure you have:

• An incident response plan: One or two pages listing the steps above and who does what.
• A contact list: Host support, developer, security provider, legal adviser, and payment provider, with phone numbers.
• Reliable backups: Off-site, versioned, and tested, with enough history to go back several weeks.
• Logs with sensible retention: Server logs and WordPress activity logs kept long enough to investigate.
• Credential inventory: A password manager listing every account related to your site.
• Monitoring: Uptime, file change, and security alerts that reach a real person quickly.

---

FAQ: Responding to a Website Security Incident

---

Conclusion

Responding to a website security incident is much easier when you follow a clear order: confirm and assess, contain, preserve evidence, investigate, eradicate, recover, notify, and review. Each step protects you from a specific mistake, whether that is destroying the evidence you need, restoring a site that is still vulnerable, or missing a legal notification deadline.

The best time to prepare is before anything goes wrong. Write a short incident response plan, keep a contact list and credential inventory up to date, make sure your backups and logs are reliable, and practise the process once in a while. When an incident does happen, you will be able to act quickly and confidently instead of improvising under pressure.