EU 376/2014 Occurrence Reporting Requirements, Explained

The regulation applies across European civil aviation and reaches both organisations and the individuals working in them. Its purpose is not to punish, it is to make sure occurrences that could affect safety are collected, analysed and acted on before they line up into an accident. To do that, it standardises four things: what gets reported, how fast, how it is stored, and how it moves.

There are two reporting streams. The mandatory stream covers defined categories of occurrence that must be reported; the exact categories are laid down in the applicable EU implementing rules, so always work from the current list rather than an old copy. The voluntary stream covers anything else a person believes could be a hazard, even when it does not fit a mandatory category. Both streams carry the same downstream duties, and both sit under the same protection.

The reporting deadline that people remember is the 72-hour window: an individual reports an occurrence within 72 hours of becoming aware of it. From there, the obligations shift to the organisation, which must:

• Collect and store each report in a structured occurrence database.
• Assess it, and investigate or follow up where the content warrants.
• Analyse the information it holds to identify hazards and trends.
• Take and track corrective or preventive action.
• Transfer the report to the national competent authority.

The storage requirement is the part that surprises teams. Occurrence data must live in a database that is ECCAIRS-compatible and classified using the ADREP taxonomy, ICAO's structured coded vocabulary for describing what happened. Exchange runs on the E5X format, a zipped XML file that carries ADREP-coded reports, and the destination platform is ECCAIRS 2. If you want the mechanics of those three names in plain language, the companion piece on ECCAIRS 2, ADREP and E5X walks through them and what they imply for your internal system.

A reporting rule only works if people report, and people only report when they trust that speaking up will not be used against them. That trust is written into the regulation, not left to goodwill. Article 16 sets the just-culture protections that make the reporting streams function.

Two ideas do most of the work:

• Information is for safety, not blame. Details from occurrence reports are used to maintain or improve safety, and are not intended to attribute fault or liability.
• Reporters are protected. Individuals are shielded from disciplinary, administrative or employment consequences on the basis of an occurrence they report, with narrow exceptions for cases such as gross negligence or wilful misconduct. Reporter identity is protected and reports are handled confidentially.

In operational terms this means de-identification is a design requirement, not an afterthought. The person who receives, codes and analyses a report should be able to work the safety content without ever needing to expose who filed it, and the wider organisation should see de-identified output. If you want the practical version of this, our note on just culture in five questions frames the boundary between honest error and unacceptable behaviour, and the closed just-culture loop shows how confidential intake can still end in a de-identified bulletin and reporter feedback without breaking that protection.

Put the obligations in order and a compliant occurrence-reporting process is a clear lifecycle, not a pile of tasks. Each step exists because the regulation asks for it, and each one produces the record the next one needs.

• Capture. The occurrence is reported within the 72-hour window through an accessible, confidential channel, and lands as a structured record rather than an email in someone's inbox.
• Acknowledge and protect. The reporter is acknowledged, and identity is separated from the safety content so the report can be worked de-identified.
• Classify. Key attributes are coded against the ADREP taxonomy at intake, so the record is exchange-ready and comparable with every other report, not a one-off free-text note.
• Assess and investigate. The occurrence is risk-assessed, and an investigation is opened where the severity or the pattern warrants it.
• Act. Corrective and preventive actions are raised, owned and tracked to closure, so a hazard does not simply get logged and forgotten.
• Transfer. The report is passed to the national competent authority in ECCAIRS-compatible form, within the timeframe the regulation sets.
• Analyse and feed back. Reports are aggregated to find hazards and trends, and reporters see that something happened as a result, which keeps the reporting flowing.

The steps that produce and close actions are where a lot of programmes leak, which is why the corrective-action loop, handled in the Actions module, matters as much as the intake handled in the SMS module. Capture without closure is a filing cabinet, not a safety system.

The single most common gap is the same one every audit finds: organisations build the intake and stop. A tidy reporting form, a monthly count of reports received, and a sense that the box is ticked. But the regulation does not ask only that occurrences be collected. It asks that they be analysed to identify hazards and that follow-up action be taken. Intake is the easy part of the obligation. The analysis, the closure and the feedback are the rest, and they are what actually reduces risk.

The failure modes cluster into a handful of patterns:

• Actions that never close. Corrective actions are raised but not tracked, so open risk lingers with nobody accountable.
• No aggregate analysis. Each report is handled in isolation, so the trend that three near-identical events would reveal is never seen.
• Silent reporters. People file and hear nothing back. Reporting volume drops, and the just-culture loop quietly breaks.
• Weak taxonomy coding. Occurrences are stored as free text, so nothing can be compared, aggregated or exchanged cleanly.
• Spreadsheet transfer. The data cannot produce a compatible file, so staff re-key every report into a portal by hand, which is slow, error-prone and does not scale.

Each of these is a place where the letter of the regulation is met on the intake page and missed everywhere after it. The fix is not more reporting; it is connecting the report to its consequences. When an occurrence links to its investigation, its corrective actions and the indicators it moves, the analysis-and-follow-up obligation stops being a manual chore and becomes a property of the system, as our note on connecting occurrence, CAPA, SPI and the Safety Risk Profile lays out.