The ISO/SAE 21434 V-model, and where coverage breaks

The V, applied to cybersecurity

The V-model is the systems-engineering shape most automotive engineers already know from functional safety. ISO/SAE 21434 uses the same shape for cybersecurity. You descend the left leg, defining what must be true and designing to it; you turn the corner at implementation; and you ascend the right leg, proving that what you built does what the left leg promised. The value of drawing cybersecurity this way is that it makes the standard's central demand visible: every commitment made on the way down must be discharged on the way up.

Mapping the clauses to the legs

The V is not a metaphor loosely draped over the standard — it maps to specific clauses.

Position on the V	Activity	Clause
Left leg (top)	Item definition	9.3
Left leg	Cybersecurity goals (from the TARA)	9.4
Left leg	Cybersecurity concept	9.5
Left leg (lower)	Cybersecurity requirements and architecture	10
Fold	Implementation	10
Right leg (lower)	Integration and verification	10
Right leg (top)	Validation of the cybersecurity goals	11
Across the whole V	Project-dependent management and assessment	6

The left leg starts with item definition (9.3) — what the item is, its boundaries, its interfaces and its operating environment. From there the TARA feeds cybersecurity goals (9.4), which the cybersecurity concept (9.5) turns into a strategy, and clause 10 turns into requirements and architecture. We treat those three concept clauses in detail in Goals, claims and requirements, because they are where the left leg's quality is decided.

The right leg mirrors it. Integration and verification (clause 10) prove that requirements were met at each level of assembly. Validation (clause 11) goes back to the top of the V and asks the harder question: not "did we build the thing right?" but "did we build the right thing?" — that is, are the cybersecurity goals actually achieved at vehicle level? Sitting across the whole V is clause 6, project-dependent cybersecurity management, which includes the independent cybersecurity assessment.

Why the shape matters for evidence

The reason the V is worth drawing is traceability. UN R155 does not merely ask whether you have a cybersecurity concept; a real assessment follows the thread from a threat scenario, to a goal, to a requirement, to a verification result, to validation at vehicle level. The V is that thread made into a picture. When the two legs are symmetric — every goal on the left has a matching test on the right — the story an assessor needs is already told. This is the engineering behind the management system described in what a CSMS is, and the standard as a whole is set out in ISO/SAE 21434 explained.

Where coverage breaks

Here is the failure the market quietly produces. The two legs of the V are usually served by two different kinds of supplier, and each covers only its own leg.

On one side are advisory and compliance firms that are strong on the left leg. They facilitate the TARA, write the cybersecurity concept, and produce a handsome document set. But they do not verify anything on a bench, so the right leg is thin — requirements that were never tested, goals that were never validated.

On the other side are penetration-testing and security-lab providers that are strong on the right leg. They fuzz the CAN bus, attack the diagnostic stack, and write up findings. But they were never in the concept phase, so their testing is not traced to any goal. The findings are real, but they float — they do not close the loop back to a requirement, and the management system meant to hold them together is described in what a CSMS is.

Both halves can be individually excellent and still fail an assessment, because an assessment is about the whole V. A concept with no verification, or verification with no concept, is a broken thread. The classic outcome is a first assessment that stalls not because the work was bad but because it was disconnected.

Closing the loop

Closing the gap does not require a bigger document. It requires that the same discipline own both legs, so that:

• every cybersecurity goal traces down to at least one requirement;
• every requirement traces to a verification activity;
• verification results feed validation at vehicle level;
• and the whole chain is reviewable by an independent assessor under clause 6.

That is a matter of who holds the thread, not how thick the folder is. When the concept authors and the people who verify on the bench are the same team, or work to the same traceability, the V stays symmetric. When they are two disconnected vendors handing over a PDF, it does not.

The AutoSifu view

We work both legs of the V on one route — concept and TARA on the left, verification and vehicle-level validation on the right — so nothing floats. With CIRT (Pune) as our strategic partner, compliance, solutioning and CoC/VTA preparation run together with the approval body in the room, which is how the thread from goal to test stays intact all the way to assessment. Covering one leg and calling it done is the gap we exist to close.