top of page
Search

Navigating the Aftermath: A Guide to RPAS Incident and Accident Reporting in Canada (2026 Update)

By: Colonel (ret) Bernie Derbach, KR Droneworks academy, 03 May 26



In the Canadian drone industry, the legal distinction between an "occurrence," an "incident," and an "accident" is a regulatory mandate. With the latest updates to TC AIM-RPAS 3.2.37 and the implementation of Level 1 Complex (L1C) regulations, staying compliant means knowing exactly what must be reported—and to whom.  





1. Defining the Terms: Incident vs. Accident


The Transportation Safety Board (TSB) Regulations and TC AIM-RPAS 3.2.37 categorize occurrences based on severity, weight, and the nature of the operation.  


What is a Reportable Accident (TSB)?


According to the TSB, a reportable occurrence (accident) happens when:  


  • Serious Injury or Death: A person is killed or sustains a serious injury (e.g., broken bone, internal organ damage) as a result of being in the aircraft or coming into direct contact with any part of the RPA, including detached parts.

  • Structural Failure or Substantial Damage (> 25 kg): For RPAs with an MTOW of more than 25 kg, it is an accident if the aircraft sustains structural failure or damage that adversely affects its performance and normally requires major repair.  

  • Missing/Inaccessible: The aircraft is missing or completely inaccessible.  


What is an Incident?


For small RPAs (250 g to 25 kg), "incidents"—such as a fly-away with no injury—are managed through internal record-keeping and Transport Canada (TC) reporting unless they involve a "risk of collision" with a manned aircraft.  


2. The Regulatory Core: CAR 901.49


A pilot who operates an RPA shall immediately cease operations if any of the following occur, until an analysis is undertaken as to the cause and corrective actions are taken to mitigate the risk of recurrence:  


  • (a) Injuries to any person requiring medical attention.  

  • (b) Unintended contact between the aircraft and persons.  

  • (c) Unanticipated damage to the airframe, control station, payload, or C2 links that adversely affects performance or flight characteristics.  

  • (d) Any time the aircraft is not kept within horizontal boundaries or altitude limits.  

  • (e) Any collision with or risk of collision with another aircraft.  

  • (f) Any time the aircraft becomes uncontrollable, experiences a fly-away, or is missing.  

  • (g) Any incident resulting in a police report or a CADORS report.  


Mandatory Retention: You must keep a record of these analysis reports for 12 months and make them available to the Minister on request.  

3. Reporting for Level 1 Complex (L1C) Operators


For those holding an RPAS Operator Certificate (RPOC) for L1C operations, reporting is not always about notifying TC immediately for every glitch. Instead, it is about maintaining a Safety Management System (SMS).  


Internal Reporting & SMS Logic


The requirement for advising Transport Canada of a system failure for Level 1 Complex (L1C) operations is managed through a combination of mandatory Internal Processes (required for the RPAS Operator Certificate) and Service Difficulty Reporting (mandated for the system's declaration holder).


While AC 901-002 does not use the specific phrase "report every system failure to TC," it mandates that an RPOC holder establish a Safety Management System (SMS) that formalizes how these failures are handled.  


A. The "Internal" Reporting Mandate: CAR 901.218 & AC 901-002


To hold an RPOC, you must establish an internal reporting system.


  • CAR 901.218(1)(d): Explicitly requires an RPOC holder to establish processes for "internally reporting and analyzing hazards, incidents and accidents and taking corrective actions to prevent their recurrence".  


  • AC 901-002, Section 8.2 (Contingency Procedures): This section requires the operator's manual to document procedures for dealing with "Equipment failure," specifically listing GPS, power sources, and GCS failure.  


  • AC 901-002, Section 10.1 (iv): Directs the operator to include "occurrence reporting procedures" in their manuals to satisfy the requirements of the RPOC.  


B. The "External" Reporting Mandate: CAR 901.197 (Service Difficulty)


The direct link between a system failure and a report to the Minister (Transport Canada) exists at the Declaration level.

  • CAR 901.197 (Service Difficulty Reporting System): The person who makes the safety assurance declaration for an L1C-capable system (often the manufacturer or a specialized operator) must establish and maintain a service difficulty reporting system.  


  • CAR 901.198: Requires that the person who made the declaration investigate the service difficulty and notify the Minister if it is found to be a systemic safety issue.  


C. Summary of Reporting Paths for L1C


For an L1C operator, a "System Failure" is handled as follows:  


Type of Reporting

Reference

Action Required

Internal Safety Report

CAR 901.218(1)(d) / AC 901-002

Recorded in company SMS and kept for 12 months for TC audit.

Service Difficulty

CAR 901.197

Reported to the person/entity that issued the Safety Declaration for that specific drone.

Ministerial Notification

CAR 901.198

Triggered if the failure indicates a design or systemic flaw that could affect other operators.


In short: You do not typically report a one-off technical glitch directly to the Minister unless it meets the definition of an accident or serious incident. Instead, as an RPOC holder, you must prove through your manuals (guided by AC 901-002) that you have a process to capture and analyze that failure internally to mitigate future risk.


  • Mandatory Internal Process: Per CAR 901.218(1)(d), an RPOC holder must establish processes for internally reporting and analyzing hazards, incidents, and accidents and taking corrective actions.  


  • Company RPOC Documentation: It is a best practice to explicitly write these internal reporting steps into your company’s RPAS Operations Manual. This demonstrates to TC during audits that you have a proactive safety culture.  


  • System Failures: While AC 901-002 focuses on manual development, its guidelines on contingency procedures (Section 8.2) for equipment failures (GPS, GCS, C2) serve as the foundation for what your SMS must capture and analyze internally and if a report to Transport Canada is warranted or not.


  1. Key Regulatory Summary


The TSB Mandate

The TSB is the primary body for external aviation safety reporting in Canada. You must call their 24-hour line at 1-800-387-3557 for any occurrence involving:  


  • A serious injury or death caused by an RPA of any size (250g to 25kg).

  • An accident involving an RPA weighing more than 25 kg.  


  • A collision between any RPA and a manned aircraft.  


The Transport Canada Mandate (CAR 901.49)


For standard Basic, Advanced, and Level 1 Complex operations, Transport Canada’s role is oversight rather than immediate notification.  


  • Mandatory Analysis: Pilots must stop operations and analyze any occurrence listed in CAR 901.49 (e.g., fly-aways, boundaries exceeded, minor injuries).  


  • 12-Month Record: The pilot must keep a record of this analysis and make it available to the Minister (TC) on request.  


  • SFOC Reporting Exception: If you are flying under an SFOC, you must use the reporting form issued with your certificate to advise TC of any occurrence.  


5. Summary Reporting Table

*Unless it results in a risk of collision with a manned aircraft.  

Occurrence Type

Report to TSB?

Report to TC?

Requirement Under Part IX

Serious Injury or Death

Yes (Immediate)

Only if SFOC

Cease Flight + Mandatory Analysis

Collision with Manned Aircraft

Yes (Immediate)

Only if SFOC

Cease Flight + Mandatory Analysis

RPA > 25 kg Accident

Yes (Immediate)

Only if SFOC

Cease Flight + Mandatory Analysis

Fly-away / Loss of Link

No*

Only if SFOC

Cease Flight + Mandatory Analysis

L1C System Failure

No

Only if SFOC

Internal SMS Analysis / Logbook Record

*Unless the event results in a collision or risk of collision with a manned aircraft. 


6. Special Case: Tethered RPA (TC AIM 3.2.38)


  • Not an RPA: An RPA tethered to the ground, hovering at a specific location without pilot input (e.g., boosting a signal), is not considered an RPA. It must meet CAR Standard 621 Chapter 11 instead.  


  • Is an RPA: If the RPA is being maneuvered or navigated by a pilot while on a tether, Part IX applies fully.


References

 
 
 

Comments


  • alt.text.label.Facebook

Providing RPAS Flight Reviews and Drone Training across Ontario and Canada.

©2023 by KR Droneworks. Proudly created with Wix.com

bottom of page