In my previous blog I wrote about safety reporting regulatory requirements based on ICAO and (EU)
When all management levels actively endorse safety as a priority it will encourage personnel to report
more and more safety related events either through mandatory or voluntary reporting system.
As a result, safety office will daily receive a significant number of safety reports that would be
impossible to manage effectively without adequate software support.
In this blog I am going to describe safety office team daily tasks and how these tasks have to be
supported by appropriate software solution.
PROCESSING NEW SAFETY REPORTS
Perform daily overview of all previous and new received safety reports
Safety office team should be able to have a quick overview of all safety reports ever received. Reports
should be searchable by various attributes and filtered by status/activity described below.
Identify new received safety reports
New safety reports are just received safety reports waiting to be processed/managed.
“Every safety report shall be managed” shall be our policy. Therefore every new safety report has to
be somehow processed based on its content and applicability.
Is occurrence already reported?
When more than one report have been received for the same occurrence (e.g. from captain, first
officer, purser, any cabin crew member, Flight Data Monitoring, external source, … ) all of them should
be grouped and analyzed together inside the same investigation.
If our organization is not accountable for reported occurrence, the software solution should be able to
generate “Outgoing safety report to external service provider” and reroute this report for further
investigation to selected external organizations (e.g. Ground service provider, Airport authority, ATM,
…). This action has to be documented and stored in the system for further tracking of accountable
Sometimes reports received are about not safety related occurrences. For an example, if it is about
security related event, we should redirect it to Security department, if it is about code-share or wet
lease-in operation event important for compliance monitoring purposes, we should redirect it to
Report might also be out of above mentioned scope and therefore consequently rejected, but in a
controlled manner – nothing done, but still recorded by the system.
Mandatory or not mandatory reportable occurrence?
As mentioned in my previous blog, we should not put reporters into position to decide by themselves if
certain occurrence is mandatory reportable or not. Therefore, this should be one of the first actions
upon receiving new safety report. If the received report is about one of mandatory reportable
occurrences listed in applicable regulation (e.g. (EU) No 2015/1018) or standard (e.g. IOSA), the
mandatory classification label has to be assigned and due dates for exchanging data with applicable
NAA (National Aviation Authority) have to be calculated automatically (e.g. in EU 72 hours for initial
notification, 30 days for follow up report, 90 days for final report).
Assign investigator for new reportable occurrence
The most common option how new safety report will be processed is to assign investigator with
appropriate competence and domain knowledge to perform investigation. Software should send an
email notification to him/her and lock the report preventing anyone else to perform any action on this
When investigator completes the investigation, system should send notification to the safety office for
investigation approval. If approved, report will be labelled as “closed”. If not, the investigation will be
reopened for additional activities.
Report investigation is an important and demanding task and will be covered more detailed in my
TIPS AND TRAPS
Keep reporters in the loop! Initial feedback to the reporter is a formal confirmation that his/her report
has been received. Investigation closing feedback would be appreciated by the reporter as formal
information that investigation of his/her safety report has been closed and as brief description of
Safety report with unknown reporter's name is considered Anonymous. For external reporters it might
be beneficial to have the option to stay anonymous as they are not part of our company culture.
Internal reporters should instead have confidence in the Just Culture of the company and
confidentiality (no name goes out of safety office) guaranteed by the safety office. In addition,
reporters should be protected by applicable law (e.g. in EU are protected as defined in (EU) No
In smaller companies even anonymized (without personal details) safety reports directly visible to all
staff might have negative effect on reporting. Declaring all safety reports confidential by default (only
visible to safety team) would solve this. Someone might object regarding sharing safety data contained
in safety reports. I would say, do not share raw safety data, share safety information instead (see
ICAO Doc 9859 Fourth edition for difference between safety data and safety information).
Don't ever forget that the only purpose of managing safety reports is improving the safety. Therefore
by default stay by your reporters. Don't give up even when judicial system attacks the aviation legacy
of trustful exchange of “what went wrong” information for the benefit of our common safety.
Trust can not be bought, one wrongly managed case can destroy work of many years and even more
years would be needed to re-establish the trust again. And without trust of our reporters we cannot
speak about Just Culture or Effective Reporting.
Aviation Safety and Compliance Consultant