Website Security Incident Response Plan

Published

Jul 14, 2026

Updated

Jul 15, 2026

Reading time

14 min read

An incident response plan is a rehearsed decision system, not a document written after an attack. It should help a technical team contain an event, help customer teams communicate verified facts, and give leadership and legal contacts enough context to make timely decisions. This guide follows the shape of established frameworks — NIST SP 800-61 Rev. 3's lifecycle and the SANS PICERL model (preparation, identification, containment, eradication, recovery, lessons learned) — translated into the decisions a web team actually faces when the "attacker" might just as easily be a bad deploy as a real adversary.

At the scale a managed edge orchestration layer operates — many origins, several security and CDN providers, hundreds of policy changes a year — the discipline behind a security incident response plan matters more than any single control. Consistent website incident response across every provider in the stack is what keeps one team's local judgment call from becoming everyone else's outage, which is why this plan treats edge provider escalation and cross-provider evidence as first-class steps, not an afterthought.

Scenario: Acme Shop's new WAF rule blocks checkout

At 09:02 UTC, Acme Shop's checkout conversion alert rises after a routine WAF policy deployment. Security events show a new block decision on POST /checkout/confirm; application health and payment-provider telemetry remain healthy. This is a security incident because the change prevents a critical customer journey, but it is not evidence of an attack or a data disclosure. The team must restore legitimate checkout without broadly disabling protection or leaking customer data into the incident channel.

1. Use a severity matrix that reflects impact and confidence

Classify severity from impact, scope, and confidence rather than raw request volume. Reassess when evidence changes. A small confirmed issue on checkout or account recovery can outrank a large noisy scan against a public page.

Acme initially classifies the checkout WAF block as SEV-2: a critical journey is materially affected, the scope is known, and there is no indication that a security boundary is bypassed. If evidence shows an active attack or data exposure, the incident commander immediately reassesses severity and engages the appropriate contacts.

2. Build a reusable security incident response plan

Copy this plan into the incident record and fill it with verified facts. Keep credentials, raw request bodies, payment information, session tokens, and full personal URLs out of chat, ticket, and status updates. A security incident response plan only earns its name if the same template is used every time: reuse removes the debate over what to log and what to skip while the clock is running.

incident:
  id: INC-YYYY-NNN
  commander: named-primary-and-backup
  severity: SEV-2
  declared_at_utc: 2026-07-14T09:05:00Z
  customer_journeys: [checkout]
  confirmed_facts: []
  hypotheses: []
  containment_change: null
  rollback_owner: named-owner
  evidence:
    - sanitized-request-ids
    - WAF-policy-version
    - deployment-version
    - checkout-success-rate-by-region
  next_update_utc: 2026-07-14T10:05:00Z
  exit_criteria:
    - legitimate-checkout-success-rate-restored
    - security-control-behavior-verified
    - monitoring-stable-for-agreed-window

Use independent signals before containment: synthetic checkout, real-user conversion, WAF action counts, origin/application responses, and recent configuration changes. Preserve the relevant timestamp range, request or trace IDs, policy and deployment versions, affected routes and regions, and the business signal. Evidence should be minimal, sanitized, access-controlled, and retained under the normal policy.

Treat evidence integrity as part of containment. Export logs and configuration snapshots to storage the incident team does not casually overwrite, record who pulled each artifact and when, and keep a hash or checksum of exports that might later matter to a regulator, insurer, or law enforcement contact. If evidence could be relevant to a legal hold, freeze its normal retention and deletion schedule until legal/privacy releases it — a plan that deletes its own evidence on the usual 30-day cycle has quietly destroyed the record it was supposed to protect.

3. Run the WAF checkout timeline

The timeline is a decision aid, not a promise that every event unfolds identically. The incident commander owns the log and changes the cadence when facts require it.

09:35 UTC | SEV-2 | Checkout confirmation was affected from 09:02-09:20 UTC.
Mitigation: reverted the newly deployed route-specific WAF policy.
Current state: checkout success rate and latency are within baseline; investigation continues.
Next update: 10:05 UTC. No customer action is required at this time.

4. Contain narrowly, communicate facts, and prove recovery

Containment should address the observed behavior with the smallest effective change: a route-specific WAF rollback, a scoped rate limit, credential revocation, or an origin firewall adjustment. Record the exact configuration version, approver, rollback step, and expiry or review date. Do not respond to a checkout outage by globally disabling managed protections or opening direct-origin access unless the incident commander explicitly accepts, records, and time-boxes that risk.

Internal updates state the owner, severity, confirmed impact, actions, current risk, and next decision time. Customer-facing updates state only verified impact, affected service, any required action, and the next update time. Provider escalations include account or service ID, UTC window, hostname and route, sanitized request IDs, region, observed response, policy version, changes already made, and business impact. Do not send credentials or sensitive payloads through unapproved support channels.

5. Run edge provider escalation with complete evidence

Most edge, WAF, and CDN providers run their own tiered severity system — commonly labeled P1-P4 or SEV1-SEV4 — with the top tier reserved for confirmed outages or active attacks and backed by an emergency phone line or a dedicated incident email address rather than the normal support queue. Knowing that tier structure before an incident, not during one, is what makes edge provider escalation fast instead of a scramble to find the right contact.

A support engineer who has never seen your traffic needs the same evidence your own team just assembled, packaged so they can act on it without a back-and-forth:

• Account or zone identifier, and the exact hostname, route, or service affected.
• The UTC time window, stated as a range, not "since this morning."
• The policy, rule, or configuration version in effect, and what changed immediately before symptoms started.
• Steps to reproduce with actual result versus expected result, plus a small number of sanitized request or trace IDs (never full request bodies, tokens, or payment data).
• Supporting diagnostic output (HAR files, curl or dig traces, traceroutes) and the priority level you are requesting.
• What you have already changed, so the provider does not propose a rollback you already tried.

Escalating with this evidence attached, rather than describing the symptom prose-first, moves a case out of the generic queue and cuts clarifying replies before an engineer starts working it.

If two providers in the stack (a DNS/anycast layer and a WAF, say) each show a partial view of the same event, escalate to both in parallel rather than waiting for one to resolve first — sequencing escalations by guesswork is a common reason incidents run longer than the fault required.

6. Meet legal, regulatory, and customer notification obligations

Notification obligations often run on a clock that starts before your investigation is finished. Under GDPR, for example, a personal-data breach likely to risk individuals' rights and freedoms must generally be reported to the relevant supervisory authority within 72 hours of the organization becoming aware of it — "becoming aware" does not wait for full root cause. Many other regimes set their own fixed or "undue delay" windows. Confirm early, with legal/privacy in the loop from SEV-1 or SEV-2 declaration, whether the facts gathered so far plausibly trigger a notification duty, rather than waiting for the postmortem to ask.

Keep internal legal assessment and customer-facing statement separate: legal and the incident commander decide what is confirmed and what obligations apply; communications drafts only what is verified and necessary for the customer to act on. A premature "no customer data was affected" claim that is later corrected is more damaging than a slower, accurate update — and can itself become a compliance problem if a notification duty existed all along.

Troubleshooting

Learn and rehearse

After recovery, hold a blameless review while the timeline is fresh — SANS guidance suggests within roughly two weeks, before memory and chat threads fade. Record what happened, why detection and controls behaved as they did, which decisions were difficult, and the owner and due date for every improvement. Feed each finding back into preparation, whether that's an updated severity matrix, a new escalation contact, or a rehearsal scenario nobody had tried; lessons that do not change the plan were not really learned.

Rehearse both a technical and cross-functional scenario at least once: a WAF checkout block, credential exposure, origin bypass signal, provider outage, or malicious webhook burst. Rotate who plays incident commander across rehearsals — a plan that only works with one specific person in the room is a single point of failure. A plan that cannot be safely exercised is still an assumption.

Related guides

• DDoS Protection
• WAF Configuration
• How to Protect Your Origin Server
• Secure Webhooks

Authoritative references

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