Importing an Excel TARA into Specialist Software Without Losing Traceability

Many engineering teams already have a TARA. It lives in an Excel workbook, or in several workbooks that grew across a vehicle program. The records can be valuable and technically sound. The trouble starts during revision, audit and customer reuse.

Moving that information into TARA software is not a column-copying task. A successful migration must preserve what the original engineer meant, including the relationships between assets, damage scenarios, threats, attack paths, ratings, controls and approvals.

Understand the shape of the workbook first

There is no universal TARA Excel layout. One workbook uses separate sheets for each entity. Another puts an entire risk assessment on one wide row. A third encodes security properties in a matrix of X marks. Repeated threat columns and hierarchical attack-tree IDs create more variations.

A migration engine should inspect the workbook geometry and record the source coordinates. Merged cells, blank cells used as ditto marks, hidden worksheets and formulas can carry meaning. Flattening everything into rows too early can destroy that meaning.

The first task is discovery. Identify what data exists, how it is organized and which areas have no confident interpretation.

Preserve the source assessment and the interpreted assessment

Keep two representations. The source representation stores what the workbook says, including its original IDs, rating terms and unresolved references. The destination representation contains the records that QuickTARA's model can accept.

This separation prevents a dangerous failure: quietly changing a customer's data so it fits a new schema. A source cell that says “High” under an unknown risk method does not authorize conversion into a specific numeric feasibility rating.

Every imported value needs provenance. Preserve the workbook fingerprint, sheet, cell or row location, mapping version and identity of the source record. A reviewer should be able to trace a new record to its original spreadsheet location.

Rebuild links rather than copying labels

Take a wide-format row with an asset name, damage scenario, threat, path and treatment. Their co-occurrence can signal an intended relationship. Separate sheets can express the same links through IDs. Another workbook can express relationships through hierarchical identifiers.

The importer needs declared rules for each layout. It should distinguish confirmed references from plausible ones. Two records with the same title are not always duplicates. An ID reused under two assets can identify two different contexts.

Wrong links are worse than missing records. A missing link appears in a review queue. A wrong link can make a cybersecurity conclusion appear supported by the wrong evidence.

Respect the original risk method

Workbooks use different impact and feasibility scales. Some follow an attack-potential method. Others use CVSS-derived criteria or a customer matrix. Do not copy the final colour from one matrix into another and call the rating equivalent.

Import the original factor values and ratings as source data. Recalculate only under a declared, verified method. Show discrepancies to the analyst. Let the team decide whether a conversion is justified.

ISO/SAE 21434 specifies cybersecurity engineering requirements, but the selected method must remain identifiable and defensible. ¹

Make the preview an engineering review tool

An import preview should state the number of assets, damage scenarios, threats, paths, controls and goals it identified. It should show unresolved references, duplicate candidates, unknown value mappings and discarded rows with exact source locations.

The engineer needs to approve explicit exclusions. The destination system must not silently invent records or approve risk treatments. An approved decision from the source workbook still needs a deliberate lifecycle policy in the new system.

The import transaction should either complete under the approved plan or fail without partial product records. Re-importing the same workbook should not create duplicates.

Plan for revised Excel files

The first import solves migration. The second import tests whether the system fits real customer work.

A new workbook revision can add records, change ratings or remove threats. Compare it against the stored previous source representation. Show added, changed, removed and conflicting records. Never overwrite an engineer's newer approved decision without explicit review.

Keep a rollback record. A safe rollback must distinguish untouched imported records from records the engineering team edited afterward.

Evaluate the QuickTARA migration workflow

QuickTARA's structured Excel importer uses mapping previews, validation, source traceability and controlled imports. Its wider multi-layout engine is being developed against a dedicated test corpus. Treat unfamiliar customer formats as evaluation candidates rather than assuming universal automatic import.

Request a QuickTARA Excel TARA migration assessment. Supply a sanitized workbook. Ask for the recognized entities, correct links, unresolved items and a written mapping report before importing production data.

Frequently asked questions

Can any Excel TARA be imported automatically?

No universal guarantee is credible. Layouts, terminology and risk methods vary. A trustworthy engine proposes mappings and exposes gaps rather than fabricating relationships.

What should a migration test measure?

Measure entity and link precision, field preservation, rating consistency, unmapped content and repeat-import behaviour. Give link precision the highest attention.