What EU 376/2014 asks of
every reporting organisation.

See the highlighted block above the contents list for the short version. The rest of this guide covers the two reporting streams and their deadlines, the just-culture protections, a compliant process end to end, and the analysis-and-follow-up gap that separates a mailbox from a functioning safety data programme.

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.

A system built for EU 376/2014 is not a smarter form. It is a system of record that carries an occurrence from the first confidential screen all the way to closure and analysis, without losing the thread or the protection. eAviora is built as that system.

Reporting starts confidential, with a closed just-culture loop: intake stays de-identified, the report is worked without exposing who filed it, and the loop can still close with a de-identified bulletin and feedback to the reporter. From intake the occurrence enters one operational graph, linked to its investigation, its corrective actions, the audits and findings that touch it, the documents it depends on, and the safety indicators it moves. Because it is one structured record rather than a row copied between tools, it is captured once and never re-keyed to travel between stages.

Two design choices make the difference on the parts operators usually miss. First, enforced closure gates: a record cannot be closed over open risk, so a degraded barrier has to carry a linked corrective action proven effective before the occurrence reads as resolved. That is the analysis-and-follow-up obligation turned into a rule the workflow enforces, not a discipline the team has to remember. Second, real statistical process control on the safety indicators, using Western Electric rules rather than a coloured trend arrow, so the aggregate signal the regulation wants you to find is actually detectable. AI agents assist along the way, but every proposal is human-gated and audit-logged, and consumption is metered in plain credits, so the assistance never becomes an ungoverned black box.

The taxonomy question follows the same principle. The goal is that an occurrence is captured in structured, controlled fields at intake, aligned to the vocabulary the exchange needs, so producing a compatible transfer is a property of clean data rather than a re-keying project. Capture the structure once, and the transfer, the analysis and the audit trail all read from the same record. See the SMS module and the Compliance module for how the intake, the analysis and the evidence sit in one place.