Automotive SPICE for Cybersecurity Process Reference and Assessment Model

Quality Management in the Automotive Industry

Automotive SPICE^®

Process Reference and Assessment

Model for Cybersecurity Engineering

Title:	Automotive SPICE® for Cybersecurity Process Reference and Assessment Model
Author(s):	VDA QMC Project Group 13
Version:	1.0
Date:	2021-07-16
Status:	PUBLISHED
Confidentiality:	Public

Copyright Notice

This document is a supplement to the Automotive SPICE Process Assessment Model 3.1. It has been developed by the Project Group 13 of the Quality Management Center (QMC) in the German Association of the Automotive Industry.

This document reproduces relevant material from:

• ISO/IEC 33020:2015

  Information technology – Process assessment – Process measurement framework for assessment of process capability

ISO/IEC 33020:2015 provides the following copyright release statement:

‘Users of this International Standard may reproduce subclauses 5.2, 5.3, 5.4 and 5.6 as part of any process assessment model or maturity model so that it can be used for its intended purpose.’

Relevant material from this standard is incorporated under the copyright release notice.

The Automotive SPICE^® for cybersecurity Process Assessment Model may be obtained free of charge via download from the www.automotivespice.com website.

Trademark

Automotive SPICE^® is a registered trademark of the Verband der Automobilindustrie e.V. (VDA).

For further information about Automotive SPICE^® visit www.vda-qmc.de.

Table of Contents

List of Figures

Figure 1 — Process Assessment Model Relationship ……………………………………………… 10

Figure 2 — Automotive SPICE and Automotive SPICE for Cybersecurity Process Reference Model – Overview . 11

Figure 3 — Possible Levels of Abstraction for the Term “Process” ……………………………….. 17

Figure 4 — Performing a Process Assessment for Determining Process Capability ……………………. 18

Figure 5 — Bidirectional traceability and consistency …………………………………………. 74

List of Tables

Table 2 — Primary Lifecycle Processes – ACQ ………………………………….. 12

Table 3 — Primary Lifecycle Processes – SPL ………………………………….. 13

Table 4 — Primary Lifecycle Processes – SEC ………………………………….. 13

Table 5 — Primary Lifecycle Processes – SYS ………………………………….. 13

Table 6 — Primary Lifecycle Processes – SWE ………………………………….. 14

Table 7 — Supporting Lifecycle Processes – SUP ……………………………….. 14

Table 8 — Organizational Lifecycle Processes – MAN ……………………………. 15

Table 9 — Organizational Lifecycle Processes – PIM ……………………………. 15

Table 10 — Organizational Lifecycle Processes – REU …………………………… 15

Table B.1 — Structure of WPC Tables …………………………………………. 47

Table B.2 — Work Product Characteristics …………………………………….. 48

Table C.1 — Terminology ……………………………………………………. 67

Table C.2 — Abbreviations ………………………………………………….. 72

Introduction

Scope

The UNECE regulation R155 requires, among others, that the vehicle manufacturer identify and manage cybersecurity risks in the supply chain. Automotive SPICE is a process assessment model, when used with an appropriate assessment method, which helps to identify process-related product risks. To incorporate cybersecurity-related processes into the proven scope of Automotive SPICE, additional processes have been defined in a Process Reference and Assessment Model for Cybersecurity Engineering (Cybersecurity PAM).

Part I of this document supplements the Automotive SPICE PAM 3.1 enabling the evaluation of cybersecurity-relevant development processes.

A prerequisite for performing an assessment using the Automotive SPICE for Cybersecurity PAM is the existence of an ASPICE assessment result for the VDA scope with a comparable assessment scope. Otherwise, an assessment using both the Automotive SPICE for Cybersecurity PAM and ASPICE PAM for the VDA scope processes has to be performed.

Part II of this document complements the existing Automotive SPICE Guideline (1^st edition). It contains interpretation and rating guidelines for the processes defined in Part I. Chapters 1 and 2 of the Automotive SPICE Guideline (1^st edition) also apply to Part II and therefore are not repeated here.

Annex B contains a subset of Work Product Characteristics that are relevant for the processes of Automotive SPICE for Cybersecurity.

Annex C contains a subset of terms that are relevant for the processes of Automotive SPICE for cybersecurity.

NOTE: this free download version does not contain Part II and Annex D of this document.

Statement of Compliance

The Automotive SPICE process assessment and process reference models conform with ISO/IEC 33004:2015, and can be used as the basis for conducting an assessment of process capability.

ISO/IEC 33020:2015 is used as an ISO/IEC 33003-compliant measurement framework.

A statement of compliance of the process assessment and process reference models with the requirements of ISO/IEC 33004:2015 is provided in Annex A.

Relation to ISO/SAE 21434

The purpose of an Automotive SPICE assessment is to identify systematic weaknesses in the primary life cycle processes, management processes, and support processes.

Automotive SPICE PAM3.1 and Automotive SPICE for Cybersecurity are covering system engineering and software engineering. Indicators for mechanical engineering and hardware engineering are not part of the current Automotive SPICE PAMs.

Certain aspects of the ISO/SAE 21434 are not in the scope of this document, as they are not performed in a development project context. They are addressed by the Automotive Cybersecurity Management System (ACSMS). These aspects, such as cybersecurity management, continuous cybersecurity activities, and post-development phases are subject to an audit of the cybersecurity management system.

The capability determination of processes for distributed cybersecurity activities, concept development, product development, cybersecurity validation, and threat analysis and risk assessment is supported by this document.

Project-dependent cybersecurity management is supported as follows:

• Cybersecurity responsibilities: GP 2.1.5 – Define responsibilities and authorities for performing the process.

• Cybersecurity planning: GP 2.1.2 – Plan the performance of the process to fulfill the identified objectives and MAN.3 Project Management.

• Tailoring of cybersecurity activities: PA 3.2 – Process deployment and GP 2.1.2 – Plan the performance of the process to fulfill the identified objectives.

• Reuse: included in make-buy reuse analysis SWE.2.BP6 – Evaluate alternative software architectures, SYS.3.BP5 – Evaluate alternative system architectures and REU.2 – Reuse Program Management.

• Component out of context: covered by Cybersecurity Engineering Process Group (SEC) based on assumptions regarding cybersecurity goals.

• Off-the-shelf component: ACQ.2 – Supplier Request and Selection and MAN.7 – Cybersecurity Risk Management.

• Cybersecurity case: input provided by base practices “summarize and communicate result” of engineering processes.

• Cybersecurity assessment: ASPICE for Cybersecurity is a model for process capability determination. An in-depth technical analysis is not part of an ASPICE for Cybersecurity assessment.

• Release for post-development: SPL.2 – Product Release, SUP.8 – Configuration Management Process, and SUP.1 – Quality Assurance Process.

The term “item” as described in Annex C is used in Automotive SPICE to define an identifiable part of system or software (this might be different to its use in other standards).

Process Reference and Assessment Model for Cybersecurity Engineering

1 Process Capability Assessment

The concept of process capability assessment by using a process assessment model is based on a two-dimensional framework. The first dimension is provided by processes defined in a process reference model (process dimension). The second consists of capability levels that are further subdivided into process attributes (capability dimension). The process attributes provide the measurable characteristics of process capability.

The process assessment model selects processes from a process reference model and supplements it with indicators. These indicators support the collection of objective evidence that enable an assessor to assign ratings for processes according to the capability dimension.

The relationship is shown in Figure 1:

Fig. 13 Figure 1 — Process Assessment Model Relationship

1.1 Process reference model

Processes are grouped by category and at a second level into groups according to the type of activity they address.

There are three process categories: primary lifecycle, organizational lifecycle, and supporting lifecycle processes.

Each process is described in terms of a purpose statement. The purpose statement contains the unique functional objectives of the process when performed in a particular environment. For each purpose statement, a list of specific outcomes is associated representing the expected positive results from the process performance.

For the process dimension, the Automotive SPICE and Automotive SPICE for Cybersecurity process reference models provide the set of processes shown in Figure 2.

Fig. 14 Figure 2 — Automotive SPICE and Automotive SPICE for Cybersecurity Process Reference Model – Overview

1.1.1 Primary Lifecycle Processes category

The Primary Lifecycle Processes category consists of processes that may be used by the customer when acquiring products from a supplier, and by the supplier when responding and delivering products to the customer, including the engineering processes needed for specification, design, development, integration and testing.

The Primary Lifecycle Processes category consists of the following groups:

• the Acquisition Process Group

• the Supply Process Group

• the Security Engineering Process Group

• the System Engineering Process Group

• the Software Engineering Process Group

The Acquisition Process Group (ACQ) consists of processes that are performed by the customer, or the supplier when acting as a customer for its own suppliers, in order to acquire a product and/or service.

Table 21 Table 1 — Primary Lifecycle Processes – ACQ

ACQ.2	Supplier Request and Selection
ACQ.3	Contract Agreement
ACQ.4	Supplier Monitoring
ACQ.11	Technical Requirements
ACQ.12	Legal and Administrative Requirements
ACQ.13	Project Requirements
ACQ.14	Request for Proposals
ACQ.15	Supplier Qualification

The Supply Process Group (SPL) consists of processes performed by the supplier in order to supply a product and/or a service.

Table 22 Table 2 — Primary Lifecycle Processes – SPL

SPL.1	Supplier Tendering
SPL.2	Product Release

The Security Engineering Process Group (SEC) consists of processes performed in order to achieve cybersecurity goals.

Table 23 Table 3 — Primary Lifecycle Processes – SEC

SEC.1	Cybersecurity Requirements Elicitation
SEC.2	Cybersecurity Implementation
SEC.3	Risk Treatment Verification
SEC.4	Risk Treatment Validation

The System Engineering Process Group (SYS) consists of processes addressing the elicitation and management of customer and internal requirements, definition of the system architecture and the integration and testing at the system level.

Table 24 Table 4 — Primary Lifecycle Processes – SYS

SYS.1	Requirements Elicitation
SYS.2	System Requirements Analysis
SYS.3	System Architectural Design
SYS.4	System Integration and Integration Test
SYS.5	System Qualification Test

The Software Engineering Process Group (SWE) consists of processes addressing the management of software requirements derived from the system requirements and the system architecture, development of the corresponding software architecture, and design as well as the implementation, integration and testing of the software.

Table 25 Table 5 — Primary Lifecycle Processes – SWE

SWE.1	Software Requirements Analysis
SWE.2	Software Architectural Design
SWE.3	Software Detailed Design and Unit Construction
SWE.4	Software Unit Verification
SWE.5	Software Integration and Integration Test
SWE.6	Software Qualification Test

1.1.2 Supporting Lifecycle Processes category

The Supporting Lifecycle Processes (SUP) category consists of processes that may be employed by any of the other processes at various points in the lifecycle.

Table 26 Table 6 — Supporting Lifecycle Processes – SUP

SUP.1	Quality Assurance
SUP.2	Verification
SUP.4	Joint Review
SUP.7	Documentation
SUP.8	Configuration Management
SUP.9	Problem Resolution Management
SUP.10	Change Request Management

1.1.3 Organizational Lifecycle Processes category

The Organizational Lifecycle Processes category consists of processes that develop process, product and resource assets which, when used by projects in the organization, will help the organization achieve its business goals.

The organizational Lifecycle Processes category consists of the following groups:

• the Management Process Group

• the Process Improvement Process Group

• the Reuse Process Group

The Management Process Group (MAN) consists of processes that may be used by anyone who manages any type of project or process within the lifecycle.

Table 27 Table 7 — Organizational Lifecycle Processes – MAN

MAN.3	Project Management
MAN.5	Risk Management
MAN.6	Measurement
MAN.7	Cybersecurity Risk Management

The Process Improvement Process Group (PIM) covers one process that

contains practices to improve the processes performed in the organizational unit.

Table 28 Table 8 — Organizational Lifecycle Processes – PIM

PIM.3

Process Improvement

The Reuse Process Group (REU) covers one process to systematically exploit opportunities in an organization’s reuse programs.

Table 29 Table 9 — Organizational Lifecycle Processes – REU

REU.2

Reuse Program Management

1.2 Measurement framework

The process capability levels, process attributes, rating scale and capability level rating model are identical to those defined in ISO/IEC 33020:2015, clause 5.2. The detailed descriptions of the capability levels and corresponding process attributes can be found in Automotive SPICE PAM 3.1.

1.3 Understanding the level of abstraction of a PAM

The term “process” can be understood at three levels of abstraction. Note that these levels of abstraction are not meant to define a strict black-orwhite split or provide a scientific classification schema. The message here is to understand that, in practice, when it comes to the term “process” there are different abstraction levels, and that a PAM resides at the highest.

Fig. 15 Figure 3 — Possible Levels of Abstraction for the Term “Process”

Capturing experience acquired during product development (i.e., at the DOING level) in order to share this experience with others means creating a HOW level. However, a HOW is always specific to a particular context such as a company, organizational unit or product line. For example, the HOW of a project, organizational unit, or company A is potentially not applicable as is to a project, organizational unit or company B. However, both might be expected to adhere the principles represented by PAM indicators for process outcomes and process attribute achievements. These indicators are at the WHAT level, while deciding on solutions for concrete templates, proceedings, tooling, etc. is left to the HOW level.

Fig. 16 Figure 4 — Performing a Process Assessment for Determining Process Capability

2 Process Reference Model and Performance Indicators (Level 1)

2.1 Acquisition Process Group (ACQ)

2.1.1 ACQ.2 Supplier request and selection

Stakeholder Requirement: Supplier request and selection ACQ2

status: new safety_level: not set security_level: not set child needs: ACQ2_OUT1, ACQ2_OUT2, ACQ2_OUT3, ACQ2_OUT4, ACQ2_BP1, ACQ2_BP2, ACQ2_BP3, ACQ2_BP4

Process ID ACQ.2 Process name Supplier Request and Selection Process purpose The purpose of supplier request and selection process is to award a supplier for a contract/agreement based on relevant criteria. Process outcomes As a result of successful implementation of this process: Stakeholder Requirement: 1 ACQ2_OUT1 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: 18-50 generated by: ACQ2_BP1 evaluation criteria are established for suppliers, Stakeholder Requirement: 2 ACQ2_OUT2 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: 14-05, 15-21 generated by: ACQ2_BP2 suppliers are evaluated against the defined criteria, Stakeholder Requirement: 3 ACQ2_OUT3 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: 12-01, 14-02 generated by: ACQ2_BP3 a request for quotation is issued to supplier candidates, and Stakeholder Requirement: 4 ACQ2_OUT4 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: 02-00, 02-01, 02-50, 08-20, 14-02 generated by: ACQ2_BP3, ACQ2_BP4 contract, action, and risk mitigation plans are agreed. The supplier is contracted in consideration of the evaluation result. Base practices Stakeholder Requirement: ACQ.2.BP1: Establish supplier evaluation criteria. ACQ2_BP1 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: ACQ2_OUT1 Analyze relevant requirements to define evaluation criteria for supplier’s capabilities. NOTE 1: Criteria may consider: Functional and non-functional requirements Technical evaluation regarding cybersecurity capabilities of the supplier, including cybersecurity concepts and methods (threat analysis and risk assessment, attack models, vulnerability analysis, etc.) The organization’s capability of the supplier concerning cybersecurity (e.g., cybersecurity best practices from the development, post-development, governance, quality, and information security) Continuous operation, including cybersecurity Supplier capability and performance evidence in terms of cybersecurity obtained by supplier monitoring in previous projects Stakeholder Requirement: ACQ.2.BP2: Evaluate potential suppliers. ACQ2_BP2 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: ACQ2_OUT2 Collect information about the supplier’s capabilities and evaluate it against the established evaluation criteria. Short-list the preferred suppliers and document the results. NOTE 2: The evaluation of potential suppliers may be supported by: Summaries of previous Automotive SPICE for Cybersecurity assessments Evidence of the organizational cybersecurity management system (e.g., organizational audit results if available) Evidence of an information security management system Evidence of the organization’s quality management system appropriate/capable of supporting cybersecurity engineering Stakeholder Requirement: ACQ.2.BP3: Prepare and execute request for quotation ACQ2_BP3 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: ACQ2_OUT3, ACQ2_OUT4 (RFQ). Identify supplier candidates based on the evaluation. Prepare and issue a request for quotation including a corrective action plan for identified deviations. NOTE 3: The request for quotation may include: A formal request to conform with all customer relevant and legal standards Cybersecurity responsibilities of the supplier The scope of work regarding cybersecurity, including the cybersecurity goals or the set of relevant cybersecurity requirements and their attributes, depending on what the supplier is quoting for Action plan for identified deviations and risks Stakeholder Requirement: ACQ.2.BP4: Negotiate and award the contract/agreement. ACQ2_BP4 status: new safety_level: not set security_level: not set parent needs: ACQ2 output: ACQ2_OUT4 Establish a contract based on the evaluation of the request for quotation results, covering the relevant requirements and the agreed corrective actions. NOTE 4: Distributed cybersecurity activities may be specified within a cybersecurity interface agreement considering all relevant aspects (e.g., contacts, tailoring, responsibilities, information share, milestones, timing). NOTE 5: In case of deliverables without any support (e.g. free and open source software), an interface agreement is not required. Output work products Contract (02-00) [OUTCOME 4 (ACQ2_OUT4) ] Commitment/agreement (02-01) [OUTCOME 4 (ACQ2_OUT4) ] Interface agreement (02-50) [OUTCOME 4 (ACQ2_OUT4) ] Risk mitigation plan (08-20) [OUTCOME 4 (ACQ2_OUT4) ] Request for quotation (12-01) [OUTCOME 3 (ACQ2_OUT3) ] Corrective action register (14-02) [OUTCOME 3 (ACQ2_OUT3), 4 (ACQ2_OUT4) ] Preferred suppliers register (14-05) [OUTCOME 2 (ACQ2_OUT2) ] Supplier evaluation report (15-21) [OUTCOME 2 (ACQ2_OUT2) ] Supplier evaluation criteria (18-50) [OUTCOME 1 (ACQ2_OUT1) ] 1 (ACQ2_OUT1) 2 (ACQ2_OUT2) 3 (ACQ2_OUT3) 4 (ACQ2_OUT4) Base Practices ACQ.2.BP1: Establish supplier evaluation criteria. (ACQ2_BP1) x ACQ.2.BP2: Evaluate potential suppliers. (ACQ2_BP2) x ACQ.2.BP3: Prepare and execute request for quotation (ACQ2_BP3) x x ACQ.2.BP4: Negotiate and award the contract/agreement. (ACQ2_BP4) x Output Work Products Contract (02-00) x Commitment/agreement (02-01) x Interface agreement (02-50) x Risk mitigation plan (08-20) x Request for quotation (12-01) x Corrective action register (14-02) x x Preferred suppliers register (14-05) x Supplier evaluation report (15-21) x Supplier evaluation criteria (18-50) x

2.2 Management Process Group (MAN)

2.2.1 MAN.7 Cybersecurity Risk Management

Stakeholder Requirement: Cybersecurity Risk Management MAN7

status: new safety_level: not set security_level: not set child needs: MAN7_OUT1, MAN7_OUT2, MAN7_OUT3, MAN7_OUT4, MAN7_OUT5, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8, MAN7_BP1, MAN7_BP2, MAN7_BP3, MAN7_BP4, MAN7_BP5, MAN7_BP6, MAN7_BP7, MAN7_BP8

Process ID MAN.7 Process name Cybersecurity Risk Management Process purpose The purpose of the Cybersecurity Risk Management Process is to identify, prioritize, and analyze risks of damage to relevant stakeholders as well as monitor and control respective risk treatment options continuously. Process outcomes As a result of successful implementation of this process: Stakeholder Requirement: 1 MAN7_OUT1 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-19, 14-51, 14-52 generated by: MAN7_BP1 the scope of the risk management to be performed is determined, Stakeholder Requirement: 2 MAN7_OUT2 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-19 generated by: MAN7_BP2 appropriate risk management practices are defined and implemented, Stakeholder Requirement: 3 MAN7_OUT3 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 14-51, 14-52 generated by: MAN7_BP3 potential risks are identified as they evolve, Stakeholder Requirement: 4 MAN7_OUT4 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-19, 14-08 generated by: MAN7_BP4 potential risks are prioritized initially for estimated damage and impact, Stakeholder Requirement: 5 MAN7_OUT5 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-19, 14-08, 14-51, 15-08 generated by: MAN7_BP5 potential risks are analyzed and risks are evaluated, Stakeholder Requirement: 6 MAN7_OUT6 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 07-07, 08-14, 08-19, 13-20, 14-08, 15-08, 15-09 generated by: MAN7_BP6 risk treatment options are determined, Stakeholder Requirement: 7 MAN7_OUT7 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-14, 08-19, 13-20, 14-08, 15-09 generated by: MAN7_BP7 risks are continuously monitored and identified for relevant changes, and Stakeholder Requirement: 8 MAN7_OUT8 status: new safety_level: not set security_level: not set parent needs: MAN7 output: 08-14, 08-19, 13-20, 14-08, 15-09 generated by: MAN7_BP8 corrective actions are performed on relevant changes. Base practices Stakeholder Requirement: MAN.7.BP1: Determine cybersecurity risk management scope. MAN7_BP1 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT1 Determine the scope of the cybersecurity risk management to be performed including project and project assets with cybersecurity properties, damage scenarios, relevant stakeholders, impact categories and related product phases. Determine the scope in accordance with its operational environment and organizational risk management policies. NOTE 1: Cybersecurity properties of assets include confidentiality, integrity and availability. NOTE 2: Typical impact categories are safety, financial, operational and privacy. Stakeholder Requirement: MAN.7.BP2: Define cybersecurity risk management practices. MAN7_BP2 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT2 Define appropriate practices to manage the cybersecurity risks according to the defined scope including: Potential risk identification Risk analysis Risk evaluation Risk determination Risk treatment decision NOTE 3: Relevant risk assessment practices may be included from established standards covering practices such as FMEA, TARA, HARA, FTA. Stakeholder Requirement: MAN.7.BP3: Identify potential risks. MAN7_BP3 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT3 Identify potential risks within the project scope initially and during the conduct of the project, continuously looking for risk factors at any occurrence of technical or managerial decisions. NOTE 4: The identification of potential risks shall include the determination of threat scenarios that impose a specific risk to initiate a damage scenario with impact on relevant stakeholders for all related properties and assets within the scope. Stakeholder Requirement: MAN.7.BP4: Prioritize potential risks initially for damage. MAN7_BP4 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT4 Prioritize potential risks with respect to damage and impact on the relevant category and stakeholder. NOTE 5: The potential risks prioritization may be consistent with the scope of risk assessment. Stakeholder Requirement: MAN.7.BP5: Analyze potential risks and evaluate risks. MAN7_BP5 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT5 Analyze potential risks to determine the probability, consequence, and severity of risks. NOTE 6: Risks are analyzed based on identified attack paths that realize a threat scenario and the ease with which identified attack paths can be conducted. NOTE 7: Different techniques for evaluation of metrics, rating and scoring scheme may be used to analyze a system, e.g., functional analysis, simulation, FMEA, FTA, ATA etc. Stakeholder Requirement: MAN.7.BP6: Define risk treatment option. MAN7_BP6 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT6 For each risk (or set of risks) define the selected treatment option to accept, reduce, avoid or share (transfer) the risks. NOTE 8: Typically accepted and shared risks define cybersecurity claims. Stakeholder Requirement: MAN.7.BP7: Monitor risks. MAN7_BP7 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT7 For each risk (or set of risks) determine changes in the status of a risk and evaluate the progress of the treatment activities. NOTE 9: Major risks may need to be communicated to and monitored by higher levels of management. NOTE 10: Risk treatment decisions may be revised for changed conditions or arise from new and updated estimations and analysis results. Stakeholder Requirement: MAN.7.BP8: Take corrective action. MAN7_BP8 status: new safety_level: not set security_level: not set parent needs: MAN7 output: MAN7_OUT8 When relevant changes to risks are identified, take appropriate corrective action. NOTE 11: Corrective actions may involve a reevaluation of risks, developing and implementing new risk treatment practices or adjusting existing practices. Output work products Risk measure (07-07) [OUTCOME 6 (MAN7_OUT6) ] Recovery plan (08-14) [OUTCOME 6 (MAN7_OUT6), 7 (MAN7_OUT7), 8 (MAN7_OUT8) ] Risk management plan (08-19) [OUTCOME 1 (MAN7_OUT1), 2 (MAN7_OUT2), 4 (MAN7_OUT4), 5 (MAN7_OUT5), 6 (MAN7_OUT6), 7 (MAN7_OUT7), 8 (MAN7_OUT8) ] Risk action request (13-20) [OUTCOME 6 (MAN7_OUT6), 7 (MAN7_OUT7), 8 (MAN7_OUT8) ] Tracking system (14-08) [OUTCOME 4 (MAN7_OUT4), 5 (MAN7_OUT5), 6 (MAN7_OUT6), 7 (MAN7_OUT7), 8 (MAN7_OUT8) ] Cybersecurity scenario register (14-51) [OUTCOME 1 (MAN7_OUT1), 3 (MAN7_OUT3), 5 (MAN7_OUT5) ] Asset library (14-52) [OUTCOME 1 (MAN7_OUT1), 3 (MAN7_OUT3) ] Risk analysis report (15-08) [OUTCOME 5 (MAN7_OUT5), 6 (MAN7_OUT6) ] Risk status report (15-09) [OUTCOME 6 (MAN7_OUT6), 7 (MAN7_OUT7), 8 (MAN7_OUT8) ] 1 (MAN7_OUT1) 2 (MAN7_OUT2) 3 (MAN7_OUT3) 4 (MAN7_OUT4) 5 (MAN7_OUT5) 6 (MAN7_OUT6) 7 (MAN7_OUT7) 8 (MAN7_OUT8) Base Practices MAN.7.BP1: Determine cybersecurity risk management scope. (MAN7_BP1) x MAN.7.BP2: Define cybersecurity risk management practices. (MAN7_BP2) x MAN.7.BP3: Identify potential risks. (MAN7_BP3) x MAN.7.BP4: Prioritize potential risks initially for damage. (MAN7_BP4) x MAN.7.BP5: Analyze potential risks and evaluate risks. (MAN7_BP5) x MAN.7.BP6: Define risk treatment option. (MAN7_BP6) x MAN.7.BP7: Monitor risks. (MAN7_BP7) x MAN.7.BP8: Take corrective action. (MAN7_BP8) x Output Work Products Risk measure (07-07) x Recovery plan (08-14) x x x Risk management plan (08-19) x x x x x x x Risk action request (13-20) x x x Tracking system (14-08) x x x x x Cybersecurity scenario register (14-51) x x x Asset library (14-52) x x Risk analysis report (15-08) x x Risk status report (15-09) x x x

2.3 Security Engineering Process Group (SEC)

2.3.1 SEC.1 Cybersecurity Requirements Elicitation

Stakeholder Requirement: Cybersecurity Requirements Elicitation SEC1

status: new safety_level: not set security_level: not set child needs: SEC1_OUT1, SEC1_OUT2, SEC1_OUT3, SEC1_OUT4, SEC1_BP1, SEC1_BP2, SEC1_BP3, SEC1_BP4

Process ID SEC.1 Process name Cybersecurity Requirements Elicitation Process purpose The purpose of the Cybersecurity Requirements Elicitation Process is to derive cybersecurity goals and requirements from the outcomes of risk management, and ensure consistency between the risk assessment, cybersecurity goals and cybersecurity requirements. Process outcomes As a result of successful implementation of this process: Stakeholder Requirement: 1 SEC1_OUT1 status: new safety_level: not set security_level: not set parent needs: SEC1 output: 15-01, 17-11, 17-12, 17-51 generated by: SEC1_BP1 cybersecurity goals are defined, Stakeholder Requirement: 2 SEC1_OUT2 status: new safety_level: not set security_level: not set parent needs: SEC1 output: 15-01, 17-11, 17-12 generated by: SEC1_BP1 cybersecurity requirements are derived from cybersecurity goals, Stakeholder Requirement: 3 SEC1_OUT3 status: new safety_level: not set security_level: not set parent needs: SEC1 output: 13-19, 13-22 generated by: SEC1_BP2 consistency and bidirectional traceability are established between cybersecurity requirements and goals and between the cybersecurity goals and the threat scenarios, and Stakeholder Requirement: 4 SEC1_OUT4 status: new safety_level: not set security_level: not set parent needs: SEC1 output: 13-04 generated by: SEC1_BP4 the cybersecurity requirements are agreed and communicated to all affected parties. Base practices Stakeholder Requirement: SEC.1.BP1: Derive cybersecurity goals and cybersecurity requirements. SEC1_BP1 status: new safety_level: not set security_level: not set parent needs: SEC1 output: SEC1_OUT1, SEC1_OUT2 Derive cybersecurity goals for those threat scenarios, where the risk treatment decision requires risk reduction. Specify functional and non-functional cybersecurity requirements for the cybersecurity goals, including criteria for the achievement of the cybersecurity goals. NOTE 1: This includes the refinement of requirements during iterations of this process. NOTE 2: This includes requirements for post-development phases which may include production, operation, maintenance and decommissioning. Stakeholder Requirement: SEC.1.BP2: Establish bidirectional traceability. SEC1_BP2 status: new safety_level: not set security_level: not set parent needs: SEC1 output: SEC1_OUT3 Establish bidirectional traceability between the cybersecurity requirements and the cybersecurity goals. Establish bidirectional traceability between the cybersecurity goals and the threat scenarios. [Outcome 3] Stakeholder Requirement: SEC.1.BP3: Ensure consistency. SEC1_BP3 status: new safety_level: not set security_level: not set parent needs: SEC1 Ensure consistency between the cybersecurity requirements and the cybersecurity goals. Ensure consistency between the cybersecurity goals and the threat scenarios. Stakeholder Requirement: SEC.1.BP4: Communicate agreed cybersecurity requirements. SEC1_BP4 status: new safety_level: not set security_level: not set parent needs: SEC1 output: SEC1_OUT4 Communicate agreed cybersecurity goals and cybersecurity requirements to all affected parties. Output work products Communication record (13-04) [OUTCOME 4 (SEC1_OUT4) ] Review record (13-19) [OUTCOME 3 (SEC1_OUT3) ] Traceability record (13-22) [OUTCOME 3 (SEC1_OUT3) ] Analysis report (15-01) [OUTCOME 1 (SEC1_OUT1), 2 (SEC1_OUT2) ] Software requirements specification (17-11) [OUTCOME 1 (SEC1_OUT1), 2 (SEC1_OUT2) ] System requirements specification (17-12) [OUTCOME 1 (SEC1_OUT1), 2 (SEC1_OUT2) ] Cybersecurity goals (17-51) [OUTCOME 1 (SEC1_OUT1) ] 1 (SEC1_OUT1) 2 (SEC1_OUT2) 3 (SEC1_OUT3) 4 (SEC1_OUT4) Base Practices SEC.1.BP1: Derive cybersecurity goals and cybersecurity requirements. (SEC1_BP1) x x SEC.1.BP2: Establish bidirectional traceability. (SEC1_BP2) x SEC.1.BP3: Ensure consistency. (SEC1_BP3) x SEC.1.BP4: Communicate agreed cybersecurity requirements. (SEC1_BP4) x Output Work Products Communication record (13-04) x Review record (13-19) x Traceability record (13-22) x Analysis report (15-01) x x Software requirements specification (17-11) x x System requirements specification (17-12) x x Cybersecurity goals (17-51) x

2.3.2 SEC.2 Cybersecurity Implementation

Stakeholder Requirement: Cybersecurity Implementation SEC2

status: new safety_level: not set security_level: not set child needs: SEC2_OUT1, SEC2_OUT2, SEC2_OUT3, SEC2_OUT4, SEC2_OUT5, SEC2_OUT6, SEC2_OUT7, SEC2_OUT8, SEC2_BP1, SEC2_BP2, SEC2_BP3, SEC2_BP4, SEC2_BP5, SEC2_BP6, SEC2_BP7, SEC2_BP8, SEC2_BP9, SEC2_BP10

Process ID SEC.2 Process name Cybersecurity Implementation Process purpose The purpose of the Cybersecurity Implementation Process is to allocate the cybersecurity requirements to the elements of the system and software and ensure they are implemented. Process outcomes As a result of successful implementation of this process: Stakeholder Requirement: 1 SEC2_OUT1 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 04-04, 04-06 generated by: SEC2_BP1, SEC2_BP4 architectural design is refined, Stakeholder Requirement: 2 SEC2_OUT2 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 13-22 generated by: SEC2_BP2, SEC2_BP8 cybersecurity requirements are allocated to elements of the architectural design, Stakeholder Requirement: 3 SEC2_OUT3 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 17-52 generated by: SEC2_BP3 appropriate cybersecurity controls are selected, Stakeholder Requirement: 4 SEC2_OUT4 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 15-50 generated by: SEC2_BP5 vulnerabilities are analyzed, Stakeholder Requirement: 5 SEC2_OUT5 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 04-05 generated by: SEC2_BP6 detailed design is refined, Stakeholder Requirement: 6 SEC2_OUT6 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 11-05 generated by: SEC2_BP7 software units are developed, Stakeholder Requirement: 7 SEC2_OUT7 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 13-19, 13-22 generated by: SEC2_BP8, SEC2_BP9 consistency and bidirectional traceability are established between architectural design and detailed design, and Stakeholder Requirement: 8 SEC2_OUT8 status: new safety_level: not set security_level: not set parent needs: SEC2 output: 13-04 generated by: SEC2_BP10 the cybersecurity risk treatment implementation is agreed upon and communicated to all affected parties. Base practices Stakeholder Requirement: SEC.2.BP1: Refine the details of the architectural design. SEC2_BP1 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT1 The architectural design is refined based on cybersecurity goals and cybersecurity requirements. NOTE 1: Refinement could be on system and software level architecture. NOTE 2: Refinement here means to add, adapt or rework elements of the architecture. Stakeholder Requirement: SEC.2.BP2: Allocate cybersecurity requirements. SEC2_BP2 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT2 Allocate the cybersecurity requirements to one or more elements of the architectural design. NOTE 3: Cybersecurity requirements could be on system and software level. Stakeholder Requirement: SEC.2.BP3: Select cybersecurity controls. SEC2_BP3 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT3 Select appropriate cybersecurity controls to achieve or support the cybersecurity requirements. NOTE 4: Typically, cybersecurity controls are technical or other solutions to avoid, detect, counteract or mitigate cybersecurity risks. Stakeholder Requirement: SEC.2.BP4: Refine interfaces. SEC2_BP4 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT1 Refine and describe cybersecurity related interfaces between the elements of the architectural design and operating environment. Stakeholder Requirement: SEC.2.BP5: Analyze architectural design. SEC2_BP5 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT4 Analyze the architectural design to identify and analyze vulnerabilities. Stakeholder Requirement: SEC.2.BP6: Refine the details of the detailed design. SEC2_BP6 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT5 The detailed design is refined based on architectural design. NOTE 5: Refinement here means to add, adapt or rework components of the detailed design. Stakeholder Requirement: SEC.2.BP7: Develop software units. SEC2_BP7 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT6 Implement the software using appropriate modeling or programming languages. NOTE 6: Criteria for appropriate modeling and programming languages for cybersecurity can include the use of language subsets, enforcement of strong typing and/or the use of defensive implementation techniques. NOTE 7: Example to cover the defined criteria above could be the use of a coding guideline or an appropriate development environment. Stakeholder Requirement: SEC.2.BP8: Establish bidirectional traceability. SEC2_BP8 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT2, SEC2_OUT7 Establish bidirectional traceability between the refined architectural design and the detailed design. Stakeholder Requirement: SEC.2.BP9: Ensure consistency. SEC2_BP9 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT7 Ensure consistency between the refined architectural design and the detailed design. Stakeholder Requirement: SEC.2.BP10: Communicate agreed results of cybersecurity implementation. SEC2_BP10 status: new safety_level: not set security_level: not set parent needs: SEC2 output: SEC2_OUT8 Communicate the agreed results of the cybersecurity implementation to all affected parties including stakeholders from post-development phases. NOTE 8: The communicated contents may include both results of the cybersecurity implementation and vulnerabilities identified within the architectural design analysis. Output work products Software architectural design (04-04) [OUTCOME 1 (SEC2_OUT1) ] Software detailed design (04-05) [OUTCOME 5 (SEC2_OUT5) ] System architectural design (04-06) [OUTCOME 1 (SEC2_OUT1) ] Software unit (11-05) [OUTCOME 6 (SEC2_OUT6) ] Communication record (13-04) [OUTCOME 8 (SEC2_OUT8) ] Review record (13-19) [OUTCOME 7 (SEC2_OUT7) ] Traceability record (13-22) [OUTCOME 2 (SEC2_OUT2), 7 (SEC2_OUT7) ] Vulnerability analysis report (15-50) [OUTCOME 4 (SEC2_OUT4) ] Cybersecurity controls (17-52) [OUTCOME 3 (SEC2_OUT3) ] 1 (SEC2_OUT1) 2 (SEC2_OUT2) 3 (SEC2_OUT3) 4 (SEC2_OUT4) 5 (SEC2_OUT5) 6 (SEC2_OUT6) 7 (SEC2_OUT7) 8 (SEC2_OUT8) Base Practices SEC.2.BP1: Refine the details of the architectural design. (SEC2_BP1) x SEC.2.BP2: Allocate cybersecurity requirements. (SEC2_BP2) x SEC.2.BP3: Select cybersecurity controls. (SEC2_BP3) x SEC.2.BP4: Refine interfaces. (SEC2_BP4) x SEC.2.BP5: Analyze architectural design. (SEC2_BP5) x SEC.2.BP6: Refine the details of the detailed design. (SEC2_BP6) x SEC.2.BP7: Develop software units. (SEC2_BP7) x SEC.2.BP8: Establish bidirectional traceability. (SEC2_BP8) x SEC.2.BP9: Ensure consistency. (SEC2_BP9) x SEC.2.BP10: Communicate agreed results of cybersecurity implementation. (SEC2_BP10) x Output Work Products Software architectural design (04-04) x x Software detailed design (04-05) x x System architectural design (04-06) x x Software unit (11-05) x Communication record (13-04) x Review record (13-19) x Traceability record (13-22) x Vulnerability analysis report (15-50) x Cybersecurity controls (17-52) x

2.3.3 SEC.3 Risk Treatment Verification

Stakeholder Requirement: Risk Treatment Verification SEC3

status: new safety_level: not set security_level: not set child needs: SEC3_OUT1, SEC3_OUT2, SEC3_OUT3, SEC3_OUT4, SEC3_OUT5, SEC3_OUT6, SEC3_BP1, SEC3_BP2, SEC3_BP3, SEC3_BP4, SEC3_BP5, SEC3_BP6

Process ID SEC.3 Process name Risk Treatment Verification Process purpose The purpose of the Risk Treatment Verification Process is to confirm that the implementation of the design and integration of the components comply with the cybersecurity requirements, the refined architectural design and detailed design. Process outcomes As a result of successful implementation of this process: Stakeholder Requirement: 1 SEC3_OUT1 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 08-52, 19-10 generated by: SEC3_BP1 a risk treatment verification and integration strategy are developed, implemented, and maintained, Stakeholder Requirement: 2 SEC3_OUT2 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 08-50 generated by: SEC3_BP2 a specification for risk treatment verification is developed according to the risk treatment verification strategy suitable to provide evidence of compliance in implementing cybersecurity requirements as well as the refined architectural and detailed design, Stakeholder Requirement: 3 SEC3_OUT3 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 13-19, 13-25, 13-50 generated by: SEC3_BP3 identified work products are verified according to the risk treatment verification strategy for risk treatment verification. The implementation of the design and the integration of the components is tested using the defined test cases. Verification and test results are recorded, Stakeholder Requirement: 4 SEC3_OUT4 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 13-22 generated by: SEC3_BP4 bidirectional traceability between the cybersecurity requirements and risk treatment verification specification (including test cases), and bidirectional traceability between the refined architectural design (including detailed design) and the risk treatment verification specification (including test cases), and between the test cases included in the risk treatment verification specification, and verification results is established, Stakeholder Requirement: 5 SEC3_OUT5 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 13-19 generated by: SEC3_BP5 consistency between the cybersecurity requirements and risk treatment verification specification (including test cases) and consistency between the refined architectural design (including detailed design) and the risk treatment verification specification (including test cases) is established, and Stakeholder Requirement: 6 SEC3_OUT6 status: new safety_level: not set security_level: not set parent needs: SEC3 output: 13-04, 13-25, 13-50 generated by: SEC3_BP6 results of the verification are summarized and communicated to all affected parties Base practices Stakeholder Requirement: SEC.3.BP1: Develop a risk treatment verification and integration strategy. SEC3_BP1 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT1 Develop and implement a risk treatment verification and integration strategy, including a regression strategy. This contains: activities with associated methods, techniques and tools, work products or processes under verification, degree of independence for verification for performing these activities, and verification criteria. NOTE 1: The risk treatment verification may provide objective evidence that the outputs of a particular phase of the system and software development lifecycle (e.g., requirements, design, implementation, testing) meet the specified requirements for that phase. NOTE 2: The risk treatment verification strategy may include requirements-based testing and interface testing on system and software level, check for any unspecified functionalities, resource consumption evaluation, control flow and data flow verification, and static analysis; for software: static code analysis e.g. industry recognized security-focused coding standards. NOTE 3: The risk treatment verification methods and techniques may include network tests simulating attacks (non-authorized commands, signals with wrong hash key, flooding the connection with messages, etc.), and simulating brute force attacks. NOTE 4: The risk treatment verification methods and techniques may also include audits, inspections, peer reviews, walkthroughs, code reviews, and other techniques. Stakeholder Requirement: SEC.3.BP2: Develop specification for risk treatment verification. SEC3_BP2 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT2 Develop the specification for risk treatment verification (including test cases) according to the risk treatment verification strategy. It shall be suitable to provide evidence of compliance of the implementation with the cybersecurity requirements and the refined architectural design and detailed design. NOTE 5: Methods of deriving test cases may include analysis of requirements, generation and analysis of equivalence classes, boundary values analysis, and/or error guessing based on knowledge or experience. Stakeholder Requirement: SEC.3.BP3: Perform verification activities. SEC3_BP3 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT3 Verify identified work products according to the specified strategy in order to confirm that the work products meet their specified requirements. Test the implementation of the design and component integration according to the risk treatment verification specification. Record the risk treatment verification results and logs. Stakeholder Requirement: SEC.3.BP4: Establish bidirectional traceability. SEC3_BP4 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT4 Establish bidirectional traceability between the cybersecurity requirements and risk treatment verification specification, including test cases comprised in the risk treatment verification specification. Establish bidirectional traceability between the refined architectural design, detailed design, software units and the risk treatment verification specification. Establish bidirectional traceability between the test cases included in the risk treatment verification specification, and verification results. NOTE 6: Bidirectional traceability supports coverage, consistency, and impact analysis. Stakeholder Requirement: SEC.3.BP5: Ensure consistency. SEC3_BP5 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT5 Ensure consistency between the cybersecurity requirements and the risk treatment verification specification, including test cases comprised in the risk treatment verification specification. Ensure consistency between the refined architectural and detailed design and the risk treatment verification specification. NOTE 7: Consistency is supported by bidirectional traceability and can be demonstrated by review records. Stakeholder Requirement: SEC.3.BP6: Summarize and communicate results. SEC3_BP6 status: new safety_level: not set security_level: not set parent needs: SEC3 output: SEC3_OUT6 Summarize the risk treatment verification results and communicate them to all affected parties. NOTE 8: Providing all necessary information from the risk treatment verification execution in a summary enables other parties to judge the consequences. Output work products Test specification (08-50) [OUTCOME 2 (SEC3_OUT2) ] Test plan (08-52) [OUTCOME 1 (SEC3_OUT1) ] Communication record (13-04) [OUTCOME 6 (SEC3_OUT6) ] Review record (13-19) [OUTCOME 3 (SEC3_OUT3), 5 (SEC3_OUT5) ] Traceability record (13-22) [OUTCOME 4 (SEC3_OUT4) ] Verification results (13-25) [OUTCOME 3 (SEC3_OUT3), 6 (SEC3_OUT6) ] Test results (13-50) [OUTCOME 3 (SEC3_OUT3), 6 (SEC3_OUT6) ] Verification strategy (19-10) [OUTCOME 1 (SEC3_OUT1) ] 1 (SEC3_OUT1) 2 (SEC3_OUT2) 3 (SEC3_OUT3) 4 (SEC3_OUT4) 5 (SEC3_OUT5) 6 (SEC3_OUT6) Base Practices SEC.3.BP1: Develop a risk treatment verification and integration strategy. (SEC3_BP1) x SEC.3.BP2: Develop specification for risk treatment verification. (SEC3_BP2) x SEC.3.BP3: Perform verification activities. (SEC3_BP3) x SEC.3.BP4: Establish bidirectional traceability. (SEC3_BP4) x SEC.3.BP5: Ensure consistency. (SEC3_BP5) x SEC.3.BP6: Summarize and communicate results. (SEC3_BP6) x Output Work Products Test specification (08-50) x Test plan (08-52) x Communication record (13-04) x Review record (13-19) x x Traceability record (13-22) x Verification results (13-25) x x Test results (13-50) x x Verification strategy (19-10) x

2.3.4 SEC.4 Risk Treatment Validation

Stakeholder Requirement: Risk Treatment Validation SEC4

status: new safety_level: not set security_level: not set child needs: SEC4_OUT1, SEC4_OUT2, SEC4_OUT3, SEC4_OUT4, SEC4_OUT5, SEC4_OUT6, SEC4_BP1, SEC4_BP2, SEC4_BP3, SEC4_BP4, SEC4_BP5, SEC4_BP6

Process ID SEC.4 Process name Risk Treatment Validation Process purpose The purpose of the Risk Treatment Validation Process is to confirm that the integrated system achieves the associated cybersecurity goals. Process outcomes As a result of successful implementation of this process Stakeholder Requirement: 1 SEC4_OUT1 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 19-11 generated by: SEC4_BP1 a risk treatment validation strategy is developed, implemented and agreed upon with relevant stakeholders and maintained suitably to provide evidence that the implementation achieves the associated cybersecurity goals, Stakeholder Requirement: 2 SEC4_OUT2 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 08-50, 13-19 generated by: SEC4_BP2, SEC4_BP3 the implemented design and integrated components are validated according to the defined risk treatment validation strategy, Stakeholder Requirement: 3 SEC4_OUT3 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 13-24 generated by: SEC4_BP3, SEC4_BP6 validation activities are documented and the results are recorded, Stakeholder Requirement: 4 SEC4_OUT4 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 13-22 generated by: SEC4_BP4 bidirectional traceability between the cybersecurity goals, risk treatment validation specification and validation results is established, Stakeholder Requirement: 5 SEC4_OUT5 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 13-19 generated by: SEC4_BP5 consistency between the cybersecurity goals and the risk treatment validation specification is established, and Stakeholder Requirement: 6 SEC4_OUT6 status: new safety_level: not set security_level: not set parent needs: SEC4 output: 13-04 generated by: SEC4_BP6 results of the validation are summarized and communicated to all affected parties. Base practices Stakeholder Requirement: SEC.4.BP1: Develop a risk treatment validation strategy. SEC4_BP1 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT1 Develop and implement a validation strategy. NOTE 1: Risk treatment validation methods and techniques typically include cybersecurity-relevant methods to detect unidentified vulnerabilities (e.g., penetration testing). NOTE 2: Risk treatment validation examines whether the associated cybersecurity goals are achieved. Stakeholder Requirement: SEC.4.BP2: Develop specification for risk treatment validation. SEC4_BP2 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT2 Develop the specification for risk treatment validation (including test cases) according to the risk treatment validation strategy. It shall be suitable to provide evidence of achievement of the associated cybersecurity goals. NOTE 3: Methods of deriving test cases may include analysis of requirements, generation and analysis of equivalence classes, boundary values analysis, and/or error guessing based on knowledge or experience. Stakeholder Requirement: SEC.4.BP3: Perform and document risk treatment validation activities. SEC4_BP3 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT2, SEC4_OUT3 Validate the implemented design and the integrated components according to the defined risk treatment validation strategy. The risk treatment validation activities are documented, and the results are recorded. NOTE 4: See SUP.9 for handling of non-conformances and vulnerabilities. Stakeholder Requirement: SEC.4.BP4: Establish bidirectional traceability. SEC4_BP4 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT4 Establish bidirectional traceability between the cybersecurity goals and the risk treatment validation specification. Establish bidirectional traceability between the risk treatment validation specification and the validation results. NOTE 5: Bidirectional traceability supports coverage, consistency and impact analysis. Stakeholder Requirement: SEC.4.BP5: Ensure consistency. SEC4_BP5 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT5 Ensure consistency between the cybersecurity goals and the risk treatment validation specification. NOTE 6: Consistency is supported by bidirectional traceability and can be demonstrated by review records. Stakeholder Requirement: SEC.4.BP6 Summarize and communicate results. SEC4_BP6 status: new safety_level: not set security_level: not set parent needs: SEC4 output: SEC4_OUT3, SEC4_OUT6 Summarize the risk treatment validation results and communicate them to all affected parties. NOTE 7: This includes typically information from the risk treatment validation activities and important findings concerning additional vulnerabilities that enables other parties to judge the consequences. Output work products Test specification (08-50) [OUTCOME 2 (SEC4_OUT2) ] Communication record (13-04) [OUTCOME 6 (SEC4_OUT6) ] Review record (13-19) [OUTCOME 2 (SEC4_OUT2), 5 (SEC4_OUT5) ] Traceability record (13-22) [OUTCOME 4 (SEC4_OUT4) ] Validation results (13-24) [OUTCOME 3 (SEC4_OUT3) ] Validation strategy (19-11) [OUTCOME 1 (SEC4_OUT1) ] 1 (SEC4_OUT1) 2 (SEC4_OUT2) 3 (SEC4_OUT3) 4 (SEC4_OUT4) 5 (SEC4_OUT5) 6 (SEC4_OUT6) Base Practices SEC.4.BP1: Develop a risk treatment validation strategy. (SEC4_BP1) x SEC.4.BP2: Develop specification for risk treatment validation. (SEC4_BP2) x SEC.4.BP3: Perform and document risk treatment validation activities. (SEC4_BP3) x x SEC.4.BP4: Establish bidirectional traceability. (SEC4_BP4) x SEC.4.BP5: Ensure consistency. (SEC4_BP5) x SEC.4.BP6 Summarize and communicate results. (SEC4_BP6) x x Output Work Products Test specification (08-50) x Communication record (13-04) x Review record (13-19) x x Traceability record (13-22) x Validation results (13-24) x Validation strategy (19-11) x

Annex A Process Assessment and Reference Model Conformity

A.1 Introduction

The Automotive SPICE process assessment and reference model meet the requirements for conformity defined in ISO/IEC 33004:2015. The process assessment model can be used in the performance of assessments that meet the requirements of ISO/IEC 33002:2015.

This clause serves as the statement of conformity of the process assessment and reference models to the requirements defined in ISO/IEC 33004:2015.

[ISO/IEC 33004:2015, 5.5 and 6.4]

Due to copyright reasons each requirement is only referred to by its number. The full text of the requirements can be drawn from ISO/IEC 33004:2015.

A.2 Conformity to the requirements for process reference models

Clause 5.3, “Requirements for process reference models”

The following information is provided in Chapter 1 of this document:

• the declaration of the domain of this process reference model,

• the description of the relationship between this process reference model and its intended use, and

• the description of the relationship between the processes defined within this process reference model.

The descriptions of the processes within the scope of this process reference model that meet the requirements of ISO/IEC 33004:2015 clause 5.4 are provided in Chapter 2 of this document.

[ISO/IEC 33004:2015, 5.3.1]

The relevant communities of interest and their mode of use and the consensus achieved for this process reference model are documented in the copyright notice and scope of this document.

[ISO/IEC 33004:2015, 5.3.2]

The process descriptions are unique. The identification is provided by unique names and by the identifier of each process of this document.

[ISO/IEC 33004:2015, 5.3.3]

Clause 5.4: Process descriptions

These requirements are met by the process descriptions in Chapter 2 of this document.

[ISO/IEC 33004:2015, 5.4]

A.3 Conformity to the requirements for process assessment models

Clause 6.1: “Introduction”

The purpose of this process assessment model is to support assessment of process capability within the automotive domain using the process measurement framework defined in ISO/IEC 33020:2015.

[ISO/IEC 33004:2015, 6.1]

Clause 6.2: “Process assessment model scope”

The process scope of this process assessment model is defined in the process reference model included in subchapter 3.1 of this document. The Automotive SPICE Process Reference Model satisfies the requirements of ISO/IEC 33004:2015, clause 5 as described in Annex A.2.

The process capability scope of this process assessment model is defined in the process measurement framework specified in ISO/IEC 33020:2015, which defines a process measurement framework for process capability satisfying the requirements of ISO/IEC 33003. [ISO/IEC 33004:2015, 6.2]

Clause 6.3: “Requirements for process assessment models”

The Automotive SPICE Process Assessment Model is related to process capability.

[ISO/IEC 33004:2015, 6.3.1]

This process assessment model incorporates the process measurement framework specified in ISO/IEC 33020:2015, which satisfies the requirements of ISO/IEC 33003.

[ISO/IEC 33004:2015, 6.3.2]

This process assessment model is based on the Automotive SPICE Reference Model included in this document.

This process assessment model is based on the measurement framework defined in ISO/IEC 33020:2015.

[ISO/IEC 33004:2015, 6.3.3]

The processes included in this process assessment model are identical to those specified in the process reference model.

[ISO/IEC 33004:2015, 6.3.4]

For all processes in this process assessment model all levels defined in the process measurement framework from ISO/IEC 33020:2015 are addressed.

[ISO/IEC 33004:2015, 6.3.5]

This process assessment model defines

• the selected process quality characteristic,

• the selected process measurement framework,

• the selected process reference model(s), and

• the selected processes from the process reference model(s) in Chapter 3 of this document.

[ISO/IEC 33004:2015, 6.3.5 a-d]

In the capability dimension, this process assessment model addresses all of the process attributes and capability levels defined in the process measurement framework in ISO/IEC 33020:2015.

[ISO/IEC 33004:2015, 6.3.5 e]

Clause 6.3.1: “Assessment indicators”

NOTE: Due to an error in numbering in the published version of ISO/IEC 33004:2015, the following reference numbers are redundant to those stated above. To refer to the correct clauses from ISO/IEC 33004:2015, the text of the clause heading is additionally specified for the following three requirements.

The Automotive SPICE Process Assessment Model provides a twodimensional view of process capability for the processes in the process reference model, through the inclusion of assessment indicators as defined in subchapter 3.3. The assessment indicators used are:

• Base practices and output work products

[ISO/IEC 33004:2015, 6.3.1 a: “Assessment indicators”]

• Generic practices and Generic resources

[ISO/IEC 33004:2015, 6.3.1 b: “Assessment indicators”]

Clause 6.3.2: “Mapping process assessment models to process reference models”

The mapping of the assessment indicators to the purpose and process outcomes of the processes in the process reference model is included in each description of the base practices in Chapter 4.

The mapping of the assessment indicators to the process attributes in the process measurement framework including all of the process attribute achievements is included in each description of the generic practices in Chapter 5.

Each mapping is indicated by a reference in square brackets.

[ISO/IEC 33004:2015, 6.3.2: “Mapping process assessment models”]

Clause 6.3.3: “Expression of assessment results”

The process attributes and the process attribute ratings in this process assessment model are identical to those defined in the measurement framework. As a consequence, results of assessments based upon this process assessment model are expressed directly as a set of process attribute ratings for each process within the scope of the assessment. No form of translation or conversion is required.

[ISO/IEC 33004:2015, 6.3.3: “Expression of assessment results”]

Annex B Work Product Characteristics

Work product characteristics listed in this annex can be used when reviewing potential outputs of process implementation. The characteristics are provided as guidance regarding the attributes that should be looked for in a particular sample work product in order to provide objective evidence supporting the assessment of a particular process.

A documented process and assessor judgment is needed to ensure that the process context (application domain, business purpose, development methodology, size of the organization, etc.) is considered when using this information.

Work products are defined using the schema in Table B.1. Work products and their characteristics should be considered as a starting point for considering whether, given the context, they are contributing to the intended purpose of the process and not as a checklist of what every organization must have.

Table 30 Table B.1 — Structure of WPC Tables

Work product identifier	An identifier number for the work product used to reference the work product.
Work product name	Provides an example of a typical name associated with the work product characteristics. This name is furnished as an identifier of the type of work product the practice or process might produce. Organizations may call these work products by different names. The name of the work product in the organization is not significant. Similarly, organizations may have several equivalent work products that contain the characteristics defined in one work product type. The formats for the work products can vary. It is up to the assessor and the organizational unit coordinator to map the actual work products produced in their organization to the examples given here.
Work product characteristics	Provides examples of the potential characteristics associated with the work product types. The assessor may look for these in the samples supplied by the organizational unit.

Work products (with the ID NN-00) are sets of characteristics that would be expected to be evident in work products of generic types as a result of achievement of an attribute. The generic work products form the basis for the classification of specific work products defined as process performance indicators.

Specific work product types are typically created by process owners and applied by process deployers in order to satisfy an outcome of a particular process purpose.

NOTE: The generic work products denoted with * are not used in the Automotive SPICE Process Assessment Model but are included for completeness.

Table B.2 — Work Product Characteristics

[This table contains only the relevant work product characteristics for the Automotive SPICE for Cybersecurity]

Table B.2 — Work Product Characteristics

WP ID	WP Name	WP Characteristics
02-00	Contract	• Defines what is to be purchased or delivered • Identifies time frame for delivery or contracted service dates • Identifies any statutory requirements • Identifies monetary considerations • Identifies any warranty information • Identifies any copyright and licensing information • Identifies any customer service requirements • Identifies service level requirements • References to any performance and quality expectations/constraints/monitoring • Standards and procedures to be used • Evidence of review and approval • As appropriate to the contract the following are considered: - references to any acceptance criteria - references to any special customer needs (i.e., confidentiality requirements, security, hardware, etc.) - references to any change management and problem resolution procedures - identification of any interfaces to independent agents and subcontractors - identification of customer's role in the development and maintenance process - identification of resources to be provided by the customer
02-01	Commitment/agreement	• Signed off by all parties involved in the • Establishes what the commitment is for • Establishes the resources required to fulfill the commitment, such as: - time - people - budget - equipment - facilities
02-50	Interface agreement	• Interface agreement should include definitions regarding - customer and supplier stakeholder and contacts - tailoring agreements - customer/supplier responsibilities (e.g., roles, RASIC chart) for distributive activities, including required actions in development and post-development - share of information/work products in case of issues (e.g., vulnerabilities, findings, risks) - agreed customer/supplier milestones - duration of supplier’s support and maintenance
04-04	Software architectural design	• Describes the overall software structure • Describes the operative system including task structure • Identifies inter-task/inter-process communication • Identifies the required software elements • Identifies own developed and supplied code • Identifies the relationship and dependency between software elements • Identifies where the data (e.g., application parameters or variables) are stored and which measures (e.g., checksums, redundancy) are taken to prevent data corruption • Describes how variants for different model series or configurations are derived • Describes the dynamic behavior of the software (start-up, shutdown, software update, error handling and recovery, etc.) • Describes which data is persistent and under which conditions • Consideration is given to: - any required software performance characteristics - any required software interfaces - any required security characteristics required - any database design requirements
04-05	Software detailed design	• Provides detailed design (could be represented as a prototype, flow chart, entity relationship diagram, pseudo code, etc.) • Provides format of input/output data • Provides specification of CPU, ROM, RAM, EEPROM and Flash needs • Describes the interrupts with their priorities • Describes the tasks with cycle time and priority • Establishes required data naming conventions • Defines the format of required data structures • Defines the data fields and purpose of each required data element • Provides the specifications of the program structure
04-06	System architectural design	• Provides an overview of all system design • Describes the interrelationship between system elements • Describes the relationship between the system elements and the software • Specifies the design for each required system element, consideration is given to aspects such as: - memory/capacity requirements - hardware interface requirements - user interface requirements - external system interface requirements - performance requirements - command structures - security/data protection characteristics - settings for system parameters (such as application parameters or global variables) - manual operations - reusable components • Mapping of requirements to system elements • Description of the operation modes of the system components (startup, shutdown, sleep mode, diagnosis mode, etc.) • Description of the dependencies among the system components regarding the operation modes • Description of the dynamic behavior of the system and the system components
07-07	Risk measure	• Identifies the probability of risk occurring • Identifies the impact of risk occurring • Establishes measures for each risk defined • Measures the change in the risk state
08-14	Recovery plan	• Identifies what is to be recovered: - procedures/methods to perform the recovery - schedule for recovery - time required for the recovery - critical dependencies - resources required for the recovery - list of backups maintained - staff responsible for recovery and roles assigned - special materials required - required work products - required equipment - required documentation - locations and storage of backups - contact information on who to notify about the recovery - verification procedures - cost estimation for recovery
08-19	Risk management plan	• Project risks identified and prioritized • Mechanism to track the risk • Threshold criteria to identify when corrective action required • Proposed ways to mitigate risks: - risk mitigator - work around - corrective actions activities/tasks - monitoring criteria - mechanisms to measure risk
08-20	Risk mitigation plan	• Planned risk treatment activities and tasks: - describes the specifics of the risk treatment selected for a risk or combination of risks found to be unacceptable - describes any difficulties that may be found in implementing the treatment • Treatment schedule • Treatment resources and their allocation • Responsibilities and authority: - describes who is responsible for ensuring that the treatment is being implemented and their authority • Treatment control measures: - defines the measures that will be used to evaluate the effectiveness of the risk treatment • Treatment cost • Interfaces among parties involved: - describes any coordination among stakeholders or with the project’s master plan that must occur for the treatment to be properly implemented • Environment/infrastructure: - describes any environmental or infrastructure requirements or impacts (e.g., safety or security impacts that the treatment may have) • Risk treatment plan change procedures and history
08-50	Test specification	• Test Design Specification • Test Case Specification • Test Procedure Specification • Identification of test cases for regression testing • Additionally, for system integration: - identification of required system elements (hardware elements, wiring elements, settings for parameters (such as application parameters or global variables), databases, etc.) - necessary sequence or ordering identified for integrating the system elements
08-52	Test plan	• Test Plan according to ISO/IEC/IEEE 29119-3 • Context: - project/Test sub-process - test item(s) - test scope - assumptions and constraints - stakeholder - testing communication • Test strategy - identifies what needs are to be satisfied - establishes the options and approach for satisfying the needs (black-box and/or white-box testing, boundary class test determination, regression testing strategy, etc.) - establishes the evaluation criteria against which the strategic options are evaluated - identifies any constraints/risks and how these will be addressed - test design techniques - test completion criteria - test ending criteria - test start, abort and re-start criteria - metrics to be collected - test data requirements - retesting and regression testing - suspension and resumption criteria - deviations from the Organizational Test Strategy • Test data requirements • Test environment requirements • Test sub-processes • Test deliverables • Testing activities and estimates
11-05	Software unit	• Follows established coding standards (as appropriate to the language and application): - commented - structured or optimized - meaningful naming conventions - parameter information identified - error codes defined - error messages descriptive and meaningful - formatting – indented, levels • Follows data definition standards (as appropriate for the language and application): - variables defined - data types defined - classes and inheritance structures defined - objects defined • Entity relationships defined • Database layouts are defined • File structures and blocking are defined • Data structures are defined • Algorithms are defined • Functional interfaces defined
12-01	Request for quotation	• Reference to the requirements specifications • Identifies supplier selection criteria • Identifies desired characteristics, such as: - system architecture, configuration requirements or the requirements for service (consultants, maintenance, etc.) - quality criteria or requirements - project schedule requirements - expected delivery/service dates - cost/price expectations - regulatory standards/requirements • Identifies submission constraints: - date for resubmission of the response - requirements with regard to the format of response
13-01	Acceptance record	• Record of the receipt of the delivery • Identification of the date received • Identification of the delivered components • Records the verification of any customer acceptance criteria defined • Signed by receiving customer
13-04	Communication record	• All forms of interpersonal communication, including: - letters - faxes - emails - voice recordings - podcast - blog - videos - forum - live chat - wikis - photo protocol - meeting support record
13-14	Progress status record	• Record of the status of a plan(s) (actual against planned), e.g.: - status of actual tasks against planned tasks - status of actual results against established objectives/goals - status of actual resources allocation against planned resources - status of actual cost against budget estimates - status of actual time against planned schedule - status of actual quality against planned quality • Record of any deviations from planned activities and reason why
13-16	Change request	• Identifies purpose of change • Identifies request status (e.g., open, allocated, implemented, closed) • Identifies requester contact information • Impacted system(s) • Impact to operations of existing system(s) defined • Impact to associated documentation defined • Criticality of the request, due date
13-19	Review record	• Provides the context information about the review: - what was reviewed - lists reviewers who attended - status of the review • Provides information about the coverage of the review: - checklists - review criteria - requirements - compliance to standards • Records information about: - the readiness for the review - preparation time spent for the review - time spent in the review - reviewers, roles and expertise • Review findings: - non-conformities - improvement suggestions • Identifies the required corrective actions: - risk identification - prioritized list of deviations and problems discovered - the actions, tasks to be performed to fix the problem - ownership for corrective action - status and target closure dates for identified problems
13-20	Risk action request	• Date of initiation • Scope • Subject • Request originator • Risk management process context: - this section may be provided once, and then referenced in subsequent action requests if no changes have occurred - process scope - stakeholder perspective - risk categories - risk thresholds - project objectives - project assumptions - project constraints • Risks: - this section may cover one risk or many, as the user chooses - where all the information above applies to the whole set of risks, one action request may suffice - where the information varies, each request may cover the risk or risks that share common information - risk description(s) - risk probability - risk value - risk consequences - expected timing of risk • Risk treatment alternatives: - Treatment option selected- avoid/reduce/transfer - alternative descriptions - recommended alternative(s) - justifications • Risk action request disposition: - each request should be annotated as to whether it is accepted, rejected or modified, and the rationale provided for whichever decision is taken
13-22	Traceability record	• All requirements (customer and internal) are to be traced • Identifies a mapping of requirement to lifecycle work products • Provides the linkage of requirements to work product decomposition (i.e., requirement, design, coding, testing, deliverables, etc.) • Provides forward and backwards mapping of requirements to associated work products throughout all phases of the lifecycle *NOTE: this may be included as a function of another defined work product (Example: A CASE tool for design decomposition may have a mapping ability as part of its features)*
13-24	Validation results	• Validation checklist • Passed items of validation • Failed items of validation • Pending items of validation • Problems identified during validation • Risk analysis • Recommendation of actions • Conclusions of validation • Signature of validation
13-25	Verification results	• Verification checklist • Passed items of verification • Failed items of verification • Pending items of verification • Problems identified during verification • Risk analysis • Recommendation of actions • Conclusions of verification • Signature of verification
13-50	Test results	• Level Test Log • Anomaly Report • Level Test Report (Summary) - test cases not passed - test cases not executed - information about the test execution (date, tester name etc.) Additionally where necessary: • Level Interim Test Status Report • Master Test Report (Summary)
14-02	Corrective action register	• Identifies the initial problem • Identifies the ownership for completion of defined action • Defines a solution (series of actions to fix problem) • Identifies the open date and target closure date • Contains a status indicator • Indicates follow up audit actions
14-05	Preferred suppliers register	• Subcontractor or supplier history • List of potential subcontractor/suppliers • Qualification information • Identification of their qualifications • Past history information when it exists
14-08	Tracking system	• Ability to record customer and process owner information • Ability to record related system configuration information • Ability to record information about problem or action needed: - date opened and target closure date - severity/criticality of item - status of any problem or actions needed - information about the problem or action owner - priority of problem resolution • Ability to record proposed resolution or action plan • Ability to provide management status information • Information is available to all with a need to know • Integrated change control system(s)/records
14-51	Cybersecurity scenario register	• Identifies: - Damage scenarios - ID - Title - Description - Impact category - Safety - Financial - Operational - Privacy - Quality - Threat scenarios - ID - Asset concerned - Security property - Confidentiality - Integrity - Availability - Attack feasibility (high/medium/low/very low)
14-52	Asset library	• Identifies - title - description - security properties - Confidentiality - Integrity - Availability - stakeholders related to the asset
15-01	Analysis report	• What was analyzed? • Who did the analysis? • The analysis criteria used: - selection criteria or prioritization scheme used - decision criteria - quality criteria • Records the results: - what was decided/selected - reason for the selection - assumptions made - potential risks • Aspects of correctness to analyze include: - completeness - understandability - testability - verifiability - feasibility - validity - consistency - adequacy of content
15-08	Risk analysis report	• Identifies the risks analyzed - ID - impact scenario (e.g., damage scenario) • Records the results of the analysis: - potential ways to mitigate the risk - selected risk treatment option (e.g. risk acceptance as cybersecurity claim or risk reduction) - assumptions made - probability of occurrence (e.g., attack feasibility) - risk value - constraints
15-09	Risk status report	• Identifies the status of an identified risk: - related project or activity or product or service - risk statement - condition - consequence - changes in priority - duration of mitigation, when started - risk mitigation activities in progress - responsibility - constraints
15-21	Supplier evaluation report	• States the purpose of evaluation • Method and instrument (checklist, tool) used for evaluation • Requirements used for the evaluation • Assumptions and limitations • Identifies the context and scope information required (e.g., date of evaluation, parties involved) • Fulfillment of evaluation requirements
15-50	Vulnerability analysis report	• Identifies - ID - Description - Attack path concerned - Attack feasibility (e.g., CVSS rating - Common Vulnerability Scoring System)
17-11	Software requirements specification	• Identifies standards to be used • Identifies any software structure considerations/constraints • Identifies the required software elements • Identifies the relationship between software elements • Consideration is given to: - any required software performance characteristics - any required software interfaces - any required security characteristics required - any database design requirements - any required error handling and recovery attributes - any required resource consumption characteristics • Includes functional and non-functional cybersecurity software requirements • Associated to one or more cybersecurity goal • Cybersecurity requirements are recognizable and categorized as such
17-12	System requirements specification	• System requirements include: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. • Identifies the required system overview • Identifies any interrelationship considerations/constraints between system elements • Identifies any relationship considerations/constraints between the system elements and the software • Identifies any design considerations/constraints for each required system element, including: - memory/capacity requirements - hardware interface requirements - user interface requirements - external system interface requirements - performance requirements - command structures - security/data protection characteristics - application parameter settings - manual operations - reusable components - Describes the operation capabilities - Describes environmental capabilities - Documentation requirements - Reliability requirements - Logistical Requirements • Describes security requirements • Diagnosis requirements • Includes functional and non-functional cybersecurity system requirements • Associated to one or more cybersecurity goal • Cybersecurity requirements are recognizable and categorized as such
17-51	Cybersecurity goals	• Describe a property of an asset, that is necessary to protect cybersecurity • Associated to one or more threat scenarios
17-52	Cybersecurity controls	• Technical solutions to prevent, detect, or mitigate cybersecurity risks • Associated to one or more cybersecurity requirements
18-50	Supplier evaluation criteria	• Expectations for conformity, to be fulfilled by competent suppliers • Links from the expectations to national/international/domains-specific standards/laws/regulations • Requirements conformity evidence to be provided by the potential suppliers or assessed by the acquiring organization • Provisions for tailoring or exception to the requirements
19-10	Verification strategy	• Verification methods, techniques, and tools • Work product or processes under verification • Degrees of independence for verification • Identifies what needs there are to be satisfied • Establishes the options and approach for satisfying the need • Establishes the evaluation criteria against which the strategic options are evaluated • Identifies any constraints/risks and how these will be addressed • Verification ending criteria • Verification start, abort and restart criteria
19-11	Validation strategy	• Validation methods, techniques, and tools • Work products under validation • Degrees of independence for validation • Identifies what needs there are to be satisfied • Establishes the options and approach for satisfying the need • Establishes the evaluation criteria against which the strategic options are evaluated • Identifies any constraints/risks and how these will be addressed

Stakeholder Requirement: Contract 02-00

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ3_OUT1, ACQ3_OUT2, ACQ3_OUT3, ACQ12_OUT1, ACQ12_OUT2, ACQ12_OUT3, ACQ12_OUT4, ACQ12_OUT5, ACQ12_OUT6, ACQ12_OUT7, ACQ13_OUT1, ACQ13_OUT2, ACQ13_OUT3, ACQ13_OUT4, ACQ13_OUT5, ACQ13_OUT6, ACQ13_OUT7, ACQ13_OUT8, ACQ13_OUT9, ACQ2_OUT4

Defines what is to be purchased or delivered Identifies time frame for delivery or contracted service dates Identifies any statutory requirements Identifies monetary considerations Identifies any warranty information Identifies any copyright and licensing information Identifies any customer service requirements Identifies service level requirements References to any performance and quality expectations/constraints/monitoring Standards and procedures to be used Evidence of review and approval As appropriate to the contract the following are considered: references to any acceptance criteria references to any special customer needs (i.e., confidentiality requirements, security, hardware, etc.) references to any change management and problem resolution procedures identification of any interfaces to independent agents and subcontractors identification of customer’s role in the development and maintenance process identification of resources to be provided by the customer

Stakeholder Requirement: Commitment/agreement 02-01

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ3_OUT1, ACQ4_OUT4, ACQ12_OUT2, ACQ12_OUT4, ACQ12_OUT5, ACQ12_OUT6, ACQ12_OUT7, ACQ14_OUT3, SPL1_OUT6, MAN6_OUT1, PIM3_OUT1, ACQ2_OUT4

Signed off by all parties involved in the Establishes what the commitment is for Establishes the resources required to fulfill the commitment, such as: time people budget equipment facilities

Stakeholder Requirement: Interface agreement 02-50

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ2_OUT4

Interface agreement should include definitions regarding customer and supplier stakeholder and contacts tailoring agreements customer/supplier responsibilities (e.g., roles, RASIC chart) for distributive activities, including required actions in development and post-development share of information/work products in case of issues (e.g., vulnerabilities, findings, risks) agreed customer/supplier milestones duration of supplier’s support and maintenance

Stakeholder Requirement: Software architectural design 04-04

status: new tags: artifact safety_level: not set security_level: not set generated by: SWE2_OUT1, SWE2_OUT2, SWE2_OUT3, SWE2_OUT4, SWE2_OUT5, SEC2_OUT1

Describes the overall software structure Describes the operative system including task structure Identifies inter-task/inter-process communication Identifies the required software elements Identifies own developed and supplied code Identifies the relationship and dependency between software elements Identifies where the data (e.g., application parameters or variables) are stored and which measures (e.g., checksums, redundancy) are taken to prevent data corruption Describes how variants for different model series or configurations are derived Describes the dynamic behavior of the software (start-up, shutdown, software update, error handling and recovery, etc.) Describes which data is persistent and under which conditions Consideration is given to: any required software performance characteristics any required software interfaces any required security characteristics required any database design requirements

Stakeholder Requirement: Software detailed design 04-05

status: new tags: artifact safety_level: not set security_level: not set generated by: SWE3_OUT1, SWE3_OUT2, SWE3_OUT3, SEC2_OUT5

Provides detailed design (could be represented as a prototype, flow chart, entity relationship diagram, pseudo code, etc.) Provides format of input/output data Provides specification of CPU, ROM, RAM, EEPROM and Flash needs Describes the interrupts with their priorities Describes the tasks with cycle time and priority Establishes required data naming conventions Defines the format of required data structures Defines the data fields and purpose of each required data element Provides the specifications of the program structure

Stakeholder Requirement: System architectural design 04-06

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS3_OUT1, SYS3_OUT2, SYS3_OUT3, SYS3_OUT4, SYS3_OUT5, SEC2_OUT1

Provides an overview of all system design Describes the interrelationship between system elements Describes the relationship between the system elements and the software Specifies the design for each required system element, consideration is given to aspects such as: memory/capacity requirements hardware interface requirements user interface requirements external system interface requirements performance requirements command structures security/data protection characteristics settings for system parameters (such as application parameters or global variables) manual operations reusable components Mapping of requirements to system elements Description of the operation modes of the system components (startup, shutdown, sleep mode, diagnosis mode, etc.) Description of the dependencies among the system components regarding the operation modes Description of the dynamic behavior of the system and the system components

Stakeholder Requirement: Risk measure 07-07

status: new tags: artifact safety_level: not set security_level: not set generated by: MAN5_OUT5, MAN6_OUT3, MAN6_OUT4, MAN6_OUT7, MAN7_OUT6

Identifies the probability of risk occurring Identifies the impact of risk occurring Establishes measures for each risk defined Measures the change in the risk state

Stakeholder Requirement: Recovery plan 08-14

status: new tags: artifact safety_level: not set security_level: not set generated by: SUP8_OUT1, SUP8_OUT7, MAN5_OUT4, MAN5_OUT6, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8

Identifies what is to be recovered: procedures/methods to perform the recovery schedule for recovery time required for the recovery critical dependencies resources required for the recovery list of backups maintained staff responsible for recovery and roles assigned special materials required required work products required equipment required documentation locations and storage of backups contact information on who to notify about the recovery verification procedures cost estimation for recovery

Stakeholder Requirement: Risk management plan 08-19

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS1_OUT6, MAN5_OUT1, MAN5_OUT2, MAN5_OUT3, MAN5_OUT4, MAN5_OUT5, MAN5_OUT6, MAN7_OUT1, MAN7_OUT2, MAN7_OUT4, MAN7_OUT5, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8

Project risks identified and prioritized Mechanism to track the risk Threshold criteria to identify when corrective action required Proposed ways to mitigate risks: risk mitigator work around corrective actions activities/tasks monitoring criteria mechanisms to measure risk

Stakeholder Requirement: Risk mitigation plan 08-20

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS1_OUT6, MAN5_OUT3, MAN5_OUT4, MAN5_OUT5, MAN5_OUT6, ACQ2_OUT4

Planned risk treatment activities and tasks: describes the specifics of the risk treatment selected for a risk or combination of risks found to be unacceptable describes any difficulties that may be found in implementing the treatment Treatment schedule Treatment resources and their allocation Responsibilities and authority: describes who is responsible for ensuring that the treatment is being implemented and their authority Treatment control measures: defines the measures that will be used to evaluate the effectiveness of the risk treatment Treatment cost Interfaces among parties involved: describes any coordination among stakeholders or with the project’s master plan that must occur for the treatment to be properly implemented Environment/infrastructure: describes any environmental or infrastructure requirements or impacts (e.g., safety or security impacts that the treatment may have) Risk treatment plan change procedures and history

Stakeholder Requirement: Test specification 08-50

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS4_OUT3, SYS4_OUT5, SYS5_OUT2, SYS5_OUT3, SWE4_OUT2, SWE5_OUT3, SWE5_OUT5, SWE6_OUT2, SWE6_OUT3, SEC3_OUT2, SEC4_OUT2

Test Design Specification Test Case Specification Test Procedure Specification Identification of test cases for regression testing Additionally, for system integration: identification of required system elements (hardware elements, wiring elements, settings for parameters (such as application parameters or global variables), databases, etc.) necessary sequence or ordering identified for integrating the system elements

Stakeholder Requirement: Test plan 08-52

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS4_OUT1, SYS4_OUT2, SYS5_OUT1, SWE4_OUT1, SWE5_OUT1, SWE5_OUT2, SWE6_OUT1, SEC3_OUT1

Test Plan according to ISO/IEC/IEEE 29119-3 Context: project/Test sub-process test item(s) test scope assumptions and constraints stakeholder testing communication Test strategy identifies what needs are to be satisfied establishes the options and approach for satisfying the needs (black-box and/or white-box testing, boundary class test determination, regression testing strategy, etc.) establishes the evaluation criteria against which the strategic options are evaluated identifies any constraints/risks and how these will be addressed test design techniques test completion criteria test ending criteria test start, abort and re-start criteria metrics to be collected test data requirements retesting and regression testing suspension and resumption criteria deviations from the Organizational Test Strategy Test data requirements Test environment requirements Test sub-processes Test deliverables Testing activities and estimates

Stakeholder Requirement: Software unit 11-05

status: new tags: artifact safety_level: not set security_level: not set generated by: SWE3_OUT6, SEC2_OUT6

Follows established coding standards (as appropriate to the language and application): commented structured or optimized meaningful naming conventions parameter information identified error codes defined error messages descriptive and meaningful formatting – indented, levels Follows data definition standards (as appropriate for the language and application): variables defined data types defined classes and inheritance structures defined objects defined Entity relationships defined Database layouts are defined File structures and blocking are defined Data structures are defined Algorithms are defined Functional interfaces defined

Stakeholder Requirement: Request for quotation 12-01

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ14_OUT7, ACQ2_OUT3

Reference to the requirements specifications Identifies supplier selection criteria Identifies desired characteristics, such as: system architecture, configuration requirements or the requirements for service (consultants, maintenance, etc.) quality criteria or requirements project schedule requirements expected delivery/service dates cost/price expectations regulatory standards/requirements Identifies submission constraints: date for resubmission of the response requirements with regard to the format of response

Stakeholder Requirement: Acceptance record 13-01

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT3, SUP7_OUT4, SUP7_OUT5

Record of the receipt of the delivery Identification of the date received Identification of the delivered components Records the verification of any customer acceptance criteria defined Signed by receiving customer

Stakeholder Requirement: Communication record 13-04

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ3_OUT4, ACQ4_OUT1, ACQ4_OUT2, ACQ11_OUT3, SPL1_OUT1, SPL1_OUT6, SYS1_OUT1, SYS1_OUT4, SYS2_OUT8, SYS3_OUT6, SYS4_OUT8, SYS5_OUT6, SWE1_OUT8, SWE2_OUT6, SWE3_OUT5, SWE4_OUT5, SWE5_OUT8, SWE6_OUT6, SUP1_OUT3, SUP1_OUT4, SUP1_OUT5, SUP2_OUT5, SUP4_OUT3, MAN3_OUT4, MAN3_OUT6, PIM3_OUT6, REU2_OUT7, SEC1_OUT4, SEC2_OUT8, SEC3_OUT6, SEC4_OUT6

All forms of interpersonal communication, including: letters faxes emails voice recordings podcast blog videos forum live chat wikis photo protocol meeting support record

Stakeholder Requirement: Progress status record 13-14

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT2

Record of the status of a plan(s) (actual against planned), e.g.: status of actual tasks against planned tasks status of actual results against established objectives/goals status of actual resources allocation against planned resources status of actual cost against budget estimates status of actual time against planned schedule status of actual quality against planned quality Record of any deviations from planned activities and reason why

Stakeholder Requirement: Change request 13-16

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT4, SUP10_OUT2, SUP10_OUT3, SUP10_OUT4, SUP10_OUT5, SUP10_OUT6, SUP10_OUT7, MAN3_OUT7, PIM3_OUT2

Identifies purpose of change Identifies request status (e.g., open, allocated, implemented, closed) Identifies requester contact information Impacted system(s) Impact to operations of existing system(s) defined Impact to associated documentation defined Criticality of the request, due date

Stakeholder Requirement: Review record 13-19

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT2, ACQ13_OUT1, SPL1_OUT2, SYS1_OUT4, SYS1_OUT5, SYS2_OUT6, SYS3_OUT5, SYS4_OUT7, SYS5_OUT5, SWE1_OUT6, SWE2_OUT5, SWE3_OUT4, SWE4_OUT3, SWE4_OUT4, SWE5_OUT7, SWE6_OUT5, SUP1_OUT2, SUP1_OUT3, SUP1_OUT4, SUP4_OUT1, SUP4_OUT2, SUP4_OUT3, SUP4_OUT4, SUP4_OUT5, SUP7_OUT4, SUP7_OUT5, SUP10_OUT7, MAN3_OUT2, MAN3_OUT7, SEC1_OUT3, SEC2_OUT7, SEC3_OUT3, SEC3_OUT5, SEC4_OUT2, SEC4_OUT5

Provides the context information about the review: what was reviewed lists reviewers who attended status of the review Provides information about the coverage of the review: checklists review criteria requirements compliance to standards Records information about: the readiness for the review preparation time spent for the review time spent in the review reviewers, roles and expertise Review findings: non-conformities improvement suggestions Identifies the required corrective actions: risk identification prioritized list of deviations and problems discovered the actions, tasks to be performed to fix the problem ownership for corrective action status and target closure dates for identified problems

Stakeholder Requirement: Risk action request 13-20

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ13_OUT6, MAN5_OUT1, MAN5_OUT2, MAN5_OUT6, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8

Date of initiation Scope Subject Request originator Risk management process context: this section may be provided once, and then referenced in subsequent action requests if no changes have occurred process scope stakeholder perspective risk categories risk thresholds project objectives project assumptions project constraints Risks: this section may cover one risk or many, as the user chooses where all the information above applies to the whole set of risks, one action request may suffice where the information varies, each request may cover the risk or risks that share common information risk description(s) risk probability risk value risk consequences expected timing of risk Risk treatment alternatives: Treatment option selected- avoid/reduce/transfer alternative descriptions recommended alternative(s) justifications Risk action request disposition: each request should be annotated as to whether it is accepted, rejected or modified, and the rationale provided for whichever decision is taken

Stakeholder Requirement: Traceability record 13-22

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS2_OUT6, SYS3_OUT5, SYS4_OUT7, SYS5_OUT5, SWE1_OUT1, SWE1_OUT6, SWE2_OUT5, SWE3_OUT4, SWE4_OUT4, SWE5_OUT7, SWE6_OUT5, SEC1_OUT3, SEC2_OUT2, SEC2_OUT7, SEC3_OUT4, SEC4_OUT4

All requirements (customer and internal) are to be traced Identifies a mapping of requirement to lifecycle work products Provides the linkage of requirements to work product decomposition (i.e., requirement, design, coding, testing, deliverables, etc.) Provides forward and backwards mapping of requirements to associated work products throughout all phases of the lifecycle NOTE: this may be included as a function of another defined work product (Example: A CASE tool for design decomposition may have a mapping ability as part of its features)

Stakeholder Requirement: Validation results 13-24

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ11_OUT6, SEC4_OUT3

Validation checklist Passed items of validation Failed items of validation Pending items of validation Problems identified during validation Risk analysis Recommendation of actions Conclusions of validation Signature of validation

Stakeholder Requirement: Verification results 13-25

status: new tags: artifact safety_level: not set security_level: not set generated by: SWE4_OUT3, SWE4_OUT5, SUP2_OUT2, SUP2_OUT3, SUP2_OUT4, SUP2_OUT5, SEC3_OUT3, SEC3_OUT6

Verification checklist Passed items of verification Failed items of verification Pending items of verification Problems identified during verification Risk analysis Recommendation of actions Conclusions of verification Signature of verification

Stakeholder Requirement: Test results 13-50

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS4_OUT6, SYS4_OUT8, SYS5_OUT4, SYS5_OUT6, SWE4_OUT3, SWE4_OUT5, SWE5_OUT6, SWE5_OUT8, SWE6_OUT4, SWE6_OUT6, SEC3_OUT3, SEC3_OUT6

Level Test Log Anomaly Report Level Test Report (Summary) - test cases not passed test cases not executed information about the test execution (date, tester name etc.) Additionally where necessary: Level Interim Test Status Report Master Test Report (Summary)

Stakeholder Requirement: Corrective action register 14-02

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT4, ACQ11_OUT2, ACQ12_OUT3, ACQ15_OUT5, SUP1_OUT3, SUP1_OUT5, SUP1_OUT6, SUP2_OUT4, SUP4_OUT3, SUP4_OUT4, SUP4_OUT5, MAN3_OUT7, MAN5_OUT6, ACQ2_OUT3, ACQ2_OUT4

Identifies the initial problem Identifies the ownership for completion of defined action Defines a solution (series of actions to fix problem) Identifies the open date and target closure date Contains a status indicator Indicates follow up audit actions

Stakeholder Requirement: Preferred suppliers register 14-05

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ15_OUT3, ACQ2_OUT2

Subcontractor or supplier history List of potential subcontractor/suppliers Qualification information Identification of their qualifications Past history information when it exists

Stakeholder Requirement: Tracking system 14-08

status: new tags: artifact safety_level: not set security_level: not set generated by: SUP4_OUT3, SUP4_OUT4, SUP4_OUT5, MAN5_OUT5, MAN5_OUT6, MAN7_OUT4, MAN7_OUT5, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8

Ability to record customer and process owner information Ability to record related system configuration information Ability to record information about problem or action needed: date opened and target closure date severity/criticality of item status of any problem or actions needed information about the problem or action owner priority of problem resolution Ability to record proposed resolution or action plan Ability to provide management status information Information is available to all with a need to know Integrated change control system(s)/records

Stakeholder Requirement: Cybersecurity scenario register 14-51

status: new tags: artifact safety_level: not set security_level: not set generated by: MAN7_OUT1, MAN7_OUT3, MAN7_OUT5

Identifies: Damage scenarios ID Title Description Impact category Safety Financial Operational Privacy Quality Threat scenarios ID Asset concerned Security property Confidentiality Integrity Availability Attack feasibility (high/medium/low/very low)

Stakeholder Requirement: Asset library 14-52

status: new tags: artifact safety_level: not set security_level: not set generated by: MAN7_OUT1, MAN7_OUT3

Identifies title description security properties Confidentiality Integrity Availability stakeholders related to the asset

Stakeholder Requirement: Analysis report 15-01

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ4_OUT3, SYS1_OUT2, SYS1_OUT3, SYS1_OUT6, SYS2_OUT2, SYS2_OUT3, SYS2_OUT4, SYS2_OUT7, SWE1_OUT2, SWE1_OUT3, SWE1_OUT4, SWE1_OUT7, SWE4_OUT3, SUP4_OUT3, SUP4_OUT5, SUP9_OUT3, MAN6_OUT2, MAN6_OUT5, SEC1_OUT1, SEC1_OUT2

What was analyzed? Who did the analysis? The analysis criteria used: selection criteria or prioritization scheme used decision criteria quality criteria Records the results: what was decided/selected reason for the selection assumptions made potential risks Aspects of correctness to analyze include: completeness understandability testability verifiability feasibility validity consistency adequacy of content

Stakeholder Requirement: Risk analysis report 15-08

status: new tags: artifact safety_level: not set security_level: not set generated by: MAN5_OUT4, MAN7_OUT5, MAN7_OUT6

Identifies the risks analyzed ID impact scenario (e.g., damage scenario) Records the results of the analysis: potential ways to mitigate the risk selected risk treatment option (e.g. risk acceptance as cybersecurity claim or risk reduction) assumptions made probability of occurrence (e.g., attack feasibility) risk value constraints

Stakeholder Requirement: Risk status report 15-09

status: new tags: artifact safety_level: not set security_level: not set generated by: MAN5_OUT4, MAN5_OUT5, MAN7_OUT6, MAN7_OUT7, MAN7_OUT8

Identifies the status of an identified risk: related project or activity or product or service risk statement condition consequence changes in priority duration of mitigation, when started risk mitigation activities in progress responsibility constraints

Stakeholder Requirement: Supplier evaluation report 15-21

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ15_OUT2, ACQ2_OUT2

States the purpose of evaluation Method and instrument (checklist, tool) used for evaluation Requirements used for the evaluation Assumptions and limitations Identifies the context and scope information required (e.g., date of evaluation, parties involved) Fulfillment of evaluation requirements

Stakeholder Requirement: Vulnerability analysis report 15-50

status: new tags: artifact safety_level: not set security_level: not set generated by: SEC2_OUT4

Identifies ID Description Attack path concerned Attack feasibility (e.g., CVSS rating - Common Vulnerability Scoring System)

Stakeholder Requirement: Software requirements specification 17-11

status: new tags: artifact safety_level: not set security_level: not set generated by: SWE1_OUT1, SEC1_OUT1, SEC1_OUT2

Identifies standards to be used Identifies any software structure considerations/constraints Identifies the required software elements Identifies the relationship between software elements Consideration is given to: any required software performance characteristics any required software interfaces any required security characteristics required any database design requirements any required error handling and recovery attributes any required resource consumption characteristics Includes functional and non-functional cybersecurity software requirements Associated to one or more cybersecurity goal Cybersecurity requirements are recognizable and categorized as such

Stakeholder Requirement: System requirements specification 17-12

status: new tags: artifact safety_level: not set security_level: not set generated by: SYS2_OUT1, SYS2_OUT5, SEC1_OUT1, SEC1_OUT2

System requirements include: functions and capabilities of the system; business, organizational and user requirements; safety, security, human-factors engineering (ergonomics), interface, operations, and maintenance requirements; design constraints and qualification requirements. Identifies the required system overview Identifies any interrelationship considerations/constraints between system elements Identifies any relationship considerations/constraints between the system elements and the software Identifies any design considerations/constraints for each required system element, including: memory/capacity requirements hardware interface requirements user interface requirements external system interface requirements performance requirements command structures security/data protection characteristics application parameter settings manual operations reusable components Describes the operation capabilities Describes environmental capabilities Documentation requirements Reliability requirements Logistical Requirements Describes security requirements Diagnosis requirements Includes functional and non-functional cybersecurity system requirements Associated to one or more cybersecurity goal Cybersecurity requirements are recognizable and categorized as such

Stakeholder Requirement: Cybersecurity goals 17-51

status: new tags: artifact safety_level: not set security_level: not set generated by: SEC1_OUT1

Describe a property of an asset, that is necessary to protect cybersecurity Associated to one or more threat scenarios

Stakeholder Requirement: Cybersecurity controls 17-52

status: new tags: artifact safety_level: not set security_level: not set generated by: SEC2_OUT3

Technical solutions to prevent, detect, or mitigate cybersecurity risks Associated to one or more cybersecurity requirements

Stakeholder Requirement: Supplier evaluation criteria 18-50

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ15_OUT1, ACQ2_OUT1

Expectations for conformity, to be fulfilled by competent suppliers Links from the expectations to national/international/domains-specific standards/laws/regulations Requirements conformity evidence to be provided by the potential suppliers or assessed by the acquiring organization Provisions for tailoring or exception to the requirements

Stakeholder Requirement: Verification strategy 19-10

status: new tags: artifact safety_level: not set security_level: not set generated by: SUP2_OUT1, SEC3_OUT1

Verification methods, techniques, and tools Work product or processes under verification Degrees of independence for verification Identifies what needs there are to be satisfied Establishes the options and approach for satisfying the need Establishes the evaluation criteria against which the strategic options are evaluated Identifies any constraints/risks and how these will be addressed Verification ending criteria Verification start, abort and restart criteria

Stakeholder Requirement: Validation strategy 19-11

status: new tags: artifact safety_level: not set security_level: not set generated by: ACQ14_OUT1, SEC4_OUT1

Validation methods, techniques, and tools Work products under validation Degrees of independence for validation Identifies what needs there are to be satisfied Establishes the options and approach for satisfying the need Establishes the evaluation criteria against which the strategic options are evaluated Identifies any constraints/risks and how these will be addressed

Annex C Terminology

Automotive SPICE follows the following precedence for use of terminology:

1. ISO/IEC 33001 for assessment-related terminology

2. ISO/IEC/IEEE 24765 and ISO/IEC/IEEE 29119 terminology (as contained in Annex C)

3. Terms introduced by Automotive SPICE (as contained in Annex C)

4. ISO/SAE 21434 for cybersecurity-related terminology

Annex C lists the applicable terminology references from ISO/IEC/IEEE 24765 and ISO/IEC/IEEE 29119. It also provides terms which are specifically defined within Automotive SPICE. Some of these definitions are based on ISO/IEC/IEEE 24765.

Table 31 Table C.1 — Terminology

Term	Origin	Description
Acceptance testing	ISO/IEC/IEEE 24765	Formal testing conducted to enable a user, customer, or authorized entity to determine whether to accept a system or component.
Application parameter	Automotive SPICE V3.1	An application parameter is a parameter containing data applied to the system or software functions, behavior or properties. The notion of application parameter is expressed in two ways: firstly, the logical specification (including name, description, unit, value domain or threshold values or characteristic curves, respectively) and secondly, the actual quantitative data value it receives by means of data application.
Architecture element	Automotive SPICE V3.1	Result of the decomposition of the architecture on system and software level: The system is decomposed into elements of the system architecture across appropriate hierarchical levels. The software is decomposed into elements of the software architecture across appropriate hierarchical levels down to the software components (the lowest level elements of the software architecture).
Asset	ISO/SAE 21434	object that has value, or contributes to value
Attack path	ISO/SAE 21434	set of deliberate actions to realize a threat scenario
Attack feasibility	ISO/SAE 21434	attribute of an attack path describing the ease of successfully carrying out the corresponding set of actions
Black-box testing	Automotive SPICE V3.1	Method of requirement testing where tests are developed without knowledge of the internal structure and mechanisms of the tested item.
Code review	Automotive SPICE V3.1	A check of the code by one or more qualified persons to determine its suitability for its intended use and identify discrepancies from specifications and standards.
Coding	ISO/IEC/IEEE 24765	The transforming of logic and data from design specifications (design descriptions) into programming language.
Consistency	Automotive SPICE V3.1	Consistency addresses content and semantics and ensures that work products are not in contradiction to each other. Consistency is supported by bidirectional traceability.
Cybersecurity goal,	ISO/SAE 21434	concept-level cybersecurity requirement associated with one or more threat scenarios
Cybersecurity property	ISO/SAE 21434	attribute that can be worth protecting
Damage scenario,	ISO/SAE 21434	adverse consequence involving a vehicle or vehicle function and affecting a road user
Element	Automotive SPICE V3.1	Elements are all structural objects on architectural and design level on the left side of the “V”. Such elements can be further decomposed into more fine-grained sub-elements of the architecture or design across appropriate hierarchical levels.
Error	ISO/IEC/IEEE 24765	The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition.
Fault	ISO/IEC/IEEE 24765	A manifestation of an error in software.
Functional requirement	ISO/IEC/IEEE 24765	A statement that identifies what a product or process must accomplish to produce required behavior and/or results.
Hardware	ISO/IEC/IEEE 24765	Physical equipment used to process, store, or transmit computer programs or data.
Integration	Automotive SPICE V3.1	A process of combining items to larger items up to an overall system.
Quality assurance	ISO/IEC/IEEE 24765	A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements.
Regression testing	Automotive SPICE V3.1	Selective retesting of a system or item to verify that modifications have not caused unintended effects and that the system or item still complies with its specified requirements.
Requirement	Automotive SPICE V3.1	A property or capability that must be achieved or possessed by a system, system item, product or service to satisfy a contract, standard, specification or other formally imposed documents.
Requirements specification	Automotive SPICE V3.1	A document that specifies the requirements for a system or item. Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards.
Software	ISO/IEC/IEEE 24765	Computer programs, procedures, and possibly associated documentation and data pertaining to the operation of a computer system.
Software component	Automotive SPICE V3.1	In Automotive SPICE V3.1 the term “software component” is used for the lowest level elements of the software architecture for which finally the detailed design is defined. A software “component” consists of one or more software “units”. → [ARCHITECTURE ELEMENT], [UNIT]
Software element		→ [ARCHITECTURE ELEMENT]
Software unit		→ [UNIT]
Static analysis	Automotive SPICE V3.1	A process of evaluating an item based on its form, structure, content or documentation.
System	Automotive SPICE V3.1	A collection of interacting items organized to accomplish a specific function or set of functions within a specific environment.
Testing	Automotive SPICE V3.1	Activity in which an item (system, hardware, or software) is executed under specific conditions; and the results are recorded, summarized and communicated.
Threat scenario	ISO/SAE 21434	potential cause of compromise of cybersecurity properties of one or more assets in order to realize a damage scenario
Traceability	ISO/IEC/IEEE 24765	The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or mastersubordinate relationship to one another.
Unit	Automotive SPICE V3.1	Part of a software component which is not further subdivided. → [SOFTWARE COMPONENT]
Unit test	Automotive SPICE V3.1	The testing of individual software units or a set of combined software units.
Validation	ISO/IEC/IEEE 29119	Validation demonstrates that the work item can be used by the users for their specific tasks.
Verification	ISO/IEC/IEEE 29119	Verification is confirmation, through the provision of objective evidence, that specified requirements have been fulfilled in a given work item.
White-box testing	Automotive SPICE V3.1	Method of testing where tests are developed based on the knowledge of the internal structure and mechanisms of the tested item.

Table 32 Table C.2 — Abbreviations

AS	Automotive SPICE
ACSMS	Automotive Cybersecurity Management System
ATA	Attack Tree Analysis
BP	Base Practice
CAN	Controller Area Network
CASE	Computer-Aided Software Engineering
CCB	Change Control Board
CFP	Call For Proposals
CPU	Central Processing Unit
ECU	Electronic Control Unit
EEPROM	Electrically Erasable Programmable Read-Only Memory
FMEA	Failure Mode and Effects Analysis
FTA	Fault Tree Analysis
GP	Generic Practice
GR	Generic Resource
HARA	Hazard Analysis and Risk Assessment
IEC	International Electrotechnical Commission
IEEE	Institute of Electrical and Electronics Engineers
I/O	Input/Output
ISO	International Organization for Standardization
MISRA	Motor Industry Software Reliability Association
PA	Process Attribute
PAM	Process Assessment Model
PRM	Process Reference Model
RAM	Random Access Memory
RC	Recommendation
RL	Rule
ROM	Read Only Memory
SPICE	Software Process Improvement and Capability dEtermination
TARA	Threat Analyses and Risk Assessment
UNECE	United Nations Economic Commission for Europe
VDA	Verband Der Automobilindustrie (German Association of the Automotive Industry)
WP	Work Product
WPC	Work Product Characteristic

Annex E Traceability and consistency

Traceability and consistency are addressed by two separate base practices in the Automotive SPICE for Cybersecurity as well as in the Automotive SPICE 3.1 PAM. Traceability refers to the existence of references or links between work products thereby further supporting coverage, impact analysis, requirements implementation status tracking etc. In contrast, consistency addresses content and semantics.

Furthermore, bidirectional traceability has been explicitly defined between

• threat scenarios and cybersecurity goals

• cybersecurity goals and validation specification

• cybersecurity requirements/architectural design/software detailed design and risk treatment verification specification

• validation specifications and validation results, and

• test cases and verification results.

An overview of bidirectional traceability and consistency is depicted in the following figure.

Fig. 17 Figure 5 — Bidirectional traceability and consistency