WordPress Incident Response: How to Build a Security Playbook

Introduction: Every WordPress Site Needs an Incident Response Plan

When a WordPress site is compromised, the first few minutes determine the outcome. Sites with a structured incident response plan can contain and remediate a breach within hours. Sites without one often spend days or weeks in a state of partial compromise, unclear about what happened, what data was affected, and whether the attacker still has access.

An incident response (IR) plan is not just for enterprises with dedicated security teams. Any WordPress site that handles user data, processes transactions, publishes content that others rely on, or represents a business needs a documented process for detecting, containing, eradicating, and recovering from security incidents. The alternative — improvising under pressure after a breach — consistently leads to worse outcomes: longer downtime, greater data loss, regulatory penalties, and reputational damage.

This guide walks through the complete incident response lifecycle for WordPress, explains how to build playbooks for common attack scenarios, and shows how VistoShield’s Incident Response plugin automates critical steps with five pre-built playbooks that execute containment and recovery procedures in seconds rather than hours.

The Six Phases of Incident Response

The NIST Computer Security Incident Handling Guide (SP 800-61) defines a framework that has become the industry standard for incident response. Adapted for WordPress, the six phases are:

Phase 1: Preparation

Preparation is everything you do before an incident occurs. This is the most important phase because it determines how effectively you can execute the remaining five phases under the stress and time pressure of an actual breach.

Preparation for WordPress incident response includes:

• Documentation: A written incident response plan that defines roles, communication channels, decision authorities, and escalation procedures. For a solo site owner, this can be a single page. For an agency managing multiple sites, it needs to be more detailed.
• Tools: Security plugins installed, configured, and tested before they are needed. This includes activity logging (for forensics), file integrity monitoring (for detection), backup systems (for recovery), and the incident response plugin itself (for automated containment).
• Backups: Verified, tested backups stored offsite. A backup that has never been tested is not a backup — it is a hope. Regularly test restoration to confirm that backups are complete and functional.
• Access credentials: Secure, documented access to hosting control panel, database, DNS management, CDN, domain registrar, and any third-party services. During an incident, searching for login credentials wastes critical time.
• Contact list: Hosting provider emergency support, domain registrar, CDN provider, and (for sites handling regulated data) legal counsel and regulatory notification contacts.

Phase 2: Identification

Identification is the process of detecting that an incident has occurred and determining its scope and nature. The faster you identify an incident, the less damage it causes.

WordPress incidents are typically identified through:

• Automated alerts: Security plugin notifications (malware detected, unauthorized file changes, suspicious login activity, WAF blocks exceeding thresholds)
• External reports: Google Safe Browsing warnings, hosting provider notifications, customer complaints, search engine ranking drops
• Manual discovery: Visible defacement, unexpected redirects, unknown admin users, spam content injection
• Performance anomalies: Sudden traffic spikes (DDoS or bot activity), increased server resource usage (cryptocurrency mining), slow page loads (injected scripts)

VistoShield’s Activity Log and Security Scanner provide the detection layer. The Incident Response plugin acts on their alerts, automatically initiating the appropriate playbook when specific trigger conditions are met. For a comprehensive look at detection through logging, see our security audit guide.

Phase 3: Containment

Once an incident is identified, the immediate priority is containment: stopping the attack from causing further damage while preserving evidence for forensic analysis. Containment is the phase where automated playbooks provide the greatest value, because speed is critical and manual execution is error-prone under stress.

WordPress containment actions include:

• Short-term containment: Block the attacker’s IP address, disable compromised user accounts, enable maintenance mode to prevent public access, revoke active sessions for compromised accounts
• Evidence preservation: Take a full backup of the compromised site (including the malware — this is forensic evidence), export activity logs, capture server access logs, document the current state before making changes
• Long-term containment: Reset all user passwords, regenerate WordPress salts and security keys, rotate database credentials, disable file editing via wp-config.php

Critical rule: Never skip evidence preservation. The instinct is to immediately start cleaning, but without a forensic copy of the compromised site, you cannot determine the attack vector, verify the full scope of the compromise, or prove to regulators what data was accessed.

Phase 4: Eradication

Eradication removes the attacker’s presence from the site entirely. This goes beyond removing visible malware — it requires finding and eliminating all backdoors, unauthorized accounts, and persistence mechanisms.

WordPress eradication steps include:

• Malware removal: Scan all files with the Security Scanner and remove all identified malicious code. Check core files against WordPress.org checksums. Check plugin and theme files against their repository versions.
• Backdoor hunting: Search for common WordPress backdoor patterns: files with eval(base64_decode(...)), files in upload directories with PHP extensions, modified .htaccess files, rogue cron jobs in wp_options, unknown mu-plugins. See our malware scanning guide for detailed techniques.
• User audit: Review all user accounts, especially administrators. Delete any unauthorized accounts. Reset passwords for all remaining accounts.
• Plugin and theme audit: Remove any plugins or themes that were not intentionally installed. Update all remaining plugins and themes to their latest versions.
• Database cleanup: Check for injected content in posts, pages, comments, and options. Remove any unauthorized scheduled events (cron jobs).

Phase 5: Recovery

Recovery restores the site to full operation with confidence that the compromise has been fully eradicated and protections are in place to prevent recurrence.

WordPress recovery steps include:

• Restore from clean backup or verified clean state: If eradication was performed on the live site, verify the result with a full scan. If the compromise was extensive, consider restoring from the most recent pre-compromise backup and re-applying legitimate changes.
• Harden the attack vector: Identify how the attacker gained access and implement specific protections. If the vector was a plugin vulnerability, update or replace the plugin. If it was a weak password, enforce stronger password policies (see our brute force protection guide). If it was an exposed REST API endpoint, lock down the API.
• Gradual restoration: Remove maintenance mode, monitor closely for 24–72 hours for any signs of re-compromise, verify all site functionality, and confirm that search engine warnings (if any) have been cleared.
• Communication: Notify affected users if personal data was accessed, update stakeholders on the resolution, and submit reconsideration requests to Google if the site was flagged.

Phase 6: Lessons Learned

The lessons learned phase is consistently the most neglected and potentially the most valuable. After the pressure of the incident has passed, conduct a post-incident review:

• Timeline reconstruction: Build a complete timeline of the incident from initial compromise to full recovery. When was the site first compromised? When was it detected? How long was the gap?
• Root cause analysis: What was the specific vulnerability or weakness that allowed the compromise? Was it a known vulnerability? Was a patch available?
• Response evaluation: What worked well in the response? What took too long? What information was missing? Were the right tools available?
• Improvement actions: What specific changes will prevent this type of incident from recurring? What changes will improve detection speed? What changes will improve response effectiveness?
• Documentation: Write up the incident report and update the incident response plan based on findings.

Building Playbooks for Common WordPress Scenarios

A playbook is a structured, step-by-step procedure for responding to a specific type of incident. Pre-written playbooks eliminate decision paralysis during an incident and ensure that critical steps are not missed.

Playbook 1: Malware Infection

Trigger: Security scanner detects malicious files, hosting provider reports malware, Google Safe Browsing flags the site.

Automated containment steps (VistoShield executes in seconds):

1. Enable maintenance mode with a custom “under maintenance” page
2. Create a full forensic backup of the compromised state
3. Disable the WordPress file editor (DISALLOW_FILE_EDIT)
4. Block outbound connections from PHP (prevent data exfiltration)
5. Send alert notification to all site administrators

Manual follow-up steps:

1. Run a full malware scan and remove all identified malicious files
2. Check all core files against WordPress.org checksums
3. Review and clean the database (posts, options, cron jobs)
4. Update all plugins, themes, and WordPress core
5. Reset all user passwords and regenerate security keys
6. Remove maintenance mode and monitor for 72 hours

Playbook 2: Brute Force / Credential Compromise

Trigger: Multiple failed login attempts from distributed IPs, successful login from an unusual location or IP, unauthorized admin account creation.

Automated containment steps:

1. Lock the compromised user account
2. Terminate all active sessions for the affected user
3. Block the attacking IP addresses at the firewall level
4. Enable enhanced login protection (CAPTCHA, increased lockout thresholds)
5. Send alert with full login activity for the affected account

Manual follow-up steps:

1. Review the activity log for all actions taken by the compromised account
2. Reverse any unauthorized changes (content, settings, user accounts)
3. Reset the compromised user’s password via a secure channel
4. Enable two-factor authentication for the affected account
5. Review all administrator accounts for unauthorized additions
6. Check for installed backdoors (malicious plugins, modified files)

Playbook 3: Unauthorized Administrator Access

Trigger: Activity log shows a new administrator account that was not created by a known authorized user, or an existing account’s role was elevated to administrator without authorization.

Automated containment steps:

1. Immediately disable the unauthorized admin account
2. Terminate all sessions for that account
3. Enable maintenance mode
4. Create a forensic backup
5. Lock all administrator accounts except a designated recovery account
6. Send critical alert to the site owner via email and (if configured) SMS

Manual follow-up steps:

1. Determine how the unauthorized account was created (compromised admin, plugin vulnerability, database manipulation)
2. Review all actions performed by the unauthorized account
3. Check for plugins installed, themes modified, or content changed
4. Scan for backdoors and malware
5. Reset all administrator passwords and regenerate security keys
6. Implement stronger access controls to prevent recurrence

Playbook 4: Data Breach / Personal Data Exposure

Trigger: Evidence that personal data (user accounts, customer records, form submissions) was accessed or exfiltrated by an unauthorized party.

Automated containment steps:

1. Enable maintenance mode
2. Block all outbound connections from the server
3. Create a forensic backup
4. Disable all non-essential plugins (reduce potential exfiltration vectors)
5. Generate a preliminary data scope report (which database tables were accessed, based on activity logs)
6. Send critical alert with data breach notification template

Manual follow-up steps:

1. Determine the full scope of accessed data
2. Identify all affected individuals
3. Engage legal counsel if the breach involves regulated data (GDPR, HIPAA, PCI-DSS)
4. Prepare and send breach notification to affected individuals (GDPR requires notification within 72 hours)
5. Report to relevant supervisory authority if required
6. Document all findings and actions taken
7. Conduct a thorough root cause analysis

Playbook 5: DDoS / Resource Exhaustion

Trigger: Sudden spike in traffic volume, server resource utilization exceeding normal thresholds, site becoming unresponsive.

Automated containment steps:

1. Enable aggressive rate limiting across all endpoints
2. Activate bot protection with challenge-based verification
3. Enable page caching bypass (serve cached content to reduce server load)
4. Block IP ranges showing the highest request volumes
5. Send alert with traffic analysis summary

Manual follow-up steps:

1. Analyze traffic patterns to determine if this is a targeted DDoS or a bot-driven resource exhaustion attack
2. If DDoS: contact hosting provider and consider activating CDN-level DDoS protection
3. If bot attack: review and update bot detection rules
4. Review server logs for the specific attack vectors (targeted endpoints, request patterns)
5. Implement permanent rate limiting rules based on the observed attack patterns
6. Consider geographic IP blocking if the attack originates from specific regions not relevant to your audience

Isolation Tools for WordPress

During incident containment, you often need to isolate the WordPress site quickly while preserving its state. VistoShield provides several isolation mechanisms.

Maintenance Mode

VistoShield’s maintenance mode goes beyond a simple “coming soon” page. During incident response, maintenance mode:

• Returns a proper HTTP 503 (Service Unavailable) status code so search engines know the downtime is temporary
• Displays a configurable maintenance page (not the WordPress default)
• Blocks all frontend access while allowing administrator dashboard access from whitelisted IPs
• Optionally blocks REST API access (preventing automated exploitation during remediation)
• Logs all access attempts during maintenance mode for forensic purposes

Plugin Quarantine

If a specific plugin is suspected as the attack vector, VistoShield can quarantine it: the plugin is deactivated and its files are moved to a quarantine directory outside the WordPress installation. This prevents the plugin from executing while preserving it for forensic analysis. The quarantine is reversible — the plugin can be restored to its original location if analysis determines it was not compromised.

Network Isolation

For severe compromises, VistoShield can restrict the site’s network access:

• Block outbound HTTP: Prevents PHP from making outbound connections, stopping data exfiltration and communication with command-and-control servers
• IP whitelist mode: Restricts all access (frontend and admin) to a specific list of IP addresses, typically limited to the site owner and security team during active remediation

Notification Best Practices

Effective incident communication is as important as technical remediation. Poor communication during an incident can cause more reputational damage than the breach itself.

Internal Notifications

VistoShield’s Incident Response plugin sends structured internal notifications through multiple channels:

• Email: Detailed incident report sent to all designated responders
• Webhook: JSON payload sent to a configured URL (for integration with Slack, Discord, PagerDuty, or custom monitoring systems)
• Dashboard notice: Persistent, high-visibility notice in the WordPress admin for all administrators

Each notification includes: incident type, severity level, timestamp, affected components, automated actions already taken, and recommended manual follow-up steps.

External Notifications

For data breaches that affect personal data, external notifications may be legally required:

• GDPR: Notification to supervisory authority within 72 hours; notification to affected individuals “without undue delay” if the breach poses a high risk to their rights and freedoms
• PCI-DSS: Notification to the payment card brands and acquiring bank if cardholder data was compromised
• US state laws: Varying notification requirements depending on the state and type of data compromised

VistoShield provides notification templates for each regulatory framework. These templates include the required information elements and can be customized with incident-specific details. The templates are starting points — for any breach involving regulated data, legal counsel should review notifications before they are sent.

Post-Incident Reporting

A thorough post-incident report serves multiple purposes: it documents what happened for stakeholders, satisfies regulatory requirements, provides input for improving the incident response plan, and creates an organizational knowledge base of security events.

Report Structure

VistoShield generates post-incident reports with the following structure:

1. Executive summary: One-paragraph overview of the incident, its impact, and the outcome
2. Timeline: Chronological sequence of events from initial compromise through detection, containment, eradication, and recovery
3. Technical analysis: Attack vector, vulnerability exploited, attacker actions, data accessed or modified
4. Impact assessment: Downtime duration, data affected, users impacted, financial impact (if quantifiable)
5. Response actions: All containment, eradication, and recovery steps taken, with timestamps
6. Root cause: The specific weakness that enabled the incident
7. Remediation: Actions taken to prevent recurrence
8. Recommendations: Additional improvements to security posture and incident response capability

Automated Report Generation

VistoShield’s Incident Response plugin automatically generates reports from activity log data, security scanner findings, and playbook execution records. The report is available in HTML format (for viewing in the dashboard), PDF format (for sharing with stakeholders), and JSON format (for integration with external incident management systems). Reports can be generated for any past incident as long as the activity log data is retained.

Agency-Scale Incident Response

Agencies managing multiple WordPress sites face unique challenges in incident response. A compromise on one client site may indicate a broader attack targeting multiple sites (shared hosting environment, common plugin vulnerability, compromised agency credentials).

Centralized Monitoring

The VistoShield Agency plan (€149/year for 25 sites) provides a centralized dashboard that aggregates security alerts from all managed sites. This enables cross-site correlation: if the same vulnerability is exploited on multiple sites, the agency is alerted to the pattern immediately rather than discovering it one site at a time.

Standardized Playbooks

Agencies can define master playbooks that are deployed to all managed sites, ensuring a consistent response regardless of which team member handles the incident. Custom playbooks can override master playbooks for sites with specific requirements (e.g., sites subject to HIPAA or PCI-DSS that require additional notification steps).

Client Communication Templates

The Agency plan includes client-facing notification templates that explain the incident in non-technical language, describe the actions taken, and outline preventive measures implemented. These templates maintain a professional tone and can be customized with the agency’s branding.

Implementation with VistoShield Incident Response

Here is a step-by-step guide to implementing incident response on your WordPress site.

Step 1: Install Prerequisites

The Incident Response plugin works best with the full VistoShield ecosystem. At minimum, install:

• Incident Response (the core IR plugin)
• Activity Log (provides the detection and forensic layer)
• Security Scanner (provides malware and file integrity detection)

Step 2: Configure Notification Channels

Navigate to VistoShield → Incident Response → Notifications and configure at least one notification channel. Email is the minimum; adding a webhook for Slack or Discord provides faster alerting for teams.

Step 3: Review and Customize Playbooks

The five pre-built playbooks (malware, brute force, unauthorized admin, data breach, DDoS) are active by default with sensible configurations. Review each playbook and customize:

• Trigger sensitivity: Adjust thresholds for automated activation (e.g., how many failed logins trigger the brute force playbook)
• Containment aggressiveness: Choose between “conservative” (alert and recommend) and “aggressive” (auto-execute containment) for each playbook
• Notification recipients: Specify who receives alerts for each incident type
• Whitelisted IPs: Define IP addresses that should always have admin access, even during containment

Step 4: Test the Playbooks

VistoShield includes a Simulation Mode that lets you trigger each playbook in a test environment without affecting the live site. The simulation executes all playbook steps but marks them as “test” actions that are automatically reversed after completion. This verifies that notifications are delivered, containment actions execute correctly, and the recovery process works as expected.

Step 5: Document Your Plan

Use the Plan Generator tool to create a customized incident response plan document based on your configured playbooks, notification channels, and contact information. This generates a printable document that can be shared with team members and stored offline for reference during an actual incident.

Pricing and Availability

The VistoShield Incident Response plugin is free and open source under the GPLv2 license. The free version includes basic incident detection, manual containment tools, and post-incident reporting. The Pro version adds the five automated playbooks, simulation mode, webhook notifications, PDF report generation, and the plan generator.

• Free: Manual containment tools, basic detection triggers, HTML incident reports
• Single Plugin Pro: €19/site/year — adds 5 automated playbooks, simulation mode, webhook notifications, PDF reports
• Pro Bundle: €49/site/year — all 9 VistoShield plugins with Pro features
• Agency: €149/year for 25 sites — centralized IR dashboard, cross-site correlation, client templates

For full pricing details, visit the pricing page.

Key Takeaways

• Every WordPress site needs an incident response plan. Improvising during a breach leads to longer downtime, greater data loss, and worse outcomes. Even a simple, one-page plan is better than none.
• The six-phase model provides structure. Preparation, identification, containment, eradication, recovery, and lessons learned. Each phase has specific actions that should be documented and practiced.
• Automated playbooks save critical time. Containment actions that take a human 30–60 minutes to execute manually can be completed in seconds by an automated playbook. Speed during containment directly reduces incident impact.
• Evidence preservation must come before cleanup. Always create a forensic backup of the compromised state before beginning eradication. This evidence is essential for root cause analysis and regulatory compliance.
• Post-incident reporting is not optional. GDPR requires breach notification within 72 hours. PCI-DSS has its own notification requirements. Even without regulatory obligations, documenting incidents improves future response capability.
• Agencies need centralized IR management. Managing incident response across 25+ sites without centralized tooling is operationally unsustainable. Cross-site correlation detects patterns that per-site monitoring misses.
• VistoShield’s Incident Response plugin provides automated playbooks, containment tools, and reporting in a single, free, GPLv2-licensed plugin with optional Pro features for advanced requirements.
• For setup instructions, visit the Incident Response documentation.