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:
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).
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.
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.
Implementation of the concept in this blog can be explored by requesting an eBRP Suite demo.