A risk-based approach to EHS system auditing
The safety management system is usually the backbone of an organisation’s approach to safety and general EHS risk. These systems provide much-needed structure to an overall risk-based approach to protecting human life. But when it comes to auditing the elements of the safety management system (SMS), there can often be a gap between those elements and the actual risk assessments the business has developed.
Take the example of “worker participation” (ISO 45000) or “workforce involvement” (CCPS), which are typical SMS elements. How often would that appear as a risk control measure in our risk assessments? If it doesn’t appear often, how do we ensure that our EHS system audits are linked to our risk-based approach?
This article takes a look at how this problem can be solved, using examples from process safety management systems (PSMS) and safety management systems (SMS).
EHS system elements vs. safety critical elements and critical controls
It is fairly typical for a business to operate using a particular type of model system. Common examples include the ISO 45000 standard for EHS, the risk-based safety model developed by the Center for Chemical Process Safety (CCPS), or the safety and integrity model developed by the Energy Institute (EI). The business adopts the approach and builds a management system (SMS or PSMS) using the standard. In the case of standards like the CCPS or EI, the standard also comes with a set of pre-defined system elements which must be implemented, audited and monitored. So we end up with a set of EHS system elements.
Within this overall framework, there is a requirement for hazard identification and risk assessment. For example: the OSHAS 18001 specifies that the business must undertake hazard identification, risk evaluation, and establishment of risk control measures. This process might identify fatality hazards such as entanglement. From the process of establishing risk control measures, we would likely find that guarding or automated trips are particularly crucial for reducing the risk of fatal entanglement. This becomes a critical control (or safety critical element, depending on the situation) which must be implemented, audited and monitored. So we end up with a set of critical controls (in an EHS setting) or safety critical elements (in a process safety setting).
Our auditing framework then needs to cover both the system elements and the critical controls. The context of these audits may be different (e.g. audited at different levels in the business, different locations, different people, different timeframes). It is not unusual to end up with two streams of auditing in parallel that have very few linkages between them.
This creates inefficiencies and reduces opportunities for true visibility and reporting of how the whole system is working.
Solution: using hierarchical groups to link EHS system elements and critical controls
A little bit of detective work is required to see how simple it can be to resolve the gap between management system elements and safety critical elements (the controls). Let’s look at a simplistic example from an EHS SMS. We’ll stay with our entanglement example from earlier.
After our risk assessment or bowtie analysis, we might end up with a list of risk control measures including some of the examples shown below.
|Risk Control Measures (Controls)|
|Operating Procedures for Registered Plant|
|Safe Work Method Statements|
|Pre-Start Information Sessions|
|Take 5 Process|
|Emergency Response Plan|
From that list, we might identify the safety critical elements for this scenario. Bear in mind that the selections here are somewhat arbitrary: if we were applying some of the ICMM critical control selection criteria, we would probably regard controls such as preventative maintenance and worker competencies (which are effective across multiple different risk scenarios) as being critical controls.
|Safety Critical Elements (Critical Controls)|
|Emergency Response Plan|
Let’s assume that in this example, we’re dealing with a large business which uses the Energy Institute model for its SMS. There are 20 SMS elements in that model, as shown below.
|Management System Elements|
|1. Leadership Commitment & Responsibility|
|2. Identification and Compliance with Legislation & Industry Standards|
|3. Employee Selection, Placement & Competency, and Health Assurance|
|4. Workforce Involvement|
|5. Communication with Stakeholders|
|6. Hazard Identification & Risk Assessment|
|7. Documentation, Records & Knowledge Management|
|8. Operating Manuals & Procedures|
|9. Process & Operational Status Monitoring & Handover|
|10. Management of Operational Interfaces|
|11. Standards & Practices|
|12. Management of Change & Project Management|
|13. Operational Readiness and Process Start-Up|
|14. Emergency Preparedness|
|15. Inspection & Maintenance|
|16. Management of Safety Critical Devices|
|17. Work Control, Permit to Work and Task Risk Management|
|19. Incident Reporting & Investigation|
|20. Audit, Assurance, Management, Review & Intervention|
There are some obvious linkages here once we look at the lists together. For example, our “emergency response plan” critical control is clearly part of the system element “emergency preparedness”. The same would be true of the “worker competencies” risk control and the system element “employee selection, placement & competency, and health assurance”.
How do we make this linkage useful? RiskView supports this functionality through our Verification Groups functionality. We can have any number of risk controls linked to a larger Verification Group. We can then schedule audits which target the risk controls, or the Verification Group as a whole. Taking one simple example, we can build the relationship as shown below:
|Verification Group (SMS Element)||Base Control (Safety Critical Element / Critical Control)|
|14. Emergency Preparedness||Emergency Response Plan|
Fire Detection & Suppression System
|15. Inspection & Maintenance||Preventative Maintenance|
|16. Management of Safety Critical Devices||Guarding|
Pressure Relief Valve
Because we have these relationships established, we unlock some opportunities:
- We can choose to audit critical controls individually: and because they are associated with a Verification Group, we can see the result against the whole group. For example, our dashboard reporting for “14. Emergency Preparedness” would show an aggregate result based on all the audits of “emergency response plan” and “fire detection & suppression system”. This gives us greater visibility with the same amount of auditing effort.
- We can choose to audit critical controls collectively as part of a Verification Group: which saves having to schedule many different audits when one large audit would do. The example of “15. Inspection & Maintenance” above is a good one, because we may regard our maintenance strategy as one cohesive system which can be audited altogether.
- Where we have an SMS system element which only has a very limited connection to our risk assessments (such as leadership commitment and responsibility), we can use Verification Groups to carry out the audit as normal. It is likely that we would have a bowtie that deals with actual system risk, and leadership commitment to the system is an essential element here (likely appearing as a Base Control). This allows us to create the audit using the Verification Group in the same way that we’d manually commission an audit of that system element.
We prepare for implementing this type of approach by building critical controls and Verification Groups into our bowtie risk assessments, as shown in the example below. This example is looking at an uncontrolled train unloading situation, and on the causal side we can see several places where inductions and onboarding training (which is part of the selection, placement and competency system element) is being used.
This allows us to move from having two separate streams of auditing (one looking at EHS system elements, one at critical controls) to having one interconnected auditing system. The beauty of this is the way that we get access to interconnected auditing, as can be seen in the example dashboard screenshots below.
If you have any questions about how RiskView supports this type of approach, click the contact us button to get in touch.