The biggest failure I have seen during a security incident was not technology.

The company had everything:

  • monitoring,
  • a firewall,
  • backups,
  • an IT team.

It looked secure.

And then the incident came.

The first thirty minutes looked like this:

  • IT was trying to understand what was happening,
  • management was waiting for information,
  • nobody wanted to make the decision.

The biggest problem?

Not the attack.

Hesitation.

Nobody knew:

  • whether to stop the system,
  • who had the final authority,
  • what level of impact was acceptable.

So everyone waited.

The decision came too late

Eventually, a decision was made.

They paid.

The attack was “solved”.

At least that is what they thought.

A few days later, another demand arrived.

They paid again.

This time, to prevent the data from being published.

The data was published anyway.

Then came the third message.

Not a demand for money.

A demonstration that the attackers could get back into the system again.

This is not exceptional

This is not an exceptional story.

This is reality.

The hard truth is simple:

When you do not control the incident, you are not in a situation where you are negotiating.

You are in a situation where you are losing.

That does not mean every decision is easy. Incident response is difficult because information is incomplete, pressure is high and every option has a cost.

But that is exactly why decision-making must be prepared before the incident.

Not during it.

Most incidents do not start as disasters

Most incidents are not disasters at the beginning.

They become disasters because of how the company reacts.

The first technical problem may be serious, but manageable.

The organizational problem can make it much worse:

  • nobody owns the decision,
  • escalation is unclear,
  • communication is slow,
  • recovery is improvised,
  • evidence is lost,
  • the attacker controls the timeline.

At that point, the company is no longer managing the incident.

It is being managed by the incident.

Tools are not enough

Monitoring can tell you something is wrong.

A firewall can block some paths.

Backups can support recovery.

An IT team can investigate.

But none of that automatically answers the management questions:

  • Do we shut down production?
  • Do we isolate systems?
  • Who talks to management?
  • Who talks to customers?
  • Who talks to legal?
  • Who decides whether to restore or preserve evidence?
  • What is the acceptable business impact?

If those questions are not answered before the crisis, the company will try to answer them under pressure.

That is rarely the best moment.

Control is the real objective

The goal of incident response is not only to remove the attacker.

The goal is to regain control.

Control over decisions.

Control over communication.

Control over evidence.

Control over recovery.

Control over the timeline.

Without that control, every attacker demand creates a new crisis.

And every delayed decision gives the attacker more influence.

The question

If this happened in your company today, who would decide?

Would you control the incident?

Or would the attacker control you?