The TRACE Threat Taxonomy: One Vocabulary Across Threats, Incidents and Risks

Illustration for: The TRACE Threat Taxonomy

Most security programmes hold four separate collections of the same information. The threat model says what could happen. The risk register says what we are worried about. The incident log says what actually happened. The vulnerability findings say where we are exposed. All four describe the same underlying reality, and in most organisations they cannot be joined, because each one describes it in free text written by a different person on a different day.

A threat taxonomy fixes that, and it is the least glamorous improvement with the largest payoff available to most programmes. This post looks at the TRACE taxonomy published at traceproject.info, and at what becomes possible when every threat, risk and incident carries the same identifier.

Why free text cannot be joined

Ask three analysts to name the same threat and you will get “phishing”, “credential harvesting via email” and “social engineering (mail)”. A human reads those as one thing, and a database reads them as three. That single problem quietly disables most of the analysis a security programme would love to do.

• You cannot count incidents by threat type, because the types are spelled differently every time.
• You cannot ask “which of our risks has this incident just made more likely?”, because nothing links the incident to the risks.
• You cannot check whether the threat model anticipated reality, because model and log share no common key.

Every mature discipline solved this the same way. Finance has a chart of accounts. Medicine has diagnostic codes. Security has been slower, and the taxonomies it does have tend to cover one altitude only. STRIDE classifies technical threat mechanics and ATT&CK catalogues adversary techniques, and neither was built to span people, suppliers, physical assets and organisational failure in one scheme.

What TRACE is

TRACE structures threats hierarchically across ten domains, each with a three-letter code, covering artificial intelligence (AII), blockchain and Web3 (BLK), cryptography and protocols (CRP), connected systems (CSY), digital systems (DSY), external dependencies (EXT), information assets (IAS), organisation (ORG), people (PEO) and physical assets (PHY). Beneath the domains sit 53 categories and around 245 individual threat events, and the scheme maps across to STRIDE, NIST CSF and MITRE ATT&CK, so adopting it does not mean abandoning what your tooling already speaks.

Two things distinguish it from the frameworks most practitioners inherit. First, the coverage is genuinely enterprise-wide, because a taxonomy with first-class domains for suppliers, people, premises and organisational failure can classify the incidents that actually fill a log, most of which are not exotic technical events. Second, it is current, because AI and Web3 threats have proper homes rather than being wedged into categories written before either existed.

Tag once, join everywhere

The practice is almost embarrassingly simple, in that every artefact your programme produces gets tagged with the taxonomy identifiers it relates to. A threat identified during modelling carries its TRACE event. A risk on the register carries the events that could realise it. An incident is coded on closure, as routinely as it is severity-rated. A vulnerability finding inherits the events it exposes you to.

Each tag costs seconds at the point of creation. The return arrives when the collections start answering questions none of them could answer alone.

Diagram of the TRACE taxonomy hub joining threat model, risk register, incident log and vulnerability findings

The taxonomy is the join key, so you tag each artefact once and the analysis falls out.

The cross-incident and risk engine

Incidents interrogate the register

Close an incident coded to a given threat event and you can immediately list every risk tagged with the same event, and ask the only question that matters. Is the likelihood we scored still honest? An incident is ground truth arriving to test your estimates. Without the join, that test happens only when someone remembers. With it, the question asks itself.

Patterns surface across incidents

Three incidents in a quarter, logged by different people as a courier data mishap, a SaaS outage and a contractor account misuse, look unrelated as free text. Coded, they are three events in the external dependencies domain in ninety days, which is not three anecdotes but a supplier assurance risk announcing itself. Cross-incident analysis is exactly the analysis free text forbids.

The threat model meets reality

Periodically compare the events your models predicted against the events your log recorded. Predicted but never seen might mean controls are working, or that the scenario was fiction. Seen but never predicted means the model has a blind spot, and now you know which domain it is in.

Coverage gaps become visible

Lay controls, risks and incidents against the ten domains and empty cells become findings. An organisation with no risks, no controls and no monitoring anywhere in the people domain does not have a people risk of zero. It has a blind spot with a domain code.

Reporting gains a stable spine

Ten domains is a board-friendly shape. Incidents by domain, trend by quarter, and risk exposure by domain against appetite all use the same categories every quarter, so trends are real rather than artefacts of renaming.

Adopting it without a big bang

Start with incidents, because they arrive at a manageable rate and coding them takes a minute at closure. After a quarter you will have your first honest incident-by-domain picture. Then backfill the top twenty or thirty risks on the register, not all of them. Tag threats as models are refreshed rather than in a retrospective crusade. Where the 245 events feel too fine-grained for a small programme, tag at category level, because the joins work at whatever depth you tag consistently. And give the taxonomy a named owner, because the whole value depends on the same event being coded the same way twice, and that is a hygiene job someone must own.

The tooling requirement is modest. Wherever your risks, threats and incidents live, they need a field for taxonomy codes and a way to filter on it. A spreadsheet can technically do it, while a platform that holds threats, risks and incidents together does it without the copy-and-paste.

Putting it into practice

Pick the taxonomy, agree the tagging depth, and start coding incidents at closure from next week. Backfill the top of the risk register the week after. Within a quarter you will have answered a question you could not previously ask, and the first time an incident automatically produces the list of risks it just made more credible, the tagging discipline stops needing to be enforced. A shared vocabulary is not paperwork. It is the difference between four documents and one system.

Promoting a TRACE-tagged threat into the risk register in RaptorGRC

The join in practice, with a TRACE-tagged threat being promoted to the risk register in RaptorGRC.