Skip to main content

​
Why Dual-Track Traceability?

ISO/SAE 21434 requires two complementary perspectives on cybersecurity treatment:
  1. What to protect — Cybersecurity goals define the protection objectives. Requirements derive from goals, and test cases verify the requirements.
  2. How to protect — Risk controls define the countermeasures. Requirements implement controls, and test cases verify the implementation.
Both perspectives must converge on the same requirements and test cases. A single requirement might simultaneously derive from a cybersecurity goal (defining what must be protected) and implement a risk control (defining how it is protected). This convergence is what makes the traceability chain complete and auditable.

​
The Two Tracks

diagram

​
Goal Track

The Goal Track answers “What must be protected and to what level?” diagram Link roles in the Goal Track:
LinkFromToPurpose
hasCybersecurityGoaltaraRecordcybersecurityGoalConnects risk to its protection objective
derivesRequirementsysReqcybersecurityGoalRequirement derives from the goal
verifiestestCasesysReqTest case provides verification evidence

​
Control Track

The Control Track answers “How is the protection implemented?” diagram Link roles in the Control Track:
LinkFromToPurpose
mitigatesriskControltaraRecordControl addresses the identified risk
implementssysReqriskControlRequirement specifies the control
verifiestestCasesysReqTest case verifies the implementation

​
Convergence at Requirements

The two tracks converge at the sysReq (Requirement) level. A single requirement can:
  • Derive from a cybersecurity goal via derivesRequirement (Goal Track)
  • Implement a risk control via implements (Control Track)
  • Be verified by a test case via verifies (both tracks)
This convergence means that a single test case can simultaneously provide evidence for both the “what” and “how” of cybersecurity protection.

​
Treatment Choice Determines the Track

The treatmentChoice field on the TARA record determines which track applies:
TreatmentPrimary TrackRequired Links
ReducingBoth tracksCybersecurity Goal + Risk Control + Requirements + Tests
AvoidingGoal TrackCybersecurity Goal + Requirements + Tests
SharingDocumentationCybersecurity Claim (text justification)
RetainingDocumentationCybersecurity Claim (text justification)
For Reducing treatments, both tracks are active: a cybersecurity goal defines the target, and risk controls define how the target is achieved. For Avoiding, the emphasis is on the goal (the vulnerability is designed out rather than mitigated). For Sharing and Retaining, the traceability is replaced by documented claims.

​
How the Risksheet Traverses the Chain

The “5. Req & Verification” view in the Risksheet displays the full chain:
  1. Cybersecurity Goal and CAL columns show the Goal Track origin.
  2. Control ID and Control columns show the Control Track origin.
  3. Requirements column uses server-side Velocity rendering to traverse implements back-links from the risk control, finding all sysReq items.
  4. Verification column traverses verifies back-links from those requirements, finding all testCase items.
This automated traversal means engineers do not need to manually maintain cross-reference lists. As new requirements and test cases are linked, they appear automatically in the Risksheet.

​
Traceability in Dashboards

​
TARA Summary Report

The TARA Report dashboard does not directly display the traceability chain but uses verdict data from the Goal Track to compute verdict distribution across the system hierarchy.

​
Cybersecurity Case Dashboard

The Cybersecurity Case dashboard explicitly displays both tracks:
  • Cybersecurity Goals Summary: Lists all goals with CAL badges and status (Goal Track origin).
  • Cybersecurity Requirements Traceability: Lists requirements filtered by classification.KEY:cybersecurity with status (convergence point).
  • Residual Risk Summary: Lists TARA records with verdict >= 4 and their treatment details (triggers for both tracks).

​
Example: Complete Chain

Consider a TARA record for “Spoofed sensor data on the Sensor Fusion ECU”:
  1. TARA Record: Identified with stakeholder “Vehicle Occupants”, CIAx = integrity, verdict = 4.
  2. Treatment: Reducing.
  3. Cybersecurity Goal: “Ensure integrity of sensor fusion input data” (CAL 3).
  4. Risk Control: “Implement authenticated sensor data protocol” (Protective Measure).
  5. Requirement: “SR-101: Sensor data shall be authenticated using CMAC with AES-128” (classification = cybersecurity, derives from goal, implements control).
  6. Test Case: “TC-201: Verify CMAC authentication rejects tampered sensor frames” (verifies requirement).
Both tracks converge on SR-101 and TC-201, providing complete bidirectional traceability from threat through to verification evidence.