Incident Management & Crisis Management – Very Different, Often Confused

Those of us who spend our business lives immersed in the Business Continuity industry swim through a sea of acronyms.  Meanwhile, we are constantly seeking the support and cooperation of colleagues who are often confused by those same acronyms.

We can make understanding easier simply by using real terms instead of acronyms.  But unless we can clearly define those fundamental Business Continuity terms, we still risk confusing our potential supporters and partners.

There are two common terms that are too often used (or confused) interchangeably:  Incident Management and Crisis Management.  They are not the same.  They are related – but have differences in purpose and objectives that ought to make their definitions clear:

Incident Management

The plans for and actions taken to respond to a disruption of day-to-day operational activities – with the objective of returning to the original state.

An “incident” must be operational.  Something must have been disrupted.  It need not be a ‘disaster’ (destruction, collapse, obliteration).  It may be a disruption in Information Technology services, or business processes – or both.

The ‘management’ of an ‘incident’ focuses on determining the impacts of the disruption, developing a strategy for response, and managing the recovery of impacted systems or processes – and coordinating the efforts of Recovery Teams charged with carrying out that strategy.

Incident Management starts when the ‘disruption’ is reported, and ceases when operations have returned to their original state (or a substitute ‘business-as-usual’, in the case of a disaster).

Crisis Management

The plans for and actions taken to protect and defend the reputation of the organization, its brand and its products/services.

A ‘crisis’ may be as a result of an ‘incident’ – but not necessarily.  A crisis could be a result of rumors, product defects, adverse publicity, negative social media activities, or actions of employees, distributors or suppliers which reflect poorly upon the organization.

Not every Incident will result in a Crisis (an operational disruption may be transparent to anyone outside the organization).  Not every Crisis will be an Incident (adverse publicity, for example, should not disrupt day-to-day operations).

The big question:  is Crisis Management a part of Incident Management?

Rarely will a Crisis become an Incident.  A crisis which results in website traffic that brings down customer service portals may require Incident Management actions to fix the operational situation.  A picket line or public demonstration that blocks entry to a facility might require Incident Management actions. But there are few other examples of ‘crises’ that will require invoking Incident Management activities.

On the other hand, operational disruptions that might require Crisis Management activities are too numerous to list.

To assure an effective response to any unplanned event, Incident Management and Crisis Management plans should be developed, updated and maintained as separate entities – but they are closely related and must be created in a manner that enables them to work together when needed.

  • Areas of responsibility must be clearly defined in both plans – and those responsibilities must match.
  • Protocols for invoking the related plan must be clearly defined in both plans.
  • Whenever possible, both plans should be tested or exercised simultaneously – so all participants clearly understand those protocols and their own roles & responsibilities.
  • The entire organization should be educated – so that everyone understands the roles of these two separate plans and teams.

When we make the mistake of merging Incident Management and Crisis Management into one entity, we create confusion.

When we choose to use either term to mean both, we risk missing the proper planning, preparation, testing and execution needed to respond – to an incident, a crisis or both.

Making sure our organizations understand the differences between an Incident and a Crisis, and who is responsible for managing our response to them, is critical to meeting the goals of every Business Continuity Management program:  assuring preparedness for the unexpected.

Don’t create confusion.  Create clear goals, responsibilities and lines of authority for both Incident Management and Crisis Management – and document them in separate plans.

SHARE:
Jim Mitchell

Jim Mitchell

A frequent speaker at Business Continuity conferences, many of Jim Mitchell’s blogs can be found elsewhere on eBRP’s website and has published articles in DRJ, Continuity Insights and Continuity Central. Jim has more than 20 years of experience in Business Continuity; if you don’t agree with his opinions – he won’t be surprised.

Related Posts

A Toolkit to Build Enterprise Resiliency

A Toolkit to Build Enterprise Resil...

A well-rounded Enterprise Resiliency Toolkit (𝗧𝗼𝗼𝗹𝗸𝗶𝘁) would provide key tools…
Enterprise Resiliency: Navigating Through Disruptions

Enterprise Resiliency: Navigating T...

In today’s threat landscape, the ability of an organization to…
Orchestrating BC/DR Testing: Virtual – Emergency Operations Centers

Orchestrating BC/DR Testing: Virtua...

  Enhancing Planning and Logistics Management  Coordinating BC/DR tests involves…
Insights into creating a successful Disaster Recovery Test – Part 2: Preparation

Insights into creating a successful...

Insights into creating a successful Disaster Recovery exercise – Part 1: Objectives

Insights into creating a successful...

Aligning Cyber Incident Response Planning with Your BC/DR Program

Aligning Cyber Incident Response Pl...

Cyber disruptions – and their impact on both reputations and…
What Can You Do when your BCM software Relationship Falls Apart

What Can You Do when your BCM softw...

“This isn’t working.”  “I’ve changed.”  “I don’t see a future…
Aligning BC/DR to CSIRP Challenges

Aligning BC/DR to CSIRP Challenges

The immediate reaction to a cyber-security incident is the FUD…
Technology Modeling – the eBRP Way

Technology Modeling - the eBRP Way

Definition: Technology modeling is a point-in-time snapshot of an Enterprise’s…
eBIA – The eBRP Way

eBIA - The eBRP Way

Definition: A Business Impact Analysis (BIA) is the cornerstone of…