Initial Cybersecurity Concept

Initial Cybersecurity Concept (Draft)

Generated: 2026-06-20. Process backbone: the 'Create cybersecurity concept' activity (see cybersecurity/activity_create_cybersecurity_concept.md). 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] 947 requirements are in supplier scope (Accept / Accept-with-Assumption / Partial).
• [Assumption] 389 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] REQ-AUTO-00001: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0001: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0002: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ-AUTO-00005: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0003: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0022: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ-AUTO-00009: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0023: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ-AUTO-00011: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0024: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0004: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0005: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0007: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0025: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] REQ_SEC_0042: Customer approves the proposed implementation method and responsibility allocation.
• [Assumption] … 374 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] Authentication (derived from 30 accepted requirements).
• [Supplier-Owned] Diagnostic security (derived from 30 accepted requirements).
• [Supplier-Owned] Cybersecurity requirement handling (derived from 17 accepted requirements).
• [Supplier-Owned] Key management (derived from 13 accepted requirements).
• [Supplier-Owned] Certificate handling (derived from 5 accepted requirements).
• [Supplier-Owned] Vulnerability management (derived from 2 accepted requirements).
• [Supplier-Owned] Secure communication (derived from 2 accepted requirements).
• [Supplier-Owned] Incident response (derived from 1 accepted requirements).
• [Supplier-Owned] Logging and audit trail (derived from 1 accepted requirements).

9. Security Capabilities

• Authentication: 30 requirements.
• Diagnostic security: 30 requirements.
• Cybersecurity requirement handling: 17 requirements.
• Key management: 13 requirements.
• Certificate handling: 5 requirements.
• Vulnerability management: 2 requirements.
• Secure communication: 2 requirements.
• Incident response: 1 requirements.
• Logging and audit trail: 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

• 672 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 Cybersecurity requirement handling.
• SSR-VIH-001 (Candidate): The supplier shall support vulnerability monitoring and incident handling for Vulnerability management over the defined lifecycle, including field updates.
• SSR-SYS-001 (Candidate): The ECU shall implement the System behavior 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 behavior 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 behavior 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 behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-005 (Blocked by Customer Clarification): The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-006 (Ready for Customer Alignment): The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-007 (Ready for Customer Alignment): The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-SYS-008 (Blocked by Customer Clarification): The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• 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-DAI-001 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Authentication data and reject manipulated or unauthenticated data.
• SSR-PROD-001 (Candidate): The ECU and production process shall enforce development/production hardening for Hardware platform support, including debug lock and protected access.
• SSR-KEY-001 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Key management 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 System behavior over the defined lifecycle, including field updates.
• SSR-VIH-003 (Candidate): The supplier shall support vulnerability monitoring and incident handling for Incident response over the defined lifecycle, including field updates.
• SSR-VIH-004 (Ready for Customer Alignment): The supplier shall support vulnerability monitoring and incident handling for System behavior over the defined lifecycle, including field updates.
• SSR-VIH-005 (Candidate): The supplier shall support vulnerability monitoring and incident handling for External interfaces over the defined lifecycle, including field updates.
• SSR-HW-001 (Ready for Customer Alignment): The ECU hardware shall provide the platform and secure-storage capabilities required for Hardware platform support.
• SSR-LIFE-001 (Ready for Internal Review): The ECU and supplier process shall handle lifecycle, field return and decommissioning for Hardware platform support, including secure data and key handling.
• SSR-LIFE-002 (Candidate): The ECU and supplier process shall handle lifecycle, field return and decommissioning for System behavior, including secure data and key handling.
• SSR-LOG-001 (Candidate): The ECU shall record bounded security-relevant events for Logging and audit trail with sufficient integrity and context for diagnostics and incident evidence.
• SSR-COM-002 (Blocked by Customer Clarification): 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-TOOL-001 (Ready for Customer Alignment): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.
• SSR-TOOL-002 (Blocked by Customer Clarification): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.
• SSR-TOOL-003 (Ready for Customer Alignment): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.
• SSR-DAI-002 (Candidate): The ECU shall verify the authenticity and integrity of System behavior data and reject manipulated or unauthenticated data.
• SSR-COM-003 (Blocked by Customer Clarification): The ECU shall restrict and protect communication for Backend and IT integration, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-TOOL-004 (Candidate): The supplier shall provide the tooling, IT infrastructure and evidence storage required for Engineering tooling.
• SSR-COM-004 (Candidate): The ECU shall restrict and protect communication for Engineering tooling, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-COM-005 (Candidate): The ECU shall restrict and protect communication for Hardware platform support, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.
• SSR-SYS-009 (Candidate): The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.
• SSR-RBAC-001 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Diagnostic security, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-VV-001 (Blocked by Customer Clarification): The supplier shall verify and validate System behavior per the agreed cybersecurity verification and validation plan.
• SSR-DIAG-001 (Blocked by Customer Clarification): The ECU shall provide the diagnostic services for System behavior required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DIAG-002 (Blocked by Customer Clarification): The ECU shall provide the diagnostic services for System behavior required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-UPD-001 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for System behavior, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-UPD-002 (Candidate): The ECU shall support secure software update/flashing for Hardware platform support, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-BOOT-001 (Blocked by Customer Clarification): The ECU shall verify boot and application authenticity/integrity for Application software behavior and enforce the defined behaviour on verification failure.
• SSR-BOOT-002 (Candidate): The ECU shall verify boot and application authenticity/integrity for Hardware platform support and enforce the defined behaviour on verification failure.
• SSR-UPD-003 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for Application software behavior, 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 System behavior and enforce the defined behaviour on verification failure.
• SSR-DIAG-003 (Blocked by Customer Clarification): The ECU shall provide the diagnostic services for Backend and IT integration required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DAI-003 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Application software behavior data and reject manipulated or unauthenticated data.
• SSR-UPD-004 (Candidate): The ECU shall support secure software update/flashing for External interfaces, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-RBAC-002 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-RBAC-003 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Backend and IT integration, 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 Application software behavior using the agreed secured data transfer / data security container scheme.
• SSR-LOG-002 (Ready for Customer Alignment): The ECU shall record bounded security-relevant events for Hardware platform support with sufficient integrity and context for diagnostics and incident evidence.
• SSR-RBAC-004 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-UPD-005 (Blocked by Customer Clarification): The ECU shall support secure software update/flashing for Backend and IT integration, accepting only authenticated, integrity-verified software through the agreed programming sequence.
• SSR-VV-002 (Ready for Customer Alignment): The supplier shall verify and validate Backend and IT integration per the agreed cybersecurity verification and validation plan.
• SSR-VV-003 (Ready for Customer Alignment): The supplier shall verify and validate Application software behavior per the agreed cybersecurity verification and validation plan.
• SSR-DAI-004 (Blocked by Customer Clarification): The ECU shall verify the authenticity and integrity of Backend and IT integration data and reject manipulated or unauthenticated data.
• SSR-COM-006 (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-COM-007 (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-SDT-002 (Ready for Customer Alignment): The ECU shall protect security-relevant data transfer for Hardware platform support using the agreed secured data transfer / data security container scheme.
• SSR-DIAG-004 (Blocked by Customer Clarification): The ECU shall provide the diagnostic services for Application software behavior 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 System behavior 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 Hardware platform support required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-DIAG-007 (Candidate): The ECU shall provide the diagnostic services for External interfaces required by the allocated customer requirements, including the specified services, sessions and data identifiers.
• SSR-RBAC-005 (Blocked by Customer Clarification): The ECU shall enforce authenticated, role-authorised access for Hardware platform support, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-RBAC-006 (Candidate): The ECU shall enforce authenticated, role-authorised access for System behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.
• SSR-KEY-002 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Certificate handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-CON-002 (Ready for Internal Review): The supplier shall produce and maintain the cybersecurity concept and verification evidence covering System behavior.
• SSR-KEY-003 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Application software behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-KEY-004 (Candidate): The ECU shall manage key and certificate material for System behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• SSR-KEY-005 (Blocked by Customer Clarification): The ECU shall manage key and certificate material for Backend and IT integration across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.
• 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-KEY-006 (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-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-005 (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-VV-005 (Candidate): The supplier shall verify and validate External interfaces per the agreed cybersecurity verification and validation plan.
• SSR-COM-008 (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] 389 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.