The same type of incident happens in two services. One manager escalates it as serious. Another records it as moderate and waits for further review. Both believe they are applying judgement, but the system now has two different responses to the same risk.
If severity decisions vary by manager, serious safeguarding risk can be under-escalated.
This creates weakness in serious incident governance. Severity classification determines who is informed, how quickly evidence is preserved, what level of review is required, and whether root cause analysis begins.
Severity frameworks must also support adult safeguarding frameworks, where similar risks should lead to similar protection decisions. Across the Safeguarding Systems & Risk Governance Knowledge Hub, classification should not depend on local confidence, habit, or tolerance of risk.
This is where consistency becomes a safeguarding control.
Why severity frameworks fail in practice
Severity frameworks often fail because they are too broad, too outcome-focused, or too dependent on individual interpretation. Managers may consider visible harm, but give less weight to potential harm, vulnerability, recurrence, failed controls, or safeguarding context.
A low visible outcome can therefore be rated too lightly even when the potential risk was high. Conversely, a concerning pattern may remain below serious incident threshold because no single event appears severe enough on its own.
A strong framework helps staff and managers classify risk consistently under pressure.
Testing severity decisions against potential harm
A provider reviews an incident where a person missed essential support, but no immediate injury occurred. The local manager rated it moderate because actual harm was not evidenced.
Safeguarding leadership reviews the classification differently. Required fields must include: actual harm, potential harm, person vulnerability, dependency level, failed control, and immediate protection action.
The severity rating cannot proceed without: explicit consideration of what could reasonably have happened if the failure had continued or repeated.
The incident is reclassified because the person was highly dependent and the failed control could have led to significant harm.
Auditable validation must confirm: severity ratings consider potential harm, not only confirmed injury or immediate outcome.
This prevents serious risk from being hidden by a fortunate outcome.
Using recurrence to adjust severity
Some incidents appear moderate until recurrence is considered. A repeated safeguarding concern may signal a failing control even if each individual event looks manageable.
A provider notices repeated delays in escalating welfare concerns across one service. Each case was rated moderate, but together they show a pattern of threshold failure.
The review asks:
- Has this concern happened before?
- Did previous actions reduce recurrence?
- Does the pattern suggest control failure?
- Could recurrence lead to serious harm?
The severity framework is revised so recurrence can increase classification and trigger governance review.
Required fields must include: previous related incidents, action history, recurrence timeframe, control affected, and revised severity decision.
Cannot proceed without: checking whether similar incidents have occurred before assigning final severity.
Auditable validation must confirm: recurrence is considered when classifying serious safeguarding incidents.
Calibrating severity decisions across managers
Even a good framework needs calibration. Without regular comparison, managers can drift in how they apply thresholds.
A provider introduces quarterly severity calibration using anonymized incident examples. Managers compare ratings, discuss rationale, and agree how thresholds should be applied.
Required fields must include: incident example, proposed rating, rationale, threshold factor, agreed rating, and learning point.
The framework cannot be treated as embedded without: evidence that managers apply severity factors consistently across comparable cases.
Where rating differences appear, the provider updates guidance, examples, or escalation rules.
Auditable validation must confirm: severity decisions are sampled and calibrated across services to reduce inconsistent classification.
This keeps the framework alive rather than leaving it as a document.
Governance expectations for severity frameworks
Safeguarding governance should expect severity frameworks to be specific, tested, and evidence-based. Leaders should be able to see whether similar incidents receive similar classifications, whether potential harm is considered, and whether serious incidents trigger the required review level.
Useful assurance includes severity audits, calibration records, threshold examples, reclassification logs, senior review decisions, and checks on incidents initially rated below serious threshold.
Where incidents are downgraded or locally retained, governance should expect a recorded rationale that can withstand scrutiny.
What strong evidence looks like
Strong evidence shows how the severity decision was made. It identifies the risk factors considered, the rationale applied, who reviewed the classification, what escalation followed, and whether the decision matched the provider’s framework.
For serious incident governance, severity classification is not just labelling. It is the gateway into protection, investigation, root cause analysis, and learning.
Conclusion
Incident severity frameworks fail when similar risks receive different responses. That inconsistency can delay escalation, weaken safeguarding protection, and distort governance understanding of serious risk.
The strongest providers standardise severity decisions by considering potential harm, recurrence, vulnerability, failed controls, and threshold evidence. They calibrate manager judgement and test whether classifications remain consistent across services.
When severity decisions are consistent, serious incident governance becomes more reliable. When they drift, safeguarding response can depend on who reviews the concern rather than what the risk requires.