ESFs Aren’t for Everyone

Through the years I’ve had numerous conversations with states, cities, and others about organizing their emergency operations plans (EOPs) around Emergency Support Functions (ESFs). In every conversation I’ve suggested against the use of ESFs. Why?

Let’s start with definitions. One definition of ESFs provided by FEMA states that ESFs ‘describe federal coordinating structures that group resources and capabilities into functional areas most frequently needed in a national response’.  Another states that ESFs are ‘a way to group functions that provide federal support to states and federal-to-federal support, both for Stafford Act declared disasters and emergencies and for non-Stafford Act incidents.’ The National Response Framework (NRF) states that ESFs are ‘response coordinating structures at the federal level’.

The key word in these definitions is ‘federal’. ESFs are a construct originally of the Federal Response Plan (FRP) which was in place from 1992 to 2004. The FRP was a signed agreement among 27 Federal departments and agencies as well as the America Red Cross that outlined how Federal assistance and resources would be provided to state and local governments during a disaster. The ESFs were carried into the National Response Plan in 2004 and the National Response Framework in 2008.

While the NRF, CPG 101, and other sources indicate that other levels of government may also organize their response structure utilizing ESFs, I think any attempts are awkward and confusing at best.

Jumping to present day, the following ESFs are identified in the NRF:

  1. Transportation
  2. Communications
  3. Public Works and Engineering
  4. Firefighting
  5. Information and Planning
  6. Mass Care, Emergency Assistance, Temporary Housing, and Human Assistance
  7. Logistics
  8. Public Health and Medical Services
  9. Search and Rescue
  10. Oil and Hazardous Materials Response
  11. Agriculture and Natural Resources
  12. Energy
  13. Public Safety and Security
  14. Cross-Sector Business and Infrastructure
  15. External Affairs

The ESFs work for the Federal government by providing organizations to address the legal, regulatory, and bureaucratic coordination that must take place across various agencies. These organizations are utilized before (preparedness), during (response and recovery… though ultimately most of these transition to the Recovery Support Functions per the National Disaster Recovery Framework), and after (AAR) a disaster as a cohesive means of maintaining relationships, continuity, and operational readiness. Each of the ESFs maintains a lead agency and has several supporting agencies which also have capabilities and responsibilities within the mission of that ESF.

Where does this fall apart for states and other jurisdictions? First of all, I view Emergency Support Function/ESF as a branded name. The ESF is a standard. When someone refers to ESFs, it’s often inferred that they are speaking of the Federal constructs. ESFs are defined by the Federal government in their current plans (presently the NRF). When co-opted by states or other jurisdictions, this is where it first starts to fall apart. This creates a type of ‘brand confusion’. i.e. Which ESFs are we speaking of? This is further exacerbated if names and definitions of their ESFs aren’t consistent with what is established by the Federal government.

Further, the utilization of ESFs may simply not be the correct tool. It may be the same agencies responsible for transportation as well as public works and engineering. So why have two teams comprised of personnel from the same agencies – especially if bench depth is small in those agencies. Related to this, I’ll say that many jurisdictions (which may even include smaller states, territories, or tribes) simply don’t have the depth to staff 15 ESFs. This is why an organization should be developed for each jurisdiction by each jurisdiction based on their needs and capabilities. It’s simply silly to try to apply the construct utilized by our rather massive Federal government to a jurisdiction much smaller.

Next, I suggest that the integration of ESFs into a response structure is simply awkward. I think in many ways this holds true for the Federal government as well. Is ESF 7 (Logistics) an emergency support function or is it a section in our EOC? The same goes for any of the other ESFs which are actually organizational components often found in response or coordination structures inspired by the Incident Command System.

All that said, the spirit of ESFs is valuable and should be utilized by other jurisdictions in other levels of government. These are often referred to as Functional Branches. Similar to ESFs, they can be used before, during, and after a disaster. Your pre-disaster planning teams become the core group implementing the plans they developed and improving the plans and associated capabilities after a disaster. As functional branches, there is no name confusion with ESFs, even though there is considerable similarity. You aren’t constrained to the list of Federal ESFs and don’t have to worry about how they define or construct them. You can do your own thing without any confusion. You are also able to build the functional branches based on your own needs and capabilities, not artificially trying to fit your needs into someone else’s construct. I’ve seen a lot of states use the term State Support Function or SSF, which is certainly fine.

I will make a nod here though to a best practice inspired by the ESFs, and that is having certain standing working groups for incident management organizational elements (i.e. communications, logistics, information and planning, and external affairs) that may not be organized under the operations section or whatever is analogous in your EOC. Expand beyond these as needed. Recall that the first step in CPG 101 for emergency planning calls for developing a planning team. There is a great deal of benefit to be had by utilizing stakeholder teams to establish standard operating guidelines, job aids, etc. in these functions or others in your EOC or other emergency organizational structure. Often it’s the emergency manager or a staff member doing this, expecting others to simply walk in and accept what has been developed. If people want to work in a Planning Section for your jurisdiction, let them own it (obviously with some input and guidance as needed).

I think ESFs are a valuable means for the US Federal government to organize, but don’t confuse the matter or develop something unnecessary by trying to carbon copy them into your jurisdiction. Examine your own needs and capabilities and form steady state working groups that become functional entities during disaster operations.

© 2021 Tim Riecker, CEDP

Emergency Preparedness Solutions, LLC®

Incident Management vs Incident Command

As I was writing my thoughts on the updated ICS-100 course in my previous post, I got to thinking that it may be prudent to reinforce the difference between incident management and the incident command system (ICS).  ICS is a specific application of incident management, while incident management is, in all, much broader than ICS.  Incident management includes field responses, emergency operations centers (EOCs), activities of secondary and tertiary organizations, funding streams, public information, and even the mechanics of politics focused on that disaster response.  Ideally, we would prefer these to all be orchestrated, such that they operate lock-step, but rarely, if ever, do we see such a thing.  It would be as if a chorus, band, orchestra, stage performers, ushers, concessioners, stage hands, lighting and sound operators, and custodial staff were all working on the same performance and conducted by one person.  They don’t.  It just doesn’t happen that way.  That’s why incident management systems, such as ICS, were developed.

Knowledge and application of systems, like ICS, are certainly important.  The beginning of every ICS class tells you why, so I don’t need to get into that here.  But to continue with my oft criticized analogies, if ICS is the trees, incident management is the forest.  And, as it turns out, many people can’t see the forest for the trees.  While ICS may be concerned with putting out the fire, stopping the bleeding, or catching the proverbial bad guy, incident management is about so much more.  Even doctrinally, consider that the National Incident Management System (NIMS), comprised of key elements, such as resource management, command and coordination (this is the ICS piece, and more), and communications and information management.  We also need to consider incident management beyond these, in as broad a scope as possible.

Incident management is a deliberate series of actions taken to solve problems associated with incidents and disasters.  There are a lot of problems that can be caused, directly or indirectly, by whatever issue we are dealing with, be it flood, fire, or hostile event.  Incident management needs to prioritize these problems and take action to address them.  While it may sound like our incident command system structures do the same type of thing, they are often concerned with immediate effects and actions that save lives and stabilize the incident, as they should be.  But that focus, necessarily, is narrow in scope and doesn’t address all the ancillary and important issues that an incident may cause.

Consider FEMA’s Emergency Support Function (ESF) structure and the matters they address.  Here are a few:

  • Transportation
  • Communications
  • Public Works and Engineering
  • Mass Care, Emergency Assistance, Housing, and Human Services
  • Public Health and Medical Services
  • Agricultural and Natural Resources
  • Energy
  • External Affairs

Do your plans address these issues?  And by plans, I mean real, actionable plans.  Many jurisdictions have functional annexes to their plans, most following the federal ESF structure, which do little more than state what agencies participate in each of the jurisdiction’s ESFs and what their primary goals are.  Let’s be honest… these are aren’t plans.  They are fully inadequate to be plans.  These are prose I might use for the introduction of a plan, but certainly not the substance of the plan itself.  This is exactly why we are missing the mark when it comes to incident management.  We talk a lot about ICS, ICS is in our plans, we train people in ICS (though not as good as we should be), emphasize ICS in exercises, and focus on ICS when an incident occurs, but how much attention is given to broader incident management?  Typically far too little.  I’ve actually had conversations with local public safety officials, asking them how well they feel they are prepared for the next disaster, and they responded that they are fine because they are trained in ICS.  I’ve received this response in more than one jurisdiction.  That’s pretty scary, especially given the lackluster condition of their plans.

Can ICS be applied to broader incident management issues?  It sure can.  It’s simply a management system that can be applied to anything you want.  But the problem is that people conceptualize ICS as something to only use ‘in the field’ and during the more urgent initial period of response.

The take-away from this is that we need to identify what our issues are and how we are going to manage them.  These are essential parts of the planning process.  Write good plans.  Invest time, effort, and likely some money into it.  Do you need to use the ESF structure?  No, but certainly make sure that all concerns are addressed.  Think about the cascading impacts of an incident.  Leverage stakeholders from across the community to ensure that you are getting input from multiple perspectives and interests.  Doing so will help you be better prepared to manage the entirety of the incident.

As always, thoughts are appreciated.

© 2018 – Timothy Riecker, CEDP

Emergency Preparedness Solutions, LLC