Initial Cybersecurity Concept

Initial Cybersecurity Concept (Draft)

Generated: 2026-06-24. Process backbone: the 'Create cybersecurity concept' activity (see cybersecurity/source document). Scope: Define & Code phase - lightweight but sufficient for feasibility analysis, effort estimation, customer alignment, technical planning and early risk reduction before project award.

Built only from accepted / accepted-with-assumption / partially-accepted requirements, open points affecting the concept, and current assumptions.

Legend: [Confirmed] [Assumption] [Open Point] [Customer-Owned] [Supplier-Owned] [Shared Responsibility].

1. Concept Scope (Define & Code phase)

• [Confirmed] 696 requirements are in supplier scope (Accept / Accept-with-Assumption / Partial).
• [Assumption] 309 requirements carry an explicit assumption pending customer confirmation.
• [Open Point] 9 open points must be resolved for the concept to be frozen.
• [Assumption] Working item: Electric Clutch Actuator (ECA) Control ECU on the TRATON GW AMT gearbox platform.

2. Customer Cybersecurity Input Classification

Customer inputs reviewed and classified (Definition-of-Done item 1).

3. System Context

• [Confirmed] The ECU sits in the vehicle drivetrain, controlling the electric clutch actuator.
• [Confirmed] External interfaces: vehicle network (CAN/PWM), diagnostic tester (UDS), software-update path.
• [Customer-Owned] OEM backend, PKI and security operations are customer-owned unless a CIA/DIA states otherwise.

4. Cybersecurity Assumptions

• [Assumption] RFQX-1001379436-P10-000-01-0007: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0008: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0012: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0013: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0015: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0017: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0018: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0019: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0021: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0022: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0024: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0025: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0027: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0028: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] RFQX-1001379436-P10-000-01-0029: Customer approves the proposed implementation method and responsibility allocation.
• Additional assumptions: 294 further assumptions in the review register.

5. Cybersecurity Constraints and Exclusions

• [Customer-Owned] PKI / key generation authority, backend update campaign and fleet monitoring are excluded from supplier scope unless confirmed.
• [Confirmed] OCR is disabled and PDFs are not analysed downstream; the concept is Markdown-derived.

6. Relevant Assets

• [Confirmed] Clutch actuator command/control integrity; ECU application and boot image authenticity; diagnostic access; key material; security logs.

7. Interfaces

• [Confirmed] Vehicle network interface, diagnostic interface, software-update interface, key/certificate provisioning interface.

8. High-Level Cybersecurity Functions

• [Supplier-Owned] Diagnostic security (derived from 19 accepted requirements).
• [Supplier-Owned] Cybersecurity requirement handling (derived from 16 accepted requirements).
• [Supplier-Owned] Authentication (derived from 15 accepted requirements).
• [Supplier-Owned] Key management (derived from 13 accepted requirements).
• [Supplier-Owned] Certificate handling (derived from 12 accepted requirements).
• [Supplier-Owned] Vulnerability management (derived from 1 accepted requirements).
• [Supplier-Owned] Incident response (derived from 1 accepted requirements).
• [Supplier-Owned] Logging and audit trail (derived from 1 accepted requirements).
• [Supplier-Owned] Secure communication (derived from 1 accepted requirements).

9. Security Capabilities

• Diagnostic security: 19 requirements.
• Cybersecurity requirement handling: 16 requirements.
• Authentication: 15 requirements.
• Key management: 13 requirements.
• Certificate handling: 12 requirements.
• Vulnerability management: 1 requirements.
• Incident response: 1 requirements.
• Logging and audit trail: 1 requirements.
• Secure communication: 1 requirements.

10. Cybersecurity Goals

• [Confirmed] Preserve integrity/authenticity of actuator control and ECU software.
• [Confirmed] Control diagnostic and update access.
• [Assumption] Protect allocated communication signals (SecOC/SDT) pending signal allocation (OP-005).

11. Responsibility Allocation (CIA / RASIC)

Mapping of cybersecurity scope to supplier responsibilities (Definition-of-Done item 4-5). No supplier responsibility is assumed for customer-owned work products unless the CIA/RASIC confirms it.

12. Customer Cybersecurity Requirements

• 454 accepted security/functional requirements form the customer requirement basis.

13. Supplier Cybersecurity Requirements to Derive

• SSR-CON-001 (Candidate): The supplier shall produce and maintain the cybersecurity concept and verification evidence covering Security evidence and traceability.
• SSR-VIH-001 (Candidate): The supplier shall support vulnerability monitoring and incident handling for Vulnerability and Incident Handling over the defined lifecycle, including field updates.
• SSR-CON-002 (Ready for Customer Alignment): The supplier shall produce and maintain the cybersecurity concept and verification evidence covering Cybersecurity Concept and Evidence.
• SSR-CON-003 (Candidate): The supplier shall produce and maintain the cybersecurity concept and verification evidence covering Security evidence and traceability.
• SSR-HW-001 (Ready for Customer Alignment): The ECU hardware shall provide the platform and secure-storage capabilities required for Hardware / HSM / Secure Storage.
• SSR-DAI-001 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data.
• SSR-SYS-001 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-002 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-003 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-004 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-PROD-001 (Candidate): The ECU and production process shall enforce development/production hardening for Supplier Development and Production Hardening, including debug lock and protected access.
• SSR-COM-001 (Ready for Customer Alignment): The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-COM-002 (Candidate): The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-COM-003 (Candidate): The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-KEY-001 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Key and Certificate Handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-VIH-002 (Candidate): The supplier shall support vulnerability monitoring and incident handling for Vulnerability and Incident Handling over the defined lifecycle, including field updates.
• SSR-VIH-003 (Ready for Customer Alignment): The supplier shall support vulnerability monitoring and incident handling for Vulnerability and Incident Handling over the defined lifecycle, including field updates.
• SSR-VIH-004 (Candidate): The supplier shall support vulnerability monitoring and incident handling for Vulnerability and Incident Handling over the defined lifecycle, including field updates.
• SSR-LIFE-001 (Ready for Internal Review): The ECU and supplier process shall handle lifecycle, field return and decommissioning for Lifecycle / Field Return / Decommissioning, including secure data and key handling.
• SSR-LOG-001 (Candidate): The ECU shall record bounded security-relevant events for Security Logging and Event Handling with sufficient integrity and context for diagnostics and incident evidence.
• SSR-COM-004 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-DAI-002 (Candidate): The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data.
• SSR-TOOL-001 (Candidate): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-DAI-003 (Ready for Customer Alignment): The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data.
• SSR-TOOL-002 (Ready for Customer Alignment): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-TOOL-003 (Blocked by Customer Clarification): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-TOOL-004 (Blocked by Customer Clarification): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-COM-005 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-COM-006 (Ready for Customer Alignment): The ECU shall restrict and protect communication for Secure Communication and Boundary Control, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-SYS-005 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-006 (Candidate): The ECU shall implement the System Function behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-COM-007 (Candidate): The ECU shall restrict and protect communication for External Interfaces, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-RBAC-001 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-VV-001 (Candidate): The supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan.
• SSR-DIAG-001 (Candidate): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-COM-008 (Candidate): The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-LIFE-002 (Ready for Internal Review): The ECU and supplier process shall handle lifecycle, field return and decommissioning for Lifecycle / Field Return / Decommissioning, including secure data and key handling.
• SSR-BOOT-001 (Blocked by Customer Clarification): The ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure.
• SSR-BOOT-002 (Candidate): The ECU shall verify boot and application authenticity/integrity for Secure software update and flash readiness and enforce the defined behaviour on verification failure.
• SSR-UPD-001 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-UPD-002 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-BOOT-003 (Candidate): The ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure.
• SSR-DIAG-002 (Ready for Customer Alignment): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DAI-004 (Ready for Customer Alignment): The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data.
• SSR-RBAC-002 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure software update and flash readiness, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-SDT-001 (Ready for Customer Alignment): The ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme.
• SSR-UPD-003 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-UPD-004 (Candidate): The ECU shall support secure software update/flashing for Secure software update and flash readiness, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-TOOL-005 (Ready for Customer Alignment): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-BOOT-004 (Ready for Customer Alignment): The ECU shall verify boot and application authenticity/integrity for Bootloader and Application State Handling and enforce the defined behaviour on verification failure.
• SSR-VV-002 (Ready for Customer Alignment): The supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan.
• SSR-VV-003 (Ready for Customer Alignment): The supplier shall verify and validate Security evidence and traceability per the agreed cybersecurity verification and validation plan.
• SSR-COM-009 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-DAI-005 (Ready for Customer Alignment): The ECU shall verify the authenticity and integrity of Security evidence and traceability data and reject manipulated or unauthenticated data.
• SSR-SDT-002 (Ready for Customer Alignment): The ECU shall protect security-relevant data transfer for Secure Data Transfer / Data Security Container using the agreed secured data transfer / data security container scheme.
• SSR-RBAC-003 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-RBAC-004 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-DIAG-003 (Candidate): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DIAG-004 (Candidate): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DIAG-005 (Candidate): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DIAG-006 (Blocked by Customer Clarification): The ECU shall provide the diagnostic services for Diagnostic Services required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DAI-006 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Security evidence and traceability data and reject manipulated or unauthenticated data.
• SSR-DAI-007 (Candidate): The ECU shall verify the authenticity and integrity of Security evidence and traceability data and reject manipulated or unauthenticated data.
• SSR-TOOL-006 (Ready for Customer Alignment): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Tooling / IT / Evidence Storage.
• SSR-RBAC-005 (Candidate): The ECU shall enforce authenticated, role-authorised access for Secure Diagnostics / RBAC, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-RBAC-006 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure communication and freshness protection, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-KEY-002 (Candidate): The ECU shall manage key and certificate material for Key and Certificate Handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-KEY-003 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Key and Certificate Handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-DAI-008 (Candidate): The ECU shall verify the authenticity and integrity of Data Authenticity and Integrity Verification data and reject manipulated or unauthenticated data.
• SSR-KEY-004 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Secure communication and freshness protection across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-COM-010 (Candidate): The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-RBAC-007 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Secure communication and freshness protection, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-COM-011 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-VV-004 (Blocked by Customer Clarification): The supplier shall verify and validate Secure communication and freshness protection per the agreed cybersecurity verification and validation plan.
• SSR-DAI-009 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Secure communication and freshness protection data and reject manipulated or unauthenticated data.
• SSR-COM-012 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-COM-013 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Secure communication and freshness protection, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.

14. Required Cybersecurity Work Products

15. Required Capabilities, Tools, IT, Hardware, Test Environment

• [Supplier-Owned] Crypto/key tooling, secure flashing tools, security test bench (HIL), penetration/fuzz tooling.
• [Supplier-Owned] Secure development environment, vulnerability-monitoring sources, evidence storage (Configuration Management).
• [Customer-Owned] PKI / signing infrastructure, backend update server.

16. Capability Gaps and Missing Information

17. Applicable Regulations and Target Market

• [Assumption] UN R155 (CSMS) and UN R156 (software update) apply for the target market; confirm with customer.
• [Assumption] EU CRA may apply depending on placement on the EU market; confirm with customer.
• [Confirmed] ISO/SAE 21434 is the governing engineering standard for the concept.

18. Open Cybersecurity Topics

• [Open Point] OP-001 (High): ECU designation, variant and item definition for TARA - owner OEM / Customer.
• [Open Point] OP-002 (High): Diagnostic security role model and service authorization - owner Shared (OEM policy / Supplier ECU).
• [Open Point] OP-003 (High): Key and certificate ownership, provisioning and lifecycle - owner OEM / Customer (PKI) + Supplier (ECU).
• [Open Point] OP-004 (High): Secure software update / backend campaign responsibility - owner Shared (OEM backend / Supplier ECU).
• [Open Point] OP-005 (High): Secure on-board communication (SecOC/SDT) signal allocation - owner OEM / Customer.
• [Open Point] OP-009 (High): Cybersecurity work products, DIA and responsibility split - owner OEM / Customer + Supplier (DIA).
• [Open Point] OP-006 (Medium): Incident response and vulnerability management ownership - owner OEM / Customer (fleet) + Supplier (ECU).
• [Open Point] OP-008 (Medium): Production, development and debug-interface hardening - owner Shared (OEM process / Supplier ECU).
• [Open Point] OP-011 (Medium): Document-specific scope and responsibility confirmation - owner OEM / Customer.

19. Concept Risks

• [Open Point] 6 high-priority open points could rework the concept if unresolved.
• [Assumption] 309 assumptions could change scope if the customer disagrees.
• [Shared] Responsibility gaps (no signed CIA/RASIC) could leave a control unimplemented or duplicated.

20. Definition of Done / KPI Readiness

21. RASI

• Responsible: Cybersecurity Manager / Lead (Software Lead where SW concept impact exists).
• Accountable: Cybersecurity Manager (Program Manager for commitment/planning impact).
• Supporting: System/Software Architect, Hardware Lead, IT/Toolchain, Quality/SWQA, Configuration Manager, Functional Safety Manager, Key Account/Sales.
• Informed: Product Owner, Program Manager, Engineering Management, Customer cybersecurity contact, Purchasing/Supplier Management.

22. Interfacing Activities

• Previous: Collect & analyze customer input; Review RFQ package & cybersecurity requirements; Specify system functions & preliminary architecture; Review customer CIA / responsibility matrix.
• Next: Define cybersecurity management plan; Establish project plans/timeline/budget; Derive supplier cybersecurity requirements; Plan TARA / concept refinement if awarded; Align cybersecurity work products with configuration item list.

Activity Backbone: Create Cybersecurity Concept

Markdown reference derived from the customer/process activity definition "Create cybersecurity concept" (NPI v0.1.0, page owner Ivar Haug). Used as the process backbone for the RFQX requirement-review and concept workflow. The PDF is a methodology input only; it is not analysed downstream and OCR stays off.

1.1 Description

Define the initial cybersecurity concept for the requested product/system based on customer cybersecurity inputs, RFQ package, cybersecurity goals/requirements, applicable standards, regulations and interface expectations. Establishes the high-level supplier cybersecurity approach for the Define & Code phase: assumptions, required capabilities, relevant system/security functions, resource needs, IT/tooling needs, hardware/test-environment needs, and open cybersecurity topics requiring customer clarification. Lightweight but sufficient for feasibility analysis, effort estimation, customer alignment, technical planning and early risk reduction before project award or project start.

1.2 Inputs

RFQ package & customer product requirements; customer cybersecurity goals & requirements; customer cybersecurity concept (if provided); customer TARA (if provided); customer cybersecurity standards/policies/templates/process requirements; Cybersecurity Interface Agreement (CIA) / RASIC / responsibility matrix; supplier evaluation questionnaire / capability assessment; applicable regulations & target market (UN R155 / R156, EU CRA where applicable); item definition, system context, functions, interfaces, preliminary architecture; known SW/HW/IT/toolchain/infrastructure constraints; internal competence matrix; lessons learned & reusable assets; assumptions, open points, clarification list.

1.3 / 1.4 Definition of Done

• Customer cybersecurity inputs reviewed and classified.
• Scope, assumptions, constraints and exclusions documented.
• Initial high-level cybersecurity concept defined.
• Goals/requirements/standards/regulations/expectations mapped to supplier responsibilities.
• Required work products identified and aligned with CIA / RASIC / responsibility matrix.
• Required capabilities, competences, tools, IT, hardware and test-environment needs identified.
• Capability gaps and missing information documented with mitigation/escalation.
• Open cybersecurity topics clarified with customer or recorded for follow-up.
• Concept reviewed with Cybersecurity Manager and relevant technical leads.
• Concept provides sufficient input for estimation, planning and the cybersecurity management plan.

1.4 RASI

• Responsible: Cybersecurity Manager / Lead (Software Lead where SW concept impact exists).
• Accountable: Cybersecurity Manager (Program Manager for commitment/planning impact).
• Supporting: System Architect, Software Architect, Hardware Lead, IT/Toolchain, Quality/SWQA, Configuration Manager, Functional Safety Manager, Key Account/Sales.
• Informed: Product Owner, Program Manager, Engineering Management, Customer cybersecurity contact, Purchasing/Supplier Management.

1.5 Interfacing Activities

• Previous: Collect & analyze customer input; Review RFQ package & customer cybersecurity requirements; Specify system functions & preliminary architecture; Review customer CIA / responsibility matrix.
• Next: Define cybersecurity management plan; Establish project plans/timeline/budget; Derive supplier cybersecurity requirements; Plan TARA / concept refinement if awarded; Align cybersecurity work products with configuration item list.

2.1 Implementation Steps

1. Collect all customer cybersecurity input documents. 2. Analyze & classify customer requirements (technical, process, work product, compliance, resource needs, open points). 3. Review CIA / RASIC / responsibility matrix; identify supplier-owned, customer-owned, shared, unclear responsibilities. 4. Define the initial high-level concept (assumptions, assets, interfaces, functions, protection needs, constraints). 5. Identify required capabilities vs internal competence, toolchain, IT, hardware, test environment, supplier capabilities. 6. Identify capability gaps, missing information, unclear requirements, clarification needs. 7. Align with IT/toolchain on tools, access, repositories, secure dev environment, vulnerability sources, evidence storage. 8. Assess implied regulations, market obligations, audits, assessments, certifications, evidence expectations. 9. Document concept, assumptions, open points, risks and recommended actions for RFQ/early planning. 10. Review the concept with Cybersecurity Manager, Program Manager, SWQA and technical leads.

2.2 Work Products

Initial cybersecurity concept; Customer cybersecurity input analysis / requirement classification; CIA / RASIC / responsibility matrix review; Cybersecurity capability & competence evaluation; Open points & customer clarification list; Initial cybersecurity risk & gap list.

2.3 KPIs (target: Yes)

Customer input package reviewed; CIA/responsibility matrix reviewed & supplier responsibilities identified; initial concept documented; assumptions & open points documented; capability/competence gaps identified; required IT/toolchain/hardware/resource needs identified; clarification topics raised/tracked; concept reviewed with Cybersecurity Manager and technical leads.

2.5 Key Guardrails

• Keep the concept appropriate for Define & Code: sufficient for RFQ/feasibility/estimation/planning, not heavier than needed before award.
• Do not assume supplier responsibility for customer-owned cybersecurity work products unless the CIA / RASIC confirms it.
• Separate confirmed requirements from assumptions and open points.
• Record unclear requirements and responsibility gaps as customer clarification topics.