1 Purpose

The purpose of this document is to provide direction to those within the SDA
responsible for Safety outputs and their obligations regarding management of cyber
risks which may affect safety risk assessments or safety risks that may affect
cyber risk assessments in accordance with:
• JSP815 Defence Safety Management System [1]:
• Element 4 Risk Assessments and Safety Cases;
• Element 7: Equipment Design, Manufacture and Maintenance;
• E7.5 The Defence organisation has mechanisms in place to ensure physical
changes to equipment, (including major software changes), materials and associated
specifications are evaluated, risk assessed, approved, and documented.
• Element 8: Infrastructure Design, Build and Maintenance.
• Defence Maritime Regulations DSA02-DMR Regulations [2]:
• Regulation 302 - Safety and Environmental Management System(s). Accountable
Persons shall develop and maintain a proportionate SEMS for their area of
responsibility and operate in accordance with it.
• Regulation 304 - Safety and/or Environmental Case(s). Accountable Persons
shall develop and maintain Safety and/or Environmental Cases to demonstrate that
platforms, products, and activities (including software safety and cyber security)
meet and maintain Safety and Environmental Protection requirements.
• Regulation 208 - Platform Authorities. PA should provide assurance that, for
each ship within their Area of Responsibility (AoR) safety assessments of software
integrity and cyber security risk are conducted.
• Defence Maritime Regulator (DMR) 03/2020 Notice - Defence Maritime Cyber Risk
Management [3], now incorporated fully into DSA02-DMR Regulations 208 and 304.
Provides guidance on good practice and provides an excellent baseline for Cyber
Risk Management, although written for merchant fleet and commercial shipping
companies:
• Department for Transport Cyber Security Code of Practice for Ships July 2023
[4]
• Baltic and International Maritime Council (BIMCO et al) The Guidelines on
Cyber Security Onboard Ships [5].
• JSP440 – The Defence Manual of Security [6], which details policies and
management requirements with regards to both physical and digital security within
MOD operations.
• JSP 628 – Security Regulation of the Defence Nuclear Enterprise. This
publication sets out the regulatory expectations for security delivery and
assurance with regards to the Defence Nuclear Enterprise (DNE), inclusive of all
MOD-owned Accountable Nuclear Material, Defence Nuclear Information and Defence
Nuclear Assets.
• “Without security features on the software controlled systems, the vessel and
personnel are at risk of intentional malicious changes which could cause loss of
safety related functions or unexpected and potentially dangerous behaviours
resulting in loss of vessel and personnel.”
1.1 Update
This Process is an update and combining of the following previous documents:
• SDA Cyber Security Related SEMS Policy, Version 0.9, January 2021.[7]
• SDA Cyber Security and Safety Risk Alignment Guidance, Version 0.3, February
2024,Version 0.3. [8]
• SDA Cyber Security Related SEMS Policy – Approach To Compliance Case. [9]
2 Scope
This process describes the mandated arrangements for assessing Safety outputs and
their obligations regarding management of cyber risks which may affect safety risk
assessments or safety risks that may affect cyber risk assessments.
3 Document Classification
This document is to be reviewed, authorised, controlled, and retained in accordance
with CD- SEMS- Level 4.0.1 HSEP Document Management [10] and has been categorised
as Significance Level (SL) 2.
4 Applicability
This Safety Cyber Security Process is applicable to all SDA Teams which are
regulated by the Defence Maritime Regulator defined in DSA02-DMR. This process
applies to equipment or installation safety and where they may affect the overall
Submarine platform safety or the associated equipment safety.
This process is for Project Teams (PTs) and Delivery Teams (DTs) in all stages of
the Acquisition cycle.

Figure 1 Acquisition Safety Lifecycle from JSP 376 [11]

In particular:
1. New Platforms Concept/ Assessment/ Demonstration.
2. Current Platforms in Manufacture.
3. Current In-Service Platforms.
4. Submarines in Disposal/ Laid-Up Submarines (LUSM).
5 Background
Utilising cyberspace is key to all military operations on land, sea, and air.
Cyberspace extends to things such as, embedded processors, controllers, Warship
Electronic Chart Display and Information Systems (WECDIS), medical life-support
systems and national electricity distribution systems . Access to cyberspace is
possible through but not limited to computer terminals, laptops, tablets, and
mobile phones. Connectivity may be achieved via wireless connections, removable
media, or physical cables. Cyberspace is dependent upon physical assets – power
sources, cables, networks, data centres, as well as the people who operate and
manage them. Cyber security is concerned with the protection of information and
information systems and operational systems from unauthorised access, harm, or
misuse .
There are several properties that factor into cyber security of the submarine, and
these should be considered when assessing the cyber security risks.
If systems are insecure, they are at risk of malicious acts or compromise and a
concerted attack may trigger safety events. Failure to make systems secure might
contravene regulatory safety requirements. In other scenarios a Safety issue, such
as a shipboard fire or other incident , may trigger security events. Failure to
adequately model and plan for safety incidents might contravene security
requirements [12].
Property Definition
Safety To ensure systems are not hazardous to crew/ workers and the public.
Security Security is the protection of valuable assets, both tangible and
intangible, from threats such as espionage, terrorism, and other breeches. Security
is divided into disciplines including Personnel, Physical, Information and Cyber.
Cyber Security To protect information and information systems and operational
systems (together with the data they hold and the services they provide) from
unauthorised access, harm, or misuse.
Availability To ensure information and systems can be accessed when needed.
Confidentiality To ensure the information remains private.
Integrity To ensure information and systems are consistent and are not corrupted.
Resilience To ensure failure can be recovered from with limited to no impact on
operations.
Operability To ensure a system is in a usable and functioning condition and is
reliable when in use.

5.1 Confidentiality, Integrity, and Availability

Cyber security risk assessments must consider the whole boat safety impact. PTs
should note the differences between the effect of Confidentiality, Integrity, and
Availability (CIA) on security and safety when considering security implications.
When considering security risk, the CIA Triad is fundamental to deciding the
importance of a capability to the wider business when prioritising its efforts to
manage risk exposure. Qualifying CIA provides a means for the business to
articulate the importance of protecting the capability or business process.
Assessment through the quantification of CIA is used to guide and inform security
policy and enables the assessment of security risk exposure, whilst also providing
a platform on which to prioritise security controls in relation to other business
priorities to protect the capability . [13]
From a safety point of view - Integrity is the highest concern followed by
Availability . Normal safety assessments already deal with availability, however
cyber security has the potential to undermine some of the assumptions in the
assessment around failure rates.
5.2 Operational Technology and Information Technology
A key part of the risk assessment is understanding the impact a vulnerability may
have if exploited. Submarines have both Operational Technology (OT) and Information
Technology (IT) systems which have different cyber security postures.
The Cyber Security for Ships Code of Practice and the Guidelines on Cyber Security
Onboard Ships[14], are two of many standards that make the distinction between IT
and OT. IT and OT can be described as:
• IT systems manage data. IT covers the spectrum of technologies for
information processing, including software, hardware, and communication
technologies. Cyber security for IT concerns information confidentiality,
integrity, and availability.
• OT systems control the physical world. OT systems differ from traditional IT
systems in that the hardware and software directly monitors/controls physical
devices and processes. Disruption of the operation of OT systems may impose
significant risk to the safety of onboard personnel, cargo, damage to the marine
environment, and impede the ship’s operation. Cyber security for OT concerns
safety, reliability, and availability.
Note the convergence of IT and OT. OT systems may be connected to IT networks for
the purposes of performance monitoring, remote support, and predictive maintenance
among others.
5.3 Safety and Security Terminology
It is important to remain cognisant of the context of language being used with
regards to Safety and Security. The two areas often have similar terms applied to
them that can often have different meanings. Issues can often stem from this
inherent lack of common language so ensuring the frame of reference is correct for
content is important. The National Cyber Security Centre (NCSC) states that their
terminology is intentionally kept generalised in their cyber security and
resilience principles for managing cyber-related risks to safety and the collection
of supporting guidance due to different organisations management of cyber-related
risks to safety.[15]
Term Security Safety
Threat Cyber Threat, the threat of a cyber-attack to a user or organisation,
and the unauthorised access, theft or damage that could result.

Insider Threat, deliberate or accidental threat to an organisation's security from

someone who has authorised access (such as an employee).
Vulnerability A weakness, or flaw, in software, a system or process. An
attacker exploits these to (for example) gain unauthorised access to a computer
system
Risk Possible future outcomes that we can describe in terms of their chances of
occurrence, and the impact they would have if realised. Combination of the
likelihood of harm and the severity of that harm. [16]

Control Action to reduce the Likelihood in accordance with SubCap Directive.

Security Risk Delegation and Referral [17].
Measures that can be taken to reduce the possibility of a risk arising or to reduce
the effect of any risk that arises. The control measures in order of preference are
‘elimination, substitution, engineering controls, administrative controls and
personal protective equipment (PPE)’. [16]

Mitigation Actions that organisations and individuals can take to minimise and
address risks.
Reduce the Impact in accordance with the SubCap Directive. Security Risk Delegation
and Referral.[17]
An activity or measure that is expected to reduce the impact of a risk event should
it occur. [16]

Hazard A hazard is something that has the potential to cause harm.[28]

Initiating Event A threat to a Safeguard that arises from causes either

internal/ external or natural.[34]

Cause Internal / External/ Natural Initiating Events or System Failures that

cause damages safeguards. [34]

Safeguards Safeguards provide engineering functionality to provide Lines of

Defence against Accident Sequences.[28]

Table 1 Security and Safety Definitions

5.4 Existing Security Cases and Existing Security
As previously discussed in Section 5.1, cyber security risk assessments must
consider the whole boat safety impact. However, PTs should be able to identify
what credit / reuse of existing Product, Service and or System (PSS) information
can be utilised to ensure maximum benefit from the reuse of PSS information
delivered either through the Risk Management Accreditation Document Set (RMADS),
or the PT Security Case .
The RMADs information can impact, but does not address, the safety aspects of
cyber-risk assessment of whole boat safety impact. Existing evidence should be re-
used wherever practicable alongside the existing safety cases to marry identified
cyber security risks with identified safety/security risks to complete Preliminary
Cyber Security Risk Assessments as soon as practicable.
5.5 Causes of Safety and Cyber Risks
There could be multiple interactions between the assessment of Safety and Cyber
Risks.
These could be:
• A new Cyber initiating event to an existing cause;
• A new cause to an existing hazard;
• An impact on a safety mitigation;
• An impairment to the recovery from a hazard;
• A new safety risk;
• A new cybersecurity threat.

Some identified causes that directly affect both security and safety risks are
identified below and could be used as a cross check with PTs on the completeness of
their Safety and Security assessments. This list is not exhaustive.
5.5.1 Insider Threat:
• Sabotage – deliberate introduction of ransomware, malware into systems or
destruction of critical components which impact on the mission and could cause loss
of life / submarine.
• Accidental introduction of ransomware, malware through poor maintenance
practices submarine through loss of critical information which may impact on the OT
so that it cannot operate safely.
5.5.2 Supply Chain Security :
• Attacks on suppliers and vulnerabilities built into the supply chain
components which can later be exploited may affect the overall function of the
submarine. The submarine may use a piece of OT hardware that only the supplier can
maintain and update or the supplier may have built in an unknown remote access
route. This introduces several risks:
 The OT hardware breaks whilst at sea and cannot be fixed meaning the
submarine is stranded for several days.
 The supplier network is breached, and the attacker uses the remote access
route to shut down the operation of the OT hardware making the submarine unable to
operate safely.
 The supplier goes out of business leaving the organisation operating the OT
hardware with no updates or maintenance which makes it vulnerable to attack or
unable to operate until new hardware / software is installed.
5.5.3 Technical and Electronic attack:
• TEMPEST attack using equipment to pick up side-band electromagnetic
transmissions from electronic devices to recover data about what the device is
doing based on things such as the unintentional transmissions that most electronic
devices will emit when in use.
• Poor software, firmware or hardware maintenance practices lead to risks that
unpatched vulnerabilities in OT and IT may be used by an attacker to compromise the
safe operation of the submarine.
• Phishing: fake servers / websites set up to trick individuals to enter their
credentials into a website that looks like the real thing.
5.5.4 Network attack:
• Shoreside port infrastructure attacks using social engineering with a browser
credential stealer to gather credentials for accessing more sensitive systems and
networks.
5.5.5 Unauthorised access to equipment / systems.
• Unauthorised personnel gain access to the submarine and compromise the system
/ equipment by attaching a laptop to download malware or physically destroy /
damage the components.
5.6 Secure by Design
Secure by Design (SbD) is a principle in that emphasises the importance of
integrating security flaws and best practise throughout the acquisition lifecycle.
Instead of treating securities as an afterthought or something that can be added
once a system is fully operational, secure by design focuses on bedding security
from the very beginning of the design phase the goal is to reduce vulnerabilities
ensure that system resilient against potential threats or attacks from the outset.

5.6.1 Secure by Design Implementation.

SbD is a mandated revised approach to ensure cyber security and resilience are
delivered and managed in Defence in accordance with RNTM 05-016/24 Royal Navy
Secure by Design and Information Assurance [18]. Timelines for transition to Secure
by Design are as follows:

a. All new programmes have been subject to SbD from 28 Jul 23.
b. All programmes in Concept phase should have transitioned to Secure by Design
by 31 Dec 23.
c. Programmes that are in the Assessment, Demonstrate or Manufacture phases
shall transition to SbD before 31 Jul 24.
d. In-Service capabilities whose accreditation expires before 31 Jul 24 can re-
accredited for a maximum of 12 months and transition to SbD when their
accreditation subsequently expires.
e. In-Service capabilities whose accreditation expires after 31 Jul 24 should
plan to transition to SbD as soon as possible. Planning should consider that
necessary work to transition will take time and therefore must be started before
accreditation expiry.
6 Roles and Responsibilities
6.1 Roles and Responsibilities
Roles and Responsibilities within a delivery team, with regards to risk which have
an implication upon both Safety and Security, can vary on a project basis. JSP440
Leaflet 5C [19] defines the following Security roles with their respective
responsibilities in accordance with SbD principles.
In the Submarine cyber environment, the risk owner is either the Defence Nuclear
Organisation (DNO) or the Navy Command Senior Responsible Owners (SRO) [19] and the
relevant equipment or safety case owners are responsible for the risk mitigation
controls put in place.
The potential safety impacts resulting from cyber risk need to be understood and
managed. Cyber risk may affect a cause, control hazard or accident so both the
safety and security teams must liaise to ensure that the effect of potential cyber
risks on the safety of the submarine are captured within the system risk register.
Roles and responsibilities on a project must be defined and documented. Safety
teams should document this within a RACI (Responsible, Accountable, Consulted,
Informed) chart within the project SEMS. Security teams should document this within
the project Security Case.
Documented post holders remain accountable but may delegate responsibility for risk
toleration within their organisation, however the risk should be owned at the
appropriate level in accordance with JSP 892 Risk Management. [20]
6.2 Cross Team Collaboration
Security and Safety teams need to collaborate, throughout the acquisition
lifecycle, to enable Security risks affecting Safety and Safety risk affecting
Security to be fully included in the Security and Safety Analysis and maintain
alignment throughout the process.
PTs/ DTs need to identify early in a project lifecycle where the touchpoints are
between cybersecurity and safety are where information must be exchanged, and
activities should be performed, and co-assurance achieved. These touchpoints
between the 2 domains and risk assessments to ensure that the necessary and
relevant collaboration occurs and should be outlined in the Project Management Plan
and Stakeholder Matrix. These should be inclusive of, but not limited to, all areas
of the Defence Lines of Development (DLoDs); Training, Equipment, People,
Infrastructure, Doctrine, Organisation, Information and Logistics.
Although PTs/DTs should hold their own Safety and Security risk registers, as shown
in Section 6.3 they should document their risks where there is overlap and knock on
effects and dependencies upon one another.
PTs own, track, and manage their own risks with the Senior Responsible Owner (SRO)
taking ownership of the associated project Cyber Security, as the Accountable
Person (AP) does for the Safety risks.
6.2.1 Safety and Security Interaction
A risk which is deemed to adversely affect the integrity and availability of a
Platform, should be considered as both a Security and a Safety Risk.
The Security team is to assess the platforms Programmable Elements (PE) for viable
attack paths and introduce Cyber Controls and to liaise with Safety team to assess
the impact to overall Platform Safety. The Safety team seeking to reduce those
risks to ALARP and report residual risk to the Platform Authority (PA).
Conversely Safety Analysis may identify new mitigations to reduce Safety risk which
may introduce a new vulnerability and will subsequently need to be assessed by the
Cyber Team.
These 2 risks could produce a conflict in how to mitigate either the Safety or
Cyber Risk.
6.3 Risk Registers/ Hazard Logs
Cyber Security and Safety risk registers may be held at different classifications.
As such risk classifications must be considered when transposing them between
registers, ensuring risks are carried or referenced in the correct documentation as
per their respective classification. Teams are to be cognisant; they can reference
a Security Risk in their register using unique identification numbers without a
need to raise the classification of the document to that of the associated risk.
It is still important that enough information is contained within the respect risk
registers such that it is meaningful but without making them unusable. It may be
necessary to include a cross reference between the two sets of documentation.
6.4 Safety and Security Representation in Committees
To ensure there is appropriate liaison between both cybersecurity and safety it is
recommended that security representation is made part of the appropriate safety
committees / working groups and vice versa. This will ensure that the relationship
between the two domains remains.
6.5 Security Defined Roles and Responsibilities
The SRO is accountable for making IA decisions however, PTs should have at least
one delegated individual who is responsible for making Information Assurance (IA)
decisions as shown in Table 1. When identified risks also have an impact upon
Safety there must be engagement with the PA in accordance with DSA02-DMR Regulation
208.
Role Responsibility
Capability Sponsors Hold responsibility for the sponsorship of the capability,
its requirement development, concept of operation and ensuring the capability can
address the risks in-service.
Senior Responsible Owners (SROs) Accountable for the delivery of cyber secure
outcomes throughout the capability lifecycle, must ensure that appropriate and
effective governance and procedures are in place within their areas of
responsibility to implement cyber security controls from the outset of programmes
as a critical development and identify, record, and manage cyber risks throughout
the whole lifecycle of the system.
Likely also to be the Senior Accountable Person in accordance with DSA02-DMR.
Project/ Delivery Team Leaders Responsible for the development and delivery of
secure capabilities that support Defence Outcomes throughout the capability’s
lifecycle.
Capability Owners In-service owners of the capability and are responsible for
operating the capability to support Defence Outcomes.
Commercial Officers Responsible for the implementation of contract terms and
conditions in the MOD that ensure that security is enforced throughout the
capability’s lifecycle
Project/ Delivery Team Security Leads Individuals within the Delivery Team
responsible for advising Delivery Team Leaders on security and risk management.
Cyber Security Assessors Responsible for independent assessment of PT’s
adherence to SbD and relevant risk and security policies and standards. They
coordinate between PTs dealing with similar security challenges to optimise
solutions and minimise duplication of effort. They are responsible for consistent,
coherent advice and support to relevant capabilities
Table 2 SbD Defined Roles and Responsibilities
6.6 Safety Roles and Responsibilities
Safety Roles are defined within DSA02-DMR and throughout the individual projects
Safety Baseline in accordance with CD SEMS 3.0.03 HSEP - Organisational Baseline
Process [21] and safety roles defined in CD SEMS 3.1.03 Safety - SQEP Process [22].
The safety roles are shown in Table 2.
Role Responsibility
Senior Accountable Person DSA02- DMR Regulation 203- The Senior Accountable
Person in each organisation shall have ultimate accountability for safety and
environmental protection of their organisation’s Defence Maritime Activities, and
compliance with the Defence Maritime Regulations.
Likely to be the SRO as defined in JSP440 Leaflet 5C [19].

Accountable Person DSA02- DMR Regulation 204- The Accountable Person shall
assure the Senior Accountable Person that the Health, Safety and Environmental
Management System(s) for Defence Maritime Activities are fit for purpose.
Platform Authorities DSA02- DMR Regulation 208- Accountable Persons shall have
Platform Authorities, or equivalents, responsible to them for ensuring all Ships
within their Area of Responsibility are safe to operate by providing safety and
environmental protection assurance of the design, system and equipment integration,
and through-life support.
Executive Safety Responsible (ESR) Corporate responsibility for material safety of
submarines / systems /equipment.
Ensures safety is funded, carried out by competent people and assured in accordance
with CD SEMS 3.1.03 Safety - SQEP Process [22]

Senior Safety Responsible (SSR) Primary authoritative Duty Holder interface.

Final safety sign-off before Submarines or Complex multi-platform Systems are
released to the Duty Holder.
Responsible for Safety Case, Lifecycle development of a class of major system /
equipment in accordance with CD SEMS 3.1.03 Safety - SQEP Process [22]

Safety Responsible (SR) Makes safety-related decisions affecting System or

Submarine Safety on behalf of the SSR.
Point of escalation of decision making for SD.
Escalates non-delegated decision-making to SSR in accordance with CD SEMS 3.1.03
Safety - SQEP Process [22]

Safety Delegated (SD) Makes limited safety-related decisions within clearly

defined boundaries, on behalf of SR or SSR, supporting the Duty Holder.
Escalates non-delegated decision-making to SR in accordance with CD SEMS 3.1.03
Safety - SQEP Process [22]

Safety Core (SC) Makes appropriate contribution to safety that is in accordance

with assignment.
Includes skilled practitioners who contribute to key systems in accordance with CD
SEMS 3.1.03 Safety - SQEP Process [22]

Table 3 Safety Roles and Responsibilities

6.7 Safety Managers
Individual PT Safety Managers have the duty to adhere to the requirements in DSA02
and other Defence Standards. Guidance on how they should proceed, both initially
and moving towards the inclusion of a compliance case in their respective SEMPs, is
provided in this document and will be supplemented by a separate guidance
process/note which will include the interfaces required with security
personnel/SME’s.
6.7.1 Training
Safety practitioners and safety delegated individuals for each PT must be suitably
trained in cyber security protocols for the exposure to IT systems that their role
entails. It is the requirement of accountable individuals for cyber security to
ensure that the delegated responsible individual is suitably qualified and
experienced to undertake cyber security assessments and to ensure that they
undertake regular training to remain current with best practice.
FAP 01- Assess what training is required and where this process sits to train
staff.
7 Triaging Process
Individual PTs, that comply with DSA02-DMR, must individually consider whether
their equipment or facilities fall within the assessment required by DMR Notice
03/2020 [3], noting the inclusion of cyber requirements and implications on the
systems affecting safety in question.
7.1 SDA Proportionate Approach to Assessing Cyber Safety Risks
As much of the equipment in the SDA is In-Service, it is not appropriate to mandate
following SbD development process for equipment that has already been designed,
manufactured, commissioned and in-service.
Therefore, the SDA has adopted a proportionate approach to undertaking Cyber and
Safety risk assessment dependant on the PTs lifecycle based around an assessment of
equipment, before commencing any Safety Cyber Assessment the following Triaging
process should be followed shown in Figure 3 Triaging Process.

Figure 3 Triaging Process

7.1.1 New platform- SSN(AUKUS)/ AUV.
Following the Process in Figure 3, for new platforms, must be developed in
accordance with incorporating SbD Principles incorporating Safety and Cyber Risk
Assessments throughout the Acquisition lifecycle in accordance with process CD-
SEMS- 4.1.06 Safety- Secure by Design Guidance. [24]
7.1.2 New build existing platform design- Dreadnought SSBN.
Under the previous Policy [23] Dreadnought was treated as a new platform, which
meant to fully comply with the DMR Notice 03/2020 [3] and therefore using the logic
in Section 5.6 incorporate Secure by Design Principles incorporating Safety and
Cyber Risk Assessments throughout the Acquisition lifecycle in accordance with
process CD-SEMS- 4.1.06 Safety- Secure by Design Guidance. [24]
7.1.3 Alteration and Amendment
For existing platforms undertaking a complex modification, then a full assessment
of Safety and Cyber Risks will need to be developed in accordance with
incorporating SbD incorporating Safety and Cyber Risk Assessments throughout the
Acquisition lifecycle in accordance with process CD-SEMS- 4.1.06 Safety- Secure by
Design Guidance. [24]
7.1.4 Class Modification/ Minor Trial
For existing platforms undertaking a simple modification then a Baseline Assessment
can be undertaken iaw Section 7.1.5.
7.1.5 Existing platform / system in service. Trafalgar, Vanguard and Astute.
This process for In-Service equipment and Class Modifications and Minor Trials is
determined to meet the intention of DMR Notice 03/2020 [3] for In-Service
equipment, without following a formal SbD development process. A Safety Security
Baseline assessment must be undertaken for equipment. A risk assessment must be
completed, and a compliance case against this process produced.
Due to the volume of platforms and systems, the PTs should take a broad view across
all equipment and allocate resource to areas prioritised by a combination of safety
and operational risk.
The Safety Security Baseline Assessment process is shown in Section 8.
7.1.6 Decommissioned Platforms/ Systems/ Components.
During decommissioning and disposal activities it is required that articles on
board vessels that contain programmable elements are managed and disposed of in a
manner appropriate for the importance of that article to the safety and security of
historical and ongoing defence operations.
8 Safety and Cyber Security Baseline Assessment
The following process should be followed for developing a Safety and Cyber Security
Baseline Assessment, for new projects and major modifications please use CD-SEMS-
4.1.06 Safety- Secure by Design Guidance. [24]
8.1 Plan
PTs should produce a Forward Action Plan to assess risk and produce a Compliance
Statement in accordance with this process shown in Section 8.2.
8.2 Process
For equipment for projects assessed from Figure 3 Triaging Process, the SDA
requires PTs assesses Safety and Cyber security Risks use the following process.
This is based on the process from the of the IET Cyber Security Code of Practice
for Ships [14].
8.2.1 Assumptions
It is assumed that the existing safety control and mitigations, lead to an
acceptable level of safety risk. This process will only look at Cyber impacts on
Safety risks and Safety impacts on Cyber risks and does not seek to replace project
teams Hazard Management processes in ensuring that safety risks due to Whole Boat
Hazards are Tolerable and ALARP.
The overall approach is shown in Figure 4.

Figure 4 Overall Safety Cyber Security Process

8.2.2 Identification and evaluation of important assets and infrastructure.
This step lists the equipment containing Programmable Elements (PE) on-board the
platform, where the failure or unspecified behaviour of the software could credibly
lead to either: a Whole Boat Hazard being impacted, impair the mitigation or the
recovery from a Whole Boat Hazard, then it is considered for this Safety Cyber
Security Assessment; else the assessment ends.
The intention is to re-use as much existing analysis as possible, therefore setting
the level of analysis is important as it sets the quantity of additional work
required. There could be either existing safety or security analysis that could be
pulled through and reused to reduce the workload. The level of analysis could be
component, equipment, or system level and would therefore be heavily dependent on
what level the existing safety and security assessments are centred around.
The list of equipment are prioritised with respect to their impact on Safety.
8.2.3 Identification and assessment of Security Risks arising from potential
threats and vulnerabilities.
A Cyber Security risk assessment may already exist and therefore based on reuse for
existing equipment as defined in Section 8.2.2.The security risk assessment as
detailed in Section 8.2.3, 8.2.4, and 8.2.7 may already have been undertaken for
the equipment and should be used if possible.
From this list, an initial qualitative Security Risk assessment is performed. This
takes the equipment, determined from Section 8.3.1, and asks a series of questions
resulting in a qualitative assessment of the relative threat level to Security Risk
posed by that equipment.
A determination is made whether the equipment presents an acceptable or
unacceptable security risk. If the security risk is acceptable then no further
assessment is made; if it is unacceptable then it proceeds to the next step.
8.2.4 Undertake Cyber Risk Assessment.
This step takes those assessed as unacceptable previously and generates further
information for the risk assessment and identifies threat paths and security
measures to further determine the security risk.
The purpose of the risk assessment is to assess the relevance of identified
security risk scenarios by determining the consequence of the impact and likelihood
of it occurring. These values will enable the SRO or delegated person to consider
the risk in context.
Cyber Risk = Impact (Value x Criticality) x Likelihood (Threat x Vulnerability).
As shown in the Risk equation in Figure 5 and Risk Assessment Criteria in shown in
Figure 5.

Figure 5 Cyber Risk Equation

As outlined above, the risk is defined as the impact an incident would have
combined with the likelihood of a cyber related incident occurring where;
• Impact is a function of the severity to the mission or operational capability
should it happen and,
• Likelihood is a function of the identified threats, vulnerabilities, system
exposure and the mitigation security controls that have been put in place.
Likelihood is derived from the threat level assessed for a particular threat type
and the vulnerability of the asset to that threat as shown in Figure 6.
8.2.5 Review acceptability of overall Security risk.
Figure 6 below shows the risk assessment categorisation matrix as described in the
SubCap Directive. Security Risk Delegation and Referral [17] This matrix has been
overlaid with a graphic to demonstrate how the implementation of adequate security
controls, mitigations and risk response plans can lower risk level.

Figure 6 Risk Assessment demonstrated in the SubCap Directive. Security Risk

Delegation and Referral.[17]
8.2.6 Review Impact on Safety Risk
As a final stage any implemented Security Controls should be viewed as an Impact on
Safety Risks.
The level of analysis is important as discussed in Section 8.2.2 as the impact of
the Security Control or Mitigation could be assessed against the existing equipment
safety baseline.
The assessment of the Safety Risk can be managed as per normal processes CD SEMS
3.1.01 Safety - Safety Risk Process[25] and CD SEMS Level 4.1.1 Safety - ALARP
Guidance[26]. The Tolerability of Risk (ToR) Submarine Risk Classification Matrix
as shown in Figure 7.

Figure 7 Safety Risk Assessment Matrix from ToR(SM)

8.2.7 Equating Safety and Cyber Risks
There is no intention in this process of linking Cyber risks and Safety risks on a
matrix as they are measuring different properties, and they should be viewed
independently. There are different definitions of equating probabilities /
likelihoods. Safety uses quantitative based probabilities (see Def Stan 00-056),
cyber uses vulnerabilities and threats. (see JSP440, Part 2, V6.0, Leaflet 2)).
Similarly, there may be challenges in defining severities and impact in terms of
risk in the safety and cyber environments. Safety uses degrees of harm (see Def
Stan 00-056), security tends to use effect on performance (see JSP440, Part 2,
V6.0, Leaflet 2).
8.3 Conflict Resolution
Following the process on Figure 4 may generate a conflict that will need to be
resolved at an appropriate level between mitigating a Security Risk and mitigating
a Safety Risk, a Security Risk mitigation may increase the Safety Risk or vice
versa.
As previously mentioned in Section 8.2.7, Safety and Cyber Risks are measuring
different properties and should not be plotted on the same matrix to help to make a
decision.
The appropriate Risk Owners are defined in Section 6.5 and Safety Roles defined in
Section 6.6, risk escalation from the SRO is shown in Figure 6, whereas the PA is
the Platform Safety Risk Owner for ‘Safe to Operate’ hazards.
Should there be a conflict between Security and Safety disciplines then the
Principal Design Organisation (PDO) should make the appropriate risk-based
decision, as defined in CD SEMS Level 4.1.5 Safety - Top Level Safety Decision
Making Issue 2.0 May 23 [27]. The PDO is the organisation with the responsibility
to understand and maintain the design integrity with whole lifecycle consideration
for all aspects (capability, safety, security, and environment) within the PDO
scope.
The Cyber risk and Safety risk should be assessed and an appropriate decision forum
taking inputs from the necessary Safety and Security Teams, referring to the
appropriate risk owner and taking into account the ALARP principle as detailed in
CD SEMS Level 4.1.1 Safety - ALARP Guidance[26]. This process should be no
different to other optimisations to be undertaken throughout the design process.
8.4 Compliance Statement
It is necessary to ensure that appropriate evidence and / or artefacts exist to
support any claims made in the Safety Case over the implementation of the
requirements of DMR Notice 03/2020 [3].
The normal artefacts and system safety processes should be used, and a statement
made on the Safety Risk that Cyber impacts have been considered.
It is recommended that where a safety impact may arise from a cyber-risk that this
is recorded in the safety Hazard Log including a reference to where that arose
within the security domain. Such a reference allows traceability and auditability
between the Safety and Cyber Domains.
There is no requirement to create Compliance Case.
9 References
1. JSP 815 Defence Safety Management System.
2. DSA-02 DMR Defence Maritime Regulations.
3. Defence Safety Authority - Defence Maritime Regulator, Defence Maritime
Regulator Notice 03/2020 - Defence Maritime Cyber Risk Management, Defence Safety
Authority, 3 Sep 2020.)
4. Department for Transport Cyber Security Code of Practice for Ships July 2023
5. Baltic and International Maritime Council (BIMCO), Cruise Lines International
Association (CLIA), International Chamber of Shipping (ICS), International
Association of Dry Cargo Shipowners (INTERCARGO) et al, The Guidelines on Cyber
Security Onboard Ships, Version 3, 2018. (https://iumi.com/uploads/2018-
Cyber_Security_Guidelines.pdf)
6. JSP 440, Defence Manual of Security and Resilience, Version 7, August 2020.
7. SDA Cyber Security Related SEMS Policy, Version 0.1, January 2021.
8. SDA Cyber Security and Safety Risk Alignment Guidance, Version 0.3, February
2024,Version 0.3.
9. SDA Cyber Security Related SEMS Policy – Approach To Compliance Case dated 31
March 2022.
10. CD- SEMS-Level 4.0.1 HSEP CECT Documentation Management.
11. JSP 376 Defence Acquisition Safety Policy.
12. Rail Cyber Security, Guidance to Industry, Department for Transport (DfT),
February 2016
13. Cyber Security and Safety, Code of Practice, The Institute of Engineering and
Technology (IET), 2021
14. The Institute of Engineering and Technology (IET). (2017). Cyber Security for
Ships - Code of Practice.
15. National Cyber Security Centre, Advice & Guidance,
https://www.ncsc.gov.uk/section/advice-guidance/all-topics. (Last Accessed
19/01/22)
16. Management of health and safety in defence: Master glossary referenced from
JSP376 Defence Acquisition Safety Policy.
17. SUBCAP DIRECTIVE 04/22 - SECURITY RISK DELEGATION AND REFERRAL, 20/12/2022
18. RNTM 05-016/24 Royal Navy Secure by Design and Information Assurance dated 14
May 24.
19. JSP 440, Part 2, Leaflet 5C, Building Cyber Secure by Design Capabilities,
Version 7.2, November 2023.
20. JSP 892, Risk Management, Version 3, December 2022.
21. CD SEMS 3.0.03 HSEP - Organisational Baseline Process
22. CD SEMS 3.1.03 Safety - SQEP Process.
23. SDA Cyber Security Related SEMS Policy, Version 0.9, January 2022.
24. CD-SEMS- 4.1.06 Safety- Secure by Design Guidance TBC
25. CD SEMS 3.1.01 Safety - Safety Risk Process December 2023.
26. CD SEMS Level 4.1.1 Safety - ALARP Guidance Feb 2024.
27. CD SEMS Level 4.1.5 Safety - Top Level Safety Decision Making Issue 2.0 May
23.
28. Tolerability of Risk from Submarines (ToR (SM)) Version 2. MAP 01-126 dated
May 2019
29. Defence Standard 00-056, Safety Management Requirements for Defence Systems,
Part 1: Requirements, Ministry of Defence, Issue 7, 28th February 2017.
30. Defence Standard 05-138, Cyber Security for Defence Suppliers, Issue 2, 28
Sep 2017.
31. Ministry of Defence Knowledge in Defence (KiD), Cyber Security, Cyber and
Defence - Cyber Security - KiD - UK MOD (mil.uk). (Last Accessed 19/01/22)
32. Tolerability of Risk from Submarines - MAP 01 - 126 TOR (SM), Version 2,
dated Sep 2019.
33. Secure by Design. Retrieved from
https://en.wikipedia.org/wiki/Secure_by_design.
34. CD- SEMS- Level 4.1.02- Safety Design Basis Guidance [In Draft].

Annex A SDA Safety Security Landscape

Figure 8 Overview of SDA Safety / Security Landscape

There are a plethora of standards for the Supply Chain (Defence Standards) to
follow in Safety and Cyber Security which form a patchwork of semi-applicable
standards. Unfortunately, none of the standards are wholly applicable to the
Submarine Safety and Cyber Domain.
Standard Description with Respect to Safety and Cyber Risks
Defence Def-Stan 00-056 Def-Stan 00 -056 [29] has limited guidance for how
to consider cyber security for safety. The principal requirements require a
contractor to ensure cyber security is considered where security breaches may be a
contributory cause of a hazard and of a failure mode respectively.
Defence
Def-Stan 05-138
Provides requirements and guidance for the levels of cyber protection required to
be achieved by Defence Suppliers. It should be noted that Def Stan 05-138 [30] is
a key component of the demonstration of cyber security but it is focussed on
Information Technology (IT) whereas most SDA systems are Operational Technology
(OT).
Defence

Def-Stan 00-055
The requirements and guidance for the achievement, assurance, and management of
safety of Programmable Elements (PE) within Products, Services and Systems (PSS).
It also encourages the use of open, civil standards where possible.
Open

IEC 61508
However, it explicitly warns that the PE open standards including International
Electrotechnical Commission (IEC) 61508, referred to in Def-Stan 00-055, do not
meet the full military requirements including for cyber security – indeed, IEC61508
specifically states that it does not cover cyber security aspects.
Open IEC 62443 Therefore, suitable alternative guidance and open standards
should be considered to ensure full compliance with Def-Stan 00-056. IEC 61508,
however does further refer to IEC 62443 which requires systems to be “secure by
design”. The cyber security principles advocated by the NCSC Advice & Guidance
webpage should be a reference point for “secure by design”.
Open RTCA DO-326A Aerospace Recommended Practice (ARP) 4754A, ARP 4761, DO-178C,
and DO-254 Additional open standards could be pertinent to both Astute Build,
Dreadnought and SSNR.

RTCA DO-326A is an aerospace standard that addresses cyber security safety

associated with the open standards that are in use for some key elements of the
Dreadnought design. Consequently, it may be appropriate to consider the safety
related cyber security standard most appropriate to the standards that any
Programmable elements were designed to
Table 4 Applicable Standards

From this assessment one could deduce that following Safety Standard DefStan 00-56,
which references 00-55 and open standards IEC61508 and IEC 62443 Cyber Security
Standard requires systems to be “Secure by Design”, therefore following a Cyber
Security Standard requiring Secure by Design with relevant linking between the
styles of 2 assessment.