Incident Response Plan Template for WordPress Website Owners
A ready-to-use incident response plan template specifically designed for WordPress sites, covering detection, containment, eradication, and recovery phases.
- Every WordPress site needs a documented incident response plan before an incident occurs, not during one.
- The six phases of incident response (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) each have WordPress-specific actions.
- Pre-prepared contact lists, communication templates, and tool inventories dramatically reduce response time during a live incident.
- Regular testing through tabletop exercises ensures your plan works when it matters most.
- Knowing when to call in professional help, and having that partner identified in advance, is a critical part of any plan.
Why Every WordPress Site Needs an Incident Response Plan
A security incident is a matter of when, not if. Even well-maintained WordPress sites can be compromised through zero-day vulnerabilities, supply chain attacks on plugins, or social engineering targeting site administrators. The difference between a minor disruption and a catastrophic breach often comes down to how quickly and effectively you respond.
An incident response plan (IRP) is a documented, tested set of procedures that your team follows when a security incident is detected. Without one, decisions are made under stress, steps are missed, evidence is destroyed, and recovery takes significantly longer. With a well-rehearsed plan, your team can respond systematically, minimise damage, and restore normal operations efficiently.
This template is designed specifically for WordPress website owners and can be adapted to your specific environment. It follows the widely accepted six-phase incident response framework, with WordPress-specific guidance for each phase.
Phase 1: Preparation
Preparation is everything you do before an incident occurs. This phase determines how effective your response will be when the pressure is on.
Essential Contacts List
Create and maintain a contacts document that is accessible offline (printed copies and stored on mobile devices, not only on the WordPress site itself). Include:
- Internal incident lead: The person responsible for coordinating the response. Include name, mobile number, and personal email.
- Backup incident lead: A secondary contact in case the primary is unavailable.
- Hosting provider: Emergency support contact, account number, and escalation path.
- Domain registrar: Support contact and account details for DNS changes if needed.
- WordPress security partner: If you have a security retainer, include the emergency contact number and your account reference.
- Legal counsel: Data protection solicitor for GDPR breach notification advice.
- ICO breach reporting: The ICO's breach reporting page and helpline number (0303 123 1113).
- Cyber insurance provider: Claims line and policy number.
- Key stakeholders: Business owner, marketing lead, and anyone who needs to be informed during an incident.
Tools and Resources Inventory
Document the tools available for incident response and ensure the team knows how to use them:
- File integrity monitoring: Your chosen tool and how to access its dashboard or reports.
- Server access: SSH credentials, hosting control panel URLs, and database access methods.
- Backup access: Location of backups, restoration procedure, and credentials for backup storage.
- Malware scanning tools: Both automated scanner access and manual inspection procedures.
- Web application firewall: WAF dashboard access for emergency rule changes and IP blocking.
- DNS management: Access to DNS controls for emergency changes such as pointing to a maintenance page.
- Pre-prepared maintenance page: A static HTML maintenance page ready to deploy, stored outside the WordPress installation.
Documentation and Procedures
Maintain current documentation of your WordPress environment:
- Complete list of installed plugins and themes with version numbers.
- Server configuration details (PHP version, web server, database version).
- Network diagram showing hosting architecture, CDN, and any connected services.
- List of all user accounts with their roles and last known login dates.
- Data processing inventory identifying what personal data is collected and where it is stored.
- A copy of this incident response plan, stored in at least two locations independent of the WordPress site.
Phase 2: Identification
Identification is the process of detecting that a security incident has occurred, assessing its severity, and determining its scope. Speed of detection directly impacts the severity of the outcome.
Signs of Compromise on WordPress Sites
Train your team to recognise these common indicators of a WordPress compromise:
- Unexpected redirects: The site redirects visitors to unfamiliar domains, particularly on mobile devices or when arriving from search engines.
- Unknown admin accounts: New user accounts with administrator privileges that nobody created.
- Modified core files: WordPress core files (wp-includes, wp-admin) have been altered from their original state.
- Suspicious files: Unknown PHP files in the uploads directory, themes folder, or root directory, often with obfuscated names.
- Injected content: Hidden links, spam content, or pharmaceutical keywords appearing in page source code.
- Performance degradation: Sudden, unexplained slowness caused by malicious scripts consuming server resources.
- Email blacklisting: Your domain is suddenly unable to send email due to spam originating from the compromised server.
- Google Search Console warnings: Security issues flagged in Google Search Console, or your site displaying Safe Browsing warnings.
- Unexpected database changes: Modified options, injected content in posts, or altered user records.
- Unusual server logs: Repeated requests to suspicious file paths, unusual POST requests, or access from unexpected IP ranges.
Monitoring and Alerting Setup
Proactive monitoring reduces detection time from weeks to minutes. As part of your preparation, ensure you have:
- File integrity monitoring with automated alerting on any changes to core files, plugins, or themes outside of planned updates.
- Uptime monitoring that alerts immediately when the site becomes unavailable.
- Login monitoring that alerts on failed login attempts exceeding a threshold and successful logins from unusual locations.
- Google Search Console email alerts enabled for security issues.
- Server log monitoring with alerting on suspicious patterns.
A regular WordPress security audit helps identify gaps in your monitoring coverage and ensures your detection capabilities remain effective.
Severity Classification
When an incident is detected, classify its severity to determine the appropriate response level:
- Critical: Active data exfiltration, site serving malware to visitors, ransomware, or complete loss of site control. Requires immediate all-hands response.
- High: Confirmed compromise with no evidence of active data theft, such as defacement or spam injection. Requires same-day response.
- Medium: Vulnerability discovered that could lead to compromise but no evidence of exploitation. Requires response within 24 to 48 hours.
- Low: Minor security misconfiguration or informational finding. Requires response within the normal maintenance cycle.
Phase 3: Containment
Once an incident is confirmed, the immediate priority is to contain the damage and prevent the attack from spreading or worsening. Act quickly but methodically.
Immediate Containment Actions
- Preserve evidence: Before making any changes, create a complete backup of the compromised site including files and database. This forensic copy is essential for understanding the attack vector and may be needed for ICO reporting or insurance claims.
- Enable maintenance mode: Deploy your pre-prepared static maintenance page to prevent visitors from encountering compromised content. This also stops the attacker from continuing to exploit the site through the web interface.
- Revoke all sessions: Force logout of all WordPress users by regenerating the WordPress security salts in wp-config.php.
- Reset all passwords: Change passwords for every WordPress admin account, hosting control panel, FTP/SFTP access, database user, and any connected service accounts.
- Block known attacker IPs: If your logs reveal specific IP addresses used by the attacker, block them at the firewall or WAF level immediately.
- Disable compromised plugins or themes: If the attack vector is identified as a specific plugin or theme vulnerability, deactivate it immediately. Rename the plugin directory via SFTP if you cannot access the admin panel.
- Revoke API keys and tokens: If any API keys, OAuth tokens, or service credentials may have been exposed, revoke and regenerate them.
Communication During Containment
While technical containment is underway, initiate the communication chain:
- Notify internal stakeholders using the contacts list from your preparation phase.
- Contact your security partner if you have a retainer arrangement in place.
- Notify your hosting provider, who may need to take action at the server level.
- Begin the 72-hour GDPR notification clock assessment: determine whether personal data has been or may have been compromised.
Phase 4: Eradication
Containment stops the bleeding. Eradication removes the threat completely. This is the most technically demanding phase and where incomplete work leads to reinfection.
WordPress-Specific Eradication Steps
- Identify the attack vector: Determine exactly how the attacker gained access. Was it a plugin vulnerability, a weak password, a compromised hosting account, or something else? Without understanding the entry point, you cannot prevent re-entry.
- Scan all files: Use malware scanning tools to identify all malicious files, including backdoors that may be dormant. Manual inspection of recently modified files is also essential, as automated scanners do not catch everything.
- Replace WordPress core: Download a fresh copy of WordPress from wordpress.org and replace all core files. Do not simply overwrite; compare and replace to ensure no modified files remain.
- Clean or replace plugins and themes: For each plugin and theme, either replace with a fresh copy from the official repository or remove entirely if no longer needed. Pay particular attention to the uploads directory, which should not contain PHP files.
- Clean the database: Search for injected content in the wp_posts, wp_options, and wp_comments tables. Look for base64-encoded strings, eval() calls, and unfamiliar JavaScript in post content and widget areas.
- Review user accounts: Delete any unknown user accounts. Reset passwords for all remaining accounts. Verify that no administrator accounts exist that should not.
- Check cron jobs: Review WordPress cron events (wp_cron) and server-level cron jobs for any malicious scheduled tasks.
- Inspect wp-config.php: Verify that wp-config.php has not been modified with malicious code. Regenerate all security salts and keys.
- Review .htaccess: Check for malicious redirect rules or access control modifications in .htaccess files throughout the installation.
If the eradication process reveals complexity beyond your team's capability, this is the point to engage professional hacked website recovery services. Incomplete eradication is worse than no eradication, as it gives a false sense of security while the attacker retains access.
Phase 5: Recovery
Recovery is the process of safely restoring normal operations after the threat has been eliminated. This must be done carefully to avoid reintroducing the vulnerability or exposing the site before it is fully secured.
Recovery Checklist
- Update everything: Before bringing the site back online, ensure WordPress core, all plugins, and all themes are updated to their latest versions.
- Implement hardening measures: Apply security hardening that should have been in place before the incident. This includes two-factor authentication, file permissions review, disabling file editing through the admin panel, and limiting login attempts.
- Restore from clean state: If eradication confidence is not high, consider rebuilding from a known-clean backup taken before the compromise, then applying updates and hardening before bringing the site live.
- Test thoroughly: Before removing the maintenance page, test all site functionality including forms, e-commerce processes, user registration, and any integrations with external services.
- Remove maintenance mode: Bring the site back online and monitor closely for the first 24 to 48 hours for any signs of reinfection or residual issues.
- Request review from Google: If Google flagged the site with Safe Browsing warnings, submit a review request through Google Search Console once the site is confirmed clean.
- Notify stakeholders: Inform internal stakeholders, and where appropriate customers, that the site has been restored and secured.
- Complete GDPR notifications: If personal data was compromised, ensure ICO notification has been submitted within the 72-hour window and individual notifications have been sent where required.
Phase 6: Lessons Learned
The final phase is often skipped under the pressure to return to business as usual, but it is one of the most valuable. A structured post-incident review prevents the same or similar incidents from recurring.
Post-Incident Review Process
Within one to two weeks of recovery, conduct a formal review meeting with all involved parties. Document the following:
- Incident timeline: A detailed chronology from initial compromise (if known) through detection, containment, eradication, and recovery. Include timestamps for each significant event and decision.
- Root cause analysis: What was the specific vulnerability or failure that allowed the incident to occur? Was it a technical weakness, a process failure, or a human error?
- Detection effectiveness: How was the incident detected? How long was the attacker present before detection? Could it have been detected earlier?
- Response effectiveness: What went well in the response? What was slow, confusing, or ineffective? Were the documented procedures followed, and were they adequate?
- Impact assessment: Document the full business impact including downtime duration, data exposure scope, financial cost, and any regulatory actions taken.
- Improvement actions: Specific, assigned actions to prevent recurrence and improve response capability. Each action should have an owner and a deadline.
Updating Your Plan
Based on the lessons learned, update your incident response plan to address any gaps identified. Common updates include:
- Adding new monitoring alerts to detect the type of compromise that occurred.
- Updating the contacts list with new or changed contacts identified during the incident.
- Revising procedures that proved inadequate or unclear during the response.
- Adding new tools to the inventory based on needs identified during the incident.
- Implementing additional security measures recommended by your security audit provider.
Communication Templates
Having pre-drafted communication templates significantly reduces response time during an incident. Prepare templates for the following scenarios and store them with your incident response plan:
Customer Notification Template
A notification to customers should include: a clear description of what happened in plain language, what data may have been affected, what steps you have taken to resolve the issue, what steps the customer should take to protect themselves (such as changing passwords), and contact details for further questions. Keep the tone factual, empathetic, and action-oriented. Avoid technical jargon and do not minimise the incident.
ICO Notification Template
The ICO provides a standard breach notification form on their website. Pre-familiarise yourself with the required fields and prepare as much standing information as possible in advance, including your organisation details, Data Protection Officer contact information, and standard descriptions of your data processing activities. During an incident, you will only need to add the incident-specific details.
Internal Stakeholder Update Template
Create a template for regular updates to internal stakeholders during an incident. Include: current status, actions taken since last update, immediate next steps, estimated time to resolution, and any decisions required from leadership. Issue updates at consistent intervals (every two to four hours for critical incidents) to maintain confidence in the response process.
Testing Your Incident Response Plan
An untested plan is little better than no plan at all. Regular testing validates that your procedures work, your team knows their roles, and your tools are accessible and functional.
Tabletop Exercises
A tabletop exercise is a discussion-based walkthrough of a hypothetical scenario. Gather your response team around a table (or video call) and work through a scenario such as:
- A customer reports that your site is redirecting to a phishing page.
- Google Search Console alerts you to a malware detection on your site.
- Your hosting provider notifies you that your site is sending spam emails.
- A security researcher contacts you about a vulnerability in a plugin you use.
Walk through each phase of the plan, discussing what each team member would do, what tools they would use, and what decisions need to be made. Note any gaps, confusion, or disagreements for resolution.
Simulated Incidents
For a more rigorous test, simulate an actual incident in a staging environment. Create a deliberate compromise (with appropriate safeguards) and run through the full response process. This tests not just procedures but the technical capability to execute them under pressure.
When to Call in Professional Help
Not every incident requires external assistance, but recognising when you need help is a critical skill. Engage professional incident response specialists when:
- The attack vector is unknown, and you cannot determine how the attacker gained access.
- Personal data may have been exfiltrated, triggering GDPR notification requirements.
- The compromise involves sophisticated persistence mechanisms (rootkits, hidden backdoors in the database).
- Your internal team lacks the specialist skills or tools needed for thorough forensic analysis.
- The site has been reinfected after a previous cleanup attempt.
- The incident involves potential legal or regulatory consequences.
- Business impact is severe and rapid professional recovery is worth the investment.
Ideally, your professional security partner should be identified and engaged before an incident occurs, through a security retainer that includes incident response hours. Searching for a reputable provider during an active incident wastes critical time and may lead to poor procurement decisions under pressure. Having a malware removal specialist on retainer means help is a single phone call away when every minute counts.
Frequently Asked Questions
How often should I test my WordPress incident response plan?
You should conduct a tabletop exercise at least twice per year and a full simulated incident test at least once per year. Additionally, review and update the plan whenever significant changes occur to your WordPress environment, such as migrating hosting providers, adding major new plugins or integrations, or changing your development team. Plans that are not regularly tested become outdated and ineffective when a real incident occurs.
What is the first thing I should do if I suspect my WordPress site has been hacked?
The first step is to confirm whether a compromise has actually occurred, without alerting the attacker or destroying evidence. Check your file integrity monitoring alerts, review recent server logs, and look for signs such as unknown admin accounts, modified core files, or unexpected database changes. Do not immediately delete suspicious files or restore from backup, as this can destroy forensic evidence needed to understand the attack vector and prevent reinfection. Once confirmed, move immediately to containment by enabling maintenance mode and revoking compromised credentials.
Should I take my WordPress site offline during an incident?
In most cases, yes. Placing the site behind a maintenance page or restricting access to known safe IP addresses prevents further damage to visitors, stops the attacker from continuing to exploit the site, and prevents search engines from indexing compromised content. The temporary loss of availability is almost always preferable to continued exposure of visitors to malware, phishing content, or data theft. Your incident response plan should include pre-prepared maintenance page files that can be deployed quickly.
Do I need a professional incident response team, or can I handle it myself?
For minor incidents such as a single defaced page with no data access, a technically capable site owner may be able to handle cleanup independently using documented procedures. However, for any incident involving potential data exposure, persistent backdoors, or unknown attack vectors, professional incident response is strongly recommended. Incomplete cleanup is the primary cause of reinfection, and forensic analysis requires specialist tools and experience. Having a professional partner identified in advance as part of your incident response plan ensures you can engage help immediately rather than searching during a crisis.
What information should I collect during a WordPress security incident?
Collect and preserve all available evidence before making changes. This includes complete server access logs, web application firewall logs, file modification timestamps, database change logs, screenshots of any visible compromise, email headers if the incident involved phishing, the complete list of WordPress users and their last login times, and a full backup of the compromised site including both files and database. Store this evidence securely and with documented chain of custody, as it may be needed for ICO reporting, insurance claims, or law enforcement.
Need Help With WordPress Security?
Get a professional security audit or speak to our team about protecting your WordPress site.
Request a Security Review