Occurrence reporting: Regulation 2026/1821 changes the lists
Commission Implementing Regulation (EU) 2026/1821 replaces Annexes I to V to Regulation 2015/1018 and adds Annex VI on occurrences from unmanned aircraft system (UAS) operations. It enters into…

The easiest change to miss is one that adds no new form but moves the boundary of what you must be able to recognise as a reportable occurrence. That is how I read Commission Implementing Regulation (EU) 2026/1821 of 27 July 2026 amending Implementing Regulation (EU) 2015/1018. In my assessment, this is not just another update to note in a register of regulatory changes. The list of occurrences begins to reflect the digitalisation of aviation and the presence of unmanned aircraft in the same airspace in which we fly.
What exactly changes
Regulation 2015/1018 contains the list of occurrences subject to mandatory reporting under Regulation (EU) No 376/2014. The new rules amend that list. Under Article 1, the existing Annexes I, II, III, IV and V are replaced by new annexes with the same numbers. Annex VI is added, covering occurrences specific to the operation of unmanned aircraft systems (UAS). A separate annex is meant to protect the existing classifications for manned aircraft.
The regulation was published in the Official Journal of the European Union on 28 July 2026. Under Article 2, it enters into force on the twentieth day following publication, which is 17 August 2026. It is binding in its entirety and directly applicable in all Member States.
Three groups of new items appear in the list. The first is occurrences related to traffic management in U-space airspace and U-space service provider (USSP) services. These include UAS operations that do not comply with the conditions and restrictions of the airspace, and missing, incorrect or delayed USSP information that endangered or could have endangered an aircraft or a person. The second is information security occurrences, for example malware, DDoS attacks and data compromise. The third is additional occurrences for UAS operations with persons on board, including crew incapacitation and contaminated cabin air. Annex VI applies to operations requiring a certificate or a design declaration, because they inherently carry a higher risk profile.
Some aviation security occurrences have been removed or reorganised to avoid duplication with the aviation security rules. Occurrences with consequences for both safety and security, such as fires or laser interference, are reported to both the safety authorities and the security authorities.
Transitional period for security occurrences
Here it is worth taking care not to remove obligations from procedures too early. Until 31 December 2027, reporting under 2015/1018 continues for bomb threats or hijackings, airport security occurrences and failure to follow arrangements concerning baggage or passengers. In the new annexes, this concerns point 4 of Annex I and point 8 of Annex III. Reporting of security incidents under Regulation 2026/247 begins on 1 January 2028. Until then, I would not assume that the security categories have ceased to apply.
Information security is not only an IT matter
From the perspective of maintenance and continuing airworthiness management, this is the most interesting part of the changes for me. Maintenance records, work planning, component records and the status of airworthiness directives are today mostly electronic. I am a supporter of digitalisation myself, because a well-designed system reduces manual transcription errors. It does, however, have a price.
Let us suppose that, as a result of unauthorised interference with a system, the flight hours of an aircraft change. The software calculates the next maintenance from an incorrect value and shows the wrong due date. Or someone modifies the data on the accomplishment of an airworthiness directive. At first the problem concerns data, but the effect reaches the safety of operations. For that reason I would not treat information security as a purely IT issue.
At the same time, not every unavailable application or server failure is a reportable occurrence. It is necessary to establish what happened, which data or functions were affected and whether the event meets the criteria in the list. An ordinary technical failure is worth distinguishing from an information security incident. What matters most to me is that information about a problem that could affect aviation safety does not stop with the user of the application or its provider. It should reach the person who will assess the consequences for aviation activity.
The change to the list also does not automatically mean an obligation to implement Part-IS or a new SMS in every organisation. Those obligations are assessed separately, under the rules applicable to the given activity.
U-space and drones: first the scope of your own activity
The new U-space occurrences and Annex VI can tempt people to make quick decisions. I see no justification for re-equipping an entire fleet or rebuilding procedures solely because the regulation has entered into force. First it is necessary to establish where and under what rules the organisation conducts operations, and whether they may involve U-space airspace. I would not equate the scope of Annex VI with every drone operation. The conditions for its application need to be read, including the references to a certificate or a design declaration.
Where I would start in CAO, CAMO and Part-145
Every change in the rules brings the temptation to add new forms and registers. I am not a supporter of that approach. I would start with a review of the existing occurrence reporting system and go through Annexes I to V with regard to your own activity, and Annex VI where UAS operations are involved.
In a CAO, I would check whether the procedures in the CAE make it possible to recognise occurrences from the current list, assess them and submit a report. In a CAMO, I would focus on the reliability of data on flight hours, completed maintenance, airworthiness directives and component status. In a Part-145 organisation, I would verify the flow of information between mechanics, the persons responsible for safety and the entities operating the information systems.
Everywhere I would ask the same question: does the person who detects an irregularity know whom to report it to and how? The best-written procedure achieves little if a mechanic, an airworthiness management employee or a system administrator does not know how to react. If the process works, it is often enough to supplement the criteria for classifying occurrences, update the legal references and discuss the changes with staff. In training organisations and flying clubs, a short discussion of a few concrete situations at a briefing will do more than sharing a lengthy document. This is my recommendation, not an implementation procedure imposed by the regulation.
In closing
The regulation shows the direction of change well: safety today is determined not only by the technical condition of the aircraft and the correctness of maintenance, but also by the reliability of data and the exchange of information between participants in aviation activity. A well-implemented rule should improve safety, not increase the number of documents. I encourage you to read the full text of the regulation, especially the annexes relevant to your activity.
About the author
Adrian Nafalski, MSc Eng.
Specialist in aircraft maintenance and continuing airworthiness management. Holder of an EASA Part-66 licence in categories B1.2, B1.4, B2 and C. He also works on avionics, the digitalisation of aviation processes and the use of artificial neural networks in technical diagnostics. Originator of the Aeronite community.