SMP09. Risk Acceptance

System Revision ID ASEMS Document Version Effective From State
3871 3.2 03/11/2017 - 00:15 Extant

9.1. Overview

9.1.0.1.

Risk Acceptance in is defined Def Stan 00-056 as:

“The systematic process by which relevant stakeholders agree that risk may be accepted.”

9.1.0.2.

Risk Acceptance is the final stage in risk management. Once risks have been assessed against requirements (Procedure SMP07 – Risk and ALARP Evaluation) and reduced where necessary (Procedure SMP08 – Risk Reduction), it will be agreed that sufficient evidence has been provided that the tolerability/ALARP (As Low As Reasonably Practicable) criteria have been met.

9.1.0.3.

There must be review at appropriate management level of each individual risk (and the aggregated risk for the system) before the Safety Case Report is finalised for major milestones. Completion of this procedure is a prerequisite for acceptance and signature of the Safety Case Report by the Team Leader.

9.1.0.4.

Risk Acceptance should occur only when there are positive answers to the questions:

“Have we done all that is Reasonably Practicable to reduce the level of safety risk posed by the identified accidents, individually and in total?”

            and

           “Are they now Broadly Acceptable or Tolerable and As Low As Reasonably Practicable?”

9.2. Procedure

9.2.1. Objectives

9.2.1.1.

The objective of Risk Acceptance is to ensure that every risk has been reviewed at appropriate management level prior to authorisation of the Safety Case Report by the Team Leader.

(Note “authorised” is used in accordance with the definitions in SMP12 – Safety Case and Case Report).

9.2.1.2.

The diagram below shows how Risk Acceptance relates to other elements of Risk Management in the Safety Management System.

9.2.1.3.

Risk Acceptance should take place after completion of Risk and ALARP Evaluation and Risk Reduction and prior to authorisation of the Safety Case Report by the Team Leader.  However, if some of the risks cannot be accepted, then there may be a need to re-enter the Risk Reduction cycle.

9.2.2. Method

9.2.2.1.

Individual risks, and the overall risk posed by the system, may be accepted when the Project Safety Committee and Project Safety Manager agree that sufficient evidence has been provided that the tolerability criteria have been met.

9.2.2.2.

The Project Safety Manager should agree with the stakeholders a process for Risk Acceptance. The process should ensure that the detailed evidence produced by the contractor is aligned against the hazards listed in the Hazard Log in a way that supports visibility and review by the appropriate management level according to risk category.

9.2.2.3.

There are defined processes for acceptance of risks within each domain (i.e. ship key hazards, airworthiness, Ordnance, Munition & Explosives, etc.) which should be followed for these risks, even if the project as a whole is primarily in a different domain.

9.2.2.4.

The military imperative sometimes demands that personnel are exposed to levels of risk that in civilian operations would not be tolerated. Decisions to tolerate such risks in order to achieve an essential military capability must always be made at the appropriate level of seniority. A formal process for referring risks up the DE&S management chain is described in ASEMS Part 2 - GMP00 Risk Referral leaflet.

9.3. Responsibilities

9.3.1. Accountability

9.3.1.1.

The Team Leader is accountable for the completion of this procedure. 

9.3.2. Procedure Management

9.3.2.1.

The Team Leader may delegate the management of this procedure to a member (Safety Manager) or members of the Delivery Team. 

9.3.3. Procedure Completion

9.3.3.1.

The Project Safety Manager and Project Safety Committee will be responsible for the completion of the procedure. However, in most cases a large part of the detailed evidence will be provided by contractors. The Project Safety Manager is responsible for approving this work as carried out to appropriate levels of detail, accuracy and completeness.

9.3.3.2.

The Team Leader is responsible for formally documenting the acceptance of the residual risk of the system by the appropriate authority. The Team Leader will ensure that this residual risk and the associated hazards are updated to reflect changes/modifications in the system or its use. The Team Leader and Project Safety Committee  should jointly determine the updated residual risk prior to acceptance of the risk and system hazards. 

9.4. When

9.4.1. Production

9.4.1.1.

Risk Acceptance is an ongoing process by which all the individual risks in the Hazard Log are reviewed at appropriate management level where claims of tolerability and ALARP are to be made. 

9.4.2. Review, Development and Acceptance

9.4.2.1.

Each major update shall be endorsed by the Safety Panel, authorised by the Project Safety Manager and accepted by the Team Leader. 

If the evidence supporting Risk Acceptance is updated, management measures should ensure that the Hazard Log, Safety Case Report and other dependent activities are also updated.

9.5. Required Inputs

9.5.0.1.

This procedure for Risk Acceptance requires inputs from:

  1. Outputs from Procedure SMP03 – Safety Planning;
  2. Outputs from Procedure SMP04 – Preliminary Hazard Identification and Analysis;
  3. Outputs from Procedure SMP11 – Hazard Log;
  4. Outputs from Procedure SMP12 – Safety Case and Safety Case Report;
  5. Outputs from Procedure SMP05 - Hazard Identification and Analysis;
  6. Outputs from Procedure SMP06 - Risk Estimation;
  7. Outputs from Procedure SMP07 - Risk and ALARP Evaluation;
  8. Outputs from Procedure SMP08 - Risk Reduction.

9.5.0.2.

The Risk Acceptance process and timing appropriate to the project should be defined in the Project Safety Management Plan, if necessary with reference to the contractor’s Safety Management Plan.

9.5.0.3.

The Risk Acceptance should use the following reference inputs, as available:

  1. Hazard Log;
  2. Risk Evaluations;
  3. Detailed evidence supporting the Risk Evaluations;
  4. ALARP justifications;
  5. Independent Safety Auditor Report(s);
  6. Safety Requirements in System Requirements Document and Contractual Documents.

9.6. Required Outputs

9.6.0.1.

The primary output of the Risk Acceptance should be the endorsement at appropriate management level of the evidence of tolerability and ALARP for each accident recorded in the Hazard Log.

9.6.0.2.

ASEMS Part 2 GMP00 Risk Referral leaflet.

9.6.1. Records and Project Documentation

9.6.1.1.

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

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

9.6.1.2.

Risk Acceptance will be documented through the Hazard Log and Safety Case Report.

9.7. Further Guidance

9.7.0.1.

The process for risk acceptance should address how the sufficiency and adequacy of the evidence will be demonstrated. Agreement that the Tolerability Criteria have been met, and that the risk has been reduced to a level that is ALARP, will be the minimum requirement. The agreement is between the Contractor, the Project Safety Manager and the Safety Panel, but, in many cases both parties should need to take due cognisance of outside bodies e.g. regulatory/certification bodies and users.

9.7.0.2.

The process for risk acceptance should be agreed at an early stage in the project and should be included in the Safety Plan. Discussions should involve the contractor’s, and the MOD’s, safety advisors; the Safety Panel; and representatives from any regulatory/certification bodies.

9.7.0.3.

In practice Risk Acceptance should be an ongoing process as individual hazards are resolved and evidence of this becomes available. This obviously reduces the risks to timescale and the peak workload on the Safety Panel. However care should be then taken to ensure that later changes and modifications do not invalidate previous Risk Acceptance. This requires effective change control and visibility of the impact of changes on hazards.

9.7.1. Guidance for Different Acquisition Strategies

9.7.1.1.

The requirements for Risk Acceptance should not change for acquisition conducted through intergovernmental agreements, OCCAR, multilateral or collaborative programmes. It is MOD policy that the same standards are met, and that assurance that these standards have been met can be demonstrated.

9.7.2. Project Risks

9.7.2.1.

Acceptance of risks on an ALARP basis will not be justified on the basis of project budget limitations.

9.7.2.2.

As in all safety matters, failure to get agreement on key issues affecting the Acceptance Process at an early stage in the life cycle will often lead to problems in cost and time terms.

9.7.2.3.

Safety Committees will resist any inclination to indulge in ever more complex calculations and analysis, which cannot be justified on time and cost grounds.

9.7.2.4.

Risk Acceptance will not be achieved if there are significant shortcomings in the previous Risk Management activities. The Project Risks identified against Procedures SMP05, SMP06, SMP07 and SMP08, can result in inability to achieve Risk Acceptance.

9.8. Version Control

9.8.1. Version 2.3 to 3.0 Uplift

9.8.1.1.

Major uplift from the Acquisition System Guidance (ASG) to online version. POEMS has undergone major revision. Refer to the POEMS Transition Document for details.   

9.8.2. Version 3.0 to 3.1 Uplift

9.8.2.1.

A minor uplift to correct spelling, grammar, and to remove some duplication of text.

9.8.3. Version 3.1 to 3.2 Uplift

9.8.3.1.

A minor uplift, GMP04 reference amended to 'GMP-00 Risk Referral Leaflet' to reflect the re-org of the GMPs. 

Subject to Policy Clauses

3.3

Stakeholder Agreements

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

3.6

Accountability

Within Operating Centres, Project Teams or their equivalents, named individuals shall be appointed who shall have defined roles, responsibilities, accountabilities and authority for ensuring safety and environmental management systems are established, implemented and maintained in accordance with the requirements of ASEMS.

3.10

Review

Operating Centres, Project Teams or equivalents shall review their safety and environmental management systems, at planned intervals commensurate with the risk, to ensure their continuing suitability, adequacy and effectiveness.

4.1

Safety Cases

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

4.7

Safety and Environmental Objectives and Targets

Operating Centres, Project Teams or equivalents shall establish and maintain relevant safety and environmental objectives with a resourced programme to achieve targets.

4.8

Accident and Incident Records

Operating Centres, Project Teams or equivalent shall monitor and record incidents where the performance of their Product, Systems or Services either caused or had the potential to cause harm to individuals or damage to the environment and use this information to keep their risk assessments valid.

4.9

Assessment Approval

Project Team Leaders or equivalent shall personally approve safety and environmental case reports to confirm their acceptance with the progress of the safety case/assessment and of the risks associated with the project.

5.1

Risk and Impact Assessment

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

5.5

Safety Risk

Products, Systems or Services shall not have safety risks that have not been formally assessed, justified and declared to be Tolerable and As Low As Reasonably Practicable (ALARP).

Process Maps

SMP A3
Identifcation Assessment & Management of Safety Risks

Click here to view

SMP DM4
Review & Refine Safety Assessment

Click here to view

SMP I1
In Service Phase Activities

Click here to view

Covered by Audit Question Sets

3.3

Audit Question Set Section 3.3 Stakeholder Agreements

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.3.

3.6

Audit Question Set Section 3.6 Accountability

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.6.

3.10

Audit Question Set Section 3.10 Review

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 3.10.

4.1

Audit Question Set Section 4.1 Safety Cases

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.1.

4.7

Audit Question Set Section 4.7 Safety and Environmental Objectives and Targets

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.7.

4.8

Audit Question Set Section 4.8 Accident and Incident Records

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.8.

4.9

Audit Question Set Section 4.9 Assessment Approval

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 4.9.

5.1

Audit Question Set Section 5.1 Risk and Impact Assessment

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.1.

5.5

Audit Question Set Section 5.5 Safety Risk

The Audit Question Set used as assurance in order to adhere to the policy described in policy clause 5.5.