Is the TARA (Not) Traceable? A Critical Assessment from Item Definition to ALM

First, let’s clarify the term “traceability.” It essentially means ensuring seamless tracking — no gaps, no breaks. (In the multifaceted automotive industry, this has been an immense challenge across countless areas for decades.) In the context of cybersecurity requirements (we’ll dive deeper into Cybersecurity Claims and Cybersecurity Goals later), you must ensure one thing: it’s always clear how these requirements were derived from assets, threats, and risks. And how they were specified, implemented, verified/validated, and adjusted when needed.

What Traceability Really Means in the Context of TARA per ISO/SAE 21434

You can practically verify this end-to-end chain along the TARA methodology by asking yourself specific questions — and examining their answers closely in your development context. These might include:

• Why does this security requirement exist?
• Which risk/threat does it address?
• Where is it implemented in the system/design?
• How was it tested (test, review, analysis)?
• Which changes potentially affect it (impact analysis)?

Here’s what matters: Traceability is more than a web of hyperlinks. It’s the ability to track every security-relevant fact forward and backward, document it with versions, and reliably update it when changes occur.

From the Item Definition (the system description) — its functions, operating states, and interfaces — assets emerge. Building on these, you model threats and attack paths, which produce risks. These risks drive Cybersecurity Goals and Claims, which materialize in test cases and verifiable requirements. Requirements translate into architectural decisions and are backed by tests with solid evidence.

Only when this chain is semantically clean, temporally valid, and organizationally anchored does TARA unfold its impact.

Otherwise, it remains merely a well-organized document.

The Three Pillars of Traceability in TARA: Purpose Over Box-Checking

Let’s briefly take a closer look at the three interlocking principles of traceability that together safeguard the impact of TARA:

1. Coverage: Complete Mapping of the Item Definition

Every function, every operating state, every interface must appear in the risk analysis. Unanalyzed elements are blind spots that become expensive later — in the form of retroactive measures, unclear responsibilities, and avoidable attack surfaces. Coverage isn’t a cosmetic number. It’s the reliability that your picture of system reality is complete.

2. Reverse Coverage: Upward Accountability

This principle, known from functional safety, states: nothing gets implemented without a requirement. Applied to cybersecurity, it means no Cybersecurity Goals and no controls without traceable derivation from an identified risk or concrete requirement. Organizations that live this discipline prevent “security theater” — measures that look good but deliver no verifiable contribution to risk reduction. They unnecessarily increase system complexity or even create new attack vectors. (This also applies in reverse: all risks must be fully mapped to controls.)

3. Quality of Impact Analysis

Changes in the initial situation — a new hardware component, a modified bus, an updated protocol — must automatically reveal which goals, requirements, architecture anchors, and test cases become temporarily invalid and may need adjustment because the risk assessment shifts.

Consistent, end-to-end traceability enables propagation from the changed element along the entire chain to the TARA, selectively updating only the actually affected Damage Scenarios and Attack Vectors. In modern development environments, “suspect links” mark exactly these spots: artifacts that must be revalidated after a change.

Without this disciplined feedback loop, organizations lose both speed and security.

Why? Because decisions rest on outdated assumptions.

The Implementation Gap: TARA Traceability per ISO/SAE 21434

ISO/SAE 21434 defines precisely what’s required for cybersecurity work in automotive development. What the standard leaves open: the “how.” How the concrete design of data flows between individual work products should look.

This gap is intentional. The traceability requirement is already anchored in Automotive SPICE and is meant to normatively allow different approaches and implementations.

For OEMs and suppliers, this creates central implementation questions when it comes to holistic integration of the TARA methodology:

• How are Item Definition results systematically transferred into the TARA?
• How is sufficient comprehensibility, traceability, and transparency ensured in the TARA work itself?
• How do TARA results (Cybersecurity Goals and controls) flow structurally into the ALM tool for requirements engineering and test management?
• How can you ensure completeness, consistency, and precision of data across all levels—especially during changes from functional updates or newly identified attack vectors?

In practice, many development teams work in separate information silos: Item Definition, TARA, and requirements management exist as separate, non-integrated work products.

This fragmentation is still manageable for simple systems. But as soon as system complexity increases or substantial changes occur, manual synchronization between silos fails.

(We haven’t even touched on the challenge of TARA work across organizational boundaries — for that, see our current article on Vertical TARA Integration)

Here’s what you need to understand clearly: A fragmented, inconsistent, and isolated way of working — where information gets lost along the chain, connections aren’t consistently maintained, and contradictions emerge between artifacts — fundamentally contradicts the core principle of ISO/SAE 21434.

Why? Because the TARA is explicitly conceived there as a “living document” that can continuously and dynamically handle new inputs/outputs. It must continuously reflect the current state of knowledge about the system and its security risks — including newly discovered vulnerabilities and functional and architectural system changes.

But how should this work in practice when traceability isn’t ensured to the required degree?

Where Theory Meets Practice: Typical Breaking Points in Traceability

It’s clear that traceability must be ensured throughout the TARA. So it’s worth examining the practical pitfalls and their consequences — across the entire development cycle.

In daily practice, we repeatedly observe typical weak points:

• Goals remain too generic and become outdated: Cybersecurity Goals are formulated so generally that their achievement is barely verifiable. Concrete test criteria are missing. What often happens: requirements tied to these goals are implemented and verified. But whether the goals were effectively achieved remains unclear when the risk assessment isn’t updated with the security measures.
• Measures without requirements: Best-practice catalogs and organization-specific selection options deliver security measures that flow directly into the architecture — bypassing cleanly formulated and traceable requirements.
• Requirements and test cases without hard links: References are made via free text instead of unique identifiers. As a result, neither test coverage nor effectiveness of measures can be reliably assessed.
• Changes break the chain: As soon as hardware, interfaces, or software stacks are adjusted (customer requirements do change occasionally, they say), feedback into the risk analysis happens too late or not at all. The organization loses oversight of its current risk situation in the product.

The Root Causes for Missing TARA Traceability

A series of obstacles can be observed that create the fundamental deficits mentioned above. They span multiple dimensions and fundamentally undermine the quality of the entire TARA and effective cybersecurity:

• Semantic gaps: Links between work products aren’t typed — whether a link “implements,” “mitigates,” “verifies,” or merely “influences” often remains unclear and thus analytically inferior.
• Temporal inconsistencies: Versions and validity periods are rarely maintained cleanly. Evidence from the last release is falsely interpreted as proof for the current state.
• Organizational silos: TARA, requirements management, architecture, testing, and PSIRT work in separate tools. Manual couplings age quickly and create invalid and missing links.
• Information loss in the supply chain: Goals and requirements are passed along as documents instead of as reusable, uniquely addressable data objects — the context becomes diluted.
• Increased and partially unnecessary effort: Possible over-implementation of controls typically binds resources that are then no longer sufficiently available elsewhere — for example, in testing.

Improving Traceability in TARA: A Robust Link Strategy Between TARA and ALM

The integration of TARA results into ALM is ultimately decisive for end-to-end traceability and effective cybersecurity development. Modern ALM platforms already enable direct embedding of TARA activities, allowing cybersecurity risks to be directly connected with requirements, security goals, and test cases.

Transfer Goals and Claims Strategically into ALM

Not just the derived requirements, but also Cybersecurity Goals and Claims should be mapped directly in the ALM tool. Why? Because they provide the context that’s indispensable for stakeholder requirements and impact analyses.

Here’s the distinction you need to make:

1. Goals and Claims with Security Controls

For these, you must map concrete requirements in ALM that describe both the security controls and their effectiveness in relation to the referenced attack. Bidirectional linking to Goals/Claims is mandatory — only this way can changes propagate in both directions. At the same time, consider additional linking to customer requirements where relevant.

Critical validation question: Has the introduction of the security control actually made the risk acceptable, so that the Goal can become a validated Claim? This question shouldn’t first be answered in the penetration test (or similar). Re-evaluation of the risk — including the implemented security control in the updated TARA — should deliver the answer already during development.

2. Claims Without Security Control

Is derivation of requirements unnecessary? Then the risk is assessed as acceptable without additional measures. But: for attacks evaluated as very difficult to execute, validation through penetration testing is still required. A corresponding validation link should be provided in the ALM tool here as well.

General recommendation: All Claims that contain controls or whose attack path was evaluated as difficult should be systematically validated through penetration tests — this must be traceable in ALM. (Simultaneously, Claims without assigned controls should also be validated — for example, through solid evidence in risk sharing with the customer or through formal management approval when accepting risks due to technical constraints — which is why ultimately all Claims should be consistently captured in ALM.)

3. Risks with Very Low Damage

Risks assessed as low due to their negligible damage require no linking into the ALM tool. This distinction saves effort and doesn’t unnecessarily overload the system.

A Lifecycle Perspective on Cybersecurity: From Goal to Claim

At the end of the development process, all Goals should have become verified and validated Claims.

System-side rule: The links to requirements and tests remain intact — even when the status has changed from “Cybersecurity Goal” to “Cybersecurity Claim.”

This continuity is crucial. Only it enables you to trace at any time which requirements and tests address which security goal and, above all, whether this goal was actually achieved.

This end-to-end traceability between cybersecurity requirements, risks, test cases, and design artifacts is also essential for compliance and the much-discussed assessment readiness. (Newer vehicle regulations will increasingly focus here — see also the current article on Korea Vehicle Security Regulation)

Functioning Synchronization: The Key to TARA as a “Living Document”

The core challenge lies in the fact that a TARA is never “finished.” Although cybersecurity was initially viewed by many OEMs and suppliers primarily as a “development topic,” it was widely underestimated that security must be reliably demonstrated and operated throughout the entire vehicle lifecycle.

With technical advancement (more software, connectivity, updates) and associated regulation, it’s clear today that it’s more of a continuous mandatory program. Without project closure, until support for a vehicle has expired.

In this context, ISO/SAE 21434 explicitly defines the TARA as a “living document” and places the lifecycle-oriented approach front and center.

The Dynamics of the Threat Landscape in Vehicle Security

Concretely, it’s about the dynamics of the threat landscape. The cybersecurity environment changes continuously. New vulnerabilities become known (CVEs). Attack methods evolve. System architecture also changes through updates, patches, or new features. Components are replaced or suppliers change. Each of these changes can make existing risk assessments obsolete.

For architecture changes:

• The TARA must be updated to reflect the new attack surface
• Asset definitions can change
• New interfaces or data flows emerge
• Existing threat scenarios must be reassessed

For new threats in operation:

• Vulnerability monitoring continuously delivers new information
• Exploit availability can change risk assessment
• Field incidents reveal real attack vectors

The Critical Synchronization Loop: When a risk assessment in the TARA changes, this must become immediately visible through linking in ALM.

Concretely, like this:

1. Automatic marking as “suspect”: The affected attack paths — and thus the affected Goals and Claims as well as all directly or indirectly linked requirements and test cases — are marked as “suspect.” This signals: Attention, action may be needed here!

2. Structured review processes: Development and test teams must systematically check:

• Is the requirement still necessary and sufficient?
• Must the requirement be adjusted (e.g., stronger encryption)?
• Must the test case be expanded?
• Are completely new requirements or test cases needed?
• Can requirements be dropped because the risk was reassessed

3. Bidirectional feedback: Changes to requirements or tests must flow back into the TARA to update Claims.

The Danger of TARA as a “One and Done” Snapshot

Without automated or at least strongly process-linked synchronization, TARA and ALM content aren’t living documents — they’re snapshots that quickly become outdated.

The consequences are obvious:

• Inconsistency: TARA and requirements drift apart
• False security: Outdated Claims suggest protection that no longer exists
• Compliance risk: During audits or in case of damage, the inconsistency can’t be explained
• Loss of risk overview: The organization loses the ability to reconstruct its actual security situation

At the same time, we always try to examine cybersecurity questions from a business and financial perspective. All too often, missing traceability — and thus false connections — lead to costs and effort around cybersecurity (and associated implementations) that could have factually been avoided. (To expand on this point, here is another article: Cybersecurity in vehicle development is not an end in itself – it is a lever for reducing costs)

Concrete Action Recommendations for TARA & ALM Synchronization

The following points are proven first levers to efficiently trigger updates, track them consistently, and document them audit-ready:

• Tool support: Invest in ALM tools with native TARA integration or develop interfaces for automated synchronization
• Suspect link management: Establish clear workflows for how suspect-marked elements are to be handled (responsibilities, deadlines, escalation)
• Define change triggers: Specify which change types trigger a TARA update (e.g., architecture changes above a certain severity level, all CVEs with CVSS > 7.0 applicable to the system)
• Versioning: Work consistently with versions and baselines — both in TARA and in ALM
• Regular consistency checks: Conduct quarterly automated checks that search for orphaned links, unresolved suspects, or missing validations

Brief Digression: Why Don’t ASPICE and ISO/SAE 21434 Assessments Already Cover This?

You might ask: If traceability is as important as outlined, why don’t companies constantly fail ASPICE or ISO/SAE 21434 audits here?

This lies in the current reality of classic assessments. The answer lies in the depth and focus of the examination.

Assessors often still check statically and document-based:

• ✓ “Is there a TARA?”
  – Yes, here it is.
•  
• ✓ “Are Cybersecurity Goals defined?”
  – Yes, see Chapter 5.
•  
• ✓ “Are there derived requirements?”
  – Yes, documented in the ALM tool.
•  
• ✓ “Are the Goals referenced in the requirements?”
  – Yes, via free text or ID.

What’s often missing: Checking dynamic development and consistency across tool boundaries and time. (Even if individual, specifically prepared traceability examples might occasionally be requested.) In a typical week-long assessment, it’s generally difficult to prove that:

• A “suspect link” after a TARA change correctly led to a change requirement in ALM
• This change requirement was actually implemented and tested
• Feedback from the test flowed back into the TARA
• The Claim now validly reflects the updated state

Yet this is precisely where the risk lurks for product certification and field operations.

A lack of traceability is a lack of process control — and this becomes critical in the following situations:

Questions That Should Be Asked (But Often Aren’t)

“Has the introduction of a security control actually made the risk acceptable?”

• Can you turn the Goal into a validated Claim?
• If this question isn’t systematically answered, you only find out in the penetration test or — worse — in the field whether the defined security controls were effective
• Best practice: Re-evaluate the risk including implemented security control in the updated TARA — this way you know already during development whether the goal was achieved

“Are all Claims that contain controls validated through penetration tests?”

• Without systematic linking to validation activities, this question is unanswerable
• Claims without validation are assertions without proof

“When new vulnerabilities emerge—how do you recognize the impacts on existing risks?”

• Without mapping CVEs to assets and requirements, this remains manual work and gut feeling
• The TARA becomes outdated a bit more with each patch cycle

“When risks change and new Goals emerge — how do you see the impacts on requirements and test cases?”

• Without bidirectional links, complete impact analysis is impossible
• Gaps emerge: new risks without requirements, old requirements without current risk reference

Conclusion: Traceability in TARA Isn’t a Feature — It’s the Prerequisite for Effective Vehicle Cybersecurity

Anyone who’s read this far has probably recognized: Traceability in automotive cybersecurity is far more than a technical gimmick for process, workflow, or automation enthusiasts.

It’s the prerequisite for cybersecurity to function at all in the reality of a connected, software-defined vehicle (that receives updates over years, must defend against new threats, and needs to satisfy regulatory requirements).

The Hard Truth: Without end-to-end, bidirectional, and semantically clean linking between Item Definition, TARA, ALM system, and Vulnerability Monitoring, you don’t necessarily create secure systems — rather, the illusion of them. Bluntly put:

• Documents that look good in audits but collapse in the change process (which factually comes!)
• Unvalidated Claims that assert instead of prove
• Requirements that emerge in a vacuum and whose connection to current risk no one can reconstruct anymore

Modern vehicles are already software-defined platforms with over-the-air updates, cloud connectivity, and an attack surface that changes faster in reality than any release cycle.

Static security documentation simply can’t map this dynamic.

Those still working today with isolated Excel TARAs and manual synchronization lose not only oversight of the actual risk situation — they also lose the ability to react quickly and reliably to new threats or architecture changes.

Already today, OEMs (and suppliers) must prove that their cybersecurity processes don’t just exist, but actually work. The question of end-to-end traceability can no longer be answered with a document. What counts then is whether a suspect link after a CVE notification actually led to an impact analysis, whether affected test cases were updated, and whether the updated Claim reflects the new real system state.

Organizations that take this task seriously now and act — with integrated tool landscapes, typed links, disciplined version management, and automated consistency checks — build more than just compliance. They create genuine ability to act:

• The ability to know within hours of a zero-day vulnerability which vehicles are affected, which components are vulnerable, and which measures must take effect
• The ability to immediately see during an architecture change which security goals must be reassessed
• The ability to reconstruct without gaps in case of damage why a decision was made and which evidence supported it

The Paradigm Shift in TARA Traceability Is Clear

Away from isolated documents → toward a networked ecosystem where Item Definition, TARA, ALM, and Vulnerability Monitoring stand in constant, validated dialogue.

Away from static snapshots → toward dynamic, versioned artifacts with semantically precise links.

Away from manual synchronization that collapses at the first substantial change → toward automated mechanisms that trigger suspect links, initiate impact analyses, and orchestrate review processes.

This isn’t a vision for the day after tomorrow — this is the standard for today.

Note: With the CYMETRIS platform for intelligent cyber risk modeling and TARA in vehicle development, a software solution is available for the first time that systematically supports end-to-end traceability from Item Definition through TARA into ALM.