Blog Safety Management


Proportionality is about committing resources to the Safety Program that are adequate – in both quality and quantity – for the required tasks.

Introduction to Proportionality

Proportionality is a concept that should be applied to determine the allocation of resource and effort to a safety and environmental argument based on its risk.  It is a difficult concept to attempt to distil into a process as each Product, System or Service will have different risks, objectives, priorities and interfaces that make a ‘one size fits all’ approach impossible.

This section describes an approach that may be used to assist in applying the concept of proportionality; it seeks to guide you in understanding where a proportionate amount of effort can be directed, while at the same time maintaining the overriding principle that Risk to Life must be managed.  Regulators require that a proportional approach is used and there are many methods that try to achieve this.  Some focus on the amount of evidence needed to justify a safety argument; some provide more emphasis on the application of activities that are required to make a safety argument and some consider that fulfilling certain criteria can lead to an assessment of risk, but one requirement that is at the centre of any proportional approach is that safety risks are acceptable. 

A fundamental consideration of a proportional approach is considering compliance against assessment criteria.  The Health and Safety Executive’s view is that there should be some proportionality between the magnitude of the risk and the measures taken to control the risk. The phrase “all measures necessary” should be interpreted with this principle in mind. Both the likelihood of accidents occurring and the severity of the worst possible accident determine proportionality.  Application of proportionality should highlight the hazardous activities for which the Duty Holder should provide the most detailed arguments to support the demonstration [that risk is acceptable].

The following considerations may affect proportionality, in a defence context:

  1. Type of consequence;
  2. Severity;
  3. The stage in the Life cycle;
  4. Intended use (CON OPS/Design Intent);
  5. Material state (degradation);
  6. Historical performance;
  7. Cost of safety;
  8. Cost of realising risk;
  9. Public Relations;
  10. Persons at Risk:
    1. 1st,2nd,3rd Party;
    1. Military
    1. Civilian;
    1. Civil Servants;
    1. Contractors;
    1. General public;
    1. VIPs;
    1. Youths;
  11. Volume;
  12. Geographical spread/transboundary.

Some important points that should be noted regarding safety and environmental proportionality approach are that:

  1. Proportionality is inherent to safety and environmental risk assessment (i.e. use of ALARP, BPEO, etc.);
  2. Proportionality is explicitly linked to risk;
  3. Multiple factors need to be considered when deciding a proportional approach;
  4. ASEMS is the mandated safety and environmental framework; therefore, the framework should be applied; it is not possible to develop a proportional approach that negates any part of ASEMS.

Waterfall Approach Process

The model that should be used to consider a proportional approach is intended to provide guidance and should only be used by competent safety and environmental practitioners.  A degree of judgement should be used when answering questions, particularly where a Product, System or Service may easily be classified in more than one category; this is why the use of competent safety and environmental practioners is required.

The waterfall approach model categorises Product, System or Service risk in accordance with factual questions, presented on the left of the diagram below, which are asked about the intended function and operation.  Each question should be used to define the cumulative potential risk, which may be presented by the Product, System or Service.  The Product, System or Service is categorised into one of three risk bands, which align to those defined in the Tolerability triangle, presented in the right of of the diagram.

During the process two initial questions are asked, where an answer of “yes” will automatically result in a categorisation of high risk, regardless of the answer to subsequent questions.  Further refinement is required for lower risk systems to ensure that the system risk is categorised appropriately.

Figure 1, Proportionality Waterfall Approach Model

The diagram above depicts the proportionality waterfall approach model used for the application of ASEMS.

Adherence to ASEMS is mandatory for DE&S.  As such, it is not possible to develop a proportional approach that negates any individual part of ASEMS and so the procedures described in ASEMS Part 2 – Instructions, Procedures and Support should be followed;  where proportionality may be applied is within each General Management Procedure, Safety Management Procedure or Environmental Management Procedure for the allocation of resource, time or effort.

Once the risk category has been established guidance is defined which prescribes the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA):

  1. Process – the amount of dedicated/specific process, level of intervention in the organisational structure the Safety and Environmental Management System are established;
  2. Effort – How much time is afforded to the management of risk;
  3. Competence – the level of competence that is required to conducted appropriate assessment and management of safety and environmental;
  4. Output – The detail of evidence and reporting is cognisant to the level of risk;
  5. Assurance – The level of assurance required which shall be applied to the process.

Guidance for the application of PECOA is provided in the table below.  It should be noted that this is indicative guidance for illustrative purposes only. It is a fundamental requirement of ASEMS safety management principles that all safety decisions made should be reviewed, assessed and endorsed by a Safety and Environmental Management Committee to ensure that the Products, Systems and Services categorisation is correct. The diagram below shows the process that may be applied:

Proportionality Process

It should be remembered that using this low/medium and high categorisation could be misleading as the model takes no account of the population or rate of occurrence of the harm. A simple system that can only cause minor injury could still have a high degree of risk if there are lots of people exposed to the risk and the accident rate was high.  Moreover, acceptance of such a situation could lead to the development of an ineffective safety culture or the bypassing of safety mitigation procedures in order to avoid a high accident/minor injury position.  This is where the application of competent safety and environmental advice is essential to ensure that any proportionality model is not slavishly followed at the expense of proper rigour.   Where this model is useful is assisting those safety and environmental professionals to perform a preliminary assessment regarding what Products, Systems or Services are a priority for the allocation of resource, time or effort.

Stage One – System type and Life Cycle Phase

The first question is used to indicate, at a high level, the likely degree of risk for a project.  It should be noted that this is not a definitive assessment and that Products, Systems or Services could move within the model as the safety or environmental evidence is assessed.  There will be a degree of pre-existing assessment which accompanies a Product, System or Service and this may be used to assist with this initial question. 

The safety and environmental assessment process should be closely aligned with the Product, System or Service development process for newly developed Product, System or Services.  Where Products, Systems or Services are in the Concept, Assessment, Development or Manufacture phase of the CADMID/T cycle, they should be accompanied by a safety and environmental assessment process which utilises quantitative assessment techniques.

Where a Product, System or Service sits in the CADMID/T cycle should not influence the rigour of any safety or environmental argument; this model is provided to assist with any determination of the resource, time or effort that may be applied to the evidence to support the argument.  All Risk to Life should be ALARP, with no exception; what changes is the allocation of resources, time and effort to reach that judgement.

Those Products, Systems or Services where the expected worst credible consequence results in, at worst, a single minor injury should automatically be categorised as LOW risk and a qualitative approach may be adopted.

Commercial Off The Shelf or Military Off The Shelf systems should be accompanied by evidence which may be used in the safety and environmental assessment to demonstrate that they are acceptably safe and environmentally compliant, particularly where these are manufactured for use in the EU, where each Product, System or Service should demonstrate compliance with the applicable EU standards.  That the Product, System or Service is Commercial Off The Shelf or Military Off The Shelf is not, in itself, evidence.

Such evidence should include test evidence, trials evidence or a certificate of conformance.  Where a Commercial Off The Shelf or Military Off the Shelf system is already in the in-service phase and it is established that there is sufficient evidence to form a compelling safety argument that the Risk to Life is ALARP, then the system should be categorised as MEDIUM-LOW.  Where the system is also non-complex then it may be categorised as LOW.

Such Commercial Off The Shelf or Military Off the Shelf evidence should only be relied upon where it is established that this evidence is sufficient to demonstrate that the system is acceptably safe and environmentally compliant and already in existence.  The degree and appropriateness of evidence should be established by a Safety and Environmental Management Committee, with particular emphasis upon the quality of the evidence for high-risk systems.  This approach should be undertaken if the Product, System or Service in its entirety is categorised as Commercial Off The Shelf or Military Off the Shelf.  Where only sub-systems or components are Commercial Off The Shelf or Military Off the Shelf, the Product, System or Service should be categorised as bespoke and assessed accordingly.

Stage Two – Risk estimation and System Complexity

Any estimation of the risk that a Product, System or Service is likely to present should be used to further refine its categorisation.  If the worst credible consequence of a Product, System or Service is multiple fatalities then that Product, System or Service should automatically be categorised as HIGH risk.

If the worst credible consequence is a single fatality or multiple severe injuries then the system complexity should be considered further to refine and inform the categorisation.  Complex or novel system designs should have a higher degree of Suitably Qualified Experienced Personnel to conduct the safety and environmental assessment.  Accordingly, those Products Systems or Services which are complex and novel should also be categorised as HIGH whereas those exhibiting a lower degree of complexity might be categorised as MEDIUM.

Notwithstanding this, those Products, Systems or Services thatare in the Concept, Assessment, Development or Manufacture/Termination phase of the CADMID/T cycle should still be supported by a quantitative safety and environmental process.  The only exceptions are those Products, Systems or Services where the worst credible consequence is a single minor injury.  These should be categorised as LOW risk and may be supported by a qualitative safety and/or environmental process.

LOW risk Products, Systems or Services were the worst credible consequence is at worst a single minor injury should be categorised as LOW-MEDIUM risk where the design is complex or novel, those exhibiting a lower degree of complexity should be categorised as LOW risk.

Once the risk category has been established the rigour which should be applied to the safety assessment process in terms of Process, Effort, Competence, Output, Assurance (PECOA) should be defined.  This is summarised below:

Program ScaleLifecycle Stage
Small scale or no Critical FunctionCADMID/TCADMID/TCADMID/T
Large Scale Capital,

Critical Function or bespoke
ProcessA rigorous quantitative safety and environmental assessment process should be applied.Consideration should be given to the application of a qualitative safety and environmental assessment process.  Functional safety/environmental assessment may be required, if identified as a risk control measure.A qualitative safety and environmental assessment process should be appropriate for low risk, low complexity systems.
EffortSignificant effort should be expended developing the safety and environmental case.A medium level of effort should apportioned to development of the safety and environmental case, increasing for newly developed systems.A medium level of effort should be apportioned to development of the safety and environmental case.
CompetenceThe safety and environmental assessment and assurance programme should be led by individuals who are experts.  Remaining personnel should be at least Practitioners who should be provided with oversight where appropriate.Personnel engaged in the safety and environmental assessment and approval should be at least practitioners.Personnel engaged in the safety and environmental assessment and approval should be at least supervised practitioners who should be provided with oversight where appropriate.
OutputA safety and environmental case should be developed which includes a safety argument.  The safety assessment process should be substantiated by quantitative evidence.A safety and environmental case should be developed, which should include a safety and environmental argument for all by simplex low risk systems.  The safety assessment process should be substantiated by quantitative evidence for newly developed systems.A safety and environmental statement may be considered for systems, which are low risk and complexity.
AssuranceThe safety and environmental assessment should be independently assured.Independent assurance should be considered and applied to those projects which are considered to be novel or complex.  Assurance may be conducted at Committee level. Independent assurance is not required.
ASEMS GuidanceSafety and Environmental   Dedicated tailored and full implementation of all Clauses, articulated through adherence to all GMPs, SMPs and EMPs.Safety and Environmental   Apply full implementation of all Clauses, in line with guidance provided for the Functional safety/environmental assessment, as required, if identified as a risk control measure and application of GMPs, SMPs and EMPs.Where Project Teams have an overarching Safety and Environmental Management Systems in place:   Safety Gather sufficient evidence to support safety argument and document in a Safety Case/Assessment in accordance with SMP 04050609 and 12     Environmental Gather sufficient information in order to produce Environmental Impact Statement in accordance with EMP 07 – Environmental Reporting.


The type of safety and environmental process which should be applied is dependent both upon the Product System or Service categorisation and the phase of the CADMID/T cycle that the project is in.  Newly developed MEDIUM-LOW to HIGH category Products, Systems or Services which are in the Concept, Assessment, Development or Manufacture phase of the cycle should have a quantitative safety and environmental assessment process applied, the depth and rigour of the assessment should be proportionate to its classification.  LOW risk Products, Systems or Services where the worst credible consequence is anticipated to be no greater than one minor injury may be assessed qualitatively.

A qualitative safety and environmental assessment process should be applied to Products, Systems or Services, which are in the In-Service, Disposal/Termination phase where it is deemed that there is sufficient evidence already in existence to demonstrate that it is acceptably safe.  In these circumstances a qualitative safety and environmental process should be applied to assess the in-service risks.

The approach uses a systematic and logical approach to categorise the resource, time and effort required to support any argument that a Product, System or Service is acceeptably safe or provides no significant damage to teh environment.  It also advocates the application of ASEMS in its entirety, prescribing the level of rigour, which should be applied in terms of process, effort, competence, output and assurance.


The effort apportioned to the safety and environmental process should be proportionate to the classification of the system.  A significant amount of rigour should be applied to those projects requiring quantitative assessment processes, particularly those with the highest degree of risk and complexity.

If a Product System or Service is assessed to be in a particularly low category and is simple it may not be necessary to undertake the full scope of risk management procedures.  In these circumstances a certificate of conformance may be sufficient, which may be supported by statement to that effect from the Safety and Environmental Management Committee.

All decisions made regarding the evidence required to justify a safety argument (regardless of risk) should be endorsed by a Safety and Environmental Management Committee.  If this is decision is delegated further for those Products, Systems or Services that are low risk is for the Duty Holder to determine as all decisions regarding to Risk to Life are made on their behalf.


The safety and environmental lead should be an expert for HIGH category projects or for MEDIUM category projects where the Product System or Service is particularly complex or a novel design.  The remaining personnel engaged on such projects should be at least practitioner level.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.

The safety and environmental lead for MEDIUM category projects should be at least practitioner level.  The remaining personnel engaged on such projects should be practitioner or supervised practitioner where appropriate supervision is in place.  A competency assessment should be undertaken which should be endorsed by a Safety and Environmental Management Committee.

The safety and environmental lead for LOW category projects should be at least practitioner level or a supervised practitioner with appropriate supervision in place.

Competency requirements relating to specific safety and environmental processes defined in ASEMS should be applied where those processes are undertaken.


A safety and environmental case should be developed for HIGH category projects which includes a safety and environmental argument, developed using Claims Arguments Evidence (CAE) or Goal Structuring Notation (GSN).  The argument should be substantiated by quantitative evidence such as reliability data or the output from quantitative safety assessment processes.

A safety and environmental case should be developed for MEDIUM category projects which includes a CAE or GSN safety argument.  The quality and depth of evidence required to substantiate the safety and environmental argument should be proportionate to the classification of the Product System or Service.   Products, Systems or Services with increased complexity or higher degrees of risk should be substantiated by quantitative evidence

A Safety and environmental case should be developed for MEDIUM-LOW category Products, Systems or Services.  A safety and environmental argument should be included for those Products, Systems or Services which are particularly complex or novel or those which exhibit an increased degree of risk

A Safety and environmental case should be developed for MEDIUM-LOW category Products, Systems or Services.  A safety and environmental argument should be included for those Products, Systems or Services which are particularly complex or novel or those which exhibit an increased degree of risk.

A safety and environmental case or Safety and environmental statement should be developed for LOW category Products, Systems or Services.  A certificate of conformance may be adequate for the lowest risk simple Products, Systems or Services

All decisions made regarding the evidence required to justify a safety argument (regardless of risk) should be endorsed by a Safety and Environmental Management Committee.  If this is decision is delegated further for those Products, Systems or Services that are considered to fall in the low category, then it is for the Duty Holder to determine (as all decisions regarding to Risk to Life are made on their behalf) whether to acept the risks or not.


HIGH and MEDIUM category projects should be independently reviewed by a Safety and Environmental Auditor.  The degree of Independent Safety and Environmental Auditor engagement should be proportionate to the project categorisation.

MEDIUM-LOW category projects should be independently reviewed by a Safety and Environmental Auditor where the safety and assessment processes applied are novel or complex.  Justification should be provided where an Independent Safety and Environmental Auditor is not appointed.

It is not necessary for projects categorised LOW to be independently reviewed.

It should be remembered that it is not prudent to take any form of autocratic system or approach without sufficient validation, verification and endorsement by competent and duly authorised individuals, who are considered Suitably Qualified and Experienced Personnel for the role.  Endorsement of decisions should be made by a competent panel or committee, as part of the overall hazard analysis and risk assessment and any variation in opinion from that presented by any proportionality model should be managed by such a panel.

If you found this post on Proportionality helpful, please leave a review.

If this post is missing something you wanted, please let me know!

Blog Safety Management

Hazard Logs – a Brief Summary

In Hazard Logs – a Brief Summary, we will give you an overview of this important safety management tool. This post serves as an introduction to longer posts and videos (e.g. Hazard Logs & Hazard Tracking Systems), which will provide you with much more content.

Hazard Logs – a Brief Summary

Description of Hazard Log

A Hazard Log is a continually updated record of the Hazards, Accident Sequences, and Accidents associated with a system. It includes information documenting risk management for each Hazard and Accident.

The Hazard Log is a structured means of storing and referencing Safety Risk Evaluations and other information relating to a piece of equipment or system. It is the principal means of tracking the status of all identified Hazards, decisions made and actions undertaken to reduce risks. It should be used to facilitate oversight by the Project Safety Committee and other stakeholders.

The Hazards, Accident Sequences, and Accidents recorded are those which could conceivably occur, as well as those which have already been experienced. The term Hazard Log may be seen as misleading since the information stored relates to the entire Safety Programme and covers Accidents, Controls, Risk Evaluation, and ALARP/SFARP justification, as well as data on Hazards.


The Hazard Log is maintained by a Hazard Log Administrator, who is responsible to the Project Safety Engineer/Manager. The Hazard Log Administrator has primary access to the Hazard Log allowing him/her to add, edit or close data records. All other personnel requiring access to the Hazard Log are normally allowed read-only access. This allows for visibility of Hazards to all but limits the control/administration of data records to the Hazard Log Administrator.

Records can be tracked by the use of a status field. This, for example, identifies whether the record has just been opened, is awaiting confirmation of mitigation actions, or is ALARP/SFARP.

It is best practice for the Hazard Log to record each Hazard as “open” and for ALARP/SFARP arguments to be provisional until all mitigation actions are confirmed to be satisfactorily completed. An example is where the mitigation depends upon the production of an operational procedure that may not be written until well after the Hazard is first identified in the early stages of design or construction.

Hazards should not be deleted from the Hazard Log, but closed and marked as “out of scope” or “not considered credible”, together with appropriate justification. Where such Hazards are no longer considered relevant to the system, the Log entry should be updated to reflect this.


In general, the Hazard Log should relate to a specified system and record its scope of use, together with the safety requirements. When Hazards are identified, the Hazard Log should show how these Hazards were evaluated and note the resulting residual risk assessment; the Hazard Log should then record any recommendations for further action to mitigate the Hazards, or formally document acceptance of the Hazards and any ALARP/SFARP justification.

Since a Hazard Log is a structured way of storing and referencing data and records on Hazards, documenting the Risk Evaluation and other information relating to a piece of equipment or system, clear cross-referencing to supporting documentation is essential. The supporting documentation can be either directly embedded or cross-referenced within the Hazard Log.

When it Might be Used

A Hazard Log should be established for all projects. This will allow full traceability of the formal decision process which would justify the assessed level of Safety Risk.

The Hazard Log is established at the earliest stage of the program and should be maintained throughout the system life cycle as a “live” document or database. As changes are integrated into the system, the Hazard Log should be updated to incorporate added or modified Hazards and the associated residual risks noted to reflect the current design standard.

It is essential that the Hazard Log is reviewed at regular intervals, to ensure that Hazards are being managed appropriately and enable robust safety arguments in the Safety Case to be established.

Advantages, Disadvantages, and Limitations


The Hazard Log contains the traceable record of the Hazard Management process for the Project and therefore:

  • Ensures that the Project Safety Programme uses a consistent set of Safety information;
  • Facilitates oversight by the Safety Panel and other stakeholders of the current status of the Safety activities;
  • Supports the effective management of possible Hazards and Accidents so that the associated Risks are brought up to and maintained at a tolerable level;
  • Provides traceability of Safety decisions made.


  • The relationship between Hazards, Accidents, and their management through setting and meeting Safety Requirements could be included within the Hazard Log. However, if it is not sufficiently robust or well-structured, this may obscure the identification and clearance of Hazards;
  • If Hazards are not well defined when they are entered into the Hazard Log, then the rigor enforced by the need for a clear audit trail of changes made may make it very difficult to maintain the Hazard and Accident records in the most effective way. An appropriate structure should therefore be designed and agreed upon before data entry starts.


A Hazard Log can be produced in any format, but an electronic format is the most common, as this tends to provide the quickest means of cross-referring and providing traceability through the Hazard Log. A paper-based Hazard Log would have limitations for most defense Systems as it would become large, staff-intensive, and cumbersome as the System developed. This in turn introduces a significant maintenance overhead for a project.

The electronic form of the Hazard Log can be developed using Database development tools like Microsoft Access or SQL Server. Alternatively, you can use an existing application such as DOORS. Alternatively, it can be completed in a simple spreadsheet package such as Microsoft Excel. The UK Ministry of Defence’s preferred Hazard Log tool was Cassandra, a proprietary Database based upon Microsoft Access.  (We will use Cassandra as an example in another blog post.)

A bespoke Database enables the originator to custom define fields appropriate to the System. Conversely, a proprietary tool allows for a consistent and standardized approach across a range of programs. A bespoke system may be relatively simple to administer and manipulate, whereas a proprietary tool may require external training. Widespread use of different bespoke solutions may become unmanageable.

Sources of Additional Information

Additional guidance on the Hazard Log can be found within the following references: MoD’s Project-Oriented Safety Management System – procedure SMP11 – Hazard Log.  An example Hazard Log structure is also presented there.

Copyright Acknowledgement

In this article, I have used material from a UK Ministry of Defence guide. It is reproduced under the terms of the UK’s Open Government Licence.

Hazard Logs – a Brief Summary: Ask Me Anything!

Blog Safety Management

Safety Management Policy

In this post on Safety Management Policy, we’re going to look at the policy requirements of a typical project management safety standard. This is the Acquisition Safety & Environmental System (ASEMS).

The Ministry of Defence is the biggest acquirer of manufactured goods in the UK, and it uses ASEMS to guide hundreds of acquisition projects. They will range from the development of large, complex systems to buying simpler off-the-shelf items.

(You may be aware that the UK Ministry of Defence has a terrible record of project failure. I have personal experience of working on both sides of contracts – for buyer and seller. I can tell you that they would have done better if they had followed ASEMS more carefully. The standard is good, but no standard can help if you don’t use it!)

The policy clauses listed here are typical of many found around the world. There is a lot to be learned by studying them.

Safety Management Policy – Overview

ASEMS Part 1 – Policy comprises a series of policy statements grouped in six loosely related sections as follows:

Part 1 – General Clauses

These clauses represent those overarching general requirements that shall be used in all instances. If the clause is self-explanatory, there may not be explicit Instructions in ASEMS – Part 2 Instructions, Guidance, and Support to support them but where these are provided, the Instructions and Guidance will provide a best practice method for compliance.

Clause 1.1 Conform to Secretary of State for Defence’s Policy

Those holding safety and environmental protection delegations shall ensure that in the procuring or supporting Products, Systems, or Services, they conform to the Secretary of State’s Health, Safety, and Environmental Protection Policy Statement.

Clause 1.2 Instructions

The instructions defined in ASEMS – Part 2 Instructions, Guidance, and Support shall be used to manage safety and environmental impact within the Enterprise.

Clause 1.3 Duty Holders

Duty Holders shall be appointed and Letters of Delegation issued in accordance with the Enterprise Chief Executive Officer’s Organisation and Arrangements.

Clause 1.4 Interfaces

Interfaces between organizations shall be identified so that risks across them can be appropriately managed and effectively communicated.

Clause 1.5 Data and Record Format

Data shall be maintained in a format, which satisfies the reporting requirements of senior management within the Enterprise. Auditable records shall be made and kept under review in accordance with relevant legislation.

Clause 1.6 Significant Occurrences and Fault Reporting

All Delivery (Project) Teams shall record and report significant Product, System, or Service faults, accidents, incidents, and near misses to the Enterprise Safety, Health & Environment Committee through the Quality, Safety, and Environmental Protection Team.

Clause 1.7 Learning From Experience

Business Units, Delivery (Project) Teams, or equivalents shall ensure accidents and incidents are investigated to identify opportunities to reduce the likelihood and impact of recurrence. Lessons learned shall be shared amongst all relevant stakeholders to maximize benefit.

Clause 1.8 Training

Enterprise-sponsored courses for system safety and environmental protection shall be the recognized route for achieving suitable and sufficient competence throughout the Enterprise.

Part 2 – Management Responsibilities

Management responsibilities for safety and environmental protection permeate through every Clause, and are the heart of any successful safety and environmental management system; however, these Clauses confer specific requirements upon management and make compliance easier to measure.

Clause 2.1 Organisation and Arrangements

Business Unit Directors or equivalent shall document their Organisation and Arrangements that shall communicate their commitment to the Secretary of State for Defence’s policy statement, continual improvement, positive safety and environmental culture, to minimize adverse effects on the environment, and comply with legal and other appropriate requirements.

Clause 2.2 Communication

Business Units, Delivery (Project) Teams, or equivalents shall ensure that communication procedures are implemented that provide an effective flow of safety and environmental protection information upwards, downwards, and across their organization.

Clause 2.3 Organisational Change Management

Business Unit Directors or equivalent shall identify any increased safety risk associated with organizational change and manage it appropriately.

Part 3 – Safety and Environmental Management System

These Clauses place specific requirements upon organizations and individuals and represent the minimum requirements for a safety and environmental management system. They include the requirement to plan for safety and environmental protection, to enact that plan, check that the plan is working, and to make changes where necessary to improve the system

Clause 3.1 Safety and Environmental Management System

Business Units, Delivery (Project) Teams, or equivalents shall operate in compliance with established Safety and Environmental Management Systems.

Clause 3.2 Safety and Environmental Management Plan

Business Units or equivalent shall ensure that all Products, Systems, or Services have a suitable and sufficient through-life safety and environmental management plan.

Clause 3.3 Stakeholder Agreements

Agreements between Stakeholders shall define and document system safety and environmental protection responsibilities.

Clause 3.4 Availability of Resources

Business Units, Delivery (Project) Teams or equivalents shall ensure the availability of resources necessary to establish, implement and maintain the safety and environmental management system and detail these in a through-life safety and environmental management plan.

Clause 3.5 Core Element Documentation

Business Units, Delivery (Project) Teams or equivalents shall establish, maintain and retain suitable and sufficient information that describes the core elements of the safety and environmental management system(s), their interaction, and any related documentation.

Clause 3.6 Accountability

Individuals deployed to assignments that require the formal delegation of safety and environmental responsibilities, accountabilities, and authority shall be mapped against, and comply with, the requirements of the Enterprise Acquisition Safety taxonomy.   

Clause 3.7 Monitoring

Business Units, Delivery (Project) Teams or equivalents shall establish, implement and maintain a suitable and sufficient procedure to monitor and measure safety and environmental performance of their safety and environmental management system on a regular basis.

Clause 3.8 Audit Frequency

Compliance with the documented safety and environmental management system shall be verified via audit at planned intervals according to a published schedule, and as required.

Clause 3.9 Internal Audit

At planned intervals commensurate with the risk:

  1. Business Units shall audit their Delivery (Project) Teams, or equivalents, safety, and environmental management systems.
  2. Delivery (Project) Teams or equivalents shall audit the safety and environmental management systems of their projects.
  3. The Enterprise Quality, Safety, and Environmental Protection Team or their representative, shall audit the safety and environmental management systems of Business Units and Delivery (Project) Teams.

Policy Clause 3.10 Review

Business Units, Delivery (Project) Teams, or equivalents shall review their safety and environmental management systems, at planned intervals commensurate with the risk, to ensure their continuing suitability, adequacy, and effectiveness.

Part 4 – Safety and Environmental Cases/Assessments

These Clauses contain the requirements that each safety and environmental case/assessment shall contain. Defense Regulators may require further, additional, requirements to what is contained in these clauses. Adherence to these Clauses will ensure safety and environmental cases/assessments contain the minimum evidence necessary to support safety and environmental arguments that Products, Systems, and Services are safe to use.

Clause 4.1 Safety Cases

Delivery (Project) Teams or equivalents shall establish and maintain through-life safety cases that provide a compelling, comprehensible, and valid argument that a Product, System, or Service is safe for a given application in a given operating environment.

Clause 4.2 Environmental Cases

Delivery (Project) Teams or equivalents shall establish and maintain through-life environmental cases that provide a compelling, comprehensible, and valid argument that the environmental impact of a Product, System or Service is reduced, or Best Practicable Environmental Option (BPEO) is applied.

Clause 4.3 Identification of Legislation and other Requirements

Business Units or equivalent shall establish and maintain a procedure for identifying and accessing the relevant safety and environmental legislative and other requirements that are applicable to their projects.

Clause 4.4 Legislation Compliance and other Requirements

Delivery (Project) Teams or equivalents shall establish, and demonstrate compliance with, relevant legislation and other requirements.

Clause 4.5 Environmental Impact Identification

Business Units, Delivery (Project) Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of environmental impacts.

Clause 4.6 Safety Hazard Identification

Business Units, Delivery (Project) Teams or equivalent shall establish, implement and maintain a procedure for the on-going proactive identification of safety hazards.

Clause 4.7 Safety and Environmental Objectives and Targets

Business Units, Delivery (Project) Teams or equivalents shall establish and maintain relevant safety and environmental objectives with a resourced programme to achieve targets.

Clause 4.8 Accident and Incident Records

Business Units, Delivery (Project) Teams or equivalent shall monitor and record accidents, incidents and near misses, where the performance of their Product, Systems or Services results in harm to individuals or damage to the environment and use this information to keep their risk assessments valid.

Clause 4.9 Assessment Approval

Safety and environmental case reports shall be personally approved by the individual with formally delegated authority to confirm their acceptance with the progress of the safety case/assessment and of the risks associated with the project.

Clause 4.10 Independent Assurance

Independent review of the Safety and Environmental Management System shall be ensured, as appropriate and commensurate to the risk, by the individual with formally delegated authority for safety and environmental protection.

Part 5 – Risk management

Risk Management is an essential function of safety and environmental protection and these Clauses reflect that importance. They set both general safety and environmental protection standards and specific the Enterprise requirements that support the need for assurance and performance monitoring to the Defence Board. The requirement to refer risks through Line management is included here.

Clause 5.1 Risk and Impact Assessment

All foreseeable Safety Risks and Environmental impacts shall be identified, assessed, prioritised and managed.

Clause 5.2 Change Management

Business Units, Delivery (Project) Teams or equivalents are to ensure that all new or increased safety risks arising from changes to Products, Systems or Services or to their operating environment are managed appropriately

Clause 5.3 Hierarchy of Controls

Business Units, Delivery (Project) Teams, or equivalent shall adopt a recognized hierarchical approach for achieving a reduction in safety risk and environmental impact.

Clause 5.4 Consultation

Business Units, Delivery (Project) Teams, or equivalent shall ensure that all stakeholders are identified and consulted so that their views and responsibilities are considered when managing safety and environmental risks.

Clause 5.5 Safety Risk

Products, Systems or Services shall not have safety risks that have not been formally assessed, justified and declared to be Tolerable and As Low As Reasonably Practicable (ALARP), unless communicated and accepted by a Duty Holder (DH).

Clause 5.6 Environmental Impact

Significant environmental impacts shall be minimised utilising BPEO.

Clause 5.7 Non-compliance Reporting

In circumstances where the ability of the Delegation Holder to achieve compliance with the requirements of ASEMS may have been compromised, Business Units, Delivery (Project) Teams or equivalents shall take immediate steps to correct the situation. Actions required could include improving the clarity of the authority, instructions or responsibilities provided, increasing resources or correcting deficiencies in practices or procedures. Where resolution of the problem lies outside the control of the Delegation Holder, the issue is to be referred through the line management chain. This requirement is to be applied to any further levels of delegation as necessary.

Clause 5.8 Referral Requirements

Where risks cannot be managed within an individual’s delegated responsibility, the risk shall be formally referred using the Enterprise Risk Referral procedure.

Part 6 – Competence

It is necessary that those involved in safety and environmental protection are suitably qualified and experienced in order for them to perform their roles. These Clauses detail the way that competence is to be captured and assessed.

Clause 6.1 Roles and Responsibilities

Business Units, Delivery (Project) Teams or equivalents shall demonstrate that competence requirements have been established for all roles in accordance with appropriate standards including the Enterprise System Safety & Environmental Protection Competency Maps, Assignment Specifications, and Success Profiles.

Clause 6.2 Suitably Qualified and Experienced Personnel

Business Units, Delivery (Project) Teams or equivalents shall ensure that those engaged in safety and environmental protection are suitably qualified and experienced to discharge their safety and environmental responsibilities.

Clause 6.3 Competence

The competence of all staff with system safety and environmental responsibilities shall be regularly assessed, monitored, and recorded.  Staff with formally delegated system safety and environmental responsibilities shall demonstrate their competence to receive the delegation prior to deployment, and their competence shall be regularly monitored and recorded. 

Safety Management Policy: which clauses will you use?

Blog Safety Management

SMP03 Safety Planning

Safety Planning: if you fail to plan, you are planning to fail. In my experience, good safety plans don’t always result in successful safety programs; however, bad safety plans never lead to success.

Safety Planning: Introduction


Safety Management Plan is defined as:

“A document that defines the strategy for addressing safety and documents the Safety Management System for a specific project.”

UK MoD Defence Standard 00-56


The objectives of a Project Safety Management Plan (SMP) are twofold:

  1. To ensure that the safety performance of the system is acceptable throughout its life;
  2. To provide and maintain adequate assurance information that this is being achieved.

These objectives can only be realised by following a coordinated and structured approach to safety throughout the system lifecycle. This encompasses setting appropriate requirements as well as conducting risk management as an integral part of system development.

Separate project SMPs are to be produced both by the Enterprise Project and by the contractor. Each SMP defines the safety activities to be conducted by that organisation, so they are closely related to each other. The programmes that they contain will also be linked to activities of system development, trials and any Safety approvals required. Similarly, the Independent Safety Auditor’s Audit Plan will also be linked to these activities.

This procedure is concerned with the SMP for the Enterprise Project rather than plans produced by the contractor or Independent Safety Auditor.

The SMP details the Enterprise’s Safety Management Activities for the Project and therefore:

  1. Ensures that safety responsibilities are recognised and properly allocated;
  2. Defines the safety programme timescales and so supports the timely completion of tasks and identification of any slippage.

The Enterprise Project SMP forms an essential element of the Through Life Management Plan. Each project requires an SMP describing the measures that will be enacted to demonstrate that the system will be tolerably safe throughout its life.

The publication and agreement of the arrangements detailed in the SMP should be the mechanism through which the Enterprise through-life safety management of the equipment is established. The SMP is the formal record of the way the Enterprise manages safety for a project.

Safety Planning: Procedure


The SMP defines the strategy for addressing safety and interprets the Safety Management System for a specific project. It also contains the safety programme which documents safety timescales, milestones and other date-related information.

The SMP will consider all aspects of equipment safety including, but not restricted to;

  1. General equipment safety;
  2. System specific requirements i.e. Airworthiness, Ship Key Hazards etc.;
  3. Occupational Safety i.e. Manual Handling, Packaging, Transport and Storage, Control of Substances Hazardous to Health etc.;
  4. Safety of operation;
  5. Infrastructure interfaces;
  6. Maintenance;
  7. Training;
  8. Disposal.

The SMP may be based on the template in Annex A. It should not be confused with the requirement of Defence Standard 00-56 for the contractor to produce a Safety Plan.

The SMP should be detailed for the current stage of the acquisition cycle but should also define a workable safety strategy for all the remaining stages, including Disposal. This safety strategy covers both the Enterprise’s input to safety engineering and safety assurance aspects, including Safety Case development and safety approvals.

Devising a general plan is not practical: each plan must be tailored to its project and goals.

See Annex B for an example of a RACI (Responsible, Accountable, Consulted, Informed) Chart which might be used as part of a Project SMP to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise  Project safety programme.

The SMP may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.


The Project SMP should contain the following information: –

  1. Outline description. Description of the equipment, clearly defining the purpose and capability expected (and eventually achieved) of the project. Clearly identify the range, or variants, of the equipment covered, its purpose, operating cycle and environment and defining interfaces with other equipment and levels of competence expected of the operator(s);
  2. Safety Management System. Details of the Safety Management System including its aims and objectives, the managerial and technical tasks to be undertaken and the organisation responsible for implementing them;
  3. Responsibilities and resources. The management structure, responsibilities, resources and interfaces with contractors that are necessary for the implementation of the safety programme. This should include the roles and details of all personnel involved throughout the life of the project. It should include the Team Leader, the individual within the team with formally-delegated safety responsibilities, the Project Safety Manager, Equipment Capability Customer, Maintainers, Users and the Project Safety Committee. The reporting chain should be identified within the plan. A RACI (Responsible, Accountable, Consulted, Informed) Chart should be used to define the responsibilities and accountabilities of the authorities involved in the implementation of the Enterprise Project Safety Programme;
  4. Audit. Details of the audit arrangements for the project, including internal and independent audits;
  5. Requirements, objectives, targets and acceptance. A definition of the safety requirements, objectives, targets, regulation, licensing and certification requirements and acceptance criteria for the project. Details of statutory safety standards, legislation and regulations, and any restrictions or exemptions that may apply. The means and criteria by which the requirements are to be demonstrated and accepted are to be clearly defined (these elements will form part of the technical requirement for the project and will become deliverables under the contract);
  6. Scope of the Safety Case. Clearly identify the range and variants, of the equipment covered, its purpose, operating cycle and environment to be covered e.g. the operating envelope;
  7. Safety Case strategy. The definition of the strategy to be followed for the safety assessment. This should give a full breakdown of all the techniques to be used to identify, analyse, assess and control hazards;
  8. Safety Programme. The programme of work that identifies and schedules the tasks contained in the previous paragraphs. This programme should be linked to key stages in the Through Life Management Plan.

An outline of Project SMP has been provided in Annex A. Additional advice is available from domain-specific safety regulations.

Warnings and Potential Project Risks

The SMP is the principal mechanism for managing project risks associated with safety activities. If the plan is not accurate or is not kept up to date, then the effects of delays in the safety activities or changing project timescales may not be recognised and managed.

If the SMP is not sufficiently detailed, then required safety activities may not be identified and planned into the programme. This may have adverse effects on the project time and cost once the missing activities are recognised and performed. If the requisite activities are not undertaken at all, then either the safety performance may not be adequate, or the necessary safety assurance evidence may not be generated. The former would lead to avoidable accidents and the latter to an inadequate Safety Case that might prevent the system from being accepted into service.

If the SMP is not reviewed and endorsed by the Project Safety Committee (PSC), then it is possible that the Project Safety Management System described in the plan may not be an accurate reflection of the safety responsibilities as understood by other parties. The programme of activities contained in the SMP might not be achievable if the resources required are not available at the times assumed.

Procedure Completion

The PSC is responsible for drafting and endorsing the SMP and agreeing on the safety targets, requirements and acceptance criteria.  It is important that all organisations with safety responsibilities described in the SMP should review the SMP described and agree that it is accurate.

The SMP endorsed by the PSC shall be accepted formally by the Enterprise’s delegated authorities for procurement, support and operation. 

Safety Planning: Timing

Initial Production

The SMP should be produced at the earliest stage of the project, e.g. at the beginning of the Concept stage and be updated as the project progresses through the acquisition stages.

Review, Development and Acceptance

It is recommended that the SMP should be reviewed to a predetermined project programme, particularly if there are major changes to the programme.  It must accurately record arrangements and should be reviewed at each meeting of the PSC, or at least annually.

The SMP endorsed by the PSC shall be accepted formally by the Enterprise-delegated authorities for procurement, support and operation.  When any of the signatories change, the SMP shall be re-issued and formally accepted again by the delegated authorities.

The SMP evolves as the project matures and additional information becomes available or decisions are made.  Early iterations will only outline broad strategies and goals; later iterations will become more definitive.  This will enable important safety management tasks to be carried out during the subsequent acquisition stages.

Safety Planning: Required Inputs

This procedure for Safety Planning requires inputs from:

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Outputs from procedure SMP02 – Safety Committee.

The SMP must be integrated with other management plans produced by the Project throughout the acquisition cycle to ensure its effectiveness. It shall also be of sufficient detail to stand alone for all safety planning activities.

The development of the SMP will be based on the following:

  1. Overall project programme;
  2. User Requirements Document and System Requirements Document;
  3. Through Life Management Plan;
  4. Existing descriptions of the safety management arrangements for organisations involved in the project (e.g. Delivery Team Safety Management System descriptions).

Safety Planning: Required Outputs

Where relevant, the outputs from this procedure should feed into the following:

  1. System Requirements Document – for any specific Safety requirements;
  2. Customer Supplier Agreement – to document agreements on Safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.

PSC meeting minutes should record the review of the SMP and any decisions made regarding its amendment and up-issue.

Safety Planning: Annex A – Template for a Safety Management Plan


Title of equipment or system to be procured with Requirement reference number.


A brief description of the project including its purpose and the environment it is to operate in. The scope of the project and interfaces with other equipment are also to be identified.


List any specialist advisors who need to be involved in the programme and send them a copy of this plan where required. Such advisers should include the internal advisors or external regulators or statutory bodies that provide advice.


A description of the Safety Management System within the Enterprise delivery team to include:

  1. The aims and objectives of the safety management system;
  2. Technical tasks to be undertaken and organisation responsible for implementing them;
  3. Identification of project staff with responsibility for carrying out safety tasks. Include those who are to be issued with letters of delegation;
  4. Cross refer to any relevant project safety documents or reports;
  5. A regime for internal or independent audits of the safety management system;
  6. Details of the project safety panel;
  7. Responsibilities, resources and interfaces with Enterprise, contractor and specialist advisors;
  8. Safety reviews, feedback and reporting procedures;
  9. Transfer arrangements;
  10. Design changes;
  11. Contractor’s trials.


  1. Safety requirements arising from legislation;
  2. Enterprise Certification requirements;
  3. Acceptance criteria;
  4. Safety requirements from the Requirement or;
  5. Safety targets;
  6. Safety-related standards to be applied e.g. British Standards, Defence Standards, International Standards or overseas standards.


Identify the tasks that will enable the safety requirements to be met and develop this into a schedule of work on a Gantt or PERT chart, link to key stages in the Through Life Management Plan.


This strategy should support the programme of work above. It will give consideration to the types of analyses and testing to be carried out. It will define the scope of work of the safety case and the interfaces with associated equipment safety cases.


This plan will be approved by a person with delegated authority.


Plan to be distributed to the management area with responsibility for in-service support. The plan will also be distributed to teams procuring equipment with which the project interfaces and or interacts.

Annex B – RACI Chart example

The SMP should contain a RACI Chart to define which authority is Responsible, Accountable, Consulted or Informed for each of the activities in the Safety Programme. A simple example is given below:

ActivitySafety Delegation HolderProject Safety ManagerIndependent Safety AuditorContractor Project Safety EngineerEquipment User
Safety Case PreparationARIRI
Safety Case EndorsementAIRII
Hazard Log AdministrationAIR
Safety Requirements PreparationARRC

Key: R – Responsible; A – Accountable; C – Consulted; I – Informed

Acknowledgement of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Safety Planning: What are Your Questions?

Blog Safety Management

SMP02 Project Safety Committee

Our Second Safety Management Procedure is the Project Safety Committee. Okay, so committees are not the sexiest subject, but we need to get stakeholders together to make things happen!

Project Safety Committee: Introduction


Safety Committee is defined as:

A group of stakeholders that exercises, oversees, reviews and endorses safety management and safety engineering activities.

Def Stan 00-56


The key elements for the effective management and delivery of safety are coordination, agreement, and proper response by those authorities with responsibilities for the equipment. 

The PSC brings together those with safety management responsibilities and other stakeholders with relevant specific knowledge, authority, or Subject Matter Expertise. It, therefore:

  1. Provides a forum through which all those with safety responsibilities can ensure effective co-ordination on safety issues;
  2. Provides access for decision-makers to all those with relevant knowledge;
  3. Provides competent oversight of the Safety Case during its development and upkeep;
  4. Provides, through records of its meetings, an audit trail showing that suitable advice has been sought and that safety management decisions were well-founded.

The Enterprise PSC may be supported by Panels, Sub-Committees, or Working Groups with the appropriate level of Subject Matter Expertise and defined Terms of Reference to address specific safety issues.

Although contractors will be members of the Enterprise PSC, they may also need to form and chair their own Safety Committee. Typically this might be necessary on more complex projects where there are multiple sub-contractors. Enterprise will be represented on the Contractor’s Safety Committee to ensure that there is an adequate understanding of the in-service environment and the user’s needs. If there are both Enterprise and Contractor Safety Committees, then they must each have clear Terms of Reference, and their inter-relationship must be well defined.

In Australia, it is a legal requirement for those with safety responsibilities (Duty Holders) to consult, coordinate and cooperate with others. Other countries may use different terms for similar requirements. The bottom line is that it’s a good idea!

Top Tip

Project Safety Committee: Procedure


The PSC should include representatives, as appropriate, from the following areas:

  1. The Delivery Team (including the Project Safety Manager, and other technical, contracts, and finance officers as required);
  2. Integrated Logistics Support teams;
  3. Equipment support teams;
  4. Customer representatives (project sponsor);
  5. User representatives (Equipment End User);
  6. Trials team;
  7. Maintenance specialists;
  8. Training Authorities;
  9. Prime contractor;
  10. Design organization;
  11. Independent Safety Auditor (if appointed);
  12. Specialist advisors (e.g. from Enterprise, certification authority, or industry safety consultants);
  13. Enterprise Safety Authority; and
  14. Enterprise Safety and Environmental Protection Group.

Other representatives that may be required to participate should include contractors, consultants, subject matter experts, safety sustainable development & continuity, operators, users, and maintainers of the equipment. These should also include reliability and quality managers, (other government departments or representatives of other nation-states governments or departments – for public sector projects.)

However, don’t invite anybody and everybody ‘just in case’, as this devalues the PSC and its work.

Top Tip

More information on PSC membership has been provided at Annex A – example Terms of Reference for a PSC. Further advice is available from QSEP.


The Committee(s) should be chaired by the safety-competent individual holding formally-delegated responsibility for safety within the Project.  A Letter of Delegation may detail the scope of the delegation holders’ responsibility and authority to carry out the safety management tasks on that program.


In order for a PSC to make decisions concerning the safety of a capability or equipment, it should be declared quorate at the beginning of the meeting. In order for a PSC to be declared quorate, the following SQEP and authorized members should be in attendance:

  • Delivery Team safety delegation holder
  • Project Safety Manager
  • Design organization
  • Customer representative (Project Sponsor)
  • Safety Case author

The quorate for a PSC can be expanded depending on the nature of the project. Details should be provided in the Project Safety Management Plan (SMP) or Terms of Reference.

If there are insufficient attendees for the PSC to be declared quorate, the meeting can still proceed with decisions being noted and only implemented once an agreement has been received from the quorum ex-committee. 

This is a good point. PSCs don’t always meet frequently, and getting some members to attend can be challenging. Nevertheless, it is important to keep moving forwards.

Top Tip

Meeting Frequency and Mechanisms

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. The key principles are to ensure that all relevant authorities are consulted, actions are agreed upon and properly allocated, and a record is kept of proceedings. A PSC can either be established for a single type of equipment, or a family of variants of equipment.

Smaller projects may choose to integrate the PSC activities with other meetings. As a minimum, the discussion of safety issues should remain a unique item on meeting agendas.

Working Level Support

Depending on the complexity of the project, one or more working groups may be established that support the PSC by assessing hazards or reviewing the integrity of specific systems. Integrity working groups could consider structure, propulsion or other electrical or mechanical systems, reporting significant issues to the PSC.

Safety Management Committee

Where a number of similar equipment are managed in a single Delivery Team, consideration should be given to establishing a top-level Safety Management Committee (SMC) to set out and agree on the safety management policy and strategy for those projects. The strategy would detail the formation of PSCs for individual equipment, or groups of similar equipment e.g. radio systems, or support vehicles rather than a type of radio or vehicle.

The SMC will monitor and control the activities of the individual PSCs, which will operate in accordance with their own SMPs. Structures can be tailored to suit individual circumstances. Terms of Reference, including membership, for an SMC, should be similar to that of a PSC. The safety management policy and strategy for those projects will be recorded in a Safety Management System document, similar to an SMP. Figure 2.1 shows an example of a Safety Committee structure, together with the management documents that sit at the relevant committee level.

Figure 2.1 – Safety Committee Structure

Safety Committee Structure

Figure 2.1 represents an example of a Safety Committee structure, with supporting working groups and hazard reviews in place. Teams can modify the structure of the Safety Committees to suit the specific organization of the program. The emphasis should be on establishing a Safety Committee with suitable chairmanship and Terms of Reference.

The structure shown in Figure 2.1 would be suitable for a large Program managing several important projects. However, it is probably overkill for most projects. With committees, less is sometimes more.

Top Tip

Project Safety Committee Authority and Competence

The chairman of the PSC should hold a Letter of Delegation detailing the authority for carrying out the safety management tasks on that program.

The PSC exists to provide information and specialist advice to those who have specific responsibility for safety management on an acquisition project so that they can reach informed decisions. The Project safety delegation holder is required to seek and consider relevant advice through the PSC but remains the decision-maker.

Whilst not all members of the PSC need to have specific competence and experience in Safety Management, it is essential that some committee members do have this competence and are consulted.  In addition to the safety delegation holder, whose competence must be established prior to their delegation being issued, other members of the PSC who must be safety competent would typically include the Project Safety Manager and the Independent Safety Auditor (if appointed).

As a minimum, the Project Safety Manager should have system safety competence at the practitioner level.  Competence requirements for the safety delegation holder will be defined in a relevant Assignment Specification.

The level of competence needed is driven by many factors – size, complexity, novelty – and this will be discussed under a post on ‘Proportionality’ (TBD).

Top Tip

Where it is considered beneficial, a combined committee may be established for the safety and environmental management activities. It should be ensured that the programs are aligned as far as possible and that data is shared where relevant.

It is suggested that where there are separate safety and environmental committees, these meet consecutively over the morning and afternoon – with membership and specialists attending as appropriate to each.

The PSC may cover groups of similar projects within a Delivery Team where common activities are required, although separate committees are envisaged for very large, high risk or diverse projects within a Delivery Team.

The PSC may meet regularly as a body, or its work may be included as a permanent item in another forum (in this instance care should be taken that all relevant parties are included), or simply through written communications. This last option is less desirable because there is no opportunity for direct interaction.

Records and Project Documentation

The records from this procedure will consist of PSC meeting minutes which should record the following:

  1. Those present;
  2. The discussions;
  3. Advice given;
  4. Decisions made;
  5. Recommendations to those with delegated authority for safety management; and
  6. Actions agreed.

Where relevant, the outputs from this procedure will feed into the following:

  1. System Requirements Document – for any specific safety requirements;
  2. Customer Supplier Agreement – to document agreements on safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case and Full Business Case submissions.

Review and Agreement of Safety Documents

The role of the PSC includes reviewing safety documents and advising the safety delegation holder on their suitability. The agreement that the document is suitable can be signified in various ways and the Project Director should define, which is required. Methods for recording the review and its findings could include:

  1. Formal sign off of the document by all members of the PSC;
  2. A recommendation, recorded in PSC minutes, that the document is satisfactory and can be authorized for release by the agreed signatory.

Warnings and Potential Project Risks

If the PSC is not established early in the acquisition life cycle, then some of the stakeholders involved may not be identified and their needs may not be addressed adequately in the development of the safety requirements or the production of the SMP. This could also occur if the PSC is established with an incomplete membership.

If the PSC does not review and approve the safety tasks described in the SMP, then the activities may be inappropriate to deliver the required levels of safety performance and safety assurance.

If the PSC does not review and approve the Safety Management System described in the SMP, then they may not identify areas of disagreement concerning responsibilities for safety.

Beware of the PSC delving into detail and doing what is expedient, rather than was is needed. Set appropriate TORs and agendas and stick to them.

Tip Top

If the PSC does not meet with sufficient frequency, then they may not identify in a timely manner, any issues with the safety program. This could result in impacts on project time and cost.

If the PSC attempts to control the detailed design solutions, rather than relying on the contractor’s Safety Committee and design function, then Enterprise will take responsibility from the designer. Enterprise staff will be represented on the contractor’s Safety Committee and shall exercise influence at that forum and through setting appropriate requirements.

Procedure Completion

Delivery Teams will complete the procedure, in conjunction with advice and information from members of the PSC.

Project Safety Committee: Timing


The PSC should be established during the Concept phase of a project by the Customer, or Requirements Manager, through the Capability Working Group, in conjunction with the relevant Project Director, to set out the safety requirements for the equipment.

The PSC has an important role to play in influencing safety requirements. This is not mentioned in ‘PSC: Required Outputs’, below, but is possibly the PSC’s most important contribution.

Top Tip


The required frequency of the PSC meetings depends on various factors including the stage of the project, the complexity of the system, and whether the PSC is supported by Working Groups or has complete responsibility.  Meetings will be required at greater frequency during periods of significant review and decision making, typically when project milestones are approaching.

PSC meetings may occur less frequently during periods of stability, such as during the in-service phase, when fewer safety decisions are necessary.  However, the PSC still has an important duty to provide oversight of the Safety Case and ensure that it remains valid and monitoring safety performance.  This will include considering whether the system or its usage is changing and seeking counter-evidence that shows the predicted level of safety performance is not being achieved in practice.

Project Safety Committee: Required Inputs

The procedure may use the following reference inputs, as available:

  1. Outputs from procedure SMP01 – Safety Initiation;
  2. Documents to be reviewed such as:
    1. Project Safety Management Plan;
    2. Independent Safety Auditor Audit Plan (if appointed);
    3. Independent Safety Auditor Audit Report (if appointed);
    4. Other Safety Audit Plans (e.g. self or Peer audit);
    5. Safety Audit Report;
    6. Hazard Log Report;
    7. Safety Requirements;
    8. Safety Assessment Report;
    9. Safety Case Report.
  3. Acquisition System Guidance Functional Competencies for System Safety Management;
  4. Records of previous meetings of the Safety Committee.

Project Safety Committee: Required Outputs

The outputs of the procedure will comprise:

  1. Established Safety Committee membership;
  2. Defined Terms of Reference for the Safety Committee (see Further Guidance – Examples Terms of Reference for Project Safety Committee);
  3. Records of Safety Committee meetings, including advice given and the actions, agreed;
  4. The advice given by members of the Safety Committee should include recommendations on whether a reviewed document (e.g. Safety Management Plan or Safety Case Report) should be authorized by the Project Director. If authorization is not recommended, then the reasons should be recorded.

Annex A

Example Terms of Reference for Project Safety Committee

Terms of Reference for – Project XXXX


To provide a forum for monitoring and coordinating all safety management and risk reduction activities associated with the project to ensure effective levels of safety and provide an appraisal of the Safety Case. The Project Safety Committee reports to the Project Director or in a larger Delivery Team to the Safety Management Committee.


  1. To set and keep under review the project’s safety policy and strategy;
  2. To set and keep under review the project’s safety targets and objectives;
  3. To define the system boundaries for safety responsibility;
  4. To advise the Chairperson of the Safety Committee on the safety responsibilities of each authority associated with the project;
  5. To advise the Chairperson of the Safety Committee on the standards, statutory regulations, and any restrictions with which the projects should comply;
  6. To review, monitor, classify and allocate new equipment hazards as they are identified;
  7. To carry out reviews of the project’s Safety Case and progress on achieving safety targets, to a predetermined program, issuing the results to the Delegated Authority;
  8. To agree on any control measures that are deemed necessary to reduce identified risks to ALARP;
  9. To ensure proper and timely availability of training and issue of documentation;
  10. To carry out actions from ISA, regulatory or internal audit findings;
  11. To operate a system for reviewing and monitoring safety performance and maintain the Safety Case.


  1. Delivery Team responsible for the procurement aspects of the project;
  2. Customer representative (Capability or Equipment Customer);
  3. Safety Officer (if appointed);
  4. Design organization;
  5. Delivery Team responsible for the support aspects of the project;
  6. Equipment User;
  7. Training Authority;
  8. Maintainer;
  9. Maintenance Authority;
  10. Specialist Advisors (as required):
    1. Defense Safety Regulators;
    2. Defense Ordnance Safety Group;
    3. Land Accident Prevention and Investigation Team;
    4. Military Aviation Accident Investigation Team;
    5. Serious Equipment Failure Investigation Team;
    6. Independent Safety Auditor;
    7. Interfacing Delivery Teams;
    8. Technical Specialists.

Acknowledgment of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Project Safety Committee: Who would You Include?

Blog Safety Management

SMP01 Project Safety Initiation

In ‘Project Safety Initiation’ we look at what you need to do to get your safety project or program started.



stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to the ultimate acceptance of the project.

We will look at the RACI chart of stakeholders under a later SMP.

Top Tip

Project Safety Initiation: Objectives

This procedure describes the start-up of safety management activities on a project. It identifies safety stakeholders and legislative and other standards that need to be satisfied. The procedure also creates the key elements of the safety management organization for the project.

In normal circumstances, this procedure would be applied at the outset of a project, early in the Concept phase. However, it can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process on an existing system. The procedure may also be re-applied at significant points in the life cycle (e.g. after Full Business Case approval), to review and update the project safety arrangements and ensure that they continue to be appropriate.

Remember that a Project delivers on a specific:

a) Outcome, result or benefits, e.g. meeting requirements;

b) Schedule; and

c) Quality criteria, e.g. needed to realise benefits.

Top Tip

This procedure assumes that the Program Director has already been appointed, and that clearly defined safety responsibilities have been formally delegated to a suitably safety-competent individual within the Delivery Team.  

Although this is written as a safety procedure, it is recognized that at this early stage the safety and environmental processes are very similar and may be carried out together. Where appropriate, the same formats and tools are recommended for stakeholder and legislative requirements to provide a single consistent basis for subsequent safety and environmental activities. These tools are described here for completeness. It is also recognized that in many projects, the roles of Project Safety and Environment Manager may be combined, and a single Project Safety and Environmental Committee may exist.

The purpose of Safety Initiation is to ensure that the safety management process is commenced on a firm basis by identifying basic information, interfaces, and responsibilities. These include:

  1. Stakeholders (including industry);
  2. Regulators and Approval Authorities;
  3. Project Safety Manager;
  4. Independent Safety Auditor if appropriate;
  5. Project Safety Committee;
  6. Project Safety Responsible, Accountable, Consulted, Informed (RACI) Chart;
  7. Enterprise internal safety regulator/audit group.

All applicable factors need to be lined up to ensure the success of a safety project or program.

Top Tip

Project Safety Initiation: Procedure

Stakeholder Identification

A stakeholder is anyone who will be affected by the introduction of the system and who needs to be consulted or informed about the development and fielding of the system, and anyone who contributes to the ultimate acceptance of the project. This may include individuals or groups that:

  1. Have safety responsibilities at any stage of the project;
  2. Have safety requirements (including information) from the project;
  3. Hold safety information relevant to the project (e.g. other Delivery Teams with interfacing or sub-systems);
  4. Have specialist or operational knowledge that can aid the project in achieving safety requirements.

As a minimum, the following will be consulted:

  1. Project Sponsor (e.g. the Director of the End Users’ Business Unit);
  2. Equipment end user;
  3. Technical Director;
  4. Other Delivery Teams involved in any sub-systems of the project;
  5. Other Delivery Teams involved with systems, projects or systems platforms with which the system/project will be closely associated;
  6. Subject Matter Experts with specialist technical or professional expertise in a subject area relevant to the Project;
  7. Relevant Enterprise internal safety regulator/audit group (via Questionnaire Form SMP01/F/01 – Safety Operating Environment Questionnaire).

When stakeholders have been identified, their contact details and involvement in the project will be recorded in form SMP01/F/02 – Register of Stakeholder Requirements and Information.

Initially, stakeholders identified and consulted at this stage will be restricted to the Enterprise. However, any relevant external stakeholders identified e.g. (other) government departments, industry, research organizations, regulatory bodies, etc., should be logged and included in a communication plan, which identifies when they should be consulted, by whom, and for what purpose. The Project may choose to include external stakeholders at this stage.

Note that for projects that involve a high number of stakeholders, consideration will be given to developing a project communication plan that includes contact details, information requirements, lines of communication, responsibilities, and any relevant security considerations.

It may be helpful to rename the project communication plan the Project Stakeholder Management Plan – what do you need from stakeholders for your Project to succeed?

Top Tip

Identify Applicable Legislation, Standards, and Requirements

The identification of relevant legislation at the start of any project is essential so that any conditions for compliance can be incorporated into the acquisition process. Project Safety Manager (PSMs) will identify and maintain a register of applicable legislation as part of the development of the Safety Case, and continuously review it and revise it as necessary.

This is the initial identification of potentially applicable safety standards and requirements (including legislation, policy, and best practice standards) that may apply to the project over its lifetime. The Register of Safety Legislation and Other Significant Requirements (see Form SMP01/F/03 – Register of Safety Legislation and Other Significant Requirements) will be used to list and document these standards for each of the life cycle stages. A separate sheet should be used for each standard identified.

Within the Enterprise, each project’s Legislative Register should be taken to include matters of Government or policy and international treaty obligations. 

Note that this will be an evolving process through several stages of the project. The Preliminary Hazard Identification and Analysis procedure (Procedure SMP04 – Preliminary Hazard Identification and Analysis) will identify additional requirements, to be consolidated into the safety requirements (see procedure SMP10 – Safety Requirements and Contracts).

Useful information sources include:

  1. Other equipment safety standards;
  2. Other relevant legislation and standards for operations in other legal jurisdictions.

For more information on this vital task, see the post on System Requirements Hazard Analysis here.

Top Tip

Create Project Safety Organization

Ultimately, the project safety management organization will be defined in the Safety Management Plan (SMP) (Procedure SMP03 – Safety Planning). However, in advance of the preparation of this document, it is necessary to set up key elements of the safety management organization, as follows:

  1. Appoint competent PSM;
  2. Appoint Independent Safety Auditor (ISA), if required;
  3. Form Project Safety Committee (PSC) (membership and role defined in Procedure SMP02 – Safety Committee);
  4. Produce high level definition of other project safety responsibilities, in the form of an initial project RACI (Responsible, Accountable, Consulted, Informed) chart for the safety management process defined for this stage of the project.

Appointment of an ISA is advisable for projects that are complex, novel, or assessed as having high levels of safety risk. The appointment of an ISA may also be mandated by domain-specific requirements or standards. 


The organization uses a number of methods of enabling compliance:

  1. Delivery Teams develop System Specifications to meet User Concept Document statements from the Project Sponsor. This is an important method for advising industry of the Enterprise’s safety and environmental requirements;
  2. The Through Life Management Plan incorporates the impact of safety and environmental legislation on the relevant equipment both now and in the future (The Project Safety and Environmental Management Plans are integral parts of the Through Life Management Plan);
  3. Use of Enterprise guidance in the development of contracts and contract conditions.

Where the Delivery Team also develops the User Concept Document on behalf of the Project Sponsor, it is extremely important that these reflect the Enterprise safety and environmental performance objectives and targets, recognizing and emphasizing any politically or publicly sensitive issues. The advice of organizational Subject Matter Experts in Safety, Sustainable Development & Continuity must be sought in the construction of the User Concept Document.

Although reference to Enterprise guidance provides the Enterprise with some protection, any Invitation to Tender must explicitly describe the project’s requirements for safety and environmental management.  In addition, compliance and performance requirements, resulting from the User Concept Document and System Specification and the project’s Safety Management Plan.

Access to information about safety and environmental legislation is enabled via a number of organizations and media – the following provides some primary examples:

  1. Legislative Registers held by the Program Teams;
  2. Defence Regulator intranet pages, Enterprise’s Safety net etc;
  3. Websites and publications of the Health & Safety Executive, Professional Societies and of lawyers or consultancies specialising in providing information and knowledge of safety and environmental matters and current affairs;
  4. Suppliers, contractors and consultants;
  5. Other projects and Delivery Teams.

Identification of and compliance with all relevant safety and environmental legalization will always ultimately be the responsibility of the Delivery Team member with delegated authority for safety and environmental protection.

Since safety and environmental legislation is continuously evolving, Delivery Teams are strongly recommended to seek expert advice on new requirements that might be likely to come into force during the project life cycle.

The wider Enterprise may maintain a list of approved specialist contractors as part of a Framework Agreement for Technical Services enabling arrangement (AKA a list of approved suppliers). This maps suppliers’ capabilities against a range of safety and environmental management areas, enabling Delivery Teams to select contractors with the necessary levels of experience and expertise for specific tasks.

Membership of the framework agreement is open to companies of all sizes and is secured by qualification against pre-determined criteria, rather than by competition. All members are subject to the same terms and conditions throughout the duration of the framework agreement.

Records and Project Documentation

Where relevant, the outputs from this procedure will feed into the following:

  1. System Specification – for any specific Safety requirements;
  2. Customer Supplier Agreement – to document agreements on Safety information to be delivered by the Delivery Team;
  3. Through Life Management Plan;
  4. Safety elements of Outline Business Case submissions.

In addition, as the competence of the PSM is relevant to the safety assurance on the project, the evidence should be retained from the selection process to verify the appointed individual is competent to perform the required responsibilities.

Warnings and Potential Project Risks

If Delivery Teams fail to carry out this procedure in a timely manner, there will be delays in engaging stakeholders, recognizing legislative or other requirements, or creating the safety organization. This will inevitably result in risks to project costs and timescales.

If the project fails to co-ordinate the treatment of stakeholders and legislative requirements between the safety and environmental management system, there is a risk that there will be inconsistent communication to stakeholders and duplication or omission of requirements (e.g. falling between the two).

The legislative and other requirements register will not be read across from one project to another, even if they are similar in scope, without a detailed review.

The competence of PSMs and ISAs is critical to the safety success of the project. It is important that this competence should be assured, and that records demonstrating that this has been done should be retained. If this is not done it will be difficult to demonstrate that safety and environmental responsibilities have been discharged correctly.

Procedure Completion

The PSM will identify the legislation, regulators, and approval authorities that the project will need to satisfy, and any requirements for independent safety certification.

The PSM will maintain a legislative register as an integral part of the Safety Case for each project.

The internal and external auditors should check for legal and policy compliance as part of their assessment of the Safety Management System (SMS), Safety Management Plan (SMP), and Safety Case.  It should be noted that responsibility for compliance still rests with those with delegated responsibility rather than with the auditor.

Project Safety Initiation: Timing

Initial Application

In an acquisition program, the procedure should be carried out early in the Concept phase.  Stakeholders, system boundaries, supporting systems/arrangements, and acceptance authorities need to be identified as early as possible to support the subsequent Preliminary Hazard Identification activity (Procedure SMP04 – Preliminary Hazard Identification) and the preparation of the SMP.

The procedure can be applied at any point of the life cycle where it is necessary to initiate a formal safety management process.


The registers of stakeholders and requirements should be reviewed and updated after Outline Business Case and Full Business Case as part of the review and update of the SMP.

New Safety Managers could also use this as a take-over checklist, to make sure all necessary decisions have been made and clearly documented.

Top Tip

Project Safety Initiation: Required Inputs

The procedure may use the following reference inputs, as available:

  1. User Concept Documentation (for Acquisition Programmes);
  2. Any other information on the proposed functionality, use, support and context of the proposed system;
  3. Existing Hazard Logs for existing similar systems;
  4. Relevant Enterprise Policy.

Project Safety Initiation: Required Outputs

The Outputs of the procedure will comprise:

  1. Appointed PSM and ISA, if appropriate;
  2. Completed Form SMP01/F/01 – Safety Operating Environment Questionnaire;
  3. Completed Form SMP01/F/02 – Register of Stakeholder Requirements and Information, which should be reviewed and updated as the project proceeds;
  4. Completed Form SMP01/F/03 – Register of Safety Legislation and Other Significant Requirements, which should be reviewed and updated as the project proceeds.

The Delivery Team should consider addressing legislation and similar issues amongst standardization issues especially when producing and reviewing the standardization strategy and implementation plan. These issues occur throughout the life of the project which the Delivery Team controls. These also occur when updating the project standards database, and project Safety Initiation documents SMP01/F/03 with changes in legislation and international agreements.

Acknowledgment of Copyright

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.

Project Safety Initiation: How would you kick off your Safety Program?

Blog Safety Management

The Risk Matrix

In this article, I look at The Risk Matrix, a widely used technique in many industries. Risk Matrices have many applications!

In this article, I have used material from a UK Ministry of Defence guide, reproduced under the terms of the UK’s Open Government Licence.


A risk matrix is a graphical representation of the various risks associated with a project and its corresponding risk management strategies. It helps to identify and prioritize potential risks.

What is a Risk Matrix?

A safety risk matrix provides a framework for ranking or classifying safety issues according to their significance. The matrix is sometimes called a “hazard ranking matrix” or a “hazard classification matrix”, but it is strictly applied to accidents, since these have harmful outcomes, whereas hazards only have the potential for harm. The matrix can be used as a risk screening tool to help decide which issues need treatment first or which need not be considered further at this time.

Risk matrices can cover exposure to different types of loss, including harm to humans, damage to the environment, financial loss or impact on reputation. If a loss in these diverse categories can be considered in common terms (e.g. the monetary impact of all types of loss), then a single matrix can cover all such issues together and prioritize which are the most significant.

The matrix covers a “risk space” defined by the two component parts of risk, namely likelihood on one axis and consequence (or severity) on the other. Each axis must span the full range of outcomes, which are considered possible for the system of interest. Each range is divided into a number of categories or bands (typically between 3 and 8) to define the cells of the matrix.

The bands on the two axes may be defined in terms that are purely qualitative, semi-quantitative, or fully quantitative, for example:

  • Qualitative:
    • Likelihood is (Frequent/Reasonably Probable/Remote/Extremely Remote)
    • Severity is (Minor/Significant/Severe/Catastrophic)
  • Semi-quantitative:
    • Likelihood is (e.g. likely to occur once per year on one site)
    • Severity is (e.g. a single death)
  • Quantitative:
    • Likelihood is (e.g. between 1×10-4 and 1×10-5 per year on one site)
    • Severity is (e.g. between 1.0 and 10.0 Fatalities and Weighted Injuries)

Each cell of the matrix is assigned an indicator defining the relative significance of issues falling in that zone. This indicator could be:

  • A risk descriptor (e.g. Low, Moderate, High, Very High)
  • A risk score or index (e.g. a number from 1 to 20)
  • A priority category (e.g. High, Medium or Low)
  • A risk class (e.g. A, B, C or D)
  • A measure of expected rate of harm or loss (e.g. 5.4 Fatalities and Weighted Injuries per year or £45,000 per year)

Where likelihood and consequence are stated quantitatively, the axes are usually considered to have logarithmic scales. Adjacent bands will typically differ by one order of magnitude. In this case, lines of constant risk run diagonally across the matrix and the risk will range by a factor of 100 across the area covered by a single cell. This illustrates that the matrix is a coarse tool, which can show large differences in risk, but does not address fine detail, such as compliance with quantitative risk requirements.

To apply the matrix, users must have a list of the relevant safety issues (from Hazard Identification and Hazard Analysis) and estimates of the likelihood and severity of each possible accident (from Risk Estimation). The matrix is therefore a technique for Risk Evaluation, which follows on from Risk Estimation. The estimates of accident likelihood and severity may be generated by different methods, depending on the stage of the project, the information available and the significance of the safety issue being explored. For example, the estimates may come from:

  • Engineering judgement by Subject Matter Experts with knowledge of similar systems
  • Historical data from this or similar systems
  • Detailed modelling (e.g. using Fault Tree Analysis and Event Tree Analysis or Bow-Tie Analysis)

Examples of Risk Matrices

The following example matrices show some of the variations in format, terminology and risk indicators across a range of sectors and standards.

Example 1: IEC 31010 Example risk ranking matrix. Severity on x-axis increasing left to right, likelihood on y-axis increasing bottom to top, with five “risk levels” which are linked to decision rules such as the level of management attention or the time scale by which response is needed.

IEC 31010 Risk Matrix

Example 2: Def Stan 00-56 Issue 2 Example accident risk classification table. Severity on x-axis increasing right to left, likelihood on y-axis increasing bottom to top, four risk classes identify significance and so management level for approval.

Def Stan 00-56 Issue 2 Example Accident Risk Classification Table

Example 3: IMO Guidelines on FSA. Example hazard risk index matrix. Severity on x-axis increasing left to right, likelihood on y-axis increasing bottom to top, risk index (RI) in each cell calculated by adding Severity Index (SI) for column and Frequency Index (FI) for a row. RI can be considered as log(risk), obtained by adding FI and SI.

FIFrequencySeverity (SI)
6 78910
5Reasonably probable6789
4 5678
2 3456
1Extremely remote2345
IMO Guideline on FSA: Risk Ranking Matrix

Example 4: ISO 17776 Offshore Sector Example risk matrix. Severity on y-axis increasing top to bottom, likelihood on x-axis increasing right to left to top, matrix areas define future action to be taken.

ISO 17776 Risk Matrix

Risk Matrix Assessment

When it Might be Used

The matrix is usually set up at an early stage of the lifecycle, defining the framework to be used for risk evaluation at subsequent stages. It should be used early in the lifecycle to provide a coarse sift of the identified safety issues so that attention can be focused on the most significant ones. This attention may involve more detailed analysis to understand complex accident sequences and to apply semi-quantitative or fully quantitative risk assessment techniques where appropriate.

Later in the lifecycle, the risk matrix may be used for determining the appropriate management level for review and acceptance of each safety issue. This ensures that the key risk drivers are brought to the attention of senior managers but they are not swamped with masses of information on less significant matters.

During the in-service stage of the lifecycle, the risk matrix technique can be applied to give an indication of significance for new safety concerns, such as those revealed by incidents or due to proposed design changes. Risk monitoring can be focused on the issues of highest significance as well as targeting resources for risk reduction.

Advantages & Disadvantages


  • Risk matrices provide a quick appreciation of the most significant issues so that attention can be focused where it will have most benefit.
  • Matrices provide a visual representation which is easily understood and so aids communication with non-specialists.
  • Risk matrices can cover impacts which are different in nature (e.g. harm to people, harm to the environment, material or financial loss), provided that these can be equated in common units (e.g. in money terms).


  • Risk matrices are good for examining different issues affecting one system or activity on the basis of their risk relative to each other. They are not effective for understanding absolute risk.
  • There is no single, correct interpretation of the level at which “safety issues” should be selected for presentation on the risk matrix. This means that different analysts may choose different levels and the resulting list of prioritised issues is somewhat subjective. The apparent results may be changed by “accident splitting” (i.e. defining one safety issue as two or more different accidents, each of which will appear to have lower risk).
  • Risk matrices consider safety issues one at a time and so do not help understanding the overall or aggregate risk exposure.
  • When a variety of different outcomes is possible from a single issue (e.g. fire – consequences can range from no harm to multiple deaths) it can be difficult to choose which likelihood and consequence combination should be used.
  • As a broad-brush technique, risk matrices should not be used for considering whether quantitative risk targets have been met or as the only technique for examining complex or high consequence issues. The matrix can, however, highlight high consequence issues so that they then receive more detailed consideration.

Risk Matrices for Project Management

In project management, we are aiming for specific outcomes, often represented as the project management triangle.

Project Management Triangle

In the center is quality (and/or safety), which is central to indicate that this cannot be compromised.  The three corners are cost, time, and scope (or requirements), and these can be traded off against each other.

This representation helps us to identify project risks by the effect that they might have on the project’s objectives.  ISO 31000 defines risk as “the effect of uncertainty on objectives”.  Again, the risk matrix allows us to identify and rank risks, identifying the biggest, most critical risks.  These risks are where we will focus most attention, looking for multiple controls, or defense-in-depth, for the most serious ones.   

An old saying is that “you can have a quick job, a proper job, or a cheap job; you can have two out of three, but you can’t have all three.”  Taken literally this is a little pessimistic, but it does remind us that if we set an absolute target on one of these axes, then we will likely have to trade the other two off against each other.   

This axiom also gives us some basic principles on which to identify controls.  We might desire controls that allow us to achieve all objectives at the same time, but this is often unrealistic.  Practical experience – encoded in a saying – suggests that we must be prepared to accept some trades in budget/schedule/scope.

Thus the risk matrix, in combination with some basic project management principles, enables more realistic decision-making.  (Real decisions involve saying ‘no’ to some things in order to say ’yes’ to others.)  Rather than naively thinking that we can have it all, the risk matrix supports robust early decision-making. 

This should make project success more likely – until somebody changes the objectives!

Additional Considerations

It should be noted that risk matrices from different standards and industry sectors are not always represented in the same way. The most common convention has a Cartesian representation (i.e. values increasing left to right and bottom to top on the two axes) so that risk increases from bottom left to top right, but the examples below show that several common matrices have a different format.

If risk estimates are generated by a team of Subject Matter Experts, their deliberations can be biased (consciously or unconsciously) if they know the risk matrix framework. There may be a tendency to choose likelihood and/or severity estimates that result in a lower apparent risk so that it attracts less management scrutiny.

Uncertainty of the estimates of severity and likelihood can be represented on a risk matrix by showing that risk with error bars rather than a single point. This can help understanding by senior managers.

Using common matrices for different systems does not necessarily result in risk estimates that can be compared in a meaningful way. The systems may have diverse risk exposure factors (e.g. number of people exposed, usage rate) and different numbers and types of accidents to consider.

(For more on risk management, see the FAQ.)

Do You Use a Risk Matrix in Your Work?

Blog Safety Management

Risk: Averse, Adverse, or Appetite?

You heard me right. Risk: Averse, Adverse, or Appetite? Which would you choose? Do we even have a choice? Read on …

We often hear that we live in a risk-averse society.  By that, I mean that we don’t want to take risks, or that we’re too timid.  I don’t think that’s the whole story.

In reality, we need to deal with several concepts.  Let’s start by looking at risk:

  • Aversity;
  • Adversity;
  • Appetite; and then
  • Perception.

Risk Adverse versus Risk Averse

These terms are often used incorrectly, so here’s a useful comparison:

Many people are confused when faced with the choice between adverse and averse.  While these two adjectives have many similarities, they are not used interchangeably.
If you want to describe a negative reaction to something (such as a harmful side effect from medication) or dangerous meteorological conditions (such as a snowstorm), adverse is the correct choice. You would not say that you had an ‘averse’ reaction to medication or that there was ‘averse’ weather.
In short, adverse tends to be used to describe effects, conditions, and results; while averse refers to feelings and inclinations.”[1]

Merriam-Webster Dictionary

Risk Adverse

A Formal Definition of Adverse

Again, the Merriam-Webster Dictionary sails to the rescue:

  • 1: acting against or in a contrary direction:
    • HOSTILE,
    • hindered by adverse winds
  • 2a: opposed to one’s interests,
    • an adverse verdict,
    • heard testimony adverse to their position,
    • especially: UNFAVORABLE,
    • adverse criticism
  • b: causing harm: HARMFUL, adverse drug effects
  • 3: archaic: opposite in position”[2]

This is all very well, but we need something that we can use, like a…

…Practical Definition of Risk Adverse

The Law Insider website provides a very useful definition of ‘Risk Adverse’.   

“Adverse Risk means any risk of an adverse effect on the Development, procurement or maintenance of Regulatory Approval, Manufacture or Commercialization of a Product.”[3]

Law Insider

It’s useful because it is so pertinent to safety.  Let me explain. Often, we want to develop a product or service, but there are:

  • Development risks – often called Project Management risks, as a development is often the focus of a project.  Remember that the ISO 31000 defines risk as “the effect of uncertainty on objectives”.  By definition, a project has specific objectives (e.g., budget, schedule, and quality). 
  • Procurement risks – when acquiring a new product or service and enterprise may also acquire development risks, for the new or upgraded thing.  There are also risks associated with contractual acceptance, fielding the product, etc.
  • In many industries and domains, regulatory approval may be needed.  This may require qualification, certification, or accreditation (or a combination thereof).
  • Commercialization risks include making a product commercially viable, positioning it in the market, and gaining user and/or public acceptance.     

Each one of these topics is a massive subject, about which countless books have been written.  Law Insider’s definition is very powerful!

Risk Averse

So, risk aversion is about feelings and inclinations.  This is such a familiar topic, that perhaps we don’t bother to explore it. Later on in this post, we will explore Risk Aversion by looking at Risk Perception.

Before we do that, let’s look at the opposite of Risk Aversion.

Risk Appetite

“Risk appetite is the level of risk that an organization is prepared to accept in pursuit of its objectives, before action is deemed necessary to reduce the risk. It represents a balance between the potential benefits of innovation and the threats, that change inevitably brings. The ISO 31000 risk management standard refers to risk appetite as the “Amount and type of risk that an organization is prepared to pursue, retain or take”. This concept helps guide an organization’s approach to risk and risk management.”[4]


Risk appetite is a really interesting concept.  The definition is that risk appetite is the level of risk that a person or organization is prepared to accept in pursuit of objectives. 

Why is Risk Useful?

Risk is necessary because we need to take risks to do almost anything. Every time we breathe in, every time we eat or drink something, we’re taking a risk.

It’s the same for businesses, enterprises, and nations.  If we keep on doing the same old thing again and again, eventually someone else will come along and outcompete us.  Ironically, the risk is that we fail to adapt and cease to exist – Darwinian selection. 

A great example of this is the Kodak corporation.  For years Kodak dominated the photography market.  However, they failed to see the promise of digital photography and didn’t take advantage of it. They were overtaken by rivals, and in the end, this mighty corporation went out of business.

So to ensure the survival of an entity, we must accept change, we must take risks. This seems to be true of populations, businesses – even software programs seem to illustrate this kind of evolutionary development [5].

Quantifying Risk and Appetite

In some areas of business, it’s easy to define risk appetite.  Financial corporations can easily define how much loss they are prepared to accept.  They can accept that a certain percentage of turnover or profit will be lost to fraud or error. 

A more sophisticated business might quantify the benefit of taking risks.  For example, lending more money might result in greater profits.  If a business understands the relationship between risk and opportunity, it can exploit it.

Too Big to Fail

A few years ago we saw the downside of that thinking.  Organizations thought they were too big to fail or too clever – they couldn’t go wrong.  Some high-profile failures lead to a domino effect, whereby many institutions effectively collapsed.  This was the Global Financial Crisis. 

As a result, the regulation of lenders was tightened up.  Banks and similar bodies were forced to keep higher reserves of cash and assets in order to survive miscalculations of risk.

How Much Risk is Enough?

So, how can we determine an appropriate risk appetite, without over-reaching ourselves?

This is a particularly difficult judgment when considering safety. Now we are not trading $ for $, we are trading dollars for injury and even death.  This is a much more difficult ethical problem.  There are various ways of making this judgment, for example in Australia we can refer to Safe Work Australia’s guidance

In this article, we will consider what leads us to a distorted perception of risk. 

Risk Perception

Some researchers claim that there are three factors that cause us to look at risk and misunderstand it.

Psychometric research identified a broad domain of characteristics that may be condensed into three high order factors: 1) the degree to which a risk is understood, 2) the degree to which it evokes a feeling of dread, and 3) the number of people exposed to the risk. A dread risk elicits visceral feelings of terror, uncontrollable, catastrophe, inequality, and uncontrolled. An unknown risk is new and unknown to science. The more a person dreads an activity, the higher its perceived risk and the more that person wants the risk reduced.[6]


I have observed that people are ready to take more risks when they think they are in control.  For example, we’re more willing to take risks when driving, rather than in trains or planes where someone else is in control. 

It’s interesting to recall that our risk of death per journey is the same in a car as it is in a plane.  Moreover, we are three times more likely to be injured in a car crash than in an air crash.  Yet, people worry about flying, but they don’t think about the car journey to get to the airport. 

Therefore, if we are to think rationally about risk, we must address those three factors of risk perception – and control. 

Three Risk Perception Factors

First, we must understand risk.  Risk assessment helps us to do this and can help us make objective decisions.

Second, we must recognize feelings of dread, for example, fear of radiation.  We must strive to understand the mechanisms that give rise to risks so that we can understand how to treat or control them. This should give us confidence, which will counteract dread.

(Also, we might explicitly identify the benefits of the risky activity.  This should help us to deal with dread rationally.) 

Third, we must estimate the number of people exposed to the risk.  Accidents with multiple casualties cause Societal Concern and get a lot of media attention, whereas the constant background of individual casualties in car accidents goes largely unreported.

Let’s Look at Control 

We often have the illusion that we are in control, and that this will prevent accidents.

The night I had my most serious car accident, I was hit by a drug/ drunk driver.  I had not lost control of my vehicle and I had done nothing wrong.  However, when the other car turned into my path, I could not avoid the collision. 

We need to give people a realistic view of how much they really control. 

If we can give people control, without real adverse effects, then so much the better.  Either that or take away control completely and make sure that users know this.

Many fatalities have resulted from users misunderstanding how much control they had – for example over ‘self-driving’ cars.  


All these factors are challenging to deal with.  Moreover, there are a number of agents using social media to stoke and exploit public outrage. This is done for various purposes, which may have nothing to do with actual levels of risk (i.e. it not be a genuine societal concern).

Perhaps we can learn from those who manage outrage for enterprises that need it?  

They work to actively and regularly present a rational view of risks and benefits.  This is intended to counter the sensationalist reporting that will arise from time to time.  Think of it as a regular vaccine of rationality against periodic outbreaks of emotional outrage.   

Risk: Averse, Adverse, or Appetite? Conclusion

Of course, there are no guaranteed solutions or magic answers to these questions.

We will always have a subjective and visceral reaction to danger.  This is a good thing, essential even.  It’s a very important survival skill, and we should be afraid of things that can hurt us.

Yet, to live without risk at all is simply not possible – we will all die of something.  Will we achieve something meaningful before that dread day comes?

To do anything requires us to take risks.  As individuals, as a society, we need to take risks to enjoy the benefits that result.  “Great empires are not maintained by timidity” as a Roman historian once said[7].  

As in so many things, we are looking for a balance. 

How much risk-aversion do you need to survive, versus how much risk appetite to thrive?

(For more on risk management, see the FAQ.)





[5] Les Hatton & Greg Warr, Conservation of Information in Proteins, Software, Music, Texts, the Universe and Chocolate Boxes, Heiland Lecture, Colorado School of Mines, 06 Mar 2018.



Blog Safety Management

Hazard Logs and Hazard Tracking Systems

In this blog post and video ‘Hazard Logs and Hazard Tracking Systems’, I’m going to tell you about the benefits and features of Hazard Logs and Hazard Tracking Systems. I’m going to be covering these topics, which are the most commonly asked questions:

  • 1. What is a hazard log? (What is it what do we do with it?)
  • 2. The key elements of a hazard log (what needs to be in it to make it work)?
  • 3. Hazard Log management (what we need to do)?
  • 4. What about hazard log tools? (What can we use to create a hazard log)?
  • 5. What’s the difference between a hazard log and a risk assessment?
  • 6. What’s the difference between a hazard log and a risk register?

The Video: Hazard Logs and Hazard Tracking Systems

Watch the full, 35-minute lesson.

The Blog Post: Hazard Logs and Hazard Tracking Systems

Hi everyone, and welcome to the Safety Artisan.

I’m Simon and today we’re going to be talking about Hazard logs and hazard tracking systems.

As I said, we’re going to look at hazard logs and hazard tracking systems and we’re going to be answering the most popular questions.

The most often asked questions about Hazard logs and Hazard Tracking Systems that you will find on the internet. So that’s what we’re going to answer.

And this is going to be the first of three sessions on this subject.


Topics for this session. Right now commonly asked questions are:

  • What is a hazard log? What is it what do we do with it?
  • The key elements of a hazard log, what needs to be in it to make it work?
  • Hazard Log of management, what do we need to do?
  • What about hazard log tools? What can we use to create a hazard log?

Effectively now we’ll be looking at that in much more detail in sessions two and three but we’ll just go over the basics today and then also, some very common questions:

  • What’s the difference between hazard log versus a risk assessment? and
  • What’s the difference between a hazard log and a risk register?

And when I say Hazard Log, you can substitute has a tracking system at all times.

They’re really one and the same thing, which we will talk about.

What is a Hazard Log?

That neatly brings us onto what is a hazard log.

And I’ve got a definition here which is actually from the UK Ministry of Defence guidance, but it doesn’t really matter where it came from and just acknowledging the source.

But the definition is really useful in that a tells you what a hazard log is.

But also, it defines a hazard log in terms of what it does.

These are the benefits that a Hazard Log gives us.

It says a Hazard Log or a Hazard tracking system is a continually updated record of the hazards, accident sequences, and accidents associated with the system.

We’ll unpack that in just a moment.

It’s Not Just a Log!

But the point I want to make here, it’s a continually updated record. Okay? It’s a management tool.

It’s not a log. You know, I always think of captain’s log in star trek, which the idea that it’s just like a ship’s log, it’s a recording of everything that’s happened.

Well, you can do that.  you can have a very rigorous recording of who’s done what, when and that’s all good.

But it’s not just a sort of dry dusty record that should sit on the shelf.

It’s a tool to help us manage risks associated with a system.

We’re managing a system, whatever it might be, it might be a physical system, a vehicle, it might be an enterprise business, it might be a piece of software, it might be an IT system, you know, where you’re a bank and you’re using an IT system to service all your customers, etcetera.

It could be any one of those things and a hazard tracking system that enables us to manage all the information that we need to look at risks associated with that system.

It’s worth saying that normally we use hazard logs for safety whereby we’re worried about harm to people, but that’s not their only application.

You can use a hazard log or a risk register in any application.

We might be talking about financial loss, damage to reputation, equipment, harm to the environment, all of these things.


What is the hazard log? Well, it’s structured and we’ll talk about structure in a moment.

structure implies we’ve got lots of pieces of information, but they are linked together into a coherent structure.

And that’s very important. We’ll spend a lot of time talking about that later.

But those languages really are the key to the Hazard log.

It’s a structured means of storing and referencing, safety, risk evaluations, and other information relating to a piece of equipment or system.


A safety risk evaluation. we’ve got the assumption is that we’ve done some risk analysis, we’ve done some risk assessment, which is a structured series of risk analyses in order to look at the total picture of risk.

We’ve evaluated that risk against some kind of norm that we’ve said, you know, this is how much risk we’re willing to put up with and we can’t tolerate that. That’s the evaluated bit we’ve evaluated against some framework or benchmark.

Risk Reduction

It’s the principal means of tracking the status of all the hazards decisions and actions to reduce risk because typically we’re not doing this for the sake of it.

We’re doing this because we have risk and we need to manage that risk. And generally speaking, we want to reduce risk.

And there are other decisions to be made about How do we deal with risk?

You know, maybe we reduce it and live with it. Maybe we give it to transfer it to somebody else if we can or we get insurance for stuff that we’re not happy with whatever it might be.

There are lots of lots of different approaches but it’s all about tracking the status.

It’s the Key

We saw in the middle of the definition about storing and referencing risk evaluations. We’re probably referencing out to other documents to other artifacts that record and analyze the risk in detail.

But the hazard log is our key to finding all of those things.

we have references in there and we can track the current status of where we think all these risks and hazards are, how much risk is there associated with our system?

That is what a hazard log is.

And as you can see, it’s defined by what it does, which is also the benefit of using a hazard log. They’re all one and the same thing.  let’s move on.

Key Elements of a Hazard Log #1

What are the key elements of a hazard log? I’ve got two slides on this.

First, you remember we talked about what goes in a Hazard Log of hazards and risks and everything to do with the accident sequence or accident sequences associated with the system.

Typically what we have in a hazard log is we have a bunch of hazards.

Now each hazard may have multiple causes. There might be a hardware failure, software failure, environmental issues that could give rise to a hazard; there might be erroneous human activity.

All sorts of causes can lead to one hazard.

And also, one hazard can lead to a number of different consequences. For example, if we have, if we’re thinking about a ship, we’ve got a hazard that says flooding, we’re getting water in where it’s not supposed to be.

Well, actually, you know, if there’s, if the ship floods, people could drown inside the ship, the ship could, I think it could founder and think it could get full of water that it loses buoyancy and sinks or it could unbalance the ship and it could cap sites: and that’s just the accident outcomes.

Most of the time, if the hazard is present, nothing bad happens at all.  Some water gets in the ship. We don’t want it. Well, we pump the water out, most ships have got bilge pumps to get the water out or if it’s just a canoe, you take it out of the water, turn it upside down and you get the water out.

No problem. consequences aren’t always harmful.  They’re not always desirable, but they’re not always harmful either.

We can get a range of consequences, a range of causes, and one hazard in the middle.

And this representation is what’s called a bowtie analysis because it looks like a bow tie. I’m not recommending bowtie analysis, but it’s a great way to represent and explain an accident sequence. That’s all I’m using it for in this instance.

Key Elements of a Hazard Log #2

What do we typically have in a hazard log?

Accident Sequence

On the right-hand side here, you can see that we’ve got the progression from causes, through to hazard through to accidents or consequences.

And we all have lots of hazards, probably lots of lots of causes and some accidents.

They will all be linked and there’s the accident sequence on the right-hand side, you know, this curve from bottom to top, as we can see hazards linked to accidents and hazards linked to causes, but causes do not directly link to accidents because you’ve always got to go via a husband.

The definition of a hazard is the one that we’re using here, is that it’s enough, it’s enough, it’s sufficient to cause an accident. But the accident isn’t inevitable just because the hazard exists.

If there is a banana skin, I’ve got rather a humorous comic version here, if there is a banana skin on the pavement and there are people walking on the pavement, yep, that’s a hazard.

An accident is perfectly possible, but it doesn’t mean it’s inevitable. People might walk around the banana or goodness knows somebody might pick it up and throw it away. The accident is not inevitable, but once the hazard is there, that’s enough. (As opposed to there being a banana skin in the bin, that’s not a hazard.)

Once we get to the Hazard, nothing else unusual needs to happen for somebody to get hurt.

That’s the accident sequence now linked to causes hazards, and maybe accidents and controls.


These are the things that stop the accident sequence from progressing and actually, maybe it’s if we go back to the previous slide.

It’s probably a little bit clearer here, we can imagine controls as vertical barriers between the causes, the hazard, and the consequences. And then you know, there’ll probably be some controls.

We’ve got controls linking to all three, and controls are not perfect. Usually, they only reduce the severity of the accident/harm. Others reduce the likelihood of harm.

We’re reducing risk all the time and in addition to those, we have references.


All of our entities in the hazard log, maybe they are more fully described in a document or some other artifacts.

Maybe we’ve done some modeling to determine how much risk there is. There is a computer model somewhere that says this is how we model the risk and therefore this is what we think the level of risk is.

We refer out other things.  Which are under configuration control.  They’re not just random bits of paper. They’re actually authorized and dated and version numbered and they’re stored somewhere safe.

But of course, I’m getting ahead of myself. Those are the documents.


Maybe we’ve got a database full of documents or maybe we’ve got physical documents or a mixture. The hazard log references those documents.

And if there are electronically stored some hazard logs will give you the ability to electronically link to hyperlink to those electronic documents.

You can go into the hazard log; you can follow the audit trail and then get back to the evidence, on which all of this is based. You’ve got a complete picture if you like of your safety case. Basically, you’ve got your argument here that you’ve managed all of the hazards appropriately.

Let’s say you’ve reduced the risk of your hazards down to an acceptable level and that’s all documented and justified it somewhere else, but you’ve got links to it.

Not all, in fact, the minority of Hazard logs in my experience, go that far, but it’s, you know, it’s an ideal to aim for. It requires a lot of discipline to link all the documents in and maintain that level of configuration control, but it can be done.

Those are the key elements of a hazard log.

Not all hazard logs will have all of those things. For example, some standards tell you that causes are optional. You don’t have to have causes. Maybe you won’t have hyperlinks to everything etcetera, etcetera.

But most of those things you will have personally, I would argue it causes are essential but that’s another story will come to that later.

Managing Hazard Logs and Hazard Tracking Systems

Yeah, we talked about hazard log management in the sense of what a hazard log allows us to manage and what it allows us to do more sort of the benefits.

But how do we actually manage a has a long day today?

Well, somebody has got to look after the hazard log, an individual or a team of people maybe.

If we’re managing a complex system, things will be happening in the real world, which we need to track. Maybe we’ve had incidents, maybe we’ve had near misses, maybe, unfortunately, we’ve had an accident. That information has got to be assessed and we’ve got to either put it in the hazard log.

You could have an incident registering your hazard log as well. Or maybe you’ve got a separate incident register, but we need to look at the incidents and we need to look at any trends that are going on and saying, well, when we bought the thing or design the thing and we thought that this, this hazard would, would pop up very infrequently, maybe once a year, but actually it’s happening once a month.

We need to change the probability of the hazard. An incident might be that a hazard has been, has occurred, but it hasn’t led to an accident, there’s been no actual harm. But we’ve noted that something untoward has happened.

We’re looking at that and go, well, actually the probability is worse or better than what we thought it would be.

And we need to update that Hazard Log to keep track of that; those two things need to be done.

Decision Support

The reason that we’re doing this is the hazard log is there to support decisions made by people in authority. And those people in authority, need an accurate picture of the risk to say, well what is the real level of risk?

You know, we said we would go ahead and use the system because we thought the risk was down here.

Maybe now we realized there’s more risk in what we’re doing than we thought.

Can I accept that or do I have to reduce it?

And the hazard log helps us to rank risks and say these are the most important risks.

These are the biggest risks that we should be paying the most attention to because we should be reducing risk.

We should be continuously monitoring to say, you know, is the system running acceptably or an unacceptable level of risk.

And the hazard log helps to support those decisions by ranking risks amongst other things.

And then fourthly, we need to do quality control.

Quality Control

At the micro-level, we need to make sure that the data in the hazard log, the information is accurate. It’s up to date. It’s justified. We haven’t just got somebody’s best guess in there if we can do better.

That’s the kind of microscopic level, but there’s also, the sort of macro-level with quality control in that I’ve seen hazard logs that have been used as a dumping ground for all sorts of information.

That actually is nothing to do with hazards and risks. Okay?

And if that happens, you can end up with a bloated hazard log with hundreds or even thousands of entries and then that hazard log effectively becomes unusable.

Okay? it’s no longer fit for purpose because there’s much information in there, we can no longer see the wood from the trees.

We can’t support sensible decision-making because we’re blinded by all this guff this information that isn’t really pertinent.

we need to do quality control at both those levels and the one is dependent on the other.

Clearly, if we’ve got a hazard log that’s full of rubbish quality information, then the trends and the decision-making advice whether we’re getting are probably going to be rubbish as well.

But we’ve also, got to be aware that if we don’t manage to hazard log properly, we could end up with something that just doesn’t work as a hazard lob anymore.

Configuration Control

It’s just got too bloated and a big part of that is the 5th bullet, which is both micro and macro quality control is configuration control.

we control hazard log, we don’t allow just anybody to shove random information in there we make sure that only authorized people are putting in authorized information, which has been quality check.

We were confident that it’s the best quality that we can get. It’s justified.

There’s something, there’s some evidence that justifies the decisions that we’re making on what we’re putting in the Hazard log.

that configuration control is very, very important and it’s one of the reasons for having an automated to actually in the s specialist who will do a lot of these things or help you do a lot of these things for you.

I’ll help you with the discipline of hazard log management.


I’ve mentioned tools, here’s a screenshot of actually quite an old tool.

Now it’s quite difficult to get hold of Cassandra but that doesn’t really matter, it’s just an illustration.

This is the kind of view that you get from a purpose-built hazard log tool. It’s built upon a database.

And on the left-hand column here you’ve got some summary information you can get an overview of how many accidents hazards causes and controls, etcetera. You’ve got some numbers tracking [how many hazards there are at] their different status[es] as they go through the life cycle.

And then typically at the top here we’ve got some basic information title, description, who put it in, what’s the likelihood for example, and then at the bottom on this version we’ve got here is an overview of all the links to other things.

[Here we are, you can see we are in what were we in? We’re in a test hazard.]

We’ve got links to accidents, controls, causes, references, and history in this database and we can link all of those things together to get that structure to get a picture.

Tool Types

Once we have that structure we can start at any point in the hazard log, you know, we’ve had an incident and then we can follow it through, we can follow the links through to find all the pertinent information, and essentially that’s what the structure does for us.

We might be using a database very often we might be using a spreadsheet, might we might be using a commercial tool as a hazard log or a risk register or indeed, and that might be part of a suite of tools that does various things where we’re linking risk management to configuration management to product management to whatever it might be.

We might have a suite of tools.

Now, in the second session of these three lessons, I’m going to be talking about commercial tools that are all based on databases.

I’m going to be talking about what you get with a fully-featured commercial hazard log tool, has a tracking tool.

Spoiler Alert – Spreadsheets!

And then in the third session, I’m going to be talking about how you implement some of that in a spreadsheet.

Now, and it’s important to remember if we go back up what we have here, we looked at these key elements, what we’ve got here is a set of relations and if we store this, what we have is a relational database.

we’ve got many too many linkages between different entities.

Okay now, strictly speaking, we must have a database to do that properly.

However, most people use a spreadsheet which I know is not a relational database, but if you observe certain rules, you can have a spreadsheet that does some of what a relational database will do and if you are careful to observe the discipline of setting up the spreadsheet correctly and not corrupting it, then you will get most of the functionality of the database.

now I can hear the purists howling at me as I say that, but in the real world, most people use a spreadsheet.

I’m sorry. That’s the dirty little secret in safety management. let’s move on.

Hazard Log Versus Risk Assessment

We’re going to talk now about hazard log versus risk assessment.

These are two very different things but they are related. On the left there we have risk assessment and risk assessment in most standards.

This diagram is based upon the ISO-31000 which is a very, very common unified risk standard. And in it, risk assessment is defined as risk identification, risk analysis, and risk evaluation.

That is risk assessment. 

Now the Hazard Log doesn’t do risk assessment but it supports risk assessment, it enables you to store the results. Okay?

You can record the results of the risk assessment, you can also, record the risk treatments. (That’s another word for controls, all the controls and risk reduction measures that you’ve taken.)

It can establish you can record context in there as well.

The Log Enables Good Risk Assessment

And then the hazard log enables good communication and consultation because certainly the commercial hazard log tools or if you make a database or make a hazard log with a database, you can use the database functionality to generate bespoke reports for different stakeholders.

the hazard log supports good communication and consultation, which is excellent. Got to do that.

And it also, supports monitoring and review because we’ve got the structure because we can review different aspects, we can review the risks, the hazards, the controls, the structure of the database and the and the hazard log in the way it presents things helps us to do that.

That is the relationship of a hazard log with risk assessment.

A hazard log is an entity, it’s a thing. Risk assessment is an activity or a series of activities, but they do go together very well.

One supports the other, right?

What’s the Difference between a Hazard Log and a Risk Register?

Now another very commonly asked question is what’s the difference between a hazard log and the risk register? And the answer is in many ways not very much.  They’re both doing basically the same thing. If we go back to, you know, I talked about Hazard log supports this risk process.

Well, this is a generic risk process; you can apply it to anything. If you had a risk register, it would support the risk process just the same.

That’s the purpose of the risk register. it’s very, very similar to a hazard log.

Hazard Log Differences

However, differences are typically for a hazard log, we are using a hazard log to track safety impacts.

Now, strictly speaking, safety, I prefer the definition where we’re talking only about harm to people, as in most jurisdictions of the world, when we talk about safety, the law says we have to protect people, that’s safety law.

And then there are usually other laws for protecting the environment and then as a business or an enterprise, we might want to protect valuable assets as well.

But the core of it is protecting people.

And a hazard log has a tracking system that is also, hazard-centric, you remember the bow tie, the hazard is there in the middle, it’s the core of everything that we do and it’s the hazards that tie multiple causes and multiple consequences together.

It really is the key to understanding that structure and all those many-to-many relationships.

Risk Register Differences

The thing about a risk register is that we can use it for the risks of impacts are just about anything.

I think the ISO-31000 standard defines risk as ‘the effect of uncertainty on objectives’. Whatever you’re doing, if you’ve got a project, you know, you want to deliver something specific at a specific time to a specific cost.

Well, you can look at the risks to those objectives if your objective is ‘business as usual’, you just want to keep things running your enterprise running steadily.

Your risk register can look at all the risks that might trip up your enterprise and stop it from working.

Also, you can use it for continuous improvement.

Although usually when we talk about continuous improvement, we usually start talking about models. Like the classic CMM, the Capability Maturity Model. There are various flavors of CMM around the world to do safety, security, finance, all kinds of things. We’ve fallen in love with maturity models. that’s really taking risk management and improvement to the next step.

But of course, to just take the first step on the ladder, we’ve got to start managing stuff and recording stuff consistently without those basic things. Continuous improvement cannot happen without it. We need a risk register and or hazard log to do all of that.

Those are some key differences between hazard logs and risk registers. In reality, they are really quite similar.

Risk Events AKA Hazards?

Some risk registers incorporate the idea of a risk event. Well, funnily enough, that sounds rather like a hazard to me. We’ve got all of these latent causes lying around. We’ve got a risk event or a trigger and then that can realize the risk. If you’ve got a risk register that supports that concept, it’s pretty, it’s almost identical to a hazard log.

That’s Hazard logs versus risk registers.

There’s More to Come…

That is the end of today’s session. Thanks very much for listening. I hope you enjoyed it. And there’s more to come.

Further Sessions on Hazard Logs and Hazard Tracking Systems

As I said before, in the second session we’re going to look at the features and benefits of commercial hazard log tools.

I showed you a screenshot, what would a fully-featured, purpose-designed database tool do for you and why would you want to do that?

And if you’re managing a particularly complex or demanding system, it will be worth going to the expense of either buying a tool or designing your own hazard log in a proper relational database. 

I’ve seen lots of Hazard logs implemented in DOORs, for example, which is a requirements management tool but of course, you know some of your requirements and not to hurt people. You can integrate a hazard log into doors or into another requirements management till provided you set it up properly.

Now and actually that brings us neatly onto the third session, which would be how do we make a proper hazard log in a spreadsheet?

How do we put a hazard log in a spreadsheet without breaking the fundamental rules?

Because we can set up tables, tabs in a spreadsheet, where each table is a list of entities be it causes, hazards, controls, references, whatever it might be.

Each one of those is an independent table and then they linked to each other properly using the primary key in each table. So, just like a database does it, we can do that in the spreadsheet more or less.

Excel for example isn’t going to give you all of the features of a proper properly set up relational database tool but it can probably for most people it will probably be enough. You’re also, going to rely on a lot of self-discipline controlling the hazard log and operating in a spreadsheet but we’ll talk about that in the third session.

I talk about lots and lots of safety and risk-related things and some security risk stuff as well at

Please do go and visit and do Please subscribe for email updates. You can get some free handouts and also, some discounts. Stay in touch with what I’m doing and the lessons and handouts that I’m producing.

Do please subscribe. and it just remains for me to say thank you very much. This lesson on was hazard logs and hazard tracking systems.

I’m Simon and thank you for watching ‘Hazard Logs and Hazard Tracking Systems’ on the Safety Artisan. Back to Start Here.

What would you like to Know about Hazard Logs and Hazard Tracking Systems?

Blog Safety Management

FAQ on Risk Management

In this FAQ on Risk Management, I will point you to some lessons where you will get some answers to basic questions.

Lessons on this Topic

Welcome to Risk Management 101, where we’re going to go through these basic concepts of risk management. We’re going to break it down into the constituent parts and then we’re going to build it up again and show you how it’s done.

So what is this risk analysis stuff all about? What is ‘risk’? How do you define or describe it? How do you measure it? In Risk Basics I explain the basic terms.

Risk Analysis Programs – Design a program for any system in any application. You’ll be able to:

  • Describe fundamental risk concepts;
  • Define what a risk analysis program is;
  • and much more…

If you don’t find what you want in this FAQ on Risk Management, there are plenty more lessons under Start Here and System Safety Analysis topics. Or just enter ‘risk’ into the search function at the bottom of any page.

The Common Risk Management Questions

Click here to see the most Commonly-asked Questions

why risk management, why risk management is important, why risk management is important in project management, why risk management plan is important, why risk management is important for business, why risk management matters, are risk management, are risk management services, is risk management important, is risk management framework, is risk management effective, can risk management be outsourced, can risk management increase risk, can risk management create value, how can risk management help companies, how can risk management be improved, how can risk management improve performance, how risk management improve organization performance, how risk management works, how risk management help you, how risk management helps, how risk management plans can be monitored, how risk management help us, how risk management add value to a firm, how risk management developed, what risk management do, what risk management means, what risk management is, what risk management is not, where risk management, which risk management certification is best, which risk management principle is best demonstrated, which risk management technique is considered the best, which risk management handling technique is an action, which risk management techniques, who risk management guidelines, who risk management, who risk management framework, who risk management tool, who risk management plan, who risk management strategies, will risk management be automated, how will risk management help you, how will this risk management plan be monitored, risk management will reduce, risk management will