What Is DDoS Incident Response? What Should Organisations Do During an Attack?

In a DDoS attack there is something as important as technical capacity:

Response speed.

The organisation may have an anti-DDoS service.

The WAF may be running.

The CDN may be in place.

The SOC may see the attack.

But if it is unclear who does what during the attack, valuable minutes are lost.

The first minutes matter especially in DDoS incidents.

Because within a short time the attack can affect;

the internet link,

DNS services,

the web application,

APIs,

the VPN infrastructure,

the customer portal.

All at once.

Organisations must therefore have a DDoS incident response plan, a DDoS playbook, an escalation matrix and a war room process prepared before the attack happens.

The core purpose of DDoS incident response is not merely to stop attack traffic.

The real objective is;

to keep critical services available, limit the attack's business impact, coordinate the right teams quickly and return the system to normal safely.

What Is DDoS Incident Response?

DDoS incident response is the technical and operational response process running from the detection of a distributed denial of service attack to the return of services to normal.

The process generally consists of these stages:

Detection

Identifying the attack.

Validation

Confirming it really is a DDoS attack.

Classification

Determining the attack type: volumetric, L3/L4, layer 7 or DNS.

Mitigation

Engaging the controls that will reduce the attack's impact.

Communication

Coordination with technical teams, management and third parties.

Recovery

Returning services to normal operating level.

Post-Incident Review

Analysing the incident and carrying out improvement work.

This structure turns DDoS response from an unplanned crisis into a controlled security operation.

What Should Be Done First in a DDoS Attack?

The first step is not to panic or immediately write a random firewall rule.

The incident must first be verified.

The SOC and network teams should look at these questions:

Is the traffic really above normal?

Which service is affected?

Are genuine users unable to get service?

Did bandwidth rise?

Did PPS or CPS rise?

Did HTTP RPS rise?

Is DNS QPS abnormal?

Did the WAF or anti-DDoS raise an alert?

This information helps understand the attack type.

Wrong classification leads to wrong mitigation decisions.

The First 5 Minutes of a DDoS Attack

In the first minutes the aim is to determine the attack's scope quickly.

Within the first 5 minutes these checks can be made:

1. The alert is verified

The SOC checks whether the alert is genuine.

2. The affected service is identified

Is it the website?

The API?

DNS?

The VPN?

3. The traffic profile is examined

Gbps, PPS, CPS, RPS or QPS values are checked.

4. User impact is assessed

Latency, timeouts and error rate are monitored.

5. Anti-DDoS status is checked

Has mitigation engaged?

This first analysis determines the next response step.

What Should Be Done in the First 15 Minutes?

Once the attack is confirmed, technical coordination must begin.

At this stage;

the SOC,

network,

application,

the ISP,

the anti-DDoS provider

can be brought into contact.

In a volumetric attack in particular, if there is a risk of the attack exhausting the organisation's internet link, upstream mitigation must be assessed quickly.

In a layer 7 attack, meanwhile;

the WAF,

bot management,

rate limiting,

application protection

mechanisms take priority.

Why Is the First 60 Minutes Critical?

In prolonged DDoS attacks, technical filtering alone may not be enough.

Within the first hour;

business impact,

customer impact,

SLA status,

backup services,

failover options,

management communication

must also be assessed.

If the attack affects critical digital services, the incident can escalate from a technical incident to a corporate crisis.

How Is DDoS Severity Determined?

Not all DDoS attacks are at the same level.

A simple classification might be:

Low

The attack was detected but there is no user impact.

Medium

There is a performance drop but the service is available.

High

There is clear user impact on critical services.

Critical

There is a service outage, a serious SLA breach or broad business impact.

Traffic volume alone must not be used when setting severity.

The most important criterion must be business impact.

Is a 100 Gbps Attack Always Critical?

No.

If the edge anti-DDoS platform cleans the 100 Gbps attack entirely and genuine users are unaffected, the operational impact is limited.

By contrast a 100 Mbps layer 7 attack can halt the payment API entirely.

It is therefore necessary to think of it as:

Attack size ≠ business impact

What Is a DDoS Playbook?

A DDoS playbook defines in advance the response process to follow when an attack is detected.

The playbook can contain processes for;

alert verification steps,

attack classification,

escalation,

mitigation,

provider communication,

recovery,

reporting.

A good playbook reduces thinking time during the attack.

What Is a DDoS Runbook?

A runbook generally defines more technical, step-by-step operations.

For a SOC analyst, for example:

1. Check the anti-DDoS portal.

2. Verify the NetFlow data.

3. Identify the affected destination IP.

4. Check the application health dashboard.

5. Set the incident severity.

and similar steps.

The playbook guides the overall operation; the runbook guides specific tasks.

What Is an Escalation Matrix?

An escalation matrix is the structure defining which teams or managers are notified at which incident level.

For example:

Severity 2

SOC + network.

Severity 1

SOC + network + application + management.

Critical

Executive management + legal + communications + provider.

This structure reduces communication confusion in large organisations in particular.

Who Should Be the DDoS Incident Commander?

In major security incidents it is useful to have one person coordinating.

That role can be called the incident commander.

The incident commander's job is not;

to perform all the technical work themselves.

Their job is;

to coordinate teams,

to track decisions,

to set priorities,

to manage communication.

This role is particularly important during DDoS.

What Is a War Room?

A war room is the shared working environment for different teams during a critical incident.

It can be physical or virtual.

Participants may include;

the SOC,

network,

systems,

application,

cloud,

the ISP,

the DDoS provider,

management.

The aim is that everyone works from the same data and incident timeline.

What Information Should Be Visible in the War Room?

On a shared dashboard;

Attack Volume

Gbps.

PPS

Packet rate.

CPS

Connection rate.

HTTP RPS

Application traffic.

DNS QPS

DNS load.

Application Health

Response time.

Mitigation Status

Anti-DDoS state.

Business Metrics

Login or transaction success.

should be visible.

This shared view reduces misunderstandings between teams.

What Should Be Done in a Volumetric DDoS Incident?

In a volumetric attack the core problem is usually bandwidth consumption.

The priority controls are therefore;

the ISP,

anti-DDoS,

the scrubbing centre,

BGP diversion.

Blocking IPs on the firewall is usually not enough.

Because the link may already be saturated.

The attack must therefore be cleaned as far upstream as possible.

What Should Be Done in a Layer 3/4 DDoS Incident?

In a layer 3/4 attack the values for;

PPS,

CPS,

the session table,

firewall CPU,

the load balancer

must be examined.

Depending on the attack type, controls such as;

SYN protection,

connection limits,

protocol filtering,

scrubbing

can be engaged.

But aggressive limits must be applied carefully because they can affect genuine users.

What Should Be Done in a Layer 7 DDoS Incident?

In application layer attacks the network bandwidth can look normal.

For that reason;

the WAF,

the CDN,

bot management,

the API gateway,

application monitoring

matter most.

If the attack is targeting a particular endpoint, for example;

a rate limit,

a temporary challenge,

request filtering,

load shedding

can be applied.

When Should Rate Limiting Be Engaged?

Rate limiting is a powerful control in layer 7 attacks in particular.

But setting a very low threshold hastily during an attack causes genuine customers to be blocked.

Pre-prepared emergency rate-limit profiles should therefore exist where possible.

For an API normally at:

1,000 requests/minute

a different policy can be engaged during a crisis.

What Is an Emergency WAF Rule?

Some organisations create pre-prepared emergency WAF rules for DDoS or heavy bot attacks.

For example;

a rate limit on a particular endpoint,

a challenge for a particular geography,

a block for a suspicious fingerprint.

All ready to deploy.

But the effects of emergency rules must be known before they go into production.

Otherwise customers are affected more than the attacker.

When Is Challenge Mode Used?

In a layer 7 attack, for particular traffic;

CAPTCHA,

a JavaScript challenge,

browser verification

can be engaged.

This method reduces bot traffic.

But it affects user experience.

Applying it to risky traffic segments rather than to the whole site is therefore more appropriate.

API DDoS Incident Response

In API attacks;

the API gateway,

the WAF,

the application,

the database

must be monitored together.

Rather than simply reducing RPS, the endpoint the attacker is targeting can be temporarily restricted.

Rate limits can also be applied;

per user,

per tenant,

per token.

This method reduces genuine user impact.

DNS DDoS Incident Response

Rapid action is needed in a DNS attack.

Because when DNS becomes unreachable, many different services are affected at once.

The things to check are;

authoritative DNS,

QPS,

latency,

provider status,

secondary DNS,

anycast nodes.

If necessary, a secondary or multi-provider DNS architecture must be engaged.

When Should the ISP Be Contacted?

As early as possible in volumetric attacks.

Coordination with the ISP becomes critical particularly when the attack approaches the capacity of the organisation's link.

The DDoS playbook must already contain;

ISP NOC contact details,

the support ticket method,

an emergency phone number,

the customer ID.

Searching for this information during the attack wastes time.

Coordination with the Anti-DDoS Provider

If a managed anti-DDoS service is in use, an open communication channel with the provider must exist during the attack.

Information such as;

attack type,

target IP,

attack peak,

mitigation status,

false positives

can be shared.

The timeframe within which the provider must respond should also be defined in advance in the SLA.

When Should On-Demand Scrubbing Be Activated?

In the on-demand model, traffic normally arrives at the organisation's own link.

When the attack threshold is exceeded, it is diverted to the scrubbing centre.

The most critical risk here is late activation.

If the link capacity is:

5 Gbps

and the attack is:

20 Gbps

the connection saturates very quickly.

The diversion threshold must therefore be set from real traffic data.

The Incident Response Advantage of Always-On Protection

In the always-on model, because traffic already passes through the protection infrastructure, no separate diversion is needed.

Time to mitigate is therefore lower.

This advantage matters particularly for banking, e-commerce and critical SaaS services.

When Is RTBH Used?

Remotely triggered black hole (RTBH) drops all traffic destined for a particular target at the upstream level.

The attack then does not affect the organisation's other network infrastructure.

But the target service becomes unreachable too.

It should therefore mostly be considered a last resort.

It can be assessed particularly when an attack on a single service threatens the organisation's entire connectivity.

Can Geo-Blocking Be Used in an Emergency?

Yes, in some situations.

If the company serves only Türkiye and 95% of the attack comes from regions where it has no users, temporary geo-filtering can be considered.

But;

VPN users,

employees abroad,

global customers

can be affected.

Coordination with business units is therefore required.

Is Writing Firewall Rules During DDoS Risky?

Yes.

A wrong firewall change made in an emergency can create a bigger outage than the attack.

Production changes must therefore be as far as possible;

approved,

recorded,

reversible.

Having an emergency change management process is useful.

What Is Emergency Change Management?

The standard change process is too slow during a critical incident.

A predefined emergency change procedure can therefore be used.

It defines, for example;

who approves,

which changes may be made,

how rollback is performed.

It matters for WAF, firewall or routing changes during DDoS.

Why Is a Rollback Plan Necessary?

An emergency mitigation rule can produce the wrong result.

A large proportion of genuine users can be blocked, for instance.

For every change, therefore, the question:

How will this be reversed?

must be answered in advance.

Crisis changes without a rollback plan are high risk.

Service Prioritisation During a DDoS Attack

Protecting every service at once may not be possible.

Critical business services must therefore be prioritised.

For example;

the payment API,

login,

the customer portal

can be high priority.

Low-priority services such as the blog or reporting can be temporarily limited.

This approach relates to graceful degradation.

What Is Graceful Degradation?

It is disabling certain secondary functions before the system fails entirely.

During an attack, for example;

the recommendation system is switched off,

expensive search is reduced,

reporting is disabled,

core transaction services are protected.

The aim is to keep critical business functions running.

What Is Load Shedding?

Load shedding is the controlled rejection of low-priority requests while the system is under excessive load.

This method prevents the backend failing entirely.

Some anonymous user requests can be rejected while authenticated customers continue to be served.

When Should Failover Be Used?

If the organisation has;

a secondary data centre,

a second cloud region,

a backup site,

failover can be considered in certain situations.

But if the DDoS attack is targeting the same public endpoint, changing only the backend does not solve the problem.

The failover architecture must suit the attack type.

Does DNS Failover Help During an Attack?

Yes, in some architectures.

But because of DNS TTL values the switch is not instant.

And if DNS itself is under attack, DNS-based failover may not work.

Failover must therefore be tested in advance.

Should Autoscaling Be Used in a DDoS Incident?

Autoscaling helps absorb short-term load increases.

But once an attack is confirmed, simply adding capacity may not be the right strategy.

Because the attacker can keep consuming more resources.

Cost increases follow in cloud environments in particular.

Autoscaling and mitigation must therefore be used together.

Should Cloud Cost Be Monitored During DDoS?

Yes.

In layer 7 or serverless attacks in particular the service can stay up while cloud costs rise sharply.

The incident response dashboard can therefore also carry metrics such as;

instance count,

serverless invocations,

network egress,

cost anomalies.

The SOC's Role in a DDoS Attack

The SOC;

verifies the attack,

correlates logs,

builds the incident timeline,

sets severity,

checks other security events,

escalates to technical teams.

But the SOC does not have to make every network change itself.

Roles must be clearly separated.

The Network Team's Role

The network team can manage the;

routing,

firewall,

BGP,

ISP,

anti-DDoS,

load balancer

side.

It plays a particularly critical role in volumetric and L3/L4 attacks.

The Application Team's Role

In layer 7 attacks the application team analyses the state of;

endpoint performance,

the backend,

the database,

the cache,

rate limiting.

It can disable low-priority features if needed.

The Cloud Team's Role

The cloud team can assess the controls for;

the WAF,

the load balancer,

autoscaling,

the API gateway,

regional health,

cloud-native DDoS.

It must also monitor the cost impact.

Management's Role

Management's job is not to analyse technical packets.

Management must assess;

business impact,

customer impact,

financial risk,

communication needs.

The technical team must feed management with short, clear information.

What Information Does Management Want During a DDoS Attack?

A format like this is useful:

Attack started: 14:02

Affected service: customer portal

User impact: 12% timeouts

Mitigation started: 14:04

Current status: stable

Estimated business impact: low/medium

This information is far more valuable to management than:

“An 18 million PPS SYN/ACK anomaly.”

When Should Corporate Communications Get Involved?

If there is prolonged customer impact, the communications team can get involved.

Channels such as;

a web status page,

customer notification,

a social media statement

can be used.

But statements must contain verified information.

Unverified attribution about the attacker must not be made.

Why Does a Status Page Matter During DDoS?

If the main web platform is unreachable, customers cannot get information.

Through an independent status page;

service status,

incident updates,

recovery

information can be shared.

It is useful that the status page does not depend on the same infrastructure.

Is the Legal Team Needed in a DDoS Incident?

Depending on the scope, yes.

The legal team can be brought in particularly where there are issues of;

extortion,

ransom DDoS,

customer impact,

contractual SLA,

regulation.

What Is Ransom DDoS?

Ransom DDoS (RDoS) is the attacker demanding payment through a DDoS threat or attack.

The attacker sometimes carries out a short attack to demonstrate their capacity.

They then send a threat of a larger attack.

Technical preparation, legal and crisis management must be handled together in that situation.

Should a DDoS Ransom Be Paid?

Decisions of this kind must not be made by the technical team alone.

They can have legal, financial, sanctions and operational dimensions.

They must be assessed through corporate crisis management and the relevant professional advisory processes.

The technical team should focus mainly on protecting the system and verifying the attack.

Should Other Attacks Be Checked During DDoS?

Absolutely.

DDoS can be used to hide other activity.

In the same period the SOC must check whether there are;

suspicious logins,

malware alerts,

privileged activity,

data transfers,

WAF exploit attempts.

This approach helps understand whether the incident is part of a broader attack.

Should the Incident Be Closed as Soon as the DDoS Ends?

No.

The incident must not be considered complete simply because traffic returned to normal.

First;

service health,

backlogs,

the database,

the cache,

autoscaling,

security events

must be checked.

Some systems remain unstable for minutes or hours after the attack.

What Is the Recovery Phase?

Recovery is the safe return of the system to normal operation after mitigation.

At this stage;

temporary firewall rules,

rate limits,

challenges,

routing changes

are reviewed.

Emergency controls must be assessed before becoming permanent.

Can There Be Cache Problems After DDoS?

Yes.

A heavy attack can have changed the cache structure or lowered the cache hit ratio.

During recovery;

cache warming,

origin load,

application response

can be monitored.

Clearing the whole cache at once creates a second load wave on the origin.

When Should Autoscaling Be Scaled Back Down?

Hundreds of extra instances may have opened after a cloud attack.

If scale-down happens too fast, a capacity problem can recur with genuine user traffic.

If it happens too late, unnecessary cost accrues.

Recovery must therefore be carried out under control.

What Should Be Done with Temporary Mitigation Rules?

During the attack, temporary measures such as;

geo-blocks,

rate limits,

WAF rules,

firewall ACLs

may have been applied.

After the incident these must be assessed one by one.

Unnecessary ones must be removed.

Otherwise they cause user access problems months later.

What Is a Post-Incident Review?

A post-incident review (PIR) is the systematic analysis of the incident after the attack ends.

The aim is not to find someone to blame.

The aim is to answer these questions:

What happened?

When did we notice?

What worked?

What did not work?

Where did we lose time?

What will we change for the next attack?

This process improves DDoS resilience.

Is Root Cause Analysis Used for DDoS?

The “root cause” of a DDoS attack is an external attacker.

But from the organisation's perspective, root cause analysis focuses on different questions.

For example:

Why did the service fail at 2 Gbps?

Why did anti-DDoS engage late?

Why did the SOC not see the alert?

Why was the origin IP exposed?

These questions reveal the real improvement areas.

How Are Lessons Learned Produced?

At the end of the incident, conclusions like these can emerge:

Anti-DDoS worked correctly.

But the SOC received the notification late.

The ISP contact details were out of date.

API rate limiting was missing.

Management communication was successful.

These outputs must be turned into an action plan.

Why Does Action Item Tracking Matter?

One of the most common mistakes is holding a post-incident meeting and shelving the report.

For every finding;

an owner,

a target date,

a priority,

a status

must be set.

For example:

Close origin IP – network – critical – 7 days

and so on.

What Are the DDoS Incident Metrics?

The important measurable metrics are:

Time to Detect (TTD)

Mean Time to Acknowledge (MTTA)

Time to Mitigate (TTM)

Recovery Time

Attack Peak

Legitimate Traffic Success Rate

Service Availability

Customer Impact Duration

These metrics can be compared from attack to attack.

Why Does Customer Impact Duration Matter?

The technical team may have detected the attack within 2 minutes.

But if customers could not reach the service for 40 minutes, incident response still needs improving.

Business impact must therefore always be measured at the end of the security metric.

What Should a DDoS Incident Report Look Like?

A professional incident report can contain these sections:

Executive Summary

The management summary of the incident.

Incident Timeline

The chronological flow.

Attack Characteristics

Gbps, PPS, CPS, RPS, QPS.

Affected Services

The systems affected.

Mitigation Actions

The measures applied.

Business Impact

Customer and service impact.

Detection Analysis

Which systems raised alerts.

Communication Timeline

Who was informed when.

Lessons Learned

The conclusions drawn.

Remediation Plan

Improvement actions.

Should DDoS Incident Response Be Tested?

Yes.

Having a playbook is not enough.

An exercise must be run.

During a controlled DDoS attack simulation, for example;

the SOC sees the alert,

network teams respond,

the provider is informed,

the war room opens,

a management update is sent.

Both the technical infrastructure and the process are thereby tested at once.

What Is a Tabletop Exercise?

A tabletop exercise is a drill in which teams test their decision processes through a scenario without generating real attack traffic.

The moderator says, for example:

“At 10:05 a 50 Gbps attack began against internet banking.”

The teams then describe;

who they would call,

which system they would check,

which decision they would make.

This method is particularly useful for testing management and crisis communication processes.

Can a Technical DDoS Test and a Tabletop Be Run Together?

Yes, and it is extremely valuable.

The technical team runs a real controlled traffic simulation.

At the same time the incident response team manages it like a real incident.

That way;

technology + people + process

are verified together.

This is far closer to genuine cyber resilience.

How Often Should DDoS Incident Response Be Tested?

It varies with the organisation's risk level.

But retesting is useful after;

a new anti-DDoS service,

an ISP change,

a cloud migration,

a major application change,

an organisational change.

Critical organisations can also run periodic DDoS exercises.

What Happens if the DDoS Playbook Is Not Kept Up to Date?

Incident response documents go stale very quickly.

Staff leave.

Phone numbers change.

The ISP changes.

A new cloud provider arrives.

The application architecture changes.

The playbook must therefore be reviewed regularly.

Emergency contact details in particular must be kept continuously current.

The Biggest Mistakes in DDoS Incident Response

The most common mistakes include;

blocking without understanding the attack type,

contacting the ISP too late,

looking at bandwidth alone,

not measuring genuine user impact,

applying overly aggressive WAF rules,

neglecting management communication,

not removing temporary rules after the attack,

not carrying out a post-incident review.

Most of these are process problems, not technology problems.

DDoS Incident Response and Cyber Resilience

Preventing a DDoS attack entirely is not always possible.

But if under attack the organisation;

can sustain the service,

can limit the impact,

responds quickly,

recovers quickly,

it has high cyber resilience.

DDoS incident response is therefore one of the most concrete applications of cyber resilience.

Conclusion: During a DDoS Attack the Most Valuable Resource Is Time

When a DDoS attack begins, the organisation has no time to design a new process.

Who is called.

Which alert is verified.

When anti-DDoS is engaged.

How the ISP is reached.

Which WAF policy is applied.

How management is informed.

All of it must have been thought through in advance.

A strong DDoS incident response approach rests on this structure:

Detect

↓

Validate

↓

Classify

↓

Mitigate

↓

Communicate

↓

Recover

↓

Improve

Technology matters greatly here.

But it is not enough on its own.

The organisations that succeed during DDoS are generally not those with the strongest anti-DDoS platform;

they are the ones that prepared technology, people and process together.

Real resilience can therefore only be verified through exercise.

And that brings us to the final stage of the series.

An organisation must not be content with buying a product and preparing a playbook against DDoS.

It must test the entire defensive chain in a controlled way, report the results and re-verify them regularly.