Need help with a safety case? Insight is the key to improving your submissions
Safety case submissions are a fact of life for many safety and risk professionals. You may not be able to avoid them, but you can certainly build them faster and better with the right approach.
The key is to bring insight to your safety case. You need to take the regulator on a journey which brings them to share your understanding of risk. Bring your insight to bear on the right tools, and you’ll be building better regulatory submissions in no time.
This article draws on the experiences of Meercat team members in assessing submissions in government regulatory roles.
The big picture: safety case and other regulatory submissions
Before diving in, it’s worth taking a second to recap on why safety cases and other types of regulatory submissions matter.
A safety case might feel like a business case or a sales pitch, and in a way it is. Major hazard facility (MHF) operators are required to submit a safety case to demonstrate that they have adequately considered safety risks as part of their operations. Oil and gas operators are required to submit an environment plan to demonstrate how they will mitigate any harmful impacts of their operations.
But for the public servant assessing your safety case, it’s more than just a sales pitch. It’s also one of the few occasions that the government is able to have insight into your operations. Most of the time, government only hears from industry when they’re reporting incidents (very rarely), reviewing performance (also rarely) or submitting safety cases (every 5 years in many cases). Public servants are often trying to formulate policy and interact with industry without getting much insight into how businesses do what they do. In order to effectively regulate an industry segment, the government needs to understand current affairs in that segment as much as possible. Safety case submissions (and other kinds of regulatory submissions) are an opportunity to look inside industry and understand it better.
Safety cases and plans are also the legislated mechanism by which the government schedules, plans and executes compliance activities. You’re held to account based on the things you said you would do in your submission.
The safety case is also the point at which an entity becomes a regulated entity, and the information supplied at that time is used to determine how much auditing and compliance work (and what kind) is required.
In this respect, your safety case establishes the context and the rules for your relationship with government. Airline operators, for example, are held accountable for complying with the security plan they submit to the regulator. Offshore facility operators must conduct their operations in compliance with the safety case in force for the facility. The public servant who audits either of these entities will only have the plan or the safety case submission to provide context for understanding those entities.
Creating shared understanding
If we take this more holistic approach to what a safety case is, it becomes evident that a safety case submission is about more than just ticking boxes and creating paperwork. A safety case is an opportunity to communicate with the regulator in order to create a shared understanding of risk.
Any person who comes upon a piece of information will understand and internalise it differently. People draw their own conclusions. With your safety case, you need to take the regulator on a journey to reach the same understanding of your risk that you have. This isn’t just to convince them to approve your submission, it’s also about ensuring that you are on the same page as the regulator. If your submission is going to shape your relationship with the regulator, you need them to guide them towards your understanding of your risk.
There are times when the regulator will disagree with your understanding. They will decline to follow the journey because there are policy matters that prevent them from accepting your point of view. In such cases, your submission needs to be revised.
Bear in mind that despite all appearances, the best outcome is not necessarily to do whatever it takes to get the submission approved. Your safety case needs to remain genuinely representative of your business. Resist the temptation or the pressure to insert provisions that are solely to satisfy the regulator. One of the greatest frustrations for public servants reviewing regulatory submissions is when the business clearly has submitted a document that is designed to tick boxes.
Why is this so frustrating for a public servant? Because, as we mentioned earlier, the safety case is an opportunity for the regulator to gain insight into your operations. It is one thing to make your safety case fit within the policy framework, but it is another to make it a document that is solely for the consumption of the regulator. If your safety case does not genuinely represent your business and the way it operates, it undermines your whole relationship with the regulator.
In some areas of legislation there aren’t actually legislative provisions to refuse a generic safety case that is designed to be approved without imparting any insight. But that is not to your benefit, because although a generic submission might get approved, it will set the wrong context for your regulatory relationship. You can expect audits to be less targeted and more drawn-out, because the regulator is trying to audit the picture-perfect version of your business that you put in the safety case.
The right tools for the job
If you’re going to take the regulator on a journey to reach the right shared understanding of risk, you need the right tools for the job. Legislation tends to create a cookie-cutter approach to how your submission should be structured, and in some cases there will be templates that are mandated by legislation or distributed by the regulator.
Therefore your opportunity to genuinely represent your business and its understanding of risk lies in the tools and techniques you use to build your case within the template. Using the right safety case software allows you to distil your insights and thinking into a digestible format for the regulator.
Hazards and operability studies / HAZOP software is a great place to start. Safety cases and other regulatory submissions are often a risk study of sort, which means that the right HAZOP software tools can produce the kind of content you need. HAZOP software should guide you through the risk study, and provide tools for collaborative work. It should provide you with exportable resources (such as risk registers or study worksheets) that can form the backbone of your safety case. The real beauty of this approach is that HAZOP software documents the process by which you reached your understanding of risk: and so the outputs of the software can take the regulator on a similar journey.
Some HAZOP software packages come with risk analysis software tools, which is ideal. A good safety case software package allows you to document your risk analysis as data which can be used to create tables, diagrams, and risk models which are visually accessible. Safety case software should enable you to manipulate the outputs until you have an image that instantly conveys your message to the reader.
A good safety case software package will also allow you to link actions to your HAZOP or risk analysis. Why is this significant? Because it documents the research and validation actions you undertook to ensure that risk was reduced to ALARP. It demonstrates to the regulator that you considered relevant factors before deciding on a particular approach. It also documents any controls or strategies that were proposed, researched, and then rejected. This depth of information is of great benefit to the regulator but is so often missing from the accompanying documentation.
It strengthens your submissions if you use the same risk management software for safety cases as you use for everyday risk assessments and audit activities. Then you have the ability to call up real-world, real-time data directly into your submission. This puts you on the road to a “living safety case”, which is the dream for many organisations. This is a key source of insight that the regulator will find invaluable.
As a side note, bear in mind that using the right tools will speed up the regulatory submission process in many ways. Using specialised tools makes it faster to build and format risk data. It also makes it easier to export the manipulated data into a report. Good software also makes the data more visually and logically accessible to the assessor, which reduces the time it takes for the regulator to review and approve your submission.
The finishing touches
Finally, make sure your safety case is a document that you would get benefit from using in everyday practice. The document may be created specifically for the regulatory submission, and not form part of your suite of everyday documents (although the “living safety case” or “living plan” is always the better option overall). If you wouldn’t get any benefit from referring back to your safety case in your daily work, you can be sure that the public servant reviewing it won’t get any benefit from it.
Whether or not you use safety case software tools, make sure that your regulatory submission is designed to create a shared understanding of your risk. Distil your insights and share them with the regulator. After all, the point of safety regulation is to bring the regulator together with industry for the common goal of protecting human life. Sharing is an essential part of the relationship.
What tools and processes do you use to build your safety cases and other submissions? Does your business have multiple safety cases, environment plans or security plans to manage? How much time and effort investment goes into your submissions?