COMPARE · TARA APPROACHES
Why spreadsheet TARA is not enough for architecture-aware ISO/SAE 21434 workflows
Spreadsheets can help teams start cybersecurity analysis — they are quick to set up, easy to share, and familiar. As vehicle programmes scale across ECUs, interfaces, trust boundaries, suppliers, attack paths, and review evidence, an architecture-aware TARA workflow becomes necessary to keep decisions traceable, repeatable, and reviewable.
WHERE SPREADSHEETS HELP
Spreadsheets can help teams start
Spreadsheets are a reasonable place to begin. For early-stage work and small teams they are quick, familiar, and need no setup — and that is a genuine strength.
Early concept work — sketching an initial cybersecurity picture before the architecture is settled
Small teams — a handful of engineers can share one file without process overhead
Initial threat brainstorming — capturing first-pass threat ideas quickly
Simple traceability tables — linking a small set of assets, threats, and controls in rows and columns
Offline review — a file can be opened and read without specialised tooling
Lightweight documentation — a low-effort record for a single, contained system
WHERE SPREADSHEETS STRAIN AT SCALE
Where spreadsheets stop scaling
None of this means spreadsheets are wrong. It means a spreadsheet is being asked to do a job it was not designed for once a programme grows. The difficulty is governance, not effort.
Version control — parallel copies drift, and it becomes hard to know which file is current
Collaboration — concurrent edits overwrite each other, and review comments are easy to lose
Repeated rework — each new programme starts from a blank or copied sheet instead of a consistent structure
ECU and interface context — a flat table does not hold the architecture the threats actually live in
Trust-boundary visibility — where data crosses a boundary is hard to see in rows and columns
Data-flow traceability — following an asset through interfaces and flows becomes manual cross-referencing
Attack-path reasoning — multi-step attack paths are difficult to express and review in a grid
Risk-treatment traceability — linking a treatment back to its threat and forward to its evidence breaks under change
Supplier and OEM handoff — sharing a working sheet across organisations mixes ownership and review state
Audit evidence assembly — building a coherent evidence set from many sheets happens late and by hand
THE ARCHITECTURE-AWARE STEP
What an architecture-aware TARA adds
An architecture-aware TARA workflow keeps the same ISO/SAE 21434 method, but links every step to the architecture it belongs to. The analysis stops being a flat table and becomes a connected model.
Assets are linked to the architecture — each asset sits on a real ECU, interface, or function
Damage scenarios are linked to assets and cybersecurity properties — impact is tied to what is actually at risk
Threat scenarios are linked to interfaces and trust boundaries — threats are reasoned about where they can occur
Attack paths are linked to feasible routes through the architecture — tied to real exposure, not abstract lists
Risk treatment is linked to reviewable evidence — each decision carries a traceable record
THE TRACEABILITY CHAIN
One connected evidence chain
An architecture-aware TARA keeps every stage linked to the next, so a change at any point stays traceable through to the reviewable evidence.
- Asset
- Damage scenario
- Threat scenario
- Attack path
- Feasibility
- Risk treatment
- Evidence
SIDE BY SIDE
The same method, held differently
Both approaches run the same ISO/SAE 21434 method. The difference is how well each one keeps the work traceable, repeatable, and reviewable as a programme grows.
| Workflow dimension | Spreadsheet TARA | Architecture-Aware TARA Workspace |
|---|---|---|
| Architecture context | Held informally, outside the sheet | Modelled — assets sit on real ECUs, interfaces, and data flows |
| ECU / interface traceability | Manual cross-referencing between rows | Each asset and threat links to its architecture element |
| Collaboration | Concurrent edits and copies drift apart | Shared workspace with consistent state |
| Change management | Architecture changes are re-entered by hand | Changes flow through linked assets, threats, and treatments |
| Attack-path review | Multi-step paths are hard to express in a grid | Attack paths follow feasible routes through the model |
| Risk-treatment traceability | Links between threat, treatment, and evidence break under change | Treatment stays linked to its threat and its evidence |
| Evidence readiness | Assembled late, by hand, from many sheets | Generated as a by-product of the workflow |
| Supplier / OEM handoff | Working files mix ownership and review state | Structured records with clearer review state |
| Review repeatability | Each programme starts from a blank or copied sheet | A consistent structure repeats across programmes |
This comparison is educational. It does not claim guaranteed outcomes — fit depends on programme scope, architecture, and the engineering review process.
FAQ
Spreadsheet TARA vs Architecture-Aware TARA FAQ
See an architecture-aware TARA on your own architecture.
Bring a representative ECU, feature, or system architecture. We will walk through how the workflow keeps assets, threats, attack paths, and risk treatment traceable — with honest answers on fit and integration effort.