Incident Response Plan Template for Web Security Teams

When incidents happen, speed and clarity matter more than perfect documentation. This template gives web teams a practical response flow that reduces confusion under pressure.

Phase 1: triage and containment

• Classify severity and impacted systems.
• Contain active exploitation paths immediately.
• Preserve logs and forensic evidence.
• Assign incident commander and channel owners.

Phase 2: communication and recovery

• Send internal status updates with timeline and owners.
• Apply fixes, rotate compromised credentials, and validate closure.
• Restore services with staged monitoring checkpoints.

Phase 3: post-incident hardening

• Root cause analysis with actionable control gaps.
• Prioritized remediation plan with deadlines.
• Executive summary: impact, actions, residual risk.

# Minimal incident timeline template
T+00: Detection
T+15: Severity confirmed
T+30: Containment action live
T+60: Stakeholder update sent
T+180: Recovery validated
T+24h: Post-incident review kickoff

Incident severity classification matrix

P1 — Critical (respond immediately)
  - Active data exfiltration confirmed
  - Remote code execution in progress
  - Ransomware or destructive attack
  Response: Isolate systems, engage all hands, notify legal within 1h

P2 — High (respond within 2h)
  - Credential compromise detected
  - Sensitive data potentially accessed
  - Defacement or unauthorized code deployed
  Response: Rotate credentials, investigate scope, notify management

P3 — Medium (respond within 24h)
  - Vulnerability exploited but impact limited
  - Anomalous access without confirmed data loss
  Response: Investigate, patch, monitor

Checklist for the first 60 minutes

• Confirm severity and impact scope.
• Assign incident commander (single decision-maker).
• Block active attack vector at WAF/firewall.
• Revoke and rotate all potentially compromised credentials and API keys.
• Preserve a snapshot of logs before any system changes.
• Send initial stakeholder notification with: what happened, what is contained, next update ETA.

Roles and responsibilities

Incidents fail when roles are unclear. Every person on a web security team needs to know their job before an incident happens, not during it.

• Incident Commander: Single decision-maker with authority to take systems offline, escalate, and communicate externally. One person only — committee decisions during incidents cost time.
• Technical Lead: Owns the investigation and containment actions. Documents every step in a shared incident channel in real time.
• Communications Lead: Owns stakeholder updates — internal (management, legal, HR) and external (affected users, regulators if required). Prepares templated statements in advance.
• Evidence Owner: Responsible for preserving logs, screenshots, and forensic artifacts before any system changes. Maintains chain of custody if legal action is possible.
• Recovery Owner: Leads the restore process, monitors for recurrence, and signs off on the all-clear.

Communication templates

Prepare these templates before you need them. Drafting communications during an active incident introduces errors, delays, and legal risk.

# Internal stakeholder update (T+30 minutes)
SUBJECT: [INCIDENT] [Brief description] — Update 1

Status: Active / Contained / Resolved
Detected: [timestamp]
Affected systems: [list]
Current action: [what the team is doing now]
Next update: [time]
Incident channel: [link]

---
# User notification template (if data affected)
We are writing to inform you that on [date], we identified
a security incident affecting [what]. We took the following
immediate steps: [actions]. If your account was potentially
affected, we recommend [action]. We have engaged [security
firm/legal] and will provide updates at [URL].

Evidence preservation checklist

Evidence collected incorrectly or too late is inadmissible and unhelpful. Capture these artifacts before taking any containment action that might alter them.

• Export raw web server access logs for the 24 hours before and during the incident.
• Take screenshots of any attacker-controlled content (defacement, injected scripts, phishing pages).
• Capture network flow data if a WAF or IDS is in place.
• Export database query logs for the incident window if SQLi is suspected.
• Preserve a memory dump if an active process injection attack is suspected.
• Store all evidence in a write-protected location with timestamps and access logs.

Common web security incident playbooks

Compromised admin credentials

• Force logout all active sessions immediately.
• Reset password and revoke all API tokens for the affected account.
• Review audit logs for all actions taken by the compromised account in the past 30 days.
• Enable MFA if not already required.
• Check for new admin accounts created during the compromise window.

Malicious code injection (XSS, stored payload)

• Identify all locations where the payload was stored and remove it.
• Assess how many users were served the malicious content and in what timeframe.
• Review CSP headers — if CSP was configured correctly, it should have blocked execution even if injection occurred.
• Implement input validation and output encoding to prevent recurrence.
• Notify affected users if session tokens were potentially stolen.

Exposed .env or credentials file

• Rotate all credentials in the file immediately: database passwords, API keys, secret keys.
• Revoke tokens at the provider level (AWS IAM, Stripe, Twilio, SendGrid, etc.).
• Review access logs for the exposed file URL to determine how long it was accessible and whether it was accessed.
• Deploy a new application key and restart all services.
• Add the path to .htaccess or Nginx deny rules permanently.

Post-incident review: the blameless post-mortem

A blameless post-mortem focuses on system and process failures rather than individual mistakes. The goal is durable improvement, not accountability theater. Teams that run blameless post-mortems learn faster and fix root causes instead of symptoms.

• Timeline reconstruction: Build a complete timeline from first indicator to full containment. Include detection lag — how long between the vulnerability being exploitable and detection. This is your single most important metric to improve.
• Root cause analysis (5 Whys): Ask "why" five times to reach the systemic failure beneath the surface event. A vulnerable plugin is not a root cause — the root cause is that no process existed to monitor plugin CVE disclosures.
• Contributing factors: Identify all conditions that allowed the incident to happen and spread. Missing MFA, no rate limiting, over-privileged database account — list every contributing factor regardless of severity.
• Improvement backlog: Convert each contributing factor into a tracked action item with an owner and deadline. These feed directly into the vulnerability management SLA process.
• Distribution: Share the post-mortem within 5 business days of resolution. Include engineering, product, security, and leadership. External-facing summaries for affected customers should follow legal review.

Building incident response readiness before incidents happen

The quality of incident response is determined before the incident occurs, not during it. Teams that test their response process handle real incidents better and reduce mean time to recovery significantly.

• Tabletop exercises: Quarterly scenario walkthroughs where the team talks through how they would respond to a specific incident type (e.g., ransomware, data breach, credential compromise). No systems are touched — the goal is identifying gaps in the plan and communication under pressure.
• Runbook testing: Each playbook (compromised credentials, XSS injection, .env exposure) should be tested by walking through each step against a staging environment. Steps that are unclear or missing are discovered before a real incident.
• Contact list maintenance: The incident response contact list must be updated quarterly. Outdated phone numbers and email addresses for on-call contacts are a consistent source of response delay.
• Communication channel readiness: Pre-create a dedicated incident channel (Slack, Teams) template and confirm all relevant people can be added and given access instantly. Do not set up communication infrastructure during an active incident.
• Recovery validation: Test the restore procedure from backup at least quarterly. Discovering that backups are corrupted or the restore process is broken during an incident is a second incident.

Post-incident security validation

• Run a full external security scan to confirm attack paths are closed. Use AI QA Monkey free security scanner.
• Validate all security headers are present — read the security headers guide.
• Review compliance posture with the free compliance scanner.
• Schedule a follow-up scan 7 days after remediation to confirm no regression.