The Part 135 Emergency Response Plan
What the SMS Rule Requires — and What Actually Goes In It

Yes — once the SMS rule applies to your operation. The FAA's 2024 final rule extended Safety Management Systems to all Part 135 operators under 14 CFR Part 5, and Part 5 builds the emergency response plan (ERP) into the safety-policy component. Specifically, 14 CFR 5.21 lists an emergency response plan as a required element of your safety policy, and 14 CFR 5.27 — titled “Coordination of emergency response planning” — requires that your accountable executive approve an ERP. So the ERP is not a separate, optional document: it is a mandatory part of the SMS your operation must have in place by the single compliance deadline of May 28, 2027. (Many operators already maintained an ERP voluntarily or under an industry audit standard before the rule; the rule makes it a regulatory requirement.)

In aviation an emergency response plan (ERP) is the documented set of procedures an operator follows the moment a serious event occurs — an accident, a serious incident, a missing or overdue aircraft, a major injury — to transition in a controlled way from normal operations to emergency operations. Under the FAA's SMS framework it is part of the safety policy: 14 CFR 5.21 calls it the means to ensure a “safe transition from normal to emergency operations,” and 14 CFR 5.27 requires it to address, at minimum, delegation of emergency authority through the organization, assignment of employee responsibilities during the emergency, and coordination with the emergency response plans of the other organizations you have to interface with. In plain terms, the ERP answers: who is in charge, who does what, who do we call, and how do the pieces fit together — written down before the bad day, not invented during it.

At the regulatory floor, 14 CFR 5.27 requires three things: (1) delegation of emergency authority throughout the organization, (2) assignment of employee responsibilities during the emergency, and (3) coordination of your ERP with the ERPs of the other organizations you must interface with when providing your service. Most usable Part 135 ERPs go further and add: an activation trigger and notification call tree; a designated emergency director and a clear succession line; an emergency operations center or check-in procedure; required external notifications (the mandatory NTSB notification under 49 CFR Part 830 is its own legal obligation on its own clock); a family-assistance and next-of-kin approach; a media and communications protocol so only authorized people speak; coordination with airports, FBOs, handling agents, and local responders; aircraft recovery and scene-preservation steps; and a post-event records and debrief process. FileFlo does not write these for you — but once they exist, it stores, versions, and date-stamps the ERP and the records that prove you trained and drilled it.

Two answers, and both matter. First, accountability: 14 CFR 5.27 requires that the operator's accountable executive — the single person identified under 14 CFR 5.25 who has control over the operation's resources and bears ultimate responsibility for the SMS — approve the emergency response plan. Second, execution: 14 CFR 5.23 requires the safety policy to define safety accountability for all members of management for developing, implementing, and maintaining SMS processes in their area, so day-to-day ERP ownership typically sits with a director of safety or accountable manager, while specific roles (emergency director, notifications, communications, family liaison) are assigned to named positions in the plan itself. The point of the ERP is to pre-assign authority and roles so that when an event happens, nobody is asking “who's in charge?” The accountable executive cannot delegate away the ultimate accountability — only the tasks.

The ERP lives inside the safety policy component of your SMS. The FAA's Part 5 SMS has four components — safety policy, safety risk management, safety assurance, and safety promotion — and the emergency response plan is explicitly part of the first one. 14 CFR 5.21 lists it among the required contents of the safety policy, and 14 CFR 5.27 (“Coordination of emergency response planning”) is the section that spells out what it must address and who approves it. That placement is deliberate: emergency preparedness is a policy commitment from the top of the organization, not a back-office checklist. It is distinct from safety risk management (which is about identifying and controlling hazards before they cause harm) and from safety assurance (which is about monitoring whether your controls are working). The ERP is what you do when something goes wrong anyway.

A template is a fine starting point, but a generic ERP template is not, by itself, a compliant emergency response plan. 14 CFR 5.27 requires coordination with the specific other organizations you interface with — your actual airports, FBOs, handling agents, and local responders — and assignment of responsibilities to your actual people and positions. A downloaded template that still says “[insert operator name]” and lists no real phone numbers, no real succession line, and no coordination with your real partners does not meet the standard, and an inspector will see that immediately. Treat a template as scaffolding: tailor the authority delegation, the call tree, and the external coordination to your operation; get it approved by your accountable executive; train your people on it; and exercise it. Then keep the approved, current version — and the records proving you trained and drilled it — retrievable. That last part is exactly what FileFlo is for; it does not author the plan.

No. They are two different obligations, and your ERP should make that crystal clear rather than blur it. The mandatory notification of an aircraft accident or certain serious incidents to the National Transportation Safety Board is a separate legal requirement under 49 CFR Part 830 — it runs on its own immediate timeline and is not satisfied by activating your internal ERP. A good ERP includes the NTSB notification (and any required FAA notification) as a step in the response, with the responsible person and the contact information pre-identified, but the ERP is the operator's internal coordination plan, while the Part 830 notification is a federal reporting duty. Confusing the two is dangerous. For anything touching an actual accident, serious incident, or enforcement exposure, involve an aviation attorney immediately — this article is compliance-document information, not legal advice.

FileFlo is the document and proof layer around your ERP — not the author of it. Once you (or your safety consultant) have written and your accountable executive has approved the plan, FileFlo classifies and indexes it as a controlled SMS document, version-controls every revision so the current approved ERP is unambiguous and superseded versions are retained, and tracks the records that prove the plan is live: emergency-drill and tabletop-exercise records, ERP training completions, annual review and approval dates, and the contact lists that go stale fastest. When an FAA inspector or an industry auditor asks you to produce the approved ERP and evidence that you trained and exercised it, you hand over a current, dated, complete set instead of hunting through inboxes. What FileFlo does not do: write your ERP, run your SMS, conduct your drills, make your NTSB notification, interact with the FAA, or give legal advice.