MOD 00-56 Safety MGMT 01000600

Defence Standard 00-56 Part 1
Issue 6 Date: 02 April 2015
_______________________________________
Safety Management Requirements
for Defence Systems
Part 1: Requirements and Guidance

_______________________________________
DEF STAN 00-56 Part 1 Issue 6
Contents
0 Introduction........................................................................................................................................... v
1 Scope and Applicability....................................................................................................................... 1
2 Warning ................................................................................................................................................. 2
3 References ............................................................................................................................................ 3
3.1 Normative References................................................................................................................. 3
3.2 Other References......................................................................................................................... 3
4 Definitions ............................................................................................................................................. 4
5 Abbreviations........................................................................................................................................ 4
6 Safety Management System................................................................................................................ 6
6.1 Safety Management Plan ........................................................................................................... 6
6.2 Agreement ................................................................................................................................... 7
6.3 Review and Update..................................................................................................................... 7
6.4 Progress Reports........................................................................................................................ 7
7. General Requirements ......................................................................................................................... 8
7.1 Deviation from Requirements ................................................................................................... 8
7.2 Legislation, Regulations, Standards and Policy ..................................................................... 8
7.3 Sub-Contracting.......................................................................................................................... 9
7.4 Multiple Deliverables .................................................................................................................. 9
7.5 Information Management ......................................................................................................... 10
7.6 Documentary Deliverables....................................................................................................... 11
7.7 Agreement of Deliverables ...................................................................................................... 11
8 Roles and Responsibilities................................................................................................................ 12
8.1 Safety Organisation.................................................................................................................. 12
8.2 Safety Committees ................................................................................................................... 12
8.3 Contractor Safety Audit Independence .................................................................................. 13
8.4 Competencies ........................................................................................................................... 13
9 Interfaces............................................................................................................................................. 14
9.1 Organisational Interfaces......................................................................................................... 14
9.2 Technical Interfaces ................................................................................................................. 14
9.3 External Interacting Interfaces ................................................................................................ 15
10 Safety Audits....................................................................................................................................... 15
10.1 Audits and Reports.................................................................................................................... 16
10.2 Independent Safety Audit ......................................................................................................... 16
10.3 Remedial Action......................................................................................................................... 16
11 Safety Requirements, Hazard and Risk Analysis............................................................................ 17
11.1 Safety Requirements ................................................................................................................. 17
11.2 Safety Requirements Management.......................................................................................... 18
11.3 Hazards and Accidents ............................................................................................................. 18
11.4 Hazard Tracking......................................................................................................................... 18
11.5 Design for Safety ....................................................................................................................... 19
11.6 Safety Analysis .......................................................................................................................... 20
11.7 Failure Modes............................................................................................................................. 20
ii
11.8 Risk Estimation.......................................................................................................................... 21
11.9 Risk and Compliance Evaluation ............................................................................................. 22
11.10 Satisfaction of Requirements............................................................................................... 22
12 Health Monitoring and Reporting System ....................................................................................... 22
13 Safety Reporting................................................................................................................................. 23
13.1 Information Set Safety Summary ............................................................................................. 23
13.2 Safety Case ................................................................................................................................ 23
13.3 Safety Case Reports.................................................................................................................. 24
14 Supply and Change Management..................................................................................................... 25
14.1 Build State Definition ................................................................................................................ 25
14.2 Change Control.......................................................................................................................... 25
14.3 Planning for Change.................................................................................................................. 26
14.4 Safety of Changes ..................................................................................................................... 26
14.5 Safe Update ................................................................................................................................ 26
14.6 Monitoring Change .................................................................................................................... 27
14.7 Incorporating Change ............................................................................................................... 27
15 Supporting Systems In-Service ........................................................................................................ 29
15.1 Management of Safety-Related In-Service Data ..................................................................... 29
15.2 Monitoring and Reporting......................................................................................................... 29
15.3 In-Service Data Analysis........................................................................................................... 30
15.4 Remedial Action......................................................................................................................... 30
16 Service Provision ............................................................................................................................... 31
16.1 Safety Case Report.................................................................................................................... 31
16.2 Service Provision Planning ...................................................................................................... 31
16.3 Risk Management ...................................................................................................................... 32
Annexes
Annex A Definitions ................................................................................................................................33
Annex B Contracting to Defence Standard 00-56 Part 1 - Guidance .................................................37
Annex C Data Item Descriptions............................................................................................................95
Annex D Integrity..................................................................................................................................127
iii
Foreword
REVISION NOTE
This Standard has been raised to Interim Issue 6 to update its content following feedback from the use of
Issue 5.
HISTORICAL RECORD
This Standard supersedes the following:
Defence Standard 00-56 Part 1 Issue 5 dated 29 January 2014

Defence Standard 00-56 Part 1 Issue 4 dated 01 June 2007
Defence Standard 00-56 Part 2 Issue 4 Amendment 1 dated 06 July 2012
Defence Standard 00-56 Part 3 Issue 1 dated 23 March 2012
a) This Defence Standard provides requirements and guidance for the achievement, assurance and
management of safety. It can be applied to any Ministry of Defence (MOD) project and in any phase
of a project’s life. Defence Contractors shall use this Standard as required by Contract. The effective
application of this Standard requires close cooperation between all parties, as the responsibility for
the achievement of safety is shared. This Standard also provides guidance for establishing a means
of complying with the requirements for the management of safety. This Standard contains clauses
that can be tailored by the MOD to meet safety requirements appropriate to the project.
b) This standard has been produced on behalf of the Ministry of Defence (MOD) by the Safety
Standards Review Committee. This Standard is sponsored by Director Technical, MOD QSEP SEP.
c) This standard has been reached following broad consensus amongst the authorities concerned with
its use and is intended to be used whenever relevant in all future designs, contracts, orders etc. and
whenever practicable by amendment to those already in existence. If any difficulty arises which
prevents application of the Defence Standard, DStan shall be informed so that a remedy may be
sought.
d) Please address any enquiries regarding the use of this standard in relation to an invitation to tender
or to a contract in which it is incorporated, to the responsible technical or supervising authority
named in the invitation to tender or contract.
e) Compliance with this Defence Standard shall not in itself relieve any person from any legal
obligations imposed upon them.
f) This standard has been devised solely for the use of the MOD and its contractors in the execution of
contracts for the MOD. To the extent permitted by law, the MOD hereby excludes all liability
whatsoever and howsoever arising (including, but without limitation, liability resulting from
negligence) for any loss or damage however caused when the standard is used for any other
purpose.
iv
0 Introduction
0.1 The new Acquisition Systems Operating Model1 includes requirements placed on Ministry of
Defence (MOD) acquisition organisations by Commands and Strategic Programmes for the delivery of
Equipment, Services, Logistics and Support (ESL&S) on behalf of defence. The purpose of this Standard is
to support acquisition organisations delivery of ESL&S by setting Safety Requirements on Contractors that
enable procurement of Products, Services and/or Systems (PSS) that are compliant with safety legislation
and regulations and with MOD safety and acquisition policy. The intent is that compliance with these
requirements will place MOD in a position to discharge its obligations with regard to the management of Risk
to Life associated with the in-service use of PSS.
0.1.1 PSS is used to describe all the articles or artefacts that are being delivered as defined in the
Contract. The Standard is intended to capture a broad spectrum of deliverables eg:
a) Service. Access to a commercially owned, commercially operated satellite communications system or

a maintenance contract for military vehicles.
b) Product. A vehicle, engine or its components.
c) System. Air traffic control facility with integrated radar and radio equipments.
0.2 Under UK law, all employers have a duty of care to their employees, the general public and the
wider environment. For the MOD this includes, but is not limited to, an obligation to manage the Risk to Life
associated with operation of military systems. In accordance with general guidance provided by the Health
and Safety Executive, and as defined in Joint Service Publication (JSP) 815, MOD will discharge this duty by
ensuring that all identified risks to life are reduced to levels that are As Low As Reasonably Practicable
(ALARP) and tolerable, unless legislation, regulations or MOD Policy imposes a more stringent standard.
0.3 Contractors who supply PSS to the MOD are subject to legal duties, which may vary with the place
of manufacture and supply or operation. MOD shall have regard to the needs of Contractors to discharge
their legal duties when interpreting and applying the requirements of this Standard.
0.4 The requirements are grouped into three main areas as follows:
a) Safety Management. Section 2. The requirements for organisational and general processes to ensure
that Risk to Life is managed effectively.
b) Safety Engineering. Section 3. The requirements for guiding the design of a PSS so that it can be
operated safely, on its own, as part of a wider system, or in a system of systems, and providing
evidence that this has been done.
c) Safety In-Service. Section 4. The requirements for managing safety where a Contractor is supporting
the MOD by providing a service, which may include operating a PSS.
Notes:
i. The safety management clauses should always apply, but the other clauses will depend on the
scope of contract. Safety engineering clauses will apply to projects involving design and development work,
but would also be expected to be applied (at least in part) to support contracts which involve design and
development, eg upgrades.
ii. If the Contract does not include provision of services (by the Contractor) then the clause of
paragraph 16 will not be applicable; similarly, if the Contract does not include support, then clauses in
paragraph 15 will not be applicable.
iii. The clauses can be tailored at a more detailed level, depending on the scope of contract,
standards or the approach to regulation in a particular sector. Guidance is given on tailoring, but this is likely
to be project dependent. Tailoring can be done only by the MOD, or as suggested by industry and with the
1 Available through the Acquisition Operating Framework (AOF) via the Defence Gateway.
v
agreement of the MOD; and must reflect the relevant domain specific Joint Service Publications (JSPs) and
regulatory arrangements.
iv. This standard is not intended to be applied to consultancy contracts for ISA services or manpower
substitution services.
v. An essential element of safety management systems is the recording of evidence in support of

safety cases or safety assessments that must be retained for audit and assurance or a legal or regulatory
requirement. Some data will be documented in the Safety Management Plan (SMP) and other data retained
as part of the information set. Throughout this Standard, unless otherwise specified, the data to be recorded
or documented must be retained with the information set.
0.5 This Standard is based upon a definition of safe, which addresses fatality, physical or psychological
injury or damage to the health of people, including MOD employees and the general public; in this Standard
we use the term Risk to Life in this sense. This Standard may be applied to address the damage to (or loss
of) PSS, environmental damage elements, or the management of environmental issues where Risk to Life
results.
Notes:
i. Safety management must include the safety issues relating to the environment (eg health and
safety risk from use or spillage of hazardous materials). There must also be consideration of any common
issues by cross-referencing the results of Hazard Identification and Environmental Features identified from
the Environmental Management System.
ii. On MOD procurement projects, a common approach is usually taken with safety and environmental
management systems and, in many cases evidence or plans are compiled into a single document, eg a
Safety and Environmental Management Plan. For clarity, this Standard refers only to safety management.
0.6 This Standard sets out requirements for achievement, assurance and management of safety,
including overarching objectives and principles. This Standard also provides guidance on establishing a
means of compliance with the requirements.
0.6.1 Sections 2 to 4 expand on the specific requirements on a clause-by-clause basis.
Note. In contracts for PSS in the Air Domain, henceforth referred to as Defence Air Environment (DAE)
as defined in the Military Airworthiness Authority (MAA) Glossary MAA02, the “should” term is the permissive
verb to allow the contractor to consider an alternative approach in meeting the clause. Any alternative
approach must be agreed with the MOD.
0.7 This Standard is applied to all PSS procured to meet diverse capabilities across all Defence
systems and may necessitate tailoring. The MOD may tailor the application of clauses and sub-clauses of
this Standard or, in consultation with the Contractor, agree tailoring to reflect the following:
a) The deliverable PSS and information, ie the scope of supply.
b) The scope of analysis: safety relevant activities to be undertaken, which may apply to more than or
less than, the scope of supply.
Notes:
i. The introduction of scope of supply is intended to identify what is delivered and not delivered to the
MOD. The introduction of the scope of analysis is intended to facilitate the clear definition of Contractor’s
responsibilities.
ii. This Standard must cover a broad range of contractual scenarios, including contracts providing
support to operations eg a PSS delivered and maintained by Contractors in an operational environment. For
all PSS to which this Standard applies, a crown servant will retain responsibility and accountability for the
Risk to Life, and would take account of this contracted PSS delivery, in the risk analysis. The use of
Contractors on Deployed Operations (CONDO) is a concept of utilising contractors during operations and
exercises to support and augment the capability of UK’s Armed Forces as part of the civilian component of
vi
the military force. The guiding principles to be followed in the development of CONDO policy are covered by
other standards and policy, such as Def Stan 05-129 and MOD JSP 567.
iii. To address a broad range of scenarios, this Standard sets out Safety Requirements which require
application in any given situation. The guidance helps to analyse the different circumstances which can arise
and to provide rationale for compliance with the Standard.
iv. Tailoring must be applied to capture the safety requirements for a specific project. It can be
particularly effective where there is an urgent operational need for Contractors to supply or modify PSS.
0.8 The scope of contract encompasses the scope of supply and scope of analysis.
Note. The scope of contract is the boundary of the safety activities of the Contract. It is negotiated during
the early phases of a project where the scope of supply and the scope of analysis are determined. The
scope of analysis would normally be applied to the PSS identified in the scope of supply. The scope of
analysis may be greater than that applied to the scope of supply, eg where interfacing and integration with
other PSS is required. In some cases the scope of analysis may be less than the scope of supply, eg where
equipment that has Safety Case is to be reused in a different operating environment.
0.9 This Standard identifies requirements for the achievement and demonstration of safety by a
Contractor who has Safety and Quality Management Systems in place.
Notes:
i. It is standard practice for the MOD to mandate an international quality standard requiring a
Contractor to have a Quality Management System. A Safety Management System (SMS) provides the
framework for the Contractor’s organisation to direct and control its safety management activities, including
the organisational structure, processes, procedures, techniques and methodologies.
ii. MOD mandated requirements for quality management in acquisition and the standard quality
assurance contractual requirements are available through the Acquisition Operating Framework (AOF)
accessible via the Defence Gateway. These requirements are not addressed in this Standard.
vii
This Page is Intentionally Blank
viii
Safety Management Requirements for Defence Systems

Part 1: Requirements and Guidance
Section 1 - General
1 Scope and Applicability
1.1 This Standard specifies the requirements for achieving, assuring and managing the safety of PSS
defined by the scope of contract.
1.1.1 This Standard provides the Contractor with guidance for compliance with the requirements, thereby
supporting the MOD in meeting their obligations with regard to the management of Risk to Life associated
with the operation of military systems.
1.1.2 This Standard considers that a product can be an engineering artefact, whether physical, data or
software, from the small scale, such as a pump or a digital map, to the large scale, such as a ship or a
geographically distributed logistics application.
1.1.3 This Standard considers that a system is a combination of elements, with defined boundaries,
which are used together in a defined operating environment to perform a given task or achieve a specific
purpose. These elements may include personnel, procedures, materials, tools, products, facilities,
services and/or data as appropriate.
1.1.4 This Standard considers a Service to be any activity using a System, eg providing air-to-air
refuelling, running a naval dockyard, or calculating the safe flight envelope for an aircraft, which are provided
by the Contractor.
1.2 The Contractor, together with the MOD, has responsibility for safety of all deliverable PSS. This
Standard is intended to cover the full range of possibilities including:
a) Where the Contractor has visibility and understanding of in-service Risk to Life, and can design PSS
taking operation into account.
b) Where the Contractor does not have visibility of in-service Risk to Life but is responsible for providing
information to those who are responsible for in-service Risk to Life of the PSS.
1.2.1 The MOD considers all Defence Lines of Development for PSS, but this may not be included in the
scope of contract, eg Concepts and Doctrine would consider Risk to Life and would be a MOD responsibility.
1.3 The responsibility of the Contractor also varies with the scope of analysis. This Standard is
intended to cover the full range of possibilities including:
a) Enhanced, where the Contractor carries out safety engineering and safety management, for the duty
holder, beyond the deliverable PSS.
b) Full, where the Contractor carries out safety engineering and safety management for the deliverable
PSS.
c) Reduced, where the Contractor carries out safety engineering and safety management only for parts
or aspects of the deliverable PSS, eg for maintenance of a product.
1.3.1 The scope of analysis is intended to be adapted to the wide range of possible MOD acquisition
scenarios.
1.3.2 Guidance on MOD safety management is available through the AOF.
Note. In the DAE, the aviation Duty Holder or Accountable Manager (Military Flying) as defined in MAA02
and RA1024, are the designated posts who can accept risks as being tolerable and ALARP.
1
1.4 Whilst Contract life may be limited, this Standard considers the whole life cycle of the PSS,
including disposal. Various phases of the life of the PSS that need to be considered should be explicitly
included within the scope of analysis. This applies to all in-service situations and scenarios including, but not
limited to, trials, operations and training for operations as defined in the Contract.
1.4.1 This Standard applies to all acquisition scenarios and all PSS but the responsibility of the
Contractor varies with the scope of supply.
1.4.2 The distinction between scope of supply and scope of analysis is intended to facilitate the clear
definition of the Contractor’s responsibilities.
1.4.3 The scope of analysis may be extended beyond the scope of supply particularly where the
contracted activity is limited to early phases of the CADMID/T cycle. The scope of analysis may need to
cover the full CADMID/T cycle.
1.5 This Standard applies to PSS that have identified duty holders, supported by Safety Committees
and relevant stakeholders.
1.5.1 For all PSS to which this Standard is applied, a crown servant will retain responsibility and
accountability for the Risk to Life. The scope of contract is agreed between the MOD and the Contractor and
would identify duty holders and relevant stakeholders who are responsible for managing safety of the PSS.
The relevant stakeholders may include representatives from MOD and Industry (for other related PSS) that
may impact the PSS safety interfaces.
1.5.2 The mechanism for managing safety is through the agreed Safety Committees. Terms of
Reference and membership will be specific to the scope of contract.
Notes:
i. This Standard is specifically about safety and there is expectation that requirements will be set by
the MOD and be included in the project documentation eg capability, performance and reliability criteria and
User and System Requirements Documents (URD/SRD).
ii. This clause is an indicative commitment from the MOD to the Contractor and a limitation on the
scope of this Standard. The Contractor must assume that the MOD has a Safety Management System
(SMS) for their PSS responsibilities, eg a Safety Committee exists prior to Invitation to Tender (ITT).
Agreeing a scope of contract is intended to clarify responsibilities between the MOD and the Contractor. As
the PSS evolves through life the scope of contract may need to be revisited and may need to be re-
negotiated.
iii. The interface and degree of support/co-operation between the MOD SMS and the Contractor’s
equivalent would form part of the MOD/Contractor agreed scope of contract. This Standard defines the
requirements placed on the Contractor. For information on MOD processes and responsibilities, Contractors
can refer to the MOD publications and procedures, eg Military Airworthiness regulations or the MOD Project-
Oriented Safety Management System (POSMS) manual, which are available through the Defence Gateway
or GOV.UK websites.
iv. One of the main mechanisms of the MOD SMS is managing safety through the relevant Safety
Committees. The Contractor’s Terms of Reference and membership of Safety Committees will be specific to
the agreed scope of contract, and based on POSMS guidance.
vi. Where there is any doubt over the validity of assumptions, or the scope of analysis, the contractor
must discuss resolution with the MOD.
2 Warning
The Ministry of Defence (MOD), like its contractors, is subject to both United Kingdom and European laws
regarding Health and Safety at Work. Many Defence Standards set out processes and procedures that could
be injurious to health if adequate precautions are not taken. Adherence to those processes and procedures
in no way absolves users from complying with legal requirements relating to Health and Safety at Work.
2
3 References
3.1 Normative References
3.1.1 The publications shown below are referred to in the text of this Standard. Publications are grouped
and listed in alpha numeric order.
Def Stan 00-250 Human Factors for Designers of Systems

Def Stan 05-57 Configuration Management of Defence Materiel
Def Stan 05-129 Contractors on Deployed Operations Processes and Requirements
ISO 9001 Quality Management Systems - Requirements
JSP 815 Defence Environment and Safety Management
JSP 567 Contractor Support to Operations: Policy Overview
JSP 440 The Defence Manual of Security
MRP MAA Regulatory Publications
Notes:
i. Def Stan’s can be downloaded free of charge from the DStan web site by visiting
<http://dstan.uwh.diif.r.mil.uk> for those with RLI access or <https://www.gov.uk/uk-defence-
standardization> for all other users. All referenced standards were correct at the time of publication of this
standard (see 3.1.2, 3.1.3 & 3.1.4 below for further guidance), if you are having difficulty obtaining any
referenced standard please contact the DStan Helpdesk in the first instance.
ii. In the DAE, the MAA Regulatory Publications (MRPs)

<https://www.gov.uk/government/collections/maa-regulatory-publications> define Air Safety Management
Systems requirements through Regulatory Articles. MRPs referenced in the main text are in the context of
the DAE only. MRPs referenced in the DAE Tailoring and Compliance Matrix (Annex B, Appendix 2) are to
be considered in addition to the normative references.
3.1.2 Reference in this Standard to any normative references means in any Invitation to Tender or
contract the edition and all amendments current at the date of such tender or contract unless a specific
edition is indicated. Care should be taken when referring out to specific portions of other standards to ensure
that they remain easily identifiable where subsequent amendments and supersession’s might be made. For
some standards the most recent editions shall always apply due to safety and regulatory requirements.
3.1.3 In consideration of clause 3.1.2 above, users shall be fully aware of the issue, amendment status
and application of all normative references, particularly when forming part of an Invitation to Tender or
contract. Correct application of standards is as defined in the ITT or contract.
3.1.4 DStan can advise regarding where to obtain normative referenced documents. Requests for such
information can be made to the DStan Helpdesk. Details of how to contact the helpdesk are shown on the
outside rear cover of Defence Standards.
3.2 Other References
3.2.1 Other references in this Standard are to recognised good practice, sources of additional guidance
and context to provided notes.
AERC Airborne Equipment Release Certificate

ALWRC Air Launched Weapon Release Certificate
ARP4754 Guidelines for Development of Civil Aircraft and Systems.
ASEMS DE&S Acquisition Safety and Environmental Management System
DEF STAN 00-55 Requirements for Safety of Programmable Elements (PE) in Defence Systems
DO-178 Software Considerations in Airborne Systems and Equipment Certification
3
IET Blue Book Competence Criteria for Safety-Related System Practitioners

IET COPISA Code of practice for independent safety assessors
ISO 26262 Road Vehicles - Functional Safety
MAA02 MAA Master Glossary
MIL-STD-882 Department of Defense Standard Practice - System Safety
POSMS DE&S Project Oriented Safety Management System
White Book An Introduction to Safety Management in the MOD
4 Definitions
4.1 Terms and Definitions
For the purposes of this Standard, the terms and definitions detailed in Annex A shall apply.
4.2 Mandatory Requirements
A requirement which uses the word ‘shall’ identifies the clause or sub-clause as mandatory. Sub-clauses
using the word ‘should’ allows the contractor the opportunity to consider an alternative approach in meeting
the sub-clause.
5 Abbreviations
ALARP As Low As Reasonably Practicable
AOF Acquisition Operating Framework
ARP Aerospace Recommended Practice,
ASIC Application-Specific Integrated Circuit
CADMID/T Concept, Assessment, Demonstration, Manufacture, In-Service, Disposal/Termination.
CONDO Contractors on Deployed Operations
CSA Contractor Safety Auditor
DEA Defence Air Environment
Def Stan Defence Standard
DID Data Item Description
DO Document Order
DStan UK Defence Standardization
ESL&S Equipment, Services, Logistics and Support
FMEA Failure Modes and Effects Analysis
FMECA Failure Modes Effects and Criticality Analysis
FPGA Field-Programmable Gate Array
FRACAS Failure Reporting Analysis and Corrective Actions Systems
GFX Government Furnished Equipment (GFE) or Assets (GFA)
IET Institution of Engineering and Technology
ISA Independent Safety Auditor
ISAWG Independent Safety Assurance Working Group
ISO International Organization for Standardization
ISSS Information Set Safety Summary
ITT Invitation to Tender
JSP Joint Service Publication
MAA Military Aviation Authority
MIL-STD Military Standard
MOD Ministry of Defence
MRP MAA Regulatory Publications
PE Programmable Elements
4
PLD Programmable Logic Device

POSMS DE&S Project Oriented Safety Management System
PSS Products, Services and Systems
SRD System Requirement Document
SMP Safety Management Plan
SMS Safety Management System
RA Regulatory Article
URD User Requirement Document
5
Section 2 - Safety Management Requirements

6 Safety Management System
The Contractor shall operate an SMS that defines the framework for the Contractor’s organisation to direct,
control and monitor its safety management activities.
Notes:
i. Safety Culture and SMSs are very important to the achievement and assurance of safety. This
Standard mandates an SMS, but does not place requirements on safety culture as that cannot be enforced
through contract. MOD guidance on safety management and safety engineering such as the Project
Oriented Safety Management System (POSMS) Manual and the White Book are available via the AOF.
ii. Regulatory Article RA1200 and the Manual of Air Safety provide detail on how an SMS is to be
implemented In the DAE.
6.1 Safety Management Plan
The Contractor shall define and implement a coherent approach to management of all safety-relevant
activities, throughout the life of the Contract and document their approach in an SMP.
6.1.1 The Contractor shall identify civil, open or other standards, or good practice, where they are used
in full or partial fulfilment of the requirements of this Standard, and document the means by which any
differences to this Standard will be resolved.
6.1.2 The Contractor should show that use of civil, open or other standards or good practice is
appropriate for their Contract.
6.1.3 The Contractor should analyse the civil, open or other standards or good practice which they intend
to apply to the contract; identify the divergences with this Standard; applicable regulations and legislation;
and document the results of the analysis and their proposed means of resolving the divergences between
them in the SMP.
6.1.4 The Contractor should ensure that the SMP covers all safety-relevant activities to a level of detail
that is reasonably practicable, so as to determine what activities are to be performed, by whom, at what time,
and with what methods and tools, throughout the Contract.
6.1.5 The Contractor should ensure that the SMP covers the work of all Sub-Contractors, including the
mechanisms that the Contractor will use for oversight of Sub-Contractor work, such as auditing.
6.1.6 Where the Contract includes provision of a service the Contractor should agree with the MOD the
balance between the activities managed through the service SMP and through other relevant plans, drawing
on the service SMP as the key plan for the safety aspects of the delivery, prior to commencement of the
service.
6.1.7 Where the Contractor has an SMS in place, the SMP should draw on that system.
6.1.8 Where the Contractor does not have an SMS in place, the SMP should address the core principles
of systems engineering and safety management.
Notes:
i. It is mandatory for Contractors to operate an SMS. In exceptional circumstances, MOD may work
with some specialist Contractors who do not have an SMS. These requirements, identified in the scope of
contract, will be reflected in the scope of supply or scope of analysis for the specific project or as directed by
the MOD Regulators. Information on the MOD’s Acquisition Safety and Environmental Management Systems
6
is available from the AOF. The White Book and the AOF contains guidance on acquisition safety
management in a systems engineering context.
ii. The SMP defines the safety-relevant activities to be undertaken, and these are agreed with the
MOD before they are performed. Where services are provided on the Contract, there may be additional
plans which govern these activities. The reporting is intended to give visibility to the Safety Committee and to
other stakeholders of the progress of the safety relevant activities, and to identify issues which need
management attention, as and when they arise.
iii. The MOD encourages the use of open, civil standards where possible, eg ARP4754/DO-178 in an
air application, or ISO 26262 in an automotive application. Further guidance is provided in the Contracting
and Tailoring Annex B to this Standard.
iv. A Data Item Description (DID) for the SMP is provided in Annex C to this Standard.
v. The MOD mandates that acquisition projects must have an SMS. The intent is that the Contractor
also operates an SMS. This requirement may be tailored by the MOD, depending on the project
requirements.
6.2 Agreement
The Contractor shall agree the SMP with the MOD.
6.2.1 The Contractor should define an SMP as part of the tendering process, and formalise and agree
the plan with the MOD at Contract award.
Notes:
i. The Contracting and Tailoring Annex B to this Standard, gives some guidance on tendering and
other pre-contract activities.
ii. The detail in a draft SMP might not be complete at the ITT stage, for example because the tenderer
may not have been able to identify all Sub-Contractors, or because they have not been able to assess
Government Furnished Equipment or Assets (GFX). As a consequence there may be substantive work to be
undertaken in formalising the SMP during Contract negotiations and from Contract award. The SMP must be
agreed with the MOD before any extensive safety work is undertaken.
6.3 Review and Update
The Contractor shall review and update the SMP to reflect changes throughout the life of the Contract.
6.3.1 The Contractor should review the SMP on a regular basis, depending on the scale and stage of the
Contract or on significant events, eg change in supplier, introduction of a new technology or changes to risk
mitigation strategy, and agree the SMP changes with the MOD before implementation.
6.3.2 When the Contract includes support, the Contractor should ensure that all changes in design and
their implementation are managed through the SMP, or in subsidiary plans, together with mechanisms for
safe and effective distribution and installation of those changes.
6.4 Progress Reports
The Contractor shall report progress against the SMP to all stakeholders as identified in the SMP, and shall
report on any necessary actions to correct deviations from the SMP.
6.4.1 The Contractor should ensure that Progress Reports highlight significant safety issues and
proposed remedial actions, as well as documenting progress against planned tasks.
Note. There is a DID for the Progress Report in Annex C to this Standard.
7
7 General Requirements
Note. The general requirements deal with the broad legislative and contractual context for the core safety
management and safety engineering activities covered in this Standard. In several cases, eg deviation from
requirements, the requirements act as constraints on other parts of the Standard, or on the application of the
Standard.
7.1 Deviation from Requirements
Any deviations from the requirements of this Standard shall be formally agreed between the MOD and the
Contractor prior to their implementation, and documented in the SMP.
7.1.1 Where there are conflicts between the requirements of this Standard and other requirements, a
means of resolving the conflicts shall be agreed between the MOD and the Contractor.
7.1.2 In the response to an ITT, the tenderer should specify how they intend to meet the requirements of
this Standard.
7.1.3 The tenderer should provide a compliance matrix for this Standard with their response to the ITT,
showing:
a) Which clauses will be or have been fully complied with.

b) Which clauses will not be or have not been fully complied with, and why, including a description of any
alternative approaches and why they are acceptable.
7.1.4 For any intended deviations, the tenderer should indicate how their approach will meet the intent of
this Standard or explain why compliance is not considered to be necessary.
Notes:
i. The domain tailoring and compliance matrices may provide specific requirements for a means of
resolving the conflicts. However, there must be an agreed solution in the scope of contract.
ii. At Contract award, the compliance matrix will form part of the scope of contract and hence future
variance will need to be agreed by the MOD and Contractor and may result in contract amendment.
iii. The ITT may identify tailoring of the Standard as required by the MOD. Agreement to further
removal or replacement of specific requirements of this Standard depends on the Contractor showing that
there is no adverse impact on the safety, or on the evidence of the safety of the PSS and agreed by the
MOD eg during Contract negotiation.
iv. Annex B to this Standard includes tailoring principles and contracting guidance and provides a
clause-by-clause tailoring and compliance matrix template.
7.2 Legislation, Regulations, Standards and Policy
The Contractor shall identify and document all relevant safety legislation, regulations and standards
applicable to the PSS delivery.
7.2.1 The Contractor shall work with the MOD to identify and agree relevant MOD policy appropriate to
the scope of supply and scope of analysis, addressing the domain and the technology used.
7.2.2 The Contractor should agree with the MOD, all legislation, regulations and standards applicable to
the scope of supply and scope of analysis, addressing the domain and the technology used.
8
Notes:
i. Legislation and standards will be documented in a legislation register which is fundamental to any
SMS, eg the MOD POSMS SMP01 identifies a legislative register as an integral part of the Safety Case.
Legislation, regulations and standards risks to delivery of PSS will be managed through safety engineering.
ii. The Contractor has responsibility for identifying relevant UK/EU and International legislation, and
this will be dependent on the Contractor’s chosen solution, eg where the legislation is technology related, the
MOD will expect the Contractor to be fully aware of their obligations to deliver compliant PSS.
iii. The MOD complies with all applicable Health Safety and Environmental Protection legislation within
the United Kingdom (UK) and overseas applies MOD’s UK arrangements where reasonably practicable and,
in addition, responds to host nations’ relevant Health Safety and Environmental Protection expectations.
MOD guidance on application of legislation is delivered through JSPs and regulations which the Contractor
may not be aware of. However there is a requirement on the Contractor to obtain agreement on compliance,
exemption or disapplication, dependent on the applicable legislation for their chosen solution, eg where
materials may be subject to European Union Directives restricting manufacture or import.
iv. It is recognised that the contractor is unlikely to be able to apply MOD policy directly. However, it is
likely that the Contractor will be able to work with the MOD in addressing such policy through derived
requirements.
7.3 Sub-Contracting
Where work is Sub-Contracted, the Contractor shall ensure and provide assurance that the relevant
requirements of this Standard are met throughout the supply chain.
7.3.1 The Contractor should identify their requirements to Sub-Contractors, appropriate to the
Contractor’s scope of supply and scope of analysis.
7.3.2 The Contractor should place requirements on Sub-Contractors to ensure that the Contractor’s
compliance to the relevant requirements of the Standard are met.
7.3.3 The Contractor should identify deliverables and audit mechanisms to provide assurance that the
requirements of the Standard are met throughout the supply chain, and record the evidence to demonstrate
compliance in the information set.
Notes:
i. Many of the requirements of this Standard relate to the relationship between the MOD and the
Contractor. It is the Contractor’s responsibility to meet the requirements of this Standard.
ii. This Standard has requirements for managing interfaces that must be addressed at the boundary
with Sub-Contractors. This may lead to involving Sub-Contractors in the top-level Safety Committee, or
setting up special working groups, rather than key stakeholders becoming involved in the Sub-Contractor’s
Safety Committee.
7.4 Multiple Deliverables
Where there are multiple deliverable PSS, the Contractor shall apply the clauses of this Standard relevant to
each PSS element, grouping common PSS elements where appropriate, and document the approach
adopted in the SMP.
7.4.1 The Contractor and the MOD should discuss and agree where it is necessary to apply specific
requirements of the Standard across each deliverable PSS.
7.4.2 Safety Case Reports and Information Set Safety Summaries (ISSSs) should be produced for each
related PSS so that they are “self-contained” from a safety perspective.
9
Notes:
i. These clauses are intended to address the situations where the Contractor is asked to produce a
variety of different PSS types, eg a fleet of different vehicle types, or supports product trials or
demonstrations which are services, in the terms of this Standard. The aim is to make the analysis and safety
assessments specific enough to control risk effectively for each of the elements of the PSS without repeating
work which is essentially identical for each of the elements.
ii. In the case of services interfacing to other PSS, as part of the Contract, there may be a need for
separate Safety Cases Reports for each interfacing PSS. For example, a demonstration may necessitate
some additional hazard analysis and safety analysis.
iii. In the DAE, only the Air System Safety Case is recognised as a Safety Case. It is supported by a
number of Safety Assessments (defined in MAA02). Where the Contractor is required to supply Safety
Cases, Safety Cases Reports, in the DAE they are referred to as Safety Assessments and Safety
Assessment Reports unless specifically referring to the Air System Safety Case.
iv. The concept, use and applicability of the Safety Case Report and ISSS are discussed in Annex B
and their relevant DIDs in Annex C.
7.5 Information Management
The Contractor shall provide the MOD with visibility of the safety engineering, support and safety
management activities throughout the life of the Contract.
7.5.1 The Contractor shall define and agree with MOD an information set which is sufficient to enable all
safety relevant design and safety analysis activities to be reviewed and repeated.
7.5.2 The Contractor shall ensure that the information set is kept up to date as the design and analysis
evolves, and that it is managed in a suitable configuration management framework. (eg Def Stan 05-57).
7.5.3 The Contractor shall maintain consistency between the information set and the configuration of
deliverable PSS.
7.5.4 The Contractor shall preserve the information set for the period or periods specified in the Contract.
7.5.5 The Contractor shall ensure that the information set remains accessible as techniques,
methodologies and tools change, through the life of the Contract.
7.5.6 The Contractor shall pass information to the MOD, Regulators and any other organisations
identified in the Contract, where that information is necessary for other parties to be able to fulfil their safety
responsibilities with regard to the deliverable PSS, or interfacing or interacting PSS.
7.5.7 The Contractor should seek to be inclusive in defining the information set, to ensure that data and
information that might have a safety role are included.
7.5.8 The Contractor should define, and agree with the MOD, processes for information management,
including periodic review of media, compatibility with current tools (both specialist and general purpose) and
devise means of migrating data as appropriate to ensure that it remains both accessible and usable.
7.5.9 Where the Contractor anticipates difficulties, or very high costs, in preserving access to parts of the
information set they should discuss approaches and options with the MOD.
7.5.10 The Contractor should consider obsolescence of the technologies used for preserving the
information set.
Notes:
i. Information set, refers to data that Contractors would necessarily produce when developing and
analysing PSS. The term information set is a label for what would be normally produced, not a new
imposition. Not all data generated will be a deliverable, but must be retained where it provides evidence to
10
support the specific safety case. It is unlikely that there will be a single document forming the information set.
Instead the information set will typically include documents, databases, spread sheets, etc. The scope of
supply defines what is deliverable from the information set.
ii. Contractors will need to ensure that the information set is manageable, and that there is no
unjustifiable burden in maintaining this information for extended periods. Technology changes due to
obsolescence may make continued information accessibility infeasible, or prohibitively expensive, and the
Contractor will need to be consult with the MOD about the cost-benefit trades.
iii. It must be assumed that an Independent Safety Auditor (ISA), if appointed, would need access
data from the information set used as evidence to substantiate the Safety Case.
7.6 Documentary Deliverables
The Contractor shall produce documentary deliverables relevant to safety, including interim versions, as
Contracted. Documentary deliverables identified in this Standard are:
a) Command Summary.
b) Information Set Safety Summary.
c) Safety Audit Plan.
d) Safety Audit Report.
e) Safety Case Report.
f) Hazard Log Report.
g) Safety Management Plan.
h) Progress Reports.
7.6.1 The Contractor shall agree with the MOD the format and content for all Contracted safety-related
deliverables in the scope of supply and document this information in the SMP.
7.6.2 The Contractor should define deliverable formatting and content taking into account the DIDs and
the requirements of any civil, open or other standards being used, as identified in the SMP.
7.6.3 The Contractor should develop and update the deliverable plans, reports and summaries at
appropriate stages of the Contract as defined in the SMP.
Notes:
i. DIDs for deliverables are identified in Annex C to this Standard and are intended to identify scope
and content of the deliverables, not the contents list. They also give guidance on the “life-cycle” of the
deliverables.
ii. The Release To Service Regulatory Articles (RA) RA1300, RA1345 and RA1350, must not be
subverted by a Command Summary. In the provision of services a Command Summary may be appropriate,
however great care should be taken in all other circumstances on invoking this clause.
7.7 Agreement of Deliverables
The Contractor shall agree with the MOD, the PSS and safety-related documentation to be delivered and
record this information in the SMP.
7.7.1 The Contractor should define the boundaries and operating environment including any known
interfacing or interacting PSS, whether extant or planned.
7.7.2 The Contractor should define the PSS to include all relevant elements across the Defence Lines of
Development, as Contracted.
7.7.3 The Contractor should record the definition of the PSS, and the results of activities within the scope
of analysis, in the information set and update it throughout the Contract to ensure that it accurately reflects
the status of the design, safety analysis and engineering activities.
11
Note. Although this Standard includes DIDs, it is anticipated that the definition of deliverable contents and
format will be a key part of the SMP; it is likely to depend to a significant degree on the JSPs or regulations
applicable to the Contract.
8 Roles and Responsibilities
8.1 Safety Organisation
The Contractor shall define the roles and responsibilities of those individuals responsible for safety within the
scope of contract and document them in the SMP.
8.1.1 The Contractor shall identify the normal point of contact for safety matters within the safety
organisation.
8.1.2 The Contractor shall demonstrate how responsibility is delegated to ensure safety is treated with
appropriate authority within the organisation and on the Contract.
8.1.3 The Contractor should keep the definition of roles and responsibilities of those individuals
responsible for safety up to date.
8.1.4 The Contractor should identify and record, in the information set, competency requirements for
each role.
Notes:
i. In practice, responsibilities will be shared between MOD and Industry and the Safety Committee is
the primary mechanisms to ensure coordination and interfaces with other organisations and stakeholders.
ii. A clear definition of roles and responsibilities within the MOD and Contractors organisation is
essential to ensure that safety issues are owned at an appropriate management level. Sufficient authority
must be delegated within the Contractors organisation to ensure that safety management is given the
appropriate priority and resources that are commensurate with the risk.
iii. POSMS SMP 01, Safety Initiation, suggests methodology to ensure that the safety management
process is commenced on a firm basis by identifying basic information, interfaces and responsibilities. This
may include use of a Responsible, Accountable, Consulted and Informed chart, or equivalent, which would
be recorded in the SMP and updated through the PSS lifecycle.
8.2 Safety Committees
The Contractor shall contribute to Safety Committees and other liaison activities to ensure effective
coordination of safety with the MOD and other stakeholders.
8.2.1 The Contractor shall provide visibility of the information set to the Safety Committee to enable it to
oversee safety management, safety engineering and safety-related support activities.
8.2.2 The Contractor shall support the Safety Committee in recommending, endorsing or providing
guidance on issues with a potential safety impact and in assuring the results of work, within the scope of
analysis, either directly or through subsidiary committees.
8.2.3 The Contractor shall support the Safety Committee in any additional roles/tasks as agreed with the
MOD and recorded in the SMP.
8.2.4 Where there is an MOD Safety Committee, the Contractor should participate in its work.
8.2.5 Where there is no appropriate committee, the Contractor should work with the MOD to establish a
Safety Committee that includes relevant stakeholders and define the constitution and Terms of Reference in
the SMP.
12
8.2.6 Where appropriate the Safety Committee should delegate work to subsidiary committees or
working groups, and document the policy on delegation of responsibility and escalation of issues in the SMP.
These sub-committees may be largely staffed by Contractor personnel.
8.2.7 Where there is concurrent work on interfacing or interacting PSS, the Safety Committee should
collaborate with other Safety Committees to manage interfaces, and should refine the scope of analysis if
necessary to minimise gaps in analysis, or overlaps and duplication of effort.
8.2.8 Where the Contract involves support, the Safety Committee should approve proposed changes to
all PSS before they are implemented and ensure the proposed changes comply with domain regulatory
requirements.
8.2.9 The Contractor should record all their support to the Safety Committee and safety-related
meetings.
Notes:
i. Management of safety is a collaborative activity between the MOD and its Contractors. In the case
of Defence projects, the Contractor will normally have extensive knowledge about engineering and means of
controlling risk, which is complemented by the MOD’s in-service knowledge of operations, other interacting
PSS, and the acceptability of risk. The Contractor’s and the MOD’s knowledge need to be brought together
to enable effective management of safety, and the Safety Committee is the primary mechanism for doing
this. To be effective, the Safety Committee must have an open and co-operative approach to all aspects of
managing safety; this is indicative of a positive safety culture.
ii. Normally the MOD will have already established a Safety Committee and the obligations on the
Contractor will be discharged through engagement in the Safety Committee. In the unlikely situation that
there is no established MOD Safety Committee, the Contractor must liaise with the MOD to establish such a
committee.
iii. The MOD expects the Contractor will keep records of their contribution and support safety-related
meetings, in line with statutory requirements and for audit purposes. The Contractor’s responsibilities may
also include producing formal records of Safety Committee meetings.
iv. The mandatory (shall) requirements are on the Contractor. Where the “should” clauses refer to the
Safety Committee, the Contractor is expected to support the work of the Safety Committee as agreed
through the tailoring and compliance matrix and defined in the Contract.
8.3 Contractor Safety Audit Independence
The Contractor shall ensure that Contractor Safety Auditors (CSAs) are independent from those areas within
the Contractor’s organisation, or any Sub-Contractors, that are subject to Contractor safety audit.
Note. Good practice for CSAs may be taken from the IET code of practice for independent safety
assessors, eg be sufficiently independent that any commercial, financial or other interests do not
compromise their ability to carry out the assessment or their judgements.
8.4 Competencies
The Contractor shall ensure that all safety-relevant tasks within their scope of contract are carried out and
managed by individuals, teams or organisations that are competent to perform those tasks.
8.4.1 The Contractor should record the evidence of competence, on an individual, team and
organisational basis, in the information set.
8.4.2 The Contractor should undertake competence management, for all project staff, drawing on
publicly available competence frameworks, where possible.
8.4.3 Contractors should ensure that competent personnel are appointed to all posts that affect safety
and confirm details in the relevant section of the SMP and in the Safety Case.
13
Notes:
i. The notion of competency also extends to organisations. In some cases there is an explicit scheme
of organisational assessment, eg in the DAE there are multiple approval schemes including Maintenance
Approved Organization Scheme and the Design Approved Organization Scheme (Reference RA1005,
Competent Organizations and Responsibilities). The presence, or otherwise, of such assessments of
organisational competence does not alter the requirements of this Standard, but the evidence produced to
achieve approval may be used to provide material which is an acceptable means of compliance.
ii. There are schemes for assessing safety competency relevant to particular standards. Examples of
safety practitioner competence schemes are: Managing Competence for Safety-Related Practitioners
(developed by the Health and Safety Executive (HSE), the Institution of Electrical Engineers and the British
Computer Society) and the Competence Criteria for Safety-Related System Practitioners (IET’s Blue Book).
The MOD also provides guidance on MOD safety-related competence through the AOF – the AOF contains
the Acquisition Safety and Environmental Management System Leaflets eg Duty Holder and Role Profiles.
Contractors will have their own schemes based on these or similar publications. Whichever scheme is used it
is expected that the Contractor will provide sufficient evidence of competence of personnel undertaking tasks
to meet contracted Safety requirements.
9 Interfaces
Note. The Standard applies on a Contract and it is likely that multiple Contracts will need to be placed to
deliver a capability for the MOD; this clause deals with the interfaces with other Contractors and with
government organisations where they are involved in the provision of parts of the capability.
9.1 Organisational Interfaces
The Contractor shall cooperate, and coordinate safety activities, with all relevant organisations identified in
the SMP.
9.1.1 The Contractor should define processes for managing organisational interfaces, eg to suppliers or
to operators of peer PSS, and document them in the SMP. These processes should cover the full scope of
contract.
9.1.2 The Contractor should ensure timely and accurate communication with all relevant organisations
identified in the SMP and participate in relevant Safety Committees to ensure coordination of safety
management and engineering activities.
Note. There may be an urgent need for timely communication between stakeholders, eg to manage an
emergent risk that impacts in-service safety.
9.2 Technical Interfaces
The Contractor shall record, as part of the information set, all assumptions and information necessary to
enable safe integration or interoperation with other PSS, including in a system of systems.
9.2.1 The Contractor shall identify and record, as part of the information set, their assumptions about any
known interfacing or interacting PSS, whether extant or planned, to enable them to carry out safety-related
activities within the scope of contract.
9.2.2 The Contractor shall record, as part of the information set, assumptions which other organisations
are entitled to make about their deliverable PSS.
9.2.3 The Contractor should define and manage the technical interfaces to each element which can be
operated in a system of systems.
Notes:
i. The aim is to ensure that the configuration of the elements is not constrained by the way in which
they have been defined and analysed, eg by considering only a single possible configuration, thereby
maximising the extent to which they can be deployed with confidence that the safety issues have been
14
properly understood.
ii. The intent is that the documentation of assumptions enables the Contractor responsible for one
PSS to say what properties they can achieve (and assure) given the assumptions they can legitimately make
about interacting or interfacing systems. Such a scheme will not be infallible, and there is a limit to the extent
to which Contractors can anticipate usage, but the aim is to limit the risk of unsafe emergent properties,
without imposing an excessive burden on Contractors.
iii. Management of interfaces is important to safety as hazards can be initiated at technical interfaces,
and because misunderstandings can occur at aligned technical and organisational interfaces, especially
where several Contractor’s PSS are brought together to form a system of systems.
iv. Where interfaces are at the boundary of the PSS produced by a Contractor (or at the boundary of
the Scope of Analysis) then information needs to be provided for other stakeholders, eg the users of the
PSS, or system integrators. Another stakeholder will need to know what they can assume, or rely on, about
an interface in order that they can meet their Safety Requirements, or to provide guarantees to others. The
assumptions might be physical or to do with information, for example: maximum electromagnetic field
strength; materials used for connectors or latency in data provided.
v. The information on assumptions must always be included in the ISSS. A DID for the ISSS is
included in Annex C to this part of the Standard.
vi. This Standard identifies the need for Safety Case Reports and ISSSs for each PSS supplied.
These reports and/or summaries would include the assumptions as necessary to demonstrate safety, or to
provide information to enable safe assembly of a system of systems.
9.3 External Interacting Interfaces
The Contractor shall assess information provided by the MOD or other Contractors for interacting PSS and
take steps to resolve any inconsistencies in the assumptions made at interfaces, in discussion with the MOD
if necessary.
9.3.1 The Contractor should seek to reconcile assumptions made at boundaries with other PSS to
ensure safe operation of the whole, recognising that changes may need to be made in PSS still under
development, to cater for limitations of other system elements.
Notes:
i. The focus is on what is known about interacting PSS, where there may be limited opportunity to
redesign.
ii. Information provided about interfacing or interacting products may need to be analysed, and
therefore must be defined in the scope of analysis. This clause deals with the case where analysis identifies
incompatibilities between assumptions, or difficulties in meeting Safety Requirements, given all that can be
assumed about interacting PSS.
iii. Changes to resolve incompatibilities will need to be agreed with the MOD as they may go beyond
the boundary of the Contractor’s responsibility. Also, these responsibilities apply at any level in the system
hierarchy, but are particularly onerous for top-level system integrators, and for those assembling System of
Systems. The AOF provides guidance on systems integration.
10 Safety Audits
Note. These clauses cover both audit by the Contractor, and enabling Independent Safety Audit.
Extensive guidance on Independent Safety Audits is available through the AOF. ISAs are appointed by the
MOD, not by the Contractor and guidance on the AOF supports management of expectations. The focus
here is on Contractor safety audits although there is no intent in using that term to imply that the Contractor
cannot employ a third party to carry out audits on their behalf. The intent of Contractor safety audits is to
show that the Contractor has implemented the SMP, as defined, or to identify remedial action in the case of
deviations. This would give a baseline for the ISA who can then take a more wide-reaching role, including
assessing the appropriateness of the SMP.
15
10.1 Audits and Reports
The Contractor shall carry out safety audits as specified in the SMP, to assure the implementation of the
SMP.
10.1.1 A Safety Audit Report shall be produced, following each safety audit, which fully describes the
findings of the safety audit.
10.1.2 All audit findings should be assessed for significance and the need for remedial action identified.
10.1.3 The Contractor should ensure that all Sub-Contract activity is audited.
Notes:
i. The Contractor may audit Sub-Contractors themselves, or rely on third parties, or assess the
results of the Sub-Contractors internal audit. The mechanism is not material; what is important is that the
audit extends throughout the whole supply chain.
ii. It may be helpful for the CSA to make recommendations on remedial action to the Contractor and,
where appropriate, the MOD.
10.2 Independent Safety Audit
The Contractor shall allow an Independent Safety Auditor, if one is appointed, reasonable access to the
information set.
10.2.1 Where restrictions on access to elements of the information set, required for safety audit, are
unavoidable, eg foreign export controls, the Contractor should identify and communicate them to the MOD at
the earliest opportunity.
Note. The intent here is that the Contractor work with the ISA and MOD to overcome access obstacles.
Common approaches include the establishment of Non Disclosure Agreements.
10.3 Remedial Action
The Contractor shall identify and implement timely remedial actions to rectify any agreed non-conformities or
other issues found in safety audits.
10.3.1 The Contractor should agree the remedial actions with the MOD through the Safety Committee,
and any other relevant stakeholders, as appropriate.
10.3.2 The Contractor should update the SMP, if appropriate, to reflect the agreed remedial actions.
Notes:
i. It is important to agree changes with the Safety Committee and other relevant stakeholders, to
ensure that the most effective and efficient route is found.
ii. Some judgment is required as to what nature and scale of remedial action needs to be
incorporated into the SMP, and how that must be done. If the audit shows that the PSS is inadequate, and a
major redesign is required, then the impact will go beyond the SMP.
16
Section 3 - Safety Engineering

Notes:
i. The intent of the Standard is that safety engineering can be undertaken for PSS, but that
knowledge of the broader context is needed if full hazard analysis is to be undertaken for a product. In
general, this would be specified in the scope of analysis.
ii. The Standard covers both the analysis of new (developmental) and pre-existing PSS.
11 Safety Requirements, Hazard and Risk Analysis
11.1 Safety Requirements
The Contractor shall clearly identify, record and track Safety Requirements throughout the Contract.
11.1.1 The Contractor shall document the process for identifying, recording and tracking Safety
Requirements in the SMP.
11.1.2 The Contractor shall identify and record Derived Safety Requirements resulting from MOD policy,
regulations and standards appropriate to the scope of supply and scope of analysis, addressing the domain
and the technology used, relevant to the Contract.
11.1.3 The Contractor shall identify and record all Derived Safety Requirements arising from safety
engineering and safety analysis activities.
11.1.4 The Contractor shall identify and record Safety Requirements to ensure Design Integrity.
11.1.5 The Contractor should identify and record all Safety Requirements, including Top Level Safety
Requirements, in the information set.
11.1.6 The Contractor should identify and record all Derived Safety Requirements needed to ensure
control of risks associated with hazards, and potential risks associated with identified failure modes whether
they are to mitigate the effects of the hazards or failure modes, or to make them less likely to occur.
11.1.7 The Contractor should identify and record Derived Safety Requirements on properties of the PSS,
where necessary to manage risk.
11.1.8 The Contractor should identify and record Derived Safety Requirements on processes, eg to show
independence of elements of the PSS, where necessary to manage risk.
Notes:
i. Safety engineering activities may influence the design resulting in decisions that generate Derived
Safety Requirements. Other system engineering activities may also result in a design decisions which
generate Derived Safety Requirements.
ii. Design Integrity is a generic term, intended to cover mechanical components as well as complex
electronics. This Standard does not impose an integrity scheme as the intent is to use civil, open or other
standards so far as possible. Guidance on Integrity is provided at Annex D to this Standard.
iii. Top Level Safety Requirements are normally imposed by the MOD on the Contractor, eg
URD/SRD. However, relevant standards, policy and legislation may change during the Contract life, requiring
revision of the Top Level Safety Requirements.
iv. Derived Safety Requirements are drawn from policy, etc. as often the MOD’s policies will be set out
in general terms, and interpretation will be needed to produce requirements specific to the PSS in the scope
of supply. Derived Safety Requirements, included in the SMP, must be met using recognised procedures
and it is important that they are recorded for traceability.
17
v. There may be cases where compliance with regulations and standards, eg for CE marking, a
declaration of compliance with new approach and global approach standards, is sufficient to meet Safety
Requirements. If the Contractor believes this to be the case then this must be documented in the SMP
(ideally at ITT stage) for agreement by the MOD. If this is the case, then many of the detailed safety
engineering requirements may not apply.
11.2 Safety Requirements Management
The Contractor shall maintain records to show traceability between each Safety Requirement, the source of
the requirements including safety analysis and mitigation for hazards or potential accidents.
11.2.1 The Contractor should record the evidence which shows that each Safety Requirement (including
Derived Safety Requirements) has been validated as being correct and complete in the information set.
11.2.2 The Contractor should record the evidence which shows that each Safety Requirement (including
Derived Safety Requirements) has been met, or documents any shortfall in the information set.
11.2.3 The Contractor should record the evidence such that it can be included in, or referenced from, the
Hazard Log.
Note. Traceability is fundamental, without it, it is not possible to understand how the results of low level
activities contribute to demonstrating satisfaction of requirements. If traceability is lost then this can seriously
undermine the validity of the Hazard Log, and hence the Safety Case for a PSS. Traceability is bi-directional
(top-down and bottom-up).
11.3 Hazards and Accidents
The Contractor shall identify all hazards and associated potential accidents, from all credible causes, within
the scope of analysis.
11.3.1 The Contractor should employ systematic analysis processes for identification of hazards and
accidents as defined in the SMP.
11.3.2 The Contractor should ensure that human factors are considered where they may be a contributory
cause of a hazard.
11.3.3 The Contractor should ensure that cyber security is considered where security breaches may be a
contributory cause of a hazard.
11.3.4 The Contractor should ensure that systematic and random failures are considered where they may
be a contributory cause of a hazard.
11.3.5 The Contractor should ensure that the undesired impact of normal functions is considered; this is
especially important for Contractors carrying out systems integration.
Notes:
i. There are established approaches to hazard analysis. Further guidance on techniques is available
on the AOF.
ii. Def Stan 00-250 considers application of human factors to system safety.
iii. JSP 440 provides policy and guidance for security.
11.4 Hazard Tracking
The Contractor shall ensure that the status of the control of all hazards is visible throughout the Contract.
11.4.1 The Contractor shall implement a Hazard Log.
11.4.2 The Contractor shall ensure that Hazard Log Reports are delivered as defined in the SMP.
18
11.4.3 The Contractor should update the Hazard Log throughout the Contract to ensure that it accurately
reflects the status of the design, hazard analysis, safety analysis and safety engineering activities.
Notes:
i. Guidance on the management of a Hazard Log is available through the AOF.
ii. The DID for a generic Hazard Log Report is at Annex C to this Standard.
iii. Some civil, open or other standards do not include use of a Hazard Log; in this case agreement will
need to be reached with the MOD whether or not the intent of the Standard is met by other Military or civil
standards, or to consider tailoring this clause. If such tailoring is not agreed, then the Contractor will be
expected to supply a Hazard Log in addition to meeting the requirements of the agreed standards.
11.5 Design for Safety
The Contractor shall undertake the design of the PSS so as to meet all Safety Requirements.
11.5.1 The Contractor shall identify mitigation strategies to minimise safety risk and meet Safety
Requirements.
11.5.2 The Contractor shall select and implement a combination of mitigation strategies for hazards or
failure modes that contribute to a hazard, according to the following precedence:
a) Elimination.
b) Reduce the Risk to Life by engineering means.
c) Reduce the Risk to Life by means based on human factors, incorporating requirements from
Defence Standard 00-250, as appropriate.
11.5.3 The Contractor shall demonstrate the effectiveness of the process for identifying and selecting
mitigation strategies, and shall record the rationale, including the application of the ALARP principle, for the
selection of each mitigation strategy in the information set.
11.5.4 The Contractor shall manage identified mitigation strategies through Derived Safety Requirements,
taking into account design decisions and any potential shortfalls in meeting Top Level Safety Requirements.
11.5.5 The Contractor should identify Derived Safety Requirements which represent the partitioning and
allocation of Safety Requirements to parts of the PSS.
11.5.6 Where there are identified shortfalls, the Contractor should meet the mitigating Derived Safety
Requirements where practicable, enabling any identified shortfalls to be eliminated or where elimination is
not possible, reduced so far as is reasonably practicable.
11.5.7 Where the shortfall does not directly impact safety, eg a non-conformance with an agreed process
standard, the Contractor should use engineering judgement to identify the most appropriate mitigation
strategies and agree them with the Safety Committee.
11.5.8 The Contractor should record the results of applying the mitigation strategies and ALARP, the
evidence that Safety Requirements are met, and any residual shortfalls against Safety Requirements in the
information set.
Notes:
i. References informing designing for safety, based around the use of Derived Safety Requirements
and links between the safety activities and other systems engineering activities, are available through the
AOF.
ii. The Top Level Safety Requirements and Derived Safety Requirements will be linked, and
traceability will be established between them, and between the requirements, design or safety activities from
19
which they arise. In general, low-level requirements will either expand on the higher-level requirements, or
deal with Contractor controlled decisions, design and analysis.
iii. The ultimate responsibility for accepting and operating a system lies with the MOD, and a decision
to deploy a System which is not ALARP can be made only by the duty holder who has considered the Risk to
Life and referred the risk to an appropriate level for acceptance. Contractors must apply ALARP principles
through generating and satisfying Derived Safety Requirements, applying mitigation strategies and possibly
using Cost-Benefit Analysis to justify decisions.
iv. In the DAE, the aviation Duty Holder or Accountable Manager (Military Flying) are the designated
posts who can accept risks as being tolerable and ALARP.
11.6 Safety Analysis
The Contractor shall carry out, using processes as defined in the SMP, safety analysis to identify how
failures or defects in the design might contribute to hazards or accidents.
11.6.1 The Contractor shall ensure that safety analysis covers all technologies, applicable to the PSS, and
is carried out through the design decomposition to a sufficient level of detail to address all credible causes of
hazards, accidents or failure modes that contribute to a hazard or accident.
11.6.2 The Contractor should use the results of the safety analysis to identify Derived Safety
Requirements.
11.6.3 The Contractor should document the results of the safety analysis in the information set.
11.6.4 The Contractor should ensure that the safety analysis results remain consistent with the design.
Note. Safety analysis can be started in the Concept phase but must be started before the design is
mature in order to help guide the design by establishing Derived Safety Requirements, eg for one
component to detect and mitigate the failure of another. The safety analysis may discover sufficiently serious
flaws in the design, eg a single point of failure to a life-threatening hazard that it will also lead to a re-design.
Where there is re-design the safety analysis will need to be repeated or updated to remain consistent with
the design.
11.7 Failure Modes
The Contractor shall identify potential failure modes, from all credible causes, which might contribute to a
hazard in the PSS, or in any known interfacing or interacting PSS, whether extant or planned.
11.7.1 The Contractor shall ensure that the status of control of all identified failure modes that contribute
to a hazard is visible throughout the Contract.
11.7.2 The Contractor shall include, in the information set, information about the identified failure modes.
11.7.3 The Contractor shall include in the ISSS, information on the status of identified failure modes.
11.7.4 The Contractor shall estimate the likelihood of occurrence and opportunities for mitigation for all
identified failure modes that contribute to a hazard and record the results in the information set.
11.7.5 The Contractor should employ systematic safety analysis processes for identification of failure
modes which might contribute to a hazard in the PSS as defined in the SMP.
11.7.6 The Contractor should ensure that human factors are considered where they may be a contributory
cause of a failure mode (see Def Stan 00-250).
11.7.7 The Contractor should ensure that cyber security is considered where security breaches may be a
contributory cause of a failure mode.
11.7.8 The Contractor should ensure that systematic failures are considered where they may be a
contributory cause of a failure mode.
20
11.7.9 The Contractor should ensure that the undesired impacts of normal functions are considered; this
is especially important for Contractors carrying out systems integration.
11.7.10 The Contractor should update information on identified failure modes throughout the Contract to
ensure that it accurately reflects the status of the design, safety analysis and safety engineering activities.
11.7.11 The Contractor should use qualitative estimates where it is not practicable to quantify likelihood.
11.7.12 The Contractor should identify potential mitigations for the failure modes that contribute to a hazard
where this is practicable; in particular they should identify any observable attributes of the PSS which could
be used as triggers for mitigations.
11.7.13 The Contractor should consider human factors where they may provide risk mitigation.
11.7.14 The Contractor should record the results of the failure mode assessment in the information set.
11.7.15 The Contractor should record all assumptions, data, judgements and calculations underpinning the
risk estimation in the information set.
Notes:
i. Identification of failure modes that might contribute to a hazard is an important step in safety
analysis. Contractors may consider using techniques such as Failure Modes and Effects Analysis (FMEA) or
a Failure Modes Effects and Criticality Analysis (FMECA), but may also include functional analyses, eg
Functional Failure Analysis (FFA).
ii. Knowledge of normal functioning of a PSS is also important to understand potential hazards arising
from the operation of the PSS. A normal function or previously identified safe failure mode when the PSS is
used in different context, eg used in a new environment, can lead to emergent hazardous behaviour. Access
to the relevant information would be expected and must be included in the relevant ISSS.
iii. All failure modes that have been identified must be documented (they form part of the information
set), but they may not be relevant to the PSS safety case. Failure modes that contribute to a hazard must be
tracked as they are relevant to the PSS safety case. It may be necessary to revisit the identified failure
modes as the design progresses or requirements change.
iv. The risks associated with failure modes cannot be fully evaluated where the Contractor does not
have enough information, eg to estimate the likelihood of a failure mode evolving to an accident, hence the
need to document assumptions and judgements. The intent here is to evaluate the likelihood of the failure
mode, either qualitatively or quantitatively, and to identify potential mitigations which must be considered by
the designers of systems employing the PSS or system integrators.
v. Guidance on risk estimation and evaluation, including identifying some of the difficulties and
limitations of quantitative risk assessment is available through the AOF.
11.8 Risk Estimation
The Contractor shall carry out risk estimation to determine systematically the severity of the harm and the
likelihood of occurrence for all identified hazards and accidents, utilising the results of the hazard analysis
and safety analysis and record the results in the Hazard Log.
11.8.1 The Contractor, with the agreement of the MOD, should use qualitative estimates for risk
assessment, where it is not practical to quantify severity or likelihood.
11.8.2 The Contractor should consider human factors where they may provide risk mitigation, and the
human element is within the scope of analysis.
11.8.3 The Contractor should record assumptions, data, judgments and calculations underpinning the risk
estimation in the information set, such that they can be reviewed and reconstructed.
21
Note. Risk estimation should be done in terms of Risk to Life. Use of risk criteria such as domain specific
risk matrices may be required by MOD policy or regulation.
11.9 Risk and Compliance Evaluation
The Contractor shall evaluate Risk to Life, for all identified hazards and accidents, and compliance with
relevant legislation, standards, regulations and requirements derived from MOD Policy, as defined in the
SMP and record the results in the information set.
11.9.1 The Contractor should evaluate risks against the criteria agreed in the SMP.
11.9.2 The Contractor should record all assumptions, data, judgements and calculations underpinning the
evaluations in the information set, such that they can be reviewed and reconstructed.
11.9.3 The Contractor should use the evidence produced to evaluate compliance with relevant legislation,
standards, regulations and requirements derived from MOD policy.
11.9.4 The Contractor should record the risk and compliance evaluation results in the information set.
Note. It is expected that the Contractor would always be able to evaluate compliance with legislation,
standards, regulations and requirements derived from MOD policy, regardless of the scope of supply and
scope of analysis.
11.10 Satisfaction of Requirements
The Contractor shall carry out safety and systems engineering activities, including but not limited to test, to
provide evidence that all Safety Requirements, including Derived Safety Requirements, have been met.
11.10.1 The Contractor shall undertake systems engineering activities which are capable of detecting
counter-evidence.
11.10.2 The Contractor should identify the most effective method, or methods, for showing satisfaction of
requirements, or providing counter-evidence, and include this information in the SMP.
11.10.3 Whilst there might be general identification of techniques early in the process, the Contractor
should ensure that the methods chosen are appropriate to the specific Derived Safety Requirements
identified.
Notes:
i. In some cases, the only way to show a Derived Safety Requirement has been met might be
through a safety analysis technique, eg a FMEA supported with manufacturer’s failure rate data can show
satisfaction of a quantitative target for the occurrence of a failure mode identified through fault tree analysis.
However, in general, as the Derived Safety Requirements can range across any specialty systems
engineering discipline, a wide range of techniques might be relevant.
ii. Counter-evidence indicates that the PSS may not meet its Safety Requirements and can arise from
incidents, accidents, engineering processes or changes in the operating environment. The systems
engineering processes is to be of sufficient rigour to generate counter-evidence when the design solution
does not satisfy the Safety Requirement, eg if the requirement has been incorrectly or poorly translated into
design then the engineering verification/review process is expected to identify the shortfall. If an
incident/accident arises during in-service use then this class of counter-evidence could be an indication that
the systems engineering and safety processes were insufficient.
12 Health Monitoring and Reporting System

Where practicable and where there is clear evidence that in-service safety will benefit, the Contractor shall
incorporate a health monitoring and reporting system with an open and accessible interface standard in the
design for the PSS.
22
Notes:
i. There needs to be an agreed process of ownership and management for retrieval and analysis of
reported data.
ii. Some regulations and standards require defined recording systems eg Accident Data Recorders or
Voyage Recorders.
13 Safety Reporting
Note. The safety reports produced by the Contractor will vary with the scope of supply and scope of
analysis, and also with the domain.
13.1 Information Set Safety Summary
The Contractor shall produce an ISSS as defined in the SMP.
13.1.1 The Contractor shall ensure that the ISSS contains sufficient information from the information set to
enable a system integrator or operator to discharge their safety responsibilities.
13.1.2 The Contractor shall ensure that the ISSS contains information on assumptions and limitations
regarding the safe use of the PSS.
13.1.3 The Contractor shall ensure that the ISSS includes a justification of the scope of the information
provided.
13.1.4 The Contractor should ensure that the ISSS is delivered incrementally, as Contracted and as
defined in the SMP, to give the MOD visibility of progress in safety engineering and safety analysis.
Notes:
i. The concept, use and applicability of ISSS and its relationship with Safety Case Reports are
discussed in Annex B and their relevant DIDs in Annex C.
ii The intent is that the ISSS provides information which a system integrator or user needs to employ
the PSS safely, and where the Contractor does not have enough knowledge (within the scope of analysis) to
assess Risk to Life. In some cases a Contractor will produce both an ISSS and a Safety Case Report.
13.2 Safety Case
The Contractor shall produce a Safety Case or Safety Cases for a PSS as defined in the SMP.
13.2.1 The Contractor shall ensure that the Safety Case consists of a structured argument, supported by
a body of evidence that provides a compelling, comprehensible and valid case that a system is safe for a
given application in a given environment.
13.2.2 The Contractor shall ensure that the evidence for the Safety Case is drawn from the information
set.
13.2.3 The Contractor shall address the life of the PSS, as defined in the SMP.
13.2.4 The Contractor shall ensure that the Safety Case identifies how to address any residual shortfalls
in meeting Safety Requirements.
13.2.5 The Contractor shall provide evidence to demonstrate the competence of individuals and
organisations responsible for tasks that have a bearing on safety.
13.2.6 The Contractor shall develop, maintain and refine the Safety Case as defined in the SMP and in
developing the Safety Case the Contractor shall address the full lifecycle (CADMID/T) of the PSS.
13.2.7 Where practicable, the Contractor should provide objective evidence.

23
13.2.8 The Contractor should provide diverse evidence, to ensure that that the overall safety argument is
not compromised by errors or uncertainties in individual pieces of evidence.
13.2.9 The Contractor should demonstrate that the arguments and evidence in Safety Cases are sound,
comprehensive and trustworthy.
13.2.10 The Contractor should provide evidence to demonstrate the adequacy and suitability of the
methods and techniques used for safety and risk analysis and in safety engineering.
13.2.11 The Contractor should develop, maintain and refine the Safety Case through the life of the
Contract.
13.2.12 The Contractor should provide evidence of competency of those whose work could impact safety
and confidence in the Safety Case.
13.2.13 The Contractor should ensure that any related Safety Cases or information sets already in
existence and identified in the scope of analysis are utilised and integrated as necessary.
Notes:
i. The Safety Case addresses hazards where the Contractor can assess risk, whereas the
information set is much broader, addressing, for example, failure modes where the Contractor cannot assess
risk (in their scope of analysis).
ii. The Safety Case may not be deliverable and, if the MOD wish to pass on support of the PSS to a
third party, explicit provision for the delivery of the Safety Case would have to be made in the scope of
contract.
iii. The requirements for the scope and content of the Safety Case are likely to vary with domain, and
the detailed requirements are set out in the domain-specific MOD policy and regulation, eg the DAE has one
safety case “The Air System Safety Case”. It is supported by a number of Safety Assessments (defined in
MAA02). Where the Contractor is required to supply Safety Cases, Safety Cases Reports; in the DAE they
are referred to as Safety Assessments and Safety Assessment Reports.
iv. In developing the Safety Case, the Contractor may need to consider the full lifecycle (CADMID/T)
of the system. For example, a delivered Service applies to the in-service phase of CADMID/T but if the
Service life is extended, then the C, A, D and M phase lifecycle assumptions may need to be re-evaluated.
v. The Contractor may not be employed through all phases of the lifecycle but will be required to
consider all CADMID/T in the analysis, eg disposal. In all cases this requirement will be defined in the scope
of the contract as an extension of the scope of analysis.
13.3 Safety Case Reports
The Contractor shall produce a Safety Case Report or Reports as defined in the SMP.
13.3.1 The Contractor shall produce Safety Case Reports that incorporate the key elements of the safety
argument and references to evidence so that, in principle, it would be possible to access the complete Safety
Case, starting from the Report, or counter-evidence where it has been identified.
13.3.2 Where there are shortfalls in the evidence the Contractor shall ensure that the Safety Case Report
provides the rationale for operating the PSS, and the ways of mitigating the residual risk.
13.3.3 The Contractor shall ensure that the Safety Case Report contains information on assumptions and
limitations regarding the safe use of the PSS.
13.3.4 The Contractor shall produce Command Summaries, as defined in the SMP, documenting the
assumptions and limitations for safe in-service use of the PSS.
13.3.5 The Contractor should ensure that any related Safety Case Reports or ISSSs already in existence
and identified in the scope of analysis are utilised and integrated as necessary.
24
13.3.6 The Contractor should deliver the Reports incrementally, as Contracted, to give the MOD visibility
of progress in safety engineering and safety analysis.
Notes:
i. Where there are shortfalls in evidence and if the Contractor cannot provide a rationale, then this
must be raised with the MOD and other stakeholders so that the relevant duty holder and Safety Committee
can take the necessary steps to assist the Contractor in addressing the shortfalls.
ii. The concept, use and applicability of Safety Case Reports, Command Summaries and their
relationship with ISSS are discussed in Annex B and their relevant DIDs in Annex C. Further guidance on the
concepts of MOD Safety Cases and Safety Case Reports are available through the AOF.
iii. The DAE use of Safety Assessments and Safety Assessment Reports to support the Air System
Safety Case is defined in MAA02.
iv. Detailed requirements for safety-related report and summaries may vary with domain regulatory
requirements.
14 Supply and Change Management
14.1 Build State Definition
The Contractor shall produce records which show the build state definition (configuration) of each PSS
element supplied.
14.1.1 The Contractor shall ensure that all stakeholders identified in the SMP as needing to be kept up to
date regarding the build state to ensure or preserve safety are provided with the build state definition.
14.1.2 The Contractor should ensure that all parts employed are as specified in design, or provide
information to enable an assessment of the impact of change where the original parts are not available or
have changed.
14.1.3 The Contractor should ensure that the build state definition is specific to each delivered instance of
a PSS, so that specific instance is properly managed.
Notes:
i. An important concept here is the build state definition, which identifies each individual PSS both as
initially designed, and as it evolves through life. The responsibility for the build state definition may migrate
from the initial Contractor to the support organisation as the PSS evolves through life; in some cases
responsibility for the build state may rest with the MOD.
ii. Defence Standard 05-57 addresses configuration management, including giving domain-specific
requirements.
iii. No DID is supplied for the build state definition, as this is a general systems engineering concept,
not something specific to safety.
14.2 Change Control
The Contractor shall define in the SMP, a change control system so that the safety impact of any planned or
unplanned change can be identified and assessed.
Note. Change control is important in the early phases of the CADMID/T cycle but more so in the in-
service phase, as mitigation and management procedures may apply to PSS in active operations. All
changes must be managed but unplanned in-service changes, due to operational circumstances, will need to
be identified and assessed.
25
14.3 Planning for Change
Where changes are anticipated, eg for managing obsolescence, the Contractor shall develop and implement
plans for proactively identifying and addressing those changes to ensure the continued safety of the PSS.
14.3.1 The Contractor should consider all relevant change drivers, including modified operating
requirements, the availability of new technologies, as well as supply chain issue such as changes to
legislation, obsolescence or ageing components, and put in place plans for dealing with all of these issues
and coordinating plans to minimise the impact of change.
Notes:
i. Although the Contractor may not be in a position to make ALARP judgements directly, they will be
in a position to support the decision process by identifying new technology options which may enable more
cost-effective mitigations, or which make previously discarded design options practicable. The SMP is
reviewed and agreed by the Safety Committee, and is the appropriate mechanism to propose design
enhancements arising out of compliance with this clause. This is to enable the MOD to judge which
improvements can be implemented in order to comply with its obligations, and meet its operational
commitments.
ii. Implementing change plans may require a contractual review; such commercial issues are outside
the scope of this Standard. However, such a review may result in a modified scope of contract.
14.4 Safety of Changes
The Contractor shall manage all changes under their control so as to preserve safety as in the original
design intent or to improve the safety of the deliverable PSS.
14.4.1 The Contractor shall review and update the information set and ISSS, as defined in the SMP, to
ensure that they remain valid.
14.4.2 The Contractor shall review and update the Safety Case and Safety Case Report, as defined in the
SMP, to ensure that they remain valid.
14.4.3 The Contractor should update the design where there are agreed changes to the Safety
Requirements, updating the information set accordingly.
14.4.4 The Contractor should update the hazard analysis and safety analysis as necessary for all
changes, both intended and unplanned, updating the information set accordingly.
14.4.5 Following any change which has an adverse effect on safety, the Contractor should propose, agree
and implement further revisions to the design so as to preserve safety.
Note. It is desirable to maintain safe PSS. However, due to operational necessity the MOD can decline to
endorse changes or may impose operational limitations on equipment in-service that may be out of control of
the Contractor and have an adverse effect on safety. The aim is to restore safety as soon as possible.
14.5 Safe Update
The Contractor shall supply updated PSS and associated information, as defined in the SMP, to enable
safety to be preserved.
14.5.1 The Contractor shall supply appropriate installation instructions to enable changes to be made
safely to the in-service PSS.
14.5.2 The Contractor shall update the build state definition for each modified PSS, so that it reflects the
modified build state and provide an audit trail of those modifications.
Note. The safe update clauses are intended for Contractors with responsibility for determining and
enabling the required update. The incorporating change and supporting systems in the Safety In-Service
26
Section identifies the safety requirements where the Contractor is also responsible for implementing the
update.
14.6 Monitoring Change
The Contractor shall monitor changes to in-service PSS that are visible to them, including using the results of
normal reporting, to identify cases where the changes may have undesired safety impacts.
14.6.1 Where undesired safety impacts are identified, the Contractor shall notify the relevant stakeholders
and, where practicable, recommend mitigation to control Risk to Life.
14.6.2 To ensure visibility of changes, the Contractor should agree with the MOD the monitoring channels
to be used; these should be recorded in the SMP.
.Note. The Contractor may have visibility of the in-service use of the PSS, in such cases the Contractor
will need to keep accurate build state configuration records of the individual PSS. This visibility may include
changes in use of the PSS in-service. The extent of the responsibility of monitoring and reporting safety
impacts due to changes will be part of the agreed scope of supply.
14.7 Incorporating Change
The Contractor shall incorporate any new or modified PSS into the in-service system, as defined in the SMP,
so as to maintain or improve safety.
14.7.1 The Contractor shall provide information to other relevant stakeholders, including the MOD in all
cases, to enable them to assess the impact of changes made to the in-service system.
14.7.2 The Contractor should assess supplied PSS, together with installation instructions, and develop
and implement plans for safe installation and maintenance.
14.7.3 The Contractor should ensure that the installation plans address changeover from the old to new
PSS, to ensure that safety is managed throughout the change and, so far as is reasonably practicable, to
ensure that a reversion to the previous configuration could be carried out should this prove necessary.
14.7.4 Where temporary modifications have been made to manage risk the Contractor should ensure that
they are removed once a permanent resolution has been implemented.
14.7.5 The Contractor should agree with relevant stakeholders what changes are to be made, including
any necessary deviations from the original installation instructions, to enable them to discharge their
obligations, eg to maintain an accurate record of the build state.
Notes:
i. In many PSS cases the Contract development and manufacture phases will overlap the in-service
phase of the CADMID/T lifecycle. These clauses may apply during the overlap and will, depending on the
scope of contract, extend to full in-service support. Therefore, these requirements relate to safety
maintenance support which may form part of a Contractor provided service. Contractors will need to include
relevant safety in-service requirements for supporting PSS and provision of services detailed in this
Standard.
ii. For a specific build state, the Safety Case, the associated Safety Case Report and the Command
Summary or Summaries, where relevant, need to be amended immediately so all the information remains
valid. In practice a judgement needs to be made regarding the necessity of change, as there is a cost to
updating documentation but also a risk of not doing so.
iii. Where in-service PSS would be required to be taken out of operational service, safety updates may
not be achievable in the short term and may require alternative mitigation to be considered and effectively
implemented.
27
iv. MOD necessarily has control over in-service requirements. It will be the duty holder who makes
decisions on implementation of mitigation and responsibility for Risk to Life.
v. In the DAE, the aviation Duty Holder or Accountable Manager (Military Flying) are the designated
posts who can accept risks as being tolerable and ALARP.
28
Section 4 - Safety In-Service

Notes:
i. This section of the Standard relates to additional requirements when the PSS is in the in-service
phase of the CADMID/T cycle and is concerned with Contractor support to in-service PSS and Contractor
provided services. This Section would be tailored to meet the scope of contract, and may be applied to trials
and demonstrations.
ii. The boundary between what is provided in support of the in-service PSS, and a Contractor
managed services will depend on the scope of analysis or scope of supply, the in-service/operational
scenarios and form part of the agreed scope of contract. In all cases the SMP and other associated plans
must delineate the roles, responsibilities, and communication channels and decision-making mechanisms.
iii. Regulators may have domain specific requirements for in-service support or service provision. The
intent here is to set generic requirements on Contractors that are independent of those domain specific
requirements or regulations.
15 Supporting Systems In-Service
15.1 Management of Safety-Related In-Service Data
The Contractor shall coordinate the management of safety-related in-service data where the deliverable PSS
interface or interact with other PSS.
15.1.1 The Contractor should exchange in-service data, or the results of analysing the data, with the
stakeholders responsible for the operation of interfacing and interacting PSS where they might be able to
use it to help sentence problems, and to determine remedial action.
Notes:
i. The Contractor will establish organisational interfaces with other stakeholders applicable to the
safety management elements of the Standard. This requirement expands on a general obligation to deal with
in-service data, by referring to stakeholders who may be integrators or responsible for interfacing PSS.
ii. Hazards on one PSS in a system may result in new hazards that manifest in another interfacing
system. Interfacing with other stakeholders (MOD and other Contractors) need to be agreed, which may
require change to the scope of contract and managed through the SMP.
iii. This Standard cannot place requirements on the MOD. Any Contractor requirements for data must
be agreed in the scope of contract and captured in the scope of analysis. If health monitoring and reporting
system is employed then supply of data will be agreed at scope of contract.
15.2 Monitoring and Reporting
The Contractor shall define and operate a process for recording and analysing relevant data from operation
of the PSS (including accident and incident reporting data), to control in-service Risk to Life and to inform the
stakeholders responsible for support activities.
15.2.1 The Contractor shall review the Safety Case, in the light of the recorded data to identify areas
where operations vary from predictions or assumptions, eg the actual Risk to Life is significantly higher than
the estimated Risk to Life, or a PSS is operated outside declared limitations.
15.2.2 The Contractor shall sentence the results of analysis of the data and the review of the Safety Case
to determine situations which indicate the need for remedial action and, once agreed with the MOD, shall
implement those actions within their sphere of responsibility.
15.2.3 The Contractor shall inform all relevant stakeholders where they have identified the need for
remedial action, and provide those stakeholders with sufficient information to enable them to take
appropriate action.
29
15.2.4 The Contractor should define and operate a process for collecting, analysing and documenting
safety-relevant in-service data including but not limited to usage and environment.
15.2.5 The Contractor should define and operate a process for collecting, analysing and documenting
defect or failure data.
15.2.6 The Contractor should define and operate a process for collecting incident, accident and near miss
reports, and comparable data from other operations available to the Contractor or supplied by the MOD.
15.2.7 The Contractor should analyse all collected data addressing both individual events and longer-term
trends, to identify those events which require action.
Notes:
i. These clauses require coordination between operations and support, regardless of whether the
support is provided by MOD or industry (or both) and the boundaries of responsibilities will be defined clearly
in the SMP or in a different plan as agreed with the MOD.
ii. Defect or failure data will be obtained from various sources some of which may be management
processes or part of the PSS (eg Accident Data Recorders).
15.3 In-Service Data Analysis
The Contractor shall define and operate a process, agreed with the MOD, for sentencing and prioritising
reported data from the in-service use of the PSS to identify remedial action to preserve or improve safety.
15.3.1 The Contractor should liaise with the MOD to establish, or interface to, a Failure Reporting Analysis
and Corrective Action Systems (FRACAS) or equivalent, to ensure that support is based on as accurate and
timely data from operations, as is practicable.
15.3.2 The Contractor should analyse reported defects, errors or failures, including human errors, across
all Defence Lines of Development, for their impact on safety to identify remedial action to preserve or
improve safety.
15.3.3 The Contractor should analyse reported incident, accident and near miss reports, and comparable
data from other operations available to the Contractor or supplied by the MOD, for their root causes to
identify remedial action to improve safety.
15.3.4 Where the Contractor supports in-service PSS which are in use by multiple stakeholders, the
Contractor should, so far as is reasonably practicable, use information relating to the PSS to efficiently and
effectively manage safety.
Note It is likely that much of the analysis of in-service data will require operational or engineering
judgement, rather than being based on solely statistical analysis.
15.4 Remedial Action
The Contractor shall implement remedial actions to preserve or improve safety, agreed with the MOD and
prioritized accordingly.
15.4.1 The Contractor should plan remedial actions taking into account the need for efficient change
management, to enable updates to the in-service PSS with minimum disruption.
15.4.2 The Contractor should plan remedial actions taking into account the need to deal with foreseeable
changes, as well as those driven by analysis of in-service events.
Notes:
i. The emphasis in these clauses is on remedial action, however the longer term actions are just as
important. eg design changes, to remedy problems, as implementation plans based on risk analysis will be
the responsibility of the duty holder.
30
ii. The Contractor will have a duty to notify relevant stakeholders if they identify that immediate
remedial action is required. Domain specific requirements or regulations will be captured in the scope of
contract.
iii. The Safety Committee will prioritise remedial action. The organisational arrangements will be
defined in the SMP.
16 Service Provision
Note These clauses apply only when the Contractor is supporting the MOD by providing a Service,
which may include operating a PSS. It is intended that they cover development operations, eg test firings,
sea trials, flight trials, etc. These are general requirements for such activities and there may be domain-
specific requirements or regulations. These clauses will not be applicable if the scope of contract does not
include service provision.
16.1 Safety Case Report
The Contractor shall produce a Safety Case Report and Command Summary and deliver them to the MOD
for approval before commencement of services.
16.1.1 The Contractor shall maintain the Safety Case, Safety Case Report and Command Summary so
they are accurate representations of the service.
16.1.2 The Contractor should produce Command Summaries so that each provision of the service can be
properly assessed and controlled in terms of risk.
16.1.3 The Contractor should provide information to support domain specific processes providing
essential information for the duty holder responsible for the service to manage Risk to Life.
Notes:
i. The Command Summary is intended to provide essential safety information on the provided
service for the mission commanding officer or manager to manage Risk to Life, and may be mission or sortie
specific. Therefore, this may lead to the production of more than one Command Summary.
ii. The Command Summaries and Safety Case Reports will be reviewed and accepted by the MOD
Regulators, duty holders and stakeholders, prior to commencement of operations.
iii. In the DAE, the Operating Duty Holder is responsible and accountable for the Air System Safety
Case. All Duty Holder Facing organizations have a responsibility iaw RA1020 in the management of Risk to
Life.
16.2 Service Provision Planning
The Contractor shall produce plans for management of service operations, covering all reasonably
foreseeable situations including abnormal and emergency situations.
16.2.1 The Contractor should ensure that the plans cover the safety of the full range of normal services
and operations, including but not limited to defining standard operating procedures, resourcing, training, and
oversight arrangements.
16.2.2 The Contractor should ensure that the plans cover the safety of emergency situations, including but
not limited to defining emergency response, coordination and decision making, including liaison with the
service duty holder and relevant stakeholders.
16.2.3 The Contractor should ensure that these plans cover safe update, including ways of making
changes on continuously running systems, if necessary, building on installation instructions supplied from
support, as appropriate.
31
16.2.4 The Contractor should ensure that the communications plan, detailed in the SMP, includes
processes for delivery of in-service data and build state definition.
Note. These plans may be part of the SMP or in a separate plan as agreed with the MOD where the
Contractor provides a service that supports an in-service/operational capability. It is essential that the
coordination mechanisms between relevant roles, responsibilities and delivery communication mechanisms
are clear.
16.3 Risk Management
The Contractor shall support the MOD in managing predicted or emergent Risk to Life arising from hazards
and accidents associated with the service, according to the ALARP principle, throughout the Contract life,
and as defined in the Safety Case Report.
16.3.1 The Contractor shall cooperate with the duty holders for interfacing or interacting services or
operations to enable effective management of Risk to Life.
16.3.2 Where necessary and with the duty holder agreement, the Contractor shall implement immediate
action to manage Risks to Life until a longer-term resolution is identified.
Notes :
i. As these requirements relate to a service upon which a MOD military capability may depend, there
is an explicit requirement on the Contractor to support the management of Risk to Life (as opposed to
providing information to enable the MOD to do so). This is necessary and appropriate when the Contractor
has responsibility for a service that may contribute directly to the in-service Risk to Life and will necessitate
demonstrable compliance with the ALARP principle. This will be agreed with the MOD and defined in the
scope of supply and documented in the SMP. Decisions on whether a Contractor service that impacts on the
Risk to Life is compliant with the ALARP principle will be made by the MOD duty holder endorsed through
the mechanism of the MOD SMS.
ii. Guidance on ALARP in a military equipment context is available on the AOF.
iii. DAE specific guidance on ALARP is contained in RA1210.
iv. It is essential that plans ensure that the roles, responsibilities, communications and decision and
action mechanisms are in place so as to manage the emergent risk. This is particularly essential where
immediate action is necessary to deal with an emergent risk.
32
ANNEX A
DEFINITIONS
For the purpose of this Standard, the following definitions apply:
Term Definition
Accident An event, or sequence of events, that causes unintended harm.
ALARP As Low As Reasonably Practicable (for further clarification refer to extant MOD
guidance).
CADMID/T Reference to the acquisition lifecycle for capability, the term CADMID/T comes
from the initial letters of its six phases, Concept, Assessment, Demonstration,
Manufacture, In-Service, Disposal/Termination.
Command Summary A distillation of the safety case report providing essential information for the
in-service/operational commanding officer or manager of a system or operator of a
service to manage operating risk.
Contractor Safety An individual or team, independent from those areas within the Contractor’s
Auditor organisation, or any Sub-Contractors, that are subject to Contractor safety audit.
that undertakes audits and other assessment activities on behalf of the Contractor.
Counter-evidence Evidence that has the potential to refute specific safety claims, eg evidence
showing that Safety Requirements, including Derived Safety Requirements, have
not been met.
Defence Air A term equivalent to Military Air Environment used to emphasize the inclusion of
Environment contractors and industry engagement, support and operations.
Derived Safety A safety requirement which is derived from a design or analysis activity.
Requirement
Design Integrity The extent to which the design is free from flaws which could give rise to or
contribute to hazards or failure modes that contribute to a hazard.
Duty holder A duty holder is a MOD person who is in key position which is responsible and
accountable for the control of activities that are so hazardous that they could give
rise to a risk to life (for further clarification, refer to extant MOD guidance).
Failure Mode An unintended behaviour of a product, service or system which could be
hazardous in the broader system context, eg when the product or service is
integrated into a system, or system as part of a system of systems.
Harm Adverse impact on people, including fatality, physical or psychological injury, or
short or long term damage to health.
Hazard Potential to cause harm, eg A physical situation or state of a system, often
following from some initiating event that may lead to an accident.
Hazard Analysis The process of analysing in detail the hazards and accidents associated with a
system.
Hazard Identification The process of identifying and listing the hazards and accidents associated with
a system.
Hazard Log The continually updated record of the hazards and accidents associated with a
system. It includes information documenting risk management for each hazard
and accident.
Hazard Log Report A periodic report of status of the Hazard Log.
Health Monitoring and A system which monitors key parameters of a PSS to enable diagnosis of
Reporting System failures and, in some cases, prediction of impending failures to enable action to
be taken to prevent failures occurring.
33
Term Definition
Human Factors The systematic application of relevant information about human capabilities,
limitations, characteristics, behaviours and motivation to the design of systems.
Incident The occurrence of a hazard that might have progressed to an accident but did
not.
Independent Safety An individual or team, from an independent organisation, that undertakes audits
Auditor and other assessment activities on behalf of MOD to provide assurance that safety
activities comply with planned arrangements, are implemented effectively and are
suitable to achieve objectives; and whether related outputs are correct, valid and fit
for purpose.
Information Set The information from the design of a product, service or system and its analysis
that is pertinent to safety.
Information Set Safety A summary of the information set which identifies the safety properties which
Summary support production of a safety case, particularly where the requirement includes
integration or interfacing with other PSS for an intended use in a given operating
environment.
Mitigation Strategies Measures that, when implemented, reduce risk.
Operating The total set of all external natural and induced conditions to which a system is
Environment exposed at any given moment.
Product An engineered artefact. Products can be from the small scale, eg a pump or a
digital map, to the large scale, eg an aircraft carrier or a geographically distributed
logistics application program.
Programmable PSS that is implemented in software or programmable hardware, which includes
Element any device that can be customised eg ASICs, PLDs and FPGAs..
Progress Report A periodic report of the status of the Safety Management Plan.
Risk Combination of the likelihood of harm and the severity of that harm.
Risk to Life Risk of harm.
Regulator An agency that ensures compliance with laws, regulations and established rules.
(May be MOD or civilian).
Risk Estimation The systematic use of available information to estimate risk.
Risk Management The systematic identification, evaluation and reduction of risk.
Safe Freedom from unacceptable or intolerable levels of harm.
Safety Analysis The systematic identification of potential causes of hazards or failure modes that
contribute to a hazard.
Safety Audit Audit to ensure that safety activities comply with planned arrangements, are
implemented effectively and are suitable to achieve objectives and related
outputs are correct, valid and fit for purpose.
Safety Auditor An individual or team that undertakes safety audits.
Safety Audit Report A report summarising the conduct of a safety audit, identifying findings, actions
and recommendations.
Safety Case A structured argument, supported by a body of evidence that provides a
compelling, comprehensible and valid case that a system is safe for a given
application in a given operating environment.
34
Term Definition
Safety Case Report A report that summarises the arguments and evidence of the safety case and
documents progress against the safety management plan.
Safety Committee A group of stakeholders that exercises, oversees, reviews and endorses safety
management and safety engineering activities.
Safety Engineering The development of products, services or systems which are safe, informed by
hazard identification, hazard analysis, risk analysis, safety analysis and
knowledge of failure modes that contribute to a hazard.
Safety Management The application of organisational, management and engineering principles in
order to achieve safety.
Safety Management The organisational structure, processes, procedures and methodologies that
System enable the direction and control of the activities necessary to meet Safety
Requirements and safety policy objectives.
Safety Management A document that defines the strategy for addressing safety and documents the
Plan Safety Management System for a specific project. .
Safety Requirement A requirement that, once met, contributes to the safety of a product, service or
system or the evidence of the safety of a product, service or system.
Scope of Analysis The depth and coverage of the safety engineering activities defined in the
Contract. The scope of analysis may apply to all, or more or less than, the scope of
supply.
Scope of Contract The scope of supply and scope of analysis.
Scope of Supply The products and/or services and/or systems and deliverable information to be
produced by the Contract.
Sentencing A decision expressing a judgement on the required remedial safety action, eg
mitigation strategy or derived safety requirement.
Service The operation or usage of a system in a defined operating environment to
achieve a specific purpose or purposes. A service can be any activity using a
system, eg maintaining/updating military vehicles.
Severity A measure of the degree of harm.
System A combination, with defined boundaries, of elements that are used together in a
defined operating environment to perform a given task or achieve a specific
purpose. The elements may include personnel, procedures, materials, tools,
products, facilities, services and/or data as appropriate.
System of Systems A system that includes more than one element that are themselves systems, and
which are interdependent but are not necessarily controlled by the same
authority or mechanism.
System Integrator A Contractor or organisation responsible for the bringing together of PSS,
ensuring that the components function together, to produce a higher-level system
or capability as defined in the Contract.
Top Level Safety Safety requirement explicitly imposed on the Contractor, usually arising from the
Requirement Contract, relevant legislation, standards or MOD policy.
35
36
ANNEX B
CONTRACTING TO DEFENCE STANDARD 00-56 PART 1
GUIDANCE
1 MOD Policy
1.1 The role of Defence Standard 00-56 is to place requirements on Contractors to enable MOD to
meet its obligations for safety management as defined by the Secretary of State’s Policy Statement and
amplified by JSP 815, Defence Environment and Safety Management. MOD policy requires compliance with
relevant legislation, policy, regulation and standards, both civilian and military. Codes of practice, mandated
procedures, advice and guidance are also provided to support MOD staff in delivery of safe PSS.
1.2 The Contractor is expected to derive Safety Requirements arising from relevant MOD policy. The
MOD will assist the Contractor identify relevant MOD policy, including standards and regulations. DE&S
delivers the mandated Safety Management System through the Project Oriented Safety Management
System (POSMS) which is available through the Acquisition Operating Framework (AOF) via the following
link https://www.gov.uk/acquisition-operating-framework. Further guidance on safety requirements is
available through the POSMS, Safety Management Procedure 10.
1.3 This Standard requires Contractors to meet their obligations with relevant aspects of legislation and
regulation, and to document the applicable legislation and regulation in the SMP.
Note. This Standard places obligations on the Contractor to identify legislation and regulations, and it is
assumed that a competent Contractor will either already be aware of such legislation and regulations, or is in
a position to identify it, particularly where they are selecting options for the PSS solution.
2 Products, Systems and Services
2.1 Most MOD acquisitions result in a delivery of an article which is intended to be operated; this
Standard refers to such artefacts as products. Products will range size and type, example products are: a
chemical sensor, a winch, a software application and a ship. However Products usually need additional
elements, such as supplies, crew, weapons, etc. in order for them to be considered as an in-
service/operational system.
2.2 Military systems are composed of elements such as Products, Services and possibly other
Systems. A System also includes Defence Lines of Development, eg procedures, supplies, training,
personnel, etc. and will usually be operated by military personnel, although civilian supported operation also
occurs. A System is usually intended to be operated in a defined environment, to achieve a particular
capability. An example System is an operating warship.
2.3 A military service is provided by the operation or use of a system. Thus a Contractor may operate a
system and provide a Service, eg a network service. In this case, the Contractor may have some
responsibility for supporting in-service safety, ie the availability of the service has to be considered in the
Risk to Life and health of MOD and civilian personnel. However, when this Standard is applied, it will always
be the case that there is an MOD duty holder who has ultimate responsibility for Risk to Life. As the range of
scenarios for providing PSS is very large, there may be conflict between the legal obligations on Contractors,
eg under the Health and Safety at Work etc Act 1974, and the operational imperative. This Standard expects
that the scope of contract will define contractual clauses which will be agreed between MOD and the
Contractor to ensure these issues are managed.
2.4 It is important to note that:
a) The MOD sometimes uses Contractors on Deployed Operations to provide operational support.
This Standard does not define rules or procedures for such cases as these are addressed by other
MOD procedures and policies (eg CONDO).
b) The distinction between different PSS impacts on the safety engineering and management
processes. For any PSS, a Contractor will be able to identify and manage some hazards, eg the
37
possibility of trapping hands in a winch. Other hazard identification will depend on the way the PSS
is used or employed. The Contractor will be reliant on the defined requirements in the scope of
contract, eg Concept of Use/Employment/Operation or User and/or System Requirement
documents (URD/SRD).
3 Summaries, Information Sets and Safety Case
3.1 The MOD generally acquires PSS which are intended to form part of more complex systems. The
system integrator will need to be provided with relevant information to enable them to assess the overall Risk
to Life. Such information could include the failure modes associated with the use of the PSS, as well as
usage constraints. This relevant information may be captured in the information set and summarised in an
ISSS but not used in the primary PSS Safety Case.
3.2 This Standard has introduced the information set, which identifies the totality of information
produced in support of the PSS. However, it would be impractical to deliver all such information to all
relevant Stakeholders. Hence, the Standard introduces the concept of an Information Set Safety Summary
(ISSS), to represent the extracted safety information, required by the Contract, to be delivered by the
Contractor to the MOD and other Stakeholders.
3.3 Together the ISSS, Safety Case Report and Command Summary represent the deliverables that
communicate safety information to the relevant stakeholders. The Safety Case Report and ISSS address
distinct purposes and may not both be required depending on the scope of contract. The intent of these
deliverables is expanded below:
a) The Command Summary is intended to provide essential safety information on the PSS for the
individual who has to manage in-service/operational risk. The Command Summary draws on
information in the Safety Case Report.
b) The ISSS is intended to provide sufficient information to enable PSS to be safely integrated into a
higher level PSS, or interfaced to a peer PSS. The ISSS summarises the technical properties of the
PSS that are relevant to safe integration/interface where the Contractor cannot directly assess Risk
to Life. The ISSS would be used by the integrator of the higher level PSS to support their safety
assessment and contribute to the top level safety case.
c) The Safety Case Report is intended to summarise the arguments and evidence of the safety case
for a given application in a given operating environment.
3.4 For some Products and Services an ISSS may be sufficient to support the overall System Safety
Case. As an example, a commercial off the shelf (COTS) winch ISSS may contain sufficient information
relevant for Risk of Life in the wider context. This would include Hazards, eg trapping hands, failure modes,
eg locking or sticking and technical information, eg load limits. In general the ISSS could be used to help
define limitations of use for a defined capability.
3.5 A System Safety Case needs to place the COTS winch in context for the specific in-service use, eg
replenishment at sea or deployment of a lifeboat. The ALARP principles would then be applied in the system
context that may lead to a safety guard fitted around the winch to mitigate a trapped hands hazard. In this
case there may only be a Safety Case Report for a lifeboat system, supported by a number of ISSSs, one of
which will be for the COTS winch.
3.6 This Standard places requirements on Contractors to collaborate with stakeholder interfaces (eg
integration/system of systems), as defined in the scope of contract, and may also place requirements on the
Contractor to collaborate in risk management with these stakeholders.
3.7 The scope of contract may include requirements on Contractors to design multiple PSSs to be
operated in a system of systems, eg In the case of a Naval support vessel controlling a set of different
unmanned vehicles (eg surface, sub-surface and air). Technical requirements would apply to each system
(vessel and different unmanned vehicles). This would inform the ISSS and Safety Case Report for each
system, ie each type of unmanned vehicle integrated with the support vessel. Therefore, for a particular
configuration of unmanned vehicles which are integrated with a support vessel, a Safety Case and Safety
Case Report could be constructed for the deployed system of systems.
38
4 Invitation to Tender and Response
4.1 Guidance on how the MOD approaches the compilation of an invitation to tender (ITT) for
generation of the Top Level Safety Requirements can be found in MOD POSMS. Prior to ITT, the MOD will
carry out any necessary tailoring of the Standard. Bidders would then respond to the ITT. Following the
selection, the potential Contractor may negotiate with the MOD and agree further tailoring compliant with this
Standard. The resulting acceptable means of compliance of the selected Contractor will be documented in
the scope of contract and detailed in the Contractors SMP.
4.2 In the lead up to a project ITT, the MOD will identify the required capability for the deliverable PSS,
eg in the URD/SRD. Other key information that the MOD may provide the Contractor, to assist in the
production of a tender response, will be guided by POSMS. This information will also include the initial
definition of the scope of contract.
4.3 The ITT will require the Contractor to provide a compliance statement or matrix against the tailored
requirements. Guidance on tailoring and use of the tailoring compliance matrices is given in Appendix 1 to
this Annex.
4.4 Contractors must note that only the MOD has the authority to tailor this Standard; although this
does not prevent the Contractor proposing alternative means of compliance during the pre-contract
negotiations. It must be understood that a detailed and unambiguous compliance matrix may be a significant
discriminator in selection of preferred bidder and subsequent Contract award.
4.5 A key safety document is the Contractors draft SMP normally included in the ITT response. A draft
SMP is an excellent method of indicating a Contractors safety management capability, understanding and
competence.
4.6 The level of detail to include in a draft SMP or ITT response will be dependent on the scope of
contract and the Top Level Safety Requirements. POSMS provides guidance on what the MOD may require.
Where necessary, the ITT response or draft SMP could also identify:
a) Where there is uncertainty as to the applicable legislation and regulations, eg new materials;
b) Where the Contractor cannot disclose required information, eg Intellectual Property Rights or
International Traffic in Arms regulation, the Contractor will need to define how such aspects are to
be addressed.
c) Where GFX will need to be incorporated, the Contractors requirement for access to relevant safety
information.
4.7 The MOD may request other preliminary deliverables to support an ITT response, such as:
a) Draft Hazard Log Report: particularly if the PSS is established, eg using Military off-the-shelf
(MOTS) or COTS.
b) Draft Safety Case Report or Safety Assessment Report: where an outline safety argument and type
of evidence is a key discriminator for selection.
c) Risk Register: where uncertainties regarding the safety requirements that might significantly impact
Contract timescales or cost are identified.
4.8 It will be for the MOD to determine if Contractors ITT response to safety would be considered
acceptable.
5 Scope of Analysis
5.1 This Standard recognises that, in modern acquisition scenarios, there may be a difference between
what PSS the Contractor delivers and what they are required to analyse. The introduction of the scope of
analysis in this Standard is intended to enable this difference to be articulated.
39
5.2 The scope of analysis defines the Contractor’s responsibilities with regards to the application of the
safety analysis processes, ie scope of hazard and safety analysis. The scope of analysis will typically cover
everything which can affect the safety of the PSS, including any ancillary material which could influence
safety; eg operating procedures. This Standard identifies three levels of analysis:
a) Full, where the scope of analysis is for the PSS, plus safety-relevant ancillary material. This is
appropriate where the Contractor has sufficient knowledge and visibility of the in-service operation
of the PSS to be able to carry out the full safety process up to, but excluding, acceptance of Risk to
Life, which can be undertaken only by MOD.
b) Enhanced, where the scope of analysis exceeds what the Contractor is supplying. This may occur
when the Contractor is a system integrator, or where the MOD specifically contracts for additional
elements, such as legacy systems to be analysed. In some cases the Contractor may undertake
the complete safety analysis of a PSS which they did not produce.
c) Reduced, where the scope of analysis is less than what the Contractor is supplying. This might
occur if it is more efficient for the MOD to contract a system integrator to undertake the overall
system safety management of a number of PSSs, not all of which are being developed by the
Contractor.
5.3 At the ITT stage, the MOD will identify the level of expected scope of analysis but the level may
change as it is partly dependent on the Contractor's knowledge and response to the ITT. The Contractor will
need to ensure that this is reflected in the safety activities documented in the SMP. It may be necessary to
modify the scope of analysis as the Contract matures, and this may require amendment to the Contract.
6 Scope of Supply, Documentation
6.1 This Standard mandates certain safety-related documentary deliverables; these form a major
element of the scope of supply. The MOD will specify deliverable documents, and their links to project
milestones, in the ITT or Contract. The SMP must detail the form and content of the deliverables and the
delivery schedules.
6.2 The Data Item Descriptions (DIDs), that includes description, purpose and format of safety
document deliverables, are at Annex C. These DIDs may be tailored by MOD either to meet PSS
requirements or where an agreed alternative, acceptable means of compliance is offered by the Contractor.
6.3 Under certain circumstances, such as an emerging operational requirement for the PSS, the MOD
may require additional documentary deliverables. It may be possible for these to be extracted from the
information set. An example is a Failure Modes and Effects Analysis for a low-level component such as a
valve or a human factors analysis for a new operating procedure. It would be expected that MOD will ask for
additional safety-related documentary deliverables only where they have a clear role in supporting safety of
the Defence activity, eg for a system integrator or a training facility.
7 Use of Other Standards
7.1 This Topic provides guidance on how open or other standards, both civil and military, could be
used. MOD may allow Contractors, as part of an agreed means of compliance, to use such alternative
standards.
7.2 It is likely that other standards will not address the MOD’s specific requirements. It will therefore be
necessary for MOD and/or Contractors to undertake a gap analysis of the standards that they intend to use
against the requirements of this Standard, eg against the requirements of MIL-STD-882 compliant PSS. It
would then be necessary to identify how any requirement shortfalls would be addressed in the SMP. The
issues that could be identified include:
a) Omissions; such as the absence of a key requirement, eg independent safety audit.
b) Conflicts; where some standards may require safety features to be incorporated which conflict with
operational necessity and where degraded functionality would be unacceptable.
40
c) Additions; where other standards impose Safety Requirements over and above those required by
this Standard, due to the limited way the military deploys the PSS, that could result in unnecessary
effort and cost.
8 Tailoring
8.1 This Standard has to address a wide range of PSS acquisition scenarios. As a consequence there
may be some clauses of this Standard which are not applicable in a particular scenario, or there may need to
be additional information on how to interpret this Standard, for a given Contract. This is referred to as
tailoring. Guidance on tailoring is given in Appendix 1 to this Annex, with a Generic Tailoring and Compliance
Matrix being provided in Appendix 2. Domain specific tailoring and compliance matrices are also included in
the Appendices and may also be delivered through MOD regulations and applied at ITT or in the Contract.
Appendices:
1 Tailoring
2 Generic Tailoring and Compliance Matrix
3 Defence Air Environment Tailoring and Compliance Matrix
41
42
APPENDIX 1 TO ANNEX B – TAILORING GUIDANCE
1 Introduction
1.1 Tailoring is the process of identifying the range and depth of safety activities that should be carried
out and depends on the scope, size, complexity, lifecycle phase and contractual arrangements of any given
project. This Standard has to address a wide range of acquisition scenarios and a result there will be clauses
of this Standard which require tailoring. Whilst tailoring is the prerogative of the MOD, it may be influenced by
a Contractors alternative, acceptable means of compliance for a given Contract.
1.2 It is expected that the proposed tailoring compliance matrix will be documented in the scope of
contract at ITT and, captured in a draft SMP or agreed between the preferred bidders and MOD prior to
Contract award. Guidance is given here on how this Standard might be tailored by the MOD, or where such
tailoring could be proposed by a Contractor during their Contract negotiations.
1.3 This Standard may be tailored by the MOD in the following ways:
a) Remove – removal of a clause or clauses from the Contract; this is likely to be at the whole
paragraph level, eg deleting all clauses in paragraph 16 if there is no contractor provided service.
However, smaller scale deletions of clauses and sub-clauses are possible but all must be
justifiable.
b) Replace – replacing a clause with an alternative acceptable means of compliance that meets the
original safety requirement, eg Domain Regulatory requirement.
c) Make Specific – revise a clause in order to address a particular acquisition scenario, or to address
a MOD specific capability requirements or Domain regulation. Some sub-clauses contain should
statements and may be added as Mandatory sub-clause by substitution of should with shall in the
compliance matrix for the Contract.
d) Add – additional requirement clauses or sub-clauses may be added to this Standard. This may be
particularly relevant where there are Domain Regulatory requirements, however, these clauses
should be documented in the SMP and documentary deliverables as appropriate.
1.4 The clauses in the Standard shall remain extant and tailoring will be reflected in the Domain
Compliance, Applicability/Tailoring Statement, Alternative Means of Compliance or Level of Compliance
fields of the Tailoring Compliance Matrix and will be defined by the MOD and reflected in the Contract eg a
Domain Regulator specific compliance matrix.
1.5 Where Contractors supply a draft SMP, delivered in response to the ITT, it is important that it
incorporates the Contractors responses to any MOD tailoring and their compliance with this Standard as
reflected in the ITT. The tailoring compliance matrix could be used to identify compliance by the bidder. The
bidder should indicate Full, Partial or Non-compliance against each clause with reasoning, justification or
proposed alternative means of compliance and their rational documented in a draft SMP. Post bid selection,
the rational for tailoring and the acceptable means of compliance, agreed by the MOD, will be documented in
the SMP, ISSS and Safety Case Report.
1.6 Appendix 2 of this Annex provides a Tailoring Matrix which advises the level of tailoring allowed for
each clause. Where a clause is stated as being Mandatory, there will need to be a robust, justified reason for
tailoring, eg compliance with Domain Regulatory requirements.
43
44
APPENDIX 2 TO ANNEX B - GENERIC TAILORING AND COMPLIANCE MATRIX
Applicability
Level of
Para Defence Standard 00-56 Part 1 /Tailoring Alternative Means of Compliance
Compliance
Statement
Safety Management System
6 Clause Extant
Mandatory.
Safety Management Plan
6.1 Clause Extant Partially Tailorable.

Safety
Management Plan
might already exist.
6.1.1 Clause Extant Tailorable. MOD
might agree use of
other standard.
6.1.2 Clause Extant Tailorable.
Agreement
6.2 Clause Extant Mandatory.
Review and Update
45
Applicability
Level of
Compliance
Statement
Progress Reports
Deviation from Requirements
a) Clause Extant Tailorable.
b) Clause Extant Tailorable.
Legislation, Regulations, Standards and

Policy
7.2 Clause Extant Tailorable. This
may be undertaken
by MOD or another
3rd Party.
7.2.1 Clause Extant Mandatory
7.2.2 Clause Extant Tailorable. This

may be undertaken
by MOD or another
3rd Party.
Sub-Contracting
46
Applicability
Level of
Compliance
Statement
Multiple Deliverables
Information Management
7.5.1 Clause Extant Mandatory.
47
Applicability
Level of
Compliance
Statement
Documentary Deliverables
7.6 Clause Extant Tailorable. MOD

might agree
another set of
deliverables
a) Clause Extant Tailorable
b) Clause Extant Tailorable
c) Clause Extant Tailorable
d) Clause Extant Tailorable
e) Clause Extant Tailorable
f) Clause Extant Tailorable
g) Clause Extant Tailorable
h) Progress Reports. Tailorable
Agreement of Deliverables
48
Applicability
Level of
Compliance
Statement
Safety Organisation

MOD might not
require
identification of
individuals.
Safety Committees

There might not be
any existing Safety
Committees.
8.2.1 Clause Extant Partially Tailorable.
There might not be
any existing Safety
Committees.
There might not be
any existing Safety
Committees.
There might not be
any existing Safety
Committees.
49
Applicability
Level of
Compliance
Statement
Contractor Safety Audit Independence

MOD may contract
a 3rd party to
undertake or
manage such
activities.
Competencies
9 Interfaces
Organisational Interfaces
50
Applicability
Level of
Compliance
Statement
Technical Interfaces
External Interacting Interfaces
10 Safety Audits
Audits and Reports
10.1 Clause Extant Tailorable. MOD

may contract a 3rd
party to undertake
or manage such
activities.
10.1.1 Clause Extant Tailorable. MOD
may contract a 3rd
party to undertake
or manage such
activities.
Independent Safety Audit
51
Applicability
Level of
Compliance
Statement
Remedial Action
SAFETY ENGINEERING
11 Safety Requirements, Hazard and Risk

Analysis
Safety Requirements
Safety Requirements Management
52
Applicability
Level of
Compliance
Statement
Hazards and Accidents

MOD may contract
a 3rd party to
undertake or
manage such
activities.
Hazard Tracking

MOD may contract
a 3rd party to
undertake or
manage such
activities.
MOD may contract
a 3rd party to
undertake or
manage such
activities
Design for Safety
53
Applicability
Level of
Compliance
Statement
11.5.2 Clause Extant Partially Tailorable

MOD might agree
different strategies.
a) Elimination.
b) Clause Extant
c) Clause Extant
Safety Analysis
Failure Modes
54
Applicability
Level of
Compliance
Statement
MOD may contract
a 3rd party to
undertake or
manage such
activities.

MOD may contract
a 3rd party to
undertake or
manage such
activities.
55
Applicability
Level of
Compliance
Statement
Risk Estimation

MOD may contract
a 3rd party to
undertake or
manage such
activities.
Risk and Compliance Evaluation

MOD may contract
a 3rd party to
undertake or
manage such
activities.
56
Applicability
Level of
Compliance
Statement
Satisfaction of Requirements

MOD may contract
a 3rd party to
undertake or
manage such
activities.
MOD may contract
a 3rd party to
undertake or
manage such
activities.
Health Monitoring and Reporting System
12 Clause Extant Tailorable.
13 Safety Reporting
Information Set Safety Summary
57
Applicability
Level of
Compliance
Statement
Safety Case

MOD may contract
a 3rd party to
undertake or
manage such
activities.
MOD may contract
a 3rd party to
undertake or
manage such
activities.
58
Applicability
Level of
Compliance
Statement
Safety Case Reports

MOD may contract
a 3rd party to
undertake or
manage such
activities.
MOD may contract
a 3rd party to
undertake/manage
such activities.
Build State Definition
Change Control
Planning for Change
59
Applicability
Level of
Compliance
Statement
Safety of Changes

MOD may contract
a 3rd party to
undertake/manage
such activities
Safe Update
Monitoring Change
14.6 Clause Extant Partially Tailorable

MOD may contract
a 3rd party to
undertake/manage
such activities.
60
Applicability
Level of
Compliance
Statement
MOD may contract
a 3rd party to
undertake/manage
such activities.
Incorporating Change
SAFETY IN-SERVICE
Management of Safety-Related In-Service

Data
Monitoring and Reporting
61
Applicability
Level of
Compliance
Statement
In-Service Data Analysis
Remedial Action
Safety Case Report
Service Provision Planning
62
Applicability
Level of
Compliance
Statement
Risk Management
63
64
APPENDIX 3 TO ANNEX B - DEFENCE AIR ENVIRONMENT TAILORING AND COMPLIANCE MATRIX
Applicability
Defence Standard 00-56 Part 1 Level of
Para /Tailoring Alternative Means of Compliance
MAA DAE Compliance Compliance
Statement
For all DAE contracts where clauses containing “should” are

invoked, the “should” term is the permissive verb to allow the
contractor the opportunity to consider an alternative
approach in meeting the clause.
Safety Management System
6 Clause Extant Mandatory.
6.01 The Contractor SMS shall meet the requirements of RA1200. Mandatory.
Safety Management Plan

MOD might
agree use of
other
standards.
6.1.4 Clause Extant. Tailorable.
6.1.5 The Contractor shall ensure that the SMP covers the work of Mandatory.
all Sub-Contractors, including the mechanisms that the
Contractor will use for oversight of Sub-Contractor work,
such as auditing.
65
Applicability
Statement
6.1.8 The contractor shall have and implement an SMS, but where Mandatory.
the Contractor does not have safety engineering system in
place, the SMP should address the core principles of
systems engineering.
Agreement
Review and Update
6.3.1 The Contractor shall review the SMP on a regular basis, Mandatory.
depending on the scale and stage of the Contract or on
significant events, eg change in supplier, introduction of a
new technology or changes to risk mitigation strategy, and
agree the SMP changes with the MOD before
implementation.
6.3.2.1 Where changes to design are made they shall be in Mandatory.

accordance with the MAA RA5000 DME Series.
66
Applicability
Statement
Progress Reports
6.4.1 Clause Extant Mandatory
Deviation from Requirements
7.1.2 In the response to an ITT, the tenderer shall specify how Mandatory
they intend to meet the requirements of this Standard.
7.1.3 The tenderer shall provide a compliance matrix for this Mandatory.
Standard with their response to the ITT, showing:
a) Which clauses will be or have been fully complied with. Mandatory.
b) Which clauses will not be or have not been fully complied Mandatory.
with, and why, including a description of any alternative
approaches and why they are acceptable.
7.1.4 For any intended deviations, the tenderer shall indicate how Mandatory.
their approach will meet the intent of this Standard or explain
why compliance is not considered to be necessary.
7.1.5 At Contract award, the compliance matrix will form part of the Mandatory
scope of contract and the Contractor shall agree any
variance with the MOD throughout the life of the Contract.
67
Applicability
Statement
Legislation, Regulations, Standards and Policy
7.2.1 The Contractor shall work with the MOD to identify and Mandatory.
agree relevant MOD policy appropriate to the scope of
supply and scope of analysis, addressing the domain and the
technology used.
7.2.2 The Contractor shall agree with the MOD all legislation, Mandatory.
regulations and standards applicable to the scope of supply
and scope of analysis, addressing the domain and the
technology used.
Sub-Contracting
7.3.3 The Contractor shall identify deliverables and audit Mandatory.

mechanisms to provide assurance that the requirements of
the Standard are met throughout the supply chain, and
record the evidence to demonstrate compliance in the
information set.
Multiple Deliverables
68
Applicability
Statement
7.4.2 Safety Assessment Reports and Information Set Safety Tailorable.

Summaries (ISSSs) should be produced for each related
PSS so that they are “self-contained” from a safety
perspective
Information Management
7.5.4.1 The contractor shall preserve airworthiness and air safety Mandatory.
information set for the duration of the PSS lifecycle plus five Consult with
years, in accordance with RA1335 or RA1225 and RA4350.” MOD re
validity of
referenced
RAs
7.5.4.2 This airworthiness and safety information should be passed Tailorable.

to the MOD for archiving.
69
Applicability
Statement
7.6 Documentary Deliverables Tailorable.

MOD might
agree another
set of
deliverables
a) Command Summary. Tailorable.
The Release To Service documentation (RTS, ALWRC &

AERC RA1300, RA1345 & RA1350 refer) shall not be
subverted by a Command Summary.
In the provision of services a Command Summary should be

appropriate, however great care should be taken in all other
circumstances on invoking this clause.
b) Information Set Safety Summary. Tailorable.
c) Safety Audit Plan. Mandatory.
d) Safety Audit Report. Mandatory
e) Safety Assessment Report. Mandatory.
f) Hazard Log Report. Mandatory.
g) Safety Management Plan. Mandatory.
h) Progress Reports. Tailorable.
70
Applicability
Statement
i) Technical Information as per RA4350 Mandatory.
Agreement of Deliverables
7.7.2 The Contractor shall define the PSS to include all relevant Mandatory.
elements across the Defence Lines of Development, as
Contracted.
71
Applicability
Statement
7.8 Conflict Resolution Mandatory.
The Contractor shall agree with the MOD, a process for

conflict resolution and document it in the SMP.
Notes:
i. Given the different duties that are held by the

Contractor and MOD, and the absence of any absolute
definition of ‘safe’, it is possible that in the course of
addressing their respective duties there will be a
disagreement over whether the PSS has achieved the
appropriate safety objectives. Disagreement may be of two
general types:
a) Those where the MOD PT is dissatisfied with the

safety performance of the Contractor and is outside the
scope of this Standard.
b) Those where the Contractor is concerned over

safety decisions taken by the MOD.
ii. Neither party may over-rule the other and force a

decision that is contrary to their duty
7.8.1 The conflict shall be raised to the safety committee with Tailorable
safety representatives from both the Contractor and MOD
present with intent to resolve the conflict.
7.8.2 In the case that issues cannot be resolved at the safety Tailorable
committee level, the conflict shall be escalated to the
Contractor and MOD senior management level for resolution.
72
Applicability
Statement
7.8.3 Where every attempt to resolve the issue at senior Tailorable

management level has been taken, and there remains a
disagreement, the issue shall be formally recorded and
copied to the relevant Duty Holder to review of the actions
proposed by the Contractor and/or MOD representatives.
7.8.4 If at the end of this process a Contractor is not satisfied that Tailorable
their safety duties are appropriately addressed they should
raise a letter to the Regulator, Duty Holder and PT detailing
the perceived safety issue and request a formal response.
Note: Any process for further conflict resolution is

outside the boundaries of this Standard
Safety Organisation
8.1.3 The Contractor shall keep the definition of roles and Mandatory.
responsibilities of those individuals responsible for safety up
to date.
8.1.4 The Contractor shall identify and record, in the information Mandatory.
set, competency requirements for each role.
73
Applicability
Statement
Safety Committees
8.2.4 Where there is an MOD Safety Committee, the Contractor Mandatory.

shall participate in its work.
8.2.7 Where there is concurrent work on interfacing or interacting Mandatory.

PSS, the Safety Committee shall collaborate with other
Safety Committees to manage interfaces, and shall refine
the scope of analysis if necessary to minimise gaps in
analysis, or overlaps and duplication of effort.
8.2.9 The Contractor shall record all their support to the Safety Mandatory.
Committee and safety-related meetings.
Contractor Safety Audit Independence
74
Applicability
Statement
Competencies
8.4.1 The Contractor shall record the evidence of competence, on Mandatory.

an individual, team and organisational basis, in the
information set.
8.4.3 Contractors shall ensure that competent personnel are Mandatory.

appointed to all posts that affect safety and confirm details in
the relevant section of the SMP and in the Safety
Assessment.
9 Interfaces
Organisational Interfaces
Technical Interfaces
75
Applicability
Statement
External Interacting Interfaces
10 Safety Audits
Audits and Reports
10.1 The Contractor shall carry out safety audits as specified in Mandatory.
the SMP, to assure the implementation of the SMS.
10.1.2 All audit findings shall be assessed for significance and the Mandatory.
need for remedial action identified.
10.1.3 The Contractor shall ensure that all Sub-Contract activity is Mandatory.
audited.
Independent Safety Audit
Remedial Action
10.3.1 The Contractor shall agree the remedial actions with the Mandatory.
MOD through the Safety Committee, and any other relevant
stakeholders, as appropriate.
76
Applicability
Statement
10.3.2 The Contractor shall update the SMP, if appropriate, to Mandatory.

reflect the agreed remedial actions.
SAFETY ENGINEERING
11 Safety Requirements, Hazard and Risk Analysis
Safety Requirements
Safety Requirements Management
77
Applicability
Statement
11.2.3 The Contractor shall record the evidence such that it can be Mandatory.
included in, or referenced from, the Hazard Log.
Hazards and Accidents
11.3.1 The Contractor shall employ systematic analysis processes Mandatory.

for identification of hazards and accidents as defined in the
SMP.
11.3.2 The Contractor shall ensure that human factors are Mandatory.
considered where they may be a contributory cause of a
hazard.
Hazard Tracking
11.4.2 The Contractor shall ensure that the Hazard Log and Hazard Mandatory.
Log Reports are delivered as defined in the SMP.
78
Applicability
Statement
11.4.3 The Contractor shall update the Hazard Log throughout the Mandatory.
Contract to ensure that it accurately reflects the status of the
design, hazard analysis, safety analysis and safety
engineering activities.
Design for Safety
11.5 The Contractor shall undertake the design of the PSS so as Mandatory.
to meet all Safety Requirements in accordance with the
RA5000 DME Series.
a) Elimination. Tailorable.
b) Reduce the Risk to Life by engineering means. Tailorable.
Note Risk to Life in the DAE is defined in MAA02.
c) Clause Extant Tailorable.
79
Applicability
Statement
11.5.8 The Contractor shall record the results of applying the Mandatory.
mitigation strategies and ALARP, the evidence that Safety
Requirements are met, and any residual shortfalls against
Safety Requirements in the information set.
Safety Analysis
Failure Modes
80
Applicability
Statement
11.7.6 The Contractor shall ensure that human factors are Mandatory.
considered where they may be a contributory cause of a
failure mode (see Def Stan 00-250).
11.7.10 The Contractor shall update information on identified failure Mandatory.

modes throughout the Contract to ensure that it accurately
reflects the status of the design, safety analysis and safety
Risk Estimation
81
Applicability
Statement
11.8.3 The Contractor shall record assumptions, data, judgments Mandatory.

and calculations underpinning the risk estimation in the
information set, such that they can be reviewed and
reconstructed.
Risk and Compliance Evaluation
11.9.1 The Contractor shall evaluate risks against the criteria Mandatory.
agreed in the SMP.
11.9.2 The Contractor shall record all assumptions, data, Mandatory.

judgements and calculations underpinning the evaluations in
the information set, such that they can be reviewed and
reconstructed.
Satisfaction of Requirements
11.10.2 The Contractor should identify the most effective method, or Tailorable.
methods, for showing satisfaction of requirements, or
providing counter-evidence, and include this information in
the SMP.
Note in the DAE this may include Loss Models.
82
Applicability
Statement
Health Monitoring and Reporting System
12 Clause Extant Tailorable.
13 Safety Reporting
Information Set Safety Summary
Safety Case
Safety Assessment
13.2 The Contractor shall produce a Safety Assessment (as Mandatory.

defined in MAA02) or Safety Assessments for a PSS as
defined in the SMP.
13.2.1 The Contractor shall ensure that the Safety Assessment Mandatory.
consists of a structured argument, supported by a body of
evidence, that provides a compelling, comprehensible and
valid case that a system is safe for a given application in a
given environment.
83
Applicability
Statement
13.2.2 The Contractor shall ensure that the evidence for the Safety Mandatory.
Assessment is drawn from the information set.
identifies how to address any residual shortfalls in meeting
Safety Requirements.
13.2.6 The Contractor shall develop, maintain and refine the Safety Mandatory.
Assessment as defined in the SMP and in developing the
Safety Assessment the Contractor shall address the full
lifecycle (CADMID/T) of the PSS.
13.2.7 The contractor shall provide objective evidence. If production Mandatory.

of objective evidence is not practicable, an alternative form of
acceptable evidence shall be agreed with the MOD.
13.2.9 The Contractor should demonstrate that the arguments and Tailorable.
evidence in Safety Assessments are sound, comprehensive
and trustworthy.
13.2.11 The Contractor should develop, maintain and refine the Mandatory.
Safety Assessment through the life of the Contract.
13.2.12 The Contractor should provide evidence of competency of Mandatory.

those whose work could impact safety and confidence in the
Safety Assessment.
84
Applicability
Statement
13.2.13 The Contractor should ensure that any related Safety Mandatory.
Assessments or information sets already in existence and
identified in the scope of analysis are utilised and integrated
as necessary.
Safety Case Reports
Safety Assessment Reports
13.3 The Contractor shall produce a Safety Assessment Report Mandatory.

or Reports as defined in the SMP.
13.3.1 The Contractor shall produce Safety Assessment Reports Mandatory.

that incorporate the key elements of the safety argument and
references to evidence so that, in principle, it would be
possible to access the complete Safety Assessment,
starting from the Report, or counter-evidence where it has
been identified.
13.3.2 Where there are shortfalls in the evidence the Contractor Mandatory.
shall ensure that the Safety Assessment Report provides
the rationale for operating the PSS, and the ways of
mitigating the residual risk.
Report contains information on assumptions and limitations
regarding the safe use of the PSS.
13.3.5 The Contractor should ensure that any related Safety Tailorable.
Assessment Reports or ISSSs already in existence and
identified in the scope of analysis are utilised and integrated
as necessary.
85
Applicability
Statement
Build State Definition
Change Control
Planning for Change
Safety of Changes
14.4.2 The Contractor shall review and update the Safety Mandatory.
Assessment and Safety Assessment Report, as defined in
the SMP, to ensure that they remain valid.
86
Applicability
Statement
14.4.4 The Contractor shall update the hazard analysis and safety Mandatory.
analysis as necessary for all changes, both intended and
unplanned, updating the information set accordingly.
14.4.5 Following any change which has an adverse effect on safety, Mandatory.
the Contractor shall propose, agree and implement further
revisions to the design so as to preserve safety.
14.4.5.1 For management of modifications to air systems, the Mandatory.

Contractor shall implement the procedures laid down in the
RA5000 DME Series.
Safe Update
14.5.2.1 Air systems and air system components shall only be Mandatory.
modified using the processes laid down in the RA5000 DME
Series.
87
Applicability
Statement
Monitoring Change
Incorporating Change
14.7.2 The Contractor shall assess supplied PSS, together with Mandatory.
installation instructions, and develop and implement plans for
safe installation and maintenance.
14.7.4 Where temporary modifications have been made to manage Mandatory.

risk the Contractor shall ensure that they are removed once
a permanent resolution has been implemented.
SAFETY IN-SERVICE
Management of Safety-Related In-Service Data
88
Applicability
Statement
Monitoring and Reporting
15.2.1 The Contractor shall review the Safety Assessment, in the Mandatory.
light of the recorded data to identify areas where operations
vary from predictions or assumptions, eg the actual Risk to
Life is significantly higher than the estimated Risk to Life, or
a PSS is operated outside declared limitations.
15.2.2 The Contractor shall sentence the results of analysis of the Mandatory.
data and the review of the Safety Assessment to determine
situations which indicate the need for remedial action and,
once agreed with the MOD, shall implement those actions
within their sphere of responsibility.
15.2.4 The Contractor shall define and operate a process for Mandatory.
collecting, analysing and documenting safety-relevant in-
service data including but not limited to usage and
environment.
collecting, analysing and documenting defect or failure data.
collecting incident, accident and near miss reports, and
comparable data from other operations available to the
Contractor or supplied by the MOD.
89
Applicability
Statement
15.2.6.1 The Contractor shall comply with aviation reporting process Mandatory.
and procedures, as defined in the scope of contract,
including but not limited to:
Narrative Fault Reporting (F760);
Unsatisfactory Feature Reports (F765);
Serious Fault Signals;
Defence Aviation Safety Occurrence Report.
In-Service Data Analysis
15.3.1.1 For Air Systems and their components, as defined in MAA02, Mandatory
the Contractor shall liaise with the MOD to establish, or
interface to, a Failure Reporting Analysis and Corrective
Action Systems (FRACAS) or equivalent, to ensure that
support is based on as accurate and timely data from
operations, as is practicable.
90
Applicability
Statement
15.3.4 Where the Contractor supports in-service PSS which are in Mandatory.
use by multiple stakeholders, the Contractor shall, so far as
is reasonably practicable, use information relating to the PSS
to efficiently and effectively manage safety.
Remedial Action
15.4.3 Remedial action shall be carried out iaw RA5000 DME Mandatory
Series for modifications and all remedial actions shall be
carried out with the agreement of the Aviation Duty Holder or
Accountable Manager (Military Flying) as defined in MAA02.
Safety Case Report
Safety Assessment Report
16.1 The Contractor shall produce a Safety Assessment Report Mandatory.

and Command Summary and deliver them to the MOD, and
any relevant Regulators, for approval before commencement
of services.
Note In the provision of services, a Command Summary

should be appropriate. However great care should be taken
in all other circumstances on invoking this clause.
91
Applicability
Statement
16.1.1 The Contractor shall maintain the Safety Assessment, Mandatory.

Safety Assessment Report and Command Summary so
they are accurate representations of the service.
16.1.1.1 The Release To Service documentation (RTS, ALWR &

AFERC RAs 1300, 1345 & 1350 refer) shall not be
subverted by a Command Summary.
16.1.2 Not Applicable Tailorable.
16.1.2.1 For delivery of services, the Contractor should produce Tailorable.

Command Summaries to inform the Aviation Duty Holder or
Accountable Manager (Military Flying) of the risks they will
be accepting.
16.1.3 The Contractor shall provide information to support domain Mandatory.

specific processes providing essential information for the
duty holder responsible for the service to manage Risk to
Life.
Service Provision Planning
16.2 Clause Extant s. Mandatory.
16.2.2.1 Where the service provided is airfield related the Contactor Tailorable.
should comply with the provisions of the RA1400 Series.
92
Applicability
Statement
Risk Management
16.3 The Contractor shall support the MOD in managing predicted Mandatory.
or emergent Risk to Life arising from hazards and accidents
associated with the service, according to the ALARP
principle, throughout the Contract life, and as defined in the
Safety Assessment Report.
93
94
ANNEX C
DATA ITEM DESCRIPTIONS
1 Defence Standard 00-56 has not previously had Data Item Descriptions (DIDs) to support the
definition and production of deliverables. The Def Stan 00-56 DIDs are intended to assist Contractors in
determining the scope of supply of the project documentation; they have a similar purpose to DIDs in MIL-
STD-882 but not should be considered as directly equivalent.
2 The format, content and frequency of deliverable DIDs will be agreed with the MOD and form part
of the scope of supply. Domain specific regulations may expand or reduced the intent of the DIDs, eg a
Safety Case Report and ISSS may be replaced by a Safety Assessment Report. The DIDs contain shall and
should statements and these are intended to identify the Mandatory and optional scope and content of
deliverables. Where possible, Contractors should use civil, open and other standards as a basis of meeting
the intent of the DIDs. The SMP will define what are the relevant deliverables and agreed DID tailoring.
3 DIDs are at the Appendices as follows:
a) Appendix 1 Command Summary.

b) Appendix 2 Information Set Safety Summary.
c) Appendix 3 Safety Audit Plan.
d) Appendix 4 Safety Audit Report.
e) Appendix 5 Safety Case/Safety Assessment Report.
f) Appendix 6 Hazard Log Report.
g) Appendix 7 Safety Management Plan.
h) Appendix 8 Progress Reports.
95
96
APPENDIX 1 TO ANNEX C
DID - COMMAND SUMMARY
1 Purpose
1.1 This DID sets out requirements for a Command Summary in support of Defence Standard 00-56.
This DID is intended to identify the scope and content of the Command Summary.
1.2 The Command Summary is a stand-alone summary of the Safety Case/Safety Assessment Report
that provides a focused report for commanding officers or managers.
1.3 The purpose of a Command Summary is to inform the commanding officer, manager or duty holder
of:
a) The safe operating envelope of the PSS.
b) Any in-service limitations imposed by design parameters, certification, and risk assessment.
c) The safety implications of any unusual aspect of the PSS’s design.
d) Information that may assist in making balanced, risk-based decisions should there be an
unforeseen requirement to operate the PSS outside the design envelope.
e) Information that may assist in making balanced, risk-based decisions about the safety risks
associated with a larger system of systems incorporating this PSS. This should include, but not be
limited to known Concept of Operations and Statements of Operating Intent and Usage.
2 Scope of Applicability
2.1 The Command Summary should be produced in accordance with the SMP together with the Safety
Case/Assessment Report when:
a) The scope of analysis for the PSS either impacts or is impacted by in-service use.
b) Tasked by the duty holder (or their agent).
c) When required by the Contract for the scope of supply.
2.2 It will capture key information necessary to enable in-service commanding officers and managers
to have an understanding of keys risks regarding the PSS being used.
2.3 Other areas may also be addressed in the summary, for example the environmental case which
might then lead to a title of ‘Command Safety and Environmental Summary’ or another variation.
2.4 Commanding officers and managers need not be given the full Safety Case or even the full Safety
Case Report, since they should not need to know all the information contained in it.
2.5 In the DAE, The Release To Service documentation (RTS, ALWRC & AERC RA1300, RA1345 &
RA1350 refer) must not be subverted by a Command Summary. In the provision of services a Command
Summary may be appropriate.
3 Application/Interrelationship
This DID contains the content and instructions for preparing a Command Summary as specified within the
SMP and in conjunction with the Safety Case Report and Information Set Safety Summary.
97
4 Preparation Instructions
4.1 The Command Summary should address the following topics:
a) Scope (PSS and in-service use).

b) In-service Limitations.
c) Assumptions made in the Safety Case.
d) Unusual Aspects of the PSS’s Design.
e) Safety risks in use and recommended minimisation techniques.
f) Level of safety provided.
g) Emergency responses.
4.2 The Command Summary may be prepared under an alternative heading provided that it addresses
the content and controls required by this DID.
4.3 Scope (PSS and in-service use)
4.3.1 The Command Summary shall clearly and exactly identify the PSS and operations within its scope
including their version and modification status.
4.3.2 A Command Summary may address more than one PSS and/or more than one
version/modification state provided that the scope is clear.
4.4 In-Service Limitations
4.4.1 The Command Summary shall clearly and exactly identify the operating environment and/or
operations within its scope. This requires the provision of intended in-service scenarios such as Concept of
Operations or a Statement of Operational Intent and Usage.
4.4.2 The Command Summary shall identify and specifically exclude any in-service scenarios that are
not addressed but might otherwise be expected to occur.
4.4.3 The Command Summary shall identify any in-service limitations on the PSS from any authoritative
source (e.g. a Safety Committee).
4.5 Assumptions made in the Safety Case/Safety Assessment.
All assumptions used within the Safety Case/Safety Assessment should be identified and recorded in the
Command Summary.
4.6 Unusual Aspects of the PSS Design
The Command Summary shall clearly identify any aspects of the PSS’s design that affect safety in a manner
that could be regarded as unusual or unanticipated, eg Cyber attack.
4.7 Safety Risks In Use and Recommended Minimisation Techniques
4.7.1 The Command Summary shall address all of key safety risks of the PSS when used in respect of
the in-service limitations and provide recommendations for minimising those risks.
4.7.2 The Command Summary shall provide information that may assist in making balanced, risk-based
decisions should there be an unforeseen requirement to operate the PSS outside the design envelope.
4.7.3 The Command Summary shall provide information that may assist in making balanced, risk-based
decisions about the safety risks associated with a larger system of systems incorporating this PSS.
98
4.8 Level of Safety Provided
4.8.1 These aspects shall be addressed in a concise but comprehensive manner using text, illustrations,
tables etc to convey the level of safety to a commanding officer or manager.
4.8.2 The Command Summary shall clearly identify requirements to be met under all foreseeable
circumstances and provide recommendations that will generally reduce safety risk.
4.9 Emergency Response
4.9.1 The Command Summary shall provide information for addressing foreseeable emergency
situations.
4.9.2 The Command Summary should provide plans that cover emergency situations including, but not
limited to, defining standard operating procedures, resourcing and oversight.
5 Control Requirements
5.1 The Command Summary should be created, held and managed under an appropriate configuration
management system, which should be specified in the SMP.
5.2 Approval of the Command Summary should be as defined within the SMP.
5.3 The Command Summary shall be a formally controlled document, or part of a formally controlled
document, with an issue number and date of issue.
5.4 The Command Summary should be updated whenever the Safety Case or Safety Assessment
Report is re-issued through the life of the PSS.
99
100
DID - INFORMATION SET SAFETY SUMMARY
1 Purpose
1.1 This DID sets out requirements for an Information Set Safety Summary (ISSS) in support of
Defence Standard 00-56. This DID is intended to identify the scope and content of the ISSS. The concept,
use and applicability of ISSS and its relationship with Safety Case Reports are discussed in Annex B.
1.2 The ISSS draws on the content of the information set to provide a justification of the safety
performance of a PSS, within bounds that are reasonable, given the scope of contract and other factors set
out below.
1.3 The ISSS is intended to provide sufficient information to enable PSS to be safely integrated into a
higher level PSS, or interfaced to a peer PSS. The ISSS summarises the technical properties of the PSS that
are relevant to safe integration/interface where the Contractor cannot directly assess Risk to Life. The ISSS
would be used by the integrator of the higher level PSS to support their safety assessment and contribute to
the top level safety case.
1.3.1 The ISSS supports the production of a Safety Case/Safety Assessment when the PSS is
integrated into a (larger) system, or a system or service integrated into a system of systems, eg for the
DAE in the Air System Safety Case. It may also supplement the Safety Case/Safety Assessment Report
which is a more specific safety report for a particular in-service use of a PSS.
1.3.2 The ISSS is constrained by the scope of analysis on the information set. A Contractor‘s analysis is
constrained to the limits of their visibility of the intended in-service operation of their PSS, and features that
are inherent in their chosen design approach.
1.3.3 In compiling an ISSS, it is recognised that whilst a Contractor may not be able to determine in
isolation the acceptability of overall safety performance of their PSS, they have a responsibility to provide
sufficient information for others to integrate their PSS in accordance with the Contractor’s design intent to
produce a system that can be operated safely.
2.1 An ISSS is required where the Contract includes the supply of product or service that is to be
installed, or integrated, into a larger PSS.
2.2 There will be cases where a Contractor can assess safety only in terms of the inherent
characteristics of their PSS, such as the use of hazardous materials, risk of electric shock, control of moving
parts. There will be other cases where the Contractor has sufficient knowledge of the intended use that they
can assess safety risks arising from the in-service operation of the PSS. The application of the DID will
require adapting to ensure that the balance of inherent/intrinsic and external/extrinsic risks is appropriate for
the Contract/PSS context. The agreed scope of supply should be documented in the SMP.
This DID contains the content and instructions for preparing an ISSS as specified within the SMP and in
conjunction with the Safety Case/Safety Assessment Report and Command Summary.
4.1 The ISSS should address the following topics:
a) Scope.
b) Identified accidents, hazards and failure modes.
c) Assumptions, dependencies and limitations.
101
d) Context of in-service use.

e) Unusual aspects of the PSS’s design.
f) Safety justification.
4.2 The ISSS may be prepared under alternative topic headings provided that it addresses the content
and controls required by this DID. The content required by the DID may be provided under a number of
documents, or incorporated with other deliverables, provided that the purpose set out above is achieved in a
clear and unambiguous way.
4.3 The ISSS should be assumed to be deliverable unless otherwise stated within the scope of supply.
Preliminary versions of the ISSS may be required as the maturity of the PSS develops. The timing and scope
of preliminary versions should be agreed with the customer and defined within the SMP.
4.4 Scope
The ISSS shall include a scope statement that defines the boundary of the PSS covered by the ISSS, taking
into account the scope of contract, the scope of analysis and the PSS in-service operation. This may be
supported by the relevant Safety Case/Safety Assessment Report and Command Summary if they are
available.
4.5 Identified Accidents, Hazards and Failure Modes
The ISSS should summarise all the potential accidents, hazards and failure modes in the information set that
an integrator may need to take into account when performing the risk analysis during PSS integration. This
should include those that have been sentenced as low risk and are not identified or recorded in the Safety
Case Report. For example: accidents, hazards or failure modes associated with a capability of the PSS that
is not currently used in-service.
4.6 Assumptions, Dependencies and Limitations
4.6.1 The ISSS should summarise all the assumptions, dependencies and limitations identified in the
information set including those not recorded in the Safety Case Report.
4.6.2 This should include assumptions and dependencies related to valid configurations of the PSS but
not currently used in-service.
4.7 Context of In-Service Use
4.7.1 The ISSS should summarise the current in-service use (the relevant Command Summary should
be used to support this topic).
4.7.2 The ISSS should also summarise capabilities that are accessible but not used in-service. This
should include capability that is inherent, eg functionality included but not used in a COTS PSS.
4.8 Unusual Aspects of the PSS’s Design
The ISSS should summarise any aspects of the PSS that could be considered unusual, particularly those
that are not covered by the Safety Case Report, this may include:
a) Foreseeable misuse of the PSS capability, eg a PSS display function being used in an ad-hoc way
to display information from another source.
b) A security vulnerability that may lead to a safety issue when the PSS is placed in an environment
outside the current in-service Safety Case.
4.9 Safety Justification
4.9.1 The ISSS should summarise safety performance of PSS. It should be not be as extensive as the
safety justification and analysis of the Safety Case Report but include elements that may not be in the Safety
102
Case Report. This should include all the inherent/intrinsic risks that are part of the PSS design but mitigated.
These mitigations may be current limitation of use, valid assumptions in the environment and dependencies
always available in the current PSS in-service use.
4.9.2 The ISSS safety justification must summarise the interface and accessible safety-related capability.
It should include relevant legislation and policy that would be applicable if the PSS capability was outside the
current in-service use, as defined in relevant the Safety Case Report, was accessed.
4.9.3 The ISSS safety justification is a summary and should be succinct and not extensive but must
highlight/summarise all the safety properties identified in the information set, particularly those not in the
Safety Case Report. The ISSS should highlight any potential safety issues if the PSS has further capabilities
or has limitations dependent on operating environment.
4.9.4 The PSS ISSS may provide an essential part of the body of evidence in a system Safety Case.
5.1 The ISSS should be created, held and managed under an appropriate configuration management
system, which should be specified in the SMP.
5.2 The ISSS shall be approved by a suitable authorised representative of the Contractor, in
accordance with the roles and responsibilities defined in the relevant management plan and endorsed by the
Safety Committee.
5.3 The ISSS may address information for more than one PSS type and/or more than one
version/modification state of a PSS, provided that the association of the information specific to the PSS
version under Contract is clear.
5.4 Reasonable access to the information set that underpins the ISSS should be provided to auditors
and others identified by the Contractors SMP as having a legitimate need to access such information for
safety purposes.
103
104
DID - Safety Audit Plan
1 Purpose
1.1 This DID sets out requirements for a Safety Audit Plan in support of Defence Standard 00-56. This
DID is intended to identify the scope and content of Safety Audit Plan.
1.2 A Safety Audit Plan should be produced for every project working to Defence Standard 00-56. A
PSS Safety Audit Plan should be updated regularly and following major project events, eg annual update or
at Preliminary or Critical Design Reviews. Updates of a PSS Safety Audit Plan should be part of the scope of
contract and defined in the SMP.
2.1 The Safety Audit Plan should identify the PSS items subject to Safety Audit( and reference the
relevant PSS SMP. The relevant PSS SMP should be developed such that they can be used to help compile
the Safety Audit Plan with the relevant scope and timing of the required Safety Audits. If there is no agreed
Contractor SMP then the Safety Auditor should use the requirements of this Standard to help determine
scope and timing of Safety Audits in the Safety Audit Plan.
2.2 The Safety Audit Plan should identify all Safety Audit requirements imposed through Contract and
applicable legislation, regulations, and MOD policy and regulations. This should take into account all relevant
jurisdictions; compliance with which may be determined during the Safety Audits.
2.3 The Safety Audit Plan should also set out the assumptions being made by the Safety Auditor with
regard to availability of documents, evidence, etc.
2.4 This Safety Audit Plan DID can be used for CSA and ISA or combined CSA/ISA plans.
This DID contains the content and instructions for preparing Safety Audit Plans. Contractor should consider
the activities in the PSS Project Plans, SMP and related Safety Audit Reports when compiling a Safety Audit
Plan.
4.1 The Safety Audit Plan should address the following topics:
a) Tailoring.
b) Applicable legislation and regulations.
c) Audit strategy.
d) Organisation and responsibilities.
e) Plans and milestones.
f) Analysis methods.
g) Interfaces.
h) Audit Reporting.
4.2 In general it is acceptable for Contractors or ISAs to use their own formats for Safety Audit Plans,
and to use the DID to check the scope and content of their PSS Safety Audit Plan.
4.3 A PSS Safety Audit Plan should be assumed to be deliverable unless otherwise stated within the
scope of supply.
105
4.4 Tailoring
4.4.1 Should this DID require tailoring for a Contractor Safety Audit Plan, then such tailoring should occur
at the Contract Tender / Contract Award stage. Any Independent Safety Audit Plan should be produced as
agreed between the Contractor, MOD and the ISA; this might involve allowing the Contractor to provide
comments on a draft Independent Safety Audit Plan to ensure that the Contractor understands the ISA’s
role, timescales and support requirements.
4.4.2 For small contracts the Contractor Safety Audit Plan could be documented within the SMP rather
than existing as a separate document; for larger contracts, a separate Contractor Safety Audit Plan should
be produced.
4.5 Applicable Legislation and Regulations
4.5.1 The Safety Audit Plan should set out the goals of the Safety Audits, eg compliance with Defence
Standard 00-56. Where a Means of Compliance has been agreed by MOD then the Safety Audit Plan should
show how it will determine that the approach has satisfied the intent of this Standard.
4.5.2 The Safety Audit Plan should identify all Safety Audit requirements imposed through Contract and
applicable legislation, regulations, and MOD policy and regulations. This should take into account relevant
jurisdictions; compliance with which may be determined during the Safety Audits.
4.6 Audit Strategy
4.6.1 The Safety Audit Plan should identify the strategy for meeting the Safety Audit goals and
requirements, eg document selection, desk reviews, sample approach, etc. such that, for Independent Safety
Audits, the level of support required from the Contractor organizations, in terms of personnel and access to
information can be identified and agreed by MOD and the Contractor as part of the scope of contract.
4.6.2 Whereas a CSA would be expected only to undertake Safety Audits of their own organization and
any Sub-Contractors, the ISA may also undertake Safety Audits of the relevant interfacing PSS through
relevant MOD organizations.
4.6.3 For contracts at the early stages of the PSS lifecycle, eg concepts, the Safety Audit Plan should
show how the Safety Auditor will assess the Contractor’s intended safety strategy for the rest of the lifecycle.
4.7 Organisation and Responsibilities
4.7.1 The Safety Audit Plan should identify the Safety Auditors, including the Lead Safety Auditor if an
Audit Team is proposed and justify how their areas of competence align with the PSS being developed /
used by the Contractor.
4.7.2 The Safety Audit Plan should identify those Contractor personnel needed to support Safety Audits;
this should be on a role basis rather than naming individuals.
4.7.3 The Safety Audit Plan should identify those within the Contractor and MOD organizations with
responsibility, authority and accountability for addressing Safety Audit Findings.
4.7.4 The Safety Audit Plan should identify roles outside the Contractor’s organisation, eg key suppliers,
and MOD Stakeholders, eg Regulators which are relevant to those Safety Audit activities.
4.8 Plans and Milestones
4.8.1 The Safety Audit Plan should provide a schedule for all Safety Audit activities and milestones,
showing clearly the link between Safety Audit activities and other activities on the Contract, eg major
milestones such as Preliminary Design Review, Critical Design Review, etc.
4.8.2 The schedule should be updated after each Safety Audit, to take into account Safety Audit Findings
and the need for the Safety Auditor to assess how such findings have been addressed.
106
4.8.3 If the amount of Safety Audit effort is small then CSA schedule could be documented as part of the
overall Contractor’s Project Plan.
4.9 Analysis Methods
4.9.1 The Safety Audit Plan should identify, define and justify the methods to be used for the Safety
Audits, especially if the Safety Audits will include assessment as well as audit activities.
4.9.2 The Safety Audit Plan should record the Safety Criteria as specified by the MOD, rather than
referencing the criteria as documented in the Contractor’s SMP. This is to address those cases where the
MOD and Contractor have not yet agreed the SMP or the Safety Criteria. In such cases the Safety Auditor
should clearly document that this is the current state of affairs.
4.10 Interfaces
4.10.1 The Safety Audit Plan should identify known interfaces to, and dependencies on, other Stakeholder
organisations and define the methods for ensuring co-ordination across interfaces, including how Safety
Audit Findings are to be communicated to other organizations; this would normally be via the MOD.
4.10.2 The Safety Audit Plan should identify the expected inputs to the Safety Audit activities which are to
be made available by Contractors, Sub-Contractors, MOD, etc as well as when such inputs will be required.
4.10.3 Where relevant, the Safety Audit Plan should also identify technical interfaces to existing or
planned PSSs.
4.11 Audit Reporting
4.11.1 The Safety Audit Plan should identify how long after a Safety Audit that Safety Audit Reports are
expected to be produced, and how the Safety Audit Findings are to be recorded, categorized, and
sentenced, as well as to whom the reports will be delivered and the roles and responsibilities with regard to
responding to those Safety Audit Findings.
4.11.2 Safety Audit Reports should record the Safety Criteria in place at the time of the Safety Audit. This
is to address those cases where later amendments to the Safety Criteria are agreed between the MOD and
the Contractor, so that it is clear which Safety Criteria were applied during each Safety Audit.
4.11.3 Further guidance on the production of Safety Audit Reports is contained in the DID for the Safety
Audit Report.
5.1 The Safety Audit Plan should be created, held and managed under an appropriate configuration
5.2 The Safety Audit Plan shall be approved by a suitable authorised representative of the Contractor
(for internal plans) or safety committee (ISA plans), in accordance with the roles and responsibilities defined
in the relevant management plan and endorsed by the safety committee.
107
108
DID - SAFETY AUDIT REPORT
1 Purpose
1.1 This DID sets out requirements for a Safety Audit Report in support of Defence Standard 00-56.
This DID is intended to identify the scope and content of the Safety Audit Report.
1.2 At least one PSS Safety Audit Report should be produced for every project working to Defence
Standard 00-56 whether undertaken by a CSA or an ISA. The scope and number of Safety Audit Reports will
be defined in the PSS Safety Audit Plan.
2.1 The Safety Audit Report should identify the items subject to Safety Audit and reference the relevant
PSS Safety Audit Plan and SMP. If there is no agreed Safety Audit Plan or relevant SMP at the time of the
audit then the Safety Auditor Report should document how the requirements of this, or other standards were
used to help drive the Safety Audit.
2.2 The Safety Audit Report should also set out the initial assumptions made by the Safety Auditor with
regard to availability of documents, evidence, etc.
This DID contains the content and instructions for preparing Safety Audit Reports. The depth, scope,
strategy and analysis methods for Safety Audits should be determined in the related Safety Audit Plan. The
Contractor should consider the activities in the PSS Project Plans, and SMP as well as the related Safety
Audit Plan when compiling a Safety Audit Report.
4.1 The Safety Audit Report should address the following topics:
a) Tailoring.
b) Applicable legislation and regulations.
c) Audit implementation.
d) Organisation and responsibilities.
e) Plans and milestones.
f) Analysis methods.
g) Interfaces.
h) Safety audit findings.
i) Conclusions and recommendations.
4.2 In general it is acceptable for CSAs and ISAs use their own formats for Safety Audit reporting and
to use the DID to check the scope and content of their PSS Safety Audit Report.
4.3 At least one PSS Safety Audit Report is assumed to be a deliverable unless otherwise stated within
the scope of supply.
4.4 Tailoring
4.4.1 Should this DID require tailoring for a Contractor Safety Audit Report, then such tailoring should be
agreed at the ITT stage. Any Independent Safety Audit Report should be produced as agreed between the
MOD and the ISA.
109
4.4.2 It would be expected that both the MOD and the Contractor would be given visibility of draft Safety
Audit Reports, so as to allow the Contractor and MOD to provide comments, such as clarifying responses to
Safety Audit Findings, and to make MOD aware of those Safety Audit Findings as early as possible.
4.4.3 Where a number of Safety Audits are being undertaken on related items within a short period of
time then it would be reasonable to produce a single Safety Audit Report addressing all such audits; as long
as this did not delay making Major Safety Audit Findings visible to the MOD and other Stakeholders.
The Safety Audit Report should record the goals of the Safety Audit, eg compliance with Defence Standard
00-56. Where a Means of Compliance had been agreed then the Safety Audit Report should document the
approach used to satisfy the agreed Means of Compliance.
4.6 Audit Implementation
The Safety Audit Report should record the audit implementation including those activities prior to the Safety
Audit, eg document selection, desk reviews, sample approach, etc. The success, or failure, of all audit
activities should be recorded. For example, an activity failed due a lack of necessary Contractor support.
4.7.1 The Safety Audit Report should identify the Safety Auditors who undertook the audits.
4.7.2 The Safety Audit Report should identify those Contractor personnel who supported the audits.
4.7.3 The Safety Audit Report should identify those within the Contractor and MOD organizations with
responsibility, authority and accountability for addressing the Safety Audit Findings raised as a result of the
Safety Audit.
The Safety Audit Report should explain the context of the Safety Audit within the overall Safety Audit
Schedule defined in the Safety Audit Plan. The Safety Audit Report should identify if the Safety Audit Plan
needs amending in the light of the Safety Audit Findings raised. This could include the need for additional
follow-up audits in order to determine whether major Safety Audit Findings are being addressed by the
Contractor, or MOD.
4.9.1 Any additional analysis or assessment method not documented in the Safety Audit Plan should be
justified and documented in the Safety Audit Report.
4.9.2 The Safety Audit Report should identify relevant Safety Criteria applicable to the Safety Audit. This
may be referenced through the relevant information in the relevant SMP or Safety Audit Plan.
4.10 Interfaces
The Safety Audit Report should identify whether the expected inputs to the Safety Audit activities, required to
be made available by Contractors, Sub-Contractors, MOD, etc were provided during the audit. If not, then
the reasons for their non-availability should be documented.
4.11 Safety Audit Findings
4.11.1 The Safety Audit Report should document the Safety Audit Findings, which should be categorized
in accordance with the categorization scheme agreed between the Contractor and the MOD and
documented in the Safety Audit Plan.
110
4.11.2 The Safety Audit Report should record any discussions regarding the Safety Audit Findings that
may have taken place during the Safety Audit, such as potential remedial action; however the Safety Auditor
should be careful to ensure that their level of independence is maintained.
4.11.3 The Safety Audit Report should clearly state the roles and responsibilities with regard to
responding to the Safety Audit Findings.
4.12 Conclusions and Recommendations
The Safety Audit Report should include an overall conclusion of the findings of the Safety Audit together with
a high level set of recommendations as to how the Safety Audit Findings should be addressed.
5.1 The Safety Audit Reports should be created, held and managed under an appropriate configuration
5.2 The Safety Audit Reports shall be approved by a suitable authorised representative of the
Contractor (for internal reports) or safety committee (ISA reports), in accordance with the roles and
responsibilities defined in the relevant management plan and endorsed by the safety committee.
111
112
DID - SAFETY CASE/SAFETY ASSESSMENT REPORT
1 Purpose
1.1 This DID sets out requirements for a Safety Case Report in support of Defence Standard 00-56.
This DID is intended to identify the scope and content of the Safety Case Report. The concept, use and
applicability of Safety Case Reports and its relationship with ISSS are discussed in Annex B.
1.1.1 In the DAE, each Air System has its own safety case, “The Air System Safety Case”. It is supported
by a number of Safety Assessments (defined in MAA02). Therefore where the Contractor is required to
supply Safety Cases, Safety Case Reports, in the DAE they are referred to as Safety Assessments and
Safety Assessment Reports. Where this DID refers to Safety Case or Safety Case Report, for the DAE it
should be read as Safety Assessment or Safety Assessment Report.
1.2 The Safety Case Report is a snap shot of the Safety Case that documents that all of the safety
issues relating to the PSS have been brought to a condition appropriate for the stage in the lifecycle, ie it
provides the safety justification to support the major Project milestones identified in the SMP. The Safety
Case Report draws on the content of the information set to provide a justification of the safety performance
of a PSS, within bounds that are reasonable given the scope of supply and other factors set out below.
1.3 The Safety Case Report is intended to provide information to those with accountability for the
safety of the PSS on the status of safety assessment and assurance, where the contractor can assess safety
risk. This includes visibility of the structured argument justifying the suitability of the safety performance of
the PSS. Depending on the scope of contract this may not represent a top level operational safety case
assessment and may feed into higher level system or operational safety case assessment/assurance
activities.
1.4 The Safety Case Report supplements the ISSS at the PSS level. Whilst it is appropriate to have a
focus on in-service use, it is also necessary to manage the technical detail that supports the design of the in-
service PSS.
1.5 A Contractor may not be able to determine in isolation the acceptability of overall safety
performance of their PSS. However, they have a responsibility to provide sufficient information in the Safety
Case Report for others to integrate their PSS in accordance with the Contractor’s design intent to produce a
system that can be operated safely.
2.1 A Safety Case Report is always required where the scope of supply includes the supply of a
system. A Safety Case Report may be required where the product is an element of a larger PSS, dependent
on the contracted scope of analysis.
2.2 There will be cases where a Contractor can assess safety only in terms of the inherent
characteristics of their PSS, such as the use of hazardous materials, risk of electric shock, control of moving
parts. There will be other cases where the Contractor has sufficient knowledge of the intended use that they
can assess safety risks arising from the operation of the PSS. The application of the DID will require
adapting to ensure that the balance of inherent/intrinsic and external/extrinsic risks is appropriate for the
Contract/PSS context. The agreed scope of contract should be documented in the SMP.
Note. For many simple products an ISSS, supported by an applicable Command Summary, may be
sufficient if the PSS is integrated into a more complex PSS with a Safety Case and associated Safety Case
Report.
A Safety Case Report is a deliverable specified within the SMP. It may be used in conjunction with the ISSS
and Command Summary. The Safety Case Report is a presentation of the Safety Case which will be based
on the evidence in information set.
113
4.1 The Safety Case Report should address the following topics (these topics do not necessarily need
to have their own explicit headings):
a) Scope.
b) Identified hazards and related accidents.
c) Assumptions, dependencies and limitations.
d) Context of use.
e) Unusual aspects of the PSS’s design.
f) Safety justification.
4.2 The Safety Case Report may be prepared under an alternative heading provided that it addresses
the content and controls required by this DID. The content required by the DID may be provided under a
number of documents, or incorporated with other deliverables, provided that the purpose set out above is
achieved in a clear, concise and unambiguous way.
4.3 The Safety Case Report may be combined with the ISSS and Command Summary. In this case
there will be large areas of commonality in DID requirements e.g. scope and context of use, however there
should be a clear delineation between the topics addressing hazards that are addressed by the Contractor,
and those where the Contractor is providing PSS and failure mode information in support of activities by
another organisation i.e. those areas covered uniquely by the ISSS DID.
4.4 The Safety Case Report should be assumed to be deliverable unless otherwise stated within the
Contract. Preliminary versions of the Safety Case Report may be required as the maturity of the PSS
develops. The timing and scope of preliminary versions should be agreed with the customer and defined
within the SMP.
4.5 Scope
4.5.1 The Safety Case Report shall include a scope statement that defines the boundary of the PSS
covered by the Safety Case Report, taking into account the scope of supply, the scope of analysis and the
PSS context.
4.5.2 The scope statement should make clear the relationship to other reports, both extant and intended,
that address the Contractors safety responsibilities and the intended use of the information contained within
those reports. For example, this may include referenced to a complementary ISSS, and the intention that
these are supplied to support a broader Safety Case that addresses integration into a system and its in-
service use (with in-service information in a Command Summary if required).
4.6 Identified Hazards and Related Accidents
4.6.1 The Safety Case Report should identify the hazards that are within scope of Contractor
responsibility. It should also identify related accidents where these are within the contracted scope of
analysis.
4.6.2 The Safety Case Report may also identify hazards/accidents that are outside of the contracted
scope of analysis but have been brought to the attention of the Contractor. These are likely to be more
relevant to the associated ISSS, and if included in this report should be clearly delineated to ensure there is
no confusion regarding boundaries of responsibility.
4.7 Assumptions, Dependencies and Limitations
4.7.1 The Safety Case Report should identify assumptions that have been used to progress the safety
activities of the Contractor. It should justify the reasonableness of such assumptions – in-service
assumptions and limitations are particularly relevant to Command Summary.
114
4.7.2 The Safety Case Report conclusions that rely on dependencies on information outside of the
Contractor’s scope of supply or analysis should be identified. This may include information supplied by MOD
on Government Furnished Equipment, or information from interfacing PSS not within the Contractor’s scope
of analysis.
4.7.3 The Safety Case Report may include dependencies on information from Sub-Contractors or
suppliers to the Contractor; however these should be clearly delineated from those from outside scope of
contract as the responsibility for management of Sub-Contract/supplier information dependencies remains
with the Contractor.
4.7.4 The Safety Case Report should identify limitations on use of the Contractor’s PSS that are
necessary to ensure safety. Limitations should be clearly linked to the possible safety impact should the
limitation not be enforced to aid judgements that may be necessary to address risks arising from operational
imperatives. These limitations are considered a key aspect of the Command Summary if one is required.
4.8 Context of use
The Safety Case Report should state the specified or intended context of use. This could include, but is not
limited to: operating environment; integration considerations; competence of users; and concept of operation.
This may also form part of the Command Summary if one is required.
4.9 Unusual Aspects of the Equipment’s Design
The Safety Case Report should highlight any aspects of the PSS that could be considered unusual,
particularly where this may contribute to reasonably foreseeable misuse in operation or maintenance.
4.10 Safety Justification
4.10.1 The Contractor is responsible for the safety performance of the PSS for inherent/intrinsic safety
risks within their scope of supply and this may extend to aspects within the scope of analysis. The level of
safety performance shall be justified against that reasonably expected through relevant legislation, contract
specification and recognised good practice.
4.10.2 The Safety Case Report should include evidence that the robustness of the justification has been
challenged to provide an appropriate degree of assurance of its conclusions. This should include search for,
and treatment of, potential counter evidence.
4.10.3 The Safety Case Report should include the key elements of the Safety Case argument and
references to evidence. From this argument and references it should be possible to trace all the evidence
and detailed structured arguments that support the safety performance conclusions.
5.1 The Safety Case Report should be created, held and managed under an appropriate configuration
5.2 The Safety Case Report shall be approved by a suitable authorised representative of the
Contractor, in accordance with the roles and responsibilities defined in the relevant management plan and
endorsed by the safety committee.
5.3 The Safety Case Report may address information for more than one PSS type and/or more than
one version/modification state of a PSS, provided that the association of the information specific to the PSS
5.4 Reasonable access to the information set that underpins the Safety Case Report should be
provided to Safety Auditors and others identified by the Contractors SMP as having a legitimate need to
access such information for safety purposes.
115
116
DID - HAZARD LOG REPORT
1 Purpose
1.1 This DID sets out requirements for a Hazard Log Report in support of DS 00-56. This DID is
intended to identify the scope and content of the Hazard Log Report.
1.2 A Hazard Log Report is a snap shot of the Hazard Log status on a given date. The PSS Hazard
Log is a continuously evolving record (database or document) which should be maintained with the PSS
throughout its lifecycle.
1.3 Hazard Log Reports must be capable of showing the linkages between Hazards, Accidents and
Controls (i.e. which hazards could lead to which potential Accidents, possibly with many-to-many
relationships, and which controls relate to which hazards and accidents). They must also differentiate
between controls which are already in place and those which are being considered or planned.
1.4 Hazard Log Reports will be produced for the purpose of review, eg by the Safety Committee, the
ISA or Stakeholders, to communicate current or changed status of the Hazard Log, as detailed in the SMP.
2.1 Given that the PSS scope of contract may not match that of overall system for which MOD Hazard
Log requirements apply e.g. in POSMS, it is essential that the relationship between the overall system level
Hazard Log and the PSS hazard information maintained by the Contractor is clearly captured and
communicated.
2.2 The scope of contract may require the Contractor to manage the complete Hazard Log for an
overall system, in which case the requirements of POSMS Safety Management Procedure 11, including any
domain specific aspects, will be applied.
2.3 Where the Contractor is not the overall system Hazard Log manager, the Contractor is required to
supply hazard information to enable MOD or their appointed Hazard Log manager to meet the POSMS
requirements. The scope of information to be supplied will be dependent on the scope of contract and would
normally be aligned to that addressed by the Safety Case/Safety Assessment Report.
Hazard Log Reports are deliverables specified within the SMP. A Hazard Log Report is used by stakeholders
to assess the status PSS Safety Case at a particular point in the project. The Hazard Log is an example of
documentary evidence in the information set and a Hazard Log Report, a deliverable within the ISSS.
4.1 The Hazard Log Report should address the following topics to the degree agreed with MOD and
documented in the SMP (these topics do not necessarily need to have their own explicit headings). The level
of detail provided against each heading should be tailored according to the agreed objective of each
snapshot report:
a) Introduction.
b) Accident Data.
c) Hazard Data.
d) Risk Classification.
4.2 The Hazard Log Report may be prepared under an alternative heading provided that it addresses
the content and controls required by this DID. The content required by the DID may be provided under a
number of documents, or incorporated with other deliverables, provided that the purpose set out above is
117
achieved in a clear and unambiguous way. Repetition of information provided in other reports should be
avoided by planning the purpose and content of such documents in advance and making appropriate cross
reference.
4.3 The Hazard Log Report should be assumed to be deliverable unless otherwise stated within the
Contract. By its nature several versions of the Hazard Log Report should be anticipated over the project
lifetime. The timing and scope of versions should be agreed with the customer and defined within the SMP.
4.4 Introduction
4.4.1 The introduction should define the scope of information covered by the Hazard Log Report and
how this relates to any associated Hazard Logs, whether maintained by the Contractor, MOD or their agent.
4.4.2 The Hazard Log Report should describe the PSS addressed by that scope, including relevant
configuration information such as PSS identifier and standard.
4.4.3 The Hazard Log Report should reference project safety information such as Top Level Safety
Requirements and safety criteria. This information may be directly included rather than referenced where this
aids interpretation of the accident, hazard and risk information in the Hazard Log Report.
4.5 Accident Data
4.5.1 The Hazard Log Report should include sufficient information to identify all relevant accidents and
their sequences linking each accident and the hazards which contribute to it, and any proposed or
implemented controls or mitigations.
4.5.2 The Hazard Log Report should include the accident severity category and probability targets to
achieve an acceptable safety performance.
4.6 Hazard Data
4.6.1 The Hazard Log Report should include sufficient information to identify all the hazards and their
status, including any outstanding corrective action.
4.6.2 The Hazard Log Report should include the hazard probability targets to achieve an acceptable
safety performance.
4.7 Risk Classification
The Hazard Log Report should include a statement of the risk classification of Accidents within scope of the
Hazard Log Report. It should be remembered that this may not be the complete set of accidents relevant to a
system and therefore may represent only a lower bound on the risk classification of the related system.
5.1 The Hazard Log Report should be created, held and managed under an appropriate configuration
management system, which should be specified in the SMP
5.2 The Hazard Log Report shall be approved by a suitable authorised representative of the
Contractor, in accordance with the roles and responsibilities defined in the relevant management plan and
endorsed by the safety committee.
5.3 The Hazard Log Report may address information for more than one PSS type and/or more than
one version/modification state of a PSS, provided that the association of the information specific to the PSS
5.4 Reasonable access to the Hazard Log that underpins the Hazard Log Report should be provided to
auditors and others identified by the Contractors SMP as having a legitimate need to access such
information for safety purposes.
118
DID - SAFETY MANAGEMENT PLAN
1 Purpose
1.1 This DID sets out requirements for a Safety Management Plan. The requirements should be
viewed as a checklist, rather than as a contents list. This DID is intended to identify the scope and content of
the Safety Management Plan.
1.2 The SMP should be updated at a frequency defined in the Contract, but it would be unusual if the
SMP were not updated at least once per annum, and on major project events, eg a Preliminary or Critical
Design Review.
1.3 In general, it is likely that the SMP would be produced by drawing on standard company practices,
eg a Safety Management Systems, and on the project-specific information defined in the Contract Statement
of Work. The SMP should address the core principles of systems engineering and safety management.
2.1 It is expected that the SMP would be a ‘child’ of the Project Management Plan which would identify
the context of the Project. For some smaller projects the Safety Management aspects may be included within
the Project Management Plan.
2.2 The SMP should identify the agreed scope of contract for the PSS, including the scope of analysis
and supply.
2.3 It should identify both primary and ancillary PSSs, eg test equipment as well as the main
deliverables, where they are safety-relevant. It should identify critical dependencies on externally supplied
PSS, eg GFX.
2.4 The SMP should identify and cover the lifecycle of the PSS within the scope of analysis
This DID contains the content and instructions for preparing the SMP. The SMP is a key plan and it should
clearly identify important aspects such as responsibilities, plans, reports, interfaces, scope of contract, supply
boundaries, requirements etc. The SMP should draw on the Contractors SMS for system engineering and
safety management.
4 Safety Management Plan Preparation Instructions
4.1 The SMP shall contain information on the following topics:
a) Applicable Legislation and Regulations.

b) Safety Strategy.
c) Safety Requirements.
d) Organisation and Responsibilities.
e) Plans and Milestones.
f) Analysis Methods.
g) Risk Assessment and Acceptance.
h) Development Methods.
i) Interfaces.
j) Information Management.
k) Safety Reporting.
l) Safety Auditing.
119
m) Change Management.
n) Deliverables.
o) Tailoring of Defence Standard 00-56.
4.2 Coverage of the above topics is Mandatory. However, tailoring may be acceptable subject to robust
justification for the changes and agreement with the MOD.
4.3 Should this DID require more extensive tailoring then such tailoring should occur at the Contract
tender / Contract award stage, not normally once the Contract is under way.
4.4 The level of detail under each topic will depend on the scale of the project. For simple projects the
SMP may contain detail for all of the above topics. For complex projects, the SMP is likely to contain detail
for key elements of the above topics, and to refer out to other documents as appropriate, eg the disposal
plan may be included in the SMP of the system into which the PSS is to be integrated.
4.5 Alternatively, for a simple project, the SMP would reference activities in the overall Project
Management Plan that are safety-related.
4.6 The topics may be viewed as a checklist for the supporting documentation, not just for the SMP
itself. However the level of detail in the SMP should be defined at the ITT and agreed prior to Contract
award, and should not normally changed once the Contract is under way.
The SMP should identify, or reference (eg reference to a legislation register), the legislation, regulations,
standards and MOD policies that apply to the PSS, taking into account all theatres in which the PSS is
intended to operate. It should also identify the relevant regulatory bodies, both civil and military, and the
impact of their regulatory role on the PSS.
4.8 Safety Strategy
4.8.1 The SMP should identify a Safety Strategy that is both appropriate for the scope of analysis of the
PSS, consistent with the Project Management Plan and MOD policy and appropriate to the project risk
profile.
4.8.2 The strategy should provide an overarching framework that will enable a PSS to be assured as
safe within the scope of supply.
4.9 Safety Requirements
4.9.1 The SMP should identify all Top Level Safety Requirements imposed through contract and Derived
Safety Requirements applicable to legislation, regulations, and MOD policy.
4.9.2 The SMP should identify processes for identifying, and for managing Safety Requirements through
the Contract life, and especially the development process. The requirements should cover all of the Defence
Lines of Development within the scope of contract.
4.9.3 The SMP should identify processes for identifying, and for managing assumptions made when
assessing the safety of the PSS.
4.10.1 The SMP should identify the key safety-related roles in the project organisation covering both
individuals and committees. It should identify responsibility, authority and accountability for safety-related
activities and decision-making, together with lines of reporting and communication. It should identify key staff
with safety responsibility, and record their qualifications and experience. The SMP should document the
Terms of Reference for the key roles.
4.10.2 The SMP should record how competency of staff in key safety roles is assessed and how it is
managed.
120
4.10.3 The SMP should also identify roles outside the Contractor’s organisation, eg key suppliers, and
MOD stakeholders, eg Regulators.
4.10.4 The SMP should address all Sub-Contractors activities and responsibilities, including the
mechanisms that the Contractor will use for oversight of Sub-Contractor work, to ensure that the
requirements of this standard are met.
4.11.1 The SMP should identify the schedule for major safety activities and milestones, and clearly show
the link between safety activities and the remainder of the activities on the Contract, eg major milestones
such as design reviews.
4.11.2 The SMP should identify other relevant plans, eg plans of significant service provision supporting
the PSS, such as test rigs or trials that may warrant their own SMP and Safety Case.
4.12.1 The SMP should identify, define and justify the methods to be used for safety and hazard analysis,
and which activities in the plan should use these methods.
4.12.2 The range of methods included will depend on the scope of analysis, but may include exploratory
analyses, eg HAZOP, deductive techniques, eg Fault Tree Analysis, and inductive techniques, eg FMEA and
Event Tree Analysis.
4.13 Risk Assessment and Acceptance
The SMP should identify and define the methods to be used for risk analysis, and which activities in the plan
should use these methods. It should identify risk measures and acceptance criteria, eg hazard risk matrices,
and the authorities for accepting risk in each category. It should also identify the organisations involved and
protocols to be used for risk acceptance.
4.14 Development Methods
4.14.1 The SMP should identify and define and (where necessary) justify the methods to be used for the
development of critical system components, particularly in response to integrity requirements, and identify
which tasks in the SMP should use these methods.
4.14.2 This shall address the full lifecycle of all relevant technologies, eg software, and critical mechanical
parts. Where appropriate the SMP should refer to external standards or sources of good practice.
4.14.3 The identification and definition of methods are necessary only where system components are
being developed, eg may not apply to service provision.
4.15 Interfaces
4.15.1 The SMP should identify known interfaces to other stakeholder organisations and define the
protocols for ensuring safety co-ordination across these interfaces, including identifying information to be
shared and engagement in Safety Committees.
4.15.2 Where relevant, the SMP should also identify technical interfaces to existing or planned PSS within
the scope of contract.
4.16 Information Management
4.16.1 The SMP should identify the scope of the information set and the formats, tools, etc, for recording
the information set, together with the protocols for keeping the information set under configuration control.
4.16.2 The SMP should identify the procedures and tools for establishing and maintaining the Hazard Log
to ensure that it accurately reflects the status of the design, hazard analysis, safety analysis and safety
121
4.16.3 The SMP should identify mechanisms for preserving the information set through Contract life.
4.17 Safety Reporting
4.17.1 The SMP should identify the frequency and nature of reports against the safety programme, and
indicate how these will be linked into major programme milestones and reviews.
4.17.2 The SMP should identify the Hazard Log Reports, ISSSs and Safety Case Reports to be produced,
including preliminary reports and/or incremental delivery of the reports.
4.17.3 The SMP should identify the distribution lists for the reports and the forum in which the reports will
be reviewed, discussed, and remedial action identified. If this is not specified, then the default is that the
reports go to, and are handled by, the Safety Committee.
4.17.4 The SMP should identify mechanisms and procedures for recording and assessing incident data,
and taking both immediate remedial action and longer-term corrective action. It should include processes for
dissemination of information to all interested parties, which may include users of similar PSS, regulators, or
other official bodies, eg the HSE.
4.18 Safety Auditing
4.18.1 The SMP should identify internal Safety Audit Plans and reporting, including processes, terms of
reference for audits, audit frequency, and audit of Sub-Contractors. This may refer to a dedicated Safety
Audit Plan.
4.18.2 The SMP should identify how Safety Audit findings (both internal and by an ISA, if appointed) will
be sentenced, reported and managed, and the escalation route (in the defined organisation) if audit findings
are not acted upon in a timely manner.
4.19 Change Management
4.19.1 The SMP should identify mechanisms and procedures for management of change for the PSS.
4.19.2 These mechanisms and procedures should address updates in-service, and the maintenance of
clear records of materiel state, even for geographically dispersed PSS.
4.20 Deliverables
4.20.1 The SMP should identify all safety-related deliverables from the Contract, and define formats for all
documentary deliverables identifying where domain regulations and agreed civil standards replace DID
formats.
4.20.2 The SMP should identify the review and acceptance process and timeframes for all deliverables.
4.21 Tailoring of Defence Standard 00-56
4.21.1 The SMP should contain a compliance matrix showing any tailoring of the Def Stan 00-56 – further
information is in the contracting Def Stan 00-56 Part 1 Annex B.
4.21.2 The SMP should contain results from identification and analyses of any divergences with Def Stan
00-56, and applicable regulations and legislation. The SMP should also contain the means of resolving the
divergences.
4.21.3 The SMP should document the agreed deviations from requirements and Def Stan 00-56.
122
5.1 The SMP should be created, held and managed under an appropriate configuration management
system.
5.2 The SMP shall be approved by a suitable authorised representative of the Contractor, in
accordance with the roles and responsibilities defined in the relevant management plan and agreed by the
MOD and the Safety Committee.
5.3 The SMP may address information for more than one PSS type and/or more than one
version/modification state of a PSS, provided that the association of the information specific to the PSS
5.4 Throughout the life of the Contract, the SMP shall be reviewed and updated to changes in
circumstances or plans. The review should be carried out regularly and all changes agreed with the MOD
and the Safety Committee.
123
124
DID - PROGRESS REPORTS
1 Purpose
1.1 This DID sets out requirements for a Progress Report. This DID is intended to identify the scope
and content of the Progress Report.
1.2 A Progress Report will normally progress of safety management against the agreed SMP and will
form a formal record which should stay with the PSS throughout its lifecycle. The Progress Report
requirements should be viewed as a checklist, rather than as a contents list. In general it is desirable that
Contractors use their own formats for documents, and to use the DID to check that the scope and content of
the Progress Report.
1.3 The Progress Report should be updated at a frequency defined in the SMP. However, it would be
normal for a Progress Report to be issued prior to significant safety meetings, eg a Safety Committee
meeting. Note: the Progress Report is not the method of recording Safety Committee minutes.
1.4 In general, it is likely that the Progress Report would be produced by drawing on standard company
reporting practises.
2.1 Progress Reports record progress against the requirements of the SMP, eg schedule and status for
major scope of supply deliverable such as a Safety Case/Safety Assessment Report.
2.2 Progress Reports may contain commentary or intermediate analysis on particular safety issues that
are natural products of the safety management, design or stakeholder directions, eg a proposed clarification
of the scope of analysis, or a derived safety requirement. Progress Reports may contain a response to a
safety issue and form an important formal record, eg an analysis of data from an incident.
Progress Reports are deliverables specified in the SMP. Progress Reports are a record intermediate
Contractor activities related to activities identified in the SMP or Safety Audit Plan. Progress Report may also
contain responses to formal actions from stakeholders.
4 Progress Reports Preparation Instructions
4.1 Progress Reports should address the following topics:
a) Progress against the SMP.

b) Progress against the Safety Audit Plan.
c) Status of scope of supply Deliverables.
d) Analysis of Safety Issues.
e) Records of Contractor activities in response to Safety Committee and stakeholder actions.
4.2 The above topics for a Progress Report are an indication of what areas a Progress Report may
cover. Progress against the SMP and status of scope of supply deliverables are Mandatory.
All Progress Reports created should be held and managed under an appropriate configuration management
system.
125
126
DEF STAN 00-56 Part 1 Issue 6)
ANNEX D
INTEGRITY
1 Introduction
1.1 Integrity is a general concept which applies across the entire system hierarchy, from the highest
level, eg an aircraft carrier, to the lowest level, eg a bolt. This Standard uses the concept of integrity, across
a range of technologies, including structures and complex electronics.
1.2 Integrity is important, from a safety perspective, as loss of, or inadequate, integrity can contribute to
hazards. A metal framework, eg an aerial mast, which has inadequate structural integrity, will fail under
normal operating loads. Complex electronic hardware and software, referred to as Programmable Elements
in this Annex which have inadequate integrity may have obscure failure modes that allow incorrect operation
resulting in Risk to Life, eg Flight Control Software that allows an aircraft to exceed its operating envelope.
1.3 Hazards and failure modes are properties of PSS which can be observed. Integrity generally
cannot be observed, but is a property of the way in which a PSS is designed, constructed and maintained.
1.4 This Annex provides guidance on the ways in which integrity requirements are determined, how
they are managed through life, and how shortfalls in integrity are sentenced. The guidance specifically
addresses where the Standard requires the Contractor to identify and record Safety Requirements to ensure
Design Integrity. In particular it considers robustness to PSS elements which are not of high integrity (or are
of unknown integrity) and impairments to integrity.
1.5 For some simple PSS elements, eg COTS/MOTS components, quality assurance, declaration of
conformity and specifications may be sufficient to show that the elements are of sufficient integrity, eg have
the requisite strength reliability or performance. For more complex or critical PSS elements, or where simple
PSS elements are to be integrated into a safety critical system, integrity needs to be more explicitly managed
during the design and development process.
2 Integrity Requirements
2.1 Integrity requirements are a special case of Derived Safety Requirements, and will generally be
allocated and managed down to the level of individual elements which are designed and manufactured or
acquired. As the Standard encourages the use of civil, open or other standards or good practice it is difficult
to give general guidance on how to manage allocation, as standards use different strategies, eg initially
allocating integrity requirements based on Hazard severity (eg ARP 4754/4761), on risk reduction (eg BS EN
61508) or influenced by controllability (eg ISO 26262). Further the standards vary in how they decompose
and allocate integrity requirements at a lower level.
2.2 It is possible to identify a number of general guidelines which should be applicable independent of
standards and technologies, and which can be drawn upon if there are no applicable domain-specific
standards.
2.3 The general principle underlying decompositions and integrity allocation is that there must be
evidence that the elements to which any integrity requirements are allocated will fail independently. In
particular, the aim is to ensure that there are no common-cause or common-mode failures due to
commonalities between the elements, and the term diversity is often used for this. Diversity is normally
introduced in design processes hence the use of the general term Design Integrity.
3 Design Integrity through Diversity
3.1 In this Standard, there are two views of diversity for PSS. The first is mechanistic diversity, eg
using the same algorithm specification in a general purpose processor and in bespoke electronics. The
second view is conceptual diversity, where different concepts are used to achieve the same effect, eg inertial
navigation system and Global Positioning System.
127
3.2 Mechanistic diversity does not address problems of lack of integrity as effectively as conceptual
diversity as the design is still the same, but it is included here as it is a form of implementation diversity
providing independence. In contrast, conceptual diversity embodies differences in the design and
development process.
3.3 Conceptual diversity is often stronger than simple mechanistic diversity in guarding against
common mode failures as it involves mechanistic diversity as well, but this is not always the case, eg using
different communications methods (analogue and digital) on the same transmission line.
3.4 Demonstrating independence with diversity may require analysis of mechanistic and/or conceptual
strategies to determine the extent of any combinatory elements, leading to a justification of the level of
independence and overall integrity.
4 Design Integrity through Architecture
4.1 Integrity is one of the key factors to take into account at the architectural design phase, and it feeds
into design and architectural trade studies. Trade study techniques such as Preliminary System Safety
Analysis (eg ARP 4761A) enable alternative architectures to be assessed based on their safety properties.
One important aspect of the trade studies is to optimise the design to reduce the cost of achieving integrity, if
possible, by placing the highest integrity requirements on simple elements, and avoiding reliance on
elements which are complex.
4.2 A further principle in design, and in allocation and management of integrity, is to avoid single points
of failure which can give rise to unacceptable risk. In some cases, eg the main spar in an aircraft, it is not
possible to avoid single points of failure.
4.3 Avoidance of single points of failure is a significant factor in design and architecture trade studies.
These studies can lead to increased confidence in the selected architecture and reduce the possibility of
over designed solutions.
4.4 If it is not possible to avoid single points of failure, then the critical PSS elements will have to be
developed to the integrity level allocated to the whole PSS, eg derived from the most severe Hazards
associated with the whole PSS. In many cases, there will be established means of developing or
demonstrating the critical PSS elements to the appropriate level of integrity, eg design codes/standards.
However, the Safety Case would also need to include an argument explaining why the approach is
adequate. The decision to impose a ‘no single fault’ (or even no double fault for ‘special’ cases), or a design
with strength margin, plus analysis, test, inspection regimes will be substantiated through integrity
requirements.
4.5 In some cases, design codes/standards are in the public domain, eg this Standard, but in other
cases they are company intellectual property which may be part of the information set, but not released in an
ISSS or a Safety Case Report.
5 Design Integrity Interdependence
5.1 There is increasing trend for interdependencies in system design between previously separate
elements of integrity, eg automated aircraft fuel distribution is used to alleviate stresses on wings. The failure
of such an automated control systems can place greater demands on the integrity of a system.
5.2 In some cases the design codes/standards or approaches which have been used historically are no
longer applicable or not considered sufficient, particularly when used out of their original context, and the
design approach and Safety Case (Report) will have to address these interdependencies.
6 Design Integrity through Robustness and Resilience
6.1 This treatment of interdependencies leads on to the notion of robustness and resilience. A system
is robust if it can continue to meet Safety Requirements, even in the presence of internal failures. A system
is resilient if it is robust, and can also continue to meet Safety Requirements in the presence of external
threats or attacks. Whilst the concepts of robustness and resilience are quite general, this Standard focuses
on the safety perspective.
128
6.2 To provide confidence that a design will be robust/resilient there is a hierarchy of Derived Safety
Requirements and, in the presence of failures or attacks the system will respond so as to meet lower, less
demanding requirements in the hierarchy when it is not possible to meet the higher-level requirements.
6.3 Sometimes the ideas of robustness and resilience are referred to as the system being fail-safe.
However, fail-safe can be interpreted as meaning there is a static state which the system can reach, ie non-
operating. In many military PSSs, there is a safety requirement for the PSS to fail-operating, albeit with
degraded capabilities – sometimes referred to as fault-tolerance or graceful degradation, eg a multi-engine
fighter aircraft can continue to operate safely on a single engine.
6.4 To an extent, robustness and resilience may be intrinsic in a design, eg structures are engineered
so that they retain sufficient integrity, following damage or over-stressing.
6.5 In many cases, however, to achieve robustness and resilience will require a form of transition
between states or operating modes and this may need additional functions to manage the transition. Ideally
transitions should be natural fallback states as additional transition functions may have high integrity
requirements. These mechanisms are forms of mitigation and will be defined during the process of design as
low-level Derived Safety Requirements.
6.6 Robustness can be achieved within a technology, eg designing alternative load paths, in case
primary structures fail, which are at least good enough to complete a mission safely. Alternatively,
robustness or resilience can be achieved using combinations of technologies. For example, if a structural
component starts to degrade, then it may be possible to alter usage or loading to extend and protect the
component’s life, eg PE restricting the flight envelope including turn rate, or controlling the fuel distribution, of
an aircraft.
6.7 Architectural evaluation, such as Preliminary System Safety Assessment (eg reference ARP 4754,)
can be used to provide evidence that the PSS design is robust and resilient, as appropriate according to the
hierarchy of requirements. It should be noted that, where single points of failure are unavoidable, robustness
may be hard or impossible to achieve; part of the evaluation would be whether or not such system properties
are acceptable or tolerable.
7 Complex Electronic and PE Integrity
7.1 The integrity of PE is addressed in Def Stan 00-55 (Issue 3 or later) which is based on objectives
developed from the principles outlined below:
a) Principle 1. PE Safety Requirements shall be defined to address the PE contribution to system

hazards.
b) Principle 2. The intent of the PE Safety Requirements shall be maintained throughout requirements
decomposition.
c) Principle 3. PE Safety Requirements shall be satisfied.
d) Principle 4. Hazardous behaviour of the PE shall be identified and mitigated – addressed by failure
modes and supported by designing for safety.
e) Principle 5. The confidence established in addressing the other PE safety principles shall be
commensurate to the contribution of the PE contribution to system risk and will be addressed by
Design Integrity requirements.
7.2 These principles are generic and could be applied to all PSS. However, all of these principles have
consistently challenged current and past civil and military projects due to the complexity of their PE.
8 Civil Standards and Design Integrity
8.1 It is MOD practice that Defence Standards are used only where civil or open standards cannot be
effectively applied in a military context. One of the goals of this Standard is that civil or open standards
should be used as the basis for complying with its requirements. In practice, not all standards will fully
129
address the above principles or the requirements of this Standard, so there needs to be a gap analysis and
development of Derived Safety Requirements to address shortfalls PE should not be treated differently to
other technologies, so the treatment of shortfalls in evidence would be addressed in the same way.
8.2 Some civil standards, eg BS EN 61508 and ISO 26262, deal with PE introducing the notion of
Safety Integrity Levels (SILs). In some standards, eg DO-178 and DO-254, the term Development/Design
Assurance Levels (DALs) is used, but for both SILs and DALs the intent is similar.
8.3 The confidence levels implied by Principle 5 are qualitative, and standards typically define integrity
or assurance levels. In general, as levels increase, the standards require the use of more rigorous
techniques and/or more independence.
8.4 Meeting the requirements of this Standard through the use of civil or open standards may not be
straightforward as their requirements relating to risk vary. Additionally, the set of techniques required, or
implied, to meet the different standards also varies. These differences in detail are accepted in the context of
this Standard, as it seeks to conform to industry norms so far as practicable. However, this may lead to
shortfalls in meeting the requirements of this Standard, such as:
a) The civil or open standards may not address all of the requirements of this Standard, ie it does not
provide a full coverage of required design integrity, eg a unique MOD regulation;
b) The civil or open standard does not provide sufficient confidence, eg a unique, more demanding,
military capability that the standard was intended to address.
8.5 Such shortfalls need to be sentenced, and will lead to Derived Safety Requirements, perhaps on
the design and development process.
8.6 Evidence of integrity should be provided to show satisfaction of requirements and to support the
ISSS and Safety Case and Safety Case Report.
8.7 Shortfalls in meeting Safety Requirements are addressed in the Standard. Tailoring of this
Standard should take into account the gap analysis between civil standards and MOD requirements. This
should also include differences in evidence requirements, as necessary.
Notes:
i. It is North Atlantic Treaty Organisation policy to use civil standards to the greatest possible extent.
ii. There are many definitions of open standard, however, an open standard should be supported by a
civil standards developing organization. Civil standards are normally open standards. MIL-STD-882 is an
example of an open standard that is supported by government agency but is not a civil standard.
9 Cyber Security and Data Integrity
9.1 The Complex Electronic and PE Integrity clauses refer to common concerns with regard to PE, but
there are two further issues which relate to PE, both of which are of growing concern with modern systems:
cyber security and data integrity.
9.2 It is important that Contractors consider cyber security issues as potential credible causes of failure
modes contributing to a hazard, and produce and implement appropriate mitigations based on this analysis.
9.3 Standards and guidelines for security diverge from those for safety both in terms of treatment of
risk, and in detailed guidance, eg on techniques for developing and assessing PE. The Contractor will need
to address the issue in the SMP and agree the approach with the MOD.
9.4 There is an increased dependence on data in PSS, due to PSS processing critical data, eg target
coordinates, complex data, eg terrain maps, or configuration data, eg defining the capabilities of a multi-role
system. Errors in any of these classes of data can have a safety impact, thus there is a need to manage data
integrity.
130
9.5 PSS can cause or contribute to, unsafe behaviour when its internal model of the world differs
sufficiently from the actual state of the real world and those decisions or actions generated by the PSS (or
recommendations given to operators) may be inappropriate.
10 Integrity Degradation
10.1 Integrity needs to be managed through life. There are a number of ways integrity can be impaired
over time. Loss of integrity may be caused by:
a) Fatigue due to use of the PSS, eg a ship’s hull, which will weaken over time with stresses from
normal operation;
b) Some technologies degrade over time, even if stored and not used due to corrosion or migration,
eg tin-whiskers is a migration associated with thermal and chemical stresses, dendrites are
migration associated with electrical field stress, silicon failures can be caused by doping migration.
c) Planned change, eg upgrading PSS due to obsolescence or legislative restriction, where the
replaced component may not have the required performance or reliability so it reduces integrity;
d) The environment, outside the PSS, changes, eg includes new buildings/features affecting a
terrain/map database;
e) The construction or development processes/tools changes, eg compilers used in the construction

of PE of PSS;
10.2 Management of integrity, through life, includes monitoring these and other factors which could
undermine the integrity. It involves understanding both PSS usage, ie purpose and requirements,
provenance of components and effective management of the supply chain.
131
©Crown Copyright 2015
Copying Only as Agreed with DStan
Defence Standards are published and obtainable from:
Defence Equipment and Support

UK Defence Standardization
Kentigern House
65 Brown Street
Glasgow
G2 8EX
DStan Helpdesk:
Tel: 44 (0) 141 224 2531/2
Fax: 44 (0) 141 224 2503
Internet e-mail: enquiries@dstan.mod.uk
File Reference
The DStan file reference relating to work on this standard is D/DStan/21/56
Contract Requirements
When Defence Standards are incorporated into contracts, users are responsible for their correct
application and for complying with contractual and statutory requirements. Compliance with a Defence
Standard does not in itself confer immunity from legal obligations.
Revision of Defence Standards

Defence Standards are revised as necessary by an up-issue or amendment. It is important that users of
Defence Standards ensure that they are in possession of the latest issue or amendment. Information on all
Defence Standards can be found on the DStan Websites https://www.dstan.mod.uk and
http://dstan.uwh.diif.r.mil.uk/, updated weekly. Any person who, when making use of a Defence Standard,
encounters an inaccuracy or ambiguity is encouraged to notify UK Defence Standardization (DStan) without
delay in order that the matter may be investigated and appropriate action taken. Sponsors and authors shall
refer to Def Stan 00-00 before proceeding with any standards work.

MOD 00-56 Safety MGMT 01000600

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MOD 00-56 Safety MGMT 01000600

Uploaded by

Copyright:

Available Formats

Defence Standard 00-56 Part 1

Issue 6 Date: 02 April 2015

Part 1: Requirements and Guidance

This Standard supersedes the following:

Defence Standard 00-56 Part 1 Issue 5 dated 29 January 2014

a) Service. Access to a commercially owned, commercially operated satellite communications system or

v. An essential element of safety management systems is the recording of evidence in support of

0.6.1 Sections 2 to 4 expand on the specific requirements on a clause-by-clause basis.

a) The deliverable PSS and information, ie the scope of supply.

This Page is Intentionally Blank

Safety Management Requirements for Defence Systems

1.3.2 Guidance on MOD safety management is available through the AOF.

3.1 Normative References

Def Stan 00-250 Human Factors for Designers of Systems

ii. In the DAE, the MAA Regulatory Publications (MRPs)

3.2 Other References

AERC Airborne Equipment Release Certificate

IET Blue Book Competence Criteria for Safety-Related System Practitioners

4.1 Terms and Definitions

4.2 Mandatory Requirements

PLD Programmable Logic Device

Section 2 - Safety Management Requirements

6.1 Safety Management Plan

The Contractor shall agree the SMP with the MOD.

6.3 Review and Update

6.4 Progress Reports

7.1 Deviation from Requirements

a) Which clauses will be or have been fully complied with.

7.2 Legislation, Regulations, Standards and Policy

7.4 Multiple Deliverables

7.5 Information Management

7.6 Documentary Deliverables

7.7 Agreement of Deliverables

8 Roles and Responsibilities

8.1 Safety Organisation

8.2 Safety Committees

8.3 Contractor Safety Audit Independence

9.1 Organisational Interfaces

9.2 Technical Interfaces

9.3 External Interacting Interfaces

10.1 Audits and Reports

10.2 Independent Safety Audit

10.3 Remedial Action

Section 3 - Safety Engineering

11 Safety Requirements, Hazard and Risk Analysis

11.1 Safety Requirements

11.2 Safety Requirements Management

11.3 Hazards and Accidents

iii. JSP 440 provides policy and guidance for security.

11.4 Hazard Tracking

11.4.1 The Contractor shall implement a Hazard Log.

i. Guidance on the management of a Hazard Log is available through the AOF.

11.5 Design for Safety

b) Reduce the Risk to Life by engineering means.

11.6 Safety Analysis

11.7 Failure Modes

11.8 Risk Estimation

11.9 Risk and Compliance Evaluation

11.10 Satisfaction of Requirements

12 Health Monitoring and Reporting System

13.1 Information Set Safety Summary

The Contractor shall produce an ISSS as defined in the SMP.

13.2 Safety Case