What goes in a drone incident report?

A drone incident report has two audiences. The FAA wants a narrow report under Part 107 §107.9 if the event triggered serious injury or significant property damage. The program wants a broader internal report capturing what happened, what almost happened, what equipment and personnel were involved, and what changes the program is making in response. The two reports overlap but are not the same document, and the program that treats the regulatory minimum as its full incident workflow misses most of the learning value.

What Part 107 §107.9 requires

Within 10 days of any operation that resulted in serious injury, loss of consciousness for any person, or damage to property other than the drone itself of at least $500, the remote pilot in command must report the event to the nearest FAA Regional Operations Center. The required fields are short: pilot information, operation details, location, person injured (if applicable), property damaged (if applicable), description of damage, and the aircraft registration number. The FAA's accident reporting page walks through the submission process.

The §107.9 report is short by design. It exists so the FAA can pattern-match across the national airspace, not so a program can learn from its own incidents. NTSB notification is also required separately for events that meet NTSB aircraft mishap definitions. Treating the §107.9 report as a complete incident record misses the operational layer the program needs.

What an internal incident report should capture

Internal incident reports go well beyond §107.9. The standard fields include incident type and severity classification, date and time, location with map reference, weather and operational conditions, equipment serial numbers and pre-flight inspection results, pilot identity and currency status, ground staff present, mission context, the full sequence of events from pre-flight through post-incident, contributing factors, harm or damage assessment with photographs, witnesses including non-program personnel, root cause analysis, corrective actions with named owners and deadlines, and the date the incident was reviewed and closed by the safety lead.

The most important additions over §107.9 are the near-miss layer and the corrective action layer. Near-misses do not trigger FAA reporting but are the leading indicator the program needs. Corrective actions tie the incident back into the program's risk register, training schedule, or SOP library, which is where the report stops being paperwork and starts changing operations.

Why anonymous near-miss reporting matters

Most program-learning happens at the near-miss layer: the pilot who barely avoided a wire, the equipment that behaved erratically before the flight ended, the ground crew that almost moved into the launch zone. Pilots are more willing to surface these if reports can be filed without naming the pilot in the document itself. Anonymous reporting reduces the social cost of reporting so the program sees patterns earlier. The reporter's identity can still be known to the safety lead, but the document in the record store does not require attribution. Near-miss data feeds the risk register and shapes future mitigations in ways the §107.9 dataset alone cannot.

Common mistakes

Treating §107.9 as the ceiling. Programs read §107.9, see the narrow definition of a reportable incident, and stop there. The FAA's reporting threshold is a regulatory minimum, not a program standard. Internal incident reports should capture events well below the §107.9 threshold.

Writing reports as blame documents. When incident reports identify a pilot or ground staff member as the failure point, the next incident will be quieter and slower to surface. Reports should describe what happened operationally, not who is at fault.

Closing incidents without corrective actions. An incident report that ends with "documented and reviewed" has done half the work. Each incident should produce at least one documented change: a training adjustment, an SOP revision, an equipment check, an airspace policy, or a risk register update.

FAQ

When does Part 107 require an incident report?

Within 10 days of any operation that resulted in serious injury, loss of consciousness for any person, or damage to property other than the drone itself of at least $500 to repair or fair market value if not repaired. The report goes to the nearest FAA Regional Operations Center.

Do near-misses need to be reported to the FAA?

No. Section 107.9 only covers events that caused injury or property damage above its thresholds. Near-misses are not externally reportable under Part 107, but they should be captured internally because they are the leading indicator the program needs to prevent the next serious incident.

Who should write the incident report?

The remote pilot in command files the §107.9 report, since the rule names the remote PIC. For internal reports, the program typically uses a safety lead or operations lead who interviews everyone involved, captures the timeline, and owns the corrective action follow-up.

How long should incident reports be retained?

Longer than any other record type. Seven years is a reasonable minimum for routine incidents, and incidents involving injury or significant property damage should be retained indefinitely or for the program's full operational life plus several years after.

Closing thought

A drone incident report serves regulatory compliance and program safety, and the document for each should reflect that. The §107.9 report goes to the FAA. The internal report stays inside the program and drives changes that prevent recurrence. Programs that conflate the two end up with reports that satisfy the regulation but do nothing for safety, or with internal documents that never make it to the FAA when they were required to.

If you are building an incident reporting workflow that captures both regulatory triggers and the near-miss patterns the FAA never sees, FlybyOps was built for the operational record problem at the center of regulated drone work. Incident reporting with anonymous submission, a risk register that tracks identified hazards and their mitigations, a document vault with expiration tracking, and an append-only audit log are all part of how the platform supports safety governance.