RSIT Records the State. TLCTC Names the Cause.

When a European CSIRT tags a ticket, it often uses the Reference Security Incident Taxonomy (RSIT). The taxonomy comes from a TF-CSIRT working group, is hosted by ENISA and is built into tools such as IntelMQ and MISP.[1] It is also the repository that ENISA’s threat landscape methodology points to for its own taxonomy update, as I noted in my post on ETL 2026.

RSIT is honest about what it is. One of its maintainers wrote that it is “about the current state of an incident”, not about how the incident came to be.[2] That is exactly the gap a cause taxonomy fills. So I mapped every RSIT value, all 39 of them, to TLCTC. The mapping, its rationales and the generated files are in the repository: mappings/rsit/.

Three questions per tag

An analyst holding an RSIT-tagged record can ask three things, and the mapping answers each of them for every value.

What does the tag already prove? “Malicious Code / Infected System” means foreign code ran, so #7 is certain (R-EXEC). “Intrusions / Unprivileged Account Compromise” means a credential was used, so #4 is certain (R-CRED).
What is still missing? Neither tag says how the code arrived or how the credential was obtained. The mapping names that question instead of guessing an answer.
Is it a successful attack at all? Many RSIT values are not. Intrusion Attempts record an attempt; the Vulnerable class records exposures; Outage and Misconfiguration have no attacker.

RSIT value	TLCTC	What the analyst asks next
Malicious Code / Infected System	<enabler> → #7	How did the code arrive and start?
Intrusions / Unprivileged Account Compromise	<acquisition> → #4	How was the credential obtained?
Fraud / Phishing	#9 → #4	Were the credentials used? That is a separate step.
Availability / Denial of Service	#6 \| #2 \| #3	Capacity, or a defect that crashes the component? (R-SPECIFIC)
Intrusions / Application Compromise	#2 \| #3	Did the application serve the attacker or consume attacker content? (R-ROLE)
Availability / Sabotage	#8 \| #1 \| Abuse of Rights	Physical or logical? Was the actor acting within their access rights? (R-SCOPE)
Intrusion Attempts / Login Attempts	attempt at #4	Did any attempt authenticate? If not, it is a near miss.
Vulnerable / Weak Cryptography	exposure to #5	A state of the target, not an event: no step.
Information Content Security / Unauthorised Access to Information	[DRE: C]	A data state, not a cause. Which step gave the access?
Availability / Outage	no cluster	No attacker: operational risk.

Across all 39 values: 4 name one cluster, 3 name one cluster plus a step RSIT does not record, 7 leave a choice between clusters, 3 are attempts, 5 are exposures, 4 are attacker infrastructure, 4 are data states, 7 are not attacks on an IT system, and 2 say nothing about what happened.

Seven tags, not thirty-nine

The mapping is delivered in RSIT’s own format. RSIT already links its values to MITRE ATT&CK through an rsit2attck crosswalk, which adds one extra field to each value in its MISP machine-tag file.[3] The RSIT mapping does the same with a tlctc field, plus a generated table and a small script to regenerate it.

Only seven values carry a real TLCTC machine tag: Scanning, Social Engineering, Burglary, Distributed Denial of Service, Infected System, Unprivileged Account Compromise and Phishing. In TLCTC a cluster assignment asserts that the step succeeded. A tag on an attempt, an exposure, a piece of attacker infrastructure or a data state would assert a step the record does not show, and every count built on it would be wrong. The other 32 values carry the candidate clusters as text, with the question that decides.

What the mapping cannot do: the terms

Several RSIT values use words that other frameworks, reports and communities define differently. “Phishing” is a URL in RSIT’s description, a social-engineering step in TLCTC and a fraud category elsewhere. “Masquerade” covers both deceiving people and logging in as someone else. “Sabotage” spans wire-cutting, malicious firewall rules, an administrator acting within their rights and bomb threats. “Fraud” and “Information Content Security” group infrastructure, content, misuse and data states rather than causes.

The mapping does not settle what these words mean. It maps each value by its RSIT description, as written. Where one word covers several causes, the entry stays conditional and names the question that decides. Two records with the same RSIT tag can therefore have different causes, and the same cause can sit under different tags.

Clearing up the terms is a task for the RSIT community and for everyone who uses them. What a crosswalk can do is make the ambiguity visible, value by value, instead of hiding it in a one-to-one table.

Using it

Everything is in mappings/rsit/: the canonical mapping with one rationale per value, a decision tree for reading an RSIT-tagged record by cause, and the generated files in RSIT’s format, dedicated to the public domain (CC0) like RSIT itself. The verdicts follow the repository’s ATT&CK, CWE and VERIS mappings where those cover the same concept. A validator fails the build when RSIT adds, renames or removes a value.

RSIT tells you what state you are in. The mapping tells you which part of the cause the tag already gives you, and which question you still have to answer before you can count it.

Sources

[1] Reference Security Incident Taxonomy Working Group (TF-CSIRT, hosted by ENISA), working_copy/machinev1 version 1003, commit b9ad1f8 (13 May 2026), CC0 1.0.
[2] RSIT issue #128, maintainer comment of 17 July 2026. See also issue #70 (2019) on linking RSIT to the ENISA threat taxonomy.
[3] RSIT rsit2attck: the attck field per value and its generated table.
[4] TLCTC mappings/rsit/: tlctc-rsit.json, decision-tree.md, upstream/. TLCTC v2.6 classifications, unchanged in v2.7.
[5] TLCTC v2.7 core paper: R-EXEC, R-CRED, R-ROLE, R-SPECIFIC, R-SCOPE, Axiom III; data risk events. The TLCTC MISP taxonomy is proposed in MISP/misp-taxonomies#348.

TLCTC Framework · v2.7 · CC BY 4.0