Goals, claims and requirements: ISO/SAE 21434 clauses 9.3–9.5

The concept phase, where the thread starts

Clauses 9.3 to 9.5 of ISO/SAE 21434 are the concept phase, and the concept phase is where the whole traceability thread of a cybersecurity programme is born. If you get these three clauses right, the requirements, architecture, verification and validation that follow have something firm to hang from. If you get them wrong, everything downstream inherits the fault — usually invisibly, until an assessor pulls the thread and it comes apart.

These are the clauses that sit at the top of the left leg of the V. They take the output of the TARA and turn it into engineering. The relationship is simple to state and easy to underdo: item definition scopes the work, cybersecurity goals capture what must be true, and the cybersecurity concept says how it will be made true.

Clause	Name	Question it answers	Principal output
9.3	Item definition	What is the item, and where are its edges?	Item boundary, interfaces, assumptions, operating environment
9.4	Cybersecurity goals	What must hold, given the risks?	Cybersecurity goals (and claims) derived from the TARA
9.5	Cybersecurity concept	How will the goals be met?	Cybersecurity concept: claims, requirements on item and environment

Clause 9.3 — item definition

Everything starts with item definition. An item is defined by its boundary, its interfaces to other items and to the outside, its functions, and the assumptions about its operating environment. This is not paperwork for its own sake: the boundary you draw here decides what the TARA will consider an asset, what counts as an interface an attacker could use, and what you are entitled to assume someone else handles.

The commonest error is a boundary that is vague or optimistic — interfaces left off the diagram, environmental assumptions ("the gateway authenticates all traffic") that are never verified or flowed to whoever owns the gateway. A weak item definition quietly narrows the TARA, and a narrowed TARA misses threats. Precision here pays for itself many times over.

Clause 9.4 — cybersecurity goals

Cybersecurity goals are the top-level objectives for the item, derived from the risks the TARA marked for reduction. A goal states a property that must hold — the integrity of a braking command, the authenticity of a software update, the confidentiality of a key — without dictating how it is achieved. It is deliberately solution-free, because its job is to be stable while the design underneath it changes.

Goals are the hinge of the concept phase. On one side they trace back to specific threat scenarios and risks in the TARA; on the other they trace forward into the cybersecurity concept and, eventually, requirements and tests. A goal with no risk behind it is unexplained; a treated risk with no goal in front of it is a dropped stitch. Alongside the goals sit cybersecurity claims — where a risk is retained rather than reduced, the claim records the argument for why that is acceptable.

Clause 9.5 — the cybersecurity concept

The cybersecurity concept is the strategy for meeting the goals. This is where the abstract becomes buildable. The concept sets out how each goal will be satisfied and allocates cybersecurity requirements — some onto the item and its components, and, importantly, some onto the operational environment. That last category matters: a concept often depends on something outside the item's boundary doing its part, and clause 9.5 is where those dependencies are made explicit rather than assumed.

The concept is the handover point to product development, which is clause 10 — requirements refinement, architecture and implementation. The quality of that handover determines whether the right leg of the V will have anything solid to verify against. This is precisely the connection the V-model makes visible, and it is why the concept phase and the verification phase have to be owned as one thread rather than split between vendors — a point we develop in the ISO/SAE 21434 V-model.

Why these clauses decide the assessment

An assessor rarely fails a programme because a single control was weak. They fail it because the thread is broken — a goal that does not trace to a threat, a requirement that does not trace to a goal, a concept that depends on an environmental assumption nobody verified. Clauses 9.3 to 9.5 are where that thread is either laid down cleanly or muddled at birth. Time spent making the item definition precise, the goals genuinely derived from the TARA, and the concept explicit about its environmental dependencies is time that prevents the expensive, late discovery that the file does not hang together. The standard as a whole, and where this concept phase sits within the lifecycle, is set out in ISO/SAE 21434 explained.

Keeping the concept alive

The concept phase is not a milestone you pass and forget. As the design matures, as the TARA is revisited, and as verification turns up surprises, the goals and concept must be kept consistent with reality. A concept frozen at kick-off while the architecture moved on is a familiar source of assessment findings. The work products are living — item definition, goals and concept are maintained, versioned and traced throughout development.

The AutoSifu view

We treat clauses 9.3 to 9.5 as the place a programme is won or lost quietly, long before the assessor arrives. With CIRT (Pune) as our strategic partner, we run one route — precise item definition, goals genuinely derived from the TARA, and a concept explicit about every environmental dependency — and carry the same thread through solutioning and CoC/VTA preparation with the approval body in the room. When the concept phase is done properly, the rest of the V has something honest to hang from.