Human Reliability Analysis (HRA)

We quantify the likelihood of human errors in safety-critical operations and assess their impact on system risk, supporting Quantitative Risk Assessment (QRA) and safety case documentation for high-hazard and regulated industries.

Every HRA engagement is led by Dr. Chizaram Dagogo-Nwankwo, Chartered Ergonomist (C.ErgHF, CIEHF), with published peer-reviewed research in human factors and accident causation in high-hazard industries.

What is Human Reliability Analysis?

Human Reliability Analysis is the discipline concerned with quantifying the probability that a person will fail to perform a required task correctly, within the required time, under the conditions that will exist when the task is performed. The output is a Human Error Probability (HEP): a number that can be incorporated into a fault tree, event tree, or bow-tie model to produce a more complete picture of system risk.

Most risk assessments treat human error as a probability modifier applied to hardware failure rates. HRA makes that modifier explicit and defensible rather than assumed. It identifies which human failure events drive risk, what the conditions are that increase or decrease those probabilities, and what changes to the system, procedure, or training would produce the largest risk reduction.

The methods used in HRA have developed across three generations since the 1980s. First-generation methods, including THERP (Technique for Human Error Rate Prediction), produced numerical HEPs from generic task databases. Second-generation methods, including HEART and CREAM, incorporated performance-shaping factors into the analysis: the conditions under which a task is performed — time pressure, fatigue, interface quality, procedure clarity — rather than treating all instances of a task as equally likely to produce error. SPAR-H, developed for US NRC applications and widely used in nuclear and high-hazard sectors, is now among the most applied methods in UK regulated environments. Third-generation methods, still largely research-stage, attempt to model cognitive processes dynamically rather than as static probabilities.

Method selection depends on the application, the available data, and the regulatory context. We apply the method appropriate to the work, not the method we know best.

Who needs this service

1. Nuclear licensed sites and their supply chains
   HRA is a core component of Probabilistic Risk Assessment (PRA) for nuclear safety cases. The Office for Nuclear Regulation (ONR) expects HRA to be carried out to an appropriate standard and to use recognised, documented methods. Facilities licensing new plant, revalidating safety cases, or responding to regulatory requests for risk quantification use HRA to meet that expectation.
2. COMAH upper-tier sites
   Quantitative Risk Assessment is required for major hazard facilities to demonstrate that risks are as low as reasonably practicable. Human error probability estimates that are simply assumed rather than derived give the HSE competent authority grounds to question the robustness of the QRA. HRA provides the documented, method-based HEPs that a COMAH QRA requires.
3. Offshore oil and gas operators
   Safety cases submitted under the Offshore Installations (Safety Case) Regulations 2015 incorporate quantitative risk estimates for major accident hazard scenarios. Where human actions are credited as safety barriers (initiating a shutdown, isolating a release, activating emergency systems), the reliability of those actions needs to be quantified, not assumed.
4. Defence and aerospace programmes
   Safety cases for military systems, aircraft, and safety-critical defence equipment require quantification of human error in the context of operator tasks. HRA methods including HEART and THERP are widely applied in this sector.
5. Organisations following a major incident
   Where a serious incident has occurred and the investigation has identified human failure as a significant contributor to the risk, quantitative HRA is used to establish baseline human error probabilities, identify the performance-shaping factors that drove the failure, and quantify the risk reduction achievable through proposed controls.

What our HRA programme includes

1. Scope definition and human failure event identification
   Working from the fault tree, event tree, or bow-tie model, we identify the human failure events that require quantification. Not every human action in a complex system requires formal HRA; the analysis begins by identifying which human failure events are significant contributors to the risk and concentrating the quantification effort on those.
2. Task analysis
   Hierarchical task analysis of the tasks associated with each identified human failure event. Task analysis establishes the cognitive and physical demands of the task, the information the operator needs to diagnose a situation and decide how to respond, and the actions required to execute the response. This is the input that drives method application.
3. Method application
   Application of the appropriate HRA method (HEART, THERP, SPAR-H, or CREAM depending on the context and regulatory requirements) to produce a quantified HEP for each identified human failure event. Performance-shaping factors assessed and documented for each task. Dependency analysis carried out where multiple human failure events are linked in sequence.
4. Sensitivity and uncertainty analysis
   HEPs are point estimates, not precise measurements. Sensitivity analysis identifies which human failure events have the most influence on the overall risk estimate, and uncertainty analysis quantifies the range of plausible values given the limitations of the methods and data. Both are standard components of a QRA-ready HRA.
5. HRA report
   A formal written report documenting the scope, method selection rationale, task analyses, HEP calculations, sensitivity and uncertainty analysis, and findings. Written to the standard required for inclusion in a nuclear safety case, COMAH QRA, or offshore safety case submission. Includes recommendations for risk reduction measures where the analysis identifies significant contributors.
6. Integration with QRA and safety case
   We work alongside the QRA team to integrate HRA outputs into the broader risk model. HEPs expressed in the format required by the QRA tool in use. Findings documented in a format compatible with safety case submission requirements.

The difference between HRA and SCTA

The two methods are related but serve different purposes.

1. Safety Critical Task Analysis identifies which tasks are critical, characterises the error modes within them, and identifies the performance-shaping factors that affect reliability. The output is a qualitative risk register with prioritised recommendations. SCTA does not produce numerical probabilities.
2. Human Reliability Analysis takes specific human failure events, typically identified through an SCTA or a fault tree analysis, and quantifies the probability of failure. The output is a number that can be placed in a risk model. HRA depends on a prior understanding of the task and the error modes within it; that understanding typically comes from task analysis and SCTA.

For many high-hazard operations, both are required: SCTA to identify and characterise the critical human failure events, HRA to quantify the probabilities for incorporation into the QRA. We carry out both services and can scope an integrated programme that delivers both.

Frequently asked questions

Which HRA method should we use?
Method selection depends on the regulatory context, the available task data, and the level of detail required. HEART is widely used in UK oil and gas and chemical applications where a relatively rapid quantification is needed and the task can be characterised against the HEART generic task types. SPAR-H is common in nuclear applications. THERP is used where the task can be broken into sub-tasks with independent failure probabilities. CREAM is applied where the cognitive context is the primary driver of reliability. We advise on method selection as part of the scoping process.

Can HRA be carried out without a preceding SCTA?
Yes, though the quality of the HRA is typically better when a prior task analysis exists. Without task analysis, the characterisation of the human failure event has to be reconstructed as part of the HRA process, which takes longer and introduces more uncertainty. Where task analysis already exists, HRA builds directly from it.

How are HEPs verified?
HEPs derived from HRA methods are validated against available data from comparable tasks where data exists, against expert judgement for tasks with no direct data, and through sensitivity analysis that quantifies how the HEP changes under different assumptions. No HRA method produces a single objectively correct number; the value of HRA is in producing a defensible, documented estimate that regulators and safety case reviewers can scrutinise. Transparency of method and assumptions is more important than spurious precision.

How does HRA fit into a COMAH QRA?
Within a COMAH QRA, HRA provides the human failure event probabilities used as basic events in the fault tree or as branch probabilities in the event tree. The HSE competent authority reviews QRAs and will challenge human error probabilities that appear assumed rather than derived. An HRA documented to an appropriate standard, covering method selection rationale, task analysis, PSF assessment, and uncertainty analysis, withstands that challenge. An assumed figure does not.

Do you provide HRA for control room and digital systems?
Yes. HRA for digital control rooms, alarm management systems, and HMI-dependent tasks requires specific consideration of the cognitive demands of monitoring, diagnosis, and decision-making under abnormal conditions. We apply HEART and CREAM to these environments and work alongside our Human Factors in Design and Digital Systems service where control room assessment is also in scope.

Discuss a project

HRA programmes are scoped individually. Tell us about the risk assessment or safety case context, the regulatory framework, and the human failure events you need quantified, and we will come back within two working days with a proposed approach.