ISO 21434 Deep Dive (3): Project-Level Management and Supplier Collaboration (Clauses 6 & 7)

By /

Editor's note:This is the third article in our "ISO 21434 Deep Dive" series, covering Clause 6, "Project-Level Cybersecurity Management", and Clause 7, "Distributed Cybersecurity Activities" — once the organization has set the rules, this is how the work actually gets done on projects.

1. Clause 6: Turning Organizational Policy into Project Action

Clause 6 focuses on cybersecurity management at the individual project level: it converts organization-level policies, processes and resources into concrete, executable project actions, keeping the product secure, controllable and compliant across the full life cycle from design to delivery. Four key objectives:

  • Accountability to individuals:define cybersecurity responsibilities and authority for each project role so that accountability for security activities is traceable;
  • Actionable planning:produce a project-specific cybersecurity plan that defines concrete security activities, deliverables and timelines;
  • Security argumentation:build a "Cybersecurity Case" that systematically demonstrates the project has reached the security level required by its objectives;
  • Independent assessment:conduct an objective cybersecurity assessment to verify the effectiveness of security measures and the sufficiency of the cybersecurity case.

The underlying logic: the organization provides top-level policy and audit frameworks; the project inherits those requirements and closes the loop throughplanning → execution → assessment, ultimately producing verifiable security outcomes. This is precisely the evidence chain UN R155 auditors scrutinize most when reviewing a CSMS.

2. Tailoring, Reuse and Special Components

The standard does not require every project to mechanically copy all activities: tailoring and reuse are permitted, butevery such decision must rest on sound argumentation and risk assessment:

  1. Tailoring:standard activities may be tailored, but a sufficient rationale must be provided to demonstrate that the adjusted activities still achieve the intended security objectives — groundless simplification is strictly prohibited. See [PM-06-01] and [RQ-06-11].
  2. Reuse analysis:when reusing existing components, assess their fit in the new context and identify potential security risks introduced by environmental changes (deployment environment, interaction interfaces, etc.). See [RQ-06-12] and [RQ-06-13].
  3. Component out of context:for components developed outside their original operating environment, the assumptions made about the operating environment must be explicitly recorded during development, then verified through rigorous testing at system integration. See [RQ-06-15].
  4. Commercial off-the-shelf (COTS) components:when integrating commercial components, their security documentation and vulnerability information must be collected; if the vendor's information is insufficient, additional security testing and penetration assessments are required to close the information gap. See [RQ-06-16] and [RQ-06-17].

For companies that rely heavily on third-party modules, chips and middleware, items 2 to 4 are the most common pitfalls:you may be using someone else's part, but the risk is still yours.

3. Clause 7: Distributed Cybersecurity Activities and Supplier Collaboration

Cybersecurity responsibility for a vehicle is naturally distributed — the OEM, Tier-1 suppliers, software vendors and cloud providers are all involved. Clause 7 answers three questions:how responsibility is divided, how interfaces are defined, and how evidence is passed along.

  • Responsibility allocation:define early in the project which party performs which cybersecurity activities, deliverables and verifications, avoiding "everyone assumed the other side did it" gaps;
  • Cybersecurity Interface Agreements (CIA):use CIAs to specify what information the parties exchange, on what schedule, and under what security requirements;
  • Supplier security management:state cybersecurity capability requirements at sourcing and qualification, write security terms into contracts, and accept deliverables against compliance criteria;
  • Evidence traceability:the supplier's security analyses and test reports must be traceable, forming part of the vehicle-level cybersecurity case.

The three most common failures in practice: deliverables cannot be obtained from suppliers; suppliers build to their own interpretation so interfaces do not line up; and changes are never re-assessed. Our advice: write the cybersecurity deliverables list and milestones into the supplier agreement at project kick-off.

More in This Series

Need Compliance Support?

Is your company working towards ISO 21434 / CSMS compliance? Contact us for a free compliance assessment. QinGuard specializes in automotive cybersecurity consulting, providing end-to-end services from gap analysis and risk assessment to system implementation and certification support.

Scroll to Top