Website Security Incident Response Plan

An incident response plan is not a document written after an attack. It is a rehearsed way to make decisions when a WAF rule blocks checkout, an API token is exposed, a bot campaign overloads an origin, or a security event may involve customer data.

The plan should serve technical and non-technical people. Engineers need the authority and access to contain an event. Operations and customer teams need verified facts, not guesses. Leadership and legal teams need to understand impact, obligations, and decisions. The best time to agree on those roles is before an incident.

Define what counts as an incident

Not every failed request is a security incident. Define categories and examples so teams do not lose time debating severity during an outage. A practical web-security taxonomy includes suspected credential stuffing, DDoS or resource exhaustion, origin bypass, WAF false positives, compromised credentials or keys, malicious API behavior, third-party script exposure, and a suspected data disclosure.

Set severity using business impact and confidence, not only traffic volume. Consider affected customer journeys, sensitive data, geographic scope, duration, service dependencies, and whether a control is being bypassed. A small event on password reset or payment confirmation can be more urgent than a noisy scan against a public page.

Assign roles and decision authority

Every plan needs named roles and backups. The same person may cover multiple roles in a small team, but their responsibilities should remain distinct:

• Incident commander: owns severity, priorities, decision log, and the end of the incident.
• Technical lead: directs investigation, containment, and recovery across edge, application, and infrastructure teams.
• Communications lead: prepares internal updates and customer-facing statements from verified facts.
• Legal and privacy contact: assesses notification, contractual, and regulatory obligations.
• Provider liaison: opens and manages escalations with CDN, WAF, hosting, DNS, payment, or identity providers.

Keep emergency contacts, account identifiers, support entitlements, and escalation channels in an access-controlled but reachable location. Make break-glass access time-bounded, separately authenticated, fully logged, and reviewed after use.

Prepare evidence that connects the delivery path

Web incidents cross layers. Edge logs may show a challenge or block; application logs may show an authorization failure; origin telemetry may reveal a slow dependency. Preserve a minimal evidence package that can connect them:

• Coordinated timestamps and the time source used by each system.
• Request, trace, or correlation IDs from edge to origin.
• Relevant WAF, bot, rate-limit, CDN, DNS, application, and authentication decisions.
• Deployment and configuration versions, including cache and firewall changes.
• Affected hosts, routes, customer journeys, regions, and time windows.
• Business signals such as login, checkout, API completion, and support contacts.

Do not copy secrets, unredacted request bodies, payment data, or session tokens into an incident chat. Apply log retention, access controls, and privacy policy to emergency evidence just as you would during normal operations.

Triage, contain, and recover in stages

1. Stabilize the service

Confirm the alert with independent signals. Check synthetic journeys, real-user signals, edge decision logs, origin health, and recent releases. Start an incident record with the current facts, assumptions, owner, and next update time.

2. Scope the event

Identify what is affected and what is not: public site, API, login, admin, one region, one provider, or an origin path. Distinguish an edge block from an origin failure, a customer report from verified abuse, and a traffic spike from confirmed compromise.

3. Apply the narrowest effective containment

Use a scoped WAF rule, rate limit, route disablement, credential revocation, origin firewall change, or traffic shift that addresses the known behavior. Record the exact configuration change and rollback step. Avoid broad country, IP, or user-agent blocks unless evidence and business impact justify them.

4. Eradicate the cause and validate recovery

Rotate affected credentials, remove the vulnerable path, deploy a patch, correct a policy, or restore a known-good configuration. Validate the user journey, API behavior, security control, and monitoring from more than one location. Do not declare recovery because the alert volume fell; confirm the original harmful condition is gone and legitimate users can complete critical work.

Communicate facts, impact, and next updates

Set a regular update cadence. Internal updates should name the incident owner, confirmed impact, actions taken, current risk, and next decision point. Customer-facing communications should state what is known, which service is affected, what customers should do if anything, and when the next update will arrive. Separate confirmed facts from active hypotheses.

Provider escalations are more effective with a short, structured request: account or service ID, start time and timezone, affected hostname or endpoint, request IDs, region, observed response, traffic pattern, changes already made, and the business impact. Do not send credentials or sensitive payloads through an unapproved support channel.

Learn and rehearse

After recovery, run a blameless review while the timeline is fresh. Explain what happened, why controls did or did not work, which decisions were difficult, and what should change. Each improvement needs an owner and due date: a missing dashboard, narrower WAF exception, origin-authentication gap, runbook update, or better customer alert.

Practice the plan with tabletops and controlled tests. Use realistic scenarios: a DDoS against login, a leaked API key, an origin IP exposed through old DNS, a provider outage, a malicious webhook burst, and a WAF change that blocks checkout. A plan that has not been exercised is an assumption.

Incident plan checklist

Before an incident, verify that roles and contacts are current; edge and origin logs share a correlation path; emergency access is tested; critical providers have an escalation route; customer communications are drafted; rollback procedures exist; and the team has rehearsed at least one technical and one cross-functional scenario.

For controls that help reduce the incident surface, read DDoS Protection, WAF Configuration, and How to Protect Your Origin Server.

Authoritative references

• NIST SP 800-61 Rev. 3: Incident Response Recommendations
• CISA: Incident Response Plan Basics
• OWASP Logging Cheat Sheet
• Cloudflare Logpush documentation