Skip to main content

Cybersecurity Claim

Under ISO/SAE 21434, a cybersecurity claim is a documented rationale for why it is justifiable to share or retain a risk. Claims arise in the concept phase from the risk treatment of the TARA, alongside the cybersecurity goals. A goal says what must be protected. A claim says why a risk is not lowered any further.

When a claim is required

The standard requires one or more claims if the risk treatment of a threat scenario includes one of these decisions:

  • sharing the risk, for example by contract or insurance;
  • retaining the risk because the analysis rests on assumptions.

A note in Clause 15 sounds broader: rationales for retaining and for sharing are recorded as claims. The requirement in Clause 9 is narrower: under it, a small risk retained without relying on an assumption needs no claim. You should still justify the decision, because the verification checks every decision against the result of the analysis.

Claims and assumptions

If the item definition doesn’t provide enough information, the analysis may assume what is missing. For the headlamp example, Annex H assumes that the navigation ECU has a firewall against invalid communication from outside, and that the gateway has strong controls, developed to CAL 4. Retaining a risk with reference to this firewall would call for a claim. Annex H itself shows no claim, since both example scenarios are reduced there.

Claims also feed forward. The cybersecurity concept has to take them into account when it describes the controls, and its verification checks that the concept is consistent with the claims.

Keeping an eye on claims

A goal is eventually achieved and demonstrated. A claim is a statement about the world outside the item, and that world changes. This is why the standard names claims as an input to cybersecurity monitoring. Validation at vehicle level checks whether they still hold. Anyone who reuses an item has to analyse whether they survive the modifications. And anyone integrating a component developed out of context has to validate its claims and assumptions.

Retaining a risk on the strength of an assumption is the least work in the TARA. After that, someone has to watch it for as long as the item is in the field. That only works if what the claim rests on stays visible. This is why itemis SECURE models an assumption as an object of its own that acts on exactly the attack paths it applies to. This is one reason a TARA is never closed and is maintained as a living TARA. Our article on the TARA gives an overview of all steps.

Related terms

Frequently asked questions

What is the difference between a cybersecurity claim and a cybersecurity goal?
Both arise in the concept phase from risk treatment. A goal follows from the decision to reduce a risk and says what must be protected. A claim follows from the decision to share a risk or to retain it because of an assumption, and says why that is justifiable.
Is a claim the same as an assumption?
No. An assumption is information the analysis takes for granted, for example that every certificate authority the item relies on is appropriately managed. A claim is the rationale for a risk decision and often rests on such assumptions. If the assumption fails, the claim wobbles.
Where do claims matter after the concept phase?
In several places. They are an input to cybersecurity monitoring. Validation at vehicle level checks whether they still hold. And anyone who reuses an item has to analyse whether the claims and earlier assumptions still hold after the modifications.
Reviewed by Jens Bühl, Product Owner on October 30, 2026