Prepare for a DDoS event by making a service-specific readiness record before an outage: map exposed endpoints, confirm the protection already in place, establish normal behavior and rehearse who will act. The output is an evidence-backed list of ready items and unresolved gaps, not a promise that an attack cannot interrupt service.
This guide is for the operator of an already provisioned service. If disruption is happening now, use the website DDoS incident-response guide. If you are still buying protection, start with coverage and selection. WebCare360 publishes this preparation workflow; it does not establish included features for any order.
Start a readiness record for one service
Name the service, its operational owner, the review date and the business journeys that must remain usable. Gather the accepted order, architecture notes, access permissions and the protection provider’s documentation. Use the following fields for each check:
- Requirement: what must work and which endpoint it concerns.
- Evidence: a dated configuration reference, provider answer or authorized check result.
- Owner: the person or team able to resolve the issue.
- Status: verified, unresolved or not applicable, with a reason.
- Next action: the remaining work and review date.
For example, “checkout remains reachable through the configured proxy” needs a documented traffic path and a successful legitimate checkout check. An unchecked dashboard switch is insufficient evidence. Record the traffic path and checkout result in the service readiness record.
Inventory endpoints and the path to each origin
List public hostnames, IP addresses, protocols and ports for the website, APIs, DNS, mail and any non-web services. Include administration access and dependencies such as payment callbacks. For each, identify whether traffic uses a proxy, an upstream network service or a direct path, and name the responsible operator. Do not assume that protecting one hostname covers every service sharing its server.
Check for direct origin access that could bypass an intended proxy. Cloudflare’s origin-protection guidance illustrates why DNS exposure and origin access rules matter. Follow your own provider’s documented trusted-source requirements; preserve required management and partner access before restricting anything. Record unknown paths as gaps rather than guessing that they are protected.
Confirm the deployed coverage and control boundaries
Record the actual covered endpoints and protocols, activation method, exclusions and escalation arrangement from the service documentation. Resolve discrepancies with the responsible provider. A capacity headline or product name is not a per-service acceptance test.
- DDoS mitigation addresses attack traffic within its defined coverage.
- A WAF evaluates web requests; it is not equivalent to protection for every network protocol.
- A host firewall controls access at the host; it cannot recover an upstream link already saturated.
- A CDN can assist delivery, but the label alone does not guarantee attack protection.
- Autoscaling adds resources under configured conditions; it is not a substitute for mitigation and may increase costs.
- Monitoring supplies observations and alerts; observing traffic does not itself prevent an attack.
The separate DDoS and WAF documentation illustrate different control scopes. These are vendor examples, not evidence of Cloudflare features in a WebCare360 subscription. Check the current WebCare360 service description against your accepted order when recording coverage.
Record normal behavior and verify visibility
Save representative ordinary and peak periods for the measurements you can access: traffic volume, request rate, response times, error rates and relevant resource use. Annotate releases, promotions and scheduled jobs so a later comparison has context. Do not choose a universal alert threshold from this article; the workload, measuring point and legitimate peaks matter.
Identify where allowed and rejected traffic can be inspected, who has access, the available retention period and any sampling or reporting delay. Verify that a permitted alert test reaches its named recipient. Record visibility you do not have and the provider contact who can supply it. AWS’s operational guidance treats visibility, alerting and support engagement as operational concerns; its product capabilities must not be assumed on another platform.
Review proposed limits against legitimate clients
Document each relevant limit’s scope, counting key, action, owner and rollback method. An IP-based limit can affect several legitimate users behind one address; browser challenges may be unsuitable for API clients. Use your vendor’s supported observation or testing method where available, then check essential journeys before enforcing a change. Rate-limiting documentation explains that matching requests are subject to a configured action; it is not a guarantee that only malicious requests match.
Keep the readiness exercise separate from rule tuning. If a check exposes a configuration fault, assign it to an authorized operator and record the corrective check needed. Do not disable protection broadly or apply arbitrary request limits just to complete the checklist.
Prepare contacts, recovery assumptions and an evidence packet
Name who can contact the provider, approve routing or filtering changes, communicate with customers and authorize recovery. Keep an alternative contact channel accessible if the hosted website or email is unavailable. Confirm access without sharing passwords, private keys or recovery codes in the record.
If a failover environment exists, document its capacity assumptions, data freshness, protection scope, dependencies and return procedure. A second address does not prove independence from the affected path. If there is no tested failover, record that limitation. Keep backup restoration as a separate recovery capability; restoring files does not filter incoming traffic.
Prepare an empty incident packet with fields for start time and timezone, affected endpoints, user-visible symptoms, traffic comparisons, relevant event or rule identifiers, provider ticket reference and a change timeline. Specify where evidence will be stored securely and who may access it. Minimize customer information and secrets in support exports.
Run a tabletop before running traffic tests
Use a fictional service-disruption scenario in a discussion, without generating attack traffic. Ask the designated participants to locate the service record, identify the escalation contact, retrieve an example monitoring view and explain who would approve a change. Walk through how they would validate legitimate access and reverse an unsuccessful change. Record missing access, unclear authority and unavailable evidence as actions.
NIST SP 800-61r3 includes preparation, plans and exercises within incident risk management. A tabletop checks coordination; it does not establish mitigation capacity. Load testing or attack simulation is a separate activity requiring explicit authorization, provider rules, a scoped plan and stop conditions. Cloudflare’s testing rules are one example of provider-specific restrictions.
Close gaps and date the next review
Mark readiness as unresolved when an essential endpoint has unconfirmed coverage, nobody can reach the escalation channel or a critical legitimate-client check fails. Assign an owner and a next check. Where a limitation remains, have the accountable service owner record the decision and its consequences; do not silently label it verified.
Review the record after a relevant deployment, traffic-path change, provider change, exercise or incident. Keep the previous version so the team can see what changed. Preparation is complete for the recorded scope only when the required evidence and responsibilities are in place; it is never a guarantee of uninterrupted service.
