Setting up your base controls – the comprehensive guide to risk control setup – Part 1
Whether you call them common controls, master controls, major accident hazard controls, your library of standardised and auditable controls can really empower your risk system. RiskView encourages you to build these Base Controls into the software to give you more leverage in implementing your risk approach.
Maybe you’re using them to build a standardised library of controls for developing your safety case. Or maybe your Base Controls are going to be the backbone of your critical control verification program.
Whichever approach you’re taking, Base Controls are a fantastic tool to get more out of RiskView.
Many of our clients need a bit of help getting started with their Base Controls. This is our bread and butter, so we thought we should share our approach to the combined risk/data analysis job of setting up good base controls.
This comprehensive guide is partly explanatory and partly instructional: because understanding the process isn’t enough unless you have a handle on the practical applications. This is part 1 in a two part series: part 1 focusing on the concepts and starting points, and part 2 focusing on moving into the practical application of the theory. Feel free to skip ahead if you’ve already got base controls theory mastered!
Setting up your base controls is the task of building these objects into your existing risk data.For those who are new to this area of RiskView, what are base controls? They are a standardised library of controls which are common across multiple risk events or risk registers. They can be used to standardise the practical risk reduction you get from a type of control (e.g. pressure safety valves) in a bowtie or LOPA study. They can also be used to tag your critical controls in preparation for an assurance program.
The goal is to find opportunities in your data. We’re not trying to force our real-world risk controls to fit into a cookie-cutter approach: we’re trying to grasp opportunities to structure our data better.
What do those opportunities look like? A good opportunity is where we can pull together controls, registers or risks that can work together to give us better data. For example: imagine we are using pre-start checks as a preventative control across three of our operating sites. The pre-start specifics are a little different at each site, but fundamentally the process and objectives of the pre-start check are the same.
If we can have a common Base Control for pre-start checks at each site, doesn’t that potentially give us 3 different points of correlation to examine the performance of that control across the business? What we have then is an opportunity to get better quality data coming out of our audit program. We just need to find the best way to grasp that opportunity.
Pre-start example: our starting position vs. what our audit reporting could look like. The problem is that the results from our starting position are not directly comparable, because there are some differences in what the controls include and how we are auditing them. We are missing an opportunity.
Equally as importantly, if we somehow have different existing Base Controls for each of those 5 sites, we are missing an opportunity to improve on the quality of data we get for our efforts. If we expend five hours conducting audits of that control across 5 sites, shouldn’t we structure the audits to maximise the quality of data we get back out?
Sometimes the opportunity is missed because our controls are wearing a cunning disguise. In the example above, site 3 is auditing PK103 Start-Up Checklist. Now on closer examination, we can see that what they intend by this control is the structured pre-start check process which follows the PK103 Start-Up Checklist procedure. But on first glance, it is easy to miss this because the control is disguised as a procedure.
This is where improving on your Base Controls can sometimes hit a roadblock in the form of resistance from control owners closer to the site level. The manager that oversees PK103 Start-Up Checklist at site 3 is probably fairly proud of the 100% audit results for his or her control, and may challenge the idea that the control fundamentally boils down to the same pre-start check process used elsewhere.
A key point to remember here is that RiskView is designed to help you make the best use of your data that you can. If the site is very attached to their view of the control (being the PK103 procedure), what we do in RiskView does not necessarily have to disrupt that. The business as a whole needs to see that site-specific control linked to the best Base Control for the job, which in this case is the Pre-Start Check Process base control. The site can continue to view their critical control as the PK103 procedure (which makes sense to them as the risk owner at the ground level), and RiskView is designed to display both views of that control in the register.
The key is for the business to unlock opportunities that exist to improve on the way that the risk system is implemented using RiskView. Because RiskView is simply a data tool, sometimes that means that to get the best form the tool you need to be prepared to take a more clinical view of some of the data points. That is: while the site-specific control might be the PK103 Start-Up Checklist, the fundamental attributes of that control match the Pre-Start Check Process base control. The richness of context we get from the procedure name and its relevance to the site isn’t lost. We just choose to take a step-back view to get the most from the system.
Taking a more clinical, analytical view is simpler once you have some tools to work with. Here’s some of the ways that we get started on setting up good base controls.
Use the advanced analysis tools in RiskView
RiskView has an advanced analysis menu which makes a big difference in dissecting your data. You can view all the controls for a particular risk on the bowtie, but the advanced analysis menu lets you view all your controls across all your risk events.
This gives you visibility of points of commonality across your data. At a superficial level, by sorting alphabetically on the control name in this view you can easily pick out controls which get used a lot.
You can also show or hide additional fields, apply filters, and manipulate the cross-sections of data that you want to see.
From your refined list, you can export the data to an Excel spreadsheet to do other kinds of trickery with your data.
Whatever method of data crunching you use, the choice is yours. Go with the method that you feel confident with (and make sure it gives you the visibility you need).
Once you’ve identified the data you need and the tools you’re going to need, it’s time to define precisely what your goals are for the Base Controls.
Clarify the level of granularity you are trying to achieve
RiskView is a data tool which enables you to develop and implement more robust risk systems. The risk and assurance approach itself needs to come from the business, not from the software.
So to set up good base controls in RiskView, we need to clarify what we’re trying to achieve. Are we building a standardised library of controls to help with safety cases? Or do we want our base controls to form the backbone of our assurance program? These initial decisions shape the scale and type of base controls we need to build.
For example, we might want a maximum of 20-30 base controls to achieve simple, clean (and lean) reporting from our assurance program. We have assurance programs for safety, environment and public safety (with 3 different regulators), so we could have a maximum of 20-30 base controls for each approach. Having some points of commonality (i.e. base controls used in more than one domain) would potentially allow us to achieve more cross-sections with the same amount of effort. Our risk registers in RiskView are already structured with different register streams for the different domains of risk, so our reporting lines and already nice and clean.
From here, we’ve got a rough sense of the granularity we are trying to achieve. A maximum of 20-30 base controls means that we wouldn’t go in too low to the ground level. If we have different competencies for different risks, but they are all linked to the same training system which is what we can actually control, then we need to pitch for a training and competency base control.
It is important to bear in mind the new functionality we recently introduced called Verification Groups (see the article here). In short, Verification Groups can be used to group multiple Base Controls where we might need to have a balance of detail and simplicity. For example, we might have a “Process Control” verification group, which includes a range of base controls such as automatic trips, alarms, and so on.
But for our purposes here, focus on getting the Base Controls set right. We can always add Verification Groups in if we need them.
Taking the example of training, here’s how we might approach setting up base controls (aiming for 20-30 base controls).
Our starting position:
Our new base controls:
You can already see that there are some key data points that we can use as criteria to see whether our base controls look right. In the examples above, we are referring back to the hierarchy of controls, control effectiveness, and control intent.
To use these criteria effectively, we may need to take a closer use at the context and usage of our controls. Part 2 of this series on base controls looks at using the context of controls to practically implement a smart base controls approach.