Key Points

1 An Incident Response Plan (IRP) is the framework that enables an organisation to make decisions and act quickly under pressure when a security or continuity incident occurs.
2 According to the IBM Cost of a Data Breach Report 2025, the global average cost of a breach reached USD 4.44 million in 2025 and the average time to identify and contain it was 241 days.
3 In Spain, INCIBE handled 122,223 cybersecurity incidents in 2025, 26% more than the previous year.
4 A useful IRP is an operational capability built on clear command, pre-authorised actions and proportionate escalation.

An Incident Response Plan (IRP) is the operating framework that defines who decides, which actions are pre-authorised and how a security or business continuity crisis is escalated. Its function is not documentary but executive: to reduce uncertainty and enable action under pressure in the first 60 minutes. Under NIS2, its existence and periodic testing are mandatory for essential entities in the EU.

“In a crisis, governance cannot be improvised: if it is not defined who decides, how action is taken and when escalation occurs, the organisation loses critical time,” explains Montserrat Recio, Senior Cybersecurity Technician at RibéSalat and guest voice on the ‘Historias Aseguradas’ podcast by SegurosNews, where she explores how companies can build a real culture of prevention against today’s cyber risks without losing operational agility.

The difference between an IRP that merely complies and an IRP that truly works lies in its purpose: reducing uncertainty, protecting business continuity and preventing an operational issue from becoming a full-blown crisis because of poor coordination. This matters more than ever: the average cost of a breach in the United States reached USD 10.22 million in 2025, according to IBM’s annual cost of breaches report, and organisations that apply AI and automation extensively in incident response save an average of USD 1.9 million per breach and reduce the incident life cycle by 80 days.

Why an IRP can no longer be just about compliance

An incident response plan focused solely on compliance is a document that passes an audit but fails under pressure: either it is so exhaustive that no one consults it during a crisis, or so generic that it does not enable real decisions. The operational value of an IRP appears when it simplifies: it sets priorities, coordinates teams and enables fast action without losing traceability.

Put differently, the IRP is a key piece of operational resilience. It does not replace prevention, but it defines what happens when prevention is not enough. That is the difference between a controlled interruption and cumulative damage: downtime, contractual impact, reputational loss and tensions with clients or partners. The regulatory context reinforces this logic: the European Union’s NIS2 Directive, whose full transposition in Spain is expected during 2026, requires strict notification timelines for significant incidents: early warning within 24 hours, an intermediate report within 72 hours and a final report within 1 month, with fines of up to EUR 10 million or 2% of global turnover for essential entities that fail to comply.

“From our experience, many organisations do not fail because of a lack of technology, but because they lack a decision-making framework that can be applied in the first 60 minutes,” notes the technical response team at Alpine Security.

What an IRP is and what it must resolve in a real crisis

A useful incident response plan is one that, in the face of a real crisis, allows the organisation to answer five operational questions clearly. It is not measured by how well it describes technical tasks, but by its ability to cover the different types of cyber risk that companies face. An IRP should contain the following sections:

  • Introduction and purpose: defines the plan’s scope, objectives and regulatory requirements.
  • Roles and responsibilities: describes the incident response team, contacts and chain of command, for example: Incident Manager, legal, communication/PR.
  • Definition of events and incidents: classifies severity levels, for example low or critical, to ensure appropriate escalation.
  • Preparation: includes policies for risk assessments, training, system hardening and tool readiness.
  • Detection and analysis: identification of the threat, confirmation of its legitimacy and impact analysis.
  • Containment, eradication and recovery: steps to isolate the threat, remove the root cause and restore systems.
  • Post-incident / lessons learned: a blameless post-mortem analysis to prevent future incidents.

In some cases, each section also includes a set of questions that the plan should be able to answer. The IRP must move difficult discussions into the preparation phase: a crisis is not the time to debate from scratch whether to isolate a system, disconnect a service or activate an alternative plan. This logic is consistent with the NIST incident response framework (SP 800-61 Revision 3, published in April 2025), which reorganises the life cycle around continuous risk management rather than treating response as an isolated event.

The most common mistake: information without authority (or authority without a framework)

The misalignment between information and authority is one of the most frequent failures when activating an incident response plan: either the technical team identifies the issue but lacks the authority to execute strong measures, or management has authority but no clear framework for making sound decisions. In both scenarios, critical time is lost and the incident’s impact grows unnecessarily.

“An effective IRP prevents that gap: it pre-agrees who decides and which levers they can activate without delays caused by coordination across different functions and levels,” Montserrat summarises.

The IRP as a blueprint for pre-agreed decisions

A strategic incident response plan rests on three operational components that must be defined before any crisis: clear command, pre-authorised actions and proportionate escalation. These three decisions, made calmly during the preparation phase, are what distinguish an orderly response from costly improvisation.

incident response plan

Clear command and decision chain

Clear command means designating in advance one person with final decision-making authority during an incident (plus a deputy), and explicitly defining how that person coordinates with IT/Security, Legal, Communication, Business and, where relevant, external providers. In an incident, a defined command structure acts as a control measure: it removes ambiguity about who decides and shortens the time between detection and action.

This does not mean centralising execution, but eliminating ambiguity. The crisis team should coordinate facts, validate decisions and escalate when needed; it should not reopen basic discussions about roles and responsibilities.

Pre-authorised actions: decide early to act on time

Pre-authorised actions are containment measures—isolating systems, disconnecting services, blocking access, activating alternative environments or suspending third-party integrations—whose execution is approved in advance under criteria defined in the incident response plan. The operational key is that they are pre-approved under specific conditions: if they are debated in the heat of the moment, organisations tend to delay them and the containment window closes.

“Unpopular decisions—for example, stopping a critical service to contain an incident—are only viable if the framework has been agreed in advance. In the heat of the moment, organisations tend to delay them,” warns the technical team.

Proportionate escalation and severity criteria

Proportionate escalation is the system of criteria that classifies each incident by severity and assigns a differentiated level of response, avoiding both overreaction (which drains resources) and underreaction (which allows damage to grow). Not all incidents require the same response: an isolated endpoint after a malware alert does not require the same reaction as a confirmed exfiltration with multi-country impact. The different types of cyberattacks affect the business in very different ways—from spyware operating in the background to advanced persistent threats (APTs) that can remain undetected for months—and a mature IRP establishes explicit severity criteria for each one.

SeverityTypical examplesDecision-makerPre-authorised actionsMinimum escalation
Lowcontained alert, isolated endpointTechnical leadisolate device, block credentialsIT/Sec
Mediumimpact on a non-critical serviceIncident leadsegmentation, blocking, intensified monitoringIT + affected business
Highsignificant unavailability / sensitive data at riskCrisis leadershipcontrolled disconnection, activation of alternative environmentsManagement + Legal + Communication
Criticalconfirmed exfiltration / multi-country impact / critical third partyCrisis committeeextraordinary measures and external coordinationManagement + Legal + Communication + Insurance

This table is an illustrative model and should be adapted to each company’s operational reality (assets, digital dependency, regulation, providers, etc.).

An operational IRP: brief, accessible and executable under pressure

An operational incident response plan combines technical rigour with clarity of execution: concise, accessible documentation designed to be activated under pressure without spending critical time on consultation. A plan can be technically correct and still fail in the real world if its length, language or structure make it unusable in the first 60 minutes. Organisations with mature documented procedures reduce mean time to respond (MTTR) by up to 40% compared with those that act ad hoc, according to NIST SP 800-61r3 guidance.

How to avoid paralysis by committee

Paralysis by committee is the operational dysfunction that appears when too many actors are involved in incident response without a predefined framework of roles, responsibilities and escalation thresholds. To avoid it, the IRP must set in advance which decisions are taken at each level, so that the crisis team coordinates execution rather than debating first principles each time.

“An effective crisis team is not the one that gathers the most people, but the one that brings together the right functions with clear criteria and traceability from minute one,” notes Montserrat.

Minimum documentation from minute 1 (for control and traceability)

Minimum documentation from minute 1 is the discipline of continuous recording that must run in parallel to incident containment: what is decided, who decides it, when and why. It is not bureaucracy, but the raw material for three critical dimensions—control, learning and defensibility—which become especially important when regulators, insurers and clients request formal evidence after an incident.

Incident response plan

Executive checklist (first 2 hours)

  • Incident declaration (yes/no) and assigned severity.
  • Responsible decision-maker and secure coordination channel.
  • Actions executed (what, when, by whom).
  • Affected systems/services and critical dependencies.
  • Evidence preserved and basic chain of custody.
  • Key internal messages (what is known / what is not known).
  • Need for third parties (forensics, legal, communication, partner).

Beyond IT: reputational, contractual and financial impact

The real impact of a security incident unfolds across four simultaneous dimensions: financial loss, theft of confidential information, business interruption and reputational damage. Treating it as an exclusively technical problem remains one of the most persistent mistakes, because cyber risk affects the company across these four dimensions at the same time from the very first minute. The IBM Cost of a Data Breach Report 2025 confirms this: 31% of affected organisations suffered operational disruption and the healthcare sector continues to record the highest average cost per breach—USD 7.42 million—for the fifteenth consecutive year. That is why a mature incident response plan must take a cross-functional view from the start, including business, communication, legal and insurance.

Crisis communication: protecting trust and reducing uncertainty

Crisis communication is the set of internal and external information actions that an organisation activates to protect stakeholder trust and reduce uncertainty during an incident. It does not start when “everything is clear”—that moment rarely arrives—but when the organisation needs to prevent internal rumours, prepare consistent messages for clients and suppliers, and protect relationships with key stakeholders.

A good practice is to separate:

  • confirmed facts
  • hypotheses under investigation
  • actions in progress
  • next scheduled update (without promising outcomes)

“Communicating early does not mean communicating more: it means communicating better, within a framework that reduces uncertainty and preserves trust,” notes the technical team.

Coordination with insurance: orderly and well-documented response

Coordination with the insurer within the incident response plan is the set of procedures that allows the cyber policy to be activated in an orderly and traceable way from the onset of the incident. Its role goes beyond financial cover: a documented response carried out with discipline reduces friction during claims handling, accelerates the activation of services included in the policy (forensics, legal, communication) and strengthens traceability vis-à-vis third parties. This is especially relevant in a context where ransomware remains the threat with the highest economic impact per incident: according to IBM, the average cost of an extortion or ransomware incident reached USD 5.08 million in 2025.

In addition, a tested and documented IRP acts as evidence of due diligence: it shows that the organisation did not merely “have a plan”, but knew how to apply it reasonably and proportionately.

“In an incident, documentation is not an ‘extra’: it is what allows decisions to be defended before clients, regulators and insurers, and turns learning into real improvement,” explains the RibéSalat specialist.

Test, learn and improve: the IRP as a living document

An effective incident response plan is a living document: it is updated after every exercise and every real incident to capture lessons learned, refine severity criteria and continuously improve response capacity. NIST recommends reviewing and updating it at least annually, or more frequently if the threat landscape, technology stack or business environment changes (new critical suppliers, mergers, international expansion).

incident response plan

Exercises and scenarios: validating scalability

Simulation exercises—also known as tabletop exercises or cyber drills—are controlled tests in which the team executes the incident response plan against hypothetical scenarios in order to validate scalability and detect weaknesses before a real incident occurs. Their greatest contribution is confirming that everyone involved knows the procedures and associated documentation, and clearly understands their role within the IRP. They also show whether the plan remains valid under different circumstances: prolonged unavailability, data leakage, a third-party incident or simultaneous impact across several countries. Practising reduces improvisation and improves real coordination across functions.

Lessons learned: turning every incident into an opportunity

The lessons learned phase is the post-incident exercise that consolidates organisational knowledge by answering four questions: what worked, what failed, which dependencies proved critical, and whether those responsible understood their role. Each review makes it possible to adjust severity criteria, operational dependencies and pre-authorised decisions—a process that the ENISA incident management guidelines identify as a structural element of the response cycle.

Practical recommendations to turn your IRP into a useful tool

Turning an incident response plan into a useful tool—and not merely a compliance document—requires action across five levers that have consistently shown the strongest operational impact. Based on the complementary experience of RibéSalat and Alpine Security, they can be summarised as follows:

  • Give the IRP a strategic focus: it should support business continuity, not merely satisfy regulatory demands.
  • Define clear responsibilities: know who decides, how escalation works and which measures can be activated without delay.
  • Keep the plan brief and operational: in a crisis, usefulness depends on clarity and execution.
  • Integrate communication and insurance: address reputation, traceability and third-party coordination from the outset.
  • Test and update the plan: exercises and periodic reviews validate that it works in practice.

In short, the clearer the decisions are before the incident, the faster and more orderly the response will be when it happens. A good IRP does not eliminate uncertainty, but it reduces improvisation and strengthens the organisation’s ability to respond with judgement, traceability and agility. If your organisation is reviewing its response capability or adapting to NIS2, DORA or other regulatory frameworks, the RibéSalat cybersecurity and cyber insurance team can support you in designing, testing and operating your IRP.

FAQs

What exactly is an Incident Response Plan (IRP)?
An Incident Response Plan (IRP) is the framework that enables the organisation to detect, coordinate and respond to a security incident in an orderly manner. Its objective is not to “document tasks”, but to ensure that, under pressure, there is clarity about who decides, which actions are allowed and how traceability is preserved. Standards such as NIST SP 800-61r3, ISO/IEC 27035 and ENISA guidance regard it as a structural component of cyber risk management.
Who should participate in the IRP within a company?
In addition to IT/Security, an effective IRP includes business functions that directly affect the outcome: management, legal, communication and—where relevant—coordination with third parties. The key is to define roles and thresholds: this is not about “adding more people”, but about having predefined escalation criteria. Under NIS2, responsibility also falls directly on the management body, which must approve and supervise risk-management measures.
How is an IRP different from a Business Continuity Plan?
The IRP organises the immediate response to contain, eradicate and recover after an incident; the Business Continuity Plan (BCP) focuses on maintaining operations and restoring business functions when there is disruption. In practice, they must be coordinated, but they are not the same: the IRP is the tactical response to the event, while the BCP is the strategy for operational resilience.
How often should an IRP be reviewed and tested?
A useful IRP is a living document: it should be reviewed after exercises and incidents to incorporate learning. NIST recommends reviewing and updating it at least annually, or more frequently if technologies, providers, critical processes or organisational structures change. It is also advisable to establish a periodic cadence of cyber exercises (tabletop, red team, crisis simulation) to validate that the plan works in practice.
What should be decided before an incident occurs?
At least three elements: clear command, pre-authorised actions (for example, isolating or disconnecting under certain criteria) and a proportionate escalation scheme by severity. These prior decisions help avoid critical delays and reduce improvisation. This pre-approval logic is consistent with NIST SP 800-61 Rev. 3 guidance and with the practices recommended by ENISA for entities subject to NIS2.
Why is it important to include crisis communication in the IRP?
Because an incident’s impact is not only technical. Managing expectations, ensuring message consistency and protecting the trust of clients and stakeholders are all part of the response. Integrating communication from the outset helps avoid delayed or contradictory reactions. Under NIS2, inadequate or late notification can also lead to fines of up to EUR 10 million or 2% of annual global turnover for essential entities.
What is gained by integrating insurance coordination into the IRP?
It brings order and traceability: it facilitates a well-documented response, reduces friction with third parties and strengthens the organisation’s ability to demonstrate due diligence. In complex incidents, that discipline can be as important as technical containment—and it has a direct impact on the management of the cyber insurance policy, claims timelines and effective coverage. With average incident costs of USD 4.44 million globally and USD 5.08 million in ransomware cases, according to IBM’s 2025 report, coordination with the insurer is no longer an administrative detail but a strategic component of the IRP.
How does NIS2 affect the design of an Incident Response Plan in Spain?
The NIS2 Directive—pending full transposition in Spain, expected throughout 2026—requires essential and important entities to have real incident-management capabilities and to notify competent authorities within strict timeframes: early warning within 24 hours, an intermediate report within 72 hours and a final report within 1 month. Management bodies assume personal responsibility. An IRP aligned with NIS2 must therefore include, in addition to the technical component, governance, board training and documentary traceability.
Contact our specialists
Let's talk about your needs.