Printer-friendly version
PDF version1.1. Hazard Log
1.1.1. Description of Hazard Log
1.1.1.1.
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.
1.1.1.2.
The Hazard Log is a structured means of storing and referencing Safety Risk Evaluations and other information relating to an equipment or system. It is the principal means of tracking the status of all identified Hazards, decisions made and actions undertaken to reduce risks, and should be used to facilitate oversight by the Project Safety Committee and other stakeholders.
1.1.1.3.
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 justification, as well as data on Hazards.
1.1.1.4.
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.
1.1.1.5.
Records can be tracked by the use of a status field, which for example, identifies whether the record has just been opened, or is awaiting confirmation of mitigation actions, or is ALARP.
1.1.1.6.
It is considered best practice for the Hazard Log to record each Hazard as “open” and for ALARP arguments to be provisional until all mitigation actions are confirmed to be satisfactorily completed. An example is where the mitigation depends upon 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.
1.1.1.7.
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.
1.1.1.8.
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 justification.
1.1.1.9.
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 an 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.
1.1.2. When it might be used
1.1.2.1.
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 programme 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.
1.1.3. Advantages, disadvantages and limitations to the defence sector or the particular domain
1.1.3.1.
Advantages
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.
1.1.3.2.
Disadvantages
- 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 rigour 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 before data entry starts.
1.1.3.3.
Comments
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 defence Systems as it would become large, manpower intensive and cumbersome as the System developed. This in turn introduces a significant maintenance overhead for a project.
1.1.3.4.
The DE&S mandated corporate Hazard Log Tool is the Cassandra database system and its online equivalent, eCassandra, a proprietary Database based upon Microsoft Access. DTs wishing to use an alternative Hazard Log Tool must be able to demonstrate that the proposed Alternative Acceptable Means of Compliance offers the same level of information/granularity so that visual representation and appropriate audit trail can be clarified and justified against the envisaged accident sequence in comparison to the mandated eCassandra tool.
1.1.3.5.
A bespoke Database enables the originator to custom define fields appropriate to the System. Conversely, a proprietary tool allows for a consistent and standardised approach across a range of programmes. 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.
1.1.4. Sources of additional information. Standards, textbooks & web-sites.
1.1.4.1.
Additional guidance on the Hazard Log can be found within the following references:
MoD’s Project-Oriented Safety Management System – procedure SMP11 - Hazard Log;
Def Stan 00-56 Interim Issue 3 – Part 2 (Guidance) Section 10.3.
1.1.5. Hazard Log Structure
1.1.5.1.
An example Hazard Log structure is presented in SMP11 - Hazard Log.
1.2. Version Control
1.2.1. Version 2.3 to 3.0 Uplift
1.2.1.1.
Major uplift from the Acquisition System Guidance (ASG) to online version.
1.2.2. Version 3.0 to 3.1 Uplift
1.2.2.1.
Update to clarify eCassandra as the mandated Hazard Log Tool.
