Building a Group-Level Incident Picture When Every Site Reports Differently

Most groups do not have a problem collecting incident reports. They have a problem adding them up.

The data exists. Every site is reporting. But when the board asks whether the organisation is getting safer, or which parts of the business are struggling, the answer takes a fortnight to assemble, arrives with caveats and does not survive a follow-up question. The numbers being added together were never the same kind of number to begin with.

That is a comparability problem rather than a reporting-culture problem, and the two are often confused. A group can have genuinely good reporting at every single site and still have no usable group picture.

This guide covers why the two instinctive fixes fail, which fields actually need to be identical everywhere, how to map different severity scales onto one, how to choose a rate denominator so sites of different sizes can be compared fairly, and what to do about historic data that used the old categories.

Three Shapes, One Underlying Problem

How the inconsistency arrives depends on how the group grew. What it does to the reporting is the same in every case.

None of this is specific to a sector. A group of engineering divisions, a group of care settings and a group of distribution depots reach the same wall at the same point of growth, because the cause is structural rather than operational.

Why the Two Obvious Fixes Fail

Forcing everyone onto one identical form. This is the usual first instinct and it fails on adoption. A form built to satisfy every entity in the group becomes long enough that people stop completing it properly, and it removes the local questions that made the original version worth filling in. Reporting volume falls, which shows up in the data as an improvement and is the opposite of one.

Leaving every entity to its own form. This protects local usefulness and produces precisely the situation the group is trying to escape.

The workable answer sits between the two, and it begins by accepting that most of an incident report does not need to be standardised at all.

Standardise the Spine, Not the Whole Form

Only the fields the group actually reports on need to be identical everywhere. In practice that is a short list.

Everything outside that table can stay local: the questions a particular division needs, the terminology a region uses, the extra detail a specialist team wants. That concession is what allows the approach to survive contact with the sites, and it is usually what unblocks the conversation with the people who have to fill the forms in.

One small point worth settling early. Whatever the software calls the record, the policy should use the words the workforce already uses, which in most organisations means incident and accident. Introducing a new umbrella term at the same moment as a new process gives people two things to learn instead of one. If the distinction between the terms is itself unclear, our guide to accidents and incidents covers where the line falls.

Free Text Is Where Group Reporting Goes to Die

The most common technical cause of an unusable data set is free text in a field that should have been a list. Site names typed by hand produce a dozen spellings of the same building. Typed job titles cannot be grouped. Typed causes cannot be counted, only read.

The rule is straightforward: if you will ever want to count it, group it or filter by it, it needs to be a list rather than a text box. Free text belongs alongside the list, capturing the detail that the list cannot hold, rather than instead of it.

Two practical notes follow. Every fixed list needs an option for cases it does not cover, or people will choose the nearest wrong answer, which is worse than an honest unknown. And that catch-all option then needs reviewing on a schedule, because an unreviewed one quietly becomes the largest category in the data set. A quarterly review that promotes recurring entries into real options is usually enough to keep the list honest.

Map Local Severity Scales Onto One Group Scale

Severity is where most groups discover their numbers are incompatible. One division runs a five-point scale, another uses high, medium and low, a third classifies by outcome. Each is defensible locally. None of them add up.

What works is a single group scale with a published mapping, rather than asking any site to abandon a scale its people already understand.

The fourth row matters more than it looks. A near miss with catastrophic potential belongs at the top of the scale rather than the bottom, and groups that classify purely by actual outcome systematically under-weight their most important warnings. The HSE’s guidance on managing for health and safety sets out the wider plan, do, check, act cycle this sits inside. Our collection of near miss examples is a useful reference when agreeing definitions with sites.

On the statutory question specifically, the HSE’s list of reportable incidents is the authority, and it is worth capturing the reportable flag as its own field rather than inferring it from severity. The two are related but not identical, and inferring one from the other is how reporting deadlines get missed. Our guide to RIDDOR covers the essentials.

Choose a Denominator, or the Comparison Means Nothing

Raw counts flatter small sites and punish large ones. A site with 400 people and twelve incidents is not performing worse than a site with 20 people and three, but a table of raw totals will say that it is.

Whichever you choose, publish it next to the number. A rate without its denominator invites the wrong conclusion. The HSE’s published statistics provide national and industry baselines if you want external context, though comparisons across differently defined populations always need care.

There is a related trap worth naming out loud, because it catches groups in their first year. Improving reporting culture increases incident counts, sometimes sharply, and that is a success being recorded as a failure. Report volume alongside severity and closure rather than on its own. We cover this in more depth in why standardised safety metrics matter and in our piece on turning safety data into better decisions.

Decide What Happens to the Data You Already Have

Nobody migrates everything, and attempting it delays the programme by months for very little return.

The usual approach is a cut-off date. Everything after it lives in the new structure. Everything before it stays in a frozen, searchable archive. Where year-on-year comparison across that boundary genuinely matters, a mapping table translating the old categories into the new ones covers the specific measures the board actually asks for, rather than the entire history.

Be explicit about where the boundary falls when you report. A footnote explaining that categories changed in a given month is far better than an unexplained step in a trend line, and it protects the credibility of everything either side of it.

Run Both Calendars From the Start

Many organisations report safety on the calendar year while the business runs on a financial year starting in April. Both views will be asked for, usually by different people in the same week. Build the reporting so the same underlying records serve either, rather than maintaining two sets of numbers that gradually drift apart.

This is mostly a question of keeping full dates on every record and avoiding pre-aggregation into fixed periods. Once data is summarised into months or quarters at the point of capture, re-cutting it to a different year end becomes guesswork.

Someone Has to Own the List

Standardisation decays. Categories get added locally, definitions drift, and within a year the group picture is unreliable again.

That is a governance job rather than a systems one. Name an owner for the taxonomy, set out who can add or change a category and by what route, review the catch-all entries quarterly, and revisit the full list annually. The HSE and Institute of Directors’ guidance on leading health and safety at work sets out the board-level accountability this supports, and anyone working towards ISO 45001 will recognise the same document-control discipline.

Groups pursuing certification should note that a consistent group-wide data set makes the management-system requirements considerably easier to evidence. That is frequently the argument that unlocks the budget when the safety case on its own has not. Our guide to health and safety management systems covers how the pieces fit together.

What Good Looks Like After Six Months

• One incident type list, one severity scale and one site register, all maintained centrally
• Local forms that still ask the questions local teams need answered
• A group report produced from the system rather than rebuilt by hand in a spreadsheet
• Rates published alongside counts, with the denominator stated
• A named owner for the taxonomy and a review date in the calendar
• Year-on-year comparison that survives a follow-up question from the board

None of that requires every site in the group to work the same way. It requires about ten fields to mean the same thing everywhere, and someone to keep them that way.

If you are working through this, our incident reporting software and reporting and analytics pages cover how the group and local layers fit together in practice, and our investigation guide covers what happens after a report is filed.