Any company that relies on technology to operate—and today, that means practically all of them—is susceptible to some form of security incident: ransomware attacks, data breaches, unauthorized access to critical systems, or infrastructure downtime.
The question is not whether it will happen, but what the company does in the first few minutes after it occurs. This is precisely where having an incident response plan distinguishes organizations that contain the damage from those that inadvertently exacerbate the loss.
What is an incident response plan?
An incident response plan is a structured document that defines, in advance, how a company should act when a security event compromises its systems, data, or operations. It establishes who does what, in what order, using which tools, and within what timeframe.
Without such a document, the response relies on the memory, availability, and judgment of whoever happens to be present when the incident occurs. There is a less technical name for this: improvisation. And improvisation during a crisis comes at a measurable cost—whether in terms of downtime, data loss, regulatory penalties, or reputational damage among customers and partners.
Why improvisation comes at a high cost
When an incident occurs without an active plan in place, certain patterns repeat with disturbing frequency. The technical team addresses symptoms without isolating the root cause. Systems are shut down indiscriminately, erasing evidence that would be essential for a subsequent investigation. Internal communication becomes fragmented, with different departments receiving contradictory information. No one knows for sure whether the LGPD requires notification, whom to notify, or the applicable deadlines.
Every hour without a coordinated response is an hour during which the incident deepens, data becomes more exposed, and the window for containment closes. As the article on IT failures and operational shutdowns illustrates, the effects of an unplanned outage are immediate and ripple across all areas of the business, extending far beyond the technical department.
The cost of improvisation also becomes apparent in the aftermath of the incident. Companies that failed to document their response steps struggle to demonstrate compliance during audits, prove adherence to LGPD-mandated procedures, or provide evidence to insurers and business partners.
What an incident response plan needs to include
A functional incident response plan does not need to be a document spanning hundreds of pages. It must be clear enough for someone under pressure to follow without ambiguity. Essential elements include:
Incident classification. Not every event carries the same level of severity. The plan must define objective criteria to distinguish a routine alert from a genuine incident and, among incidents, identify those requiring an immediate response.
Roles and responsibilities. Who leads the technical response? Who notifies senior management? Who handles external communications? Who decides whether to shut down systems? Include names, job titles, and backup contacts for when the primary person is unavailable.
Containment procedures. Specific steps to isolate the compromised environment without destroying evidence. This includes which systems to shut down, which to keep running, and how to preserve logs for subsequent forensic analysis.
Communication protocol. Clients, vendors, partners, authorities, and the internal team require distinct messages at different times. Poorly communicated incidents trigger secondary crises, while a lack of communication breeds distrust that is difficult to overcome.
ANPD notification criteria. The LGPD requires that incidents involving personal data be reported to the National Data Protection Authority (ANPD) within a specific timeframe after the event is discovered. Without a pre-established protocol, this window often closes before an internal consensus on what occurred is reached.
Recovery procedures. Following containment, the order of priority for resuming operations must be defined. Which processes come back online first? Which backup should be used? What integrity checks are required before bringing the environment back into operation?
The continuity plan does not replace the response plan.
It is common for companies to confuse the two documents or believe that one replaces the other. It does not.
The business continuity plan defines how the company maintains its essential operations during a prolonged crisis—it operates on a timeframe of weeks and months. The incident response plan addresses the initial minutes and hours: it contains the situation, preserves evidence, coordinates communication, and paves the way for recovery.
The two plans complement each other and must be synchronized, yet they answer different questions.
A company that has only a continuity plan knows how to survive a crisis. Without a response plan, however, it reaches the survival phase only after having exacerbated the damage during the acute phase of the incident.
Why plans that exist on paper don’t work in practice
Many organizations have a document called an “incident response plan” sitting in some network folder. The problem lies in how much time has passed since it was last tested—or if it ever was.
An untested plan is merely a hypothesis. When a crisis hits, the team discovers that contact details are outdated, procedures describe systems replaced two years ago, and none of the designated individuals remember being assigned that role.
This pattern ties directly into the points raised in the article about determining whether your infrastructure can withstand an incident: environments that have never undergone real-world stress testing reveal their weaknesses at the worst possible moment. The same applies to the plans designed to protect them.
Testing an incident response plan involves simulating a real-world scenario, activating the responsible parties, walking through the procedures, and identifying where the process breaks down before a real attack exposes those flaws. This type of simulation is technically known as a “tabletop exercise,” and it should be part of the schedule for any company that takes security seriously.
The right time to put the plan together has already passed. The second-best time is now.
Companies that lack a structured incident response plan often find themselves in this position due to a combination of two factors: the perception that "it won't happen to us" and the feeling that creating such a plan is too complex a project to fit into their schedule.
The first factor is the same one analyzed in detail in the article on the false sense of security: the absence of prior incidents is not evidence of protection; rather, it indicates that no recorded attempt has succeeded so far.
The second factor has a more straightforward solution. An incident response plan does not need to be fully formed from the start. It can begin with the most critical elements—clear responsibilities, classification criteria, and communication protocols—and evolve through periodic reviews, following the same information security risk management logic where every decision has an owner and a review deadline. What cannot be remedied is attempting to create the plan only after an incident has already begun.
