By the time you read this, it will be 2026 and the EASA SMS requirement that applies to U.S.-based repair stations with EASA 145 privileges should be fully implemented. Congratulations, you’ve got an SMS!
The EASA SMS regulation applies indirectly to U.S.-based repair stations through the FAA-EASA Bilateral Aviation Safety Agreement and its implementing guidance. This means that U.S.-based repair stations do not have to comply directly with the EASA SMS regulations. Instead, the SMS provision is declared as a “special condition” and the current implementation mode is for the U.S.-based repair station to establish a “voluntary” SMS that meets the requirements of 14 CFR Part 5. FAA acknowledgement of the repair station’s participation in the voluntary program is (currently) sufficient to meet the requirements. But that is not the end of your SMS adventure. It is only the beginning.
You need to operate your SMS effectively in order to extract safety value from the system. You also need to manage the care and feeding of your SMS. Care comes in the form of working in accordance with the processes defined within your SMS: Safety Policy, Safety Risk Management, Safety Assurance and Safety Promotion. Feeding reflects the data that you feed into your system in order to assess risk, assess the success of mitigations, and generally assess the safety performance of your organization (including through the recording of the SMS elements like hazards, risks, and mitigations).
Ideally, you should be continuously receiving data on your safety performance. This data might show that your system is working well or it may reveal safety hazards that should be considered in a risk assessment. This is one of the things that makes SMS different (and that potentially makes it superior to other programs): the program should have mechanisms for obtaining data on a consistent basis and analyzing that data.
Record Your Data
It is important that you have a way to record the safety data generated by, and provided to, your SMS. A hazard that might not seem to need mitigation today might be subject to mitigation in the future if (a) your original risk assessment is shown to be incorrect (e.g., the safety hazard occurs more often or with greater safety effect than previously calculated), (b) your safety assurance mechanism suggests that the mitigations targeting this hazard are not effective in reducing the risk to an acceptable level, or (c) your safety goals change in a way that requires the safety mitigation (or further mitigation) of the identified hazard.
For many years I have promoted the creation of a relational database that lists all recognized hazards and their risk assessment metrics. This should include both initial risk assessments and post-mitigation risk assessments.
For example, obtaining parts that do not meet correct specifications is a hazard. The related unmitigated risk is typically unacceptable. Because the risk is unacceptable, a number of related mitigations are required by law. For example, receiving inspections are typically a required part of the quality system under Part 145. Related mitigations may include receiving inspector training, supplier audits, or special measurement equipment, to support the inspections.
In addition, though, the relational database should identify the mitigations, and connect each one of those mitigations to one or more hazards. The mitigations are the procedures and processes used to reduce the risk (of a hazard) to an acceptable level. Each of these mitigations should be identified in the relational database, and they should also be connected to the hazards that they mitigate. Recognize that one mitigation may actually respond to more than one hazard, and each hazard may have more than one mitigating process that collectively reduce the risk of that hazard to an acceptable level. This is the first reason for the relational database, so that you can record these often complex relationships.
Starting the SMS Database
If you are just starting out, and want a good way to start, then I recommend that you populate your company’s hazard database with your company’s existing processes. Each process is meant to accomplish a goal. Those goals can be recharacterized as avoided hazards. The example, above, of the receiving inspection processes being tied to the hazard of improperly received goods is a good specimen of the sort of thing that can be identified as a pre-existing hazard-mitigation pair. By identifying your pre-existing hazard-mitigation relationships, you start to better understand how your system works, you may identify processes that don’t appear to have a function (and thus will need further review), and most importantly you are creating a useful tool for using SMS to help guide future change management (we will return to this change management idea in a few paragraphs).
You will also want to have a mechanism for reviewing the SMS data in order to support continuous improvement. Part of this is using your database to feed data into your safety assurance program. You should be scheduling safety audits (or other safety assurance activities) for your mitigation processes to assess (1) whether the process is correctly implemented, and (2) whether the process is achieving the intended results.
Another important relationship to record is data generated by your safety assurance processes, which may include (but not be limited to) audits assessing the success of your implemented safety mitigations. One way to record this might be to provide an anticipated risk assessment when a mitigation process is developed, and a corrected risk assessment once the process has been audited. Another mechanism could be to simply record the findings associated with the process, to use those findings to help drive future process improvements and innovations.
It is a good idea to use your safety promotion mechanisms to communicate the new processes, and to train on them, to improve the chance that they will be successful in driving the behavior that you want to drive. By providing a brief summary of your safety assurance data (what is working and what is not), you can help your employees and business partners understand how your system is changing and why those changes are important to the business’ safety improvement efforts.
Change Management
Remember the relationships that we described earlier in the article: hazards, related to risks, which are in turn related to mitigations? Part of the value of a robust database is that it becomes a useful tool for change management. If you plan to change a procedure and it is identified in your relationship database, then you can see which hazards are mitigated by this procedure.
This allows you to assess whether your proposed change will affect the way that the related hazard(s) are mitigated by the process change. This helps to avoid unintended consequences that undermine past safety mitigations.
By using your SMS as a change management tool, you now have data to drive your change management analysis, instead of relying on mere conjectures about the likely effects of a change. The SMS database should not be your only tool in analyzing changes, but it can be an important one.
