A high level of transparency in aviation safety management systems (SMS) is critical for creating:
I think most, if not all, aviation safety managers would agree with me on this. Aviation safety data security is commonly under the control of an SMS administrator, who may also be the director of safety.
Safety managers are safety professionals and are not data security professionals.
This is undoubtedly why safety managers have many questions about configuring users' safety roles and permissions in their aviation SMS database. For example, one SMS software may use:
The million-dollar question is: "What is the best practice for organizing access to safety information?"
While this seems like a more practical, "how-to-use-the-software" question, it’s actually a more philosophical question:
But what exactly do we mean when we talk about transparency?
It all comes down to information and what people (are allowed to) know. Transparent safety cultures are cultures that:
The catchword here is relevant. Transparency does not mean everyone has access to all information – it means that if a piece of information affects an employee, he/she has a means of being aware of it. Period.
Of course, there are certain practical considerations here, such as issues that require investigation, etc. With that in mind, what are some best practices for User Roles/Security setup to maintain data security in aviation SMS data management scenarios? Some roles described herein relate to SMS Pro's aviation SMS solution. Your software probably has something similar, so you adopt similar data security strategies.
The first thing that should be done is to, initially, try and set up your security roles for different users as they function in real life. Before assigning any roles, consider and perhaps even map out an org chart of your company with a brief description of what each management personnel is responsible for in the SMS implementation. Organizational charts are useful for visualizing the layout and workflow of safety information within an organization.
For example, your org chart may lead you to have:
Note that one Safety Manager may also have the Admin role if he/she is in charge of maintaining the SMS database configuration.
An Administrator can also assign SMS-Executive roles depending on a larger organization’s more complicated organizational structure, such as the head of HR, CEO, and CFO, as may all likely have vested interests in the aviation SMS.
In this case, as well, an executive may be given a department head role if he/she performs such in real life.
We can consider SMS users as being best suited for general employees.
Some aviation SMS databases allow custom roles. Custom user roles are designed to control what safety issues users can/cannot see.
Again, configuring custom roles in an SMS database properly entails that you have a solid stance on what transparency means for your organization, as well as some common sense. What follows is an example of how one SMS database handles data security. Other programs may do something similar but in a different fashion.
For SMS Pro, the first thing to note is whether the SMS user's role has “View All Divisions” checked. With this "transparency setting," every authorized user will be able to see all reported safety issues in all divisions because every user has the SMS user's role by default once they are trained and inducted into the system. We should note that there will be exceptions to "all issues." For example, we would not want all users to see 'sensitive' reported issues. These sensitive issues may be:
The ability of users to access and modify information from different divisions in the company is of primary concern to how much transparency an organization has. To give you peace of mind, general users can occasionally view reported safety concerns, but they never have the ability to modify SMS data records without being granted additional permissions.
Additional transparency-related issues involve questions like:
Your answers to these questions will determine how transparent (and liberal) your organization is. Approximately five percent of aviation service providers practice almost complete transparency. The remaining 95% are still living in the days of the traditional safety program. If you are old enough, you may remember the traditional safety program, then one that:
Safety cultures take time to mature. Moving away from historical attitudes toward the "safety program" will take at least another generation.
Obviously, a balance between what is practical/ideal needs to be considered with your particular organization. When configuring aviation SMS software, there may be no "perfect setup" because there are so many exceptions and use cases. This becomes more evident with more complex but flatter operations.
When you configure your SMS software, there are some settings, such as "SMS users receiving notification of reported safety issue from all divisions," which are both unwise and impractical. Other things, such as only letting SMS users view their reported safety issues (no checks on the “View” column) clearly subscribe to a lower level of transparency but may be prudent.
Data transparency also depends on whether you are sharing your SMS database software with other organizational units, such as with:
Deciding the proper setup will take:
Every security configuration check (or lack of checking) should be carefully considered. A good rule of thumb for this question is to work from the highest level of access (SMS admin) to the lowest (SMS users).
Remember that designing security access of roles follows a pretty linear process:
Also, remember that granting access down the road will look a lot better than restricting access later on, so perhaps a conservative approach to start is considered a best practice and smart idea.
To see an aviation SMS software solution and its benefits in action, you may be interested in these demo videos.
Have questions? Want to see SMS Pro live? Sign up for a demo.
Last updated June 2024.