How to Build an Incident Response Plan (IRP) : Ultimate FAQ
- JS Gervais
- Oct 27
- 29 min read
From Preparation to Action
In this series we covered the team, the BCP, and the DRP.
This article covers the Incident Response Plan (IRP) : where strategy turns into action.
Prefer a head start? Ready-made IRP from our trusted partner ⭷ An Incident Response Plan is not a cybersecurity document: it is a business continuity instrument expressed through a security lens. The IRP is where strategy becomes action. It defines how your organization detects, reacts, contains, and communicates during a cyber incident. When it is written and executed properly, it brings structure to chaos, clarity to decision-making, and confidence to leadership.
But what is an incident?
The word "incident" is one of the most overused and misunderstood terms in cybersecurity. Its meaning shifts depending on the framework, the industry, and the audience.
For example, ITIL uses incident to describe any unplanned interruption to a service or degradation in its quality. In that context, even a failed printer or a slow ERP module may qualify as an incident.
By contrast, NIST, ISO/IEC 27035, and FIRST CSIRT Services Framework take a more security-focused approach, where the term refers specifically to events that threaten the confidentiality, integrity, or availability of information systems.
We align with this latter interpretation, as it best serves the context of cybersecurity governance and response:
An incident is any situation that causes, or has a high likelihood of causing, a negative impact on one or more of the core cybersecurity pillars: Confidentiality, Integrity, or Availability (the CIA triad). Privacy is considered a component of confidentiality.
A FAQ for 20 Years of Fight Exposure
Below we share lessons learned the hard way in real crises, across organizations of every size, various verticals, public and private. This knowledge belongs equally in boardrooms, classrooms, and on the operations floor where cyber incidents are fought every day.
This article is not about theory. It is about what actually works when a real incident unfolds, when minutes count, people panic, and leadership needs answers fast.
Frameworks like ISO 27035, NIST SP 800-61, the NIST CSF, ITIL Major Incident, and FIRST CSIRT services all bring value, but none fully capture the pressure of the first 72 hours or the human dynamics that determine success or failure. That is where field experience takes you to the next level.
These lessons and pieces of advice may seem obvious at first read, but implementing them within an enterprise governance program and under pressure requires serious work. So we suggest to use this guidance as a template. Adapt it to your context step by step. There are no two identical organizations, with various ways of doing things and cultures. Think critically, document your decisions, and do what is best for your organization.
This is our gift to help you improve your incident management program faster, with less professional pain, smoother operations, and optimal business resiliency.
We hope our work will be useful to you. If so, let us know!
-- The Breach Commander DFIR Team
Incident Response Planning FAQ
Q: Does my organization need an incident response plan?
A: Yes.
The Incident Response Plan (IRP) is the backbone of an organized, defensible, and accountable response. Its purpose is to define what must be done, when, and by whom when an incident strikes.
The IRP brings order to chaos by establishing clear priorities, decision authority, communication rules, and documentation discipline. It ensures that actions are coordinated rather than improvised and that leadership decisions can be justified later to auditors, insurers, and regulators.
Having an IRP is not just good practice, it is most probably a formal must if not an obligation for your organization.
Beyond best practice, an IRP is a requirement under many laws, standards, and frameworks.
Examples include:
ISO/IEC 27001 and 27035, which require documented incident response procedures.
NIST Cybersecurity Framework (CSF) and SP 800-61, which define response as a core function of cybersecurity governance.
CMMC, SOC 2, and PCI-DSS, which mandate tested and maintained incident response plans.
GDPR, HIPAA, and several national privacy laws, which require timely reporting of security breaches that only a structured plan can enable.
Cyber insurance policies, which often require a current and tested IRP as a condition for coverage and as proof of due diligence.
An IRP is a management instrument, not a technical manual. It provides direction, accountability, and confidence when everything else feels uncertain.
Q: Is a technical-only IRP a mistake?
A: Yes.
From over two decades supporting a wide array of organizations (military, government, insurance, maritime, industrial, etc), one of the biggest mistakes we've seen is when organizations produce an IRP that considers only the technical aspects of incidents.
Technical-only IRPs ignore the business dimension that gives incident management its true purpose. They may describe how to restore servers or isolate malware, but they fail to consider what the business actually needs to survive and recover.
An effective IRP connects the technical response to business continuity, legal, insurance, and communication requirements. It bridges the gap between engineers, executives, and external stakeholders so that actions are aligned with organizational priorities, not just system uptime.
A purely technical IRP is incomplete by design. In most organizations, IT is not the business itself, it is a critical support function.
The IRP must reflect this reality to offer its maximum potential.
Q: What is the most important aspect of incident management?
A: Calm leadership.
People managing incidents must be cool in times of chaos.
Some can. Some cannot.
This becomes obvious when an incident happens. You will see quiet people shine under pressure and confident people lose their footing. Identify incident leaders who stay calm, decide clearly, and build trust. Train them, back them, and make sure everyone knows who they are before the next crisis.
Q: Is a modest plan better than no plan?
A: Yes.
A simple, even imperfect plan that people know and can execute under pressure will outperform a complex one that no one understands. The value of an IRP is not in its formatting or legal polish, but in the readiness and coordination it enables when things go wrong.
Too often, organizations delay writing a plan because they want it to be perfect. Meanwhile, incidents still happen. A draft plan that gives direction and accountability today is far better than a theoretical masterpiece waiting for approval tomorrow.
Start with something you can use. Run a tabletop exercise. Adjust what breaks. Add depth as you learn. Over time, your IRP will mature naturally through practice and experience, not endless editing.
An imperfect plan executed with discipline is a sign of maturity.
Q: Does the IRP need governance and document control?
A: Yes.
Because during a crisis you cannot waste a minute asking which version to use.
Treat the IRP as a controlled security asset:
Keep the plan known of approved stakeholders
Keep an approved digital copy and one offline copy
Record version, date, approver, and summary of changes
Mark sensitivity and distribution levels
Require formal sign off by the CISO (or delegated authority)
When the plan changes, the change log must show who did what and why
Access, storage, and distribution should comply with privacy, labor, and records-retention obligations
Q: Should the IRP be considered a "sensitive" document?
A: Yes.
During a crisis, you cannot afford to lose time wondering which version of the plan is valid or where it is stored. Governance and document control are what keep your IRP reliable, current, and accessible when it matters most.
Treat the IRP as a controlled security asset, not just a policy document. It must be both protected and available.
Good governance practices include:
Keep the plan known only to approved stakeholders who have defined roles and responsibilities.
Maintain at least one approved digital copy and one offline or printed copy in case systems are down.
Record the version, date, approver, and a summary of changes each time it is updated.
Clearly mark the sensitivity level and distribution list, applying need-to-know principles.
Require formal sign-off by the CISO or their delegated authority before release.
When changes occur, the change log must show who made them, when, and why.
Ensure secure but rapid accessibility: authorized responders must know exactly where to retrieve the plan, even during outages or network segmentation.
Access, storage, and distribution must comply with privacy, labor, and records-retention regulations.
Periodically verify that all copies, including offline ones, reflect the latest approved version.
A well-controlled IRP is both secure and ready. Locked away or outdated, it becomes useless. Governance makes sure it can be trusted and used instantly when chaos begins.
Q: What if the plan fails?
A: Use judgement.
Even good plans can crack under pressure. People may forget steps. Systems behave differently. Attackers adapt.
“Everybody has a plan until they get punched in the face.” — Mike Tyson
In such circumstances in the military circles, they would say: Improvise, adapt, overcome.
The point of the IRP is not perfection. The point is resilience and recovery with accountability.
This is why we strongly advise to appoint individuals who are capable of applying the plan and who know the business well enough to decide and act when the path is unclear.
Q: Can a plan replace human judgment?
A: No.
A plan guides action. It does not replace thinking.
You need people who understand your business, who can connect the dots quickly, and who have the judgment to act under pressure.
No document, tool, or checklist can make critical decisions for you.
Incident response leadership is not a junior role. You cannot save costs by assigning inexperienced staff and expect the IRP to do the work for them. A perfect plan in the hands of untrained or hesitant people is useless when reality starts moving faster than the paper.
When the unexpected happens (and it will) it is the calm, experienced minds that will prevent panic, interpret incomplete information, and make decisions that balance risk, law, and business survival.
A good plan supports good people. It never replaces them.
Q: Is there any urgency to manage incidents?
A: Yes.
The first 72 hours are the most critical, especially for severe incidents.
This is when you validate scope, activate retainers, notify stakeholders, and pick early containment strategies. It is fine to carry uncertainty in this window, but it is not fine to be unstructured. Many legal and contractual frameworks start timers at discovery or confirmation. Your IRP should include a legal timer workflow with a named owner and counsel oversight.
Priorities in the first 72 hours:
Establish the war room and work arrangements.
Preserve safety and business continuity.
Capture and preserve evidence.
Contain in ways that do not destroy forensics.
Communicate early with leadership, counsel, insurers, and key partners.
Q: Should every alert or observed threat activity count as an incident?
A: No.
As defined in our introduction above, we consider that an incident is any situation that causes, or has a high likelihood of causing, a negative impact on one or more of the core cybersecurity pillars: Confidentiality, Integrity, or Availability (the CIA triad). Privacy is considered a component of confidentiality.
If none of these pillars are affected or at credible risk, the event does not meet the threshold of an incident. It should be handled as an event and not escalated into full incident response (See below "If it is not an incident, what is it?").
Establishing and communicating this definition clearly helps prevent overreaction to minor anomalies and ensures that genuine incidents receive the focus, resources, and urgency they deserve.
Q: Is an incident and a crisis the same thing?
A: No.
A crisis is an incident whose impacts threaten the business itself.
In a crisis, operations, customers, trust, profits, safety, or the environment are at risk.
Not all crises are cyber incidents, but most modern crises include cyber elements.
Your IRP should define how a crisis management structure interacts with the cyber command structure and when it takes precedence. (See our article on Business Continuity Planning)
Q: How do we assess impacts beyond IT?
Q: Does the IRP only consider the cyber CIA triad?
A: No.
The IRP should not limit the notion of risk to the cyber CIA triad.
The cyber confidentiality, integrity and availability (CIA) pillars measure technical challenges. They are key to the IRP, since we're managing cyber incidents.
But there is more we can do to protect and support business resiliency when events are cyber by nature. To complement the CIA triad, we can add the PEAR 🍐 model, which broadens the focus to human, business, and societal impacts.
More specifically:
(P)eople: health, safety, morale, and productivity.
(E)nvironment: physical or societal damage.
(A)ssets: infrastructure, systems, data, and facilities.
(R)eputation: trust, brand, and regulatory posture.
Ideally to be meaningful, severity must reflect both CIA and PEAR holistically in the organization.
Q: Should the IRP contain technical how-tos ?
A: No.
An IRP exists to guide coordination, not execution.
It should define the why, what, who, when, and sometimes where of incident response.
Why: the purpose of response, tied to mission, trust, continuity, and revenue.
What: the outcomes and objectives by phase, such as contain, restore, report, and preserve.
Who: the accountable roles, their alternates, and escalation paths.
When: the target timeframes, often expressed as SLOs or SLAs.
Where: the systems or sites involved, if the organization is geographically distributed.
Avoid embedding the how. The specific ways to perform containment, recovery, or communication vary endlessly by system, team, and context. Each group, from network engineering to legal or finance, should maintain its own procedures describing how their specific responsibilities are carried out. Or else, in the absence of such written procedures, we consider that staff should have the know-how to achieve a result related to their competence domain (the reason they are on the payroll).
From our experience, trying to blend orchestration and technical execution in a single plan has generally failed spectacularly in practice.
So, keep the IRP at the orchestration level, and link to technical procedures or playbooks as annexes. This keeps the plan usable under stress, concise, modular, and scalable.
Q: Who owns the IRP?
A: The Chief Information Security Officer (CISO) or equivalent role.
The CISO typically owns and is accountable for the plan.
During declared incidents, operational command shifts to the Incident Commander, while legal and safety considerations remain the ultimate authority.
Legal and regulatory obligations, as well as safety considerations (life, environment) should have priority over the IRP, and may thus override parts of the IRP when encountered.
Any deviation must be justified, logged and reviewed after the incident to adjust the plan.
The plan should also define who can grant general extraordinary or emergency waivers, and who closes them.
Q: How many core roles should we define?
A: 3.
Start with three clearly defined orchestration leadership roles. These are the backbone of the Incident Response Plan.
Incident Commander
Leads the overall response, sets priorities, and ensures that all activities align with business objectives and leadership expectations. Acts as the final decision authority during the incident.
Business Lead
Manages the business response, assesses impacts, decides trade-offs, and ensures alignment with Business Continuity Plans (BCP). Coordinates closely with the BCP Coordinator when recovery or continuity measures are activated.
Technical Lead
Manages the technical response, overseeing investigation, containment, eradication, and recovery. Directs the technical responders and ensures that actions are documented and verified.
We often refer to:
The team under the Technical Lead as the Technical Incident Response Team (T-IRT).
The team under the Business Lead as the Business Incident Response Team (B-IRT).
Supporting members from various functions (IT operations, security, legal, communications, HR, finance, and others) join these ad-hoc teams as needed.
Important organizational consideration
To avoid conflict and confusion, the IRP should clearly state that, once activated, incident response duties take precedence over normal day-to-day work. Individuals assigned to IR roles must be empowered and supported to pause regular duties and focus on the response.
In practice, this can become challenging in large or federated organizations where reporting lines, chargeback models, or inter-departmental agreements blur authority. Tensions may also arise when incidents stretch over time and employees are pulled between urgent IR tasks, regular performance metrics or other business obligations.
Mitigation comes from clear governance and pre-approved escalation paths. The IRP should document the authority of the Incident Commander to direct activities across departments and subsidiaries for the duration of the response. Senior management endorsement is essential so that all stakeholders understand that supporting incident management is not optional.
Q: How should roles and responsibilities be documented?
A: Use a RACI matrix.
The RACI matrix is a very effective and compact format.
It's construction will require operational discussions with various stakeholders to adequately define and align the tasks with work functions, scopes of authority, professional responsibilities and ways of doing things in your organization. But the result will be very useful.
How to build the RACI matrix
Put tasks on rows and roles on columns.
Mark who is (R)esponsible, (A)ccountable, (C)onsulted, and (I)nformed.
Keep one master RACI for the IRP and specific RACIs for high frequency playbooks.
Everyone should know their box before the chaos starts, so awareness training and tabletop exercises will be key.
Q: Can anyone declare an incident?
A: No.
Only expressly-appointed individuals or roles should be authorized to declare incidents.
The "declaration" of an incident is the act by which the organization officially marks the beginning of an incident, the start of the incident clock and the activation of the IRP.
It is not a communication action, but a logistical one.
The declaration power can be assigned to named individuals (e.g. the person in charge of cybersecurity) or to roles within a team (e.g. SOC Lead and CERT Manager).
Too many declarers might create noise. Too few may create paralysis. Define who can declare, who assigns severity, who can escalate or downgrade, and how to document the declaration in the decision log.
Treat the authority as both power and duty.
Q: Should severity levels be formally defined?
A: Yes.
Severity is an assessed threshold representing impact gravity and the required pace of work.
Quantitative triggers: financial loss, downtime, number of affected users, data records exfiltrated, count of critical systems.
Qualitative triggers: loss of trust, legal exposure, (lack of) control of the situation, adversary capability.
Match work tempo to severity, for example:
Sev 0 catastrophic: 24/7 crisis mode, in person war room, executive presence.
Sev 1 high: 24/7 rotation, frequent executive updates, cross functional staffing.
Sev 2 moderate: extended hours, daily executive briefings.
Sev 3 low: business hours, SOC-led with periodic reporting.
Inconsistent severity and cadence erode trust.
Assigning higher than necessary severity levels burns precious resources, drains people, and creates unnecessary panic. Severity should be based on verified impact, not fear or optics.
Severity discipline separates mature programs from chaotic ones.
Q: Should we maintain specialized playbooks?
A: Yes.
A unique workflow cannot fit all threats, impacts and incidents. Therefore we recommend maintaining modular playbooks that can apply piecemeal to the situation with only the relevant actions to take at that time.
Consider the relevant subset of themes below to cover many incidents typical to the modern enterprise:
Malicious software execution (malware)
Intrusion into systems
Ransomware and destructive malware
Business email compromise and payment fraud
Web application compromise and API abuse
Data breach or privacy exposure
Denial of Service (Dos), Distributed DoS (DDoS) or otherwise unavailability of systems.
Third party or supplier compromise
Insider threat and misuse
Operational Technology (OT) or industrial Control system (ICS) disruption or intrusion
Specialized playbooks will keep your incident management straight to the point, and also facilitate focused training and simulation.
Q: Do we need a "war room" to manage incidents?
A: For severe incidents, yes.
Severe incidents benefit from the physical regrouping of key personnel, rapid information sharing and intense collaboration. This is usually facilitated by monopolizing a large meeting room as the based camp for the decision makers and other key players.
This is typically called a "war room": a controlled environment where the critical response is led, documented, and coordinated.
Its goal is speed, clarity, and accountability.
Purpose
One source of truth for actions, decisions, and status.
Shorter decision cycles by putting the right people together.
Preserved evidence of diligence through accurate, timestamped records.
Format
Physical room for high severity incidents. Quiet, access controlled, with whiteboards and large displays for timelines and status. Tight badge list.
Virtual room when physical is not feasible. Use a secure orchestration platform with role based access. No personal accounts. Recording rules set by counsel.
Important Roles
The Incident Commander, the Business Lead and Technical Lead (on rotation)
A scribe (if possible), to track decisions and tasks
The executive (on rotation)
The BCP Coordinator if BCP is activated (on rotation)
Rhythm
Short opening standup to confirm objectives, risks, and timeboxes.
Regular cadence updates for leadership and for technical teams. Separate the two.
Rolling action list with owners and due times. Nothing leaves the room without an owner and a deadline.
Visual timeline on the wall or shared screen. Decisions and discoveries pinned with time and owner.
Clear rules for side work. If it is not logged, it did not happen.
Work discipline
Maintain composure and confidentiality; every word, note, and tone can become part of the audit trail.
One primary channel for chat and files. Ban side threads for operational content.
No photography unless approved by counsel. No ad hoc recordings that might break privilege.
Access on a need-to-know basis. Visitors are brief, purposeful, and logged.
End of day summary captured in the record: what we know, what we did, what we will do next, and blockers.
Human resources management
Keep people healthy for the expected core incident duration. Two weeks is a prudent minimum gauge for severe incidents.
Involve HR and psychological support. These events strain morale and mental health.
Plan food services and breaks.
If key staff cannot leave because of unique knowledge or distance, arrange quiet onsite sleeping quarters so they can rest between shifts.
The IRP should have provisions for how and where the war room will be established, and its priority so that its activation take precedence over day to day meetings.
Q: Are there special considerations for communication channels?
A: Yes.
Communication discipline is as critical as containment. During incidents, a single leaked message or mishandled chat can cause legal exposure, panic, or loss of trust. Your organization must decide in advance how, where, and by whom communication will occur under stress.
1. Use only pre-approved, encrypted channels
Establish secure collaboration tools for incident coordination and ensure everyone with an IR role knows how to use them.
Avoid personal accounts, personal devices, or social media messaging under any circumstance. Doing so can break privilege, chain of custody, and confidentiality.
2. Have an out-of-band option ready
If your primary corporate platform (email, chat, or conferencing) is suspected or confirmed compromised, you need a fallback channel. For example, a pre-registered secure chat, alternate email domain, or approved voice conference line.
Document these alternate channels in the IRP and test access regularly. Switching communication mid-incident without preparation adds chaos.
3. Define and apply internal INFOCON levels
INFOCON (Information Operations Condition) is a concept borrowed from military and national defense cyber operations. It defines levels of cyber threat readiness and prescribes communication and access restrictions that escalate with risk.
At higher INFOCON levels, communication becomes more restricted and formal, requiring stronger authentication, tighter approval chains, and reduced audience size.
You can adapt this principle for your organization by creating internal tiers such as:
These internal levels remind everyone that communication security tightens as threats grow, not the other way around.
4. Keep the human element in mind
No matter the tools or levels, communication hygiene ultimately depends on people. Train staff not to forward, screenshot, or summarize IR discussions outside controlled channels. Rehearse channel switches during exercises so that in a real event, everyone moves together.
The outcome is clear, trusted, and privileged communication that keeps your team synchronized, your evidence defensible, and your organization protected from self-inflicted leaks.
Q: Is there a difference between playbooks, workflows, and procedures?
A: Yes.
In practice, people often mix these terms when describing how work is sequenced to reach an objective.
However, to be precise in the writing of your governance, know that each term carries a distinct meaning and level of detail.
The table below summarizes their purpose and relationship within your IRP ecosystem.
Concepts and how they relate inside your IRP stack
Q: Can containment and investigation requirements be balanced?
A: Yes.
In theory, processes paint a clean, sequential picture of how things should unfold: assess, contain, investigate, eradicate, recover. Each step flows neatly into the next, with clear handoffs and decision points.
In reality, cyber incidents generally do not follow such a perfect order. Actions overlap, invert, and repeat. Chaos, human judgment, fatigue, communication delays, and unplanned constraints constantly distort the flow. What looks perfect on paper quickly bends to the situation on the ground.
The goal is not to obsess about the static process but to always consider priorities.
Always balance containment, investigation, and business imperatives against real-world conditions.
Containment without intelligence causes reinfection. Investigation without containment causes escalation and damage.
Treat containment as risk management under pressure, not panic or perfection. Executives should resist forcing linear order: effective incident response is adaptive by necessity. The best teams adapt sequence to context, not the other way around.
Q: Are insurance considerations relevant for the IRP?
A: Very.
We've seen cyber insurance grow into a central pillar of modern incident response.
In the early 2000s, the major cyber incidents organizations faced were mostly service disruptions or fraud. Fraud, cyber-facilitated or not, has always been an insurance topic, and downtime has long been covered under business interruption clauses.
Along with this shift came a steep learning curve. As ransomware became endemic, the volume and cost of claims skyrocketed. Since 2020, global cyber insurers have reported substantial aggregate losses, reshaping underwriting models, coverage limits, and the expectations placed on insured organizations. See our article on the inevitable convergence ⭷.
Today, insurers are not just payers of last resort; they are governance stakeholders in how incidents are handled. Their influence touches legal privilege, vendor choice, evidence handling, and communications cadence.
Cyber insurance shapes response governance, vendors, and documentation.
Panel providers: many policies require using approved legal, forensics, and communications vendors. Using others without consent can limit coverage.
Notification and cooperation: early notice unlocks resources. Insurers expect factual updates, access to logs and images, and documented decisions.
Evidence for claims: adjusters need cost records, timesheets, vendor invoices, and a reliable timeline.
Coverage clarity: know what is covered such as incident response, business interruption, data restoration, extortion, regulatory defense, and liability.
Privilege and messaging: align counsel, insurer, and executives on what is said and when.
Ransom and extortion: if considered, follow policy rules for negotiation conduct, sanctions checks, and approvals.
Store policy numbers, adjuster contacts, and breach coach details in the IRP annex.
Q: Should incident management consider the cyber supply chain?
A: Absolutely.
The digital "supply chain" means the risks of your 3rd party providers are your risks too. And vice versa to some extent.
Your customers won't care whose fault it was. They expect you to safeguard their confidential information and deliver quality.
If your operations depend on digital services providers, their failures are yours, their data leaks contain your data, and intrusions into their systems may well allow the attacker to reach your systems.
Maintain escalation contacts for critical vendors. Ensure contracts include audit rights, incident cooperation, meaningful SLAs, and access to logs. Include vendor events in your severity and reporting models.
Contract language and cooperation duties vary. Review with counsel before incidents occur.
Q: Should the IRP include communication and reporting criteria?
A: Definitely.
Clear and disciplined communication is one of the strongest determinants of how well an incident is managed and perceived. Your IRP must define who communicates, with whom, when, and about what.
Silence invites speculation and can harm customer and partner trust.
Communication obligations are not optional. Regulations, contracts, insurance policies, and due diligence expectations all define how and when you must notify certain parties. Beyond legal mandates, proactive and honest communication reassures customers, partners, and employees that the situation is under control. Silence invites speculation, and speculation damages trust.
What to include
The IRP should document:
The communication and reporting process, including regulatory, contractual, and voluntary notifications.
The RACI for communication: who is Responsible, Accountable, Consulted, and Informed.
The cadence of updates based on severity and stakeholder expectations.
The review and approval path for all external communications, coordinated through Legal Counsel or your breach coach.
Key stakeholder groups
Depending on the situation, consider communication with:
Employees and internal collaborators
Customers and partners
Service providers and suppliers
Insurer (as defined in your policy)
Law enforcement
Regulators and oversight authorities
Shareholders or boards, if applicable
Not every group applies in every scenario, but planning for each avoids confusion later.
Engaging external authorities
The IRP must identify regulatory and legal obligations and maintain updated contact information for law enforcement, regulators, and other authorities. Engagement should always proceed through Legal Counsel or your breach coach, who understand timing, privilege, and disclosure boundaries.
Only share verified facts, not assumptions or theories. Document every exchange, including date, participants, and information shared. Track regulatory notification deadlines and align them with confirmed impact assessments.
Disclosures must follow contractual and regulatory requirements and any applicable safe-harbor provisions.
Ownership and accountability
The Incident Commander owns timing and accuracy. They may delegate the act of reporting to the Business Lead or Technical Lead but remain accountable for what is communicated and when.
Accuracy builds credibility. Discipline sustains trust. Communication that is deliberate, documented, and aligned with governance is the mark of a mature incident response program.
Q: Is the performance of incident management measurable?
A: Yes.
Every incident produces a trail of decisions, actions, and communications. Hidden in that trail are valuable data points that, when analysed, tell the real story of how your organization performs under pressure.
A good starting point is to collect metrics that reflect time, cost, resilience, and decision quality:
Mean Time to Detect (MTTD): how long it takes to confirm that an incident is real.
Mean Time to Contain (MTTC): the time between detection and successful containment.
Mean Time to Recover (MTTR): how quickly critical systems and services are restored.
Number of incidents by severity: helps track patterns and gravity over time.
Cost by activity type: investigation, containment, recovery, communication, and legal.
Downtime cost: lost productivity or revenue per incident.
Insurance-covered expenses: the portion of your loss that was reimbursed.
Reinsurance impact: whether the event affected your premiums or coverage terms.
Customer turnover variation: how trust and retention changed after the incident.
The best metrics are the ones your business leaders and cyber defense teams actually use to improve their work. Sit with them, discuss what matters, and map those needs to the data you can collect next time.
Metric definitions should be formally documented for reference and to avoid misinterpretation.
Using an orchestration platform such as Breach Commander makes this process far easier, since analytics, decision logs, timelines, and evidence trails are built in. Performance reporting then becomes part of the workflow, not an afterthought.
Q: Can recovery be measured?
A: Yes.
Recovery is a state where systems and services are back to working as intended.
Define exit gates, integrity checks, and functional validation of full business workflows.
Declare recovery only after end-to-end service is available, stable, and the business stakeholders confirm it is usable as intended.
Q: is it advisable to negotiate ransom demands ourselves?
A: No.
Whatever the form of extortion, whether ransomware, data theft, or another threat, do not negotiate directly with the attackers.
Ransom and extortion situations involve complex legal, financial, and regulatory risks. Engaging directly can create liability exposure, violate sanctions, or worsen the attacker’s leverage by revealing information you cannot retract.
If your organization’s policy allows ransom negotiations under certain conditions, those activities must be handled by authorized professionals who are:
Experienced in dealing with threat actors and their negotiation patterns.
Protected under legal privilege, typically through breach counsel or a specialized negotiation firm.
Recognized by your insurer, since most policies only cover negotiation and payment if approved vendors are used.
Capable of performing sanctions checks and ensuring compliance with anti-money-laundering laws.
Your Incident Response Plan should define your organization’s ransom and extortion policy clearly, whether it allows, restricts, or outright prohibits negotiation. It should also include:
The escalation and decision-making path through Legal, Executive, and Insurance channels.
The documentation and authorization steps if negotiations are considered.
The fallback procedures if payment is refused or fails.
For many organizations, the safest and most defensible position is a firm no-pay, no-negotiation policy. If negotiation is ever an option, treat it as an exceptional decision, not a reflex.
In all cases, involve your legal counsel in any related discussions.
Q: Is paying a ransom a good strategy?
A: No.
Paying a ransom may appear to be the quickest path to recovery, but it carries serious philosophical, legal, operational, and moral implications that should never be underestimated.
Unfortunately, for some organizations, payment becomes the only perceived way out when attackers have destroyed backups, changed credentials, or erased all other recovery options. It is rarely a good choice, but sometimes the only remaining one.
This content is informational and not an encouragement to pay or to refuse payment; your policy decisions should be made with counsel.
1. Philosophical and moral considerations
Paying fuels the criminal ecosystem. It rewards extortion and keeps the business model of threat actors alive. Every ransom payment strengthens the attackers’ capabilities and funds the next wave of attacks, often against new victims who will suffer the same fate.
2. Legal and regulatory exposure
Ransom payments can violate sanctions or anti-money-laundering laws depending on the attacker’s identity, location, or affiliations. Even when technically legal, most jurisdictions expect full documentation, due diligence, and reporting to regulators and law enforcement. Acting without legal guidance can turn a bad situation into a worse one.
3. No guarantee: but a cynical criminal business model
There is no enforceable contract between you and a criminal. Many organizations that pay never receive a functional decryption key, or later discover that stolen data was leaked or resold anyway. Payment often buys nothing but a false sense of control.
However, some threat groups operate ransomware as a structured business model. Their profitability depends on maintaining a certain “reputation” among victims and negotiators: if too many victims are cheated, future victims will stop paying.
In practice, many victims who paid did receive working decryption keys, and in several cases, the attackers appeared to respect their promise not to leak data publicly. But there is never certainty that stolen data was actually deleted on the attacker's side, and our opinion is that it is unlikely.
So we come back to the same truth, which raises the core problem of trust in criminal assurances.
4. Insurance limitations
Cyber insurance policies rarely guarantee ransom reimbursement. Most require prior authorization, legal clearance, and negotiation through approved vendors. Paying without following these steps can void coverage entirely.
5. Reputational and ethical damage
Payment can erode trust with customers, partners, and regulators if it becomes public later. It may appear as concealment or a lack of control. In contrast, transparency and diligence tend to preserve reputation and demonstrate accountability.
6. The reality check
If paying the ransom is not illegal under your specific circumstances, it ultimately becomes a business decision. Leadership must weigh operational survival against moral and long-term risks, ideally with advice from legal counsel, the insurer, and law enforcement.
Still, there is one lasting consequence: once you pay, you are marked as a "good customer". Threat actors share intelligence within their networks, and organizations that have paid may afterwards face increased targeting according to industry experience. Payment proves that extortion works, and profitable customers tend to get repeat visits.
Is there concrete value to tabletop exercises?
A: Yes.
Tabletop exercises are one of the most effective and affordable ways to validate your incident response plan and strengthen team readiness. They show how people, processes, and technology work together when things get difficult.
A tabletop exercise is a structured discussion built around a realistic scenario. Participants describe the actions they would take, explain their reasoning, and identify decision points, dependencies, and communication needs. Unlike full-scale simulations, tabletops require no technology but often reveal more insight than any audit or checklist.
Many organizations voluntarily run tabletop exercises as part of their cybersecurity and business risk awareness programs, or simply as powerful team-building activities.
Best practice frameworks such as ISO 27035, NIST SP 800-61, and ITIL all highlight exercises and simulations as essential components of continuous improvement. Insurance providers also frequently include questions about plan testing and validation. Tabletop exercises are the perfect answer to both expectations.
The value comes from what you learn, not how dramatic the scenario is.
Well-run tabletop sessions help you:
Test your processes and escalation paths to confirm that decision authorities and contact lists are current.
Validate role clarity so everyone knows who leads, who approves, and who reports.
Assess communication flow to make sure information moves quickly and accurately across technical, legal, and executive stakeholders.
Expose gaps and dependencies that documents alone never reveal.
Build confidence, trust, and calm decision-making under pressure.
Meet compliance and insurance expectations, since many frameworks and insurers require regular response exercises.
Best practices for tabletop sessions
Start small, then add complexity as participants gain confidence.
Involve a mix of executives, legal counsel, technical leads, and communications staff.
Use varied scenarios such as ransomware, insider misuse, data leakage, or supplier failure.
End with a short, blameless debrief to capture lessons and assign improvement actions.
Update your IRP and playbooks after each exercise.
The more you practice, the fewer surprises you face when a real incident strikes. What you rehearse calmly today becomes instinct in the middle of a crisis tomorrow.
Feedback from the field
Our experience hosting tabletop exercises and other types of simulated challenges has shown that participants almost always find them valuable, even when they were initially reluctant to attend. Many later admit they learned not only about incident management, but also about themselves and how they think under pressure.
When executives and board members participate in tabletop exercises, they gain firsthand awareness of timing, decision pressure, and communication expectations.
As the simulations unfold and the chaos feels real, participants discover how they react when confronted with uncertainty, stress, and time-critical decisions. The experience pushes people to their limits in a safe environment, building confidence, composure, and mutual respect across teams.
Q: Should the plan be tested?
A: Absolutely.
No plan survives untested.
Training and rehearsal are what turn written intentions into real capability. There are several reasons to make them a recurring habit:
Regulatory compliance: some frameworks and certifications require tabletop exercises at defined intervals. If your organization falls under those mandates, exercises are not optional.
Insurance expectations: many cyber insurance policies now include explicit requirements for regular training and simulations. Meeting those expectations helps maintain eligibility and supports your claims in case of a real event.
Proactive maturity: even when not mandated, running tabletop exercises at least once a year, and ideally once per quarter, delivers far more value than the time invested.
Regular exercises bring multiple benefits:
They test processes, recall lists, and the comfort level of leadership when facing uncertainty.
They build collaboration and trust across departments that rarely work together in daily operations.
They expose gaps in resilience planning, surface untested assumptions, and reveal hidden dependencies or single points of failure.
Practice makes perfect
Start small. Ask what-if questions. Ponder over them in small groups.
Then add complexity as the players gain maturity.
After every test or real event, hold a blameless review. Capture what worked, what did not, and assign owners with dates. Update the IRP, the annexes, and playbooks. This is incident capitalization.
You will discover that every simulation session, even the imperfect ones, improves the team’s muscle memory.
What you practice calmly today becomes instinct when the real pressure arrives.
By doing so, you are turning pain into institutional intelligence.
Q: Do severe incidents have impacts on the lives of the stakeholders?
A: Yes.
Major incidents disrupt more than business operations; they also affect the rhythm of work and personal life for those directly involved.
While every organization must respect its labor, contractual, and wellness obligations, it is realistic to expect that key personnel will experience demanding schedules and shifting priorities during the height of response.
When a major incident is declared, routines will change. Meetings may be postponed, priorities will realign, and certain leaders may need to remain closely engaged for extended periods. Planning ahead helps reduce stress and maintain effectiveness.
For stakeholders involved in incident management or support, ensure that the plan anticipates the following considerations:
Review calendars for the coming weeks and reschedule non-essential commitments.
Delegate routine responsibilities to a trusted second in command.
Inform regular stakeholders that attention will temporarily focus on urgent response duties.
Provide team members with clear expectations about workload, rest, and recovery time.
Where possible, make family or home arrangements to sustain focus when needed.
Always follow organizational HR and health and safety policies, especially regarding extended hours, fatigue, and time off.
A well-managed incident response is not about endurance or heroism. It is about sustained clarity, coordination, and sound decision-making under pressure, while maintaining energy and composure for as long as the situation demands.
Q: Should we activate the full IRP every time an incident occurs?
A: No.
Not every incident warrants the full machinery of an emergency response. As discussed in the severity section above, the assessed severity determines the speed, complexity, and depth of the required actions.
For most organizations, truly major incidents are rare. On an average day, many alerts or minor events may escalate into low-severity incidents that can be handled directly by technical or operational teams without mobilizing executives or spinning up a 24/7 war room. Doing so for every case would be inefficient and exhausting.
However, even small incidents must still be logged, triaged, and documented. This ensures that patterns, weak signals, and recurring anomalies can later be correlated through threat intelligence or post-incident analysis. What looks minor in isolation may reveal a larger campaign when viewed collectively.
A mature IRP scales proportionally to the impact and risk. The key is to react appropriately: decisive when needed, measured when possible, and always documented.
What’s next?
Even with all our shared experience and guidance, writing your own IRP will always be a custom challenge. No two organizations are identical. It takes time, collaboration, and a few difficult conversations to align every stakeholder (technical, business, external) around a shared playbook.
The effort pays off.
When done properly, your IRP becomes one of the most valuable governance assets your organization will ever own.
Whether you build it yourself or start from a proven template, the goal is the same: clarity under pressure, confidence in leadership, and a documented path to recovery.
Where to find external governance support
If you need external assistance, many reputable cybersecurity consulting firms specialize in governance, risk, and compliance. They will help build and align your IRP with regulations, frameworks, and insurer expectations.
Ready-made IRPs for faster deployment
An IRP is inherently custom, but in practice, about 75 percent of the content can be reused safely across most organizations. The remaining 25 percent is what makes it yours: your business model, your risk tolerance, and your team culture.
We have contributed to two ready-to-use IRP products provided by a trusted partner:
A FREE basic IRP, to kick-start your program and meet minimum regulatory and insurance expectations.
A paid complete IRP document, which includes expert guidance and structured customization support.
These templates were originally designed for maritime organizations, but their structure applies broadly and includes operational technology (OT) and physical operations considerations. A more general-purpose cyber IRP, without maritime specifics, is planned for release in 2026.
Find the documents here:
Where is Breach Commander in all of this?
Breach Commander was designed around an Incident Response Plan.
It integrates the logistical, collaborative, and documentation capabilities required for full orchestration, turning your IRP from a static document into a living, executable process.
It is made to provide a single pane of glass platform for unified incident orchestration, evidence capture, communication, and reporting. You can also add your steps to our ready-made playbooks, precisely supporting your IRP.
📰 Related articles:
More reading? Continue with our insights about the governance items to put in place for optimal incident management.
Ready to orchestrate cyber incidents like a pro and remove the pain?
Head over to the store to find the subscription for your organization
Comments