Manual TARA vs Automated TARA: Why Spreadsheets Don't Scale

Manual TARA using spreadsheets typically spans several workshops and weeks of elapsed time per system, produces inconsistent risk ratings between engineers, and struggles to maintain traceability across ISO/SAE 21434's 42 required Work Products. Structured TARA platforms use AI-assisted threat identification, structured risk scoring, and automatic Work Product generation to shorten the first-draft cycle and keep the analysis consistent — how much they save depends on scope, reuse, and review depth, so measure it on your own programme. For any organization performing TARA at scale, the question is no longer whether to adopt structured tooling, but when.

The Manual TARA Problem

Most automotive engineering teams today perform TARA using a combination of spreadsheets (Excel or Google Sheets), word processing documents, and in-person or virtual workshops. The typical workflow looks like this:

A cybersecurity engineer creates a spreadsheet template with columns for assets, threats, impact ratings, feasibility ratings, risk levels, and treatment decisions. The team schedules a series of workshops — usually several sessions of a few hours each — where subject matter experts from systems engineering, software, hardware, and cybersecurity review the system architecture and brainstorm threats. Between workshops, the cybersecurity engineer consolidates inputs, resolves conflicting assessments, and updates the spreadsheet.

After the workshops, the engineer documents the results in formal work product templates, cross-references them to the system architecture, and circulates the outputs for review. Reviewers provide comments in email or document markups, requiring further iteration. The entire process, from initial workshop scheduling to final approved work products, typically spans weeks of elapsed time per system.

For a vehicle program with many systems requiring TARA, this manual cycle repeats for every system in scope, with workshop time multiplied across every participant — a heavy resource commitment that directly impacts program timelines and engineering budgets.

Why Spreadsheets Fail at Scale

Spreadsheets are general-purpose tools being forced into a highly specialized role. Their fundamental limitations become critical at automotive scale:

• No structured threat knowledge:Spreadsheets have no built-in knowledge of automotive threats. Every threat must be manually identified by the workshop participants, meaning the quality of the TARA depends entirely on who is in the room. If the team lacks experience with a specific attack vector — say, USB-based firmware injection or Bluetooth Low Energy protocol exploitation — that threat simply will not appear in the spreadsheet.
• Inconsistent ratings: When two different engineers assess the same threat on the same system, they frequently arrive at different impact and feasibility ratings. Spreadsheets provide no mechanism to enforce consistent scoring criteria.
• Broken traceability:ISO/SAE 21434 requires full traceability from assets to threats to impacts to risks to treatment decisions to Cybersecurity Goals. In a spreadsheet, traceability is maintained through manual cross-referencing — cell references, row numbers, or naming conventions. As the spreadsheet grows with every asset, threat, and attack path, these references break, become inconsistent, or are simply forgotten.
• Version control chaos:Spreadsheet-based TARAs inevitably spawn multiple versions as different stakeholders contribute. “TARA_v3_final_FINAL_reviewed_JK.xlsx” is a familiar sight in automotive engineering teams. Without proper version control, it is impossible to maintain a single source of truth.
• No reuse across systems: Threats identified for one system (e.g., a telematics ECU) are often applicable to similar systems in the same vehicle or across vehicle programs. Spreadsheets provide no mechanism for systematic reuse of threat knowledge, leading to duplicate effort and missed threats when similar systems are analyzed independently.
• Audit readiness:When audit time comes — whether for CSMS certification, UNECE R155 type approval, or customer review — teams spend significant time reformatting spreadsheet data into presentable work products. The gap between the working analysis (spreadsheet) and the formal deliverable (document) creates additional effort and opportunities for errors.

What Automated TARA Looks Like

An automated TARA platform transforms each pain point of the manual process into a structured, repeatable workflow:

Instead of blank spreadsheet columns, the platform presents a structured system modeling interface where the analyst defines the system architecture — components, interfaces, data flows, and trust boundaries. This model becomes the foundation for all subsequent analysis.

Instead of brainstorming threats from scratch, the platform applies a curated threat catalog to the system model, automatically identifying applicable threats based on component types, interface protocols, and data classifications. The analyst reviews, refines, and supplements the AI-generated threats rather than building the list from nothing.

Instead of subjective rating discussions, the platform provides structured scoring frameworks with explicit criteria for each rating level. Guided assessment reduces inter-analyst variability and creates documented rationale for every rating decision.

Instead of manual cross-referencing, the platform maintains automatic traceability from assets through threats, impacts, feasibility, risks, treatment decisions, and cybersecurity goals. Every element is linked, and changes propagate consistently.

Instead of reformatting for audits, the platform generates ISO/SAE 21434-compliant Work Products directly from the analysis data — ready for review, approval, and submission.

Effort: Measure Your Own Manual and Tool-Assisted Hours

We do not quote a single per-system effort figure here, because the honest answer depends on item scope, how much earlier analysis is reused, and how deep the expert review goes. What changes is where the hours go. A manual TARA spends them in workshops, in analysis and documentation, and in review and iteration, and typically spans weeks of elapsed time. A tool-assisted TARA spends them on system modeling and a first-pass analysis, on expert review, refinement, and validation, and on Work Product generation and final review. A structured tool can shorten the first-draft cycle and keep ratings consistent; the expert review stays.

To compare the two on your own programme, measure your manual engineer-hours per TARA (Hm) from the timesheets of recent manual TARAs of comparable scope, and your tool-assisted engineer-hours including expert review (Ht) on a pilot. Then put them into the model in our ROI of automated TARA post: saving per TARA = (Hm − Ht) × fully loaded hourly rate, and break-even = tool cost ÷ that saving.

Two caveats keep the comparison honest. Formal sign-off by the Cybersecurity Manager sits outside both measurements and is paced by reviewer availability rather than analysis effort. And hours saved only repay a tool licence when there is enough volume — repeat platforms, variants, and re-assessments — which is why the ROI model asks how many TARAs you will actually run.

Quality Comparison: Consistency and Completeness

Beyond effort, structured tooling changes the quality profile of the analysis:

• Threat coverage: Platforms with comprehensive threat catalogs put known attack vectors in front of the analyst for every system, so coverage depends less on what workshop participants happen to remember. Engineers still decide which threats apply and add the ones the catalog does not cover.
• Rating consistency: Structured scoring frameworks reduce inter-analyst variability in impact and feasibility ratings. When the same criteria and guidance are presented consistently, different analysts tend to converge on similar ratings.
• Traceability completeness: Automatic traceability removes the manual cross-referencing that causes broken references and orphaned entries in spreadsheet-based TARAs. Every threat traces back to an asset and forward to a Risk Treatment decision and Cybersecurity Goal.
• Audit readiness: Work Products generated directly from the analysis data are always current, consistently formatted, and structured for audit review. There is no gap between the working analysis and the formal deliverable.

When to Switch from Manual to Automated TARA

The right time to adopt automated TARA depends on your organization's scale and maturity:

If you are performing your first TARA: Starting with an automated platform is ideal. It provides structure and guidance that helps teams new to ISO/SAE 21434 learn the process while producing compliant outputs from day one.

If you have only a handful of systems to analyze: Manual TARA is feasible but inefficient. On engineering hours alone, a tool licence rarely pays back at low volume — run your own numbers through the ROI model before assuming it will. The case at this scale rests on consistency, traceability, and a reusable foundation for future programs.

If you have many systems per vehicle program: The case for automation strengthens quickly. The manual approach scales poorly — the engineering hours, workshop coordination, and consistency challenges grow with every system — and across several programs or platform variants the hours saved can repay a tool licence.

If you manage multiple vehicle programs: This is where automated TARA with cross-program reuse pays back fastest, because volume drives the return. Threats identified in one program should automatically inform analysis of similar systems in other programs, building institutional knowledge over time.

The automotive industry is moving toward mandatory cybersecurity compliance, and the volume of TARA work will only increase. Teams that adopt automated platforms now build capability, efficiency, and institutional knowledge that compounds over time. Those that wait will face an ever-growing backlog of manual TARA work that threatens program timelines and compliance deadlines.

Want to review TARA on your own architecture? Talk to Agnile's cybersecurity engineering team or explore our ISO/SAE 21434 guide for more on the TARA methodology.