Getting live critical control management reporting: escaping the month-end reporting cycle

The whole point of critical control management is to carefully monitor the performance of controls that save lives. Reporting on performance need not be a manual, periodic process: it can be live and accessible at any time.

In the mining space, the ICMM guidance clearly states that identification of critical controls must flow into verification of control reporting, and then to a response to inadequate critical control performance.

The zero harm philosophy (used in construction, engineering and process safety) also emphasises the importance of critical control management. A key output of the process should be actionable intelligence: that is, information about control performance that has immediate relevance and can drive good decision-making.

This reporting is often limited by the ability of risk systems to produce timely reporting. This is often a manual process. Organisations using Excel spreadsheets or clunky software packages often resort to a monthly or quarterly reporting cycle. This results in a flurry of activity each period to collate and massage the verification data into a performance report for the board.

The alternative is to automate critical control verification and reporting. This allows the risk team to review live reporting, even if the risk committee or board might still only review performance monthly or quarterly.

Here we’ll look at how this works as part of a simple automation implementation for the critical control management process examining how Meercat RiskView handles this type of process.

Building the Framework from Existing Data

To automate the critical control verification and reporting, we need to describe our existing risk management system in the software. With RiskView we can use the import/export feature (mainly from Excel) to pull our existing data into the software.

Critical control management really needs a robust (and defensible) method of defining critical controls. For this reason, bowtie analysis is usually the go-to tool. Bowties work well for breaking down the sequence of events resulting from a hazard and understanding the risk reduction effect of controls.

RiskView allows us to import our data and populate bowties automatically, which reduces some of the barriers to getting started. We might need to rearrange our data to get it imported seamlessly into RiskView. This is usually a painless task. Importing and converting the data to bowties can take as little as a week, and can be done by the Meercat team.

We then need to create our common critical controls list in RiskView. We can use the import/export feature again to bring in outside data. If we haven’t already identified our critical controls, we can use the bowties (some guidance is available here). Selecting our critical controls on each bowtie is important, because it signposts the critical controls for RiskView.

We also need to create our principal hazards (aka material unwanted events, major accident events, potential significant incidents, etc) in RiskView. This is again a signposting exercise so that RiskView understands how our risks link up to our principal hazards.

Lastly, we need to set up performance standards for our critical control verifications. To get started with critical control verifications in RiskView, we have two simple options:

  • Target a particular critical control across all the different risk areas that the control is used; or
  • Target a particular principal hazard and the critical controls that mitigate it.

The choice we make here will affect the main focus of the reporting we get from RiskView. If we want to focus on the performance of common controls (e.g. training and competency) wherever they are used, we need to build performance standards for each critical control. If we want to see how our controls are performing to reduce principal hazard risk, we need to build performance standards for each principal hazard.

If we already have an established system for verifications (with existing audit templates), we can use the import/export feature to save time. We might need to rearrange the data a little to make it easier to import a whole performance standard in one go.

The picture of how we get our live performance reporting should be getting a bit clearer now. Because our critical controls are linked up in RiskView, and we use the system for conducting our critical control verifications, we can get live feedback from those verifications.

Automating the Critical Control Verification

Automating our verifications is a simple matter of building the maps that tell RiskView what to audit and where. Verification templates are used in RiskView for this mapping.

To automatically generate verification activities in RiskView, we need to specify:

  • Which principal hazards AND/OR critical controls we are targeting;
  • Which sites or risk registers we want included in the scope; and
  • Which performance standard should be used.

From this mapping, RiskView will automatically create and assign verifications as appropriate:

  • RiskView will work out which sites need to do verifications, because it knows which risks are linked to the principal hazards or critical controls. It will automatically create activities for the sites that should be included in the scope. It will also exclude those controls that have been excluded from a particular risk scenario, increasing our ability to use a master bowtie to underpin scenarios across different sites and registers.
  • RiskView will work out which risks need to be included in the scope, because it knows which risks are linked to the principal hazards or critical controls. It will attach a copy of the risk bowties to the verification activity so that the auditor can refer back.
  • RiskView will work out who the activities should be assigned to, because it knows who is responsible for verifications in each site or register. If that person is unavailable or needs to delegate the work, he or she can forward the verification to another user.

The verification itself can be completed on desktop, laptop, tablet or phone. It can also be conducted without an internet connection (and then synced up later).


Because the verifications are done in the system, the performance findings can be updated as quickly as the Internet can shuttle the information. The quality of reporting we get reflects how much we tell RiskView about our risk.

Extracting live reporting

The live reporting on control performance is available as soon as we sign into RiskView. The dashboard has a range of critical control management dashlets that summarise how our performance is going. The data shown in these dashlets updates as quickly as the data is received from completed verifications. There is no end-of-month or end-of-quarter rush, because RiskView compiles the latest data as it comes in. It also sends out notifications and reminders to make sure that the work gets done.

What we get is truly actionable intelligence because RiskView knows so much about our risk exposure:

  • Because RiskView knows which risks are linked to which principal hazards and critical controls, it can aggregate (summarise) critical control performance. It can show us how each critical control is performing, and how that performance impacts on our protection against principal hazards.
  • Because RiskView knows how each question in each verification was answered, it can compile all the verifications together and give us an aggregated performance value. This allows us to see how our performance looks across the board (and not just based on the very latest audit).
  • Because RiskView knows how many verification activities have been generated and completed, it can tell us how we are tracking in terms of assigned and overdue verifications.
  • Because RiskView handles our risk assessments, our verifications, and our reporting, we can drill-down to linked items. If we see a critical control performance result we’re not happy with, we can click through to see the auditor’s notes for the latest audit. We can see which bowties are affected by the findings.

We can also compare the performance across sites, thereby identifying best practice and weaknesses.

This is the ultimate critical control management approach for risk teams that are time-poor with broad risk exposure. Verifications are easier to complete and the results are immediately available. A manager can review performance and identify problems at a glance. We can also use filters such as principal hazard, control or site to make the information easier to digest. This enables us to draw useful conclusions about a broad risk exposure with a relatively small dashlet report.

Getting the most out of critical control management automation

We’ve shown how simple it can be to automate critical control management. We’ve leveraged existing data and corporate knowledge to shorten the setup process.

To get the most out of this kind of automation, we need to make sure that our initial planning clearly identifies the type of reporting that we want to get. The way that we set up principal hazards, risks, and critical controls in the system strongly shapes what our live intelligence picture looks like.

So before we start building, we need to ask some questions. We should consider:

  • What do we want the main focus of our reporting to be? Do we want to hone in on critical controls, or do we want to see how critical control performance and principal hazards interact?
  • How do we want to see our data grouped? Do we want to separate by site or by department? Each approach can be useful, and we can do both (if the organisation is large enough to justify it). The difference comes out in the reporting, which will let us compare risk across locations (by site) or across different functions (by department, such as logistics vs production).

It’s also important to ask how we want our risk reporting to look (independently of our critical control reporting). The risk register report in RiskView will show the controls that we use and their latest verification results. To get the most from this, we need to set up the system architecture at the start to produce the kind of cross-sections that are most useful to us.

Post a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.