I begin this article with an uncomfortable truth: assuming that a company can avoid any security incident is unrealistic. Attack surfaces are constantly growing, environments are becoming more complex and cyberattacks more difficult to detect.
Therefore, the challenge in cybersecurity is no longer just to prevent, but to be prepared to respond when it happens. Because in a cybersecurity crisis, the impact is not defined by the attack itself, but by how it is managed during the first hours. Let’s take a look.
Imagine that one Saturday morning, the SOC team detects suspicious activity on a server. Nothing particularly alarming at first, but within minutes there are signs of unauthorized access. It is not yet clear whether information has been stolen, but the risk is there.
As the investigation progresses, questions begin to arise that go beyond the IT team: Do we stop the affected server and assume the operational impact? Do we wait until we have more information with the risk of the attacker moving forward? Do policies, such as NIS2, require us to notify the appropriate authorities? What do we communicate, and when?
It is at this point that it ceases to be just a security incident and becomes a business decision.
Therefore, from our experience in Softeng managing incidents in medium and large companies, we have extracted three lessons that often make the difference between a controlled incident and one that generates a crisis with business impact.
1. The business context is key to making decisions in the event of a security breach.
Returning to the previous scenario, the SOC service has confirmed the unauthorized access, although the situation is now under control: it has been detected quickly and the corresponding response measures have been implemented.
But detecting unauthorized access is not enough to understand the impact it can have on the business.
In effective crisis management, the following more strategic questions must be answered:
- Which critical processes depend on the affected systems?
- Is there an obligation to notify the competent authorities if we are subject to GDPR, NIS2 or DORA regulations?
- What could be the reputational impact if the breach becomes public?
At this point, no further technical information is needed. Business context is missing.
And without that context, decision making becomes complicated: either you overreact and stop systems unnecessarily, or you underestimate the risk and give the attacker room for maneuver.
That’s why managing a security crisis well is not just about detection. It is being able to connect, almost in real time, what is happening at the technical level with its impact on the business.
When that connection exists, the organization can prioritize judiciously. And in a crisis, that’s what really limits the impact.
2. The speed is not set by the attacker, it is set by your decision-making capacity.
Continuing with the example, while the SOC team continues to investigate, the attack does not stop.
Today, with attackers using AI to be much faster and more effective, time is against them. We see it all the time: recognition of the entire internal network in minutes, persistence in hours, and theft of sensitive information before there is full visibility.
Meanwhile, within the organization, another type of complexity begins. IT, legal, communication and management teams have to be coordinated to make non-trivial decisions together:
Is a production environment isolated? Is a critical operation stopped? Are the relevant authorities notified? Are customers informed?
And therein lies the real problem: the time that elapses between detecting and deciding.
Many organizations detect the incident well, but take too long to act. And that delay is, in many cases, what amplifies the impact.
The organizations that respond best are not necessarily those that have the most technology, but those that have reduced that decision time. Because they have already defined who decides what, when and with what criteria.
3. Crisis plans that are not trained fail when they are most needed.
Here is an idea that summarizes very well what happens in these cases: “The more you sweat in training, the less you bleed in combat.”
Almost every organization has some kind of incident response plan, but every day we see that very few have tested whether it actually works under pressure.
The difference is quickly noticed when a real incident occurs. In untrained organizations, very clear situations arise:
- Doubts about who has the authority to shut down systems.
- Blockage in decision making due to lack of shared information.
- Delays in notification due to doubts about legal issues.
- Inconsistent messages to customers or employees.
- Excessive dependence on suppliers without clear coordination.
In contrast, organizations that have previously worked through these scenarios operate very differently. For example, one way to do this is through TTX-type exercises, where a real crisis is simulated, such as a ransomware or data leak, and teams must make decisions in real time as if the incident were occurring, without executing technical actions.
This type of exercise makes it possible to detect failures that do not appear in a document: coordination problems, poorly defined roles or decisions that are blocked at the critical moment.
The most mature organizations have already gone through this process: they have tested their plans, involved management and aligned all teams, including suppliers.
That generates something that cannot be improvised on the day of a real incident: trust.
Going back to that Saturday morning, it all started with an early detection by the SOC team. That first alert was key to narrowing the scope of the incident from the outset.
But from then on, what happened next made all the difference.
If the organization was able to understand the real impact, make decisions quickly and act with coordination, that incident was probably contained. If not, that’s where it started to escalate.
Because in cybersecurity, as important as detecting is knowing how to respond. And this ability is not improvised, it is worked on beforehand.