Post Incident Analysis (PIA) – A Method to Analyze Your Actions During a BCP Event

The Post-Incident Analysis (PIA) is an invaluable tool for learning from crises and disruptions and improving your event response. In today’s post, we’ll look at when and how to do a PIA and explain how you can leverage them to enhance your organization’s resiliency.

 

The Most Important Thing About the Post-Incident Analysis

The most important thing about PIAs can be stated in two words: doing them.

Too many organizations don’t bother, thinking, “We’ve had the event, we recovered, let’s get back to our normal work.”

This is unfortunate because it amounts to passing up a great learning opportunity. It also means potentially leaving gaps in the organization’s response capability that might come back to haunt it later on.

The PIA’s Definition and Purpose

Backing up a little, let’s answer the question of what a post-incident analysis is.

A PIA, to quote MHA Consulting CEO Michael Herrera, “is the reconstruction of an incident to assess the chain of events that took place, the methods used to control the incident, and how the actions of your organization, as well as those of outside entities such as emergency services and third-party vendors, contributed to the eventual outcome.”

The most common shortcoming we see with PIAs, besides organizations not doing them, is that they limit their efforts to identify and fix the cause of the disruption.

Identifying and fixing the root cause is great. It’s exactly the right thing to do. But that’s not really what a PIA is about. The purpose of a PIA is to assess the quality of the event response.

Specifically, the organization should look at how it did in managing the event. Was the activation process clear? Were any gaps in training uncovered? Were there any obstacles in communication? Were the right actions taken? What worked well?

Seeing the PIA as an Opportunity

It’s common to think of a post-incident analysis as a burden. Another approach is to look at it as an opportunity.

Getting through a real-world event (as you’ve just done) provides the best chance you will have to learn about and improve your event response capability. This could pay big dividends and avoid painful costs the next time you face an event.

But reaping these benefits requires conducting a systematic assessment of your event response; in other words, doing a PIA.

A PIA should be conducted whenever you activate one or your emergency response teams.

Benefits of Conducting a PIA

Here are some of the main benefits organizations reap from doing PIAs:

  • Obtaining a comprehensive record of the incident for use in evaluating enterprise and departmental procedures and recovery plans.
  • Identifying changes and gaps in the recovery actions and procedures.
  • Learning about response times under real conditions.
  • Learning about the quality and timing of communications to internal and external stakeholders.
  • Gaining insight into the effectiveness of safety practices and related procedures.
  • Learning about training needs for department personnel.
  • Gaining knowledge of working relationships with outside agencies.
  • Getting an opportunity to assess the viability of alternate work sites and strategies.
  • Identifying changes to processes or preparation which will reduce or eliminate risks or outages in the future.

Content of a Post-Incident Analysis

At a minimum, the PIA meeting and report should cover the following:

  • Date and time of the incident. The date and time the event occurred.
  • Location of incident. The location and address of the incident.
  • Type of incident. Include a brief description of the event type (e.g., fire, flood, workplace violence, power failure, etc.).
  • Situation upon activation. Give a brief description of the situation at the time of plan activation. Note the type of personnel who are the first to assess or arrive on the scene.
  • Strategy. List the strategies chosen to respond to and recover from the event. List what each strategy entailed (e.g., close off building and relocate affected staff) and the results of implementing it.
  • Common obstacles. List problems encountered by more than one department. Such problems may indicate a need for review of procedures, training, or recovery plans.
  • Outcome. List the extent of damage and impact to business operations. Include damage to facilities and equipment and injuries to personnel, if applicable.
  • Note which operations worked well and those that need improvments. Look at strategies and results, not only at the incident command level but also at the department level, if appropriate. This helps reinforce procedures and tactics that were successful so they may be applied to similar situations in the future.
  • Stakeholder communications. Review the internal and external communications process during the incident. Were communications adequate, proactive, and regularly updated? Were the appropriate stakeholders communicated with during and after the event? What could be improved?
  • Incident organizational chart. Using a simple organizational chart, show lines of authority and responsibility. Identify the span of control.  This allows for a more formal review of the response process in order to identify the positive aspects and correct deficiencies.
  • Root cause identification. Ensure the root cause of the event is identified and specify follow-up remediation to reduce of eliminate the risk of reoccurrence.
  • Recommendations. List any recommendations for correction or modification based on the findings. Include: mitigation of the common obstacles; identification of operational processes to prevent or reduce future outages; changes in communication timing, methods, or recipients; changes to current response plans; and changes to team members’ responsibilities. (Remember, during a crisis event, the roles and responsibilities should be about best fit and capability, not title.)

The PIA report should be formally reviewed and approved by the appropriate parties to ensure accuracy and comprehensiveness. The report should be completed within 14 days of the incident.

All participants must be truthful and candid to ensure the results are accurate and complete. Remind all parties that the PIA is not a place to criticize people or second-guess decisions. The purpose isn’t finding fault but identifying gaps to close and successes to build on. Look forward. Leverage the PIA and event to improve your future response and prevent future events.

A final element of the PIA is ensuring that the findings and action items are documented and included in the BC program action items for follow-up and eventual completion. Action items should be prioritized, assigned due dates, and reviewed on a regular basis (at least monthly).

Boosting Resilience, Protecting Stakeholders

The PIA is a vital tool for helping organizations learn from events and improve their response to disruptions. The PIA’s purpose is to assess the company’s event response in order to identify successes that can be built on and gaps that should be closed.

Not doing PIAs allows the persistence of gaps that can exact a significant toll during future events. Doing them improves the organization’s ability to respond to disruptions, boosting resilience and protecting stakeholders.

Further Reading

For more information on conducting Post-Incident Analyses and other hot topics in BC and IT/disaster recovery, check out these recent posts from MHA Consulting and BCMMETRICS:

About
Michael Herrera
Michael Herrera is the Chief Executive Officer (CEO) of MHA. In his role, Michael provides global leadership to the entire set of industry practices and horizontal capabilities within MHA. Under his leadership, MHA has become a leading provider of Business Continuity and Disaster Recovery services to organizations on a global level. He is also the founder of BCMMETRICS, a leading cloud based tool designed to assess business continuity compliance and residual risk. Michael is a well-known and sought after speaker on Business Continuity issues at local and national contingency planner chapter meetings and conferences. Prior to founding MHA, he was a Regional VP for Bank of America, where he was responsible for Business Continuity across the southwest region.