ERP for drones: the remote pilot's emergency response plan

The ERP - Emergency Response Plan - is the document that says what to do once control of a drone operation has been lost: who to alert, in what order, and how to limit the consequences of a crash, a collision or a flyaway.

⚠️ Outside aviation, ERP usually means enterprise resource planning, and in French it also names a building open to the public. In drone regulation, ERP always means the emergency plan: it is the term used by EASA, JARUS and national authorities.

What it is not: an emergency procedure

This is the most common confusion, and the SORA methodology settles it clearly. It separates three levels of response:

• contingency procedures bring an abnormal situation back under control, such as a weakening battery or a temporary link loss;
• emergency procedures deal with the aircraft itself once it is out of control: flight termination, parachute, forced landing;
• the ERP starts where the aircraft no longer matters. It handles the secondary effects of a loss of control - an injured person, a fire, a struck aircraft - and coordinates the response with emergency services.

Put simply, an emergency procedure is played out on the remote controller. The ERP is played out on the phone. The SORA 2.5 main body states it plainly: the ERP does not deal with the control of the UA.

What it must contain

SORA 2.5 places it under operational safety objective OSO #08 (operational procedures are defined, validated and adhered to). Its Annex E sets a minimum content:

1. the list of anticipated emergency situations that may have secondary effects;
2. a procedure for each of them, including the criteria used to recognise the situation;
3. the list of relevant contacts: air traffic control, police, fire brigade, first responders.

It adds four expected qualities. The ERP must be suitable for the situation, effectively mitigate the anticipated secondary effects, clearly assign duties among the crew, and be practical and trained, so that it can be executed under stress.

The last point is the one people forget. An ERP nobody has ever walked through is a plan in name only.

Proportionate to the risk, not to the paperwork

Annex E specifies that the ERP should be proportionate to the possible secondary effects of a ground impact, such as a fire or a release of toxic gas. A 900-gram drone over a field and a 25-kilo multirotor over an industrial site do not call for the same plan.

The level of evidence follows the same logic. At low assurance levels, the operator declares that the ERP is adequate. At high assurance, a tabletop exercise is expected, and a competent third party validates that it is representative. The exercise may involve the third parties named in the plan, such as the fire service or the site manager.

What changed with SORA 2.5

In earlier versions of the methodology, the ERP counted as a ground risk mitigation: having one could lower the risk class. SORA 2.5 removed it from the mitigations and attached it to operational procedures instead.

The practical consequence: an ERP no longer lowers your level of requirements. It is part of what you must demonstrate, whatever that level is.

A general plan, and a sheet per site

A useful ERP has two layers.

The first is general. It lives in the MANEX, the operations manual: anticipated situations, procedures, roles, the alert chain. It changes little.

The second is specific to each job. This is the one that serves in the field:

• the exact coordinates of the site, to read out to emergency services;
• the nearest hospital and fire station, with their access routes;
• local contacts: client, site manager, air traffic control unit;
• the assembly point and access for emergency vehicles;
• the risks specific to the place: stored products, power lines, public present.

A generic ERP, copied from one job to the next, fails exactly here. On the day it is needed, nobody has time to look up the hospital's address.

When it is required

In the Open category, no formal ERP is required. Having the useful numbers and the site address ready remains good practice.

In the Specific category, it is part of the file: it is expected under OSO #08 in a SORA assessment, and the operations manual carries it. It is one of the documents the authority looks at, because it shows whether the operator has thought about what comes after.

Key takeaways

1. The ERP is not a flight procedure. It starts when the aircraft no longer matters.
2. At a minimum it contains the anticipated situations, a procedure for each, and the contacts to reach.
3. It is proportionate to the possible secondary effects, not to the size of the file.
4. It is trained. A plan never rehearsed does not hold under stress.
5. It is broken down by site. The field sheet is what saves time.

Going further

• SORA for drones - the risk assessment methodology that requires the ERP in the Specific category.
• MANEX - the operations manual that carries the general ERP.
• JARUS - the group of authorities that publishes SORA.