Skip to main content

​
Fields Overview

Field IDDisplay NameTypeRequiredEditable In
cybersecurityContextCybersecurity ContextPlain textRecommendedDraft
assumptionsAssumptionsPlain textRecommendedDraft
systemElementIdSystem Element IDWork item referenceYesDraft
subsystemSubsystemWork item referenceNoDraft

​
Field Definitions

​
cybersecurityContext

Captures the cybersecurity scope of the risk specification document. Describes the system boundaries, interfaces, and threat environment relevant to the TARA analysis. 
Field ID:    cybersecurityContext
Type:        string (plain text)
Appears on:  riskSpecification document header
Purpose: Provides contextual framing for the entire risk analysis. Every stakeholder reviewing the TARA should read this field first to understand what system, interfaces, and threat environment are being analyzed. Example values:
System ElementExample Context
ADAS Control System”ECU controlling brake-by-wire and lane-keeping, ISO/SAE 21434 compliant, V2X and CAN interfaces in scope”
Connectivity Gateway”Telematics gateway bridging V2X, cellular, and in-vehicle CAN networks, external interfaces in scope”
Sensor Fusion ECU”Multi-sensor fusion controller processing camera, radar, and LiDAR data for ADAS decision-making”

​
assumptions

Documents the assumptions made during the risk analysis — external dependencies, environmental conditions, or operational constraints that bound the TARA conclusions. 
Field ID:    assumptions
Type:        string (plain text)
Appears on:  riskSpecification document header
Purpose: Records what was taken as given at analysis time for traceability and audit. Changes to assumptions may invalidate existing TARA conclusions and require re-analysis. Example values:
  • “Assumes secure boot is implemented on target ECU”
  • “Network isolation guaranteed by gateway firewall rules”
  • “Physical access to vehicle interior is unrestricted (worst case)”
  • “OTA update channel uses TLS 1.3 with mutual authentication”
When assumptions change, the associated Risk Specification should be sent back to Draft via the Rework action to trigger re-analysis. All prior approval signatures are automatically invalidated.

​
systemElementId

Links the Risk Specification document to its target system element. This field is used by the Risks Home Dashboard and the TARA Summary Report to discover which TARA module covers which system element. 
Field ID:    systemElementId
Type:        Work item ID reference (string)
Appears on:  riskSpecification document metadata
Behavior:
  • Dashboards use Lucene query type:riskSpecification AND systemElementId:{elementId} to find the TARA for each system element
  • If no document matches a system element, dashboards display a “Missing TARA” indicator (em-dash with nx-missing CSS class)
  • Only the first matching document is shown if multiple Risk Specifications reference the same element

​
subsystem

Optional reference to the parent subsystem for organizational context. Used by the TARA Summary Report in the Unacceptable Risk action items table. 
Field ID:    subsystem
Type:        Work item ID reference (string)
Appears on:  riskSpecification document metadata

​
Field Usage in Dashboards

The following diagram shows how document custom fields feed into dashboard queries: diagram
DashboardFields UsedQuery Pattern
Risks HomesystemElementId, statustype:riskSpecification AND systemElementId:{id}
TARA Summary ReportsystemElementId, subsystemtype:riskSpecification AND systemElementId:{id} AND project.id:{pid}
Cybersecurity Case(indirect via taraRecord module)project.id:{pid} AND type:taraRecord

​
Relationship to Other Configuration

These document fields work in conjunction with:
The riskSpecification document type uses the document_risk.png icon and is displayed as “Risk Assessment” in the Polarion UI. It is the only document type that carries TARA-specific custom fields.
Source: riskSpecification-custom-fields.xml